Control references and sequence structures

My supervisor and I were discussing one of his programs, and he asked
me if I knew why he kept getting "Object reference is invalid" on a
property node that was using a reference. I couldn't figure it
out either, and eventually I said to try moving the actual control
itself (on the block diagram), into the first pane of the sequence
structure, and just feed the wire through.
This solved all of our problems... however both of us were
stumped with why what I suggested actually made it work. Anyone
know why this is?
Oops... I just realized that I made this on the breakpoint board
instead of the LabVIEW board...sorry. Although I suppose that the
people who frequent this might be the best to answer this...
Message Edited by Novatron on 07-14-2005 05:24 PM

There should be no difference between the two code versions IF you adhere to proper dataflow.
(Of course it is conceivable that the program is a mess and there is a race condition, e.g. if the reference is initially invalid and you set it elsewhere in the code via e.g. a local variable of the reference. In this case, a subtle change (e.g. the sequence structure) can rearrange the execution order for it to suddenly work by accident.)
I would be very curious to see a working example that demonstrates your described behavior.
LabVIEW Champion . Do more with less code and in less time .

Similar Messages

Labview Crashes when adding case and sequence structures

I am running into a problem that I have never experienced before - when I am adding case and sequence structures to a version of code I am writing, Labview 6i crashes (i.e CPU allocation jumps to 95% on the task manager and hangs there) requiring an "end task". I am writing the code within XP Pro running on a 1.7 Ghz Pentium 4 machine with 512 MB.
The code is used to control valves and temperature controllers on a Noble gas analysis line and is fairly simple. There are multiple nested sequence (30 steps long) and case structures within a while loop. The code itself is around 1.9 MB, so given the speed and on-board memory of my machine I doubt that I am reaching and physical limit in terms of the memory or proce
ssing power required.
Has anyone ever seen something like this? Could the code have been corrupted by an email transfer? If so are there ways to recover? Any help would be greatly appreciated.

Yes. At least to 6.0.2. Also, you might be able to fix the problem by doing a mass recompile of the directory that the vi resides in, this fixed a similar problem I had about a year ago. Just start Labview, but don't open any of the VIs in that program, then select Tools->Advanced->Mass Compile. I am not sure why it worked for me, but it did, I think it cleans up the code a bit.
Jon D
Certified LabVIEW Developer.

Control references and XY graph

hi there,
I was wondering if somebody can help me with passing data to a " XY graph
" not waveform graph [ in a main VI ]
from a sub vI using the concept of a control reference..
p.s: I dont intend to flatten data .
It works fine with waveform graph but there is nothing to show ( even
examples ) me how to do it with XY
graph.
thanks.
ananth

In the example, why is the control reference outside the case statement, since the graph
is only updated when plot=true the ref belongs inside or did I miss something?.
ananth wrote:
> thanks
> and you said it right. that was the problem.
>
> "John Lum" wrote:
> >>>I was wondering if somebody can help me>>with passing data to a " XY
> graph" not>>waveform graph [ in a main VI ] >>from a sub vI using the concept
> of a>>control reference.. >>I don't see any problems here using LabVIEW 6.0,
> and I'm wondering if you're>having trouble with a Variant input or something.>>Here's
> an example of a subVI that spits data into a main VI's XY Graph by>way of
> a control reference>ftp://ftp.ni.com/incoming/xy.zip>>Regards,>John Lum>Na
tional
> Instruments

Updating outputs inside case and sequence structures.

I am having problems creating a control program for a
solenoid that I am working on. (This control program is a small apart of
a much larger program)
There are three states that happen to turn on the solenoid.
1) The high current stage is turned on
2) Both current stages are turned on
3) The high current stage is turned off and the low current stage remains on until
turned off.
There is a state where the solenoid is off, both states turned off.
I made a Labview program that attempts to create these three states, using a
sequence and a case statement. (see attached) You can click on "request open" and see in "global_solenoid_current.vi"
that the switches operate properly and the low current LED does not turn off
until "request closed" is clicked. (I had to use global
variables in order for this bit of code to work in my main program) The global variables
update in the sequence, but they do not update the LED's on the front panel in the properly.
How may I allow these LED's to operate properly?
Again there are many constraints with this piece of code since it is in a
larger control program with an over-all while loop.
-I cannot put a permanent while loop around the solenoid control code since it exists within
another large while loop. If the smaller loop executes then the next iteration
of the main loop never occurs until the smaller loop ends.
-Also, one must be careful not to have one unstoppable sequence since it would repeat in every
iteration of the larger main loop.
-I tried a state machine, but that did not seem to work well. The sequence repeats over and over.
Attachments:
Solenoid_Control.zip ‏15 KB

