LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

No FPGA Response on LSB Weights and Offsets?

Hi Folks,

I've written an FPGA DAQ application for the PXI-7813R Reconfigurable IO card (just like cRIO except in a PXI card) and three R series expansion chassis.  Specifically, I'm trying to get the LSB weights and offsets for several channels on several C series analog input and output modules.

I've got two 9237 strain gauge modules, two 9217 RTD modules, a 9263 and a 9265 module (analog output), and a 9205 analog input module.
Okay, now that that's all been explained... The segment of my code that used to return these cal constants worked for a while, but now I'm getting absolutely nothing back except zeroes on all channels (for the LSB weights and offsets).  Suddenly, it just stopped working.

I tried a couple of reboots of the PXI and recompiling, but nothing seems to help.  (Recompiling gets really old) I know that the rest of my FPGA code is working properly because I can turn my digital outputs on and off without any problem.  It's the analog cal constants portion that's stopped cooperating.

I wish I could post a screenshot, but I have no image hosting... I have a large, typedef'ed cluster that I populate with the cal constants from each module.  None of the FPGA property nodes are data dependent on each other, but I'm using four sequental "bundle by name" functions.

Does anyone have any suggestions?   Has anyone seen this behavior before?  I'd appreciate any help.

Thanks in advance,

Jim F



0 Kudos
Message 1 of 23
(9,985 Views)

Hi Jim,

Are there any error messages returned out of the IO nodes?  If the IO nodes error out the data returned will be default values ( 0's ).

Bassett

Message Edited by Bassett Hound on 09-13-2007 10:56 AM

Message 2 of 23
(9,976 Views)
Hi Bassett,

Thanks for the fast response.  Only the property node for the 9205 has error clusters - the rest of the nodes don't have any.  I didn't have the 9205's node wired for errors, but I'm going to do that and recompile and see what I can find out from that.

There may very well be an error from the 9205, but I'm still wondering if that would somehow effect all of the other modules, too.

Is there anything else I should check before I begin recompiling?

Thanks again,

Jim


0 Kudos
Message 3 of 23
(9,970 Views)
Not off the top of my head.  To make it quicker I wouldn't compile your entire app, but just compile an additional VI that only reads the Calibration values and returns the error nodes as well.  The compile should be a little quicker.

Bassett
0 Kudos
Message 4 of 23
(9,968 Views)
Good call... I'll strip it out and make a separate VI.
0 Kudos
Message 5 of 23
(9,964 Views)
Okay Bassett,

I compiled and ran a VI that reads the LSB weights and offsets.  The property node for the 9205 showed no error, and everything still showed up as zero.  Oddly enough, having also run an invoke node for my two 9237 modules' "Start" methods, that invoke node gave me error 65536.

Looking up the error yields "CompactRIO:  (Hex 0x10000) Unable to communicate with the module. Reinsert the module and check connections."

I checked all of the cables (they were tightly seated) and reinserted the 9237 modules, and now everything except the 9237 cal constants are coming through.  I'm still getting error 65536 on the 9237 invoke node, and my 9237 cal constants are still all zero.

Have I misused the "start" invoke nodes?  It seems strange to me that re-seating the 9237 modules apparently made all the other constants come through.

Thanks for all your help so far...

Jim
0 Kudos
Message 6 of 23
(9,955 Views)

I don't think you could misuse the Start and Stop IO lines that would affect reading the calibration.  You might post and image of your VI so we can offer some more suggestions.  Since we isolated it down to the 9237 we could try running the shipping example for the 9237 and seeing if it gives the same error.  You might check the pins on the slot the 9237 was in to see if any of them are bent ( I've been bitten by this before since I'm a little hard on the equipment )  You might also try just reading the 9237s serial number and vendor number, if those error out with the same communication error it might be a more grevious error.  

Has the module ever worked?

Bassett

Message 7 of 23
(9,947 Views)
I'm pretty sure that both of the 9237 modules worked before, but I could be wrong.  I've haven't hooked up any strain gauges yet, as I was concentrating on getting the development done first.  However, I do remember that all of those constants came through as recently as yesterday when I was running a different bitfile.

I just checked the pins on the pair of 9237s, as well as the pins of their two neighbors.  Everything looks okay, and the chassis cable seems to check out, too.

I've removed the "start" invoke nodes just for the heck of it, and I'm going to try again.  If that doesn't work, I'll see if I can read the serials and maybe revisit the shipped examples...  I'll let you know how it turns out.

Jim
0 Kudos
Message 8 of 23
(9,940 Views)
Okay, I've got good news and bad news.  Removing the "start" invoke nodes (or some other cooincidence) caused the first 9237 module to start returning its weights and offsets. The second module still won't give me its constants, but it will give me its vendor ID and serial.  At least we know it's still talking.

I switched the slots of my two 9237s, and the same thing occurs on whichever module is in slot 2.  I checked the cable on the PXI card one more time to make sure all the pins are making contact.  I even switched to a different expansion chassis using the same cable to the same connector on the PXI card.

Any more ideas?
0 Kudos
Message 9 of 23
(9,930 Views)
I guess some screenshots are a little overdue... Here you are
Download All
0 Kudos
Message 10 of 23
(9,926 Views)