[Solved] Cannot set output of FLIPFLOP using data and clock inputs

Hi,
I'm trying to write logic to send a message if the coordinate system is changed to G54 when LinuxCNC is in Auto mode (the primary purpose of this is to warn the operator if M2 or M30 changes the coordinate system to the default G54 coordinate system after using a different coordinate system).
I currently have the following logic:

net is_mode_auto halui.mode.is-auto
net coordinate_system_raw qtpyvcp.g5x_index 

addf near.2 servo-thread
net coordinate_system_raw near.2.in1
setp near.2.in2 1
net is_g5x_index_1 near.2.out

loadrt flipflop count=1
addf flipflop.0 servo-thread
net is_g5x_index_1 => flipflop.0.clk
net is_mode_auto => flipflop.0.data
net in_auto_and_g54 flipflop.0.out

loadrt message names=coordinate_system_changed messages="Information: Coordinate system has been changed to G54"
addf coordinate_system_changed servo-thread
net in_auto_and_g54_pulse coordinate_system_changed.trigger

This is in my custom_postgui.hal file, as I am using the QtPyVCP pin 'qtpyvcp.g5x_index' to determine which coordinate system the machine is in (surprisingly, this pin isn't available in HALUI).

I'm using the FLIPFLOP component as I only want the output bit to go high if 'is_g5x_index_1' goes high when 'is_mode_auto' is already high. If I instead used an AND2 component, I would also get an unwanted trigger if I entered Auto Mode while in G54.

The issue I'm grappling with is that the FLIPFLOP component just does not appear to produce a change in the output as I would expect when the data and clock inputs are set correctly to produce an output.

The code for the component is here: github.com/LinuxCNC/linuxcnc/blob/master...onents/flipflop.comp

FUNCTION(_) {
    int c;

    c = clk;
    if ( reset ) {
    out = 0;
    } else if ( set ) {
    out = 1;
    } else if ( c && ! data.oldclk ) {
    out = data_;
    }
    out_not = !out;
    data.oldclk = c;
}

The crucial lines are 'data.oldclk = c;' (at the bottom) and '} else if ( c && ! data.oldclk ) {'
This indicates that the output will only be high for a single cycle if the data input pin is already high and the clock input pin goes high. Obviously this might not be directly observable through halshow, but I'd expect that if connected to the trigger input pin of MESSAGE, I would get an output, but I do not.
I therefore connected a ONESHOT component to the FLIPFLOP output to more easily observe the FLIPFLOP output:

loadrt oneshot count=1
addf oneshot.0 servo-thread
net in_auto_and_g54 oneshot.0.in
net in_auto_and_g54_pulse oneshot.0.out
setp oneshot.0.width 10

However the ONESHOT output pulse does not go high when connected to FLIPFLOP, indicating that FLIPFLOP is not functioning.
I am certain that the connections have been made correctly and have tested the components separately and they are all functional (besides FLIPFLOP of course)

If anyone has any idea of what I might be missing here, help would be much appreciated! 

I haven't, no! I tried using is_g5x_index_1 to trigger a oneshot as flipflop the clock input instead, but no change. I'd expect both would work and give the same result though (since the flipflop writes the data input on a rising clock edge).

I'm convinced I must've missed something but I have no idea what it could be.

If you have any examples of a working flipflops using clk and data that would help, I couldn't see much when I had a look!

Trying it by hand works, that is:

halcmd: loadrt flipflop
halcmd: addf flipflop.0 servo-thread
halcmd: getp flipflop.0.out
FALSE
halcmd: setp flipflop.0.data 1
halcmd: setp flipflop.0.clk 1
halcmd: getp flipflop.0.out
TRUE
halcmd: setp flipflop.0.data 0
halcmd: setp flipflop.0.clk 0
halcmd: setp flipflop.0.clk 1
halcmd: getp flipflop.0.out
FALSE


Have you tried plotting the flip flop input and output signals with halscope?

Thanks so much for looking into this for me! I was able to reproduce what you did above (as I'd expect to be able to).

If I use halcmd to unlink the is_g5x_index_1 clock input from the flipflop, and then manually set the value of the clock input, the flipflop works as expected, only for it to not function again when I reconnect 'is_g5x_index_1'.
My understanding is that it shouldn't be possible for the flipflop to be in the state shown in the screenshot where both the data and clock inputs are high, but the output is low.
 

Again, I'm not sure what could cause this. I was able to form the connection to connect the clock input so there should be no issues with the number format. I can see the changes in the clock input in Halshow, it just has no effect on the output.

Having clock and data high and output low is perfectly valid:

set clock low
set data high
set clock high
set data low

The rising edge of clock copies the data input to output
The data input state doesn't matter except at the rising edge of the clock
also the clock state doesn't matter only the rising edge is important.

Are you sure you don't mean:
set data low
set clock high
set data high
If the clock is set high after data is set high, the output will be high.
If the clock is set high before the data is set high (aka data is set low), the output will be low.

But sorry, yes, you are correct that the rising edge sets the output, so you could put the clock high and then the data input high but the output would not go high (and that's the entire reason I'm using the flipflop and not an AND gate).

In this case I did put the clock input high after I put the data input high, and yet the output doesn't change.

In this case I did put the clock input high after I put the data input high, and yet the output doesn't change.

That can happen if the clock was already high

Sorry, I need to clarify, when I say 'put it high' I mean 'change it from low to high'.

Both my inputs ('is_mode_auto' and 'is_g5x_index_1') stay high as long as I remain in Auto Mode and G54 respectively, so the flipflop should work as intended and the output should trigger if I enter G54 when already in auto mode (which is how I've been testing it).

The flip flop works as intended as far as I can tell.
Like I said, you will likely have to plot the inputs and outputs
with halscope so you can see the signals at enough timing
resolution to determine what is happening, something like this: