Encoder Error

[Haragorn]

So, today, I was trying to set up a US Digital Encoder. I did what I could figure out from the help files, programming-wise, and LabVIEW finds no errors. However, when I try to run our code, I always run into this error:

Deploying NI_FPGA_Interface.lvlib:NIFPGA
CounterEncoderSourceConvertion.lvlib:
LVSourceTypeToFPGAType.vi
Failed to download NI_FPGA_Interface.lvlib:NIFPGA
CounterEncoderSourceConvertion.lvlib:
LVSourceTypeToFPGAType.vi
Deployment completed with errors

Any ideas why that's happening? If needed, I can print screenshots of the code that references the encoders.

[Joe Ross]

Did you install the LabVIEW update and reimage the cRIO with the v19 image?

[Alan Anderson]

I was going to post something similar tonight. Our development system suddenly decided that it wasn't going to run our project anymore, giving exactly that error. We had just added encoders to Begin and Finish. I took them out again, but the error remains.

I couldn't find NI_FPGA_Interface.lvlib:NIFPGA
CounterEncoderSourceConvertion.lvlib:
LVSourceTypeToFPGAType.vi anywhere on the computer. On the off chance that the file might have disappeared, I reran the LabVIEW update. The error remains.

Is anyone successfully using encoders in their LabVIEW code yet? It would be nice to know that it's possible and that I'm not make a futile effort to find what we did wrong.

[Tom Line]

Alan - we went through testing of 10 transmissions yesterday to confirm encoder function before mounting on the robot and didn't have any issues using Labview and the default framework with the encoders added. These are all the USdigital models that come with the toughboxes / supershifters.

Likewise we ran them all beta season without an issue. I've never seen that particular error before.

[Alan Anderson]

Originally Posted by Tom Line

Likewise we ran them all beta season without an issue. I've never seen that particular error before.

We didn't have any problems during the beta either. I asked only because of the possibility of a bug having been introduced in the LabVIEW Update 2.0, but I guess that's not the case.

Without any other suggestions, the only thing I can think of to try is to uninstall and reinstall LabVIEW (and apply the update).

[rwood359]

Originally Posted by Alan Anderson

Is anyone successfully using encoders in their LabVIEW code yet? It would be nice to know that it's possible and that I'm not make a futile effort to find what we did wrong.

We're running a pair on US Digital on AndyMark Super shifters with no problems noted.

[jhersh]

Originally Posted by Alan Anderson

Is anyone successfully using encoders in their LabVIEW code yet? It would be nice to know that it's possible and that I'm not make a futile effort to find what we did wrong.

Our team is using an encoder with all the latest updates and we at NI also run an encoder in the release test bench. We haven't seen this either place. Obviously any more details you can give will help us to narrow this down.

Thanks,
-Joe

[Greg McKaskle]

Would this by chance be a computer used in the beta program? If so, it may be an odd side effect of the installer updates. If this does't resolve with a cleaner install, please contact technical support so that we can dig deeper and determine what really happened.

Greg McKaksle

[Alan Anderson]

Originally Posted by Greg McKaskle

Would this by chance be a computer used in the beta program?

Our development computer indeed has had the 2010 beta software installed. I'll try removing LabVIEW and reinstalling.

[Haragorn]

Today, when I tried to run the code, it worked fine. No changes were made to the code. I did build and deploy it first, to test if that worked, but I'm not sure if that had anything to do with it. I have no idea why it's working now and wasn't yesterday.

[Alan Anderson]

Originally Posted by Haragorn

I have no idea why it's working now and wasn't yesterday.

Ours worked today too, but I do know why. The error message didn't say there was a problem finding the vi, it said there was a problem deploying it. So I inferred that the trouble might be with the cRIO and reimaged it. Success!

There's a lot more voodoo in the NI system than I'd like, but I think I'm getting a feel for the right way to wave the chickens around when necessary.

[Greg McKaskle]

Not to rain on the parade, but this doesn't really make sense. The cRIO does contain flash, and when code is deployed, it and all dependencies are stored in flash. But when executed using the run button, the VIs are saved locally to PC temp storage, and all VIs are downloaded. I think that VIs can reference .out files already on the flash, but I don't think that anything on the disk would have confused the deployment. If there were VI conflicts due to VIs already being in memory, that would have resulted in a different dialog. I don't really see why reimaging the cRIO would solve the issue.

Greg McKaskle

[Alan Anderson]

Originally Posted by Greg McKaskle

...when executed using the run button, the VIs are saved locally to PC temp storage, and all VIs are downloaded...

The error message says "Failed to download NI_FPGA_Interface.lvlib:NIFPGA CounterEncoderSourceConvertion.lvlib:LVSourceTypeT oFPGAType.vi" which implies that the VI was not downloaded for some reason. Without knowing anything about how it really works, I could speculate that perhaps the vi on the cRIO had gotten set to read only, or its directory entry was somehow corrupted to the point where it couldn't be replaced by the download attempt.

I don't really see why reimaging the cRIO would solve the issue.

I don't see why either, but LabVIEW couldn't download that vi immediately before reimaging and did download it immediately afterwards. I consider that to be highly compelling evidence that the reimaging indeed fixed the problem.

[Greg McKaskle]

I'm wondering what part of reimaging fixed it. Did you happen to work up to that? Do you know that a reboot of the cRIO, or a disconnect/reconnect did not resolve the error?

The RT LV engine does cache VIs in memory. It purges elements in the cache due to editing operations, and this either indicates something that needed to be purged and replaced that failed to allow itself to be replaced, or it may point to an issue on the host where LV couldn't locate or build the cross-compiled version of the library VI to download.

I have never seen this, so I'm just trying to get what I can from your breadcrumbs. As you said, this gremlin is one I'd like to purge.

Greg McKaskle