How do uninitialized shift registers work in reentrant VI's

If I am using what NI calls "Functional Global Variables" (see link) where you use an unitialized shift register in a "one shot" while loop, what happens to the functionality of the shift register if the VI is reentrant?
http://zone.ni.com/reference/en-XX/help/371361A-01/lvconcepts/suggestions_for_exec/
Solved!
Go to Solution.

I was tempted to say that they work as expected, but you have already said that you don't know what to expect.
A reentrant VI is one that has its own dataspace. That means that if I have two of them, they each have their own data and know nothing about each other. This is great for VIs that need to save state for some reason. Some examples of this are moving averages or some filters. They need to know values from the last time they were called in order to calculate the answer for this time and they need to keep track of this answer for use in calculations next time they are called. If these VIs had a single dataspace but were called in several places, their data from last run could be the data from the other call and therefore not be correct.
This is where reentrancy comes in. You merely make this VI reentrant and it saves state correctly because now each call has its own dataspace and therefore its own data.
Functional Globals work on the opposite principle. You want to mix the data from one call location with the data from another. You want to have it save state from this time and use that data reguardless of the caller the next time it is run. You cannot make Functional Globals into reentrant VIs.
I hope that this helped.
Bob Young
Bob Young - Test Engineer - Lapsed Certified LabVIEW Developer
DISTek Integration, Inc. - NI Alliance Member
mailto:[email protected]

Similar Messages

Static Shift registers

My understanding of shift registers is that if you don't initiaze them
then they will hold the value from the last instance, hence be static.
I've created a subvi and placed multiple copies in a case statement,
all it does is check to see if the value has changed, yet when it runs
the second time it starts out at zero when it should be whatever
number went through the sub the last time.
Am I missing something here?
Bundle to byte array contains single to byte array sub vi
Ron
Attachments:
Bundle to Byte array w change.vi ‏29 KB
Single to Byte array w change.vi ‏10 KB

You should always consider initializing shift registers. Keep in mind that if you just opened a VI that contains uninitialized shift registers, it won't remember the data from the last time it was run (because it has been unloaded from memory since then), so it's more likely the values in that shift register are garbage. That could be even more dangerous, since how LabVIEW interprets that data could cause very strange and erratic behavior in your application.
Here's my solution that works for Functional Globals and general shift registers: Consider initializing them the first time the VI is called inside the While Loop, as demonstrated below:
The First Call VI outputs a true the first time that instance of it is called, and false every other time. For Functional Globals you could alternatively have a dedicated Initialize case to perform this function. The advantage of the technique listed above is that you are guaranteed initialization on the first call, regardless of whether the client programmer remembers to call an initialization case.
Message Edited by Jarrod S. on 04-11-200612:33 PM
Message Edited by Jarrod S. on 04-11-2006 12:33 PM
Jarrod S.
National Instruments
Attachments:
Pic1.jpg ‏7 KB
Pic2.jpg ‏14 KB

Whether its really bad to set uninitialized shift register

Hello Everyone!
Just two short and probably dummy questions, hoping u would pls answer it and thx very much!
1. Is it really not good to set a shift register without initialization? What will be the result? Since I read fr many books and they all said it is better to initialize shift register whenever u set one.
2. Is there any case that we need the uninitialized shift register?
Best regards!
Solved!
Go to Solution.

sophiey wrote:
Since I read fr many books and they all said it is better to initialize shift register whenever u set one.
What kind of books are you reading???
The decision to initialize or not, depends on the desired functionality. There is no global "better" at all. It depends what you want to do.
Uninitialized shift registers (or globally initialized feedback nodes) provide the core functionality of action engines. One of the most useful programming tools. Get familiar with it and your skills will increase dramatically!
LabVIEW Champion . Do more with less code and in less time .

How to generate pseudo random noise(PRN) binary sequence using shift registers?

what is the block diagram to generate pseudo random noise (PRN) binary sequence of 1's and 0's using shift registers
please help
i need 2 submit this project in this week