You need to understand dataflow.
In your program, you only read the globals exactly once/call of the subVI and write the output to the LEDs of the program. Thus the indicators get updated exactly once at an undefined time with repect to the other code.
As a bandaid fix, you could remove the global variable reads and write to locals of the LEDs in the various frames where the LEDs need to change. Also don't do unecessary global reads and writes. For example, if both cases are False, you read a global, then write the just read value back within nanoseconds. This is a completely useless operation if you think about it. Right?
Somehow, the program does not feel right at all, but I would need to see the rest of the code for a final analysis. There has to be a better way to do this!
LabVIEW Champion . Do more with less code and in less time .
Attachments:
Solenoid_ControlMOD.vi ‏35 KB

In-Place Element Structures, References and Pointers, Compiler Optimization, and General Stupidity

[The title of this forum is "Labview Ideas". Although this is NOT a direct suggestion for a change or addition to Labview, it seems appropriate to me to post it in this forum.]
In-Place Element Structures, References and Pointers, Compiler Optimization, and General Stupidity
I'd like to see NI actually start a round-table discussion about VI references, Data Value references, local variables, compiler optimizations, etc. I'm a C programmer; I'm used to pointers. They are simple, functional, and well defined. If you know the data type of an object and have a pointer to it, you have the object. I am used to compilers that optimize without the user having to go to weird lengths to arrange it.
The 'reference' you get when you right click and "Create Reference" on a control or indicator seems to be merely a shorthand read/write version of the Value property that can't be wired into a flow-of-control (like the error wire) and so causes synchronization issues and race conditions. I try not to use local variables.
I use references a lot like C pointers; I pass items to SubVIs using references. But the use of references (as compared to C pointers) is really limited, and the implementation is insconsistent, not factorial in capabilites, and buggy. For instance, why can you pass an array by reference and NOT be able to determine the size of the array EXCEPT by dereferencing it and using the "Size Array" VI? I can even get references for all array elements; but I don't know how many there are...! Since arrays are represented internally in Labview as handles, and consist of basically a C-style pointer to the data, and array sizing information, why is the array handle opaque? Why doesn't the reference include operators to look at the referenced handle without instantiating a copy of the array? Why isn't there a "Size Array From Reference" VI in the library that doesn't instantiate a copy of the array locally, but just looks at the array handle?
Data Value references seem to have been invented solely for the "In-Place Element Structure". Having to write the code to obtain the Data Value Reference before using the In-Place Element Structure simply points out how different a Labview reference is from a C pointer. The Labview help page for Data Value References simply says "Creates a reference to data that you can use to transfer and access the data in a serialized way.". I've had programmers ask me if this means that the data must be accessed sequentially (serially)...!!! What exactly does that mean? For those of use who can read between the lines, it means that Labview obtains a semaphore protecting the data references so that only one thread can modify it at a time. Is that the only reason for Data Value References? To provide something that implements the semaphore???
The In-Place Element Structure talks about minimizing copying of data and compiler optimization. Those kind of optimizations are built in to the compiler in virtually every other language... with no special 'construct' needing to be placed around the code to identify that it can be performed without a local copy. Are you telling me that the Labview compiler is so stupid that it can't identify certain code threads as needing to be single-threaded when optimizing? That the USER has to wrap the code in semaphores before the compiler can figure out it should optimize??? That the compiler cannot implement single threading of parts of the user's code to improve execution efficiency?
Instead of depending on the user base to send in suggestions one-at-a-time it would be nice if NI would actually host discussions aimed at coming up with a coherent and comprehensive way to handle pointers/references/optimization etc. One of the reasons Labview is so scattered is because individual ideas are evaluated and included without any group discussion about the total environment. How about a MODERATED group, available by invitation only (based on NI interactions with users in person, via support, and on the web) to try and get discussions about Labview evolution going?
Based solely on the number of Labview bugs I've encountered and reported, I'd guess this has never been done, with the user community, or within NI itself.....

