GPX plugin not sending temp updates while heating up

[leofaoro]

--- per Mark to open here in the GPX plugin project

What were you doing?

Sent a gcode file to print. It goes thorugh the GPX plugin though. Happens with any file I submit.

What did you expect to happen?

Upon telling the printer to heat up, expected to have every 5s update of the temperatures.

What happened instead?

It starts heating up the bed, and then no communication from the printer until the bed reaches target temp. Same with when extruder is told to heat up. The print time also stops running.

Branch & Commit or Version of OctoPrint

1.2.9 master

Printer model & used firmware incl. version

Qidi Tech I running Sailfish 7.8

Browser and Version of Browser, Operating System running Browser

Windows 7, Chrome 48.

Link to octoprint.log Link to contents of terminal tab or serial.log Link to GPX log all here: https://www.dropbox.com/s/6ka2u10n3ggkj6n/Desktop.zip?dl=0

Screenshot(s) showing the problem:

https://www.dropbox.com/s/ok8ery6xudig8ec/Capture.JPG?dl=0

I have read the FAQ.

[markwal]

The trouble is the M134 and M133 handling. The printer goes into a wait for temp state and GPX should poll for temperatures via x3g every so often (1 sec) and give OctoPrint M105 style reponses. According to the serial.log though, GPX doesn't do this and instead a 30 second time out occurs.

A workaround while you're waiting for a fix from me is to try M116 in place of M134 and M133 since that will wait for whatever temp is set and since it is what I use, should work. Unless there is something else going on with the x3g protocol with your firmware. I'll test M133 and M134 at some point tomorrow or the next day.

[markwal]

Oh shoot. Just tried M134 and it works on my printer. My guess is that your printer is answering the busy query differently than mine. Could I ask for some more diagnostic info?

1. Turn on verbose GPX logging (Settings->GPX)
2. Disconnect and reconnect the printer
3. Terminal tab type the following (with a cold bed, so a wait will be necessary): M140 S50 S0 M134 T0

That'll ask the printer to heat the bed to 50C and then wait for it. It should give temp updates in the terminal window, but if it hits your issue it'll timeout. If it does repro the timeout, grab another copy of the plugin_GPX.log (now that it is verbose) and paste a link here.

Thanks

[dcnewman]

