FPGA Development - Why is this comparator not working as intended?

[Valeliw]

Hello,

I am a student whose project has taken me to the beautiful land of Labview FPGA development. I am very new to this so any advice regarding my design is appreciated. Admittedly, Labview is much nicer than using Vivado, but I am having some trouble with some functions that should really be basic. I am reading two voltage inputs, comparing them, and their difference is compared to a user set value. Below is a picture from part of the front and back panels of this functionality (ignore the fact that I called my voltage readings I2 and I3): 

https://imgur.com/a/M2KRuen

As you can see from the front panel, the difference between the two is calculated correctly (around 1.6 in this picture). However, the LED "Diff Warning" that SHOULD turn on as soon as this difference is above "Differential Setting" is still turned off. As a consequence, "Fault Location" stays at 0 and is never set to 1. I've bashed my head at this for a while and honestly every compilation takes 10 minutes and I can't take it anymore.

Any idea why this might be? I will leave the code file attached as well if anyone is interested.

Thank you for your help everyone!

PS: Here is my system info

-NI cRIO 9024

-FPGA cRIO 9114

-Input module is NI 9223 (seems to work fine)

-Output module is NI 9401 (not as issue at this time)

[crossrulz · Accepted solution]

Local Variables are a clear sign that you are (most likely) doing something wrong in FPGA land, more so than in a Windows application.  Start by combining your Data Acquisition loop and the comparison loop.  You probably also need the Differential Setting control to be INSIDE of the loop (it is currently only being read once before the start of the loop and you will therefore always be using the starting value).

I would change your fault handling loop to use a FIFO or an occurance instead of constantly reading from a local variable.  The FIFO can store your fault locations and it will only perform the DIO action when something comes in.  You can think of the FIFO as a special version of a Queue.

Your DIO loops on the bottom should all be a single loop.

And why so many shift registers?  Almost all of them are just extensions of local variables or read values that you then use on the next loop.  Get rid of them and just read and use in the same loop iteration.  You are not doing anything here that requires a pipeline architecture.

[Valeliw]

---

@crossrulz wrote:

Local Variables are a clear sign that you are (most likely) doing something wrong in FPGA land, more so than in a Windows application.  Start by combining your Data Acquisition loop and the comparison loop.  You probably also need the Differential Setting control to be INSIDE of the loop (it is currently only being read once before the start of the loop and you will therefore always be using the starting value).

I would change your fault handling loop to use a FIFO or an occurance instead of constantly reading from a local variable.  The FIFO can store your fault locations and it will only perform the DIO action when something comes in.  You can think of the FIFO as a special version of a Queue.

Your DIO loops on the bottom should all be a single loop.

And why so many shift registers?  Almost all of them are just extensions of local variables or read values that you then use on the next loop.  Get rid of them and just read and use in the same loop iteration.  You are not doing anything here that requires a pipeline architecture.

---

Very interesting, thank you! I will attempt these changes tomorrow when I get access to the cRIO. You mentioned that Local Variables are an issue, and I have read that indeed they seem to cause a fair few problems in LabVIEW. Apart from race conditions, why would that be the case?

I am still quite new to this software and working without local variables seems very complex, especially in a case such as the Fault Location variable that can have multiple values. I have a feeling that the FIFO solution you mention is pointed towards this specifically, but I am not super confident I understand what it is and how it is used (if I understand correctly, it is a sort of queue that stores values and can be read later?) 

You have also mentioned the fault handling loop, I suppose you mean the loop containing the case structure with Fault Location as input? Do you suggest it should instead be triggered by the FIFO that would feed it it's stored values?

And about shift registers, yeah that's my bad. I read an article about pipelining and optimisation and I half assedly applied it to my project. I'll get rid of them and just read and write in the same loop. 

Finally you point about the bottom loops, those are just for testing and show so they're just there to confirm to me which outputs of the module are currently outputting. If they were single loop surely they wouldn't get updated, right?

Thank you for your answer! 

[crossrulz]

---

@Valeliw wrote:

Very interesting, thank you! I will attempt these changes tomorrow when I get access to the cRIO. You mentioned that Local Variables are an issue, and I have read that indeed they seem to cause a fair few problems in LabVIEW. Apart from race conditions, why would that be the case? 

---

Race conditions, memory issues, in the case of FPGA you have extra fabric being used, and it is just generally pointing to a bad architecture.

---

@Valeliw wrote:

I am still quite new to this software and working without local variables seems very complex, especially in a case such as the Fault Location variable that can have multiple values. I have a feeling that the FIFO solution you mention is pointed towards this specifically, but I am not super confident I understand what it is and how it is used (if I understand correctly, it is a sort of queue that stores values and can be read later?) 

You have also mentioned the fault handling loop, I suppose you mean the loop containing the case structure with Fault Location as input? Do you suggest it should instead be triggered by the FIFO that would feed it it's stored values?

---

The FIFO is exactly the same as a Queue.  And what I am suggesting you use is a form of a Queued Message Handler.  You could also look to the Producer/Consumer as a starting point.

---

@Valeliw wrote:

Finally you point about the bottom loops, those are just for testing and show so they're just there to confirm to me which outputs of the module are currently outputting. If they were single loop surely they wouldn't get updated, right?

---

Why wouldn't they?  Only if the loop stops running would they not update.