Marlin command M109 S160 not working correctly  

RE: Marlin command M109 S160 not working correctly

So -- where is CooldownNoWait actually used?  Is it in the marlin_main ?  

RE: Marlin command M109 S160 not working correctly

I think we've pretty well established that the unhelpful suggestion to "just read the source code" was made by somebody who clearly didn't verify that doing so would be worthwhile. If you have to drill down into several functions to debug features that don't work as described in the comments -- the original suggestion mind -- you're debugging. Not much help when you just want to get a feature working as described. 8 bit Marlin is known to be a mess, and Prusa's work has probably compounded that just by nature of the limited resources they have to work in. The point being that the state of the code base is understandable, but a bit of corrected documentation would be a help. "Just read the source" is no more helpful than RTFM when the FM hasn't been kept up to date. But thanks for that.

RE: Marlin command M109 S160 not working correctly

On re-read, my last post came across as pissier than I meant it to. I was just annoyed at having gone down the rabbit hole of reading through the source to see what I'd missed only to realize it doesn't function as described or expected based on the top-level code. I want my half hour back!

RE: Marlin command M109 S160 not working correctly

real answer = Configuration.h has:

// Actual temperature must be close to target for this long before M109 returns success
#define TEMP_RESIDENCY_TIME 3 // (seconds)
#define TEMP_HYSTERESIS 5 // (degC) range of +/- temperatures considered "close" to the target one
#define TEMP_WINDOW 1 // (degC) Window around target to start the residency timer x degC early

and Marlin_Main has :

static void wait_for_heater(long codenum, uint8_t extruder) 
{
#ifdef TEMP_RESIDENCY_TIME
long residencyStart;
residencyStart = -1;
/* continue to loop until we have reached the target temp_and_ until TEMP_RESIDENCY_TIME hasn't passed since we reached it */
while ((!cancel_heatup) && 
      ((residencyStart == -1) ||
       (residencyStart >= 0 && (((unsigned int)(_millis() - residencyStart)) 
       < (TEMP_RESIDENCY_TIME * 1000UL)))))
{
#else
while (target_direction ? (isHeatingHotend(tmp_extruder)) :
                          (isCoolingHotend(tmp_extruder) && (CooldownNoWait == false)))
{
#endif  //TEMP_RESIDENCY_TIME

if ((_millis() - codenum) > 1000UL) 

so CooldownNoWait is overridden by TEMP_RESIDENCY_TIME being defined ( for the extruder)

RE: Marlin command M109 S160 not working correctly

So a simple "blow off the standard" is in play because it was convenient at the time.

RE: Marlin command M109 S160 not working correctly

Posted by: bobstro

On re-read, my last post came across as pissier than I meant it to. I was just annoyed at having gone down the rabbit hole of reading through the source to see what I'd missed only to realize it doesn't function as described or expected based on the top-level code. I want my half hour back!

A rather nicer kind of pissy though, I commend you.  Working without documentation - especially when what we do have is almost useless dated reading material as reference - when we are only trying to help Prusa's customers (and learn) - it almost feels like an insult. 

RE: Marlin command M109 S160 not working correctly

one of the advantage/disadvantages of opensource is that you can always refer to the source as a final authority on how something works

RE: Marlin command M109 S160 not working correctly

Posted by: david.a66

one of the advantage/disadvantages of opensource is that you can always refer to the source as a final authority on how something works

Again - and what Bob was eluding too: that is only reasonable if 1) you are fluent in the language;  2) you have the will and desire to sort through code that is poorly written, unprofessional (not that that is always helpful, either); and itself inconsistent and undocumented.

At least the function name in the second example hints at what is happening ...

#define GET_VAL( val, type ) \
    {                                                   \
        ASSERT( ( pIP + sizeof(type) ) <= pMethodEnd ); \
        val = ( *((type *&)(pIP))++ );                  \
    }

float InvSqrt (float x){
    float xhalf = 0.5f*x;
    int i = *(int*)&x;
    i = 0x5f3759df - (i>>1);
    x = *(float*)&i;
    x = x*(1.5f - xhalf*x*x);
    return x;
}

RE: Marlin command M109 S160 not working correctly

Ah yes, just follow the call to the function that uses many globals (?) and a tenary operation for good measure. Crystal clear. Which expression is associated with the R parameter?

while (target_direction ? (isHeatingHotend(tmp_extruder)) :
                          (isCoolingHotend(tmp_extruder) && (CooldownNoWait == false)))

RE: Marlin command M109 S160 not working correctly

Posted by: david.a66

one of the advantage/disadvantages of opensource is that you can always refer to the source as a final authority on how something works

Good documentation is the basis of good code. No comments is bad. Incorrect comments are worse. RTFM is only a good response when the FM is correct. Same applies with code. 

RE: Marlin command M109 S160 not working correctly

Posted by: bobstro

 

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;

)