Here are some articles that can help provide some insights into LabVIEW programming and the LabVIEW compiler. They are both interesting and recommended reading for all intermediate-to-advanced LabVIEW programmers.
NI LabVIEW Compiler: Under the Hood
VI Memory Usage
The second article is a little out-of-date, as it doesn't discuss some of the newer technologies available such as the In-Place Element Structure you were referring to. However, many of the general concepts still apply. Some general notes from your post:
1. I think part of your confusion is that you are trying to use control references and local variables like you would use variables in a C program. This is not a good analogy. Control references are references to user interface controls, and should almost always be used to control the behavior and appearance of those controls, not to store or transmit data like a pointer. LabVIEW is a dataflow language. Data is intended to be stored or transmitted through wires in most cases, not in references. It is admittedly difficult to make this transition for some text-based programmers. Programming efficiently in LabVIEW sometimes requires a different mindset.
2. The LabVIEW compiler, while by no means perfect, is a complicated, feature-rich set of machinery that includes a large and growing set of optimizations. Many of these are described in the first link I posted. This includes optimizations you'd find in many programming environments, such as dead code elimination, inlining, and constant folding. One optimization in particular is called inplaceness, which is where LabVIEW determines when buffers can be reused. Contrary to your statement, the In-Place Element Structure is not always required for this optimization to take place. There are many circumstances (dating back years before the IPE structure) where LabVIEW can determine inplaceness and reuse buffers. The IPE structure simply helps users enforce inplaceness in some situations where it's not clear enough on the diagram for the LabVIEW compiler to make that determination.
The more you learn about programming in LabVIEW, the more you realize that inplaceness itself is the closest analogy to pointers in C, not control references or data references or other such things. Those features have their place, but core, fundamental LabVIEW programming does not require them.
Jarrod S.
National Instruments

How should I set up my VI so that I can use the linear fit coefficient data analysis program, when my values are coming from while loops within a sequence structure?

I'm attempting to create a calibration program, using the printer port, and a Vernier Serial Box by modifying a calibration program designed for the serial box.
There are six calibration points, and to collect them, I have it controlled by while loops so that the numbers are taken when a button is pushed, and this is inside a sequence structure so that I can get the six different points. I feed these numbers into two different arrays (for x and y values) and then try to use the linear coefficient analysis on these points, but the values for the slope and intercepts it returns are not correc
t.
If I cut out the array and coefficient analysis, and feed the same numbers in directly without the while loop and sequence structures, it produces the proper values... I don't know why the numbers it is producing are different, and I'd really like to know.
Thanks,
Karinne.

I would use a data manager sub-vi that would be called by each from of the sequence structure that produced a data point. The data manager sub-vi could auto append new items or could place items in a specific entry of an array. Later on when you want to calculate the linear fit, call the sub-vi to return the array of values.
Stu

Data acquisition with control references

I'm a new LabView user and I would like to acquire data in a subVI and display that data in the main VI. I think that I need to use control references and refnums, but I just haven't been able to figure it out. I would GREATLY appreciate any help I could get.
Thank you!

From your description I would guess that the "subVI" has a loop in it that repeatedly reads the FP hardware, and the indicator is inside the loop. Right?
The thing to do is move a lot of the logic in the subVI up to the Main VI--or add the Main's added logic to the subVI, whichever is easier. In the first case, the subVI would go away, in the second, the subVI would become the Main VI.
If you're confused, post your code in V6.0 format and I'll show you what I mean.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Control references vs. global variables

