I’m having some issues with the 4X encoder setting. At one point circa February 09 (after the release of update 3a) there was a known bug in the FPGA code related to the 4X setting. Even after searching through CD, NI Communities, etc. I haven’t been able to figure out if a fix was ever implemented.
Can anyone (Greg?) confirm that FPGA 1.0.0 (which appears to be the image that accompanies the FRC_2009_v11.zip update, which itself part of the FRC Update 3a package) is really the latest image available? It seems that if a fix was ever implemented, the rev should have been bumped. Hence my wondering.
According to the FRC_ImageVersion.txt file on the cRIO, I’ve got:
I’m actually not the definitive guy for this. I believe this has been truly fixed for this year, and the workaround last year was to turn on a bit of averaging.
I cannot say for sure if it was fixed last year, or if the workaround was the solution.
Thanks Greg. I’ll continue to use the workaround until Kickoff '10, and then use the new version after that. Now if I could only figure out why the Global that stores the rate from “Encoder Get” keeps getting zeroed out then I’d have this thing licked…:rolleyes:
You may already know this, but right click on the global and select Find>>References. It will bring up a list of the readers and writers. You can click or hit ctl-g to go from one to the next and think about how the writers may be interacting. Ideally, you will only have one writer, but if you need to update in more than one location, at first glance that seems impossible.
You may want to read up on functional globals in LV. Each non-reentrant subVI automatically acts as a critical section, ensuring that only one caller is active in the function at a time. This allows you to put data modifications within a common function to ensure that your parallel updates are playing nicely.
The single update also makes it easier to put traps into your code to break when the update value is zero. Feel free to ask more questions.
Well, I’ve got my Global Variable issue ironed out now.
I did read the available docs carefully but found that I wasn’t really off-base in my understanding of how they work in LabVIEW. Although that boosted my ego a bit, it didn’t help me figure out the problem. My next step was to methodically go through the main VI data flow in full detail, and I eventually realized my mistake during that process.
The architecture I’m experimenting with deliberately writes to the same Global in multiple locations within different SubVIs. The states within this architecture are structured so that only one Global write operation is active at any given time. Or so I thought. It turns out that I’d placed a Global write operation on the exterior of a set of cases (Init, Execute, Stop in Disabled.VI), when I really should have put it only withinin the Stop case. The unintentional, repeating write was trodding all over the intentional one (in Periodic Tasks.VI ) with its stale data.
Be sure to watch for read/modify/write sequences that may overlap. If you are building your data access around the communications protocol state machine, you should be in pretty good shape. You may still find it useful to push the global accesses down into a subVI and add a check-out and check-in mechanism. You can put a counter inside the subVI that allows you to put validation code to catch any unexpected accesses in the future and put up a dialog or hit a breakpoint. This is especially useful if someone else will work on the code.
The image you were using did not include the fix in the FPGA. There was a workaround in WPILib that would adjust for the bug.
In the image for this year, the bug is fixed in the FPGA. Look for version 2010 and revision 1.3.0 of the FPGA. The corresponding workarounds in the library are also removed for 2010.
You can look here for a list of changes since 2009. It’s still in progress, but the FPGA changes are all there.
This problem I’m having may or may not be related, but here it is:
I started programming with encoders (the US Digital shaft encoder) in LabVIEW and every once in a while when front panel debugging, I’ll get an error when trying to run Robot Main on the cRIO with my Encoder code. I get the same error with the pre-written encoder examples. I posted in this thread because the 4x encoder setting and FPGA were mentioned.
The error I get when I try to Run my LabVIEW code on my robot is that it fails to deploy the NI_FPGA_Interface.lvlib:CounterEncoderSourceConvertion.lvlib and then the entire deployment process fails.
I believe it is a problem with the supplied Encoder libraries, because this error didn’t come up until I started opening encoders.
