LabView 5.0.1F1 SE + DAQPad-1200

Hello,
I recently salvaged a DAQPad-1200 and a copy of LabVIEW 5.0.1F1 SE that my university's EE department were throwing away, and have been attempting to use them on a Windows 2000 computer with the NI-DAQ 6.9.3 drivers. However, whenever I attempt to do any sort of data acquisition functions, the VI reports that the Call Library functions are not supported in the student version. I was under the impression that the student versions were able to interface with the DAQ hardware, and that it was other features that were disabled. Am I simply mistaken, or is there some other error with the software which I would be able to fix? I realize I am asking for help with outdated equipment and software, but any assistance would be greatly appreciated.
sschutta
Solved!
Go to Solution.

Hello sschutta,
Thanks for your post and questions about LabVIEW and DAQ.
I see that you have a DAQPad-1200 that you are using. Is the error that you are seeing referring to a call library function node or dll call? The reason I ask is because this is not a supported feature in the student version and could be the cause of your error. Take a look at the following knowledge base that talks about this error:
Problems with NI-DAQ VIs and LabVIEW Student Edition
Also it looks like the version of LabVIEW that you have is not compatible with the DAQPad 1200. See the link below for a supported list of devices:
Which DAQ Boards are Supported when Using the LabVIEW Student Edition?
Let me know if this clears up your questions or concerns about using your DAQ device! Also do you need to speak to someone about getting some new equipment for your university? Let us know and have a great day sschutta.
Cheers!
Corby_B
http://www.ni.com/support

Similar Messages

Can I run a DAQpad-1200 directly from linux?

I'd like to run the DAQpad-1200 directly, ie not through labview, from linux. Is there a driver, or can I get the parallel port interface spec and address the parallel port directly?

You would need the register level programming manual for this device, and I don't believe that one exists.
Regards,
Erin

LabVIEW 5.0.1f1 installed on Windows 2000

I'm transferring LABView 5.01f1 programs from a W95 computer to a W2000 computer. I set all the software directories the same on both computers. When I open a .vi on the W2000 computer it had to search for many of the sub .vi's. I had to go thru all the .vi's and find all the sub vi's then resave them. That was a hassle and I wondered if there was an easier way to go about this but since it worked I wasn't too concerned until another user logged on the computer(Novell Network) then when a vi was opened it needed to search for sub vi's again. Does anyone have a solution? I thought that the vi path's were saved in the vi itself.
Thanks,
[email protected]

I believe that this knowledgebase answers your question exactly.
Hope this points you in the right direction!
E. Sulzer
Applications Engineer
National Instruments

I get an 10403 error on daqpad-1200 for analog inputs

OS: WIN2K
NI DAQ 6.9.3
also loaded LV6Eng.exe
I know there are analog inputs.
All other ports work.
Why don't these work?
Anything I should be looking for?

Shawn,
Are you receiving the following error:
"The device is not responding to the first IRQ level"
If so, you should examine the Verify the Interrupt Request (IRQ) Setting section in the following troubleshooting resource:
Parallel Port DAQ Device Troubleshooting in Windows 2000
Spencer S.

Using a DAQCard-1200 on Windows XP w/ LabView 8.0

I'm attempting to connect a Windows XP equipped laptop running LabView 8.0 with a DAQCard-1200. I originally gathered data from an experiment from an older computer running LabView 6, and so I copied the vi over to the new system. Originally I was missing some subVIs from the DAQ folder. Now I've copied files from the older version that it was missing (AI acquire waveforms, 1easyio.lbb, files of that nature) into the new folder DAQmx. These files create the error message "... is not executable". I've read some stuff of the discussion boards that it seems to me that DAQ isn't the same as DAQmx, but I'm not sure why. As soon as I fix this problem, I'm also having difficulty installing the new 6.9.3 driver for the DAQCard-1200 because theres a newer version installed. I found the discussion board topic about how to uninstall newer versions through the control panel and I did that, but that's actually when the problems started happening with non-executable vi's.
Any help would be appreciated.
Mike

