Delaying motion enable after machine-on

andypugh wrote:

what happens if you link the (not inverted) output to motion.enable?

I suspect it will prevent you turning the machine on, but it is probably worth a try.

I suspect you're correct, if I've recreated this correctly.

I have a stripped-down test config that doesn't rely on hardware and doesn't have anything complicated. The section of interest is as follows:
I've attached the config files if anyone wants to give it a shot on their own - or if you just want a simple bare-bones loadable config to play with.
Part of the message is hidden for the guests. Please log in or register to see it.

Quoting from: linuxcnc.org/docs/html/man/man9/motion.9.html

---

motion.feed−inhibit IN BIT

When this pin is TRUE, machine motion is inhibited (this includes jogs, programmed feeds, and programmed rapids, aka traverse moves).

(snip)

Motion resumes when this pin goes FALSE.

---

There is no mention of preventing motion from homing, but is this perhaps an innocent omission that should be rectified? it seems to me that homing constitutes "motion" and it is reasonable to expect that it would be inhibited by this pin.

This is bittersweet. It means that a solution is available, but to implement it without building myself would mean waiting until this is in a release. It also means that since there's a "fix" it's less likely that anyone will be interested in solving this in a more immediate way. I guess one of these days I'm going to have to take the leap and try building it.

And I still hold that the existing pin should prevent motion, including homing. Homing is motion.

Does that not greatly increase the chance of having other problems though? Bugs that haven't yet been worked out?

I was thinking to include only the changes that I'm interested in to preserve what stability I have.

The "Toggle Machine Power" button still remains something of a mystery to me. I can cause it to be activated but can't prevent it from being deactivated.

I'm close to a solution simulating three external buttons I'd have on the system anyway. Here are my expectations and observationis:

* AXIS starts up and shows e-stop button state relative to external e-stop
--> Works as expected

* Pressing external "Enable" or "Disable" do nothing while e-stop is active
--> Works as expected

* User cannot press "Toggle Machine Power" button
--> Working, but not quite how I'd like. It displays message "can't enable motion, enable input is false". I'd prefer no message or something like "Use button on control panel to enable machine".

* User presses external "Enable" button and there's a delay (signaled by flashing indicator) before enabling motion. During this time no user-initiated motion is allowed.

--> Also seems to be working. Homing buttons and menu options are greyed out, arrow keys do not cause motion, also program run/step/stop controls are all greyed out

* Pressing "Enable" again does nothing when already enabled
--> Works as expected

* Pressing external e-stop disables machine, setting UI buttons to correct state
--> Works, but I'd rather not have the cryptic message "motion stopped by enable input" appear at bottom-right of screen

* UI e-stop should be a slave to external e-stop
--> e-stop cannot be cleared through UI but it can be set. This is acceptable, but custom delayed enable is broken by this action until "Disable" is pressed

* "Toggle Machine Power" should not do anything, being a slave to the custom "Enabled" state
--> Pressing "Toggle Machine Power" results in similar undesirable behaviour to pressing the UI e-stop

See attached config. It should work without custom hardware.

The indicator shown in the pyVCP panel to screen right will flash for 8 seconds after pressing "Enable" then go solid and "Machine Power On" will be triggered. "Disable" turns it off and resets everything for another go.

These would be external hardware buttons in a real machine.