LabVIEW FPGA/NI 9505 current sense returning incorrect values

[Mountain Goat]

Hi guys,

I'm working with a cRIO system and seem to be running into some issues with the current sense IO on the NI 9505 in that it is returning an incorrect value during execution. I didn't see this posted earlier, but it's acting like it might be a bug in the LV FPGA module because I can't seem to find anything in my code that would make things work the way it is.

Here's a quick description of the setup that I'm working with:
-NI cRIO 9004
-3M Gate FPGA
-NI 9505 connected to a servo motor (no load on the servo)
-LV 8.0.1 with LVRT 8.0 and LVFPGA 8.0

Here's the behavior I'm seeing:
I have a servo connected to the 9505, and am able to turn the motor on and off, enable and disable the motor drive, and determine positional information from the encoder. Originally, I was able to see the values detected by the current sensor on the NI 9505 change in response to me altering the duty cycle. However, after adding some additional complexity to my application and re-compiling, downloading, and running the code again, the FPGA current sensor started and stayed at 2047 (with motors disabled and not physically moving). I could turn the motor on and off (and watch it physically move), but the current sense value never deviated from 2047 (even when the motor drives were disabled). I didn't see anything suspect in the code, and the compile process didn't result in any errors.

To make sure I wasn't crazy, I wrote a very small VI (an image shown in Current Sense.jpeg) that just reads the current sense value. It fluctuates between -1 and 0 counts  when the motor is disengaged.

Since this VI apparently worked, I decided to download the Current Loop - NI 9505 (FPGA).vi example (no recompile) included in the LV help. This VI worked OK as well, and the current fluctuated between about -30 and 30 counts while it was being controlled.

Knowing that the hardware is working OK, I wrote a new VI from scratch (but in the same project as the Current Sense VI that worked) that just runs loops to update the inputs and outputs of the 9505. I've attached an image of this VI in System IO.jpeg. I can use this VI to control every aspect of the motor (as well as to get some of the module properties), but the FPGA current sensor still jumps to 2047 and stays there regardless of what the motor is actually doing.


Has anyone run into this issue in the past or have any thoughts on what might be causing it? I can't seem to peg it to a specific thing in the code, but it seems to be happening consistently to my larger VIs.

thanks,
the goat

[ChadE]

Hello the goat,

Thank you for bringing this to our attention. The NI Motion R&D Group has begun looking into this issue. We will update this discussion forum post when we have more information.

Regards,

[Mountain Goat]

Hi Chad,

Thanks for the reply.

After I posted my message, I found that removing the Serial Number, Device ID, and Vendor ID properties from the lower right hand while loop (shown in System IO.jpg in my original post) fixed the problem after recompiling the code.

I haven't yet removed the properties one-at-a-time to identify which one was causing the problem, but it seems that keeping those properties out of your code is at least a simple workaround that doesn't require major changes to the code.

Mountain Goat

[ChadE]

Hello Mountain Goat,

Thanks for the new information. That is what we guessed might be the problem and were in the process of verifying when we saw your post.

Communication between the 9505 and FPGA is performed through parallel and serial protocols. The current sense data is part of the serial bus. The Serial Number, Device ID, and Vendor ID properties share the same serial bus but are part of a different data packet. When those properties are read, and you are trying to read the current sense, the data for the current sense will be incorrect since the serial bus is being used to read the above properties. Do not read those properties as part of the main application loops or while trying to perform other operations with the module. If you need to read them, do so before executing the main loops. The three properties listed above are the only ones that show this behavior. Various cRIO modules have similar requirements when reading certain properties.

Regards,

[Mountain Goat]

Hi Chad,

Thanks for the information, it was very helpful.

Mountain Goat