so M109 Rxx sets setTargetHotendSafe() temp to xx and CooldownNoWait  to False

and M109 Sxx sets setTargetHotendSafe() temp to xx and CooldownNoWait  to True

RE: Marlin command M109 S160 not working correctly

Posted by: david.a66

and M109 Sxx sets setTargetHotendSafe() temp to xx and CooldownNoWait  to True

Cool. Except for the fact that reality bites and Sxx actually waits for cooldown. Can't test ATM, but I recall Rxx did nothing. Even the Prusa owner's blog describes the actual operation as being different. 

I've done my bit of reading through the code. Now you can play along and insert an M109 S160 in your startup gcode. Preheat the nozzle well above 160C then start the print and behold reality. Does your observation match your expectations based on review of the code?

RE: Marlin command M109 S160 not working correctly

because TEMP_RESIDENCY_TIME is defined to 3 in Configuration.h R and S both just set the hotend temp to xx and the code waits for the temp to settle to xx for a stable 3 seconds +- 1 degree. it might be nice to make that controllable by another Mcode instead of being locked by a configuration option.

RE: Marlin command M109 S160 not working correctly

So are the following assertions true on a Prusa printer running current firmware?

so M109 Rxx sets setTargetHotendSafe() temp to xx and CooldownNoWait  to False

and M109 Sxx sets setTargetHotendSafe() temp to xx and CooldownNoWait  to True

Most of us have figured out what the firmware code should do by perusing the Marlin documentation wiki, without trying to figure out C++ tenary operations. We did, indeed, read the FM as it were. The simple fact that the firmware neither functions per the Marlin spec nor the Prusa source comments is the very issue we've been grousing about. 

RE: Marlin command M109 S160 not working correctly

It seems the ability to read obtuse C++ is being worn as a badge of ego.  I started coding in the early 1970s. I was pretty proficient in those early languages. Fortran, a bit of Lisp and a touch of Smalltalk and I decided writing AI learning routines wasn't my forte (lol - if only I knew then what I know now) ... of course BASIC and LabVIEW (eh) for it's instrumentation control predominance. Some MatLAB, too. 

Pascal and C and several ASMs, some PERL and HTML; was pretty good at getting sed to do what I wanted. Heck, I even wrote some microcode for Intel processors.  But I moved out of engineering into marketing (better hours and lots of paid travel worldwide) about the time C# and C++ became the languages of the day.  

So - the code does not do what it was intended to do by it's original authors.  Prusa reworked it to do something they wanted done, but simple did the Prusa thing and left it up to the user to test, debug, and determine if it is fit for use.

RE: Marlin command M109 S160 not working correctly

Gee, I did seem to hit a nerve with my simple question. Amazing insights provided by all. A sorry story of how some straightforward code is defeated by an obscure subsequent bit of logic, probably written by someone else who didn't give a rat's ass for what he/she broke.

I started coding in the early 1970s.

tim...my first program ran on a Bendix G15 at Carnegie Tech back in 1967. It had vacuum tubes. The program worked as expected. Language was ALGO, predecessor to ALGOL. I've done most of the languages you've enjoyed and suffered with over the years. Remember, FORTRAN got us to the moon. Lots of Visual Basic for Applications inside Excel recently. And then I got interested in Arduino, and was taken back in time to C++ hell. Terrible syntax, arcane structures, readability nightmare, etc. Sorry guys, I'm not a C++ fanboy.

But back to the issue at hand. I was hoping for a way to coax the current temp out of the Prusa for use in G code, but I guess that's not in the cards. As I said above, OctoPrint asks for it and gets it. So, what's next? Do we need a firmware mod to get there? I presume the firmware source is available: Prusa is open source, right? Any C++ afici0nodas  out there willing to take this on for the masses?

RE: Marlin command M109 S160 not working correctly

Posted by: jack

[...] But back to the issue at hand. I was hoping for a way to coax the current temp out of the Prusa for use in G code, but I guess that's not in the cards. As I said above, OctoPrint asks for it and gets it.