This is a fairly simple homework problem. My hints (on the LabVIEW side):
1- look at while loops
2- look at shift registers on while loops with multiple input elements
3-look at the logic components, AND, OR XOR
Look at this wiki article: http://en.wikipedia.org/wiki/Linear_feedback_shift_register
Do the work, you won't learn if someone shows you how it is done! The palette that the previous post points to are of PRN and other "noise generators" but I suspect that is not what you are after.
Know that creating a PRN with a reasonable number of shift register taps produces very pseudo results, as the "random" pattern begins to repeat pretty quickly, thereby making it not a truly random number.
When you have an attempt that is sort of working and want additional suggestions, post the code here. We won't do your work, we will help you try to do it, and learn it, yourself.
Putnam
Certified LabVIEW Developer
Senior Test Engineer
Currently using LV 6.1-LabVIEW 2012, RT8.5
LabVIEW Champion

Shift Registers not working properly with counter group .vi

Because I'm not sure how to refer to them as a group.
Well, because my previous vi only let my DAQ(STC) model no. 6020E read on one channel, I switched to a new set of .vis. They solved my channel problem, but in exchange, they introduced a set of new ones.
First, when the .vi runs without shift registers(used a function generator for testing), the count ascends at a steady linear rate. That means with shift registers, I should be getting a horizontal line or close to it, right? For some reason, instead of a horizontal line, I instead get a zigzaging line that steadily ascends the amount its supposed to.
Sometimes, the count just zigzags up in down from 4 mill to 0 and back again for reasons I do not comprehend.
I'll upload my new .vi and my old .vi.
Screenshots too
http://imageshack.us/g/192/shiftregisterproblem.png/
http://imageshack.us/photo/my-images/560/idontevenp.png/
Attachments:
Pulse Counter attempt mkIII.vi ‏96 KB
Pulse Counter attempt mkII.vi ‏43 KB

Ok, here are the pictures and one of the vis uploaded .
Attachments:
idontevenp.png ‏238 KB
shiftregisterproblem.png ‏223 KB
daq-stc.llb ‏1736 KB

TS4225 I have just shifted to iOS 7 but i believe i lost the audio output through the earphone terminal. How do I make it work again?

How do I make it work again? I tried with the apple earphones provided and the stereo jack in my car, both didn't seem to work. The thing is, if functioning normally, after I insert the earphone jack in the terminal, the sound from the speaker should disappear and be rerouted to the earphones, this didn't happen.
Shall I reset my iphone?

it's not ios7 it's not software it's a hardware issue
it's this
https://discussions.apple.com/thread/1343532
just the opposite where rather then the switch being stuck in one way it's stuck in the other
more hits
https://www.google.dk/search#q=iphone+stuck+in+headphone+mode

Want to learn more about shift registers and formula nodes

I am new to Labview and have looked at the example files and help files regarding shift registers and formula nodes. I was hoping that someone has a simple and detailed VI expaining how each of them(shift registers and formula nodes) works.

Formula nodes are not one of the first things you will need to be looking at. look at the help files (press ctrl-H) for some syntax examples. Shift registers are easy: they carry the value from the end of the loop back into the start of the loop. The great power of shift registers is to use them without initializing. In that case they will retain their last value as long as the vi is in memory. This is a little more advanced topic, though.
I included a simple example that illustrates what a shift register does. Requires Labview 7.1
Good luck,
aartjan
Attachments:
shift (LV7.1).vi ‏19 KB

Better method than using a large number of shift registers?

