Alarm/Door disable M7 (Mist) state

[amoineau]

Describe the bug

It might be an intended behaviour not a bug, but when triggering an alarm or door signal the M7 state is reset.

Expected behavior

I wanted to know if it could be avoided, if we could keep the M7 state during emergency stop or at least get it back to the previous step when resuming? On our machine, M7 is used to pilot a relay that switch between the two tools we have and opening the hood triggers a door signal. So if someone pause mid file to check something and open the machine it then resume with the wrong tool, which ruin the entire file and potentially hours of process.

Thank you in advance for your help.

[svenhb]

If you enable this checkbox, you should see all sent commands: I'm sure there is no M9 to switch off M7 state. Probably it comes from grbl itself?

Perhaps someoe pressed stop and this code will be performed?:

[amoineau]

I was afraid that it came from GRBL itself shutting down the accessories when the Door input is triggered... In which case it will be hard to solve.

I only have M5, no M9, in the "send following gcode...". So I don't think the problem is coming from there :/

Edit: I'll check GRBL's config.h to see if there is an option for that. I have little hope but we never know !

[svenhb]

If you check grbls protocol.c https://github.com/fra589/grbl-Mega-5X/blob/edge/grbl/protocol.c you find: grbl will switch off spindle and cooling - makes sense in connection with cnc

      // Parking manager. Handles de/re-energizing, switch state checks, and parking motions for
      // the safety door and sleep states.
      if (sys.state & (STATE_SAFETY_DOOR | STATE_SLEEP)) {

        // Handles retraction motions and de-energizing.
        if (bit_isfalse(sys.suspend,SUSPEND_RETRACT_COMPLETE)) {

          // Ensure any prior spindle stop override is disabled at start of safety door routine.
          sys.spindle_stop_ovr = SPINDLE_STOP_OVR_DISABLED;

          #ifndef PARKING_ENABLE

            spindle_set_state(SPINDLE_DISABLE,0.0); // De-energize
            coolant_set_state(COOLANT_DISABLE);     // De-energize

[amoineau]

How did you find that x) You are amazing. So if I comment the last line, it shouldn't de-energize the M7 anymore ?

[svenhb]

How did you find that

I was just interested (that GRBL-Plotter is not be the resson for that ;-) and had an idea where and what to look for.

So if I comment the last line, it shouldn't de-energize the M7 anymore ?

I don't know - just try. Perhaps there is some other code which handles the coolant state

[amoineau]

Sure i'll try it, it's just that the machine is now 400 km away from my office, so it's getting harder to test stuff like that ^^'

[amoineau]

I've done some preliminary tests and it seems to solve my problem, i'll try on the actual machine Wednesday. Thank you for your help, I would never have found that line myself !

[amoineau]

Hi ! I tested on the machine and when the door state is triggered the Mist does not reset thanks to the change, but when I press "Resume" the Mist is disabled... I also disabled the coolant disable in the SLEEP case, lower in the file, but it's not a problem of disabling after a while, it's really when sending the resume command.

[svenhb]

it's really when sending the resume command.

Did you also try with other GCode sender? I'm sure it's the same...

Perhaps you should examine what happens after system_set_exec_state_flag(EXEC_CYCLE_START)

ISR(SERIAL_RX)
{
  uint8_t data = UDR0;
  uint8_t next_head;

  // Pick off realtime command characters directly from the serial stream. These characters are
  // not passed into the main buffer, but these set system state flag bits for realtime execution.
  switch (data) {
    case CMD_RESET:         mc_reset(); break;     // Call motion control reset routine (soft reset).
    case CMD_STATUS_REPORT: system_set_exec_state_flag(EXEC_STATUS_REPORT); break; // Set as true
    case CMD_CYCLE_START:   system_set_exec_state_flag(EXEC_CYCLE_START); break; // Set as true
    case CMD_FEED_HOLD:     system_set_exec_state_flag(EXEC_FEED_HOLD); break; // Set as true

in https://github.com/fra589/grbl-Mega-5X/blob/edge/grbl/serial.c

[amoineau]

Oh no, I wasn't suggesting that your software was the problem, I watched the detailed "Real time status report" and it seems it only sends the resume command. I still believe that it might come from how GRBL handles the resume signal but I can't find where is resets the coolant. Ok I'll follow that lead, thank you !

[svenhb]

Also I found here: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Commands#ascii-realtime-command-descriptionsascii%E5%AE%9E%E6%97%B6%E5%91%BD%E4%BB%A4%E8%AF%B4%E6%98%8E

If the parking compile-time option is enabled and the safety door state is ready to resume, Grbl will re-enable the spindle and coolant, move back into position, and then resume.

Did you enbale this compile option?

[amoineau]

No I don't have the parking enabled.

[svenhb]

Perhaps that's the trick?

[amoineau]

Doesn't parking move the head, every time their is a pause ? among other changes of behaviour ?

[svenhb]

No idea. Perhaps you ask here: https://github.com/fra589/grbl-Mega-5X/issues

[amoineau]

Ok thanks for all the help

[svenhb]

I hope you could fix it. Because it's not GRBL-Plotter reason, I close this issue.

[amoineau]

Hello, I didn't find a fix yet, but you are right, this is not your problem, thanks for the help.