Marlin command M109 S160 not working correctly  

RE: Marlin command M109 S160 not working correctly

Posted by: jack

[...]

{if (current nozzle temperature) < 160} M109 R160 {endif}

I'm new at G-code, so I need a specific example to try.

I have some bad news. Despite the name "gcode", the files sent to the printer contain nothing but commands. There is no real-time feedback from the printer to any sort of interpreter to make conditional choices. All of the logic (such as it is) supported in the slicer is used to control what gcode commands the slicer inserts into the print file. As such, it can know about things like nozzle sizes, layer heights and current layer, but it has no way of knowing (or doing anything with) the temperatures at print time.

The printer itself is profoundly dumb when it comes to print-time logic. There are some safety and monitoring functions in the printer firmware that act based on sensors, but none of those are exposed to the gcode we generate, at least not in any sort of documented way.

Unfortunately, Prusa's documentation on their implementation of the Marlin gcode feature set is pretty sparse. I often just plug in commands and observe the results. From what I've been able to determine, you're stuck waiting for the specified nozzle temp with M109, whether the nozzle  is hotter or colder at print time. This is in contrast to M190 which will set the target temp for the heat bed, but proceed if the current temp is higher at print time. I have no idea why it's inconsistent.

RE: Marlin command M109 S160 not working correctly

M109 is intended to set a temp then wait.  M104 is intended to set and continue. An artifact of CNC operations. But M109 is supposed to be directional: M109 R150 is not the same as M109 S150.  These are implementation defects by Prusa.  Probably some dev's idea of simplification.  But done without respect for the standard set down by others - instead making the printer operate on S as if it were R. 

Usage
M109 [B<temp>] [F<flag>] [R<temp>] [S<temp>] [T<index>]


Parameters
[B<temp>] 
With AUTOTEMP, the max auto-temperature.

[F<flag>] 
Autotemp flag. Omit to disable autotemp.

[R<temp>] 
Target temperature (wait for cooling or heating).

[S<temp>] 
Target temperature (wait only when heating). Also AUTOTEMP: The min auto-temperature.

[T<index>] 
Hotend index. If omitted, the currently active hotend will be used.

RE: Marlin command M109 S160 not working correctly

But the firmware does have the ability to respond to variables during printing. The variables are that list of limited PLACEHOLDERS.

Such that during printing, BEFORE LAYER CHANGE gcode can respond to things like

{if [layer_z]=>20.000}M140 S[first_layer_bed_temperature]+10{end if}

But - back to that age old problem with Prusa not documenting what they do ...

RE: Marlin command M109 S160 not working correctly

There is no real-time feedback from the printer to any sort of interpreter to make conditional choices.

bob... Bad news, indeed. I would note that I just installed a Pi Zero W on my printer, and have OctoPrint running on it. Looking at the terminal screen, I see periodic M105 commands being sent to the printer, with the very temperature I want coming back as the first item in a received list. I don't want to get too complicated here, but perhaps OctoPrint can issue the commands I want at the start of a print job.

But - back to that age old problem with Prusa not documenting what they do ...

tim... Agreed it's a senseless thing for Prusa to not be compliant with such a simple feature. That's why I posted here, hoping that someone from Prusa command central would see my comment and reply. All this to get a G-code startup to prevent oozing, which Prusa should have done in the first place. My startup code works well enough for PLA, but I had to make a different version for PETG because the bed takes so long to get to target. Next hill to climb is to have one script that handles both. Would need to know what filament is being used, and there might be a config variable that G-code can use for that. Thanks for the insights, guys...Jack

RE: Marlin command M109 S160 not working correctly

I feel the pain: I want a commend like M860 that waits for the PINDA to be 40c, not 44, or 28, or 41.  It would mostly solve many of my layer one issues.

RE: Marlin command M109 S160 not working correctly

Posted by: Tim

But the firmware does have the ability to respond to variables during printing. The variables are that list of limited PLACEHOLDERS.

I expect to see the slicer inserting gcode with specific values based on those settings. It would be awesome if gcode included some way of handling conditional code, but I've yet to see it in the list of gcode that works on the Prusas. Would love to be wrong on this one.

RE: Marlin command M109 S160 not working correctly

Posted by: bobstro

Posted by: Tim

But the firmware does have the ability to respond to variables during printing. The variables are that list of limited PLACEHOLDERS.

I expect to see the slicer inserting gcode with specific values based on those settings. It would be awesome if gcode included some way of handling conditional code, but I've yet to see it in the list of gcode that works on the Prusas. Would love to be wrong on this one.

 

Yeah - you might be right Bob; that said, somewhere in the back of my mind I was thinking the printer was executing code, and I still have that odd feeling I've seen something like it happening. But it may have been as simple as the printer waiting to meet some conditional like temperature set points before the next planner action.

RE: Marlin command M109 S160 not working correctly

tim i think you can get what you want with M860 by doing

M140 0

M104 0

M860 xx ( cooldown pinda temp) waits till pinda is < setting if bed and extruder set temp set to 0

M104 (print)

M140 (print)

M860 xx ( print pinda temp) waits for pinda > setting if bed or extruder set temp >0

RE: Marlin command M109 S160 not working correctly

I found this description helpful for understanding M860:

[...] Note that both sections use the M860 command. When the printer receives the M860 command, it checks if both heatbed and nozzle heaters are off. If so, it treats the M860 command as an instruction to wait for the PINDA to cool down, and will wait until the PINDA temperature is at or below the specified value. Otherwise, it treats this command as instruction to wait for the PINDA to warm up, and will wait until the PINDA temperature is at or above the specified value.