I'm trying to work with example code provided free by stanford research systems (http://www.srsys.com/downloads/soft.htm).
Their example software alows the user to run an analog scan across 100 masses (the x axis) which progressively produces a graph of all the data. It repeats scanning (and updating the graph)until the user hits stop.
My goal is to find a way to make the program display the graph of the last scan while it is displaying the current scan (this way it is possible to compare the graphs and see how they change). But as best I can tell the data is generated and plotted in a while loop piece by piece so the best thing my labview inept mind has managed so far is using a large nu
mber of shift registers and graphing the points as they generated along with points that were generated 10 cycles ago in a different color.
So I hope to either find a good way to use shift registers to get values from over 100 cycles ago (which doesn't really seem to work unless i just make space for over 100 little arrows in my loop) or to find a better approach to the whole mess.
The example does not seem to use XY plot and to tell the truth I don't know exactly what its using to plot.
Can anyone offer any guidance or at least understand my question enough to point me in the right direction.
I'm including the stock example and my adaptation to it but if you need to use the included sub vi's the package is on that SRS webpage I listed above (look under RGA).
I suppose this may all be too much to ask but I can dream can't I?
Attachments:
original.vi ‏87 KB
changed.vi ‏92 KB

I certainly agree that the DAQ programming is the part leaving me most confused. I'll attach the package that I am trying to modify, the trouble is there are so many sub vis involved in actually acquiring the data that I am not entirely sure what format the data comes out in.
Perhaps to someone more skilled than I am with lab view the inner workings of this package would be clearer. If you are up for it then look at SRSRGAa simple analog.vi in SRSRGA61.lib and you can see what I'm working with.
I'll also attach my attempt to modify the code to make it work like altenbachs example... however somehow it would seem my timing/synchronization is off. Hope some of this makes sense, I'll see what luck I can have with get w
aveform components, I suppose I have been approaching this so far as if my DAQ was just giving me data points as opposed to a waveform.
Attachments:
rga_lv_61.zip ‏2132 KB
graph_app.1.vi ‏101 KB

Capture Last ten Shots (Shift Registers)?

Situation: -
I am continuously acquiring data on 4 channels of the DAQ card using conditional triggering. Each loop captures 2000 samples, which are stored in 2-D waveform arrays containing each scan of each channel. The data is continually updated on a waveform graph for the user to monitor. After a period of "test time" or when you press a button, the loop will end and the last loop of waveform data gets passed to the analysis VI where all the calcs are performed (I only perform calcs/analysis on static data once test time has completed).
Problem: -
I now want to average the last 5-10 points prior to the while loop ending (as the injection needle will jump around slightly shot to shot). I can enable indexing on the while loop and then select the points I require afterwards (i.e. the last 5-10 or whatever), but this takes up a hell of alot of memory and the processor starts caching to disk too often. Can you imagine just how many points are stored in memory (2000 samples/channel, 4 channels per scan, sampling at 80KHz, for 10mins).
There is no need to store all these points. Each time the loop iterates, the buffer is cleared so the program runs quickly and smoothly. All I need to do is store the last 5-10 waveform array's and pass these on to the next VI, not the whole XXXXXX amount of arrays/point.
I may try and use a sequence, so that the first sequence uses disable indexing and ends after the "Test time" has elapsed. This then continues into the next sequence and proceeds to capture a further 5-10 shots with indexing enabled, before passing to analysis VI. This still doesn't really capture the last 5-10 iterations, it captures the next 5-10 iterations, but it would do.
Ideally, I want the while loop to execute with indexing disabled, and at a certain point in time (comparing the "Test Time" with the "sample rate"), the while loop changes to 'indexing enabled' which will build up an array of waveform data until the loop ends (about 5-10 iterations later).
Any Ideas. If you've got time on your hands..........

You can use a shift register. This will just maintain the last "n" amounts of data sets. I've attached a really simple example to illustrate this.
This may work for you needs however there is an issue that the shift registers are in essence being used the whole time so you will have more memory interaction than you may want ... which depending on your performance requirements may not be desirable.
If that is the case then it may be best to slightly modifiy the approach you're using. Indexing continually instead of in the main loop. Set up a condition/case upon which within the main loop you initiate a sub loop that then starts logging the data you require for averaging.
Hope this helps,
Kamran
Attachments:
ShiftRegister.vi ‏36 KB

Simplify VI that is recording a rate but is currently using too many shift registers

I have a VI that was made by the director of scary movie, so beware, this VI is a nightmare!...or at least to me it is.
Background:
I have 20 pans and I have a water level sensor that outputs a voltage from 0-5 Volts. By knowing the volume of the pans, I calibrated the output to be in gallons. The real output I need is a volumetric flux, which is gallons per minute per square foot. We are currently achiving this by using a VI that a summer intern made (See attached). It works well, but it is just so messy and hard to clean up and expand. The plan is to have 100 pans total and I don't want to copy paste this code 5 more times!
Questions:
-How can I collect a rate differently? If you notice on the calibration subvi attachement, the rate is calculated manually knowing how fast the loop is going in the main VI. I don't know if this is the best way
-Can I get rid of the shift registers some how?
-Is there a way for me to combine the calibration subVIs so that I don't have to have one subvi for each channel?
Thanks in advanced!
Solved!
Go to Solution.
Attachments:
calibration subvi.JPG ‏29 KB
Shift register mess.JPG ‏79 KB

Hi all,
I will attach the actual code in a few minutes. There's some propietary information that I need to remove before uploading. I'll be right back
EDIT:
Ok guys, please see VI's attached. The VI that I need help with is "AWC - Commercial Main VI - Rev0" and the messy part it's towards the bottom.
I have been cleaning up this VIs and making subVIs for a few months now (time on and off) but I can't seem to get a grasp on how to minimize the big shift register mess.
Maybe some background on myself might help? I'm a ME but I have been using LabView for easy project for the last 2 years. I took Core 1,2,3 class of LabView so I guess I know enought to be dangerous and to get myseld into trouble. I don't practice as much as I would like to and that's probably why I'm stuck with this big mess.
I will also accept any other tips that anybody has offer in any other part of the VI. I can also clarify any parts of the VI if that helps.
Thanks,
Pepi
Attachments:
NI Help.zip ‏366 KB

Using a loop back node to build array okay instead of shift registers?

Attached is a sample of how I want to accomplish appending to multiple arrays and would like an opinion wether it is acceptable or not. I didn't want to use 12 shift registers wired from the 6 possible case structures mainly because of esthetic reasons. Each case will be called in turn during program execution only once. So case 0 builds it's array then later case 1 and so on. It seems to work but frankly manipulating arrays in LV confuses me a bit. I cannot test in the actual program since the hardware the complete program controls is not yet installed. Your input as to the wisdom of doing this or proposing a better solution (maybe one that actually works) is appreciated
Mike
Attachments:
sample2.vi ‏33 KB

You never have more than one element in each array since you initialize the shift register with every call of the VI.
Use "built array" instead of "insert into array", it's cleaner. However, since you only kep one elements, maybe you can jist place the scalar value inside a shift register. Make sure the default value is NaN so you know when it contains valid data.
All you probably need is an array of fixed size (12) and replace appropriate elements as need arises.
What you probably want is an action engine. See http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=240328#M240328
LabVIEW Champion . Do more with less code and in less time .

Initialising Shift Registers

Hi
I am totaly new to labview so assume that this question can be easily solved!
I am trying to implement a FIR filter (can't use pre-designed sub vi's because it must operate in accordance with a specified transer function).
I think I have the design sorted except that I am having trouble with initialising shift registers. I can't get them to work,
any help would be apriciated.
Chris
Attachments:
initial_filter_design_1.vi ‏57 KB

You're correct. I should have mentioned this technique.
The attached image shows how to do this.
The "First Call" function will only produce a True the first time a VI is called, so the shift register will get initialized the first time the sub-vi runs, then the shift register will retain the value after each call.
Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
Attachments:
init_SR_in_loop.gif ‏5 KB

Replacing shift registers with queues or notifiers?

Hello World,
I'm using labView 7.1 with my first application, which is essentially a spectrum analyser and comparison to limits. now due to the parameters of the sampling 12000 samples/sec with 4096 point I have quite large chunks of data involved in rolling averages of 1 minute and rolling buffers that are an hour long. I'm pretty new to labview but I'm finding pretty easy to pick up except when it comes to optimisation and performance (I've been used to the microsoft approach until now) due to the fact that the instrument I'm building has to run in psuedo "real time".
I've been looking at replacing the shift registers with either queues or notifiers but I'm unsure if these techniques would result in improvements or not.
I'll attach a jpg of my main loop, I've only got the one but it is separated into three separate tasks but they are all governed by the data flow, DAQ then PROCESSING then REPORTING.
I've been told that by separating the loops and making them run in parallel LV will be able to compile it more efficeintly, but I'm unsure how to do that .
Cheers
Andrew
90% of all experts aggree that 1 out of 10 experts are wrong
Attachments:
Step 14 -Post Course Mk4d.jpg ‏376 KB

