errors in LabVIEW because Max is not ready

[Dave_Thomson]

I'm having an unusual problem with Max and LabVIEW.
I need to have a LabVIEW program launch auotmatically on startup and run unattended. I put a shortcut in the Startup folder, use automatic logon, and generally things work. However, I have had some issues doing this with 8186 and 8187 PXI controllers. The 8186 was running WXP. When it started up and launched my program, often times LabVIEW could not talk to various NI hardware in the PXI chassis. I would get errors doing D/A, A/D, DIO, reading Max settings, whatever. If I quit the program, exit LabVIEW, then launch the program again without rebooting, everything usually works.
The 8187 is similar, but the problems aren't as severe. Most of the time, the program works right away when it boots up and runs. However, once in a while, the digital output doesn't work. It doesn't return an error, but the DO bits don't work. It's as if the DIO mapping is wrong, and it's setting a different DIO port or something. If I quit LabVIEW and restart it, it is fine. So I'm guessing that it has to do with MAX. I believe LV reads the Max database when it launches. If Max isn't ready or something goes wrong, it won't work until LabVIEW is restarted and rereads Max. I'm using traditional Daq, by the way. Also, I'm configuring the DO channels in LabVIEW, not in Max, so all that Max should be doing for the DO is registering which Device is which.
I' playing with putting a delay in the startup before launching LabVIEW. That seems to help. A 10 second delay reduced the chance of the DO error somewhat. So far, a 20 second delay seems to have eliminated the error. But that is a poor kludge.
Summary: PXI-8187, PXI E-series multifunction card, LV 7.1, Max 3.1, Traditional NI-Daq, W2K, DO. Has anyone seen a situation wherein Max does not appear to be ready by the time LabVIEW has launched and started? If so, is there a fix? Has anyone seen a situation wherein Max does not appear to be ready by the time LabVIEW has launched and started? If so, is there a fix?

Thanks,
Dave

[nickbike]

Hello Dave,
Are you creating your program as an executable? If you are not, I would suggest you try this. Please see KnowledgeBase 3C6FNR8O
on creating an executable for startup.

Nicholas C
National Instruments
Applications Engineering

[Dave_Thomson]

Nick,
Thanks for the idea. I had considered trying this, but haven't gotten around to it yet. I've done this before with other systems. The reason I did it then is that it loads faster. In this case, I was going to try it just because it was something different, but I wasn't expecting much. In fact, loading the LV software faster would, according to my current theory, just make things worse. It seems that the LV program is starting before the low-level drivers are really ready. So how would making the LV program (in .exe form) load faster help?

[nickbike]

Hello Dave,
If you notice when you build a VI into an Application in LV 7.1 the nidaq.dll is included in a data folder. The .exe application accesses that .DLL therefore LabVIEW does not need to open and neither does MAX. All the configuration settings for your VI are saved in the .exe when it's built. You will notice that when you are running the application from an .exe, LabVIEW does not open. This makes the program load much faster because the .exe is only loading and using the LabVIEW run-time engine not the full version of LabVIEW.
I would try building your VI into an .exe and see if you are seeing the same behavior.


Nicholas C
National Instruments
Applications Engineering