I did once find a reference indicating M860 Sxx would wait for temps to meet or exceed the specified value, while M860 Rxx would wait for temp to heat or cool to the specified value. I tried this once but don't recall the results. Forgot to keep notes!

RE: Marlin command M109 S160 not working correctly

Posted by: david.a66

M860 xx ( cooldown pinda temp) waits till pinda is < setting if bed and extruder set temp set to 0

Interesting the developers didn't misimplement M860 in the same way they misimplemented M109 and M190. That M860 waits for heating or cooling regardless.  Just one more "Why'd they do that?"

But thanks, David & Bob, knowing how it actually works is helpful.

From the blog: this is exactly what I am experiencing.

Although the initial launch-date firmware included an automatic temperature offset calibration routine, for many users this yielded results worse than the default table.

RE: Marlin command M109 S160 not working correctly

prusa m860 only takes the S argument

RE: Marlin command M109 S160 not working correctly

it's pretty easy to look up how gcode is implemented its all in https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/Marlin_main.cpp  

you can search for the code you want, there is a comment in the code for every gcode

RE: Marlin command M109 S160 not working correctly

Posted by: david.a66

it's pretty easy to look up how gcode is implemented its all in https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/Marlin_main.cpp  

you can search for the code you want, there is a comment in the code for every gcode

Not to be argumentative, but I've found places where Prusa makes changes that are contradictory to the comments and algorithms, and does NOT comment they made changes.

RE: Marlin command M109 S160 not working correctly

true, but you can still see the current code even if the comments are old

RE: Marlin command M109 S160 not working correctly

Posted by: david.a66

true, but you can still see the current code even if the comments are old

Not all of us are expert c++ coders; and it's very easy to make significant changes with very simple and hard to spot deviations in structure.

RE: Marlin command M109 S160 not working correctly

Posted by: david.a66

true, but you can still see the current code even if the comments are old

You can do that, true, but it may have no bearing on the reality of printing. If you read the comments, you'll find this:

//!@n M190 - Sxxx Wait for bed current temp to reach target temp. Waits only when heating
//! Rxxx Wait for bed current temp to reach target temp. Waits when heating and cooling

If you examine the code, you'll find this:

    //! ### M109 - Wait for extruder temperature
    // -------------------------------------------------
    case 109:
    {
[...]
      if (code_seen('S')) {
          setTargetHotendSafe(code_value(), extruder);
              CooldownNoWait = true;
            } else if (code_seen('R')) {
                setTargetHotendSafe(code_value(), extruder);
        CooldownNoWait = false;

Looking at the C++ code, it appears to be functioning exactly as described in the comments. Except that's not how it works in practice. I've got M109 S160 in my startup gcode. The actual real-life printer will wait for either cool-down or warm-up to 160C. Why? I have no idea and I'm not prepared to do a trace through setTargetHotendSafe() or a debugging session. IIRC specifying the R parameter does nothing. (Can't test, on the road this week.)

RE: Marlin command M109 S160 not working correctly

And if we analyze what the code does:

if (code_seen('S')) {    // so we have M109 Sxxx or Rxxx covered
          setTargetHotendSafe(code_value(), extruder);  // then we push the value to setTemp
              CooldownNoWait = true;   // after we set the temp, we then set the no waiting flag
            } else if (code_seen('R')) {
                setTargetHotendSafe(code_value(), extruder);  // then we push the value to setTemp
        CooldownNoWait = false;   // after we set the temp, we then set the no waiting flag

It appears as if some process out there is running and monitoring (controlling) the temperature that is suppose to also monitor the no-waiting flag.  It probably just ignores it without regard to what Marlin says it should do.

There are two defects against this behavior on github ...

RE: Marlin command M109 S160 not working correctly

And, my initial read was thinking setTargetHotendSafe was a function ...

 D:\My Tools\Applications\Prusa 3D Printer\Prusa-Firmware-MK3_3.7.1\Firmware\temperature.h (1 hit)
Line 156: static inline void setTargetHotendSafe(const float &celsius, uint8_t extruder)

And at that point we lose track of it, and it's likely accessed by a pointer to a function referencing an array of indexes to function pointers.

Seriously ... searching for it in the entire firmware bundle:

Search "setTargetHotendSafe" (5 hits in 2 files)
D:\My Tools\Applications\Prusa 3D Printer\Prusa-Firmware-MK3_3.7.1\Firmware\Marlin_main.cpp (4 hits)
Line 5520: setTargetHotendSafe(code_value(), extruder);
Line 5639: setTargetHotendSafe(code_value(), extruder);
Line 5642: setTargetHotendSafe(code_value(), extruder);
Line 9313: setTargetHotendSafe(saved_extruder_temperature, saved_active_extruder);
D:\My Tools\Applications\Prusa 3D Printer\Prusa-Firmware-MK3_3.7.1\Firmware\temperature.h (1 hit)
Line 156: static inline void setTargetHotendSafe(const float &celsius, uint8_t extruder)

Then this:

static inline void setTargetHotendSafe(const float &celsius, uint8_t extruder)
{
if (extruder<EXTRUDERS) {
target_temperature[extruder] = celsius;
resetPID(extruder);
}
}

RE: Marlin command M109 S160 not working correctly

and

target_temperature[extruder]

drives the PID loop in temperature.cpp

and wait_for_heater in marlin_main does the work waiting