Fat Controller wrote:
Hello World,
I'm using labView 7.1 with my first application, which is essentially a spectrum analyser and comparison to limits. now due to the parameters of the sampling 12000 samples/sec with 4096 point I have quite large chunks of data involved in rolling averages of 1 minute and rolling buffers that are an hour long. I'm pretty new to labview but I'm finding pretty easy to pick up except when it comes to optimisation and performance (I've been used to the microsoft approach until now) due to the fact that the instrument I'm building has to run in psuedo "real time".
I've been looking at replacing the shift registers with either queues or notifiers but I'm unsure if these techniques would result in improvements or not.
I'll attach a jpg of my main loop, I've only got the one but it is separated into three separate tasks but they are all governed by the data flow, DAQ then PROCESSING then REPORTING.
I've been told that by separating the loops and making them run in parallel LV will be able to compile it more efficeintly, but I'm unsure how to do that .
Cheers
Andrew
Don't convert shift registers into queues or other things for performance reasons! LabVIEW has a lot of internal optimization logic when compiling your code which works best on shift registers. On a queue you will always copy the entire data of a message in or out even if you only need one byte of it.
Try to look at your architecture. You do want to do as much as possible in place. Try to completely avoid Append Array or Append String inside loops if possible. They are costly operations as they have to reallocate memory each time and often copy the entire data from the first array into the resized array. Better is to once preallocate an array of the necessary size, keep it in your shift register all the time and then use Replace Array Subset, Index Array and Array Subset nodes only on this. You will also have to maintian some index shich tells you up to where you have currently filled that array and that one is usualy best put into a shift register as well.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

