Help - RT controller stops responding, once embedded VI application starts

[Dave_Bell]

I am developing a LabView RT-based instrument, and need to have the embedded VI resident in the PXI controller (has hard drive), and start at boot time.

I started with a simple VI that continuously outputs a pattern to a DAC card (the only I/O board that has arrived, as yet.) Was able to successfully Build it as a stand-alone executable, and get it loaded onto the PXI controller, with properties set to Run When Opened. When I reboot the controller, control is transferred to "user program", presumably my VI application.

At that time, the PXI controller stops responding to attempts to connect to it, view the panel, etc., and I do not get any output to the DAC card. Neither LabView (change ex
ecution target) nor an ftp client can connect. I have to use the PXI Launch Reset Disk I made, to regain control.

Any suggestions for probable pitfalls or ways to debug the problem(s)?

[Chad_H]

Dave,

Follow the instructions in Chapter 2 of the RT Series PXI/CompactPCI Controller User Manual.

You do not need to use "Run When Opened."

Also, make sure that your front panel values are saved as default before building the applications so that the device numbers are correct.

Finally, make sure that you are doing error checking (to break out of a loop when there are errors), and that any continuous loops in time critical priority VIs sleep long enough for other operations (such as the user interface updates) to occur.

Regards,

Chad H.
Applications Engineering
National Instruments

[Dave_Bell]

Thanks, Chad...
I re-did all you suggested, this morning. Printed the User manual from pdf, tomak esure i had the latest, re-read ad tried to carefully follow Ch 2. Still no luck.

Part of the problem is that there are very limited means to see if the app is actually running, let alone correctly. To eliminate other sources of errors, I stripped the VI to a fairly minimal GPIB application. I initialize, then enter an infinite loop, waiting for a command to be received. To ensure there is some time for other code to run, I have a Wait For Millisecond Multiple, with a 100 mS count in the loop. I also set the GPIB timeout to 1 Second, then handle the resulting error, ignoring Timeout. When a string is received, I parse it, looking for either "*IDN?" or an in
strument command, which is simply a digit string, right now. A Case structure contains a response for the ID request, and processes the numeric commands to a panel indicator.

The above runs fine as a VI on the RT PXI controller. I receive no errors from the Application Builder, and have the app set to Launch on Boot-Up. If I drill down into the startup directory with an ftp client, I see startup.exe, but notably, the date and time do not update each time I Build. They have changed, but it seems to be rare that they do??

When I reset the PXI Controller and allow time for the app to load and start, I find that I am unable to ftp into the Controller - for a while. Eventually, I *can* get in. Once the app seems to be running, I try to "talk" to it using MAX on the host PC. I get an immediate EBUS error, indicating no instruments found on the Bus.

Any further suggestions?
Can you suggest a very simple, "known" working example that does not rely upon any I/O cards other than the GP
IB I/F on the 8156B controller?
May I send you the VI I'm trying to use, so you can show me the dumb things I shouldn't be doing?

Thanks!

[Chad_H]

Dave,

Which controller are you running with? If you are using the PXI-8140 RT Series, you have user defined LEDs you can toggle to show it is running. If you have a controller with a floppy drive, you stick a loop in parallel with everything that accesses the floppy drive every 10 seconds (a cheesy way of seeing if your program is running, but it works because the drive light will come on every 10 seconds).

When using Internet Explorer for FTP, clear the cache between each operation. That may or may not explain what you are seeing.

I have
built an application out of the LabVIEW<->GPIB.vi successfully.

If you would like to attach your VI, go ahead. Please trim it down and document it well.

Regards,

Chad H.
Applications Engineering
National Instruments

[Dave_Bell]

I'm running the 8156B controller, so don't (?) have any LEDs I can manipulate. The floppy drive is a good idea!

I did get something to run, at least. Very simple VI that just writed Date/Time string to a file on the HDD, set up into a loop with a 1500 mS delay (Wait for mS Multiple), and a limited number of iterations.(i>5, or 7 loops.) When I finally (took a while) got in through ftp, the log file had 7 lines, with incrementing time. Also, NI-RT/STARTUP/Startup.exe was updated to the latest Build time.

