Cura: USB connection handling proposal

[fieldOfView]

A while back there was some discussion about how Cura handles USB-connected printers.

Current problems:

• Cura does not properly (auto-)detect all printers, and a manual port-selection is missing
• Cura tries connecting to all serial ports on startup, resetting all connected printers (and other Arduino-based peripherals)
• A USB connected printer is "seen" by all printer-instances in Cura as "the" USB-connected printer
• In case of multiple connected printers, there is no way to see which printer is connected to which serial port

Most of these problems would be solved if Cura did not automatically assume that any connected USB serial port could be a 3d printer that any of the printer instances could print to. Instead I think connecting a printer via USB should be a conscious step for the user. When adding a printer Cura should ask the connection details. These connection details are then stored with the printer (stack) configuration.

I have made a fairly rough mockup plugin of what this could look like:
https://github.com/fieldOfView/USBConnectionMockup
Install the plugin and add a new printer (or press the "Connect via USB" button on the Printers preference pane). Note that this mockup is fully non-functional at this point.

This is inspired by how the connection with the UM3 or OctoPrint are handled; I think that in the future we will see more and more printers being available via other means than USB, so USB should be regarded as "just another way of connecting to the printer" instead of being assumed the default and only way.

Some further thoughts:

• Cura would not need to open the serial port until it is needed (eg when starting a print, uploading firmware, switching to the monitor). Once the serial port has been opened, it can remain open, so the print-monitor keeps working.
• Cura could store (a hash of) the response to a M115 gcode command to check if the printer is indeed the same as it was once connected to. If it detects another response it could invalidate the connection info and present the usb connection window again.

[thopiekar]

Using M115 was also my idea in the past. You probably remember that we both researched on how printers answer to this command and the problem was, that all the printers answer to this command differently.
In my point of view Cura shouldn't care much about USB as technicue, but about the serial communication behind it. If I'm not wrong I should have some code lying around (from the days of python2.6 and 2.7) which handles about different serial devices. I began to handle USB and bluetooth devices on Linux and Windows in a common way and started to make it work with Android (using PyJNIus and Android classes). However, in my point of view, if we are starting to create a new plugin from scratch we should think about all the other ways how serial communication can be done (USB, Bluetooth, Wifi [using esp8826 chips], etc.).

[fieldOfView]

I'm not suggesting identifying a printer with M115, I am suggesting checking if a serial device is still the same (or similar enough) printer.

we should think about all the other ways how serial communication can be done (USB, Bluetooth, Wifi [using esp8826 chips], etc.).

Wouldn't all of these expose a serial port to the system? If so, there's not much difference to "USB" printing.

[nickthetait]

I'm just starting my team to implement/overhaul USB printing :wink:

See https://code.alephobjects.com/T594

[Ghostkeeper]

Would it be an idea to add USB printing configuration as a printer "action", rather than limiting this to Custom FDM Printer? That way, the user can also deal with multiple UM2 printers and such without having to create a Custom FDM Printer for that, allowing him to use our normal functionality like quality profiles.

[fieldOfView]

That is the idea of the proposal. The stub plugin I wrote attaches itself as a "when added" action to any printer that has a USB port (supports_usb_connection).

[CX-Piet]

Hi, I can not connect via USB on v2.4 where can I find the plugin?

[fieldOfView]

There is no functional plugin yet, only the non-functional mockup mentioned in this thread.

[CX-Piet]

Oh not good. :-/ Cura is useless without USB for me....
I guess there is no solution for that in a few, because that problem exists such a long time... Am I right??

[nallath]

The point is that we hardly have any printers out in the wild that use USB. So from the perspective of Ultimaker, it makes little to no sense to put a lot of effort into it.

[CX-Piet]

Is that so?
I have read the last hours tons of posts from people who are looking for a problem solution regarding USB support...
Also the new feature of live monitoring makes no sense without USB, right?

[boelle]

I think the usb issue is real. But of course if you only care about ultimakers then it does not make sense

but then why is there a ton of printers beside ultimakers included?

