FPGA Array Comparison by element wierdness

[nathand]

Which indicators or other information is suggesting that the array values are swapped?

Without going to the actual equipment, can you run the system at your desk with the FPGA set to execute on your development computer and confirm that you get the same results? (In case you haven't done this before, right-click on the FPGA Target in the project and find the appropriate menu item, I think it's labeled Execute On). That will also allow you to probe all the wires in the FPGA code and see the values on them. Again, you'll probably want to replace the analog inputs with constants for this test. To make this work you may also need to copy/move the Realtime Host VI into the My Computer target so that it will talk directly to the simulated FPGA, bypassing the RT portion.

[Drew.Rankin]

---

@nathand wrote:

Which indicators or other information is suggesting that the array values are swapped? The RT "MaxLoad(%)" and/or "LCNominal(mV/V)" elements 0, 1 affect the correct limits on the inputs from the 9237 (ai) while element 5 affects input 4 from the 9237 input. This should line up where MaxLoad(0,1,2,3,4,5) compares to ai(0,1,2,3,4,5). From the output of the OR Array elements and the Less? comparitor, the processing seems to be MaxLoad(0,1,2,3,5,4) to ai(0,1,2,3,4,5). I have an output in another part of the original code that verifies the ai order is correct; however, it is not shown in the attached project. In that code, I index the whole ai array and specifically wire out elements 0, 1, and 5 to an analog output card.

Without going to the actual equipment, can you run the system at your desk with the FPGA set to execute on your development computer and confirm that you get the same results? (In case you haven't done this before, right-click on the FPGA Target in the project and find the appropriate menu item, I think it's labeled Execute On). That will also allow you to probe all the wires in the FPGA code and see the values on them. Again, you'll probably want to replace the analog inputs with constants for this test. To make this work you may also need to copy/move the Realtime Host VI into the My Computer target so that it will talk directly to the simulated FPGA, bypassing the RT portion. I will look at this, I did not realize that you could put the RT code to "My Computer" with the calls to the FPGA front panel and have it run properly. I have tested only the FPGA code in simulation before to understand how it was behaving, and it seemed to be fine; however, I didn't realize you could actually simulate the RT. That's cool.

---

[nathand]

Just want to make sure I'm correctly understanding what you wrote. Are you saying that in the simplified VI you posted, if you run it on the real system and change MaxLoad index 4, it will then cause the LoadError? And as far as you can tell, the reason this happens is that the updated MaxLoad value would cause a LoadError for AI channel 5, but not for AI channel 4? Did you try this with your simplified VI? It seems to me it would be very helpful to look at the individual elements of the array output of the Greater Than comparison and confirm that your theory is correct, which I'm hoping you can do in simulation.

[MrQuestion]

Looking at the code, i can see some issues with the floating point and the conversion.

This is a 24 bit 4bit int fixed point value.

There is no auto convert for this. This will most definatly cause issues with conversion from a sgl.

LabVIEW has no idea on how to convert a sgl to a special fixed point value. LabVIEW will do it's job and if the SGL number fits in the fixed point value definition it will convert it. But, you usually use fixed point to represent something such as a scaled value.

For example one bit represents 25mv or something like that, or it might be a ratio.

I've never worked with this card, so I don't know what terms the output value are in.

I would be surprised to see that you can just convert a SGL to a special fixed point value like what I see in this VI without any issues.

Does this card have any examples in the Help>>Find examples when you filter on the hardware?

[nathand]

---

MrQuestion wrote:

This is a 24 bit 4bit int fixed point value.

There is no auto convert for this. This will most definatly cause issues with conversion from a sgl.

---

It's actually a 24-bit int with -4 bits of integer value (yes, this is entirely permissible). Automatic conversion to and from single-precision on the host side works fine, in my experience. What sort of problems do you think will occur here? Play with it a bit - put a fixed-point numeric indicator on your front panel, and wire a single- or double-precision numeric control to it. I think you'll find it works fine within the range of values that can be represented by the fixed-point.

[MrQuestion]

Yes the automatic conversion will work if the numbers that are within range.

This is generally a bad idea to let labview do this work for you. 

My concern isn't over the ability of LabVIEW to convert this. My concern is that LabVIEW doesn't know what this number really represents.

For example what does the 24bit -4bit int value represent? 

The NI9237 page says that it has a 24 bit analog input accurate to +/1 25mV/V

But that doesn't mean each bit from the analog input on the FPGA is 25mV/V

If you look at the detailed specs for the 9237 https://www.ni.com/docs/en-US/bundle/ni-9237-specs/page/specs.html

You see 

Scaling coefficient

2.9802 nV/V per LSB

When LabVIEW sees the Analog input of 24bit -4bit Int Fixed point it has no idea that each bit in reality represents 2.9802 nV/V.

When you blindly convert this to a sgl data type not only do you lose touch with the true representation of the data, but in some cases you risk loosing resolution. 

As it is now the data from the Analog Input has no units or representation. 

I suggest taking the output of the AI multiply by the scaling coefficient so that you will have a number that is in terms of nV/V

From there you can scale that value up to mV/V (to match the LCNominal type)

As I mentioned before I have never worked with this card. 

[nathand]

I'm with you on not having worked with this particular card, but I think you're off -course about the scaling. That card handles scaling internally. The value that's coming out of the AI is already correctly unitless, and can be compared directly to the limit value. The math and automatic conversion looks entirely reasonable to me here.

[MrQuestion]

This might point you in the right direction. 

This example also includes a calibration technique as well. Change the path accordingly.

C:\Program Files (x86)\National Instruments\LabVIEW 2012\examples\CompactRIO\Module Specific\NI 9237\NI 9237 Getting Started\

Let me know what you find out.

[Drew.Rankin · Accepted solution]

All,

Thanks for the suggestions. I did go down to the machine yesterday afternoon and was able to examine the operation of the FPGA remotely without disturbing the RT code running. This is a VERY COOL THING that I did not realize you could do with a cRIO. I was able to observe the interaction between the RT and the FPGA directly and found that nothing was actually wrong with the application code.

So while this turned out to be much ado about nothing, I learned that I could examine and troubleshoot FPGA code running on a cRIO without actually stopping the RT application to "connect" to the chassis. Pretty sweet, if you ask me!

Procedure:

1. Connect to the cRIO chassis using an open Ethernet port

2. Open the RT project

3. Open the FPGA vi that is running on the chassis (as long as the bit file/vi matches the build running on the FPGA)

4. Run the vi

5. The vi will enter "interactive mode"

6. Observe the vi (you can make changes to the VI controls at this point; however, I chose not to so that I could watch the RT application interactions on the FPGA front panel. You CANNOT probe the block diagram, at least not in the mode I was running.)

7. Close the FPGA vi WITHOUT clicking "Abort" so that the vi continues to run 

8. Disconnect the Ethernet cable

9. Have a cup of coffee and think about what you have observed.

All in all a succesfull day. Thanks everybody!

Drew