Hi Mike,
You are correct that Traditional NI-DAQ and DAQmx are different. Before setting up a system you need to determine which one is right for you. You can check here to see the most recent version(s) of the driver which are compatable with your hardware. The DAQCard-1200 is not supported by DAQmx, and the most recent version of Traditional DAQ which is compatable is NI-DAQ 6.9.3.
The second thing to take into consideration is software compatibility. You must check to see what LabVIEW versions are compatable with DAQmx 6.9.3. This information is provided to you in a Knowledge Base. Traditional NI-DAQ was designed for use in LabVIEW 6.1. It will also install to earlier versions back until LabVIEW 5.0.1. Although it is not recommended, it is possible to use DAQ 6.9.3 with LabVIEW 8.0. The procedure for getting this to work is outlined in Using Older Versions of NI-DAQ (6.9.3) with LabVIEW 7.x or 8.x.
After installing the correct version of the driver, you can try opening and running your VI. There may be some minor modifications required to get the application to run in LabVIEW 8.0. Do not copy DAQ or DAQmx VIs between computers. It is likely that this can cause difficulty in communicating with your device due to incompatibilities (i.e a newer VI may not be compatable with your DAQCard-1200). If you find that you are still unable to run your VI after following the above suggestions, post back with the problem you are having for further guidance. If possible, it would be recommended to upgrade your hardware and begin working with DAQmx to ensure the best possible support with your application.
Hope this helps,
Jennifer O.
Applications Engineer
National Instruments

LabVIEW can communicate to SIEMENS PLC S7 1200 through Profinet TCP

Dear All,
I could to establish a TCP connection between LabVIEW and the CPU 1215 through Profinet.
I had a problem in LabVIEW side, but by adding a block, the problem was solved.
Regards,
Ras

Hi Pragnesh,
As I mentioned in my old post above, this question should be posted in the Industrial Communications board where the relevant NI specialists are, so you'll have better chance of a good answer.
Having said that, I'll try to help a bit from what I know (improving on my old post ). Profinet requires deterministic timing and onboard CPU to run the protocol (see this post), hence we need a Profinet board and cannot simply use ethernet port to communicate in Profinet networks.
The kind of board you need depends on how you define interfacing with the S7-1200 controller:
- Case 1: A device programmed by LabVIEW acting as Profinet slave for the S7-1200
NI has CompactRIO Profinet Slave module which you can use in this case.
- Case 2: A LabVIEW-programmable board replacing the S7-1200 as Profinet IO Controller
Comsoft offers a Profinet IO Controller for this kind of case. You can contact them for more information on it.
- Case 3: LabVIEW in a programming device (laptop, etc) communicate directly to S7-1200 via Profinet
I don't think this is possible. There is a reference example for this but only for S7-300. Even then it was achieved by observing the protocol, not from an official reference.
Hope this helps.
-Yodha-

DAQPad1200 and LabVIEW 3

Hello
Really I have problem with my DAQ 1200. I have a Lab program on Labview 3 which works with DAQ 1200 parallel port. The PC is an old one with HD 500 MB and OS win 3.1
Now I have to use this system (Labview, DAQ 1200 parallel port) in new PC with new OS (does not matter which one 2000 or XP). I succeed to run Labview 3 in XP, put DAQ 1200 is still unknown by XP. Every time when I run my laboratory program in Labview there is error ((the DAQ device is unknown or the driver does not support it)).
Please can somebody tell me what I should do, or the best solution to make DAQ 1200 parallel port work with new OS and continue working with my Labview 3. I tried with win 2000, but by add new hardware I do not found DAQ 1200 to install it and by XP the same problem.
Thanks a lot

Wow, talk about trying to work with stone knives and bearskins.
Lab1994 wrote:
I succeed to run Labview 3 in XP,
Now that's just impressive. A little scary too.
put DAQ 1200 is still unknown by XP. Every time when I run my laboratory program in Labview there is error ((the DAQ device is unknown or the driver does not support it)).
Please can somebody tell me what I should do, or the best solution to make DAQ 1200 parallel port work with new OS and continue working with my Labview 3. I tried with win 2000, but by add new hardware I do not found DAQ 1200 to install it and by XP the same problem.
The only thing I can suggest is to look over this article: DAQPad-1200 (Parallel Port) Installation under Windows XP.
You may want to consider whether it's really worth all this effort, as it may be cheaper for you to just get a modern USB DAQ device with a current version of LabVIEW.

Data aquisition from spectrophotometer in two analog channels, X-Y plot