I guess my question centers on the appropriate application of control references.
I am writing a complex program that has a state machine at the top level, and, for one frame of the state machine, a while loop containing a couple subVIs, each of which contains many subVIs. The lower-level subVIs are affected by buttons on the top-level VI. Information from the lower-level VIs must be shown on the top-level front panel within the loop. My question is: what is the best way to do this?
(I have a previous version of the program that I wrote that keeps just about everything on the top level so that I can update the front panel, but this is not at all modular.
In addition, I considered breaking things up into more than on
e front panel, but this doesn't seem to be a good option for this section of this program.)
Last week I read about control references, and decided that this could be the way to deal with this issue. I have not worked with them before, so I want to know: Are control references an appropriate solution for this issue? Is it good programming practice to use them, especially to update data on charts and graphs? How do they compare programming-wise and efficiency-wise to global variables?
Global variables are another solution, I think, but I would have way too many variables to update. I think the advantage with global variables is that one could just insert a global variable in a subVI and not have to wire it up through the different subVI levels, which one would have to do (I think) with control references.
Can you offer any advice?
Thanks!

Paul,
The actual implementation of the solution is up to you. This is indeed a complex question.
I would offer the following advice:
On globals:
Try to avoid them. I try to restrict the use of globals to unidirectional. If you have ever dealt with a race condition, you will know why. Mistakes are often made with globals, and they are quite apt to become the biggest source of bugs in a program, especially in one as large and/or complex as your appears to be. If you must use globals, try using a shift register, or LabVIEW 2 style global instead. Basically, you use an unitialized shift register with two (or more) cases: Read and Write. This prevents race conditions, but only if the VI is non reentrant. However, implementation is still difficult.
Control References:
I also have read and heard about control references. I have had much use for them, for controlling the appearance of controls and indicators (and decoratiopns too, I guess...). However, I would caution you on using them to pass data around. This violates dataflow in a big way, as you are passing around pointers, instead of data. I believe this is difficult to implement, and even more difficult to keep straight. I personally recommend using them only for attributes of FP components, not for passing data.
So, what do I believe is the most elegant solution? I think a data server is your best bet. This is close to a LabVIEW 2 style global, but a little more active. Simply write all of your data into a subVI in any manner, a queue, a FIFO, LIFO, etc. Then, retrieve the data as desired. Buffering, queuing, etc are all handled by the data storage and retrieval subVI. It becomes sort of a small active database. The two sides (storage and retrieval) are independent of each other, and the code is all handled in the function. A basic version is a LIFO, Last In First Out, wherein the data is overwritten constantly. The data is then read by the reading VI, the front panel VI in your case, at any time, and the data is always the latest. You can add complexity as you need, such as making it a FIFO. This is done by simply writing the data to an array, then reading back the oldest value (by reversing the array and reading index 0.)
I believe this is an elegant solution to your problem. It does maintain dataflow, except that time is taken out of the equation, depending on how you look at it. It simplifies your program because you only need to do three things. Write the data handler, then drop in the function into the VI that writes, and the one that reads. It is also flexible in handling the data.
Good luck, and let us all know how you do.

Getting control references which are in tabs

Hello,
In a labview vi, we can successfully get all the control references, including references to tab controls. We would also like to get at the control references of controls which are contained within the tabs. We've been hunting around the methods/properties of the vi pane references (where we found the controls[]) reference, and can't seem to find how to access the control references within tabs. Does anyone know the method/property to do this?
Thanks
David Jenkinson

The Pages property will return a 1D array of references to each page. Then you can autoindex this to get the controls for each page reference:

Sequence structure and Latch action

Dear Sir or Madam,
I have a sequence with commands in each frame. Is there a way to have a
LATCH ACTION, between frames??.
Thanks in advance for your any help.
Sincerely,
Luis Diaz
[email protected]

I would recomend that you get rid of the sequence structures and use a state
machine. A State machine will give you a much more powerful and flexible
program. Browse the example programs available at the Resource Library of
NI's Developer Zone zone.ni.com). There is even an example called Pause/Resume
& State Machine.
"Kevin B. Kent" wrote:
>Luis Diaz wrote>> Dear Sir or Madam,>>>> I have a sequence with commands
in each frame. Is there a way to have a>> LATCH ACTION, between frames??.>>>>
Thanks in advance for your any help.>>>> Sincerely,>>>> Luis Diaz>> [email protected]>>Not
quite sure what you mean here.>You can pause between each frame, there are
2 ways to do this.>Add a frame AFTER the frame to pau
se>1) put in a timer
(Wait MS) you can hardcode this wait or have>a value that the user can enter.>2)
put in a while loop and have a button to proceed, or use some sort of>logic.>>All
this will do is send the commands and then wait for the timer to expire>or
the loop to end.>>A more elegant approach is to use a state machine. This
is a combination of>a case structure inside of a while loop. You have much
more control over the>>sequence of events and it is much easier to read and
debug.>>Again all this will do is wait between cases (if setup that way)>>Using
the state machine you can have a case return to itself which>is esentially
a LATCH.>>There are samples of the state machine at various locations.>>Let
me know if you need more help> Kevin Kent>

