Counter & DIO not working every time

[kenavt]

Hey guys,

We're using the Counter class of the WPI Library in LabVIEW to count the rising edges of a proximity sensor (simple DIO through the Sidecar) in its semi-period mode.

Our procedure at the beginning is to turn on the cRIO and run Robot Main/deploy the whole robot project. This first time, our Counter does not register anything without any errors). However, if the robot project is re-deployed in the same way without any changes to the code, the counter works perfectly.

The raw DIO data works perfectly fine (we get raw feedback from our sensor regardless of the number of times it has been deployed) but the Counter appears to be unreliable.

Can anyone give any advice on this? Is this a problem others have replicated?

[kenavt]

Consider this a formal bump. This issue is starting to cripple us, and getting a bit worse in that it takes more deployments to get the system to work. Any help would be appreciated.

We're hoping to test the exact same code with a different cRIO on Saturday.

[apalrd]

I don't know anything about this specific issue, but this seems similar to the issue we had last year with Encoders (which internally use Counters for 1x or 2x). We could not get Rate from half of the counters(1x/2x) or encoders(4x) on the first boot, but could get Distance.

The workaround (for the entire 2011 season) was to only use half of the Encoders, since half of the FPGA counter and encoder(4x) modules had issues. We created dummy encoders in a specific order to force LV to allocate the counters in a specific order, and it worked, then jhersh released a workaround which marked the bad encoders/counters as already allocated in the WPIlib, so it would not use them.

Try creating two in order (by wiring a wire between the errors on the Opens so it forces them to execute in order) and seeing if both or only one has this issue.

[kenavt]

Our current status is that we've added in error wires to control the data flow in the Begin.vi when initializing the counters. We have four Counters being initialized in the order of Real - Dummy - Real - Dummy. The Counters now appear to be working properly when perma-deployed and when temporarily deployed. We are now having trouble using Counter data in the Teleop.vi, but that appears to be an issue with our PID loops, not the Counter class itself.

Palardy, could you elaborate on the issue you had last year and the workaround? Is that what we implemented?

[apalrd]

Originally Posted by kenavt

Our current status is that we've added in error wires to control the data flow in the Begin.vi when initializing the counters. We have four Counters being initialized in the order of Real - Dummy - Real - Dummy. The Counters now appear to be working properly when perma-deployed and when temporarily deployed. We are now having trouble using Counter data in the Teleop.vi, but that appears to be an issue with our PID loops, not the Counter class itself.

Palardy, could you elaborate on the issue you had last year and the workaround? Is that what we implemented?

That's what we did last year. I couldn't remember if the first one was dummy or real, but they alternated (at least the first few did, one of the last ones seemed random).

What issue are you having with the data?

[kenavt]

Hmmm, alright.

Our current issue now is discrepancies between how the LabVIEW code works when it's temporarily deployed and permanently deployed. We have integers that are outputs from a NI default PID node. The inputs are valid doubles or clusters of doubles. We have feedback going to the User Message area in the Driver Station that reports the integers as strings correctly (in Teleop.vi) when temporarily deployed, but not when the program is permanently deployed. Then, "NaN" is displayed instead. Have you had this issue either?

[apalrd]

Have you probed the wire to see if it actually is NaN? Try probing up to the source of the NaN.

I usually use NaN in my code to indicate fatal error conditions. It's possible something has an NaN error.

[Doug Norman]

Can you post a simplified version of your code that exhibits the problem, along with instructions on how to reproduce the problem? If so, I can try it on my test system.

[kenavt]

Our head programmer intended to post himself on this thread with code, but he never got around to it, and the issue appeared to resolve itself (No, we don't know how).

I don't have code on hand (will attach in future post when I can get at it). I want to post screenshots of the apparent solution if anyone else in the future has this issue.