Clear shift registers between runs

Hi,
Noob question of the day! I am building an array and would like to clear shift registers between runs. I have attached a VI. It runs a while loop every second and adds that iteration number to an array. I then display the length of the array. I would like it such that each time I press run, the program starts with a "blank slate." Any standard way of clearing everything. I would love to do something like:
clc
clear
if it were matlab...
Solved!
Go to Solution.
Attachments:
shift register count.vi ‏8 KB

What do you know, I guess the problem is that I am left handed. Sometime I even confuse up and down.
Yes I meant the right-click the left shift register.
LabVIEW Champion . Do more with less code and in less time .

Similar Messages

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 there and alternative to shift registers for saving data across iterations in a subVI operating inside a loop?

I am creating a subVI state machine (case structure) which will run inside a while loop which will be executing every 250ms. The reason I wanted to make the state machine case structure into a subVI is because I want to execute 64 of the machines within the same loop. The goal is to monitor certain types of voltage changes on 64 I/O channels on a FP2200 RT module and report periodic details about state changes to a database. My thinking was that by executing each independent machine in the same loop structure, I will only worry about one thread. It seems that the alternative of having one state machine thread per I/O channel is probably more than the RT module can handle. Please correct me if I am wrong on that.
The issue I'm now having is as I'm creating the state machine, I am finding that I need to keep track of some pieces of data from one loop iteration to the next. This is easy enough to do with shift registers but in order to use them, I have to create additional input nodes to my SubVI as well as output nodes. For example, I want to use a queue to buffer some I/O data but as of now, I have to create this queue outside the loop, pull it into the loop across a shift register, feed it to the subVI, and output it to the out Shift register. It would be better if I didn't have to output this queue because there's no reason for anything to have access to it outside the subVI. It just creates an extra set of wires to look at and makes me worry a bit about maintainability.
Is there a better way to approach this problem?

You could place a while loop inside your sub vi that has a true constant wired to the stop condition. Then add unitialized shift registers to that while loop to keep data between iterations.
or you could use a feedback node inside the sub vi

Design issue with sharing LV2 style global between run-time executables

Hi,
Just when I though that I had everything figured out, I ran into this design issue.
The application that I wrote is pretty much a client-server application where the server publishes data and the client subscribes data using data sockets. Once the client gets all the data in the mainClient.vi program, I use LV2 style (using shift registers) to make the data global to all the other sub-vi’s. So the LV2 is in initialize mode in the mainClient.vi program and then in the sub-vi’s the LV2 is in read mode. Also, I had built the run time menu for each sub-vi that when an item is selected from the menu, I would use the get menu selection to get the item tag which will be the file nam
e of the sub-vi and open the selected sub-vi using vi server. This all worked great on my workstation where I have labVIEW 7.0 Express installed. But the final goal is to make exe’s for each of these sub-vi’s and install runtime on the PC’s that do not have labVIEW installed. Of course when I did that only the mainClient.exe program was getting the updated data from the server but the sub-vi’s were not getting the data from the mainClient.exe. I did realize that the reason for this is due to the fact that I had compiled all the sub-vi’s separately and so the LV2 vi is now local to each executable (i.e. all executables have their own memory location). Also, the run-time menu did not work because now I am trying to open an executable using vi server properties.
To summarize, is there a way to share LV2 style global's between executables without compiling all of the sub-vi’s at one time? I tried using data-sockets (local-host) instead of LV2 st
yle gloabls to communicate between the sub-vi’s but I ran into performance issues due to the large volume of data.
I would really appreciate it if anyone can suggest a solution/alternative to this problem.
Thanks
Nish

> 1) How would I create a wrap-around for the LV2.vi which is
> initialized in my mainClient.vi and then how would I use vi server in
> my sub-vi to refer to that LV2.vi?
> You mentioned that each sub-vi when opened will first connect to the
> LV2.vi via via-server and will keep the connection in the shift
> register of that sub-vi. Does this mean that the sub-vi is accessing
> (pass-by-reference) the shared memory of the mainClient.vi? If this
> is what you meant I think that this might work for my application.
>
If the LV2 global is loaded statically into your mainClient.vi, then any
other application can connect to the exe and get a reference to the VI
using the VI name. This gives you a VI reference you can use to call
the VI. Ye
s, the values will be copied between applications. That is
why you need to add access operations to the global that returns just
the info needed. If you need the average, do that in the global. If
you need the array size, do that in the global. Returning the entire
array shouldn't be a common operation on the LV2 style global anyway.
> 2) Just to elaborate on my application, the data is
> transferred via DataSockets from the mainServer.vi on another PC to
> the client’s PC where the mainClient.vi program subscribes the
> data (i.e. 5 arrays of double type and each arrays has about 50,000
> elements). The sub-vi’s will have to access these arrays
> located on the mainClient.vi every scan. Is there any limitation on
> referencing the mainClient.vi data via vi-server from each sub-vi?
Your app does need to watch both the amount of data being passed across
the network, and the amount being shared between the apps. You might
want to consider puttin
g the VIs back into the main app. What is the
reason you are breaking them apart for?
Greg McKaskle

Calculate maximum value of subarray while creating it using a case structure and shift registers

I have two 1D arrays that contain cyclical information (kind of like a sine wave). One that contains information on position in degrees and another that contains torque. I would like to calculate the maximum torque value each time the position is within a certain range (e.g. from 30-80 degrees). The ranges are repeated - that's why it is cyclical. I use the "in range" function, a case structure and shift registers to build a new array with values that fall within the range I specify - this was the easy part (see VI attached). I'm struggling with a way to calculate a maximum value for each subarray formed when values are "in range". Your help is much appreciated.
Solved!
Go to Solution.
Attachments:
Simple Calculate between anatomical position range.vi ‏16 KB