Dear colleagues!
I am new to LabView and I am only starting to learn the system (I have never been a programmer, I'm a chemist to be precise).
I have before me a task to interface an old analog scanning spectrophotometer to PC via LabView.
It has two output analog channels: one is wavelength (two ranges, currenlty let it be 190 to 390 nm; it reads on multimeter as 0.19-0.39 V range) and another one is absorbance (0-1V range). An UV spectrum sholud be an X-Y graph wherein X is wavelength and Y is absorbance.
I am able to read one channel OR another. I am able to read BOTH channels simultaneously, but how can I plot them AGAINST each other, not against TIME?
I am using DAQPad-1200 (LPT interface) and LabView 6.1 (that's why I am unable to read most of the VI's posted on the forum ).
Is such an interfacing even possible given my software and hardware limitations???
Thank you all in advance!

Thanks a lot, johnsold!
I am now able to get something which looks like an UV spectrum! %)
1. I will post an image (later); however, my primary objective is to get two columns of numbers, not necessary to see an X-Y graph onscreen.
2. Without inserting arrays like I did LV always tells about error connecting this data line from two channels to save "2-D data to file" option telling me that input is 1D!
3. I have a manual for the device, it has all of the schematics. I am no electrician though. I will post scanned circuit diagrams then when I manage to scan them.
Now I see two more opportunities to control the device.
A. There is a circuit (+12V DC) on the rear of one of the modlues, which, if shorted for at least 500 milliseconds (according to Tracor manual) can initialize automatic scan. How can this be done using Labview and DAQ device? My first guess is to use an analog output and some kind of a relay, either electromagentic or semiconductor one. Is there any other possibility?
B. In my code I am always asked to write to a file after I initialize the sequence. Can this be done AFTER the sequence is finished?
C. Finally, is it possible to automatically stop the While loop when the number generated by shift register becomes equal to 190?
Here are attached a new code and a sample of data.
Attachments:
Tracor970A-v1.0.vi ‏53 KB
UV-test-01.txt ‏15 KB

LV printing problem

I used Report Generation to implement printing of front panel. Everything is nice. Then I built a appalication and tested the printing function on a computer without installing LV6.02. I got the following error:
failure: image.cpp, line 11472
in LabVIEW 6.0.2.
But if I install the LV6.02, everything will be nice.
It seems that the "Crimal" is Runtime engine.
How can I do?
For most of my usesrs, the LV is not sure to be installed.
I installed Runtime engine 6.02. The OS is Win95/98.

The 1200 family cards have some special properties different from the common E serials. It was ignored.
The following is the reason that causes the problem.
Unlike other boards in differential mode, for the 1200 family of data acquisition boards (DAQCard-1200, PCI-1200, Lab-PC-1200, DAQPad-1200, and Lab-PC-1200AI) the channels names of the four differential channels are 0, 2, 4, and 6 as opposed to 0, 1, 2, and 3. So, in your scan list you have to specify (in descending order) "6, 4, 2, 0" for your four differential channels.
The patch is available in the ftp://ftp.natinst.com under the name Biobench12P.exe.

Bug? Right-click on Front Panel causes selection rectangle!

Originally posted on LAVA: http://lavag.org/topic/12097-right-click-on-front-panel-causes-selection-rectangle/. This post contains an updated description of the problem.
Anytime I right-click on a control on the FP, and dismiss the context menu, I get a selection rectangle. If I don't catch it, moving outside the bounds of the FP will cause the FP to scroll to continue my unwanted "selection". So far this has been repeatable every time.
I noticed that the problem doesn't occur on the Controls pallette, only the context menu for controls. Also, if I mouse over the context menu before dismissing it, the problem doesn't occur. If I select an item from the context menu (which also dismisses it), the problem doesn't occur.
I am running LabVIEW 8.6.1f1 on Windows XP Home SP3.
-Ian
Solved!
Go to Solution.

I once worked in a lab which contained a transformer with its incessant 120 Hz hum. Just when I could tune it out someone would say "What's that hum?" and then it would annoy me again. Similar story in a different lab which had a cooling water drain. Just when I get used to the sound, someone would bring it up.
This behavior has p#$#ed me of on numerous occasions and I am mostly used to it by now. At home I use a track ball mouse which covers a lot of real estate in a hurry so of course I am often scrolling a FP into never-never land. Now you bring it up and I am having flashbacks... (Thanks really, it is time to get this fixed)
I have learned to spot the little circle in the crosshair cursor. When it is missing, you are in selection mode.

