FPGA - Issue with calculating analog output.

[HRingenbergCU]

Hello,

I am a relative beginner with LabVIEW programming and using FPGAs. I have taken over a previous students project that uses a cRio FPGA to calculate the analog voltage output to a torque controlled motor to make it mimic a single degree of freedom rotational system. I have attached an image of the while loop used to find this voltage based on the position, velocity and acceleration of the motor. These are also calculated on the FPGA from the motor encoder output. This basic loop as no issue and is working as expected by calculating the correct output and sending it to the motor driver.

Working loop to calculate output

However do to mechanical torque bias of the motor I have developed a method that is used to correct the analog output via addition of a 3rd order function of position. However when I try to implement this 2nd script by changing the select control variable the FPGA no longer outputs a signal to the amplifier even when the polynomial coefficients (C0, C1, ... etc.) are set to zero.

Loop with empirical correction, failing to output signal.

The only differences between these scripts I see is the multiplication and addition of constants that I am setting at the top level VI and sending to the FPGA. I am uncertain if I have used some unsupported functions on FPGAs such as (x^2). The modifications seem minimal but result in a failure to output anything. If I can supply any more information let me know, all ideas or guidance are appreciated!

Note: Still using LabVIEW 2014 with the NI - cRio 9063 and outputting the signal through a NI 9263 module.

Best,

Hunter

[GerdW]

Hi Hunter,

when the code in the 2nd image is executed then some value is written into that AO node, so some value is used for output...

Why don't you check that output value by writing it into an indicator you can read with your RT target?

[BertMcMahan · Accepted solution]

There's a good chance all those coercion dots are killing your signal. If you post your code we can see it. I'd suggest running the same code on a normal VI with an indicator instead of the AO terminal, that way you don't have to compile each time.\

Gray wires are of type Fixed Point. The red dots means there is a coercion happening, which means there may (probably) be some data fidelity loss.

For example, if your Velocity Filtered is a FXP 8.8 and your Damping eta is 8.8, the output of the Multiply terminal will default to a 16.16. The red dot means it's being coerced.

Right click on the terminals and go to Data Type to see their FXP representation. You can also right click on the Multiply and select Properties, then Output Configuration to see how they're configured to output. I'd recommend unchecking Adapt to Source and specifying things manually.

Fixed point math can be tricky, but you'll need to understand it to program an FPGA.

[HRingenbergCU]

Thank you for the suggestion! I have written that value to the AO to an indicator for both the first (working) and the second case (not working) and it seems my suspicions are correct. In the first case I am seeing the proper value for an output (voltage to the motor) and in the second case the indicator remains at 0 under the same loading conditions. I am still stumped.

[HRingenbergCU]

Thank you Bert, moving to a regular VI is a great idea for debugging. Recompilation has been considerably slowing down the process. I was unaware that is what the red dots indicate and see how that is important to know. I wired everything in a way that made sense to me but did not realize fixed point math could corrupting the signal. I will look at changing those settings and get back to you. I appreciate the informative response! 

[BertMcMahan]

If you can post your code (not a picture, but the actual VI, or a VI Snippet) someone else here can take a look. FXP math is a very unusual way to think about things and can get tricky the first couple times you work with it.

[HRingenbergCU]

Here I will attached the FPGA.vi file that is running on the cRio. I can read/write to this from a driving top-level VI. (Which I  can include if needed but I feel confident is working). For a quick rundown the loops in order from top to bottom perform the following functions.

Loop #:

1) Software fail-safe to prevent large motor angles.

2) Selects control for the motor: Switches 0 and 2 are positions controls that we don't need t worry about. Option 1 is the working torque control mode and Option 3 is the broken mode for trying to adjust this torque. This is where the issue is.

3) Tracks the motor encoder position. Also numerical calculation of velocity and acceleration.

4) Filters noise from the data.

5) A trigger loop for timing in certain experiments.

I appreciate the help and apologize for the slow response I was not working this weekend. Is there a benefit for using fixed point math on the FPGA or would I be okay with trying integers as this is a relatively simple program? Thank you again!

Hunter

[GerdW]

Hi Hunter,

have you opened the contextr help window?

Did you move the mouse along those FXP wires and watched the content of that context help?

Your calculations result in <a ±,64,212> FXP: this is quite big. Too big…

What does your AO channel expect? (It's not possible to know without your lvproj file!) I guess it's something like <±,11,16>: trim your calculations to result with such a FXP datatype…

Do you even need to start with FXP of 64 bit word length?

Many of your calculations involving FXP data show coercion dots: this really is a no-go. You need to know which FXP datatype you need and you need to adapt each step of your calculations to give the correct result in a sensible FXP datatype!

Other stuff in your VI:

Use Select nodes instead of big case structures.

Why are there ToFXP nodes that don't change the FXP datatype?

Cleanup. (Even AutoCleanup will improve your diagram.)

[HRingenbergCU]

Bert thank you for the help, I actually got it working now by manually changing the outputs of the multiplication nodes to the appropriate values and make sure they match when summed. This has worked and now I can test if my calibration coefficients will work as hoped. Thank you!