Cura: [2.1 Beta] Cura not printing to usb

[tenten8401]

Cura 2.1 doesn't seem to recognize my Printrbot Simple.
Drivers are installed properly and Cura 15.04 recognizes it.

[thopiekar]

As you said, you already installed the needed drivers for your printer, I can only guess you are using Windows(?). Which version do you use?

[tenten8401]

Windows 10 x64

[Ghostkeeper]

If it's not registering the connection to the Printrbot Simple, the relevant code in Cura is here: https://github.com/Ultimaker/Cura/blob/master/plugins/USBPrinting/USBPrinterOutputDeviceManager.py#L223

This code was copied from here: https://github.com/daid/Cura/blob/SteamEngine/Cura/util/machineCom.py#L31

The only real difference is that the serial_port_auto setting is removed. The only thing I can see going wrong otherwise is that Cura 15.04 is still open and holding the COM port busy (or another instance of 2.1 for that matter).

[tenten8401]

Didnt have 15.04 installed when doing the testing, but i didnt reboot my computer when i tried it. Will try it later after this 24h print finishes

[nallath]

I ported / wrote most of that code, but as you might imagine, it was never tested on a printerbot. For the 2.2 there has been some refactoring, so you could try it again once we release that for beta.

[awhiemstra]

In addition, there is a known issue on Windows 10. Microsoft decided that they wanted to include an arduino driver. However, this driver does not actually work but does conflict with the driver we supply. There is an article about it on our support website, but I cannot currently recall the link for it. You might want to verify that you are not running into that.

[fieldOfView]

I think @awhiemstra is referencing this document:
https://ultimaker.com/en/resources/18627-change-arduino-drivers
Not sure if it is helpful, since 15.04 does recognize the printer

[tenten8401]