Parallel Port Not Assigned

Changed my LapTop with ME to another one with XP. While trying to configure my DAQPad 1200, MAX 2.2 shows no options on the parallel port other than "Not Assigned". I have an older Lap also with XP and I could install the DAQPad. Both computers are TOSHIBA, Satellite. Is there a driver with corrected bugs for XP? Thanks for the help

Refer to the previous post linked below:
DAQPad-1200 parallel port not assigned

More XControl questions / issues

XControl 1, X1, has two other XControls, X2 and X3, on its
block diagram
When I open a VI with X1 on it, the Init ability is called
for X2 and X3 three times each. X1’s
Init ability is called one time. (The
other VIs you see pop up are called from X2 and X3 as a result of Init
executing, so they illustrate the Init calls.
They close when Uninit is called, and you can see as much when you close
the VI and project)
When I close said VI, the Uninit ability is called for X1
and called twice for X2 and X3. This, of
course, leaves one instance of X2 and X3 left open. Consequently, references and VI’s I opened as
a result of the Init call are left open (you notice the two subvi's still open).
Once I close the project, the Uninit abilities are called
for X2 and X3, closing the remaining resources.
There is a file in the folder called log.txt I write to in
the init and Uninit abilities for each XControl. If you open it after each step you can see
what I’m talking about.
Additional things:
After I close the VI, but not the project, X2 and X3 are of course
locked. When I right click “Unlock this
library for Editing”, LabVIEW crashes with a .cpp error. http://forums.ni.com/t5/LabVIEW/Error-when-I-Unlock-Library-for-Editing-with-XControl/m-p/1009044#M4...
My real project loads the XControls (and executes the Init ability) as soon as it opens for
some reason, and makes it nearly impossible to edit them unless I close and open the
XControls individually, due to the .cpp error above.
Questions
Is it expected that an XControl an another XControl should be called more than once?
Why don't they get unloaded when the main XControl is closed and unloaded?
Why the .cpp error?
Tim Elsey
LabVIEW 2010, 2012
Certified LabVIEW Architect
Attachments:
XControl Forum Test source.zip ‏165 KB
XControl demo video.zip ‏3598 KB

Hello elset191
Here is the Corrective Action Request that references your issue. I have included you as a customer whom this problem is affecting.
Request #: 302463
Description: XControls remain open after corresponding VI is closed and crash occurs, XControl cpp error in LabVIEW 8.6.1f1 (Fatal Internal Error: "ThEvent.cpp", line 184)
I'm sorry that this has been a frustration to you. The fastest way to resolve this issue appears to upgrade. Have you attempted to reproduce this error in LabVIEW 2010 SP1? I was unable to reproduce this situation in LabVIEW 2010 SP1.
The CPP error is due to some issue with how this has been internally developed. It appears to have been resolved in LabVIEW 2010 SP1 as do the other issues you have been dealing with. Can you please confirm this for me? I am happy to further address this issue to ensure your success. All the best!
P.S. I have provided a link to the LabVIEW 8.6 Help simply for competeness.
Editing XControls that are in Use
http://zone.ni.com/reference/en-XX/help/371361E-01/lvhowto/editing_xcontrols_in_use/
Sincerely,
Greg S.

Why replay history data from NI-DAQ buffer?

LabVIEW 8.6.1f1, NI-DAQ 8.8, Win Vista, two cDAQ chassis. (I can't move to LV09 or LV10 for this, not yet anyway).
I have a client with two cDAQ banks, each with 16 TC channels (on 4 modules) and 16 voltage channels (on 1 module), 64 channels all told.
The config operation is like this:
This is called twice, with TC CHANNELS and V CHANNELS describing the channel arrangement. Both channel descriptors are the same except for device number. The Sample rate works out to 1000 / 100 = 10 Hz. I am using CONTINUOUS SAMPLES, with no need for a buffer, but I understand that one is created anyway.
One loop of my main program is waiting on the READ function:
You can see the explanation of why the loops are there.
After reading the data (at 10 Hz), each frame is sent via UDP to somewhere, and every 5th frame is displayed, via another loop.
This program runs 24/7 on the same computer as another program.
All this works fine in normal circumstances.
However, occasionally, a weirdness creeps in:
In the mornings, after waking the screensaver (or the CPU itself, I'm not sure), we sometimes (not every time) get a very rapid display - the displays are changing much faster than the expected 2 Hz.
I've been wondering whether the data shown was historical, or simply faster updates of live data.
Today, it so happened that a blower was turned on just before waking the computer. The device takes 15 seconds to ramp from zero up to operating pressure normally, and then it stays there.
The readings on screen were frozen (unchanging). When the computer was awakened, what my client saw was the reading for the blower pressure ramp from zero to running pressure in 2-3 seconds, stay there for 2-3 seconds, drop quickly to zero for 4-5 seconds, and start the ramp again.
Over and over and over it replayed this data, way faster than 2 Hz. At least 40 times it replayed this same data, while the real pressure was just variations around the operating pressure. As time went on, instead of dropping to zero, it would drop to some point on the ramp up and repeat from there.
I don't know if it would eventually straighten itself out - the client gives up and restarts the program. All is well after that.
I've gone over my code several times, and I can't see a mechanism for me to store this data and re-play it.
Here's my best guess as to what's happening:
Since I am not explicitly setting the buffer size, it defaults to 1000 samples.
Since I'm running at 10 Hz, 1000 samples = 100 sec.
At some point, because of the screensaver, or because of CPU sleepage, or because of integer rollover, or because of zombie infiltration during the night, NI-DAQ has become confused.
When the mouse was wiggled, the gates were opened. After that, whenever I ask for a sample, it gives me one, without regard to read/write position. It continually gives me the next sample from the buffer and wraps around, again and again, and again, as fast as I can read / process / display.
It is also putting new data into the buffer, so that the historical data eventually gets wiped out.
That fits the facts:
  It shows only recent (last 100 sec) data, not ancient data, and not live data too fast, as I had considered.
  The data changes with time - oldest data gets wiped out.
  It plays the SAME data over and over and over.
But that means a bug in NI-DAQ, I think.
QUESTIONS:
Any flaws in my thinking?
Any previous sightings of this symptom?
Any ideas for workarounds?
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

The rapidly changing data, is that on the viewing machine or on a display on the device acquiring the data?
The "device acquiring the data" is a pair of cDAQ chassis. There is no display there. It's the LabVIEW program that is reading and displaying the data.
Does your computer go into any sort of power saving mode where the USB controllers are disabled during hibernation/standby?
on MY machine, I have tried this with CPU sleepage and such. Didn't know you could sleep the USB, but on MY machine, that's disabled.
But I haven't made it happen on MY machine.
My CLIENT's machine is actually running XP, and is set to turn off monitor NEVER, turn off hard disk NEVER, and system standby NEVER.
What version of DAQmx do you have installed?
On MY machine, it's 8.8 - I haven't found out from my client yet what his is, but it won't be far away from what came with LV 8.6.
Can you post your code?
Well, OK:
Here's two of the loops running (the third loop deals with TCP/UDP and is not relevant, I think).
The TCM DAQ manager 's READ function is pictured in the original post.
Here we wait on a sample, scale it (volts into EU), and feed it to the PROCESS TCM DATA vi (which does averaging).
Here's the NEW DATA function for PROCESS TCM DATA:
The ST (short-term) HISTORY is set up as an N channel by 5-sample array, and ST HISTORY SAMPLES is set to 5.
The DAQ loop, after processing this data, triggers a DISPLAY event, which triggers a DISPLAY action, which lands here:
The GET DISPLAY function retrieves the latest averages:
That data (64 channels worth) is split into two banks and displayed:
The display process simply distributes the array data into clusters (channels can be user-configured to be in various locations on the screen):
The UPDATE TIP action causes a TIP STRIP string to be updated:
The TIP STRIP shows the average and min and max values (which might be hidden from the display itself), based on which display cell the mouse is in.
A MOUSE ENTER event on any display cell sets the CLUSTER CONTAINING MOUSE variable to the CTL REF of the event, a MOUSE LEAVE event for the overall display bank (containing 32 cells) sets the CLUSTER CONTAINING MOUSE variable to Not-A-RefNum.
the DISPLAY looks like this (only a few cells shown). The display for this program occupies an entire 1680x1050 LCD display, another program runs on the main monitor.
As you can see, the only storage in this process is the AVERAGER, and that is limited to 5 samples (0.5 sec). It cannot store any more than that.
I've thought about the possibility of the mouse oscillating between two cells (as mice are sometimes known to do) when it is parked, and causing a flood of MOUSE ENTER events.
But 1) it happens more often than the odds would dictate (a random location is not likely to be on a cell border), and
2) When that cleared up, the queue would be processed, but it would display CURRENT data more rapidly than 2 Hz. NOT historical data.
Given that it seems to be about 100 sec of history (judging by my client's recap of what he saw, and how it operates), that points to the 1000-sample buffer within NI-DAQ. That's the only place that I see to store that data.
I'll admit that I'm not watching the ERROR output from the NIDAQ READ function. Perhaps I should.
The only scenario I can come up with is that NI-DAQ's READ pointer is confused.
When I ask for a sample it tells me that there is ONE and only ONE available. So I deal with it.
When I ask again, it tells me the same thing.
When I ask again, it tells me the same thing.
It goes round and round the READ buffer. At the same time, new data is coming in, replacing the oldest stuff.
But it (apparently) never gets back to the "normal" condition, where it WAITS on a sample at the RAD function.
Nobody has waited long enough to see if it would do that eventually, after a few minutes (50+ replays), they give up and restart.
Restarting the program resets the cDAQ drivers, among other things, so the problem goes away.
If there's another scenario to cause these symptoms, I'm all ears. But I cannot think of it.
If it was a USB SLEEP problem, I wouldn't think the data would replay from BEFORE the wake-up. But that's what happened.
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

Edit Palette Set disabled?

recently lost my hard drive so just reinstalled LabVIEW 8.6.1f1 and 9.0f3
now (and this is in both 8.6 and 2009) when I right click the Function palette and Control palette open on the Express; for years I have been opening to Functions to Programming and Control to Modern. But I cannot change it - going to Advanced > Edit Palette Set opens the dialog, shows Current Palette Set is Local Host, but the 2 palette sets are un-editable and the View button is greyed out. is there some priveledge that I need to set? Seems I've done this before (way back when) what's changed?
thanx
lmd2
Lawrence M. David Jr.
Certified LabVIEW Architect
cell: 516.819.9711
http://www.aleconsultants.com
[email protected]
Solved!
Go to Solution.

lmd2,
I think what you may be wanting to do you'll find by first pinning a palette
Then select view to either change the standard view or visible categories.
Hope this is what you were looking for.
James

Why does this extra REG EVENTS cause memory leak?

LabVIEW 8.6.1f1, Win XP/Vista
My client reported a memory leak in a particular section of my code - my own tests confirmed it.
Although I have found it and eliminated it, I still don't understand what's really happening.
The RTEC RECEIVER CONTROLLER vi produces a cluster with various (maybe 30) event refnums in it.
For this particular piece of code, I am only interested in 5 of those events.
I was experimenting with registering the cluster as a whole (it works), and I inadvertently left the 2nd REGISTER EVENTS function in place.
So there are TWO event registration refnums, but only one of them is being used.
As the program proceeds, more and more memory is being consumed by LabVIEW (as reported by Windows Resource Monitor). Leaving the program with this particular window running overnight would use up a gig or RAM.
I verified that nothing else was consuming it - disabling the actual data handling did not fix the problem - eliminating this extra registration did fix it.
So my question is - why?
The registration only happens once, and then there are a million events or more in a 12-hour period.
I can guess that the registration creates some sort of queue within LabVIEW for the events to reside in. With no EVENT structure tied to that refnum to consume the events, that queue expands forever.
Is that a reasonable guess, or is there something I am missing?
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

CoastalMaineBird wrote:
I can guess that the registration creates some sort of queue within LabVIEW for the events to reside in. With no EVENT structure tied to that refnum to consume the events, that queue expands forever.
Is that a reasonable guess, or is there something I am missing?
Yes, it's a very reasonable guess and is most likely what's happening.
You might say "LabVIEW could see I'm not actually doing anything with the reference and could therefore optimize the code by ignoring it (which is something LV does in some other cases)", but I'm assuming this is a corner case whoever wrote the original code did not think about, because this could be implemented only in a case where the node neither outputs a reference nor gets one as an input.
Try to take over the world!

LabView 5.0.1F1 SE + DAQPad-1200

Similar Messages

Maybe you are looking for