remove the makerbots, they for sure dont work (tested by myself)
remove any printer that runs repetier firmware (my personal printer runs that)

strange enough if i go back to 15.04.6 where i have the option of setting a specific port and speed it works like a charm.

[fieldOfView]

remove the makerbots, they for sure dont work (tested by myself)
remove any printer that runs repetier firmware (my personal printer runs that)

That's a rather overly dramatic (and non-constructive) statement... Even though USB connectivity may not currently be working for these printers, you can still use Cura 2.x to slice and then use another tool to send the sliced result to the printer.

[boelle]

i know... very bad sense of humor (my sense that is)

and yes not very constructive

[fieldOfView]

I have begun implementing the proposal here:
https://github.com/fieldOfView/Cura/tree/feature_usb_connection

Update: https://github.com/Ultimaker/Cura/pull/1688

[boelle]

:-D will there be an exe/installer once its ready for testing?

[fieldOfView]

That is not up to me. I don't have a build system, I just run Cura from source.

[boelle]

At least its one step closer. Fingers crossed that it will get in to cura now that some footwork is done

[Ghostkeeper]

Eventually we hope to be able to publish daily or weekly builds of master. Until then you'd have to wait for the next beta release or use Thopiekar's PPA build for Linux.

[boelle]

i think patience will be my best bet as linux stuff dont run well on windows... it might if you install a ton of extra software and know what you are doing

[nallath]

I ocasionally put nightly versions online. It's something we have to do by hand, but it's not a whole lot of effort.
I'm willing to put a nightly up if this is done.

[boelle]

i was thinking and my logic might be faulty

but could i not take the .py files from the PR and overwrite the ones allready there ?

[fieldOfView]

You would need the .py and the .qml files.

As long as the PR only has functional changes in the files in the plugins folder, that would work. But the PR already has one fix in a .py file outside that directory which gets "compiled" into a .pyc file in the python35.zip file, so that would complicate things. At this point it is a fairly minor fix though.

[boelle]

oh...

then i have to wait a bit for a nightly build as i have no means or skills to compile myself

[jannoke]

How can I stop cura from stealing my usb ports. I don't want cura to touch them. I have multiple printers and it's really annoying that cura keeps stealing them between firmware compilations. I don't even use cura for printing. Why is it acting like malware putting it's hands there not intended. I understand the whole "select the serial port" could be some work , but if this "auto" feature is so hard to NOT implement then at least there could be way to turn off autograb and turn it on when needed.

[fieldOfView]

Go to Preferences -> Plugins and disable USB Printing. Restart Cura.

[jannoke]

Yei. Thanks a million. I just recently figured that there are plugins for cura. Was stupid enough to search for plugin that would disable it , without realizing whole cura is actually consisting of plugins itself and to disable the one responsible the action.

Thanks again.

[madmax2]

Any update on when we can see this feature introduced in cura?
Cura 3.2.1 still does not work when USB printing.

Yes the reason why the old cura 15.06 USB printing worked is because we were able to manually choose the COM port and baudrate.

Octoprint and Simplify3D also can do usb printing because we can to choose the
COM port and baudrate.

I don't understand why since Cura 2.x,
developers decided that removing the ability to choose COM port and baudrate was a good idea.

@fieldOfView
Can you not reuse some of the old code from cura 15.0.6 etc that had the com port and baudrate
selection in the new update for cura 3.x.
This will speed up the implementation.

[fieldOfView]

The majority of Cura development is done by Ultimaker. Ultimaker does not recommend USB printing with their printers. That is why USB printing does not get much attention.

Can you not reuse some of the old code from cura 15.0.6 etc that had the com port and baudrate
selection in the new update for cura 3.x.

if only it were that simple. Between the old Cura (up to 15.04) and the newer versions, the frontend has been entirely rewritten. In the front-end not a single line of code is shared between the two. So it is not simply a question of copying code from one version to the other.

Implementing this has been on my list of things I want to do for a while, but the truth of the matter is that I am a volunteer developer and don't use USB printing myself. So more important things keep popping up for me to fix or implement. To complicate matters, I only have Ultimaker printers, and for those printers the current USB printing works. That makes it that much harder for me to make sure that what I would implement also works for other printers.