After this print finishes, I will test with official arduino drivers and the windows 10 drivers, rebooting after each try. I will get back to you guys on whether it works or not. (Print's half way done!)

[tenten8401]

After rebooting my computer, Cura still isn't recognizing the printer.

[nallath]

Could you give us the logs? It should say a bit more there.

[tenten8401]

All I can find are engine loss, where would I find the actual logs

[nallath]

https://github.com/Ultimaker/Cura#logging-issues

[tenten8401]

Will re-format my post later today.

[tenten8401]

Here are the logs...
http://hastebin.com/juqefucita.tex

[fieldOfView]

Looking at the logs, Cura tries and fails to communicate with a printer on the COM3 port. Do you know if your printer is on COM3, or on another port? Do you have any other serial devices connected to your computer?

[tenten8401]

My printer is on COM3

[thopiekar]

@fieldOfView I guess there is something wrong before the code tries to test the different baudrates.

2016-05-09 19:55:37,625 - INFO - Could not establish connection on COM3: 'Timeout'. Device is not arduino based.

For some reason this message worries me the most.

[fieldOfView]

That's what I meant with "tries and fails to communicate with a printer on the COM3 port" ;-)

If COM3 is indeed your printer we have to find out why it is not responding to Cura.

[tenten8401]

I have also tried removing "3D Builder" and disabling 3DPrintService with no luck.

[tenten8401]

Currently the windows 10 Printrbot driver is installed, however I couldn't quite find what I should use as an alternative.

[thopiekar]

@fieldOfView Ah, ok. Isn't there a tool like lsof on Windows?

[thopiekar]

Ahh! That looks useful.

http://www.doublecloud.org/2014/05/which-process-holds-my-file-tools-on-linux-and-windows/

[fieldOfView]

I don't think the serial port is in use by another process; it seems to be not responding (timeout) instead of saying it is busy.

Pinging @nallath, hoping he can help.

[nallath]

The "not arduino based" error is spooned up when the ispBase can't connect to it. To be honest, I just copied that code from daid, as he warned me of the clusterfuck that is called USB printing.

The lines below it:
2016-05-07 09:18:02,152 - DEBUG - Attempting to connect to printer with serial COM3 on baud rate 115200
2016-05-07 09:18:02,152 - DEBUG - Attempting to connect to printer with serial COM3 on baud rate 250000
2016-05-07 09:18:02,153 - DEBUG - Attempting to connect to printer with serial COM3 on baud rate 230400
2016-05-07 09:18:02,153 - DEBUG - Attempting to connect to printer with serial COM3 on baud rate 57600
2016-05-07 09:18:02,153 - DEBUG - Attempting to connect to printer with serial COM3 on baud rate 38400
2016-05-07 09:18:02,154 - DEBUG - Attempting to connect to printer with serial COM3 on baud rate 19200
2016-05-07 09:18:02,154 - DEBUG - Attempting to connect to printer with serial COM3 on baud rate 9600
2016-05-07 09:18:02,154 - ERROR - Baud rate detection for COM3 failed

Indicate that it correctly tried all baud rates, but the printer never gave a correct answer. Cura tries to call send a get-temp command. If it gets a number of correct responses it simply assumes that the current baud is correct (how else would we get a right answer...)

In this case, we never seem to get the right answer. Note that some kind of connection was established (if it can't open the com port, we would expect to see that in the log as well)

[tenten8401]

So basically, It's just the way Cura detects the printers and nothing I did wrong?

[thopiekar]

I think so. It would be interesting to me how Cura acts in your case if you
are using Linux for example. Just to be 100%ly sure it us not printer
related, but related to Windows specific code.

Additionally you can take a serial console, called thermite or
something that sounds similar. I used that application years before to talk
with other serial devices. It was very handy.

There you can send the GCode (only the command to ask for the temperature
here) manually and see what your printer answers. It will be useful to
understand what's going wrong here.

[tenten8401]

Okay.

[thopiekar]

Just in case you are interested to provide extra information to find a
solution here 😉

[tenten8401]

Downloaded something called Termite (not thermite) and got the following output from it:

M105
ok T:25.9 /0.0 B:27.0 /0.0 T0:25.9 /0.0 T1:41.2 /0.0 T2:50.6 /0.0 @:0 B@:0

[thopiekar]

As reference: This is what my bq Hephestos2 returns:

M105

ok T:23.0 /0.0 B:0.0 /0.0 T0:23.0 /0.0 @:0 B@:0

😉

[tenten8401]

Probably why Cura isn't recognizing it at all.

[thopiekar]

Seems so. We'll see tomorrow what the Ultimaker people will say about that. I'm sure we made a good job so far providing this info 😉

Good night ✌

[Ghostkeeper]

Thanks for your dedicated feedback!
The difference is just that it reports temperatures for two additional nozzles, but it should be robust against that. Basically, the code just checks for the string T: in the response: https://github.com/Ultimaker/Cura/blob/2.1/plugins/USBPrinting/PrinterConnection.py#L299

[tenten8401]

That's odd, because my response does contain T:

[daid]

Looks like some delay/timeout is missing somewhere, the old code would try each baudrate for at least 5 seconds. As you need to wait for bootloaders/startup time of the firmware. The log clearly shows that that is not happening.

@nallath did you test this code on Windows? Linux has far better serial port behavior then Windows. Meaning that if it works on Linux, it might fail on Windows.

[nallath]

Uh. Didn't test it on windows, but there have been others that used it with an UM on windows if i recall correctly.

It could be that it's the combination of windows + printerbot firmware.

[tenten8401]

This is still an issue on 2.1.2. Would love this fixed if possible.

[nallath]

The USB printing has been tested on multiple platforms now and it works for Ultimaker machines.

I don't have acces to a printerbot (and Ultimaker definately won't buy me one ;)), so I can't fix / test this.

[tenten8401]

I can do whatever you need done, collect serial output, whatever you need. Do you have skype or something? I would LOVE to get this fixed as the old Cura just looks like garbage compared to the new one.

