UM2 controller reset/reboot when opening USB port on Linux

[stevegt 1]

Hi All,

Can anyone tell me if this is a bug, or a feature? My google fu isn't coming up with a clear answer... With my UM2 (Marlin 14.03, one of the Bay Area Maker Faire batch) plugged into a Linux USB port, the printer resets when I open the port (motors clunk, LEDs go off, LCD display goes black, then everything comes back up as if after a power cycle). It's acting as if one of the I/O lines is attached directly to the reset pin on the board.

This happens even on a read, such as:

$ cat < /dev/ttyACM0

I get the same behavior with both my Ubuntu laptop and a raspberry pi. We don't have Windows or Mac boxen at home or shop, so can't test it that way.

I first discovered this while trying to upload firmware from Cura (also 14.03) -- the reset prevented the upload from starting before timeout. After maybe a couple of dozen attempts over two days, it did manage to upload, and now uploads seem to be working consistently. (That successful upload was just a replacement of Marlin 14.03 with itself -- I didn't want to try anything else until I understood this behavior, but now I'm wondering if something changed without the version number incrementing. I also tried a buncha different baud rates, and now have it at 115200, which is what worked for the first successful upload iirc.)

If the intent was to completely disable anything but firmware updates via USB, then I can understand hardwiring things so that opening the port always causes a reset. (I understand that USB printing is "not supported" for UM2, but I was also under the impression that Daid was working on it, and that g-code controls should work anyway but without any real-time expectations. As far as I can tell, "USB control not possible at all" would be a better description, at least for my particular UM2.)

This is all very confusing to people (like me) trolling around in these forums, seeing references to, say, pronterface, trying to use it with a UM2, and getting the reset behavior on each connect attempt. How might I disable the resets? Is this buried somewhere in bootloader code, or would I need to cut a trace on the board? Are all UM2s like this, or is it just the recent ones? Or is it not supposed to be resetting this aggressively at all?

Thanks,

Steve

 

[Daid 306]

It's normal behaviour that the printer resets if you open the serial port. (This is actually behaviour copied from Arduino)

You might get around the problem in linux with:

stty clocal -hubcl /dev/ttyACM0

There are stability problems with the USB on some computers. Which is why we opted not to officially support USB printing. However, all the code is in place for it to work, and you can actually do it from Cura if you switch to "RepRap" gcode flavor.

If you are more into writing your own code, this is the USB communication implementation of Cura:

https://github.com/daid/Cura/blob/SteamEngine/Cura/util/machineCom.py

(As you need to do flow-control and stuff, doing straight "cat" to the serial port is not recommended)

 

[stevegt 1]

Thanks Daid, that was enough clues to get me going. For anyone else who's interested; there were multiple causes for the behavior I was seeing, which is why I was so confused:

