flipflop

Hi!

Who can explain why the I/O type is used for the "out" pin?

component flipflop "D type flip-flop";
pin in bit data_ "data input";
pin in bit clk "clock, rising edge writes data to out";
pin in bit set "when true, force out true";
pin in bit reset "when true, force out false; overrides set";
pin io bit out "output";

That is fairly mysterious but it does seem to work, that is, you can set and clear the output via the output pin

that is:

setp flipflop.0.out true
does set the output true
and
setp flipflop.0.out false
does set the output false

Yesterday I faced a mysterious situation in LinuxCNC v2.7.8:

signame signal was TRUE. I could not change this in any way manipulations with flipflop inputs.
Perhaps the reason is that the carousel component was at that time in incomprehensible state. Unfortunately I can not reproduce this effect yet...
Perhaps this situation arose because of the failure of the carousel component. Or maybe it was the cause of the carousel's failure...

Do you have another output driving signame?
since the flipflop output is a I/O pin, this would be legal if the connected pin was also an
I/O pin ( for example 2 flip flop outputs connected in parallel might stick like this)

carousel.0.enable is an input so should not be able to affect the state of the flipflop output

PCW wrote:

Do you have another output driving signame?

No.

PCW wrote:

since the flipflop output is a I/O pin, this would be legal if the connected pin was also an
I/O pin ( for example 2 flip flop outputs connected in parallel might stick like this)
carousel.0.enable is an input so should not be able to affect the state of the flipflop output

All the connections with this signal I observed in halshow - there were no others.
I believe that this is the fault of the incomprehensible state of LinuxCNC, which happened after the next command to change the tool "M6T2" - the carousel component was in a strange state and did not give the command to turn on the motor, despite the state of the input signals.

But the essence of my question is not in this problem.
So far I'm inclined to think that the "io" type was specified by chance, instead of "out."

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 ...