FieldPoint Family

cancel
Showing results for 
Search instead for 
Did you mean: 

Re-connecting to a Fieldpoint startup.exe vi

I am having problems re-connecting to a vi that is running as a startup vi on a Fieldpoint 2000. I have done this procedure before with LabVIEW 6 and FieldPoint 3.x, but it doesn't work anymore after upgrading to LabVIEW 7 and FieldPoint 4. Here is the procedure:

* Write a vi, download it and test it until it works.
* Save the vi on the host machine (call it my_vi.vi).
* Close my_vi, open a blank one, open app builder
* All paths look good. Select my_vi.vi as the top-level vi, verify the path is correct.
* Build and download
* Use MAX to re-boot the FP2000, watch to see that it comes up and the vi is running. My_vi toggles a digital output bit once a second, so I can see that it is running properly.
* Now try to tar
get LabVIEW to the FieldPoint device.
* It says that my_vi.vi is missing. When I look at the path it says it was downloaded from, it is c:\ni-rt\startup\startup.exe\my_vi.vi !!! This is on the target, not the host. If I browse to the location of the vi used for the build, it looks at it and says that the versions don't match!!! I have tried this over and over again, with no changes made between saving and building. The versions should match. Since it claims that they don't match, I can't open the front panel on the running vi. I can only stop it, which is not acceptable in the final version.

What gives? How did the paths and versions get messed up and how do I straighten them out again?

Rich
0 Kudos
Message 1 of 3
(3,260 Views)
Rich,
First I would like to ask you to review the following documents on good architecture for a real-time application. It is not recommended to rely on the default communication in the final application. Main reasons are that only one host can connect at a time, you do not have any access to resources on the host, and you can not choose what information and how often it gets sent back to the host. It is there fore better to develop a seperate communication back to the host. For example you might use TCP if you have a lot of data to send, or you could choose data socket if you want multiple clients to view the data.

LabVIEW Real-Time Architecture and Good Programming Practices
http://zone.ni.com/devzone/conceptd.nsf/webmain/DC6EE13F8612FC4686256B510066724F?opendocument

Using the LabVIEW Real-Time Communication Wizard
http://zone.ni.com/devzone/conceptd.nsf/webmain/A6F17EE4ADCAB99686256D5E0053E210?opendocument

And there is more information on DevZone in the LabVIEW>Real-time Module category:
http://zone.ni.com/devzone/devzone.nsf/webcategories/C25F8C664230613A862567DF006ABB06?opendocument&node=dz52024_us

The behaviour of having to browse to the VI when it had been started as an appliction, has always been there. When the VI is started as an application it is loaded from c:\ni-rt\startup\startup.exe. If the VI on the host is not located in the same place (which it is unlikely to be) then you must search for it. The behaviour that has changed is that LabVIEW sees the built executable as being different from the source VI. This is a unfortunate side effect of the Application Builder optomizing the VI before the application is built. It is something that we are aware of and are working to fix. In the mean time you can get around the problem by retrieving the built executable from the RT target using FTP. Then create a folder c:\ni-rt\startup on the host computer and place the startup.exe in that folder. Once you have done that, then when LabVIEW connects to the RT target it finds the startup.exe on the host and the two match. No dialog will be shown. The only drawback is that the built exectuble does not have the block diagram, so you will only be able to see the front panel.

Carl L
National Instruments
0 Kudos
Message 2 of 3
(3,260 Views)
Thank you for explaining this, Carl. I am NOT relying on the host connection for communication in my final app. It runs all by itself, and I want to be sure it runs even after a power loss, so I compile it as startup.exe. There are two reasons I would like to re-connect to the target while the app is running. One is to see some detailed error indicators that are not accessible otherwise. I have many error indicators internal to the vi, but they get OR'ed together for external communication. If an error crops up and I want to find exactly where it came from, I can look at the front panel and find out. A remote panel connection would work for that. I also like to check on the free memory every now and then to make sure I am not running into trouble. You
r solution above may allow me to do that.

Rich
0 Kudos
Message 3 of 3
(3,260 Views)