Or, You could use something like FlexiHub to access mine (just found out about it, very cool)

[thopiekar]

I'm sure that using socat (http://linux.die.net/man/1/socat) would be enough 😉
Looks simple and easy to use (at least when Linux is installed already), but never used it before.

[nallath]

Are you able to run cura from source? In that case it's pretty easy for me to make a version for you that has a ton extra logging.

[tenten8401]

I can do that.

On Thu, Jun 30, 2016, 3:29 AM Jaime van Kessel [email protected]
wrote:

Are you able to run cura from source? In that case it's pretty easy for me
to make a version for you that has a ton extra logging.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/736#issuecomment-229581359, or mute
the thread
https://github.com/notifications/unsubscribe/AF42h61c4PGOeJhRLWtlbZEFB67qO445ks5qQ3BWgaJpZM4IZbvy
.

[nallath]

Could you send me a message at j.vankessel at ultimaker dot com?

I don't have time this week to help you with this, but i might be able to find some next week.

[tenten8401]

@nallath think you could help me out with this? Haven't been on in a while. :P

[thopiekar]

@tenten8401, Email sent to @nallath ?

[nallath]

I've added more debug code to the USB auto detection stuff. Should be in tomorrows build.

[fieldOfView]

(note that @nallath is talking about a build of Cura 2.2 that is not publicly available)

[tenten8401]

Update: I may have found a potential problem! I attached to my serial port using CuteCom (Linux serial monitor), and sent M105. First output was "Active Extruder: 0". Send M105 again and got a valid temperature reading. Could this be why it's erroring out? Here's a video of the issue, I'm not sure why this is happening at all.

https://youtu.be/Rf0CzaIP3kA

Edit: Now that I look closer at the video, it seems to be printing that out as soon as the serial monitor connects, which is baffling.

[fieldOfView]

If the firmware consistently answers "Active Extruder: 0" to the first M105 after a reset, that would indeed be a problem. Let's have a go at this theory.

In the folder to which Cura got installed, there should be a subfolder named plugins.
Open the file cura/plugins/USBPrinting/USBPrinterOutputDevice.py
On or around line 337 it should read as follows:

                if b"T:" in line:

Change that to:

                Logger.log("d", "Response: %s" % line)
                if b"T:" in line or "Active Extruder" in line:

The first line is optional, but may help with debugging. Make sure the two lines have the same indentation, and uses spaces, not tabs. Keep a backup of the original just in case.

[tenten8401]

Complete noob question here, but where would one find the Cura files when installing from the AUR? Full disk search is taking forever and I'm absolutely clueless. https://aur.archlinux.org/packages/cura/

[fieldOfView]

I have no experience with Arch myself, so I am not sure. Candidates would be something like /opt/cura, /usr/bin/cura, /usr/local/bin/cura. But those are just guesses.

[tenten8401]

Can't find it in /opt, /usr/bin/cura is a script, and /usr/local/bin/cura doesn't exist. I'll wait for the full disk search and get back to ya.

[fieldOfView]

does the script have anything useful in it? cat /usr/bin/cura

[tenten8401]

Not really. http://hastebin.com/ixejigigam.py

[fieldOfView]

I can keep guessing some more, but I think it is better if I wait until someone who knows linux chimes in. @thopiekar ?

[thopiekar]

By default Cura goes to /usr/lib/python/dist-packages/cura.
Optionally it is possible that it goes to a directory with the python
version, which was being used during build, eg.
/usr/share/python3.5/dist-packages/cura.

Mit freundlichen Grüßen/With kind regards

• Thomas Karl Pietrowski

[tenten8401]

Found it. /usr/lib/cura/plugins/USBPrinting/PrinterConnection.py .... I believe I'm using 2.1.2... which... aparently isn't right on your github releases page, as the AUR pulls it from 2.1.3.tar.gz

[thopiekar]

