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.

[foxalabs]

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.

[foxalabs]

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.

[foxalabs]

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 ?

[foxalabs]

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.

[foxalabs]

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.

[foxalabs]

@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).

[KoviRobi]

Starts up Cura Notices weird noise, starts investigating around the computer

To be fair, I'm probably one of a limited few who have a serial console based printer attached to their computers. Nice to know I can at least just set an environment variable.

[Ghostkeeper]

That is without doubt one of the weirdest side effects I've ever seen in any bug report.

[JamesHagerman]

This absolutely made my morning.

Now imagine replacing the printer with a serial based medical device.

Seriously, disabling the plugin by default is the right thing to do.

[kzyapkov]

This is almost as funny as it is absurd. Cura should not be poking at serial ports like that. Do disable the plugin for sure, but Ultimaker should just fix this madness.

[Rummageca]

This still seems active and no Fix in site?

Was working on Arduino projects while sending files to printer via Cura

What I noticed was that Cura seems to send Data out all available COM ports while communicating with the printer, not just the COM port it is attached to. I have tested this being that my computer currently has 9 active com ports for projects.. all active ports are receiving M codes like m105 and some other random data that is collected corrupted. this also blocks my other software from all COM ports while Cura is sending data.

If I run a serial data catcher it seems that Cura Spams the temp call request for the printer and some other data on all Com Ports instead of the active Cura Com..

This seems to be true even if your not using the USB to connect... EX over TCP IP, WIFI.

[fluffysquirrels]

This "behaviour" took me a day to diagnose, because on Linux it looks like random data is being sprayed to all serial ports.

So many questions. Why does Cura continue to write "M105" when it has received no response on a serial port? Why is there no visual indication that it is trying to connect? Why is there no preference to disable or announce this behaviour? Why is there no option to enable/disable USB printing when I add a printer that supports it? Why not just put some text on the Monitor tab indicating which USB ports are being scanned or even that scanning is taking place?

[Ghostkeeper]

Why does Cura continue to write "M105" when it has received no response on a serial port?

It tries several baud rates. After those failed, I wouldn't expect it to try again until the COM ports change. But it has been years since anyone worked on this, so it's hard to know.

Why is there no visual indication that it is trying to connect?

Because nobody built it.

Why is there no preference to disable or announce this behaviour?

Because nobody built it.

Why is there no option to enable/disable USB printing when I add a printer that supports it?

Because nobody built it.

Why not just put some text on the Monitor tab indicating which USB ports are being scanned or even that scanning is taking place?

Because nobody is building it.

[JamesHagerman]

Well, that's not correct, but I forgive you.

I opened #7483 to be the UI half of my suggestion to disable the plugin by default. It was rejected because it wasn't clean enough... In an already messy area of codes that continues to have bug reports opened for it, and for an area that impacts a tiny cross section of Ultimaker customers.

The final comment pointed back to this GitHub Issue saying the correct answer was for someone in the community to do the work. And now it looks like someone is asking the community to do work again.

Which... Honestly feels weird when someone tries to step up and the PR is rejected.

Thus, it appears that the only valid short-term solution here is to disable the USB printing plugin by default.

That would stop this behavior.

So where in the code are the default list of plugins set to Enabled or Disabled?

On Fri, Nov 5, 2021, 6:40 AM Ghostkeeper @.***> wrote:

Why does Cura continue to write "M105" when it has received no response on a serial port?

It tries several baud rates. After those failed, I wouldn't expect it to try again until the COM ports change. But it has been years since anyone worked on this, so it's hard to know.

Why is there no visual indication that it is trying to connect?

Because nobody built it.

Why is there no preference to disable or announce this behaviour?

Because nobody built it.

Why is there no option to enable/disable USB printing when I add a printer that supports it?

Because nobody built it.

Why not just put some text on the Monitor tab indicating which USB ports are being scanned or even that scanning is taking place?

Because nobody is building it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/Cura/issues/5207#issuecomment-961902871, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH5G6BXHBCCQQBJYUG57NTUKPNDZANCNFSM4GRPKF5A .

[Ghostkeeper]

I think the PR you tried to link to is this one: https://github.com/Ultimaker/Cura/pull/7843

We know that Cura's users make over a million prints over USB cable each month. So disabling the USB printing plug-in by default is not a solution to us, not even temporarily. It'd prevent a problem for some people, but break the workflow of millions of others. Yes, they can in theory get it to work again, but they'd have to find it. We're not going to put a notification in everyone's face about something most users are not using (and many people don't read the notification spam either), yet every USB printer user would need to know about it.

So where in the code are the default list of plugins set to Enabled or Disabled?

All plug-ins are by default enabled, as defined by this init:

https://github.com/Ultimaker/Uranium/blob/817ff7ff0e849e791d0a2c6de1b0aaa617b051af/UM/PluginRegistry.py#L68

We are looking for a solution that makes the port scanning optionally a manual action, or as with this ticket: allow the user to select the ports to scan.

[meh2481]

Days worth of mindless debugging why my arduino projects weren't working brought me here. I wish my google results for "pi pico M105" and "arduino M105M105M105" or such would have brought me here, but glad to know there's at least a workaround. Here's to companies doing a better job cleaning technical debt in 2022.

[jeffminton]

I want to piggyback on the comment from @meh2481

I also spent days debugging an issue with my Raspberry Pi pico. I know this software is being delivered free but I really feel that I don't want any software on my computer that will just spam commands to random serial devices when they appear. At least not without being able to easily disable that automatic scanning feature without disabling the USB functionality entirely.

[rosscarlson]

Another who's been bitten by and had this bug cost him SEVERAL hours and multiple failed prints.

So am I right from reading all of this that there is STILL no fix for this? I USE USB printing so I can't just disable an entire feature that I need but I also do a lot of Arduino development on the same machine, which means I can't be printing and working with my Arduino at the same time. Given many of my prints are 6+ hours not being able to use my machine for either printing or Arduino during this time is a complete non-starter.

So I guess I'm forced to find another slicing software as this is absurd, how is there not a simple option in the UI to specify which COM port the printer is using? Such an incredibly simple fix for a problem that has cost likely HUNDREDS of man hours of time.

So?

[JamesHagerman]

From what's been said by Cura devs at Ultimaker, the USB printing plugin is complicated and going back through to refactor it isn't worth their time currently because it works fine with Ultimaker's printers.

Neither is it worth their time to add warnings to the application about this behavior. Nor is it worth their time to add documentation about this behavior.

I'm unsubscribing because, at this point, I've moved on to software that doesn't disrupt the rest of my hardware tools.

[Fen-Star]

EDIT: For new reader, the following statements are incorrect. I misunderstood the cause of the issue.

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.

Wait, ultimakers don't support USB printing? Then why, if you want to sabotage 3rd party printers (which seems to be your reasoning for this bug,) would you even allow it use USB? Most of the maker community uses serial ports for programming microcontrollers. At this point, why not have USB printing disabled by default and allow users to manually enable it? Is enough of your userbase using USB printing that it is worth having the default state of Cura to sabotage every com port on your computer?

Side note: Cura is as much "free software" as Chrome or any one of countless other programs that operates for the monetary benefit of a corporation while getting free work from the FOSS community. There is nothing wrong with that, but if ultimaker thinks developing software required to use its products is some sort of charitable venture they are mistaken.