Latest FPGA code?

[ayeckley]

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:

Image: FRC_2009_v11.zip
Date: 1/23/2009
NetComm: 1712
FPGA: 1.0.0

Thanks in advance...

[Greg McKaskle]

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.

Greg McKaskle

[ayeckley]

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...

[Greg McKaskle]

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.

Greg McKaskle

[ayeckley]

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.

So, as expected: user error.

[Greg McKaskle]

Sounds like you are on your way.

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.

Greg McKaskle

[jhersh]

Originally Posted by ayeckley

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:

Image: FRC_2009_v11.zip
Date: 1/23/2009
NetComm: 1712
FPGA: 1.0.0

Thanks in advance...

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.

Cheers!
-Joe

[plusk01]

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:CounterEncoderSourceConver tion.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.

Anyone else experience the same problem?


Parker Lusk
Programming
Shockwave Team 1742

[Alan Anderson]

Originally Posted by plusk01

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:CounterEncoderSourceConver tion.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.

Anyone else experience the same problem?

At least two teams have posted about this issue. When we had it happen to us, the thing that finally made the problem go away was reimaging the cRIO.

See http://www.chiefdelphi.com/forums/sh...ad.php?t=81366 for discusson.

[PICgnosis]

Originally Posted by Alan Anderson

At least two teams have posted about this issue. When we had it happen to us, the thing that finally made the problem go away was reimaging the cRIO.

See http://www.chiefdelphi.com/forums/sh...ad.php?t=81366 for discusson.

Make that three teams. Reimaging the cRIO resolved the issue for us as well.