And, in case you're wondering, we've not made any changes to X3G reporting in 7.8. (Not too sure why leofaoro has a 7.8 build; it's not been pushed out for alpha testing yet. Perhaps he built it himself?) With a bot with a very recent 7.8 build, Octoprint 1.2.9, and GPX Plugin 2.4.1, I launched a build and you can see the temp queries happening regularly and being responded to in this .mov video,

https://www.dropbox.com/s/lyz5vob6yblx8j0/octopi.mov?dl=0

The gcode was pretty typical with M140 and M104 commands to set platform and extruder temps and then a M6 to cause the printer to wait for the target temps to be reached before actually extruding any plastic,

M140 S50 T0
M104 S207 T0
G162 X Y F3000 ; home XY maximum
G161 Z F1200 ; home Z minimum
G92 Z-5 ; set Z to -5
G1 Z0 ; move Z to 0
G161 Z F100 ; home Z slowly
M132 X Y Z A B ; recall home offsets
G1 X-95 Y-95 Z30 F9000 ; move to wait position off table
M6 ; wait for things to heat up

[leofaoro]

Thanks all. I tried to send the M140 command, here's what I got back

Send: M140 S50 S0 M134 T0 2016-03-06 18:37:23,553 - SERIAL - DEBUG - Recv: ok 2016-03-06 18:37:23,577 - SERIAL - DEBUG - Recv: // echo: (line 11) Semantic warning: M134 cannot select non-existant heated build platform T0

Am I selecting the wrong printer? Right now I have Flashforge Creator Pro in Simplify3d, and Replicator 1 (dual extruder) in the GPX plugin

As for the origin of the firmware: it came with the printer I bought a few weeks ago. Am I running pre-release code ?

thanks a lot Leo

[leofaoro]

Tried selecting FlashForge Pro and Replicator 2 with HBP in GPX plugin, same output.

Some more logs here https://www.dropbox.com/s/qnxm75nnhn3p19k/Desktop2.zip?dl=0

[dcnewman]

As for the origin of the firmware: it came with the printer I bought a few weeks ago. Am I running pre-release code ?

Hard to say. There was very briefly a window in which the version number had been bumped to 7.8, a bug was reported and fixed, a build issued for FlashForge-like printers, AND THEN the gates were opened to new code changes. A full field test cycle has not yet been done since those changes started going in.

If your build reports a r1605 or earlier then you should be okay. (Utilities > Version Info). However, if it reports later than r1606 then consider yourself a field tester. If it reports r1234 then it's anyone's guess as that would mean that QiDi built it themselves.

[leofaoro]

Great. Turns out is is r1234. I guess I'll read about how to downgrade :/

[dcnewman]

I'd leave it be for the time being.

[leofaoro]

Definitely not impacting the printing itself. thanks again.

[dcnewman]

Send: M140 S50 S0 M134 T0 2016-03-06 18:37:23,553 - SERIAL - DEBUG - Recv: ok 2016-03-06 18:37:23,577 - SERIAL - DEBUG - Recv: // echo: (line 11) Semantic warning: M134 cannot select non-existant heated build platform T0

That warning, "M134 cannot select non-existant heated build platform T0" is from the GPX plugin and not the printer itself. It suggests that perhaps you were changing GPX plugin settings. Specifically the machine definition. You will get that error when you use "M135 T0" but the machine definition states that Tool 0 lacks a heated build platform.

https://github.com/markwal/GPX/blob/master/src/gpx/gpx.c#L5453

Now, the default Replicator 1 Dual machine definition has the heated build platform defined for both Tool 0 and 1,

https://github.com/markwal/GPX/blob/master/src/shared/std_machines.h#L174-L175

[It's the '1},' near the end of each of those lines.] So, this suggests that you either have changed some of the machine definition and the changes lost declaration of the heated platform, or perhaps you selected "FlashForge Creator Pro" in the list of choices? That's an alias to Replicator 1 Dual. However, there had been a bug in the GPX plugin if I recall correctly whereby that alias wasn't working correctly. But explicitly selecting "Replicator 1 Dual" should work. Gotcha is that you said you did select Replicator 1 Dual in the GPX plugin. So that has me back to wondering if at some point you tweaked any of the machine settings in the GPX plugin. When you do that, it writes the change to a .ini file on the Octoprint server. It then uses them. And if they lack the platform setting, then that would explain what you're seeing.

[markwal]

There could also be a bug in the code that updates the current run state. The Plugin always starts with Replicator 2 because that's what no gpx.ini means to GPX. The gpx module gets loaded when you connect the printer, so if you select the printer and then click "connect" it goes through the same path basically as offline GPX. If you change the printer after that, it tells GPX to reset the state and load the .ini file. I've tested that, but it's possible it is less robust than the other order.

[markwal]

Oh shoot, I just reread my email and it ate some line endings. I'm sorry I messed that up because now I need to ask you for more help. I needed the M140 and the M134 to be on different lines. :-(

1. Click "disconnect" in octoprint to start fresh
2. Settings->GPX: Check verbose gpx logs & set your printer type to "Replicator 1 Dual"
3. With a cool (lower than 50C bed), type these two lines, one at a time with an enter key after each one:

M140 S50 S0
M134 T0

It should time-out this time. And then download and post a link to the plugin_GPX.log. Sorry for the hassle, but I didn't catch the wait state failure because we didn't put the printer in the waiting for temperature state.

[leofaoro]

Hi Mark HAve Replicator 1 Dual selected in GPX, give the 2 commands in sequence, still the same output. Also, I have not changed any of the defaults in GPX or in octoprint general prefs.

Log: https://www.dropbox.com/s/93gkszrgb9f6568/plugin_GPX.log?dl=0

thanks Leo

[markwal]

No. that wasn't the same. The x3g conversation is different. This time it asks the bot to wait to reach temperature. Still looking into it.

[markwal]

Oh shoot. I missed again. :-( That M140 S50 S0 was supposed to be M140 S50 T0. Dang it. That S0 stomped on the S50, so no target got set, so no wait state again.

M140 S50 T0
M134 T0

Once more? Are you still getting the warning about not having a heated platform when you type these? If so, please ssh in and:

cat ~/.octoprint/data/GPX/gpx.ini

If you could copy and paste what you get from that, it could be helpful. Though I've probably messed up the instructions again.

[leofaoro]

Ok. this works as expected. Heats the platform and provides temp updates.

GPX log: https://www.dropbox.com/s/93gkszrgb9f6568/plugin_GPX.log?dl=0

and here's gpx.ini

[printer]
build_progress=1
ditto_printing=0
gcode_flavor=makerbot
machine_type=r1d
recalculate_5d=0

[leofaoro]

Interestingly, now it is returning the temp readings during heating. Not sure why it started to work....

[markwal]

It looks like we lost our repro, so I'm closing this for now.

[leofaoro]

Indeed it seems to be working fine now. Thanks Mark.

[leofaoro]

Hi Mark. Not sure what is happening but this error came back. Now after M134 I get one return of temperatures and everything stops. I can't print anything. Here are the logs again and what I'm trying to print. https://www.dropbox.com/s/635se5516fswon7/Desktop%20%282%29.zip?dl=0

thanks Leo

[leofaoro]

FYI if I use M116 T0 after bed heating up it works but after the extruder command if I use M116 T0 it just skips. So I used M116 without parameters and it behaves just like before...updates stop.

Also: to restart the printing, i need to hit cancel, disconnect, reconnect. Hitting cancel it stops the print, but if I hit Print again it does nothing.

Leo

[leofaoro]

Sorry one more piece of info. If I print from the SD card using M133/M134 it works.

[leofaoro]

Tried again with M116, before it worked (M116 T0) for the bed. And now it didn't. So it is not consistently failing.

[markwal]

I haven't figured it out yet, but one of the strange things in your logs, is we send a set the bed temperature: M140 S110 and that gets sent in x3g and the bot says: ok. And then we turn around and ask, what's the bed target temperature and the bot says "0". Which inside of my code clears the flag that says we're in a "wait" state, so now we stop pestering the bot about temperatures and assume OctoPrint will ask with M105, but we didn't send an "ok" to OctoPrint so it won't do that.

So the first bug here is that when we clear the wait state because the target is 0, we should say "ok" to OctoPrint.

However, that will just mean that we don't stop and wait for the temperature to arrive and that will give the next problem that your build will cancel due to too many timeouts.

I wonder why your firmware answers "my target temperature for the heatbed is 0" when it shouldn't.

[markwal]

Hmmm.... Maybe the set temperature M140 S110 goes into the planning queue and the get current target asks immediately. That would explain the situation. I wonder if your firmware is different in this respect.

[leofaoro]

Thanks Mark. I mentioned before that my firmware seems to be an internal build from Qidi so I can't say for sure. One thing I could do if you'd like is grant you access to my machine via http and/or SSH.

I understand also if you'd prefer to not investigate this further as this may be simply an issue with a custom firmware anyway. In that case, I could try to install the current stable version of sailfish (7.7?)

thanks Leo

[dcnewman]

Hmmm.... Maybe the set temperature M140 S110 goes into the planning queue and the get current target asks immediately. That would explain the situation. I wonder if your firmware is different in this respect.

Well "standard" Sailfish (and MBI firmware) do not make either the set temp or query temp commands wait in a planning queue. They are both done immediately upon receipt.

[markwal]

Yeah. It doesn't execute it in the planner order, but it is still async with the serial conversation, right? https://github.com/jetty840/Sailfish-MightyBoardFirmware/blob/e13545cafc088ba395d1f2c08590f8d9b6b2bac4/firmware/src/MightyBoard/Motherboard/Host.cc#L247

Since the command to set the bed target is 136, it has the high bit set, get's pushed and the host gets an OK. The host sends in the tool query for the temp, and that is answered directly without a command::push return OK in between.

So I'm thinking here, it's just the bot didn't get a slice before the query packet comes in. So to try something I've added a wait for queue empty before a wait for bed temp that I'll test here for a bit.

@leofaoro you can probably work around this by putting some commands in between setting the temperature and waiting for it. In my own start gcode, I set the temps at the beginning and then move the nozzle to the front right before waiting for temperature. That way the target isn't zero by the time I get to the wait.

[markwal]

@leofaoro and if my fix pans out without breaking anything (it's only in the python wrapper, so won't break command line translation), I'll check in a fix and you should be able to get an update that fixes this issue.

And you may not want to update your firmware. Who knows if Qidi put something in there that you need?

[leofaoro]

thanks Mark I will try this tonight and report.

[dcnewman]

Yes, it's possible for the temp query to be answered before the set temp is executed as there is a buffer of X3G commands. X3G queries are not buffered. So, we had a clash of semantics when "planning queue" was written previously. The set temp doesn't waiting in the planning queue. But it can wait in a buffer of X3G commands.

[markwal]

Ah. That makes sense. My conjecture earlier would have been more accurate if I'd said buffered rather than planning queue. It doesn't make it to the planning queue.

[leofaoro]

I just tried it remotely and it worked just fine! Thanks Mark and Dan. Below is the g-code I used to start. It's the default S3D slightly modified.

; \ Replicator 1 dual start.gcode ** M73 P0 ; enable build progress M140 S[bed0_temperature] T0 G162 X Y F3000 ; home XY maximum G161 Z F1200 ; home Z minimum G92 Z-5 ; set Z to -5 G1 Z0 ; move Z to 0 G161 Z F100 ; home Z slowly M132 X Y Z A B ; recall home offsets M135 T0 ; load right extruder offsets G1 X110 Y-50 Z30 F3000 ; move to wait position right hand side of the table G130 X20 Y20 Z20 A20 B20 ; lower stepper Vrefs while heating M126 S[fan_speed_pwm] M134 T0 ; stabilize bed temperature M104 S[extruder0_temperature] T0 G130 X127 Y127 Z40 A127 B127 ; default stepper Vrefs G92 A0 B0 ; zero extruders G1 Z0.4 ; position nozzle M133 T0 ; stabilize right extruder temperature G1 X110 Y-70 E25 F300 ; purge nozzle G1 X120 Y-70 Z0.15 F1200 ; slow wipe G1 X110 Y-70 Z0.5 F1200 ; lift G92 A0 B0 ; zero extruders M73 P1 ;@body (notify GPX body has started) ; \ end of start.gcode **

[markwal]

Should be fixed by ac856d0 as long as I constructed the 2.4.3 release of the OctoPrint-GPX plugin correctly