flipflop

That's very odd, It seems unlikely that linuxCNCs state would affect simple hal connections,
in my experience the HMI and interpreter can pretty much take a hike and the hal stuff still keeps ticking

If you have the dev tools installed, it would be trivial to recompile flipflop with its output pin changed
to an simple output as a test

During the work of the machine in the program was the command "M6", which the machine did not perform - the tool has not changed. The operator noticed this and pressed E-STOP and informed me. I did not turn off the machine and began to investigate the cause. I started the test program of tool change in a cycle - the tool did not change. However, the pin iocontrol.0.tool-change changed its state. Then I found that, despite the correct combination of input signals, flipflop does not change the state at the output. Using "halcmd unlinkp ....." I detached all the flipflop inputs and began to study its behavior by sending signals manually ...
After restarting LinuxCNC, this problem can not be repeated.
Continues these experiments there is no possibility - the machine is in production. I changed the HAL file by completely eliminating this trigger.
It is not possible to reproduce such a situation on the test bench.

That's very odd, not sure how this could happen without either memory corruption
or the thread failing

I installed my BlackBox component on this machine - in case of an accident, it will write status of HAL in the file ...

The Carousel comp did have some conditions in which it could get stuck.
This was fixed during the summer, so ensure that you are using a recent version.

github.com/LinuxCNC/linuxcnc/commit/d09a...88174c46462571a3012f