Difference control refnum and control reference

Hi guys.
I am new on labview reference, can you explain difference between control refnum and control reference.
Gary Wang

Are you sure you don't mean "refnum control"? That is a front panel control that can be selected as a reference to any one of several data types such as application, VI (including strictly typed), control or indicator. Whereas the "control reference" is a block diagram object that points to a specific control on your front panel (it can also be "linked" to other objects so it is similar to a "refnum control" in that respect).
“A child of five could understand this. Send someone to fetch a child of five.”
― Groucho Marx

Tethering and Controlling the Shooting Sequence Numbers

This may be a bit much - but I have to ask.
I'm just getting started with Aperture, but one of my reasons for switching from Lightroom was the Tethering abilities of Aperture.
My question is very simple, when shooting tethered where/how can I control the image sequence numbers? The sequence number on my EOS 5D is controlled by the folder it's writing too, and the EOS software lets you specify a starting number- however ...
Aperture is not using the EOS Utility to do the tethering, or is it?
Anyway- if someone can tell me how to control my sequence starting point while shooting tethered, that'd be cool --
thanks-

When I upload photos to My Photo Steam the sequence of the photos is altered. So any shots taken in 'burst' mode will not appear in order - usually the middle shots of the burst sequence are moved to either the beginiing or the end of the seqence. (so, for example, when reviewing a sequence in My Photo Stream - you see a basketball player take a shot before he dribbles towards the basket...)
I wonder, why you are seeing more than one photo of a burst of photos in the PhotoStream at all. According to the "Photo Stream FAQ" only the final selected photo of a burst will upload to the Photo Stream, see:
http://support.apple.com/kb/HT4486
Are all of the photos taken with burst mode or image stabilization on my iPhone 5s saved to My Photo Stream?
No. Only the final photos that you select when using burst mode, and only the final composite image shot with image stabilization are added to My Photo Stream.

Event applied to control references