@fieldOfView also keep in mind that we are talking about Cura 2.1 here.
See on the AUR page that it is being used.

My upgrade to 2.3 is being held because of a strange bug during code import from GitHub (sadly).

[thopiekar]

Oops, yes, that's where the plugins go to 😅

[tenten8401]

For whatever peculiar reason, when adding that line to PrinterConnection.py, it magicially detects the printer and allows for printing to usb...

2016-09-10 12:42:06,739 - DEBUG - Response: b'echo:Unknown command: "~"\n'
2016-09-10 12:42:06,740 - DEBUG - Response: b'ok\n'
2016-09-10 12:42:06,742 - DEBUG - Response: b'ok T:28.6 /0.0 B:0.0 /0.0 T0:28.6 /0.0 @:0 B@:0\n'
2016-09-10 12:42:06,745 - DEBUG - Response: b'ok T:28.6 /0.0 B:0.0 /0.0 T0:28.6 /0.0 @:0 B@:0\n'
2016-09-10 12:42:06,747 - DEBUG - Response: b'ok T:28.6 /0.0 B:0.0 /0.0 T0:28.6 /0.0 @:0 B@:0\n'
2016-09-10 12:42:06,749 - INFO - Printer connection listen thread started for /dev/ttyACM0
2016-09-10 12:42:06,750 - INFO - Established printer connection on port /dev/ttyACM0

[tenten8401]

I take that back, restarted Cura and it just didn't work again.
http://hastebin.com/coxehuvaji.vhdl

[tenten8401]

Just magicially worked again... http://hastebin.com/unumabilom.py

[thopiekar]

All the USB printing code needs a great bundle of cleanups and improvements. In my point of view it could work more threaded. Also having something like a headless core would be great, which could run on simple boards, like RPi.
Of course there is OctoPrint, but I don't like that it focuses on virtualenv installation and depends on creepy dependencies ( at least I had problems getting them running on my NAS - had to downgrade and upgrade some of them).

[fieldOfView]

If it works sometimes, but not always, it could be that it is timing related.
Around line 324 where it says

            time.sleep(1.5) # Ensure that we are not talking to the bootloader. 1.5 seconds seems to be the magic number

Change that to

            time.sleep(2) # Ensure that we are not talking to the bootloader. 1.5 seconds seems to be the magic number

[fieldOfView]

@thopiekar I don't see how that helps here.
Thanks for chiming in with the install location.

[tenten8401]

2 seems to be working. Let me try a few different things to confirm that it does make it more reliable.

[fieldOfView]

Ok, if 2 is working, remove the Logger.log() line that you put there before.

[tenten8401]

Removed the logger line, seems to be working properly. Doing a test print now...

[tenten8401]

Actually, for some reason, restarted Cura and it just... doesn't work again.

Edit: Seems to be somewhat random at this point. Let me try a few things.

[thopiekar]

@fieldOfView: Well, doesn't help here, but wanted to mention what I think about the USBprinting plugin in general at the moment. I know off-topic of course..

[tenten8401]

Okay, so this is odd. The first 2 times I open it after unplugging the printer and plugging it back in, it's not recognized. The 3rd time and up it is.

[tenten8401]

It's making a mess everywhere but that's to be expected on default settings. It does resemble what I'm trying to print however.

[fieldOfView]

You could try a longer delay than 2 second (which means Cura tries to communicate longer before giving up)

[tenten8401]

I'll try a few durations. I'll get back to you on what works and what doesn't. Right now I'm doing a calibration print.

[tenten8401]

Can we get a max retries option? The time.sleep(x) doesn't seem to be doing anything at all.

[Ghostkeeper]

Sleeps and retries are like cheap razor blades. They cut it for a while, but before long they'll do more harm than good.

I'd rather have us find the cause of this behaviour before we introduce a setting like that.

[fieldOfView]