LV 8.21: strange behavior with DAQ tasks, parallel running VI's and shift registers

Hello,
I have made a VI using DAQmx vi's. The VI uses shift registers to store DAQ tasks and other (internal) information. I have implemented several modes of operation (enum control with a case structure) like 'init', 'read AD', 'config AD' etc. If I use this multi mode VI in a single main VI everything work as expected. I have attached a jpg that shows one example where the DAQ VI is called from 2 parallel running while loops. One loop aquires the data (LOOP 1) while the other loop configures the aquisition task (LOOP 2). If I implement the same thing by putting LOOP2 in a different VI that runs seperately from the first VI I get an error message (200428):
Possible reason(s):
Measurements: Value passed to the Task/Channels In control is invalid.
The value must refer to a valid task or valid virtual channels.
Task Name: EasyDAQ_AD
Of course, the second VI is started manually after the 1. VI has passed the initialization part. The error message is triggered from the 1. VI that executes the DAQ task. From my understanding of the LV execution system this seems like a bug to me. Does anyone have an idea what could go wrong here?
klaus
Attachments:
problem.jpg ‏30 KB

1. In general, this kind of technique is something I've been using successfully for years. (Ben recently wrote up a very nice treatment of these "Action Engines" as a "Community Nugget.") So I don't start by expecting this to be a bug in the LV execution system.
2. Your description of the problem sounds almost backwards. You say you manually start the 2nd vi ("Config AD") *after* running the 1st vi ("Read AD"). Seems like you'd need to do the Config 1st and then do the Read, right? I kinda suspect you actually did it in the right order, but described it wrong.
3. The next likely scenario is that the Config failed, but you didn't trap the error and were unaware of it. Then it makes sense that the Read would also fail.
4. A couple issues I regularly deal with in these DAQ Action Engines is internal error handling. I often keep a shift register inside to store errors generated inside the Action Engine. But it can get a little tricky doing sensible things with both the internal error and any other error being wired in as input.
I said all that so I can say this: if you have complex nested case statements, or lots of different action cases to handle, double check that the task wire makes it from all the way from left shift register to right. Sometimes they get lost if they go through a case statement, the output tunnel is set to "use default if unwired", and 1 or more of the cases don't wire the output.
-Kevin P.

Is this roughly how the labVIEW Execution Systems work?