Hello!
I built a VI that can run on its own or controlled by a superordinated VI. If there are valid references comming into the subordinated Vi these are used exclusivly, otherwise references to the controls of the superordinated VI are used.
So inside my program I exclusivly use references and property nodes to access or change data.
My first question is if you think that is a bad solution concerning the performance of the VI and if you have any improvements?
The next problem is that my VI is quit slow now (there is a while loop checking all the time if there are changes made to the controls (via their references) and acquiring data (using RS232) and updating controls. Thereby I use a 20 frames long sequence inside the loop.
Is that the reason for slow performence?
To speed things up I considered to us an event structure instead of the sequence to check the changes and only to do the acquisition every cycle.
But I don't see a possibility to use the event structure to check events on value changes of controls via their references.
Any idea?
Thank you,
Alexandra

> But I don't see a possibility to use the event structure to check
> events on value changes of controls via their references.
>
With LV7, it is possible to use an event structure on control references
to another panel. As for whether this is the reason for performance
problems, that is hard to say without seeing your application.
First suggestion is to use the profiler. Tools>Advancec>Profile VIs.
It should help you start looking in the right place and run informed
experiments.
Another way of doing this is to send it to [email protected] and let me use it
as part of the VI critique going on at NIWeek. We will keep the names
anonymous and find the best technique we can for the problem you are
trying to solve. This offer goes for anyone with a VI t
hat they'd like
to see NI try to improve upon.
Greg McKaskle

Timing control signal and data acquisition

I have a series of relays which when activated will close different elements of a circuit and I also have a sourcemeter(Keithley) sending a constant source current and reaing the voltage back.(But when no relays are closed the circuit is open and no source current flows )
I have a microcontroller(pgmmed for 9600 baud rate) based hardware circuit which closes different relays sequentially based on the input it recieves from labview pgm passed on through a Rs232 cable(9600/8 bit/no flow control)
So i made a sequence structure of sending signal to microcontroller signal then wait for the signal transmission and realy activation and then read the voltage value form keithley sourcemeter back to labview thro a GPIB cable.
These three events are reapeated sequentially in a while loop.
A schematic picture is attached.
BUt the problem I ma facing is the maximum speed of reading is limited to 200msec/reading even thought the relay activation time is as low as 30 msec.
I tried with many different delay times (140-60 msec...but more or less each reading takes up 200msec irrespective of the delay time..)
What could be the bottle neck is it the Rs232 setting at 9600 baud rate..can changing that to higher baud rate/including flow control solve this problem?
Attachments:
daq_printscreen.GIF ‏45 KB

siva0182 wrote:
Find attached the picture of the vi where I tried to put in timers.one in each of the frame and at the end added one more frame just to measure the time elapsed .
The last frame and the frame with sourcemeter measurment show adifference of about 140 msec.
Is there any way to improve the speed of this portion?
Probably not. It sounds like the Keithly VI is taking 140 msec. You can try opening that up to see if there is anything in there that could be causing an unnecessary slowdown. But trying to tighten it up too much may cause occasional errors (such as timeouts) in trying to get a response back.
But surprisingly I tried displaying the actual timer value at the start and at the start of sourcemeter read function ..but the display of both indicators is almost equal with little difference of only 10 msec.????? I'm not sure which of the several timers you are referring to here. What is the value going into the wait function between the VISA write and the Keithly VI?
When you do benchmarking, the timer functions should be in a frame all by themselves. Having it mixed with another function or VI causes a bit of uncertainty as to when the time was taken. For instance, you dont' really know if the Keithly VI was started before the time was taken or after. (The time was probably taken first, but without a data flow or sequence structure dependency, you can't be sure.)

Check control signal and write in 1s, ignore control signal for the following 2s.

I am new to Labview, recently I use DAQ to receive 2 channels, one is expected signal and another one is control signal. If the control signal is higher than threshold (rising edge), write expected data in 1s. Then, ignore the control signal in 2 second. The process is repeated. The attachment is my program but it doesn't work. I use flat sequence to do 2 consecutive tasks but cannot ignore the control signal.
Any help is appreciate.
Attachments:
Save data with control signal.vi ‏187 KB

siva0182 wrote:
Find attached the picture of the vi where I tried to put in timers.one in each of the frame and at the end added one more frame just to measure the time elapsed .
The last frame and the frame with sourcemeter measurment show adifference of about 140 msec.
Is there any way to improve the speed of this portion?
Probably not. It sounds like the Keithly VI is taking 140 msec. You can try opening that up to see if there is anything in there that could be causing an unnecessary slowdown. But trying to tighten it up too much may cause occasional errors (such as timeouts) in trying to get a response back.
But surprisingly I tried displaying the actual timer value at the start and at the start of sourcemeter read function ..but the display of both indicators is almost equal with little difference of only 10 msec.????? I'm not sure which of the several timers you are referring to here. What is the value going into the wait function between the VISA write and the Keithly VI?
When you do benchmarking, the timer functions should be in a frame all by themselves. Having it mixed with another function or VI causes a bit of uncertainty as to when the time was taken. For instance, you dont' really know if the Keithly VI was started before the time was taken or after. (The time was probably taken first, but without a data flow or sequence structure dependency, you can't be sure.)

Control references and sequence structures

Similar Messages

Maybe you are looking for