LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

counter stuck at zero

Solved!
Go to solution

Hi,

 

I'm using LabVIEW 2014 on Windows 64 bit to acquire displacement data from a digital encoder as follows: Renishaw linear encoder --> NI 9411 digital in --> cDAQ-9174 --> Windows machine.

 

I have a VI that records the displacement at 5000 Hz. It's been working fine for weeks but suddenly, the displacement value (i.e. the count) stays stuck at zero no matter how much displacement there is.

 

Displacement data is also being used in a SoftMotion feedback loop.  That is working fine.  I am even using SoftMotion commands to create a displacement history, which looks right (this displacement history is limited to low frequency activation by the nature of SoftMotion so I created this second way of measuring displacement to get to high frequency).  Point being, I'm confident the linear encoder is working fine.

 

I am extremely puzzled because I haven't changed anything of substance that I can think of.  I did switch the cDAQ9174 to a different USB cable os I started with the hypothesis that I had screwed up connectivity somewhere in hardware.  The cDAQ 9174 and the NI 9411 both pass Self Test in NI MAX.  I checked continuity of the relevant cable pin by pin and it is fine.  Then I started trying to get more insight into the value of the counter.  I have a number of versions of this VI and they all report that the counter is flatline at zero no matter how much displacement there is in the system.  I ran the VI in highlight execution mode to look for clues and I spotted something that seems slightly odd, at least to me.  The counter is identified as cDAQ1/_ctr*.  Does anyone know what that means?

 

Attached are screenshots of the VI with and without highlight execution turned on in case anyone sees anything in there that I'm missing.

 

Thanks,

 

John

Download All
0 Kudos
Message 1 of 3
(2,817 Views)

Hey John,

 

I didn't see anything strange in your screenshots. The cDAQ1/_ctr* just means that there are more characters following "_ctr", but by default highlight execution only includes 11 characters. You can see the same behavior in a few of your other constants.

 

When you changed USB cables, did you change any of the inputs to the 9411? Is everything still configured to match the Connections for Counters and 9411 specifications?

0 Kudos
Message 2 of 3
(2,614 Views)
Solution
Accepted by topic author jdfinan

Thanks for your help.  I can't exactly say I solved this but the issue has gone away.  I reversed all the changes I made to cabling and then repeated them and suddenly it worked again so it must have been a connection issue somewhere along the line.  Thanks for explaining the * thing, good to know that was a red herring.

 

John

0 Kudos
Message 3 of 3
(2,610 Views)