Resume job automatically?

What does the serial console say once you re-close the door?

The config.h options that CONTROL should be flagging are these:



Makes me wonder if it doesn't like the NC door and expects an NO door?

Unless BlackBox implements the pin differently, there may be something to this: [edit: this is the point at which my exhausted brain stopped looking at pictures properly, apparently]



If grbl is expecting high for active and low for feed hold (by the definition of the config option). Depends how the interrupt is set up...

So, if you follow the rabbit hole of the surprisingly effective GitHub search function...

Grbl has a specific door-safety subroutine in system.c:



It's a bitwise comparison of the pin state polling function's returned byte (ie. is one of those Analog In pins pressed?) with the byte address of the door switch pin (A1, feed hold, if you've set it in config.h as above). If both are 1, ie. the button that is currently pressed is also the door safety switch, it returns true to the main program and triggers a realtime feed hold.

So what's the "system_control_get_state()" function actually looking for? That's right above it in system.c:



It just... Reads all the pins. A lot. Interesting point, though; it looks for the definition of a control pin invert mask. Where are the definitions? Back in config.h:



Ah. So... You wanna use an NC switch on your door, you have to... Tell the system you're using an NC switch. Shocking.

Question is, does CONTROL manipulate the INVERT_CONTROL_PIN_MASK? Actually, looks like yes. So.. I'm stumped. That was an illuminating ride, though.

 

Yeah I thought I was onto something and then realized I wasn't.

The options in the flashing image look correct, you see what variables they change in my post, but short of reflashing manually I'm not sure what would be wrong. Seems unlikely that CONTROL is manipulating the wrong bits short of a random typo in the code - "00001000" instead of "00000100" on a mask or something. Everything else looks like it should be right, so hopefully Peter finds something on his dive.

 

Yeah, I thought I had it in my evening exhaustion and clearly 'twas not to be.

I just looked through grbl-flashing.js and I see you precompile your hexes anyway, which makes sense. Nothing obvious wrong that I can see (not being a JS programmer!), anyway, though the separate door and hold switch cases in websocket.js seem weird. I assume it's written that way for a reason though. Will be interesting to see what you come up with!

 

Ah, I see. I don't think I'd ever had cause to read that far down the Interface wiki page, actually. Some interesting stuff in there, I'll have to fully read it sometime.

THAT'S the bit I was looking for, where you actually parse and react to the status reports, but GitHub wasn't showing that instance of "status.machine.inputs", which is mostly what I was searching for (to be fair to it, there are a lot!).

Seems like adding an includes('D') if case directly above it (or just changing the whole thing to a switch as well) would circumvent that. If a machine isn't using a door hold .hex, it'll never send a D. If that's the first possible option, immediately followed by a standard H check, it'll always cause the right type of pause to the main loop. Like, literally just pasting in:

Code:

if (pins.includes('D')) {
        // pause
        pause();
        var output = {
          'command': '[external from hardware]',
          'response': "OpenBuilds CONTROL received a DOOR AJAR notification from Grbl: Check safety door. Operation will resume upon door close."
        }
        io.sockets.emit('data', output);
      } // end if DOOR

...Or something along those lines. Though actually, it looks like it would continue down the list of if-statements and also make H true as well, so maybe adding the Boolean to that one makes sense, since D will always include H, but H won't always include D. I'm guessing there's much less reason to avoid Booleans on an i86 machine than there is on Arduino, where you're more significantly penalized.

So where does the unpause() come in? I see the socket (SocketIO?) listener for resume, but I don't see a socket.emit('resume', true) anywhere else in the repo other than where specifically requested by the user (in keyboards.js and index.html, unsurprisingly).

Which I suppose, thinking about it, would lead to the OP's observed behaviour, right? If there isn't a listener- function, if-statement, whatever- with a flag for "D was true, now D is false because the door was closed on the switch", that either calls resume() directly or socket.emits a resume=true before resetting the "D used to be true" flag (so it's not spamming "resume" every time parseFeedback() runs and DOESN'T receive a 'D'), then the only way to restart the machine is, indeed, to press the button to make it do so.

That seems like more of the issue than the order of the if statements, because all you'd get there is a double "pause" call/broadcast. So the above code should have a bit where you declare var doorFlag = false; or whatever up at the top in the global scope, and then check for it each time you don't receive a 'D':

Code:

if (pins.includes('D') && !doorFlag) {
        // pause
        pause();
        var output = {
          'command': '[external from hardware]',
         'response': "OpenBuilds CONTROL received a DOOR AJAR notification from Grbl: Check safety door. Operation will resume upon door close."
        }
        doorFlag = true;
        io.sockets.emit('data', output);
      } // end if DOOROPEN

if (!pins.includes('D') && doorFlag) {
        // unpause
        unpause();
        var output = {
          'command': '[external from hardware]',
        'response': "OpenBuilds CONTROL received a DOOR CLOSED notification from Grbl: operation will now resume."
        }
        doorFlag = false;
        io.sockets.emit('data', output);
      } // end if DOORCLOSE

...Or something.

 

Just a little more work left to do then.

Yep- UI button and assigned keyboard shortcut:



I'm guessing the only way to allow this to happen is to assign a socket.emit to those events, since they're not directly in the index.js file and therefore can't call unpause() directly? Might explain why it's done that way. I have no idea what I was thinking when I wrote code even 6 months earlier though.

 

Hi,
I'm running 1.0.238 and hoping to have the job resume when the door is closed again. However, it just pauses and does not restart. I need to hit resume on the computer to make it restart. Are others having this problem as well, or is there another setting I need to check? My settings look like Francisco's up above.

Best,
Sanjay

 

Yes, I ran the wizard for the door enabled version.
Thanks,
Sanjay

 

Hi Francisco,
We came up with a similar workaround in a way. We wanted the system to wait for a trigger to make the next movement, so we put in a pause after every movement and a set up a USB button (USBbutton.com) to send a space bar to resume the program.
Best,
Sanjay

 

Was there ever a solution to this? Control won’t resume as it should when the door is closed. I have to physically click play in control to resume.