Note that we currently use a sleep to wait for the bootloader on the controller to do its thing (and stop waiting for us to upload firmware). It could very well have been the case that some printers take longer to be ready to accept commands than others.

[boelle]

since my thread is a dublicate and i dont know much about fault finding etc what would the guru's suggest i test first?

M105
SENDING:M105

T:25.47 /0 B:25.12 /0 B@:0 @:0

printer is running repetier firmware

[boelle]

@tenten8401 added a line to PrinterConnection.py, but i'm blind and cant see what he added where in that file

[boelle]

it was the log options

would they be needed to hunt down why it will not connect?

Running on windows 8.1 64 bit and cura 2.3

[Ghostkeeper]

If the printer sends something else back than just a number for the temperature, such as "Active Extruder", then that might be a valid sign too that there is a printer behind that COM port, and we can try to send g-code to that port. The logging is a way to communicate to developer what the printer answers.

[boelle]

look a few post up,,, that is what i get when i send a M105

[boelle]

otherwise i just get ok and a number back every 2-3 sec

[boelle]

ie

ok 199810
ok 199810
ok 199810
ok 199810
M105
SENDING:M105
ok 199810
T:26.05 /0 B:25.70 /0 B@:0 @:0
ok 199810
ok 199810
ok 199810
ok 199810

[fieldOfView]

It does not help knowing what you get in this case, it helps knowing what Cura gets. That's what the logging is for.

As a general hint on using github: at the moment 8 people get an email about every post you make. Please don't post a single sentence at a time.

[boelle]

so my task is to add

Logger.log("d", "Response: %s" % line)

to

USBPrinterOutputDevice.py

??

and then post the log once i found that one

LOG(cura.log) http://pastebin.com/Jwb4CWYE
LOG(stderr.log) http://pastebin.com/CN6FE7mB
LOG(stdout.log) http://pastebin.com/ctbPzrPi

same again with the line added

LOG(cura.log) http://pastebin.com/gxP7txsj
LOG(stderr.log) http://pastebin.com/gxP7txsj
LOG(stdout.log) http://pastebin.com/jTqDLwGS

I know the printer is at COM3 at 115200, at least that is the manual settings in 15.04.6

[fieldOfView]

Did you add it to the specific place in that file where I instructed? Before the line if b"T:" in line:
In the cura.log you posted I don't see the output I would expect.

[boelle]

C:Program FilesCura 2.3pluginsUSBPrintingUSBPrinterOutputDevice.py

http://pastebin.com/7xTfDfBZ

and upps i did it after :-D

which one of the logs are the important one?

            Logger.log("d", "Response: %s" % line)  
            if b"T:" in line:

                Logger.log("d", "Correct response for auto-baudrate detection received.")

correct?

[fieldOfView]

Yeah, please put it before the line, not after. Make sure the indentation is correct.

stderr.log contains only the output of the last time you ran Cura, whereas cura.log has all your sessions concatenated. If you post stderr.log, please make sure you close Cura first (else the file will likely be empty)

[boelle]

USBPrinterOutputDevice.py http://pastebin.com/bnnGpZB5

Log: http://pastebin.com/s7cDYHF9

[boelle]

Let me know if i can help with further testing

Have the whole day and not much to do

[fieldOfView]

I have not much time, and a lot to do :-)
Here's a version of USBPrinterOutputDevice.py that has some more debug output:
http://pastebin.com/x0gkuQed

[boelle]

stderr.log: http://pastebin.com/DCMmMK0b

[fieldOfView]

Ok, that's weird. It doesn't even get round to try different baudrates.
Oh, wait a minute! Some Arduino-clones I've worked with connect as a different device when they are in bootloader/programmer mode. In that case the serial port disappears for a little while. Cura seems to detect this and thinks "oh, nevermind, this serial port has gone away. Stop trying to connect to it immediately".

Try replacing your USBPrinterOutputDeviceManager.py with this:
http://pastebin.com/Qa3YnPcp
(You are using the 2.3 or master branch, right?)

