1. Got a question or need help troubleshooting? Post to the troubleshooting forum or Search the forums!

Answered Trying to figure out connectivity issues

Discussion in 'Troubleshooting' started by Michael Keyser, Mar 21, 2017.

  1. Michael Keyser

    Michael Keyser New Member

    Joined:
    Sep 14, 2016
    Messages:
    14
    Likes Received:
    4
    So, I'm trying to figure out a connectivity issue I'm having with my Robo 3D R1+. I've been having random disconnect issues on my printer while using OctoPrint on my Raspberry Pi 3 (RP). Here are a few examples: here and here. This has basically lead me to do my own digging; to the best of my ability.

    I started monitoring my logs in real-time to see if I could track down what's happening. I started up my print, opened up an SSH connection to the raspberry pi (RP) on my phone (Termius - for anyone who cares), ran the following command sudo watch -n 0.5 'cat /var/log/syslog | tail -n 15', and waited. I also use Printoid with the entire setup, so I was able to watch the print with the popup, while keeping an eye out for new log messages to appear below the cam view. After about 40 minutes - sure enough, my print failed. Based on the logs:

    Code:
    Mar 19 18:52:51 octopi systemd[1]: Time has been changed
    Mar 19 18:52:56 octopi dhcpcd[723]: wlan0: no IPv6 Routers available
    Mar 19 18:57:02 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 18:57:08 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:03:32 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:04:55 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:06:04 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:06:23 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:06:30 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:06:31 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:06:31 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:07:37 octopi systemd[1]: Starting Cleanup of Temporary Directories...
    Mar 19 19:07:37 octopi systemd[1]: Started Cleanup of Temporary Directories.
    Mar 19 19:10:44 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:15:34 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:17:01 octopi CRON[6220]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
    Mar 19 19:25:47 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:35:16 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:49:06 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:49:47 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:50:29 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:51:10 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:51:52 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:52:28 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:53:04 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:53:41 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:54:18 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:54:54 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:55:30 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:56:07 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:56:44 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:57:20 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:57:54 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:57:57 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:58:34 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:58:50 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:59:10 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 19:59:46 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:00:23 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:01:00 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:01:36 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:02:13 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:02:50 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:03:26 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:04:04 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:04:40 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:05:18 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:05:54 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:06:32 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:07:08 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:07:08 octopi rsyslogd-2007: action 'action 19' suspended, next retry is Sun Mar 19 20:07:38 2017 [try http://www.rsyslog.com/e/2007 ]
    Mar 19 20:07:46 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:07:46 octopi rsyslogd-2007: action 'action 19' suspended, next retry is Sun Mar 19 20:08:16 2017 [try http://www.rsyslog.com/e/2007 ]
    Mar 19 20:07:55 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:08:23 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:08:23 octopi rsyslogd-2007: action 'action 19' suspended, next retry is Sun Mar 19 20:08:53 2017 [try http://www.rsyslog.com/e/2007 ]
    Mar 19 20:09:01 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:09:01 octopi rsyslogd-2007: action 'action 19' suspended, next retry is Sun Mar 19 20:09:31 2017 [try http://www.rsyslog.com/e/2007 ]
    Mar 19 20:09:38 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:09:38 octopi rsyslogd-2007: action 'action 19' suspended, next retry is Sun Mar 19 20:10:08 2017 [try http://www.rsyslog.com/e/2007 ]
    Mar 19 20:09:47 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:10:16 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:10:16 octopi rsyslogd-2007: action 'action 19' suspended, next retry is Sun Mar 19 20:10:46 2017 [try http://www.rsyslog.com/e/2007 ]
    Mar 19 20:10:52 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:10:52 octopi rsyslogd-2007: action 'action 19' suspended, next retry is Sun Mar 19 20:11:22 2017 [try http://www.rsyslog.com/e/2007 ]
    Mar 19 20:11:31 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:11:31 octopi rsyslogd-2007: action 'action 19' suspended, next retry is Sun Mar 19 20:12:01 2017 [try http://www.rsyslog.com/e/2007 ]
    Mar 19 20:12:08 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:12:08 octopi rsyslogd-2007: action 'action 19' suspended, next retry is Sun Mar 19 20:12:38 2017 [try http://www.rsyslog.com/e/2007 ]
    Mar 19 20:12:46 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:12:46 octopi rsyslogd-2007: action 'action 19' suspended, next retry is Sun Mar 19 20:13:16 2017 [try http://www.rsyslog.com/e/2007 ]
    Mar 19 20:13:00 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:13:23 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:13:23 octopi rsyslogd-2007: action 'action 19' suspended, next retry is Sun Mar 19 20:14:23 2017 [try http://www.rsyslog.com/e/2007 ]
    Mar 19 20:14:01 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:14:39 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:14:39 octopi rsyslogd-2007: action 'action 19' suspended, next retry is Sun Mar 19 20:15:39 2017 [try http://www.rsyslog.com/e/2007 ]
    Mar 19 20:15:17 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:15:18 octopi kernel: [ 4963.021032] usb 1-1.3: USB disconnect, device number 5
    Mar 19 20:15:18 octopi kernel: [ 4963.021314] cdc_acm 1-1.3:1.0: failed to set dtr/rts
    Mar 19 20:15:19 octopi kernel: [ 4963.255371] usb 1-1.3: new full-speed USB device number 6 using dwc_otg
    Mar 19 20:15:19 octopi kernel: [ 4963.369876] usb 1-1.3: New USB device found, idVendor=2341, idProduct=0010
    Mar 19 20:15:19 octopi kernel: [ 4963.369890] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=220
    Mar 19 20:15:19 octopi kernel: [ 4963.369897] usb 1-1.3: Product: Arduino Mega 2560
    Mar 19 20:15:19 octopi kernel: [ 4963.369903] usb 1-1.3: Manufacturer: Arduino (www.arduino.cc)
    Mar 19 20:15:19 octopi kernel: [ 4963.369909] usb 1-1.3: SerialNumber: 85438363139351204151
    Mar 19 20:15:19 octopi kernel: [ 4963.370835] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
    Mar 19 20:15:20 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:15:25 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:15:59 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:15:59 octopi rsyslogd-2007: action 'action 19' suspended, next retry is Sun Mar 19 20:16:59 2017 [try http://www.rsyslog.com/e/2007 ]
    Mar 19 20:16:48 octopi MJPG-streamer [598]: serving client: 127.0.0.1
    Mar 19 20:17:01 octopi rsyslogd-2007: action 'action 19' suspended, next retry is Sun Mar 19 20:18:01 2017 [try http://www.rsyslog.com/e/2007 ]
    Mar 19 20:17:01 octopi CRON[536]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
    Mar 19 20:18:16 octopi rsyslogd-2007: action 'action 19' suspended, next retry is Sun Mar 19 20:19:16 2017 [try http://www.rsyslog.com/e/2007 ]
    Mar 19 20:23:04 octopi kernel: [ 5428.491118] usb 1-1.3: USB disconnect, device number 6
    Mar 19 20:23:04 octopi kernel: [ 5428.491405] cdc_acm 1-1.3:1.0: failed to set dtr/rts
    Mar 19 20:23:04 octopi rsyslogd-2007: action 'action 19' suspended, next retry is Sun Mar 19 20:24:04 2017 [try http://www.rsyslog.com/e/2007 ]
    Mar 19 20:23:04 octopi kernel: [ 5428.731053] usb 1-1.3: new full-speed USB device number 7 using dwc_otg
    Mar 19 20:23:04 octopi kernel: [ 5428.845554] usb 1-1.3: New USB device found, idVendor=2341, idProduct=0010
    Mar 19 20:23:04 octopi kernel: [ 5428.845567] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=220
    Mar 19 20:23:04 octopi kernel: [ 5428.845574] usb 1-1.3: Product: Arduino Mega 2560
    Mar 19 20:23:04 octopi kernel: [ 5428.845580] usb 1-1.3: Manufacturer: Arduino (www.arduino.cc)
    Mar 19 20:23:04 octopi kernel: [ 5428.845586] usb 1-1.3: SerialNumber: 85438363139351204151
    Mar 19 20:23:04 octopi kernel: [ 5428.846386] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
    Mar 19 20:28:38 octopi rsyslogd-2007: action 'action 19' suspended, next retry is Sun Mar 19 20:29:38 2017 [try http://www.rsyslog.com/e/2007 ]
    I can see that the specific USB connection for the printer is disconnecting and then reconnecting. I've even tried swapping out a different RP and it still doesn't fix the issue.

    So, I figure it's either an issue with the USB driver (I have the appropriate power supply - been seeing that as a reoccurring potential fix) or from the modifications on the Arduino I made for mounting my RP underneath the case.

    [​IMG]

    Only thing against the idea of it being the aforementioned modifications is that I don't have any failures at all when printing from Simplify3D. I also found this and figured it might be worth a shot to attempt as well, being that other people have had USB connectivity issues with the RP as well.

    I'm curious if I can replace the Arduino Mega with one that isn't from arduino.cc, like this for example, to test.

    Anyone have any ideas or input on what may causing inconsistent connections with the RP?

    Note:

    This is a continuation on this post.
     
    #1 Michael Keyser, Mar 21, 2017
    Last edited: Mar 21, 2017
  2. Michael Keyser

    Michael Keyser New Member

    Joined:
    Sep 14, 2016
    Messages:
    14
    Likes Received:
    4
    So, an update:

    I'm having disconnects due to someone flipping some incandescent light bulbs on/off (rapidly) on the same circuit my printer is plugged into. That's what's causing my prints to fail. I can see it in my logs, real-time. Observed, tested, reproduced, and confirmed. I've tried two different power supplies that were marketed for the raspberry pi and both are susceptible to the aforementioned.

    So, I got a switching power supply (Mean Well 5v 3A) in lieu of what I had learned and got it all connected to the power supply via soldering CAT5 (rated for 25 watts) to the underneath of the micro USB connector socket. I've tested the input on the raspberry pi and I'm getting a consistent 5v on the test pads. I power everything up and I see that OctoPrint was able to connect to the printer and I'm seeing M105 messages with acknowledgements. After I send ONE move G-Code command, my printer moves as instructed, and stops responding to the M105 messages and I eventually see (2-20 seconds) cdc_acm 1-1.4:1.0: failed to set dtr/rts in my syslog. I have to restart the raspberry pi OS in order to re-establish a connection to the Arduino or else I repeat that error in the syslog upon each attempt.

    image000000.jpg

    So, I added a breadboard into the mix to test voltage from the DC side on my power supply to see if maybe it's not supplying sufficient amps to the Arduino. I'm using the LED as a visual indicator to any noticeable voltage drops and I had my voltmeter in the mix to detect anything upon the G-Code command being sent by me for a move. After a few tests, I couldn't once detect any noticeable drop in voltage. I unfortunately don't have a DC shunt to test DC amps being drawn; yet.

    But, I was wondering if any engineers on this board might have any input as to what might be going wrong. I also found this and wondered if this might be what's potentially causing issues in my switch power supply scenario. When I plug the wall wart back into the raspberry pi, I'm able to control just fine; so long as I don't have little humans flipping my lights on/off...

    The whole purpose of getting this power supply was to provide consistent voltage/current and be able to mount this all inside the case.

    Thank you in advance to anyone who responds.
     
    #2 Michael Keyser, Apr 1, 2017
    Last edited: Apr 1, 2017
  3. Geof

    Geof Volunteer Moderator
    Staff Member

    Joined:
    Nov 9, 2015
    Messages:
    6,757
    Likes Received:
    2,339
    If the power (mains) is fluctuating that severe I'd consider a UPS battery back up. It provides clean power and a supply of power if the mains fluctuates

    Edit: or completely goes out it will keep the printer powered for a short time
     
  4. Michael Keyser

    Michael Keyser New Member

    Joined:
    Sep 14, 2016
    Messages:
    14
    Likes Received:
    4
    Thank you, @Geof.

    I considered the UPS, too. Biggest issue with that is the sensitivity on it being so great, that I'd kill the battery with how often it would switch to battery mode.

    Hence, why I was attempting the switching power supply route. If I can maintain a consistent current for the Arduino, I think that would finally get me down the road, long-term. I'm just not sure how/why I need to do that.
     
    Geof likes this.
  5. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,912
    Likes Received:
    7,338
    Most UPS boxes have software that will let you configure things like sensitivity.
     
  6. Michael Keyser

    Michael Keyser New Member

    Joined:
    Sep 14, 2016
    Messages:
    14
    Likes Received:
    4
    @mark tomlinson agreed. Sorry, I meant that I'd have to set the sensitivity so high (based on my observations) for it to seemingly be effective. Even then, if I'm to invest in a UPS (not to minimize the safety of protecting a print from a power outage), that'd be a costly solution for what I believe I'm already close to. I just need to figure out why the Arduino is becoming unresponsive in the connected to a switching power supply scenario.
     
  7. Michael Keyser

    Michael Keyser New Member

    Joined:
    Sep 14, 2016
    Messages:
    14
    Likes Received:
    4
    I'd also note that the webcam I have connected to the raspberry pi, too, doesn't disconnect (physical and log monitoring observation). So, that's why I'm focused on the Arduino in this case.
     

Share This Page