Maslow Home Maslow Community Garden Newsletter

Losing USB connection

I’m still relatively new to this Maslow thing, but I had it running fairly smoothly a few weeks ago. I’m trying to cut fairly large arcs that cover most of the sheet. A few days ago, webcontrol started reporting a lost USB connection in the middle of my cuts.

The weird part is that this lost connection only occurs when the sled is in the upper right quadrant of the board. The cuts are completely symmetrical, so every cut that happens in the upper right quadrant is mirrored in the upper left, but the dropped connection only happens when the sled is in the upper right. It’s happened many, many times, so I’m convinced that this isn’t a coincidence and that there’s something about that location.

After the USB timeout, the connection is automatically re-established after a few seconds. It appears to me that the arduino is rebooting. I base this on the fact that the log reports “PCB v1.3 TLE5206 Detected” shortly after the connection timeout. I’m not very familiar with the firmware code, but it looks to me like this would only be printed during the setup() function.

So, why is the arduino rebooting?
Is rebooting the problem, or just a side effect of losing connection?
Is there a way to turn on additional debugging to help me diagnose this?
Is there a way to extend the communication timeout? (Could it be that simple?)
Other ideas?

Some details:
Nothing has changed in my setup between when things were working correctly and when this problem started happening. All code is up to date. I’m running holey calibration firmware.

I did make some minor changes to the gcode between when it was working and when this started. These involved changing depth and changing the number of sub-arcs that are used create the larger arcs. I don’t see how this could be the problem, unless breaking the arc into more gcode commands somehow causes an overflow or something. But why only in the upper right?

The line of gcode where I lose connection varies, but it’s always a G3 command. G3 commands near the bottom of the board do not cause the loss of connection, and not every G3 in the upper right causes the problem. The symmetrical G2 commands on the left side of the workspace never have an issue.

I suspect some sort of interference, but there are no communication or power wires particularly near to where this happens. In fact, there are other parts of the cut where the sled comes much closer to these wires, and there are no problems there. But interference can be a funny thing and difficult to track down. I could see interference causing communication errors, but could it really cause the arduino to reboot?

When the lost connection occurs, the left motor is doing almost all of the work. The sled is being pulled from the right side of the workspace pretty much directly towards the left motor. Perhaps this motor is over-taxed and causing problems.

Some things that I’ve tried, none of which help:
Moved wires to mitigate interference.
Ran extension cords to plug things into different outlets.
Modified the gcode so that the router is doing a very shallow cut to minimize resistance so the left motor doesn’t have to work so hard.
Disabled all the Windows 10 USB sleep/power management settings.
Swapped out the motor control board. (I was desperate and I had a spare.)

Things I still want to try:
Run through the gcode with the router turned off.
Replace the arduino (but I don’t know how to do this – I’ll ask about that in a separate thread).
Change the power supply.
Continue trying to mitigate interference.
Replace the G3 commands with G1 commands. (Maslow reports that it is already doing this because of the large radius, but it’s worth a shot and simple to do.)

Any thoughts would be appreciated.

Thanks in advance,

Eric

Did any of those other changes help? I haven’t seen this behavior before. I think your theories sound good and the things you have tried seem like the right ones to try to me.

Hi, I got exactly the same problem. Was using Maslow few months ago quite a lot, it was no this problem then. May it be something about webcontrol ( software)???

@dead_homer were you able to find a solution?

I haven’t had any Maslow time lately, so I haven’t been able to look into this further. Perhaps this week.

Am I correct that seeing “PCB v1.3 TLE5206 Detected” in the log means that the arduino has rebooted?
If so, can interference cause a reboot? What else would cause a reboot?

My guess is that if its happening in the same spot, then its something in the gcode that’s causing the controller firmware to crash, which then results in a reboot. Most likely something with arcs (G2/G3).

It’s always possible there’s some bug in webcontrol that is causing the problem. Perhaps post the gcode.

Are you running stock firmware or holey calibration? If running holey calibration, you can put the controller into Fake Servo mode and and run the gcode. It will simulate everything without running the motors. If it crashes then, then its almost definitely gcode related.

1 Like

That’s a reboot of the controller. It’s caused by either:

  1. Some hiccup in the usb connection
  2. Host computer, for whatever reason, disconnecting and then reconnecting with the arduino. Sometimes if the host goes to sleep, this might happen.
  3. As mentioned above, some gcode command that is causing the firmware to crash and then reboot.
1 Like

Very good suggestion. This should indicate if its hardware or software. The code to turn FakeServo ON is “the answer to the ultimate question of life, the universe and everything.”

If it fails with FakeServo ON then we will probably need to see your gcode file and/or WebControl logs to find the problem as its almost certainly software. Don’t bother reading further.

If it works with FakeServo ON:
Turn off FakeServo and run Actions -> Test motor/encoder and post results.

If Test motor/encoder is OK then:
Make sure FakeServo is OFF and move the Home position so that the piece is cut somewhere else on the workspace. You could also try physically switching the motors from left to right to see if problem gets mirrored. This could identify a motor power overload condition specific to the cut position.

Beyond that you could try basic process of elimination for USB. These are all edge cases as it sound like a reproducible rather than intermittent problem.

  • Use a different shorter USB cable - motor power draw may reduce USB signal strength on the stock long cable.
  • Tape down the USB cable, with a little bit of slack, on both ends - Could be a specific vibration causing lose connection.
  • Remove all other USB devices connected to device that is running Webcontrol - If using RaspberryPi with WiFi Dongle and Wireless Keyboard/Mouse you could be maxing its power supply. Use at least 2A power for RaspberryPI.
  • Plug USB into a different port on device that is running Webcontrol - Wear could make it lose or could just be a weak soldered port.
2 Likes

Thank you everyone for the suggestions. I finally got some Maslow time and tried out many of these. Unfortunately, it’s still not working.

Here’s what I tried this time:

  1. Ran in Fake Servo mode. This worked fine. (BTW, this is a great feature!)
  2. Performed a motor/encoder test. No problems reported.
  3. Modified the gcode to remove all cuts (i.e., all z-axis changes), then ran through the gcode, which now just moved the sled around, with the router and vac turned on. This worked fine.
  4. Swapped to a shorter USB cable; routed the cable differently. I still lost the USB connection.
  5. Swapped the left motor for a spare that I had. I still lost the USB connection.
  6. Rerouted electric lines; plugged thing into different outlets. I still lost the USB connection.
  7. Modified the gcode to limit the feed rate to 15 in/min (so the motors didn’t need to work as hard?). I still lost the USB connection.

The location-dependence of this problem makes me think it must be electrical interference. But I’ve re-routed every electrical and communication wire and I get the same behavior.

So maybe then it’s some sort of strain/overload on the motors that’s specific to the cut location. What’s weird is that the cut is left-right symmetrical, but the problem only happens in the upper right. I’d like to try to cut something completely different to see if the problem still occurs. But I’m in the middle of this cut, and I am determined to finish it before I swap out the plywood and try a different cut.

-Eric

Are you saying that the entire codes runs without disconnecting if you remove the z-axis changes?

1 Like

Yes. The code runs with no disconnection problems when I remove z-axis changes.

1 Like

What happens if you run a different file which cuts in that same location?

:man_facepalming:
After breaking my head to get webcontrol to run on ubuntu, I’ve hitch-hiked the entire code of webcontrol to find the phrase “Please enter a number”, while the answer was here all the time :man_facepalming:

3 Likes

I laughed after doing the same thing.

1 Like