I do wholeheartedly recommend using OctoPrint on a dedicated (small) computer such as a raspberry pi to control your printer instead of trying to get USB printing from your main computer to work reliably.

[fieldOfView]

I did once get halfway through implementing the proposal here: https://github.com/Ultimaker/Cura/pull/1688
Since then (networked) printer output has gotten a rewrite, and USB printing also changed quite a bit internally. I have been planning to revisit my earlier work, but can not make promises about when it will work reliably.

[madmax2]

@fieldOfView
Yeah when I said reuse the code, I also mean using the logic and the framework of how they implemented the com port and baud rate.
Regardless of the newer versions or changes, logic shouldn't change too much.

But even if you can't reuse the code, does having the logic structure of USB printing in 15.04 help with you implementing usb printing?

Since you are a volunteer developer, why not focus on USB printing and let the other ultimaker developers and other devs do the fixes and implementation of other stuff..
The reason is because I have only seen 1 developer ie (You) even trying to get a mockup going (which gave me some hope) and got half way through with USB printing implementation.

Please don't abandon this, because as you can see from the many reported issues and commenters
USB printer is a very much wanted features from Non ultimaker printer users.

Yes, I already know about octoprint (who hasn't?) and have it install on my pc.
I don't use octopi, because I like using other slicers like Simplify3D and cura to tests different prints and quality...hence why I connect my printer to the PC via USB.

Octopi is too under powered and cannot handle those other slicers.
I can export the gcode from those other slicers into octopi/octoprint but then it takes more steps
instead of just printing directly via usb from those slicers.

I would like to try out the Cura 2.x to 3.x but due to no usb printing I can't.

Yes, I can sliced the gcode and send it to octoprint etc..
But this is pain, if you like to do many different print profile tests and tweaks.

I prefer if I can do usb printing directly from within Cura 3.x.

While I understand USB printing might not be needed by you, since you don't use it.
I can assure you, if you can get USB printing working in cura 3.x you will make many people very happy.
There would also be more increase in users base of cura 3.x.

Right now we need to resort to cura 15.04 if we want to use Cura, which is sad
cos it is such an outdated software which lacks the more features rich Cura 3.x.

[fieldOfView]

OctoPrint is a print host. You should not do slicing with it (even though it comes with an old, rudimentary curaengine slicer).

Cura is a slicer. You should not use it as a print host (even though other slicers have a printhost built-in, and Cura has a rudimentary print host in it too).

I understand that USB printing in Cura feels like the most important thing in the world to you now, but it is not for me. Instead of USB printing, I implemented things like custom multiextrusion printers (and 90% of Machine Settings), jogging and extruder preheating (for USB connected printers and OctoPrint), selectable themes (and the first dark theme), OctoPrint integration and much, much more.

I can pour many, many hours into USB printing, and still end up with an implementation that does not work for everybody. I simply can not test it with other printers than my own (I have 2 Ultimaker printers). That makes it tedious, and I don't like tedious ;-). I am not saying I will never get round to implementing what I suggested above, it just does not have my priority right now.

[Ghostkeeper]

Our project manager put this off of our planning. We won't get the time to implement this any time soon.

[fieldOfView]

Was it ever on the planning?

[Ghostkeeper]

Yeah I put it there because I think it's important that your print doesn't get ruined as soon as you start Cura :wink:

[joba-1]

Hmm, there is quite some interest in this. Strangely enough I didn't see it before. I wonder what my search terms have been :D
Anyways: I implemented a fix for some of the (all my) problems of Cura serial port autodetection in #4554
Maybe you want to test it? Comments welcome

[madmax2]

@joba-1 I tested the new usb printing on Cura 3.5 and I get an error after it finishes heating up the heat bed

Error:
HALTED Reset or M999.

[joba-1]

Hi @madmax2,

thanks for testing.

I see errors after heating up with 3.5 as well, without my changes.

My changes only prevent communication with selected serial devices. They do not interfere once communication is established, but they are kind of my preparation on looking into your (my main) issue with cura.

[madmax2]

@joba-1 Yeah, I was hoping the usb printing would finally be fixed in cura 3.x..
At least cura managed to connect to the printer now..
and I can move the printer nozzle around the bed etc..

But once I begin the print, it heats up the heat bed and gives that error...

Guess I will have to keep waiting some more for this to be fixed..
At least one major problem has been fixed ie usb not connecting to any printer..
Now we need to resolve this bug of why it is stopping after it heats up the heat bed,

Do you have any clue as to what causes the printer to halt after heating up the heat bed?
Also who was the coder that managed to get the usb connection to finally work with Cura?

[joba-1]

Hi @madmax2,

so you are in a much worse position than me: for me the print worked fine until including cura 3.3, then just paused for no apparent reason at certain times during the print.

The good news for me is: I have now tested the github version (which I guess will be the basis for cura 3.6 at some point in time) plus my fixes regarding serial port filtering in my pull request and printing works again, even temperature updates are not delayed anymore. So, for now no need to fix anything further for me :) Free weekend :D . I hope this helps you too.

