Tim_S

Just glancing at the screenshot... You can use the File Dialog VI. All channels collected will show on the graph. The values can be cleared using a local variable or a property node. This will concatenate the two arrays, but only the current value. You would need to use a shift register to store that concatenation and then add to it on each loop. A better way may be to open the file to save and then keep writing to it during the acquisition (and may be the only way to do this in a long term DAQ). Before you configure the DAQ, or at least before the DAQ start. Yes. No as the data flow has the stop set after the while loop has terminated and is not in a loop itself.

The situation where I've run into this error message is when I try and load plugins from an executable. Typically it's a missing/misplaced DLL, but determining which can be a major pain. Switching to source code doesn't help as the plugin source isn't broken since everything is found where it's expected to be. The why the VI is broken would be of value to me. I've also been able to "fix" some DLL builds by turning on debugging and not had the time to go back and determine why. Tim

The VI properties has a Window Size category which allows you to check "Scale all objects on front panel as the window resizes" and "Maintain proportions of window for different monitor resolutions". The down side to this is fonts do not rescale, tables and multi-column listboxes do not rescale the columns, and things will look strange if you switch between "standard" and "widescreen" monitors. I believe monitor 0 is the active monitor and 1 is the first monitor... this may be why you get incorrect launches 1 of 6 times. Tim

Can you explain what is or is not happening? Your post is lacking in information. Tim

One issue we've had is the device drivers only support some versions of LabVIEW. This might not be an issue between 5 and 7.1, but should be checked. Tim

I don't have anything with LV 5 (it's been, what, 12 or 13 years since I've seen LV 5...), but my experience with LV 8.0 was a performance degradation with more than 2 processors. I expect you won't have an issue with multiple processors and that the application will split between the two. Tim

UPDATE: Tech support has filed a CAR. Tim

Thanks to everyone for looking at this. I've emailed this thread to NI Tech Support. Tim Crossing his fingers for a LTS version of LabVIEW

I'm trying to make sure that I'm not out in left field. I've got a SR# with NI Tech support and would like a second opinion while he looks at it. I've narrowed down to the code in the attached VI causing problems for me. The VI will cause LabVIEW to, at best, stop responding (including window updates), or, at worst, go away. By go away I mean it vanished from Task Manager with no message as to why. I didn't see a known issue with LV 2010 SP1 (which is what I'm using) on this. I get proper behavior if I put in a i32 constant or an array of i32s, so it's something about having an array of clusters of the elements I'm using. Switching the boolean to include array size resolves the issue in that I get an error, which would be the behavior I expect. Thanks, Tim Untitled 1.vi

The options I can think of require you to be able to modify the DLL. 1. The DLL could pop-up a progress window with a cancel button. 2. The data is sent to the DLL to calculate and the function call returns immediately. The DLL processes the data in the background and performs a callback when the calculation is finished. Another function call could be used to abort the calculation. Tim

It's trying to get the installer for the serial driver to include in the installer you are building and has nothing to do with the driver being installed on your build PC. It's going to use the serial driver installer as your laptop may not have the files needed for the specific machine you are going to install your application on. Tim

Under the category "Additional Installers", toward the bottom, is NI-Serial. Is NI-Serial checked? This will include the serial drivers with your installation kit. You would have to manually install the serial drivers otherwise. Tim

Did you install the serial drivers with your application? They can be included in the installation, but won't install by default. Tim

It sounds as if you like the NI hardware, but can't invest in learning the software. The RT OS on the PXI systems is Phar Lap ETS (Phar Lap is now owned by IntervalZero). The website for ETS is located here.

I believe the coding reference you are looking for exists with in the LabVIEW examples. The whole solution will not be there, but pieces will be. I think what you've listed is possible, though I'm not entirely clear on what you're doing. You can route signals internally to generate trigger signals, however this is a 1-to-1 mapping. You would have to OR the signals together externally and route the result back in to do what you describe. Tim

Can you convert the existing code to a DLL? There is a KnowledgeBase article here that discusses it. Can you split the system into real-time and not real-time "post processing"? It sounds as if you can since you are considering a SBC/embedded PC option. Tim

Correct. This is expected behaviour, though not necessarily desirable. You'll have to write code to update fonts with panel size. Tim

Look through the examples that ship with LabVIEW for how to perform DAQ and writing a TDM/TDMS file. The examples are not full applications, but are quite good in showing how to do a specific task. Tim

Even when you don't work in a regulated environment it can be a major thing. The equipment we sell warranties for 1-2 and operates for, typically, 5 years before being retooled. Keeping all the versions (and drivers!) we've used handy just in case some customer's equipment is down can eat a lot of space. Tim

You can turn off the UAC and that should allow you to write, but then you're running without the UAC. There is a meathod to request enhanced permissions (not sure if that's the actual name for it) which allows you to temporarily modify the registry, files in Program Files, etc. I'm not sure what's involved, but that's where I got to when I decided it would be easier (and save some of what little sanity I have) to put a flag in the code to switch where values were stored based on XP or Win7. Tim

I was assuming you had written both app_a and app_b. What I was thinking was app_a could send a TCP message to app_b with the port information. This won't work since you aren't developing both sides. Tim

No, I can't. There's a lot of questions you need to research answers to and you've not even gotten to the lense or the lighting. The lighting will (not can, but will) make-or-break the application. You can, as I said, go to NI's website as a starting point. I would recommend talking to your local representative about your specific application. Tim

My initial thought is for app_a to tell app_b that it exists. Tim

I'll have to look at the code sugested when I get a moment, however it seems like this is a network in the software similar to UDP, RS-422 or RS-485 in that everyone has to receive the message, determine if it's addressed to them and act accordingly. Alternatively there could be code acting similar to an Ethernet switch in the middle, which would look at the destination of the address and determine a direction to send it. Tim

The Write is generating the timeout error, so have you checked that the device you are talking to is receiving the message? This could be as simple as it's not plugged in or turned on. Tim