The short version of the story: If you want to talk to your UM2 from pronterface, miniterm, or any other python app, simply set them to 250000 baud, but first upgrade your pyserial to the latest version from sourceforge SVN. (You need r469 or later -- pip doesn't have it yet). This may also be the solution if you're seeing timeouts while trying to upload new firmware to the UM2 from inside Cura. The standard 14.03 version of UM2 Firmware is running at a 250000 baud rate. Unless you've hacked your Linux userland to allow that custom baud rate, you won't be able to talk to the UM2 from e.g. minicom or screen. Neither stty nor setserial are likely to cooperate with setting the baud rate to 250000 either, so don't worry about those not working -- they just won't. But python apps work great after the pyserial upgrade, as long as you set them to 250000 baud. Just go do it, stop reading now, and stop thinking "surely this doesn't apply to me...". :wink:

Here's the long version:

 

• The printer resets when DTR goes high on the USB port. As Daid says, this is normal for many Arduino and compatible variants, particularly newer ones. This is usually implemented by the simple expedient of installing a capacitor between the DTR or RTS line and the reset pin (removing that cap would of course get rid of the auto reset). Some use DTR, some use RTS, while some (like most of my older Arduino variants and compatibles) you need to reach over and hit the reset button to load a new sketch. For the UM2, I was able to narrow it down to DTR by using the miniterm.py application that ships with pyserial -- it lets you toggle DTR or RTS manually.
  
• Using e.g. 'stty -hupcl clocal < /dev/ttyACM0' to keep linux from toggling DTR didn't work in my case. I didn't pursue this further, because I'm happy enough knowing at least what's going on and why.
  
• Even after figuring out the DTR thing, I still couldn't actually talk to the UM2 using miniterm, pronsole, pronterface... All I got was baud rate mismatch noise. It turned out that my UM2 is in fact running at the 250000 baud rate, which is normal for UM2 firmware 14.03, and in order for python apps to talk to it, I needed to upgrade pyserial to the latest SVN version from http://sourceforge.net/p/pyserial/code/469/. At the moment, 'pip install' didn't get me a new enough version.
  
• I have no idea why Cura is now able to upload firmware to my UM2, given that I've got "Machine Settings" set to 115200. I imagine the bootloader might be doing some autobaud magic, but I haven't dug into that yet.
  
• Because of the baud rate mismatch and unpatched pyserial I was running earlier, I can't prove that the autoreset delay had anything to do with Cura's earlier firmware upload timeouts; they could have been caused by baud rate mismatch. I thought about playing around with the timeout settings or adding more sleep times in stk500v2.py, but since I now can't reproduce the problem, there's not much profit in that. For the record, the line of code raising the exception was 'raise ispBase.IspError("Timeout")' in https://github.com/daid/Cura/blob/SteamEngine/Cura/avr_isp/stk500v2.py#L122.
  

 

Thanks again Daid,

Steve

 

[stevegt 1]

Just to add to the mix, I just ran across this change that Daid made to Cura a year ago, to work around any unpatched older versions of pyserial:

https://github.com/daid/Cura/commit/28efc5a0b63d338bd976306460d7f6324fc0d1fb

I'm not sure how this affects my conclusions above -- on the one hand, it would explain why Cura *should* have worked before I upgraded pyserial. But in reality Cura *didn't* work for the first 20-30 attempts at uploading stock firmware to the UM2. And then it worked once, and has worked on every try since then. And it started working before I upgraded pyserial.

Something makes me think stk500v2.py needs about a 4 second sleep in stk500v2.connect(), right after cycling DTR, before the flushes; give the firmware plenty of time to finish setup. But I can't prove it, because I can't make uploads fail now.

Steve

 

[stevegt 1]

Okay, forget what I said about the 4 second sleep -- just had a string of those timeouts again tonight, while jumping back and forth between stock and custom firmware. Added a 4 second sleep in connect() but that didn't stop the timeouts. The only thing I can add is that it seemed that the motor clunk was a lot louder on the attempts that ended in timeout, while the successful upload attempts were quieter. EMI? Pretty subjective observations though.

Steve

 

[Daid 306]

stk500v2 talks to the bootloader, not the firmware itself.

 

[stevegt 1]

Another clue -- got a string of timeouts from Cura today, no luck loading firmware. Exited, restarted, same problem. Connected via pronterface, no issues there. Went back to Cura, loaded firmware on first try, works fine since then.

The timeouts always come in solid strings. They're not intermittent; it either works or it doesn't. Recalling my earlier experiences, Cura had upload timeouts for the first two days I had it. I gave up, started playing around with pronterface, didn't get it working because of the old pyserial, went back to Cura and it began uploading fine.

Hypothesis: Something pronterface does with DTR or the Linux USB device is cleaning up whatever problem Cura is having.

When this happens in the future, I'll try other tools -- miniterm, stty, and setserial -- and see if any of them have the same curative effect. I'll also see if pronterface is consistent in its effect.

Since I can't make the timeouts happen on demand, this is going to take a few weeks, maybe months. :wink:

Steve

 

[stevegt 1]

Still thinking about that louder "clunk" that's associated with the timeouts. We know the Z axis friction is lower on my particular printer (leading to z axis homing bug fix).

 

Following that lead, I was able to cause a single timeout today:

 

1. connect via pronterface
   
2. G28
   
3. G0 Z210
   
4. disconnect pronterface
   
5. Attempt firmware upload from Cura while watching the bed. After Cura raises DTR, the bed falls to the floor, then Cura times out.
   

Hypothesis: As the bed falls, the Z axis motor acts as a generator, emitting EMI, mucking up the reset and causing Cura to timeout.

I don't know if this is really what's happening or not, particularly since I was only able to cause one timeout this way, and haven't yet been able to cause another. Just a data point.

If there are no objections, I'm considering starting a new topic about these timeouts, since the original purpose of this topic is only distantly related. Maybe more eyes will help narrow it down.

Steve

 

[Gurtaj89 1]

Hi @Daid and @Steve,

I encountered a similar issue while trying to connect my Ultimaker 2 Extended + to a raspberry pi. I was trying to get data from temperature sensors while the print was in progress. But every time I sent in a request via serial from the raspberry pi , the printer would reset. After reading your post, I have some perspective on why that was happening.

However, my intention here is not to print via USB but rather just use it for getting temperature values. One crude way that I figured out was to establish the serial connection first and then start the print using the dial and display of the printer. But it seems that doing this might be interfering with the printer functions as the display intermittently shows "Printing using USB".

Is there  a way I can work around this ? And how frequently can I request such data from the printer ? Are there any serial buffer considerations?

Edited April 14, 2017 by Guest

[Daid 306]

There are some ways around the reset, on linux, with stty (you will have to google a bit, you will have to disable all modem control lines). There is no real issue in requesting temperature data very often, if you in a loop "request&wait for reply" you won't run into any issues. The firmware itself cannot buffer more then 4 commands.

This all can be made to work, but it's not the easiest thing in the world.