My theory about what caused the print to stop is: Cura was sending temperature requests while the printer is not ready to accept new commands or at least answers in a way Cura did not expect. Until the command queue is filled up. Then bad things happened...

Which firmware and version are you using? And which printer? Anycubics Delta Kossel Pulley with Marlin 1.1.9 is what I use now. It may help updating to this, if your printer is supported.

Regarding who did the fixes to USBPrinting plugin: I dont know. I have my printer barely 6 months and was quite happy with the delivered software (old cura) and firmware (old patched marlin) most of the time. I only recently started to get adventurous and updated firmware and slicer software and only since then I follow the development (a bit).

If you really want to know: git blame will help you find out who committed stuff.

[joba-1]

Too bad: I see the pauses and halts again. Seems to be correlated with extruder temperature and print speed: the higher the more errors :(

[BenjaminHamel]

Excuse me? Closed?

This is still an issue. Just put a manual option to select which com port to use.

Have you just given up?

[joba-1]

looks like it.
I use other tools now, mostly printrun/pronterface, and only go back to cura if I want to try out new cura slicer features and then just generate gcode files with it. Pronterface has the nice benefit that it can be X-forwarded easily so I can check print progress while not at home. Also it shows a detailed printer communication log (would be invaluable, if I only had printing problems with it :) )

[madmax2]

yes why close an issue that has not fixed yet?

[thymjan]

Cura seems to block every COM-Port. While printing there is no chance to communicate with an other COM Port. Strange behavior. Even when printing over network without any local printer atached the COM-ports are blocked.

[theOehrly]

I also have this issue with Cura blocking all available COM Ports on Windows, regardless of what sort of device actually is connected (if no other software has already connected to that port). This is rather annoying.
I don't use Cura for printing directly, as my printer is not supported. But I do use it for slicing. I need to take care to always start software in the right order or Cura will prevent conncting to the printer.

Also I sometimes have Cura open in the background because I might need to do another print of the same part with somewhat modified settings. Now when connecting an Arduino for example (or just reconnecting the printer) I need to close Cura, forcing me to setup the print again. (Especially annoying with multi part multi material prints)

Generally I think software should not block anything it doesn't need. There should be a setting to turn this behaviour off.

[Ghostkeeper]

You can turn the behaviour off if you don't use USB printing. You need to go into the Marketplace (bear with me), go to the installed plug-ins, and you'll find a bunch of plug-ins there that are pre-installed with the default distribution of Cura. One of these is USB printing. If you disable that, Cura will no longer send g-code to COM ports to test whether there are printers behind them.

[theOehrly]

Thank you. I didn't find any options in settings and didn't really know about that plugin stuff. That at least solves my issue.
I still think blocking all COM Ports is not the nicest way of doing this though. I guess some people who need USB printing might still run into issues.

[Ghostkeeper]

Indeed. We've had multiple requests and proposals to fix that but it doesn't have a great priority for Ultimaker so we haven't found the time to implement that.