Cura: Add configuration option to specify serial port connection.

[uchobby]

Application Version
3.6.0

Platform
Win 10

Printer
Creality CR10

Steps to Reproduce
Run Cura then try to open any serial port COMx

Actual Results
Access error indicating that the COMx port is already open

Expected results
Cura should not open and thereby kill all serial devices on a PC

Additional Information
CURA holds serial ports so they can not be accessed by other applications
The previous ticket is similar https://github.com/Ultimaker/Cura/issues/4039. Is unfathomable that that ticket was closed without resolution. Just WOW!

USB connection handling proposal #1049
https://github.com/Ultimaker/Cura/issues/1049
A good solution to this significant bug in Cura. If you can not see how to do this, you should start Cura with a big red bordered splash, "When this software runs, all serial ports will fail to open. We could fix this with a few minutes of coding work but can't be bothered to make things work well for other users."

[nallath]

I understand this is frustrating, but we have limited time to fix things. As we're being paid by Ultimaker (and despite us giving this software way for free and open source, we're still a company), we focus on Ultimaker issues first and foremost.

So if you want a fix, convince the Creatily people to start contributing back to Cura. They are very much welcome to provide a pull request to fix this. But I've made this appeal many times before to them, but I guess them not providing any software is the reason their machines are so cheap. You do get what you pay for I'm afraid.

That being said, did leaving snarky comments ever help you in getting your issue resolved? It's not doing wonders with regards to motivating me to fix it on my own time (as that would be the only alternative at this point).

[uchobby]

Jaime,

Thank you for the feedback. Sorry for being snarky. I was, as you say, frustrated and seeing that the issue had been reported twice with what seemed like a “who cares” response as rejection. It just rubbed me wrong.

I had lost a great deal of personal development time with another project due to the lockout on serial. This was not a minor thing to me. I was trying to troubleshoot several issues at the same time, and the serial port thing greatly aggravated the process. It only dawned on me that Cura was the cause because I had made the same mistake long ago, with trying to make automatic serial port selection work in an application. Cura was not connecting to my printer when it was available, due to some interaction with other software I had using serial ports, so I went on the hunt to find where I could force the selection, and it dawned that you must be doing automatic and did not provide a config option.

Anyway, the combination of my debug serial frustration, then seeing the issue identified and rejected twice, I got a very bad impression and was sure no action would occur anyway. That it would just be rejected again, but I had to try. I am a long time Simplify 3D user and was impressed by the new features in Cura. As it stands now, I will not be able to use Cura without tieing up my development PC with which I am constantly doing other embedded development where I need serial ports.

I do like that you used the automatic detection method but feel that you should allow for overriding it with a config option. As it’s likely others will have this issue and not figure out what’s going on. Your audience is primarly makers who will not be able to do things like Arduino projects for the hours Cura is printing from their PC. Put yourself in there shoes and remove your long history of experience and knowledge of how things work. How would they ever figure out what was wrong?

David

[nallath]

They wouldn't. I fully understand that. But there is just a finite number of things I can do in the first place and that is without having to navigate things like "It's helping the competition". As you can probably imagine, there are always people who feel that even answering issues from third-party printers is already putting in too much time / effort.

That being said; If you don't care about USB printing at all, you can just disable the USB printing plugin in its entirely.

[uchobby]

Jaime,

I do use USB printing.

Does the Ultimaker use a serial port? Wouldn’t this issue occur regardless of the printer type? If so then, this is not a Creality issue.

From what I gather, the issue is that Cura is cycling through all the serial ports looking for any printer. I assume this would always happen when the USB printing plugin is enabled.

The most important issue would be helping the users know about the serial port issue, before it harms things. Not sure what the best way for that is. Nor would I expect the typical user to pay enough attention to notice the information.

David

[zrgravity]

I'm also having the same issue with Cura, where I am unable to use any serial port from another software while Cura is running.

