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 #4039. Is unfathomable that that ticket was closed without resolution. Just WOW!

USB connection handling proposal #1049
#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.

[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 <#5207 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH5G6BXHBCCQQBJYUG57NTUKPNDZANCNFSM4GRPKF5A> .

[Ghostkeeper]

I think the PR you tried to link to is this one: #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.

[fieldOfView]

@Fen-Star, what do you even think you will get out of a message like this? Do you really think there's anybody that thinks "well, he convinced me, now I'll spend the time to implement it" after reading your message?

if you want to sabotage 3rd party printers (which seems to be your reasoning for this bug,)

Statements like this do not help your cause one bit. If you just want to rant, that is fine with me but then I (you know, one of those FOSS community members) am not going to engage in communication with you. You are biting the hand that feeds you.

why (...) would you even allow it use USB

It may be unthinkable for you, but the current implementation actually works for many people. Removing this functionality would result in an outcry from many.

If the current implementation is in your way, it is easy to disable it and Cura will no longer touch your serial ports (see the "manage" tab (cogwheel) in the Marketplace, and scroll down to USB Printing).

My vote would be to remove the current plugin from Cura and put it in the Marketplace. That way it is still available for people for whom it works. But it is really up to UM to decide if that is worth the number of support calls from people that say Ultimaker has now broken their USB printing workflow.

Side-note: I have personally started trying to create a plugin that totally replaces the USB printing functionality with something that is actually being maintained. The latest attempt uses the core of Printrun/Pronterface, but even that seems to no longer get maintained much. Drama like this really does not motivate me to restart that effort.

[nallath]

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.

Ultimaker doesn't believe that. We do, however, believe that opening up the product for our printers to others is a charitable project. It's a charitable project that we gladly invest in and also one that benefits us to a large extent, but that doesn't change things much.

[Fen-Star]

I think that at this point, USB printing is unlikely to get updated. If ultimakers don't have usb printing functionality anymore then there isn't any reason for ultimaker to work on it. There are an increasing number of alternatives such as octoprint and cloud boxes (or whatever they call them) as well, so the incentives for someone else to work on it is also diminished. From that standpoint, to what I assume* is a vast majority of users, the current implementation is more of a hindrence than a help.(Although, I feel like widows should have some native ability to tell you if a serial port is being used by a program, and that would solve some of the confusion.) If you want to fix the issues, by all means, go for it, I have nothing against that, and that would be the ideal solution. I wasn't actually advocating sabotage, but rather I was using hyperbole and snark to highlight how this really has nothing to do with third party printers. I probably should have been more constructive with my comments. In my defense, after spending a few hours trying to figure out what I did wrong with my chip and then realizing that I had Cura open, I was a bit irritated. *Obviously, I could be wrong, this is obviously something that should be decided based on the usage metrics.

…

On Wed, Jun 8, 2022, 4:19 AM Aldo Hoeben ***@***.***> wrote: @Fen-Star <https://github.com/Fen-Star>, what do you even think you will get out of a message like this? Do you really think there's anybody that thinks "well, he convinced me, now I'll spend the time to implement it" after reading your message? if you want to sabotage 3rd party printers (which seems to be your reasoning for this bug,) Statements like this do not help your cause one bit. If you just want to rant, that is fine with me but then I (you know, one of those FOSS community members) am not going to engage in communication with you. You are biting the hand that feeds you. why (...) would you even allow it use USB It may be unthinkable for you, but the current implementation actually works for many people. Removing this functionality would result in an outcry from many. If the current implementation is in your way, it is easy to disable it and Cura will no longer touch your serial ports (see the "manage" tab (cogwheel) in the Marketplace, and scroll down to USB Printing). My vote would be to remove the current plugin from Cura and put it in the Marketplace. That way it is still available for people for whom it works. But it is really up to UM to decide if that is worth the number of support calls from people that say Ultimaker has now broken their USB printing workflow. Side-note: I have personally started trying to create a plugin that totally replaces the USB printing functionality with something that is actually being maintained. The latest attempt uses the core of Printrun/Pronterface, but even that seems to no longer get maintained much. Drama like this really does not motivate me to restart that effort. — Reply to this email directly, view it on GitHub <#5207 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACD636NEQUXBAVTPH5E6RQTVOBJQ5ANCNFSM4GRPKF5A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Fen-Star]

If this bug was caused by a third party printer, I would agree with you. However, this is an issue with cura itself regardless of what brand printer is used. Framing cura as a "charitable project" in this context doesn't really make sense.

…

On Wed, Jun 8, 2022, 4:58 AM Jaime van Kessel ***@***.***> wrote: 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. Ultimaker doesn't believe that. We do, however, believe that opening up the product for our printers to others is a charitable project. It's a charitable project that we gladly invest in and also one that benefits us to a large extent, but that doesn't change things much. — Reply to this email directly, view it on GitHub <#5207 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACD636IW4PXZPOS6JGG2PR3VOBOEZANCNFSM4GRPKF5A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[nallath]

Well, no, because Ultimaker printers don't even trigger the USB printing to start. A printer can indicate if it supports USB printing at all. If it doesn't, it also doesn't even attempt to start looking for the connection.

[fieldOfView]

A printer can indicate if it supports USB printing at all. If it doesn't, it also doesn't even attempt to start looking for the connection.

AFAIK, that is not true. The USB Printing plugin looks for serial ports and tries to connect to them regardless of what printers are added to Cura.

[nallath]

It is true;

Cura/plugins/USBPrinting/USBPrinterOutputDeviceManager.py

Lines 83 to 86 in d5511a0

	if container_stack.getMetaDataEntry("supports_usb_connection"):
	machine_file_formats = [file_type.strip() for file_type in container_stack.getMetaDataEntry("file_formats").split(";")]
	if "text/x-gcode" in machine_file_formats:
	port_list = self.getSerialPortList(only_list_usb=True)

The getSerialPortList is what ensures that scanning actually happens.

[fieldOfView]

I stand corrected.

[Fen-Star]

Well then, I was completely wrong and you were right. This is a problem caused by a 3rd party. My apologies. I had not realized that playing with the ender printer had changed the cura settings. If I might make a suggestion, because it appears that I am not the only one confused, I would try to explicitly state that the cura USB behavior was caused by the printer profile. I say this not to excuse my stupidity, but rather in the hopes that it might help others. Again, my apologies.

…

On Wed, Jun 8, 2022, 6:45 AM Jaime van Kessel ***@***.***> wrote: Well, no, because Ultimaker printers don't even trigger the USB printing to start. A printer can indicate if it supports USB printing at all. If it doesn't, it also doesn't even attempt to start looking for the connection. — Reply to this email directly, view it on GitHub <#5207 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACD636K35MNQQX5DYN2ZSITVOB2U7ANCNFSM4GRPKF5A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[tikabass]

@Fen-Star I know this has been a while, but Cura interferes with all serial ports, including any other Arduino projects you have connected to your computer, whether they are printers or not.

[omgwtf2]

https://www.youtube.com/watch?v=ITiTqMYC5u0

[bentomo]

Whether or not this issue is caused by a third-party plugin, this is a VERY common issue that NEEDS a resolution. I just hit this as well. I simply use Cura as a slicer and put my gcode on an SD card for my printer. Here, my custom macro pad is hijacked by Cura and spitting out GCODE. My macropad is broken and the only way I knew why my macropad broke is because I recognized the M105 command AND had a display on my macropad.

This can even be a SECURITY VULNERABILITY if third-party plugins can just go and do arbitrary things to a system. And the way security vulnerabilities are found and patched in OSS communities is making noise. So here I'm showing a VERY standard case where I'm just using Cura, with an ender 3 plugin. And I just so happen to have other USB devices on my computer with COM ports (which is not just a "maker" thing mind you) and CURA is not even checking what the device is before hijacking it.

I do realize this is not necessarily Ultimakers fault. But Ultimaker is hosting and enabling the rogue plugin. AND I just so happen to be lucky enough to have something that showed me what the problem was. There are easy solutions to prevent Cura from blindly blasting serial data to COM ports. And NO, the solution can not be "disable the USB plugin" because you first have to hit this issue, figure out what's going on, then find the obtuse solution, and disable it if you are NOT using USB printing.

[mydevpeeps]

Thanks to a request that came my way I have spent some time working on a variation of the bundled USBPrinting plugin. This concept currently only works if you are running multiple versions of cura on the same computer. It would have no effect if you are running the same version multi-instanced. I am working on a Proof-of-concept at the moment and once it works I will find a way to post the code into the marketplace.

Assumptions:

• You are running two different versions of Cura on one system We tested 5.2.1 and 5.3.1.
• You have two USB-connected printers to the same system. We tested a Creality and Longer..
• You always use the same version of cura to connect to the same printer.

The Workaround:

• Disable the bundled USBPrinting plugin.
• There are 5 variations of the bundled USBPrinting plugin. Their short names are USBPrintingDP1 thru USBPrintingDP5. Each one looks for a specific single COM port to be defined using a variation of the bundled variable version. Instead of CURA_DEVICENAMES being a list, DP1 looks for CURA_DEVICENAME_1 as a single entry, DP2 looks for CURA_DEVICENAME_2 and so on.

The Proof of Concept:

• Creality in Cura 5.3.1 on COM5
  • Disable bundled USBPrinting plugin
  • Install USBPrintingDP1 plugin
  • set system variable: CURA_DEVICENAME_1 = COM5
• Longer in Cura 5.2.1 on COM4
  • Disable bundled USBPrinting plugin
  • Install USBPrintingDP2 plugin
  • set system variable: CURA_DEVICENAME_2 = COM4

Once it's all squared away I'll get it published to the marketplace.... stay tuned.

[mydevpeeps]

@fieldOfView please assign this one to me as well. I am actively working on it now.

[ilmagico]

I just got a new AnyCubic printer and hit this problem: my keyboard would stop working (it's programmable and exposes a serial port)!
This is even before a printer was configured, it doesn't even matter if you have a Ultimaker or not. I believe this plug in should be disabled by default, if it cannot be fixed.

That said:

• I saw in the first few comments someone from Ultimaker saying that, since their printers basically don't use USB anymore, that should be up to the other printer makers to fix, if they don't provide their own software. Does AnyCubic contribute to Cura by any chance? They might have an interest in fixing this.
• @mydevpeeps are you still working on this? If not, I can try taking a stab at this if (ever) I have some free time to dedicate.

[ilmagico]

I found this useful snippet of code in Cura/plugins/USBPrinting/USBPrinterOutputDeviceManager.py:

            # 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

So ... it seems there is already a way to tell Cura to only look at certain serial ports, filtering either by device name, type, or VID/PID, which at least (if it works) would prevent it from interfering with unrelated devices. Not quite enough to select a specific serial port for each printer, and definitely not user friendly.

But seriously: if the Ultimaker team doesn't have time to implement this properly, at least disable the USB plugin by default, cause it's seriously broken (and yes, I might still take a stab at this if I have time).

[mydevpeeps]

I just got a new AnyCubic printer and hit this problem: my keyboard would stop working (it's programmable and exposes a serial port)! This is even before a printer was configured, it doesn't even matter if you have a Ultimaker or not. I believe this plug in should be disabled by default, if it cannot be fixed.

That said:

• I saw in the first few comments someone from Ultimaker saying that, since their printers basically don't use USB anymore, that should be up to the other printer makers to fix, if they don't provide their own software. Does AnyCubic contribute to Cura by any chance? They might have an interest in fixing this.
• @mydevpeeps are you still working on this? If not, I can try taking a stab at this if (ever) I have some free time to dedicate.

yes, this has been accepted and it in the marketplace. however it's meant to fix a multiple printer issue. you should use the built in variables if you only have one USB printer.

[github-actions]

Hi 👋,
We are cleaning our list of issues to improve our focus.
This feature request seems to be older than a year, which is at least three major Cura releases ago.
It also received the label Deferred indicating that we did not have time to work on it back then and haven't found time to work on it since.

If this is still something that you think can improve how you and others use Cura, can you please leave a comment?
We will have a fresh set of eyes to look at it.

If it has been resolved or don't need it to be improved anymore, you don't have to do anything, and this issue will be automatically closed in 14 days.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.
If you encounter this issue and still have a need for this, you are welcome to make a fresh new issue with an updated description.