Fieldpoint Channels not working when deployed to RT Target

[Scott93535]

Hello

     I am working with a cFP-2100.  When running the code remotely from my computer all of the digital outputs of a DO-400 works.  but once I run the code on the controller remotely one channel does not work at all and another channel comes on correctly but does not turn with the proper time delay.  Has anyone seen this behavior before?

Thanks
Scott

P.S. This thing is so close!  Everyone's help from this discussion gropu has been greatly appreciated.

[Wayne.C]

Scott,

If you wait a while, will the program start working properly?  Several other cFP users and myself have noticed that the first pass through our programs was taking a lot of time and that the timing of our I/O was off.  The fix was to add an empty text file named fpremote.ini to the ni-rt\system directory of the cFP controller.  Make sure you have this empty file.  I still do not fully understand why this works, but it does.

Here is a link to the original posting http://forums.ni.com/ni/board/message?board.id=110&message.id=4281&requireLogin=False

[Scott93535]

Thanks for the note, I'll work it this evening.  In the mean time I attached an image of the vi portion in question.  I built a simple program to toggle each output and ran it from both my computer and from the RT target and it worked fine with no timing issues.  The vi in question runs fine from my computer but not from the target.  The image shows what portion does not work on the target.  The timer in that frame does work properly.  I also tried to directly address the FP write block instead of passing the address to it from the calling vi buthadthe same results.

Scott

[Wayne.C]

Scott,

Have you considered wiring up the error cluster?  It could be that the FP Write is generating an error or warning that might help explain the problem.

[Scott93535]

No, I haven't done that yet.  I'll have to add the file you suggested and wire the error cluster out this evening.  It just seems that it if it works when run from my computer it should not have an issue running from the RT target

scott

[NIJanell]

Hello Scott,

I believe what you are experiencing is a known issue.  If you are using LabVIEW Real Time 8.0 and not doing any remote IO there will only be an fpbank.ini (the local IO file) transmitted to the controller upon deployment, not an fpremote.ini (remote IO file). The driver will try to find the fpremote.ini file, retrying for 5 seconds every time a new IO control is used. This issue is only present in LabVIEW 8.0 and only occurs if you are not doing Remote IO, when doing remote IO the fpremote.ini file is created automatically. 

The issue was fixed in the FieldPoint driver that shipped with LabVIEW Real Time 8.0.1. 

If you do not want to update your driver and RT module, a workaround for this version is to create a blank file fpremote.ini and place it in the ni-rt/system directory on the controller.

Good luck!

Janell R | applications engineer

[Wayne.C]

Janell,

Thanks for the info.  Can you clarify Remote IO?  Are you talking about one cFP reading IO on other cFP?

thanks

Wayne

[Scott93535]

Janell

     Thanks for the note.  I am not sure what version of LabView RT I have but I'll check this evening.  Not to ask the question again, but can you clarify "remote IO"?  I was running the VI from my desktop without issue and then started having problems once the vi was being run from the controller.  I am assuming "remote IO" means running hte vi from my computer and not the controller.  Can you explain why the missing file would allow some channels to work but not others?  Just curious about that.  I have no issue updating hte firmware so I will probably take that route.

Thanks for the help.

Scott

[Scott93535]

Hello

       I put the fpremote.ini file in the proper location, and checked my software version numbers, I have LabVIEW RT 8.2, and Fieldpoint drivers 5.2.0.  this did not seem to resolve the issue.  Also, I ran a simple program with only one vi that toggled each output in sucession and ran it both from my computer and from the controller and it ran without issue.  I am only seeing this problem when I run the vi noted above.  The vi that is not working properly is called by the main vi.  It works fine if I run it from my computer but when it is run on the controller.  Additionally, I wired  out the error cluster and did not see any error messages comming up.

Scott

[Wayne.C]

Scott,

Have you double checked that the software versions on the cFP exactly match the versions on your development machine?