Cura: Current print is sabotaged when launching new Cura

[Xisle]

Application Version: 15.05.96
Platform: OS X 10.9.5

Steps to Reproduce:
Launch new Cura while printer is printing

Actual Results:
Print fails -1

Expected results:
Cura would launch without effecting current print

[awhiemstra]

This is actually more of a bug in the USB serial firmware. It resets the printer when you try to connect to it, even when not sending any commands. Since we try to detect what printers are connected on launch, this can trip up the ongoing USB print.

I do not yet know how to solve this apart from completely delaying any attempts to determine connected printers, which in my opinion is not really a nice solution.

[nickthetait]

One option might be a shared list of COM ports which are available or currently in use. If this list has not been created (first instance of Cura to be started) then the normal printer detection is run. If the list exists, then don't let a new instance connect to printers which are being used.

[Xisle]

The old Cura connects to the printer after choosing "Print". Isn't that still a viable option? Some people want to try Cura before they buy a printer or just to produce a .gcode file [edited].

What benefit is there to printer querying on startup? Cura should perform slicing without one IMO.

[nallath]

Yeah, but it would be nice to know if the device you found is an device that you can actually use. If you connect an arduino with the old Cura, it thinks its a 3D printer. The polling ensures that we know if there are printers connected.

[Xisle]

That leaves anyone without a printer unable to use Cura.

How do you determine if the Arduino connected is a printer or not? Can that be done after clicking Print?

I personally have every printer you make added to Cura 15.04 for helping others on the forum and in chat. This is impossible with the new Cura :|

[nallath]

No, it simply checks if there are printers. It will still be able to save to SD / G-code. I don't know why you think that isn't possible. It simply wants to know if the option of usb streaming is at all possible before doing anything.

It can be done after you click the button. But the main point of what we do now is that we know before hand if there is a printer. I think its kinda bad user experience to see a 'print with usb' button, only to find out after you clicked it that it doesnt work.

The only way we know that something is a printer is simply sending some commands to it and checkin its responses. If those are okay, we can safely assume its a 3D printer.

[Xisle]

First of all, I resolved my problem of not being able to slice without a printer. The UM2 I had added to an earlier beta version was not allowing slicing - adding a new UM2 fixed it.

Issue #69 and Issue #70 are similar.

