[3.2.1] USB printing improvements

[rflulling]

"No Printer Connected" Bug report.
Similar issues #1434 #3423

CURA 3.2.1 on 64 bit Windows 7 Pro, on i5-650, 8GB DDR3, 3TB SATA2, Radeon 17.12.1 on AMD R7-2XX 2GB DDR5. Controlling a "Power Spec i3 Mini (Wanhao)," over USB2. Setting is "Marlin."
Chipset is ATMEGA2560. Firmware is Marlin 1.1.4. M501.txt, M105.txt, M303.txt

1. "No Printer Connected" after sending an instruction printer doesn't like. Example: at max-Z (100) then press +Z a few more times. USB cable pull to reset serial interface, will resolve.
   cura.log 1A
2. "No Printer Connected" after sending sliced file that causes an unseen error in the software. Can be resolved by restarting software and redoing everything you just did...
   cura.log 2A, cura.log 2B
3. In some cases after a print, when attempting to start the next print, "Unable to start print because printer is not connected," and the "Pause" + "Abort Print" buttons persist, regardless of button pressed, the "No Printer Connected" will pop up. Hardware reset is required when this happens. Sometimes also a USB cable pull to reset serial interface.
   cura.log 3A
4. "No Printer Connected" may also be generated if another software such as Simplify 3D talks to the same port. This to an extent is expected. What CURA lacks is a function to tell tell CURA to Connect now, or Try again. The this can be resolved by restarting the software, removing USB cable and reconnecting or by resetting machine. -No long for this one as the issue is simply that CURA will not retry a port once fully loaded. There needs to be a function that it will retry a port, or a button to manually retry.

Nothing done with the software interface will restore when the "No Printer Connected" happens.
Log posted contains only one of the 4 ways this error is generated. -Will look at adding one log per situation generated. -What seems to be happening are unimplemented traps in the software, it crashes, cannot generate an error, gets stuck, gives up without notice.

As @ChrisTerBeke says on #3423 , this could be a firmware issue, and might well be a part of the issue. I have considered. But there are no updates from Power Spec or Wanhao, though there are reports that other firmware can be used. Edit: 03/08/2018 11:54 CST Just did a quick study on firmware, found that I can do an update, but I would have to learn to config the build, then perform a build. Several options are available that don't make this too hard, but it is nothing I am diving into tonight.

OEM skinned version of CURA has no issue in talking to printer even when newest version says "No Printer Connected," and despite this connectivity CURA 3.2.1 will not restore connection. However the OEM contains perhaps 2% of the tools the current CURA has. OEM can send direct commands but is unable or unwilling to send gCode generated in CURA 3.2.1, no error is generated.

Edit: For sure something in code being sent or generated. Have no idea what. Have to guess a little. If code sent is redundant or in error the connection will drop, this is observable, and CURA will refuse to reconnect. Pulling the USB cable will reset. Sending same code will cause drop. Need a serial terminal or a spooler log to see what is going on.

Note: Would really like a direct code send line. CURA has many great tools. M3D based their interface on CURA, I feel spoiled coming from their tools to this more limited set of tools (regarding the spooler side).
Simply 3D for the record had a great control panel, so does M3D. These why doesn't CURA?
Simplify 3D is able to talk to the printer regardless of what CURA says, it's control panel connects every time, no issues. Never had M3D or Simplify drop, or refuse to reconnect. This is a Vanilla CURA exclusive.

[ChrisTerBeke]