[boelle]

2.3 beta as downloaded from the site

as for different ports during programming.... yes mine does that but i have to remove a jumper for it to happen... during normal mode it will stay with COM3... also if i hit reset

testing....

[boelle]

http://pastebin.com/TkBeVYFi

[boelle]

doooh... new filename...

retesting and will add log to this one

http://pastebin.com/bBphkdwX

[fieldOfView]

Are you quite sure you overwrote the USBPrinterOutputDeviceManager.py file with the one from my pastebin? Because I inserted a 10 second pause, and I don't see the expected pause in your log.

[boelle]

double checking

USBPrinterOutputDevice.py should still be the last one you asked me to put in right?

USBPrinterOutputDevice.py: http://pastebin.com/cZXCXLP5
USBPrinterOutputDeviceManager.py: http://pastebin.com/YYvJByL1

log: http://pastebin.com/pGGdD3KN

[fieldOfView]

Yes, USBPrinterOutputDevice.py should be http://pastebin.com/x0gkuQed (which seems to be the one you last pasted)
One more go at USBPrinterOutputDeviceManager.py with more logging. Last one I have time for for now:
http://pastebin.com/RftKsjJm

[boelle]

http://pastebin.com/mUQpB1ZH

[fieldOfView]

Ok, one more USBPrinterOutputDeviceManager.py
http://pastebin.com/kaQpd6z1

[boelle]

http://pastebin.com/RqtdFVFe

[boelle]

did my last log give any clue to whats going on or not going on? :-D

[fieldOfView]

No, none whatsoever. Perhaps I can send over some other attempts tomorrow.

[boelle]

no problemo

i will be arround 10-11 eu time

[boelle]

did you forget me? or are we at the point where we just dont know why it does not find the machine automatic?

but well i just hope manual selection comes back at some point for those strange cases where automatic does not work

[Ghostkeeper]

It's been a bit hectic over here (due to this RC1 tag we're putting everywhere now). We're going to need a bit of time...

[boelle]

no problemo, i thought that there was an explanation somewhere

[saulmayo]

Has any solution been found? In version 2.3.1 still does not work.

[boelle]

nope. no dialog box yet for setting serial port

i have started to print from sd card instead, thou they should still add it

[mayhemer]

Could prolonging the timeout help?

When using Cura 14.0.6 it takes approx 10 seconds before I start seeing the temperatures when connecting Megatronics 3.0 board with Merlin (not sure about the version) via USB.

There is also an option to save the gcode and print from old cura or even repetier, but where are we then?

[Ghostkeeper]

You'd expect that a printer can respond to a temperature request within 5 seconds... As long as it's fully booted. I might even be able to type that response by hand in that time if I were a ghost in the shell, so to speak...

Perhaps we can make the baud rate a machine setting? And the time-out duration too?

[daid]

Nope, some machines take more then 15 seconds before the respond, as they have a long wait time in the bootloader.

Which is why the old Cura increased it's timeouts when you manually selected the serial port.

[ianpaschal]

We won't be working on such old versions of Cura so this is a Won't fix.

[Ghostkeeper]

This is still a problem in Cura 3.2.1. We'd need to gradually increase the time-outs when attempting a connection like 15 did.

[jackha]

Yes we are going to fix this! :-)
CURA-5396

[jackha]

Sooo who can help me with testing? I only have Ultimakers to my disposal.

[tenten8401]

I'd be up to testing with an original Printrbot Simple, although the newest Cura seems to connect just fine over USB. If there's something I can do to help test it I can.

[jackha]

@tenten8401 At least that's good news! If it connected fine in the first try, there should be no difference here. Only in the retries it does different timeouts: https://github.com/Ultimaker/Cura/commit/b2b9de796034a3739760455983d37bf9924c457f

[ianpaschal]

This was fixed a while back, so closing!