I'm not using a browser for ftp, by the way. Just MSoft's DOS-based ftp client.

I'll clean up and attach the GPIB VI in the morning.

Thanks for the help!

[Dave_Bell]

Again, this is running on an 8156B RT PXI controller, in a PXI-1006 chassis. No instrument funsctions are in the VI, only the most rudimentary GPIB receive and response code. I cut this down from a slightly more complicated VI, and tried it this morning. Still runs fine as a VI on the PXI box, but wehn I compile it to startup.exe, it hangs/crashes/maybe refuses to run at all. After it has been "running" for several minutes, I can regain control of the PXI controller, entering via ftp, or by remote LabView connection. I guess that means the VI has stopped running by then?

[Dave_Bell]

Well! Some progress, and confirmation of a problem:
I was trying again, with a slight modification of the VI I attached earlier. I separated the SetTimeout from the rest of the VI in two frames of a Sequence, and added some logfile notations after init, receipt of a string, and response to ID query. Built, saw that as usual, the date/time didn't update on the PXI HDD, but rebooted to run it, anyway. After succeeding in ftping in, I noticed the new logfile was NOT created, but the OLD logfile, from the simple File I/O test was made new. Confirmation that startup.exe truly was not being updated.

In earlier attempts to embed my application (last week), I was trying to run the Build while my application target was selected to the development PC, but with the proper (\\\C\NI-RT\STARTUP) locations in the dialog boxes, and startup.exe in the Application Name box. Compile would error off, with a message "Unable to Create Directory". The local NI rep was in, and he steered me to targeting on the remote controller, and doing the Build then. That worked, sort of, with the problems I have been having this week, but successful Build, anyway. I also found last week, that from the ftp client, I am unable to delete the file startup.exe. I get Permission Denied, even though the permission flags are -rwxrwxrwx. There seems to be a pattern here:
Build, running on the host PC, cannot perform some file/directory operation on the remote.
FTP cannot delete startup.exe.
Build, running on the remote, does not always create a new version of startup.exe.

I tried Building a totally different VI, and found that startup.exe was updated. Tried building my stripped application VI, and once again, startup.exe was updated! Is there some bug, wherein I have to switch to a different VI and Build it, between Builds of my application?!?

At any rate, after doing that "dance" with Build, the stripped test VI (attached again), with logfile outputs, works! Runs contiuously, responding to commands over the GPIB from MAX, logs them to HDD, etc...

At least now I may be able to proceed with development, but I'd REALLY like to know what's happening with Build writing to the PXI HDD!

[Chad_H]

Dave,

Good job on the troubleshooting! Which version of LabVIEW Real-Time are you using?

The problem you are apparently seeing has not yet been reported by anyone else.

Are you positive that each time you built the executable that you were targeted to the controller, and not to the Host PC? When I was trying to reproduce the problem, I built an application twice, making minor changes each time, and saw startup.exe updated. I tried a third time, and it appeared not to have changed, until I realized I had not targeted the RT Engine by mistake. Always double check the destination directory to make sure it is on your RT Engine.

I have not been able to reproduce the problem. Would you please carefully t
est it on your end, and make a detailed list of the steps you take. Send the list of steps and the initial VI that you use to make the exe. I will then do the same on my end.

Regards,

Chad H.
Applications Engineering
National Instruments

[Dave_Bell]

I am running RT 6.1, which agrees with the bug report in the KB you referred me to. Thanks!
I am pretty certain about the sequence of Build attempts, and where I was targeted, but will re-run some trials today, and report the results.
Thanks for the help!

[Dave_Bell]

OK, Chad, here are the results of testing. I can reproduce this at will. I saved my notes as an RTF document, and will attach it.

Development platform:
LV RT 6.1
Windows 2000

Target platfrom:
PXI-8156B controller
PXI-1006 chassis

Dave Bell, Lockheed Martin, Sunnyvale, CA