For direct G-code sending I created this PR (#3187) a while ago, but it's still under review and probably needs some updates.

[rflulling]

@ChrisTerBeke I like both the idea of the line as well as perhaps a drop down or some way of managing a few drop downs based on need so that not all commands need be remembered.

However as a matter of good practice I think that all users should be familiar with gcode, not just the cheat of the interface. A great interface can help make great results and help speed up code assembly. But so far not one interface assembles all the tricks and there are so many more out there. Thus any user who even thinks they are good, should be familiar with, the command line. -Especially for testing.

I might also request that you extend your input line. I see it is kept short so as to fit ascetically, and true enough many code lines are short. But some are long.

A proactive log is also good. Not just the one that CURA keeps semi hidden, but also a real time log of the sent and received. Why is it that CURA does not have these things already? Is it perfect and never needed such tools?

In general the Spooler or Control panel side really just feels empty and under developed. I would hope that can be soon cured.

[rflulling]

I am watching after a successful print, and after abort commands. I suspect the issue is that after sending a M104 S0, something is refusing to give up until both the Requested temp of 0C and the actual temp of 27C are the same. Since I have no access to an echo of the serial transaction, I cannot see what is really happening.

Pause works here, after the print but Abort print causes the "No Printer Connected."

What is clear is that CURA seems to think that the print is ongoing.

Was temporarily resolved by restarting Cura. The issue with this is that the model is lost and must be reloaded.

[ChrisTerBeke]

The main reason is that Ultimaker printers don't officially support USB printing, and that USB printing is a flawed way of controlling a 3D printer as you always need you computer attached. There's also many technical issues with serial/USB that could cause a print to go wrong (some are caught in modern G-code protocols, some are not). In that extend, Ultimaker doesn't really work on the monitoring of USB printing, but rather on network printing (UM3, OctoPrint from community), or just export to external drive and print stand-alone.

[rflulling]

Please don't blame serial or USB for poor support from developers. I have seen to many examples of how it can work without issue for weeks on end. The bug I have been seeing is unlike any I have encountered before.

[ChrisTerBeke]

It's fine if other devs want to rely on USB for printing, but we think we shouldn't because it gives more issues than it solves, and it's not a good printing experience. It's not really blaming, but a product decision.

[rflulling]

Never said you should rely on anything. There are many ways to connect to a device. There are also simple ways to denote how a device should be connected to, and provide the interface for those connections. I was surprised to see that CURA did not care how it was expected to connect. I really expected to see this under machine management. But instead found only build parameter settings.

Seriously if it is the stand of Ultimaker, or CURA to ignore or throw out support for USB or serial. Then this needs to be made public, so that people can stop depending on CURA and look to other solutions until USB (only the most common interface) is replaced with something else.

By the way, so far, the crashes, seem to be happening internally, within CURA, silently, without generating any sort of external error. No error, no traps, no flags, nothing a user can use to ID and correct the issue. -Original post updated nightly.

[rflulling]

[WARNING] There are empty layers (or layers with empty extruder plans) in the print! Temperature control and cross layer travel moves might suffer.
2018-03-09 08:53:43,567 - DEBUG -
[(6468)-Thread-20] USBPrinting.USBPrinterOutputDevice._connect [382]: Correct response for auto-baudrate detection received.
2018-03-09 08:53:43,577 - DEBUG -
[(6468)-Thread-20] USBPrinting.USBPrinterOutputDevice._connect [382]: Correct response for auto-baudrate detection received.
2018-03-09 08:53:43,587 - DEBUG -
[(6468)-Thread-20] USBPrinting.USBPrinterOutputDevice._connect [382]: Correct response for auto-baudrate detection received.
2018-03-09 08:53:43,601 - INFO -
[(6988)-Thread-21] USBPrinting.USBPrinterOutputDevice._listen [515]: Printer connection listen thread started for COM10
2018-03-09 08:53:43,601 - INFO -
[(6468)-Thread-20] USBPrinting.USBPrinterOutputDevice._connect [389]: Established printer connection on port COM10
2018-03-09 08:53:44,325 - DEBUG -
[(8756)-MainThread] CuraEngineBackend.CuraEngineBackend._onSlicingFinishedMessage [582]: Slicing took 7.16707181930542 seconds
2018-03-09 08:53:44,325 - DEBUG -
[(8756)-MainThread] CuraEngineBackend.CuraEngineBackend._onSlicingFinishedMessage [591]: See if there is more to slice...
2018-03-09 08:53:44,335 - DEBUG -
[(8756)-MainThread] UM.Backend.Backend._logSocketState [181]: Socket state changed to Closing
2018-03-09 08:53:44,335 - DEBUG -
[(8756)-MainThread] UM.Backend.Backend._onSocketError [203]: Socket debug: Arcus Error (13): Closing socket because other side requested close.
2018-03-09 08:53:44,335 - DEBUG -
[(8756)-MainThread] UM.Backend.Backend._logSocketState [183]: Socket state changed to Closed
2018-03-09 08:53:44,364 - DEBUG -
[(8756)-MainThread] CuraEngineBackend.CuraEngineBackend._onBackendQuit [722]: Backend quit with return code 0. Resetting process and socket.
2018-03-09 08:53:49,900 - DEBUG -
[(8756)-MainThread] UM.Controller.setActiveStage [155]: Setting active stage to MonitorStage
2018-03-09 08:53:49,972 - INFO -
[(5684)-Thread-6] SliceInfoPlugin.SliceInfoJob.run [29]: Sending anonymous slice info to [https://stats.ultimaker.com/api/cura]...
2018-03-09 08:53:49,986 - DEBUG -
[(8756)-MainThread] USBPrinting.USBPrinterOutputDevice.printGCode [181]: Started printing g-code
2018-03-09 08:53:49,997 - WARNING -
[(6988)-Thread-21] USBPrinting.USBPrinterOutputDevice._sendCommand [446]: Serial timeout while writing to serial port, trying again.
2018-03-09 08:53:49,998 - WARNING -
[(8756)-MainThread] USBPrinting.USBPrinterOutputDevice._sendCommand [446]: Serial timeout while writing to serial port, trying again.
2018-03-09 08:53:50,501 - WARNING -
[(8756)-MainThread] USBPrinting.USBPrinterOutputDevice._sendCommand [446]: Serial timeout while writing to serial port, trying again.
2018-03-09 08:53:50,502 - WARNING -
[(6988)-Thread-21] USBPrinting.USBPrinterOutputDevice._sendCommand [446]: Serial timeout while writing to serial port, trying again.
2018-03-09 08:53:50,631 - INFO -
[(5684)-Thread-6] SliceInfoPlugin.SliceInfoJob.run [33]: Sent anonymous slice info.
2018-03-09 08:53:51,003 - WARNING -
[(8756)-MainThread] USBPrinting.USBPrinterOutputDevice._sendCommand [446]: Serial timeout while writing to serial port, trying again.

[rflulling]

funny,

Wanaho specifies Simplify 3D as their slicer of choice, and the i3 Mini is listed on the Simplify website. But in the software it is not listed and the user must customize the i3 set-up. Once up and running the communications are rock solid. Though the interface needs spiffing up. -Cannot generate issues reported here with CURA 3.2.1 in S3D 4.0.

Powerspec, takes the i3 Mini and inverts it. Mostly identical but a mirror image. Then specifies CURA as their slicer, even includes a skinned version of CURA 16.x. But CURA itself has otherideas, seems that USB printers are by choice (?) poorly supported and as such unstable. Ironic considering M3D uses CURA as well and they are also rock solid. Seems only the Vanilla versions lack the code to be stable.

[rflulling]

Irony, after digging through RepRapWiki, I found command to tell the printer to store a log on the SD card. This means that when the serial crashes in CURA, I just might get to see the echo. So in S3D, I instructed the printer to open a new file and start keeping a log. Closed the connection and opened a session in CURA. And of course as if demonstrating for the Cable man, every bug that was happening, refuses to act up. Most annoying, is that surely I could recreate the issue where if I send a command to many times I get the error, right? Well like a Sega channel that never works any other time, it's behaving perfectly while being watched... I am feverishly annoyed, but I swear to capture the whole truth about this issue. The community deserves stable software and I will fight to get it.

Ahh I see now, CURA must know its being tattled on. New bad behavior. Rather than simply dropping the connection, it does nothing. Pretends like all is normal and the print is starting, but in fact it is hung and nothing is happening. From here I can Pause and Abort, and abort does work. Heater does not kick in and the print never starts. This is new, since activating slave side log feature.

Something definitely crashed while I was trying to make it happen for the log. But this is the first time that I could not get any admission of this at all. Restarting the software, resolved the issue. Logging still active. Slave not reset.

[rflulling]

A bug hunter does not rest, until he can break the software over and over, and describe what he was doing, and how to dependably break the software again. -There are bugs here, I have seen and tasted them. The hunt is afoot!

[rflulling]

Added logs for the each of the instances of the issue reported.
Added machine details. From command line.

[Ghostkeeper]

It looks like what happens is that the firmware stops responding after receiving a command it can't execute (such as moving outside of the build volume). Cura then receives a time-out on this command. After the time-out, Cura doesn't try again to connect to that USB port because it thinks that the device is not a 3D printer.

I can think of two solutions to this problem from Cura's side:

1. Improve the intelligence in Cura in trying these USB serial ports. Maybe if we've seen a reaction from that port before but there is now a time-out, we might want to try that port again a few more times to see if it was just temporary.
2. Don't send any commands that the printer cannot execute. Normally Cura shouldn't do that, but with manually jogging the printer this can still happen. However your 2nd reproduce path seems to be a normally sliced print sent via USB cable to the printer and I wouldn't expect that to produce moves outside of the build volume or anything. There might be some inaccuracy in your printer definition, or else we may have a bug in CuraEngine here.

[rflulling]

I have been beating the heck out of this thing on Simplify and no connectivity issues whatsoever. E stop, stop start, jog, manual commands, bad commands, etc. If anything I have found that simplify needs a drop down or switch to allow a user to define the port that a printer is expected to be on, something that Cura seems to do automatically. But with all Cura's just do it in silence stuff there is no way to kick it in the rear when something doesn't add up, or things decide to not work.

Cura does several things I really like and so does Simplify. I wish I could just merge the two. Keeping the stuff that works. Both need stuff above and beyond.

Pulled the file I told the printer to create that was supposed to be a log of things happening on its side. Maybe I misunderstood what that command was. The log was blank. So either I have no idea what that command does, or there was no event on the printer side when Cura said it lost the printer.

For now, I am putting my money, on this is a CURA USB thing. Google says others have reported similar issues.

[Ghostkeeper]

The time-out threshold of Cura is fairly simple right now. Increasing its complexity could improve reliability.

There were some ideas a long time ago to allow users to select a COM port and actively make connections instead of the COM port scanning we do now. This would support more printers and prevent Cura from ruining prints because Marlin restarts when a USB connection is detected.