Octoprint is able to intersperse gcode queries and interpret responses during print-time in a way that we can't in gcode. If you look through the various Marlin references, there are some printers that seem to be able to do amazing stuff, but I think we're at the upper limit of what can expected with the current hardware capabilities.  

So, what's next? Do we need a firmware mod to get there?

I think some of those capabilities will have to wait for the next generation of consumer-grade 3D printer hardware. It is interesting to look at Klipper and other efforts that off-load the heavy calculations and planning to an external CPU (e.g. Raspberry Pi), leaving the printer itself left to do simple movement and extrusion. This might conceivably allow a printer with a simple 8 bit board to continue to be used and move the smarts to more capable devices capable of being more easily programmed and maintained with fewer hardware restrictions. I personally like this idea as I think it'll allow us to get more use out of fundamentally sound hardware that just isn't very smart. This might also reduce the future cost of 3D printers as they can be kept relatively simple.

I presume the firmware source is available: Prusa is open source, right? Any C++ afici0nodas  out there willing to take this on for the masses?

From what I've read, Prusa is at the point with Marlin that adding any feature requires either optimizing some existing code for smaller size, or dropping other features. The 8 bit controllers are simply maxed out. I can stumble through C++ code, but chaotic code in any language is no fun at all. I gave up on programming when I tried to get into C++ memory management. 

I got into the game a bit later than you guys (early-mid 1980s) back when Ada was supposed to be the language of the future and they were teaching Pascal in school. I stepped out of the programming game and got into networks, which is why this thread touched a nerve. I spent many weeks away from my family dealing with a software rollout that was about to go bad, potentially losing our company a few million in contracts. Systems would simply lock up and the programmers were insisting our guys were screwing up the networks. Spent days validating the networks, only to find nothing out of the ordinary. I put a protocol analyzer on the line and monitored the server comms. Things would run normally for a time, then I'd see the server make a request that generated an error return due to another server being busy, congestion or other simple error. The server would hang. I started to press the hot-shot Apple programmers about their error handling, only to be told that they didn't need any because "TCP is a reliable protocol". I guess they expected the protocol to handle cable breaks. These same clowns shipped systems out with dozens of workstation IPs hard-coded to the same value instead of using DHCP. Of course, a Mac required the poor schmuck setting the system up to boot and wiggle the mouse around to make a change. Many long nights ensued. Worked well enough in the lab! Software weenies that don't bother observing reality's affect on their code really annoy me.

Now that my son is a developer, Thanksgiving dinners can be awkward.

RE: Marlin command M109 S160 not working correctly

A friend once commiserated on being part of a team that was doing simple one-zero I/O between two machines (not standard based). Turns out the teams on both sides of the interface thought the other side was handling flow control so they didn't need to worry about it.

Then the time I was asking for some test code and the guy writing the code (senior member of the team) was sending request for data commands to the device under test as fast and the host could go.  It never occurred to him that might possibly exceed the devices ability to respond or even handle the resulting IRQ loads.  And no - the device wasn't using hardware handshaking because early on the original designer didn't think it was worth the extra software to say "Wait, I'm busy!".  So a simple throughput test was turned into a latency/buffer overrun test.

An M command to grab temps is there - but half the problem is in the slicer - as Bob reminded me earlier, it is unable to handle variables and recode accordingly.  So it will take a new generation of thought to make it happen... or using something like a smarter Octoprint.

RE: Marlin command M109 S160 not working correctly

I know your pain

Now that my son is a developer

My son #1 is a software quality assurance guy for Intel, and son #2 is a combo software/network guy for Boeing Defense Systems. What did I do wrong?

But back to the issue: I have a Pi Zero W sitting inside my printer that has a program that asks the printer for temperatures and gets them. It can also issue real-time G code commands back to the printer. Perhaps the loop can be closed in that Pi Zero with the right software. Beyond my programming capabilities, but I could write a good spec for one.

And yes, 3D printers are still hamstrung by 8 bit electronics. You buy a $1,000 printer and it has an $4 brain. Pretty soon the 8 bit chip set will cost more than a 32 bit set, and perhaps that will motivate them. Having the software guys jump through painful hoops to cram code into 8 bit hardware is costly. Moving to a more modern, capable system might actually reduce total costs of a printer, and yield a better product to boot.

RE: Marlin command M109 S160 not working correctly

...there are only 10 kinds of people in this world--those who know binary and those who don't...

Favorite question of mine is "What is 2+2?"  It's my proof English is a horrible language for communication.