It's not really noise - it's more inconsistency. So a position output can run: 20, 30, 40, 50, 60 etc. OR, it could run: 21, 24, 32, 41, 44, 51, 59 etc. But, it is always cyclical.
Attached you will find a .csv file with the data arrays - I'm using POS (ANAT) degrees column (column D if you open in excel). There you also see torque in ft-lbs along with some other information.
Attachments:
025C.csv ‏224 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

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

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

Bypassing shift registers

Being a beginner, I was experimenting with loops and shift registers. Originally I had an add operation that added 1 each time and the results passed back around via a shift register. Maybe I was thinking of op amps at the time but I thought why not just loop the output back to the input instead of going thru the shift register. Seems to work, is it a reliable design?
thanx,
jh
Solved!
Go to Solution.
Attachments:
feedback.vi ‏19 KB

jvh75021 wrote:
Maybe I was thinking of op amps at the time but I thought why not just loop the output back to the input instead of going thru the shift register.
Your shift register has absolutely no function here, because you never even use its output anywhere. Click on the shift register and delete it. Run the VI again. Notice no real difference! Now you could right-click the feedback node and "replace it with shift register and still retain about the same functionality. Shift registers and feedback nodes are interchangeable to some degree.
Important Details: Shift registers and feedback nodes are not completely equivalent. Notable differences exists in the way they can be initialized. A feedback node does not require the presence of a loop (at least in newer LabVIEW versions) and shift registers cannot be globally initialized. Feedback nodes can exist entirely inside a single case of a case structure. Shift registers require a loop on the same subdiagram. Shift registers can be resized on the left to access earlier histories. Feedback nodes can only access one history (selectable in newer versions).
Shift registers and feedback nodes are central to elegant and efficient code, so make sure to become completely familiar with them. New users often do ugly local variable hacks to approach some of their functionality.
LabVIEW Champion . Do more with less code and in less time .

Using Shift Registers

I am trying to create an algorithm that timestamps when a subject's arm is raised. The subject has a bluetooth accelerometer attached to their arm and y acceleration=0 when raised and y=1 when lowered. We want to timestamp the raise. Right now we have (using shift registers) that when Yaccel <0.2 and Yaccel-1>0.2 and Yaccel-2>0.2, write to file (In Case Structure).
We used 2 shift registers to get the Yaccel-1 and Yaccel-2 values.The problem is: any jerk in the direction of the y axis causes the acceleration in this direction to go to 0 momentarily. We need to look at a longer running list (about 1 second or 100 data points) of data to assure that this isn't a jerk but a raise. However, we can't have 100 shift registers as that would be crowded.. What can we do?
Thanks,
-Adam

You can look at the enclosed example which relies on time of 1sec interval, however I just considered Yaccel - 1 for demonstration, you may include others later.
The timer is set(just double click on it) to 1 sec and time duration been scrutinised to make a decision of using the data or scrap it off. If time goes above 1sec(no jerks occured), values are retained and ticks to state-0(you may code here, to write the data to the FILE), where if time is <1sec(jerky behaviour) and data is discarded by moving to state-2.
The reason to do the time check in side the case structure is that, we don't want to loose the data till first second if the check is positive. To conclude, the structure starts gathering values when Yaccel - 1 goes >0.2 and also makes decision to write or not by checking the timer value inside it.
Hope it gives some idea.
Message Edited by Parny on 03-02-2009 11:38 PM
Attachments:
case0.JPG ‏43 KB
case1.JPG ‏54 KB
example_time.vi ‏25 KB

Yosemite 10.10.1 - DNS cache does not clear when switching between WiFi networks

Before updating to Yosemite, DNS caches would clear when switching between WiFi networks, as they should.
For Example, when using an Exchange server, your server name might be something like mail.company.com. Outside of the corporate LAN the IP would resolve to the outside (WAN) address. When you move the laptop inside the corporate LAN, it should clear the cache so mail.company.com resolves to the internal (LAN) address. This is just one example of a dumb DNS transition not taking place switching from outside to inside (and vice versa).
Instead, OS X is holding onto the outside DNS record even when moving to the Corporate LAN. The only way to fix is to run the DNS cache command (which is MUCH more convoluted in Yosemite now), or more easily, to quickly turn off then turn on WiFi.
This is an irritation as I have to perform this action every morning, and every time I come back to my desk from offsite.

Well, clearing the caches is as simple as this, no?
Clear MDNS Cache
sudo discoveryutil mdnsflushcache
Clear UDNS Cache
sudo discoveryutil udnsflushcaches
One other thing: Have you tried 10.10.2? There are many many fixes in 10.10.2 over 10.10.1.

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

Multiple shift registers in For loop

I'm using multiple shift registers to find the number of different string in a string array. However, the shift register got refreshed every time it finds a different string and returns back to 0. How can I have the register remember its previous value after it encounters a new string value?
Solved!
Go to Solution.
Attachments:
count.vi ‏19 KB

You should think about making your code scalable. At the moment, you need to re-architect the VI from scratch whenever the sensor names or their number changes. If you suddenly have 1000 sensor names, the code would be unmamangeable because the sheer number of cases and shift registers!
Attached is an simple alternative. As you can see, the code remains the same, even if the number of sensors or their names changes in the future. See if it makes sense. (You can easily modify it to also count unrecognized names, for example).
Modify as needed.
Some other possible bugs in your VI:
You should initialize the shift register with zero, not one. Right now the results are one too high.
Case "B" is actually "B." and the count is only accidentally correct because it is also the default case and there are no other sensor names (e.g. F) in the input array.
LabVIEW Champion . Do more with less code and in less time .
Attachments:
CountMOD.png ‏19 KB
countMOD.vi ‏19 KB

Clear shift registers between runs

Similar Messages

Maybe you are looking for