I've not taken a class in OS design, so I don't know the strategies used to implement multitasking, preemptive or cooperative. The description below is a rough guess.
LabVIEW compiles Vis to execute within its own multitasking execution environment. This execution environment is composed of 6 execution systems. Each execution system has 5 priority queues (say priorities 0->4). Vis are compiled to one or more tasks which are posted for execution in these queues.
An execution system may either have multiple threads assigned to execute tasks from each priority queue, or may have a single thread executing all tasks from all priority queues. The thread priorities associated with a multithreaded execution system are assigned according to the queue that they service. There are therefore 5 available thread priority levels, one for each of the 5 priority level queues.
In addition to the execution queues, there are additional queues that are associated with tasks suspended in various wait states. (I don't know whether there are also threads associated with these queues. It seems there is.)
According to app. note 114, the default execution environment provides 1 execution system with 1 thread having a priority level of 1, and 5 execution systems with 10 prioritized threads, 2 threads per priority queue. NI has titled the single threaded execution system "user interface" and also given names to the other 5. Here they will be called either "user interface" or "other".
The "user interface" system is responsible for all GUI actions. It monitors the keyboard and mouse, as well as drawing the controls. It is also used to execute non-thread-safe tasks; tasks whose shared objects are not thread mutex protected.
Vis are composed of a front panel and diagram. The front panel provides an interface between the vi diagram, the user, and the calling vi. The diagram provides programmatic data flow between various nodes and is compiled into one or more machine coded tasks. In addition to it own tasks, a diagram may also call other vis. A vi that calls another vi does not actually programmatically branch to that vi. Rather, in most cases the call to another vi posts the tasks associated with the subvi to the back of one of the labVIEW execution system�s queues.
If a vi is non-reentrant, its tasks cannot run simultaneously on multiple threads. This implies a mutex like construction around the vi call to insure only one execution system is executing the vi. It doesn�t really matter where or how this happens, but somehow labVIEW has to protect an asynchronous vi from simultaneous execution, somehow that has to be performed without blocking an execution queue, and somehow a mutex suspended vi has to be returned to the execution queue when the mutex is freed. I assume this to be a strictly labVIEW mutex and does not involve the OS. If a vi is reentrant, it can be posted/ran multiple times simultaneously. If a vi is a subroutine, its task (I think there is always only one) will be posted to the front of the caller's queue rather than at the back of the queue (It actually probably never gets posted but is simply mutex tested at the call.) A reentrant-subroutine vi may be directly linked to its caller since it has no restrictions. (Whether in fact labVIEW does this, I don�t know. In any event, it would seem in general vis that can be identified as reentrant should be specified as such to avoid the overhead of mutexing. This would include vis that wrap reentrant dll calls.)
The execution queue to which a vi's tasks are posted depends upon the vi execution settings and the caller's execution priority. If the caller's execution priority is less than or equal the callee's execution settings, then the callee's tasks are posted to the back of the callee's specified execution queue. If the caller's execution priority is greater than the callee's specifications, then the callee's tasks are posted to the back of the caller's queue. Under most conditions, the vi execution setting is set to "same as caller" in which case the callee�s tasks are always posted to the back of the caller's execution queue. This applies to cases where two vis are set to run either in the other execution systems or two vis are set to run in the user interface execution system. (It�s not clear what happens when one vi is in the �user interface� system and the other is not. If the rule is followed by thread priority, any background tasks in the �other� systems will be moved to the user interface system. Normal task in the �other� systems called by a vi in the �user interface� system will execute in their own systems and vice versa. And �user interface� vis will execute in the caller�s �other� system if the caller has a priority greater than normal.)
Additionally, certain nodes must execute in the "user interface" execution system because their operations are not thread-safe. While the above generally specifies where a task will begin and end execution, a non-thread safe node can move a task to the �user interface� system. The task will continue to execute there until some unspecified event moves it back to its original execution system. Note, other task associated to the vi will be unaffected and will continue to execute in the original system.
Normally, tasks associated with a diagram run in one of the �other� execution systems. The tasks associated with drawing the front panel and monitoring user input always execute in the user interface execution system. Changes made by a diagram to it own front panel are buffered (the diagram has its own copy of the data, the front panel has its own copy of the data, and there seems to be some kind of exchange buffer that is mutexed), and the front panel update is posted as a task to the user interface execution system. Front panel objects also have the advanced option of being updated sequentially; presumably this means the diagram task that modifies the front panel will be moved to the user interface execution system as well. What this does to the data exchanged configuration between the front panel and diagram is unclear as presumably both the front panel and diagram are executing in the same thread and the mutex and buffer would seem to be redundant. While the above is true for a control value it is not clear whether this is also true for the control properties. Since a referenced property node can only occur on the local diagram, it is not clear it forces the local diagram to execute in the user interface system or whether they too are buffered and mutexed with the front panel.
If I were to hazard a guess, I would say that only the control values are buffered and mutexed. The control properties belong exclusively to the front panel and any changes made to them require execution in the �user interface� system. If diagram merely reads them, it probably doesn�t suffer a context switch.
Other vis can also modify the data structure defining the control appearance and values remotely using un-reference property nodes. These nodes are required to run in the user interface system because the operation is not thread-safe and apparently the diagram-front-panel mutex is specifically between the user interface execution system and the local diagram thread. Relative to the local diagram, remote changes by other vis would appear to be user entries.
It is not clear how front panels work with reentrant vis. Apparently every instance gets its own copy of the front panel values. If all front panel data structures were unique to an instance, and if I could get a vi reference to an instance of a reentrant vi, I could open multiple front panels, each displaying its own unique data. It might be handy, sort of like opening multiple Word documents, but I don�t think that it�s available.
A note: It is said that the front panel data is not loaded unless the front panel is opened. Obviously the attributes required to draw an object are not required, nor the buffer that interfaces with the user. This rule doesn�t apply though that if property references are made to front panel objects, and/or local variables are used. In those cases at least part of the front panel data has to be present. Furthermore, since all data is available via a control reference, if used, the control�s entire data structure must be present.
I use the vi server but haven�t really explored it yet, nor vi reference nodes, but obviously they too make modifications to unique data structures and hence are not thread-safe. And in general, any node that accesses a shared object is required to run in the user interface thread to protect the data associated with the object. LabVIEW, does not generally create OS level thread mutexes to protect objects probably because it becomes to cumbersome... Only a guess...
Considering the extra overhead of dealing with preemptive threading, I�m wondering if my well-tuned single threaded application in LV4.1 won�t out perform my well-tuned multithreaded application in LV6.0, given a single processor environment�
Please modify those parts that require it.
Thanks�
Kind Regards,
Eric

Ben,
There are two types of memory which would be of concern. There is temporary and persistent. Generally, if a reentrant vi has persistent memory requirements, then it is being used specifically to retain those values at every instance. More generally, reentrant code requires no persistent memory. It is passed all the information it needs to perform its function, and nothing is retained. For this type of reentrant vi, memory concern to which you refer could become important if the vis are using several MBytes of temporary storage for intermediate results. In that case, as you could have several copies executing at once, your temporary storage requirements have multiplied by the number of simultaneous copies executing. Your max memory use is going to rise, and as labview allocates memory rather independently and freely, the memory use of making them reentrant might be a bit of a surprise.
On the other hand, the whole idea of preemtive threading is to give those tasks which require execution in a timely fashion the ability to do so regardless of what other tasks might be doing. We are, after all, suffering the computational overhead of multithreading to accomplish this. If memory requirements are going to defeat the original objective, then we really are traversing a circle.
Anyway, as Greg has advised, threads are supposed to be used judiciously. It isn't as though your going to have all 51 threads up at the same time. In general I think, overall coding stategy should be to minimize the number of threads while protecting those tasks that absolutely require timely execution.
In that sense, it would have been nice if NI had retained two single threaded systems, one for the GUI and one for the GUI interface diagrams. I've noticed that control drawing is somewhat slower under LV6.0 than LV4.1. I cannot, for example, make a spreadsheet scroll smoothly anymore, even using buffered graphics. This makes me wonder how many of my open front panel diagrams are actually running on the GUI thread.
And, I wonder if threads go to sleep when not in use, for example, on a wait, or wait multiple node. My high priority thread doesn't do a lot of work, but the work that it does is critical. I don't know what it's doing the rest of the time. From some of Greg's comments, my impression is it in some kind of idle mode: waking up and sleeping, waking up and sleeping,..., waking up, doing something and sleeping... etc. I suppose I should try to test this.
Anyway that's all an aside...
With regard to memory, your right, there are no free lunches... Thanks for reminding me. If I try this, I might be dismayed by the additional memory use, but I won't be shocked.
Kind Regards,
Eric

How do uninitialized shift registers work in reentrant VI's

Similar Messages

Maybe you are looking for