2.10.0 bug in user-request-enable

[multigcs]

there is a bug in 2.10.0-pre0.5 🙁
linuxcnc-uspace_2.9.0~pre1+git20230208.f1270d6ed7-1 works

i think user-request-enable is not going back to zero after first connection

Therefore, when the connection is lost, no estop is triggered on my end and I am unable to reconnect to external controller.

[rene-dev]

Can you explain what you mean by connection?

[multigcs]

udp connection to my RIO board,

'user-request-enable = 1' starts the udp connection and 'user-enable-out = 1' hold's the connection,
after that, normaly, 'user-request-enable' go's back to 0 .but now it stays on 1

i think the same problem will be with remora boards

[andypugh]

Are you are referring to the HAL pin iocontrol.0.user-request-enable?

[multigcs]

yes, iocontrol.0.user-request-enable

maybe because this change:

 int Task::emcAuxEstopOff()
 {
-    EMC_AUX_ESTOP_OFF estopOffMsg;
-
-    return forceCommand(&estopOffMsg); //force the EstopOff message
+    /* remove ESTOP */
+    iocontrol_data.user_enable_out = 1; //we're good to enable on ESTOP_OFF
+    /* generate a rising edge to reset optional HAL latch */
+    iocontrol_data.user_request_enable = 1;
+    emcioStatus.aux.estop = 0;
+    return 0;
 }

[rmu75]

udp connection to my RIO board,

'user-request-enable = 1' starts the udp connection and 'user-enable-out = 1' hold's the connection, after that, normaly, 'user-request-enable' go's back to 0 .but now it stays on 1

whatever is going on there, there is no such thing as a "udp connection", the datagram protocol has no state. So it is somewhat murky what is meant by "after first connection" or "hold connection".

[multigcs]

nothing to do with udp directly, my hal-component have a timeout if no packet received for 3ms or so,
then it set iocontrol.0.emc-enable-in to 0, this trigger estop in linuxcnc.

to re-enable my system, normally i need to press the estop button in the gui to set iocontrol.0.user-request-enable back to 1

but now, the iocontrol.0.user-request-enable is always set to 1 and the system trys to enable my system even if I don't want to.

[andypugh]

I don't know what the correct behaviour should be for the pin. It's sourced outside the realtime system so being a pulse might not make sense. It might make sense to stay true while the GUI button is pressed, but that behaviour would have to be in the GUI.

As a workaround in your case you could use the HAL "edge" component to set a pin for a fixed time on the rising edge.
https://linuxcnc.org/docs/devel/html/man/man9/edge.9.html

[multigcs]

If no one knows how the PIN should behave correctly, then you should just keep it as it is.
It always worked before, so why change it now?

[rmu75]

doc says "iocontrol.0.user-request-enable (bit, out) TRUE when the user has requested that E-stop be cleared" -- how does iocontrol know what the user requested?

[rmu75]

The difference seems to be that iocontrol_v2 reset user_enable_request after waiting for emc_io_cycle_time.

[multigcs]

In the new version, iocontrol.0.user-request-enable behaves in the same way as iocontrol.0.user-enable-out in Halshow,
so you can also remove the pin completely if it does not perform any specific task.

[rmu75]

you would have to use the halscope to be sure, halshow can miss short pulses, but quickly grepping the source suggests those 2 are identical in master. @rene-dev ?

[andypugh]

The difference seems to be that iocontrol_v2 reset user_enable_request after waiting for emc_io_cycle_time.

There no-longer is an emc_io_cycle_time. (or an emcio)
5fcc215

The few pins that emcio handled have been moved into Task. Presumably that's where it stopped being a pulse output.