while loop in fpga is not executed

[Pachi]

Guess who's back!

[Pachi]

Andy,

I apologise for the delay. From my initial findings I do not see the bug. 
The VI worked as expected.

[Pachi]

Here is the code I derived from your VI. It is showing the exact same behaviour in both 2011 and 2010.

Please check this VI and tell me your thoughts.

[Pachi]

The coersion dot issue is a boundary case bug that was fixed in 2011. For your case, it shouldnt matter. Set the FXP constant data type configuration to "+, 24, 1" to match that of your input, so that the coersion does not propogate. In this case you will not see the difference in coersion dots. However, this should not have any difference on the output. Please let me know if you find otherwise.

Regards,

Prashanth

[Yamaeda]

I'd guess on race condition. Your local variables of Stop will keep it's previous value the next time you run your program, meaning it'll read True on first loop and stop. Run the program in highlight execution and check.

/Y

[Pachi]

That could explain unexpected behaviour, but it cannot be the case always. For instance, it he restarts LabVIEW and runs again, the Stop variable should read out a zero, and start working fine. But as I understand from Andy's posts, it is a recurring problem.

My two cents,

[Yamaeda]

Hmm, the Heartbeat checks if it's changed since last loop, and if has it increases missed loops, is this how it's supposed to work or should it be the other way around?

/Y

[Olivier_L]

Hi,

I think he said that he had the same behaviour with both code in the same loop (code with and without case structure) but the code without case structure is executing, so it should not be a problem with loop not running.

Because of coercion dot, would it be possible that something in FXP configuration has changed, and values are round to an integer that looks like it's frozen, but it's not?

or another solution would be that the Case control value change and the case condition is not executed anymore!?

Regards,

[Pachi]

I did not see it round to an integer for sure. It retained FXP and gave out decimal values like expected.

Andy,

As a side note, is there a reason you are explicitly using the "Remove FXP Overflow status" after add? You could instead uncheck the "Include overflow status" in your add primitive's configuration dialog. (Also, avoid calling primitives as vi's. Before looking at your code, I assumed you had a subVI called add)

Regards,

[AndyKr]

Hi,

sorry for my late answer and thank you very much for your tips and the interesting discussion. I was not in my office the last days but now I am back.

First I tried to use the test.vi from Pachi. I compiled it on LV2011 and have a strange behavior when I run it. It just counts and the values are changed when the "StepSizeSin" value is larger than 0.5. If it is 0.5 or smaller all four outputs stay constant. For 0.5 the sinus outputs are 0 and for values <0.5 they become constant values. This means for some reasons the add function seems to have a problem or is not working for input values <0.5. The same yields for negative values. For values <=0.5 it works but for values between -0.5 and 0.5 it does not work for me. It seems the add function is not wrapping around if the value is smaller than 0.5. And for very small values of StepSizeSin (e.g. 0.001) the sinus output is 1. So the add function saturates at 1 since sin(0) should be 0.

My RT system is a crio 9022 with 9114 FPGA. So I attach my whole project file. Maybe there is a problem there if the vi is working for you.

Regarding the "Remove FXP Overflow status", I use the overflow indicator to count the number of periods. So I was thinking to increase a counter by +1 each time the flag is set, and then remove it directly again so that it does not count the next loop iteration.

For the heartbeat problem, the RT system changes the boolean variable in each iteration to show it is still running. But the rt system runs much slower than the FPGA. So the heartbeat system in the FPGA should always count the loops when the variable is NOT changed and stop the FPGA system if it is not changed for the number of "missed loops". If the variable is changed, the counter "missed loops" is reset to zero. - This is what I expected from the heartbeat loop but maybe I have a mistake in my thinking there.

But since I do not reset the values after I stopped the system, I have to check if it is a race condition in the loop. I will try to check this tomorrow.

Anyway, thank you very much for your help. Maybe you have some more ideas regarding the add.vi and wrapping around its value. Otherwise I will try to fill in a bug report, but I do not know where.

Best regards

Andy