If the old Cura process is active when the new Cura is launched, no slicing can occur. ( Issue #69 )

When the new Cura starts up, if the old Cura is printing via USB, the current print will fail and no slicing can occur. ( Issue #70 )

I have gotten the two issues mixed up a bit. Sorry for any confusion.

[BagelOrb]

Is this problem fixed by now?

[nallath]

Nope.

[nickthetait]

We (Aleph Objects) are interested in tackling this issue. For reference here is our ticket: https://code.alephobjects.com/T430
Is there any particular way that this should be accomplished?

[nallath]

I'd say add a preference option somehwere that simply disables the auto scanning of USB ports and then add something (machine action mayhaps?) that enables the scanning.

[fieldOfView]

Yes on the preference, but I would have the USBPrinterOutputDevice open/close the USB connection on demand (if the preference option for this behavior is checked). No need for a machineaction, I think.

[nickthetait]

I guess I'm not clear on why auto-scanning is useful. Is it actually needed by anyone? What benefit does it provide?

My point being that we don't need a preference option if it provides little value.

[nallath]

The point is that the auto-scanning ensures that the USB devices that we found are actual printers (and not arduino's / somethin else attached to the printer).

[nickthetait]

Gotcha

[thopiekar]

Wouldn't it make more sense collecting all knowledge in Cura's GitHub wiki? It is great to see all efforts around, but I think it would make more sense keeping it at one place 😉

[kakaroto]

I don't see why it's done that way in the first place. I understand that it's nice to be able to just click 'print' and it's already connected to the printer, but it only saves a second of the user's time maybe ?
As for the argument of not showing the option to the user if it's not an actual printer that is connected, then I don't see that as an issue of Cura, a user can click the "print to USB" button if he wants, but if he doesn't have a printer connected by USB, then Cura can't do anything about that and it's not Cura's fault either. I think it's fine to just pop a message that Cura wasn't able to find any USB printers to connect to after the user clicks the "print to USB" button, rather than not having the button in the first place.

This auto-scan feature has a lot of potential issues though, first of all, as discussed here, it will reset any ongoing print, so you can't open multiple instances of Cura in order to 'play around with a model'.. Also in case you have more than 1 printer connected to the machine, then you simply can't use Cura2 as they'll both try to open a connection to both printers (not sure if you can set a specific COM port for each printer in preferences so you can just print to them from 2 instances, bypassing the auto-detect, like on Cura1). And the use case that personally annoys me the most is that if I have my printer permanently connected through USB to my PC, but my printer (power supply) is actually turned off, then the serial port will still exist, but I just can't connect to it. So after I set up what I want to print and how, then I decide to launch the job, turn on the printer, and now I'm stuck because I can't print to it since that port has already been discarded from the list of potential USB printers because it couldn't connect to it, so I either have to close Cura and lose all the positioning/whatever I was doing, reopen Cura and start over again while it detects that the printer is actually on... or I have to disconnect the USB cable, wait 5 seconds for the USBPrinterOutputDeviceManager to detect that the port disappeared, then reconnect the USB, and wait another 5 seconds for the auto-detection to start again (and God forbid if I plug it back in before the 5 second timeout and I miss the timer and I have to redo it..)
If all of this is to not show a button to the user that doesn't absolutely need to be hidden, then I personally prefer having the behavior of Cura1, as it would solve some usability issues.
What do you think ?

[nallath]

We (read Ultimaker) have been moving away from USB printing and will continue to do so. Future machines will most likely no longer support it in any form. This is the major reason why we haven't spent a whole lot of time in finding the most optimal fix for this. The only reason I see to use it now is to firmware updating, where some form of auto check is nice (but not reaaaly required).
If you want to change this, be my guest. I don't feel like I have enough experience with USB printing to say sensible things about what work flow works best.

[kakaroto]

@nallath ok, thanks!
Does anyone else approve or oppose the idea of changing the USB printing work flow to the way it was before ?

[thopiekar]

Don't know how old Cura was working as I jumped into Cura when we've been working on 2.x.
But the easiest solution I see is to let Cura open only once. So the USBprinting plugin won't try to find a programmer for the print ( the reason why the printer is resetting ).
Alternatively we could use lockfile mechanism to care whether the USB port is already used or not.

I would like to work on that, but this problem doesn't happen to me often and when printing I'm care about using a STL viewer I have installed here.

That said neither got priority on this nor time to care about that. But hope you can get this working 😉

[awhiemstra]

There are basically two steps to the USB printer detection:

1. Look for local com ports that potentially have printers connected.
2. Try to connect to the com ports that were found and determine if it really is a printer we can print to.

Step 1 can be done without any interference with the printer. Step 2 needs to connect to the printer and can potentially break prints.

Personally, I would suggest to reflect this two step process in the USB printing plugin. The first step can be done continuously and without problems. This may lead to false positives but since that only means there is an extra "Print with USB" option this does not seem like a big issue to me. Especially if you can completely disable USB printing from somewhere. Then, when you actually press "Print", it would scan the found serial ports for a connected printer and start printing, with proper error reporting if no printer can be found and maybe allowing to select a specific printer if multiple are found.

This would resolve most of the issues with the auto-scan while not needing to add enable/disable toggles. The two downsides I can see with this is that you may get false positives if you have a serial device connected that is not a printer and that the scanning when starting a print can still interrupt a printer that is printing. This would only be a problem when printing with two usb-connected printers though.

[kakaroto]

@thopiekar the way Cura-1 was working was that when you clicked the 'control' (print to usb) button, the print interface opened, and that's when it started scanning for the printer and connect to it. Your machine settings can also have a specific port/baudrate set (instead of 'AUTO') in which case it just tried to open that port instead of scanning for a printer.
The issue with using a lock file is if someone is using another software (non-cura2) to print, or if printing using the SD card.

@awhiemstra That's what I wanted to do, and I think it would have the less impact on the user. I'll be revamping the usb-printing user-interface at the same time to look a little more like the one we have in Cura LE. But I think for that, it's best to open a new issue to discuss what everyone's input would be on the user interface changes before I start work on that.

The first downside you mention, there's not much that can be done for it, and thankfully, it's not a huge issue, as the second one, I'll think of a way to decrease its effect as much as possible :

• shared memory/lock file so if a second print is ongoing with another cura instance, it would know about it and skip it?
• Keep a cache of the device name and serials it finds and their connection success/failure (Ultimachine RAMBo would eventually be known as a printer, "FTDI serial to USB" would be known as a non-printer if it keeps failing to connect to it over time). Give the user choice for if it detects multiple serials that are "known to be printers".
• Any other ideas that I might come up with to alleviate the issue without causing further problems/false negatives.

So from my understanding, the USB printing system is not a priority right now for Ultimaker, and we have your blessing to fix/implement it differently in order to fix this issue.
Thanks!

[fieldOfView]

I'll be revamping the usb-printing user-interface at the same time to look a little more like the one we have in Cura LE.

Have you had time to check out the changes we made in the 2.3 beta yet? We would like the USB printing to integrate with the monitor area in the sidebar. Other types of printer output will/should also integrate with that, like the OctoPrint plugin that @nallath and I have been working on (see https://github.com/fieldofview/OctoPrintPlugin), a future version of the Doodle 3d plugin, etc.

I'll admit that I don't know how the USB printing looks in the LE edition. Perhaps we can bounce some designs back and forth?

[awhiemstra]

So from my understanding, the USB printing system is not a priority right now for Ultimaker, and we have your blessing to fix/implement it differently in order to fix this issue.

Yes. We just implemented the bare minimum to make things work. Pull requests will be gladly accepted. :)

The first downside you mention, there's not much that can be done for it, and thankfully, it's not a huge issue

Yeah, that is why I said we should probably do it like this anyway. And it might even be possible to get a little bit of information from the system about what is connected to a serial port. At least, for USB devices a manufacturer etc. should be reported. So you can filter out some things that are obviously not printers.

shared memory/lock file so if a second print is ongoing with another cura instance, it would know about it and skip it?

That is probably a good idea since it is fairly simple to implement yet at least prevents Cura from fighting with itself.

Keep a cache of the device name and serials it finds and their connection success/failure (Ultimachine RAMBo would eventually be known as a printer, "FTDI serial to USB" would be known as a non-printer if it keeps failing to connect to it over time). Give the user choice for if it detects multiple serials that are "known to be printers".

I am not sure how well that will work because I do not know how much information you can get from the serial port. It might be possible to combine it with the USB information I mentioned above, in which case we can probably do this fairly safely. On the other hand, if it is just "serial port X failed to connect previously" we should probably do nothing with that.

I'll be revamping the usb-printing user-interface at the same time to look a little more like the one we have in Cura LE. But I think for that, it's best to open a new issue to discuss what everyone's input would be on the user interface changes before I start work on that.

As far as I know, the USB printing in 2.3 uses the print monitor rather than an ugly popup. So you might want to have a look at that, as @fieldOfView also mentioned.

[kakaroto]

@fieldOfView no I haven't looked at 2.3 yet, so thanks for mentioning it, I'll definitely look into that first so we can have good integration with the work you've done already.

I'll admit that I don't know how the USB printing looks in the LE edition. Perhaps we can bounce some designs back and forth?

The Cura LE print interface looks like this :

The 'Resume' button changes from Print to Pause to Resume depending on the current print status. While printing, the move/extrude controls are disabled, and while paused, only the move controls are disabled. The 'Show Log' would only appear if there's an error (can't connect to printer for example), but since I'm running a development version it's always there. Anyways, this interface might be a good starting point, but it has no/little support for dual extrusion so it would need to be redesigned anyways.

@awhiemstra

I am not sure how well that will work because I do not know how much information you can get from the serial port. It might be possible to combine it with the USB information I mentioned above, in which case we can probably do this fairly safely. On the other hand, if it is just "serial port X failed to connect previously" we should probably do nothing with that.

Oh, I am so stupid, I never noticed that saying 'serials' could be interpreted as 'serial port', but what I meant was "serial number", not "serial port"! Every USB device will have a unique serial number, so we can keep a cache of "serials" (read: serial numbers) that have succeeded, so if we see multiple serial ports which have a serial number that is known to be a printer (due to a previous successful connection to it), then we tell the user to chose which port to open instead of scanning them.

Thanks for everyone's feedback! Once I look at the new print monitor of 2.3, I'm going to start a new issue for discussing the UI design if there is a need for such a discussion.

[thopiekar]

The first time I see Cura LE 😮
If I'm not wrong there was someone asking to get his app into Cura with
exactly such controls.
A shame we haven't heard about it again.

[fieldOfView]

Ah, yes, the pronterface/printrun template based ui... I have always found that quite hideous. I think something like how OctoPrint has it could be made to fit better with the looks of new Cura:

[thopiekar]

I find that the controls above look better. Of course the colors don't fit to the Cura theme, but I can image that these controls might be great together with touch as input.

[awhiemstra]

I have personally never understood the purpose of those controls in the first place. :p I would also recommend putting them into a separate machine action plugin rather than cluttering up the print monitor, since as far as I know that is meant for monitoring the state of the print, not actively changing it.

[Ghostkeeper]

I was wondering if caching serial ports could have any effect, but caching serial IDs could work well, if you can get serial IDs from a USB port without rebooting the printer. That's the first real solution to this conundrum I've seen.

[fieldOfView]

@awhiemstra: I actually use them quite a lot with OctoPrint, eg for manually priming my extruder(s), clearing my buildplate remotely, preheating my buildplate, etc. Besides, every other print host has them, so there are a lot of people who have built their workflow around them.

I agree that this should be implemented as a plugin, but would like to have things like tweaking feedrate and temperatures at least in the monitor.

[thopiekar]

I agree.

I see the main need for these controls when it comes to maintenance.
Of course you don't do/need this during a printer. The user should be
already prepared when starting a print.

Also have changing temperature in the monitor should be ok, because the
monitor could provide the same as the printers UI while printing from SD.

Mit freundlichen Grüßen/With kind regards

• Thomas Karl Pietrowski

[kakaroto]

Concerning the print controller UI, I've opened a new issue for that because it seems clear that there is interest in discussing it. This will keep things more organized : https://github.com/Ultimaker/Cura/issues/979

@Ghostkeeper Yes, the serial ID is available, you can get it with 'lsusb -v' if you want, that doesn't open or reset the printer.
Actually, here's a little demo I did in ipython :

In [1]: import serial.tools.list_ports

In [2]: for port in serial.tools.list_ports.comports():
    print("%s -- %s" % (port, port.usb_info()))
   ...:     
/dev/ttyACM0 - RAMBo -- USB VID:PID=27B1:0001 SER=55539333937351416280 LOCATION=2-3

You can easily from there extract the serial number itself. I think there's also a method of retrieving it directly without string manipulation, but I'm not sure.

And from lsusb :

[kakaroto@kakaroto ~]# lsusb  -v -d 27b1:0001 

Bus 002 Device 007: ID 27b1:0001  
Device Descriptor:
[...]
  iManufacturer           1 UltiMachine (ultimachine.com)
  iProduct                2 RAMBo
  iSerial               220 55539333937351416280
[...]

It should be fairly simple to keep a cache of known serial numbers that have had a successful connection in the past. We would still need to scan in case there's a device that wasn't working before (printer was powered off) but would still work now. But it can help at least prioritize which devices to test, and if more than 1 printer is available, let the user know before we attempt to reset them all.

[nallath]

Serial ID won't work for Windows. Ultimaker machines tell you that they are ardunio's, but not quite. Just had an interesting talk about this with @daid.

[kakaroto]

@nallath why would it not work on Windows ? Every USB device has a serial number, as it's part of the USB device descriptor structure. I'd be interested to know the details of what you and @daid discussed concerning this issue.

I just tested the same code on Windows (with pyserial 2.7 instead of 3.0 which I had on linux) and apart from the comports() function returning tuples instead of objects, the result is the same, I get "SNR=" instead of "SER=". The format is somehow different for other devices I have (an ACPI com port from my motherboard, and an FTDI usb to serial cable), but it still has the serial number in there ("VID_+PID_+" format for the FTDI cable).
However, I don't have an Ultimaker machine to test what it returns, but I would expect pyserial to return that information, regardless on whether it appears as an arduino or anything else. If pyserial doesn't, then we can maybe use the win32 API directly to retrieve the device descriptor and get the serial from there.

If you could provide me with the information returned by the serial.tools.list_ports.comports() on your Ultimaker machines, that would be a great help.
Thanks!

[daid]

as it's part of the USB device descriptor structure.

It's optional, and not included after the first 4000 produced UM2s, due to every serial number making a new COM port on windows, and windows running out of COM ports after 4096. Causing major problems for our assembly plant. Removing the unique serial ID caused windows to re-use the COM port mapping. And thus solved a major problem for us.

We've abused the Arduino Mega2560 VID/PID for a large part of the UM2 production by mistake.
The vendor/product strings are different, but Windows caches those from the first device, and thus are useless to distinguish.

The "reset" problem is why the old LegacyCura delayed actual full probing until you tried to do something with the printer, and just made a general assumption about an USB serial being most likely an printer.
I warned Nallath about this issue when he started on this implementation for Cura 2. But his reaction was "that's the users problem". So fight it out with him.

[nallath]

That wasn't my exact response, but whatever. I changed it because the flow made more sense if you weren't printing at the time. If i recall correctly, we only got the responses of the printers being aborted after the first release. At that point the system was in place and never got any priority.

[kakaroto]

It's optional, and not included after the first 4000 produced UM2s, due to every serial number making a new COM port on windows, and windows running out of COM ports after 4096. Causing major problems for our assembly plant. Removing the unique serial ID caused windows to re-use the COM port mapping. And thus solved a major problem for us.

I see! That's not very good, but I guess it only means that UM machines won't be recognized by serial id. Anyways, the serial id is to be able to recognize "this serial port is _definitely_ a printer", if UM machines are recognized as "this serial port may or may not be a printer", then it wouldn't change anything. As long as we're not using the serial IDs exclusively to decide whether or not to connect to a port, then it should have no consequence for us.

[nallath]

The serial is also not able to recognised. If the very first device that you enter is an UM, all arduino boards that you plug in later are also seen as an UM.

[Tahutipai]

Having an option to disable the usb-scan-on-startup would be great.

If I have a print job running, and start up a first instance of Cura, the probing crashes the print job.

[nallath]

fieldOfView is working on this.

[fieldOfView]

... for Cura 2.7

In Cura 2.6, you will be able to turn off the USB Printing plugin altogether as a temporary workaround.

[hsaturn]

Under linux, we have many solution.
1st one at minimum, cura can create

/var/lock/cura/ttyUSBx.lock

while printing for example. Thus any other instance of cura check this lock file before. This is a very common solution to this problem.

Another possibility is to check if the port is already used by any software.
This can be achieved in console by

fuser /dev/ttyUSBx

gives the processe that uses the port. But this won't indicate if the port is really used (printing on it for example).

The first solution should be enough.

[Ghostkeeper]

The problem is not that another process is accessing the same USB port and communication gets mixed up or something, @hsaturn. It also happens with just one instance of Cura.

The problem is that whenever Marlin detects an incoming connection, it reboots to some sort of USB mode. So a lock on the PC side won't make any difference; there is no other software in there that is (or should be) accessing the USB device. It's just Cura trying to probe whether there is Marlin on the other side.

[ianpaschal]

6+ months old, and old versions of Cura. This is a Won't Fix.

[Ghostkeeper]

I would suggest to fix this in new versions of Cura, not in old versions of Cura, no. It is still a bug in 3.2 though and quite a serious one. If you start Cura while a USB cable connects to your printer, the print is ruined.

However this is also a duplicate so I'll mark it as duplicate of https://github.com/Ultimaker/Cura/issues/1478.

[ZericE]

It took me quite a while to figure out why another project I'm working on, one that has nothing to do with 3D printing, was failing due to a USB serial port being inaccessible. I eventually realized the problem only occurred when Cura was open. I've read several of the bug reports on this and understand a real fix may not happen. I do suggest though, that the USB plugin be disabled by default, and when it is enabled, give the user a warning about the unexpected behavior of the plugin. This would save many people from frustration and time trying to figure out their issue.

[growveggies]

For me, Bluetooth audio dropouts started to occur when Cura was active.

How to start troubleshooting that?!?
At some point in time, I was even thinking about EMF interference from the steppers and the heated bed PWM...
But eventually, I solved it.

Two non-active paired Bluetooth devices have serial ports in my system, which were scanned by Cura, which needed attention from the Bluetooth stack, causing dropouts in an active Bluetooth audio connection.

Thanks for pointing out that the USB plug-in can be disabled.
But PLEASE change Cura: make it stop creating all kinds of weird issues in their user's computers by continuously and needlessly scanning all of the serial devices by default.
Fortunately, for years now, I didn't see any of those offending COM-port-hogging apps anymore. It seemed that software developers came to their senses. But now there's Cura...

Unbelievable...

Otherwise: very good product, though.
I'm currently using it for all of my 3D print work. It is connected to an Anet A6, by an Octoprint Raspberry, over WiFi. Works great.