Is there a way to check (via GCODE) if the steppers have become disabled?

[GregValiant 1,240]

I've been working on a couple of applications for 3d printers.  It would be really useful to be able to query the printer to see if the steppers have lost their position.  I can disable them, I can enable them, but I haven't come across anything that just asks the question "Hey, do you know where you 're at?".  Knowing if a "Home All" or "Home XY" is required before running a routine would be a good thing.  I would prefer not to have to call homing moves constantly if they aren't required.

M114 gives the last known position.  What I want to know is if the XYZ are flashing on the LCD.  (That might just be a Creality thing, but I'll take it.)

 

(It just dawned on me that I put this in the Cura page.  Feel free to move it to another area.)

Edited October 18, 2020 by GregValiant

[Longtoke 25]

3 hours ago, GregValiant said:

It would be really useful to be able to query the printer to see if the steppers have lost their position.

 

The problem is, without positional feedback from the steppers themselves, or a system incorporated in the design of the printer to track the stepper movements, there is no way to get that feedback from the firmware and the G-code.  There are some after market modules you can buy that can record and monitor stepper motors, some even have an error correction function included, but as far as I'm aware they don't integrate with you printer on the G-code level you need. 

 

4 hours ago, GregValiant said:

What I want to know is if the XYZ are flashing on the LCD.  (That might just be a Creality thing, but I'll take it.)

 

All Creality do on some of their printers is route the G-code currently being executed to the display, giving the illusion it's displaying the current positional information live accurately. Think of it as a blind man being told to walk ten paces forward and 3 paces left. If you then ask him where he is standing, he would say ten paces forward and three left, without actually  knowing where he is standing. 

 

4 hours ago, GregValiant said:

I would prefer not to have to call homing moves constantly if they aren't required.

 

Without positional feedback from stepper motors, this is what we're stuck with. Once you've powered up and done a home position routine you shouldn't need to home again unless you've lost power. 

[GregValiant 1,240]

What I've done is to set the stepper time out to 4 hours instead of the default 2 minutes when the app is started.  I'm not real happy with that as keeping the steppers energized and holding position does involve wear and tear.  I haven't found (and I'm 95% sure it doesn't exist) a way to query the machine to find out if the steppers are enabled or disabled.  If they are disabled then sending an M114 is useless since as you say - the machine would send back "where it thought it was".  If however the steppers are still enabled, then the M114 returns good information on the print head and extruder locations.  I am most concerned with a user asking for a movement and because the steppers are disabled the print head crashes into the end stops or a print.  It would be much better to query the printer and then IF the steppers are disabled to inform the user that it needs a homing move before making the requested movement.

[Longtoke 25]

9 hours ago, GregValiant said:

If they are disabled then sending an M114 is useless since as you say - the machine would send back "where it thought it was".  If however the steppers are still enabled, then the M114 returns good information on the print head and extruder locations.

 

If the steppers are disabled during operation, ideally they won't change position, so using M114 as you describe should be fine. Either that or the steppers are losing position when disabled which is likely to cause it's own issues, and the need for keeping them active is warranted. While there is some wear and tear attributable to keeping idle motors active, I would think it's very minimal, especially when compared to the potential loss of time and materials on a failed print. 

 

Also ( as far as I'm aware with Creality printers using Marlin firmware ) if the steppers are disabled and the program hits a line of G-code that requires a disabled stepper to activate, it automatically reactivates said steppers and continues printing, effectively remembering it's current positioning anyway, proving the steppers haven't lost position while disabled of course. 

 

Another thing to note, if you do a homing procedure mid way through a print, you will likely have the print head collide with the current print anyway, unless you are doing custom home positioning. 

 

Regardless, if you do figure a way to do what you're trying, let us all know the secret ;D

[GregValiant 1,240]

"...ideally they won't change position..."

I see you're an optimist.  When dealing with users it is better to be a pessimist.  If you design a textbox and it is supposed to contain only numbers and then Fat Finger Freddie hits the R key instead of the 5 key the error has to be trapped or something stupid will happen.  If you catch the keystroke you can inform the user right away.  If you catch the exit from the box it's OK.  If you catch a button click that is going to use the bogus data, you have to slap the user's wrist and send them back to enter correct data.

One of the tools in my software is to try to recover an aborted print by starting from a byte location in the gcode file.  If you know pretty much where the error occurred, and the print isn't a plate of spaghetti, and the table hasn't moved, and the print hasn't shifted on the table, then there is a chance to get it going again.  It works, but I worry about having to home the Z.  There is no way to tell where a print might be on the build plate so I'd like to catch Fat Finger Freddy with his hand poised over the wrong key.  I don't think it's going to happen so I'll have to stick with my workaround of setting the timeout to 4 hours.

[Longtoke 25]

34 minutes ago, GregValiant said:

When dealing with users it is better to be a pessimist.

 

"if you make something idiot proof, they release a better version idiot" 

 

-quote from an old engineer who taught me my trade years ago. My own experiences have proven it to be true countless times...

 

39 minutes ago, GregValiant said:

One of the tools in my software is to try to recover an aborted print by starting from a byte location in the gcode file.

 

Have you explored how Creality have setup their firmware for print resume functionality ? I'd speculate you could modify/extend the coding they used, or at a minimum gain an insight to how they achieved it in the firmware.