Is there a reason AutoDetectBaudJob (where the USB Printing plugin is spending most of it's time waiting for the printer to respond) couldn't be modified to check any available COM ports less often after it fails x times? Right now, it looks like it continuously keeps all ports open in their own threads, continuously waiting on each for a response to the M105 command. Is this due to the Arduino reset-and-bootload delay every time the port is opened that it has to wait on each port for so long?

Does this behavior continue even when a printer is already connected? For example, if a printer is connected on COM9, will Cura continue to check COM10 and COM11, even though the only configured printer is already connected?

I only use Octoprint with Cura, so I'm not familiar with the USB printing side.

[uchobby]

I had the issue while printing via USB serial, it seems the auto detect runs always regardless of whether or not a printer is already connected.

The auto connect feature is valuable so I’d say keep it but add a config option to set the serial port in the printer details. Only do the search on ports if the port is not specified. You might have a disable auto detect option. The ability to detect multiple connected printers could suffer if this option was disabled. A simple user approach would be to use auto only if you have a printer in the list without a serial port set.

David

[jorgie0]

This is not an acceptable outcome. A program that ties up comm ports when it's not using them is behaving incorrectly.
The work around of turning off the USB plug appears to be a none starter for me as
1/ I cannot find the "USB plug in";
2/ I assume if I turn off USB then I will not be able to control the printer.
Rock and hard place.
Regards
Sean

[uchobby]

This is an issue across the board, not just with non-Ultimaker printers. Any printer, including Ultimaker, would case the serial port concern if it uses USB.

[Ghostkeeper]

Any printer, including Ultimaker, would case the serial port concern if it uses USB.

That's the point though. Ultimaker printers don't support printing via USB any more since the Ultimaker Original. We still sort of support the Ultimaker Original, but the userbase is now so small that it doesn't have a great priority for us.

If you'd like to lay a hand at fixing this via a PR though, we'd be happy to test it for you on Windows, MacOS and Linux.

[hg42]

I had a print running using Printrun. When I opened Cura to check something, my print suddenly stopped.

I don't have any printer configured for usb printing AND I don't use any host functionality of Cura, so why should I expect Cura to access my serial ports and break running communications?
It's a kind of behavior of a virus, very similar to deleting user files.

Note, there could exist other serial communication like logging sensor values or some robot application (both can also be related to 3D-printing). I have done things like this before.
This could also be dangerous, especially because it's not expected in any way.
Cura definitely shouldn't mess with the serial devices like this.

I understand, why you don't like to put work into such a feature.

However, I don't understand the conclusion of your reasoning:

If Ultimaker doesn't use/recommend usb printing (which runs flawlessly for me since many years), why do you enable this kind of autoconnect feature by default for all users?
It would be more logical to disable the plugin by default and eventually enable it for printers known to connect via serial (but then please give at least a warning BEFORE disturbing all serial devices). If the plugin would have an appropriate warning in it's description, the user can choose if he wants to take the risk.

Apart from this, the best way to handle this, would probably be to make the autoconnect optional and add a setting for the serial device, even if it would only be a text field, in case an enumeration seems like too much work. I would generally prefer a text field, because it also allows unusual configurations like a pipe like in case of the Klipper "firmware" or a print server.

[sk8nfool]

I have a related problem on Ubuntu Linux. Cura kills an ongoing print if a second instance is started. This occurs because Cura doesn't open the try (serial device on Linux) exclusively. This means the auto connect mechanism trashes the current print. This is a bug regardless of whether or not any of the above discussion applies. Exclusivity is still required to keep other apps, including Cura, from disturbing an ongoing print.

[weselyn1995]

I would greatly appreciate if this bug would get revisited. A manual option for setting the COM port seems like a reasonable solution to eliminate the auto detect issue.

This bug affects Ultimaker users as well. (I'm using an Ultimaker 2+ which was pretty pricey when I bought it back in the days) Right now I need to use two computers for my project (which aims to track the accuracy of the moving nozzle) as I have to control my printer via USB and log data via another COM port simultaneously.

Please revisit this bug.

[Ghostkeeper]

Sorry, we still don't have time to revisit this.

[jellewie]

G*d dam it's annoying that Cura hoards com ports. I'm a developer and it doesn't matter what I connect when Cura is open I can't use any com port since Cura just hoards them all.

When I try to work on Arduino boards, Cura can't be open..
When I'm programming chips, Cura can't be open...
When I connect my Audio device, Cura can't be open (it uses com audio over Bluetooth)
this list would just go on...

What I would suggest;
Only connect to a Com-port when the user opens the Monitor tab,

Maybe even options that you can select what device and 'auto connect' as suggested above in the original post.

[uchobby]

+1 for jellewie's comment above.

[sk8nfool]

+1 again!!

[hg42]

+1 for sure

[hg42]

btw. the workaround is to disable the USB plugin completely and print with another host software. E.g. use printrun/pronterface/pronsole... (which has some benefits, like gcode plater, much better gcode view, reliable printing).
I personally never used Cura's printing host part...
that's why I wasn't amused to see it disconnect all my devices.

Note, in some situations the behaviour is really dangerous.
E.g. I had a college running a robot that disconnected in the middle of a critical sequence of actions because he started Cura. This created some really bad troubles...he was totally pissed about Cura when he found the reason...words like "crap"...

It's simply totally unexpected that Cura would do that to you and it's a behavior last seen in the days of Windows 3.1, when every software thought it would run alone on the computer.

Multitasking is quite usual these days and it's simply plain wrong to grab more than what you need or really use. It's very similar to busy looping, but with more serious effects.

[foxabilo]

Time to find the "bug/feature" in the source then people. Should be a fairly simple fix, then we do a pull request. It's kinda the point of Open Source 👍 I'll see if I have time to patch the code this week, I'll put the fixed compiled binaries on my GitHub assuming it's an easy fix for the time being.

[fieldOfView]

Let me chime in here. It is _not_ a fairly simple fix (no offense taken).

I wrote the proposal mentioned in the OP (#1049). I took a stab at implementing it here: #1688. I got stuck because - lets face it - the USB Printing code has not had a lot of attention and is a bit of a swamp of a lot of interwoven "simple fixes". Please believe me when I say that every change to the code, no matter how well reviewed and tested, will break someone's workflow, or specific printer/firmware combination. That makes it disheartening to work on this code. Especially for someone like me that has not used USB printing in 6 years (other than for testing my contributions); I prefer using OctoPrint myself.

Because USB Printing currently works for some people, and making changes will break it for some of them, I propose writing a plugin to replace the USB Printing code in Cura. This can be distributed and tested independent of Cura releases and until it is tested by a lot of people with different printers/firmwares, the current solution can continue to work for people who successfully use it. Once the plugin works satisfactory, Ultimaker can consider either including it or simply dropping the current USB Printing code and tell people to download the plugin instead.

I did preparatory work, such as factoring out firmware flashing from the USB printing code (#4275). That should make this undertaking more manageable. I am willing to at least update and polish my earlier attempts. But please know that I am a sensitive person; if people start calling things "crap", I will stop the endeavor.

[foxabilo]

Fixed! don't even need to get a new download 👍 Just create an environment variable called CURA_DEVICENAMES and set the value to COM<your printer com port> and CURA will only open that particular com port, you can use regular expressions to specify a range of ports if yours moves about.

How to set environment variables for your particular OS https://www.schrodinger.com/kb/1842

It's listed in this bit of CURA code along with other environment variables you can specify

    ##  Create a list of serial ports on the system.
    #   \param only_list_usb If true, only usb ports are listed
    def getSerialPortList(self, only_list_usb = False):
        base_list = []
        for port in serial.tools.list_ports.comports():
            if not isinstance(port, tuple):
                port = (port.device, port.description, port.hwid)
            if only_list_usb and not port[2].startswith("USB"):
                continue

            # To prevent cura from messing with serial ports of other devices,
            # filter by regular expressions passed in as environment variables.
            # Get possible patterns with python3 -m serial.tools.list_ports -v

            # set CURA_DEVICENAMES=USB[1-9] -> e.g. not matching /dev/ttyUSB0
            pattern = environ.get('CURA_DEVICENAMES')
            if pattern and not search(pattern, port[0]):
                continue

            # set CURA_DEVICETYPES=CP2102 -> match a type of serial converter
            pattern = environ.get('CURA_DEVICETYPES')
            if pattern and not search(pattern, port[1]):
                continue

            # set CURA_DEVICEINFOS=LOCATION=2-1.4 -> match a physical port
            # set CURA_DEVICEINFOS=VID:PID=10C4:EA60 -> match a vendor:product
            pattern = environ.get('CURA_DEVICEINFOS')
            if pattern and not search(pattern, port[2]):
                continue

            base_list += [port[0]]

        return list(base_list)

[uchobby]

Awesome!!

[Ghostkeeper]

We added that (thanks to @joba-1) as a workaround, but I don't consider that to be a workable solution for most users. More ideal would be to have something in the interface.

[foxabilo]

Yea @Ghostkeeper, a nice menu to change those env's to global vars /ini file values ("Restart required"?) .. you know the kind of thing, would be awesome. Now that should be a fairly simple job. You up for it @fieldOfView ?

[foxabilo]

OK a little salt for an otherwise sugar day, when CURA starts up, it will grab all com ports (this is on windows) but if you have the port already open, it will not try and take anything but the port defined in the environment settings, so there is a different task grabbing all the serial ports that is not using the nice regular expression filter at startup, time to dig.

[foxabilo]

Seems to grab all ports on a timer if you are doing anything but at the final print stage deciding between file and USB. I'll see if I can find the offending USB enumerator after I get the bills paid.

[nallath]

@foxabilo Thanks for looking into it!

[tomb18]

The environment variable does NOT prevent cura from toggling DTR and setting my transmitter into transmit.
How does one tell cura that NO printer is attached? I do not even have one attached to the computer. I carry over the gcode to my printer.

[fieldOfView]

Go to the "Installed" tab of the "Marketplace", scroll down to the "USB Printing" plugin and uncheck it. Restart Cura, and it will no longer touch your serial ports.

[tomb18]

That did it. Thanks very much.

[fleutot]

FWIW, on Debian stretch, Cura steals the tty that I currently have in use (no printing, just opening Cura 4.4.1 and slicing). Even after closing Cura, I can't recover the ttys.

[tikabass]

@fieldOfView Thank you. I've been trying to get rid of this Cura's non-working USB feature for year. It's been very frustrating to have a non-working feature messing with all of my arduinos.

[foxabilo]

@fieldOfView Nice one, great to see the open source community do what it does best.

[JamesHagerman]

Just ran into this as well. Actually, I ran into it 3 days ago and banging my head against the wall was not a relaxing way to spend portions of my long vacation. PlatformIO, Arduio IDE, and any other software expecting to access COM ports are all affected.

It would be polite to add @fieldOfView's suggestion (or a note about this behavior) to a visible spot in the UI. Perhaps a footnote on the Preferences>Printers panel?

Honestly, more than one Cura developer seems to agree that this is an issue and it's not going to go away on it's own. Similar concerns are mentioned in comments attached to this commit back in 2018: https://github.com/Ultimaker/Cura/commit/290adbd906dc468d032e22b8d7af4853d040c11d

While that approach would at least increase the chances of people recognizing this issue (even if only when first setting up their printer), another suggestion might be a better short term fix:

What about making the USB Printing plugin be opt-in (disabled by default)? That paired with a note on the Preferences>Printers panel instructing users to enable the plugin would be more friendly than the current default behavior.

These are just ideas. I understand they aren't PRs and they aren't complete solutions. If either idea helps alleviate this issue for users (or reduces time spent on closing duplicate issues) then I think it's worth sharing.

For good faith, I'll try my hand at creating a PR for the first of these suggestions.

[JamesHagerman]

Something like this?

diff --git a/resources/qml/Preferences/MachinesPage.qml b/resources/qml/Preferences/MachinesPage.qml
index 5341af65d..543486773 100644
--- a/resources/qml/Preferences/MachinesPage.qml
+++ b/resources/qml/Preferences/MachinesPage.qml
@@ -113,6 +113,15 @@ UM.ManagementPage
                     }
                 }
             }
+
+            Text {
+                textFormat: Text.RichText
+                text: "<i>Note: The USB Printing plugin can cause unexpected serial port behavior in third-party software such as Arduino IDE and PlatformIO. The USB Printer plugin can be disabled in the Cura Marketplace as a workaround. (GitHub Issue <a href=\"https://github.com/Ultimaker/Cura/issues/5207#issuecomment-570139859\">#5207</a>)</i>"
+                width: parent.width
+                wrapMode: Text.Wrap
+                topPadding: UM.Theme.getSize("default_margin").height
+                onLinkActivated: Qt.openUrlExternally(link)
+            }
         }

         UM.Dialog

It ends up looking like this:

I'll open a PR if there's any chance of it being accepted.

EDIT: I'm no copywriter. It should clearly be USB Printing...

[jrmoserbaltimore]

Note that being unable to change the printer connection can cause problems with prints if the printer loses connection. This has happened during a print; the only way to connect back up is to close Cura and open it back up again (at which point it instantly works).