LabVIEW
Shift Register in labview
- LabVIEW will manage the memory. You don't need to worry about "location". Sometimes, the content of the SR changes (e.g. If an array increases in size) and memory needs to be reallocated.
- The data in the shift register remains until it is overwritten by new data. If the SR is uninitialized, it will be remembered between calls until the VI leaves memory.
- Yes, you can always branch the wire and connect an indicator or use the data in the wire.
- Yes (You read from that location on the left, and write to it on the right)
- You can also use feedback nodes, which are similar, but don't need to be anchored on a loop.
Here's an explanation how things are stored in memory.
He's back! (smiley-wink)
@AnandR wrote:
Hi,
This is regarding the shift register in while or for loop terminal. can you please answer my below questions.
1. where this shift register will be stored(memory location)
2. what is the life time of this shift register.
3. can i access the shift register value when VI is open and when VI is running.
4. The input and output shift register are the same memory location.
5. while and for loop terminal are the oly terminal we can created shift register.
Is there any simulation application which i can visualize how labview modules (components are stored in memory).
Regards,
Anand
You may be interested in reading this Nugget I wrote about Action Engines which utilized Shift Registers to get you started.
Lets see what I can do to help you get out of the memory rut you find yourself in.
1. where this shift register will be stored(memory location)
We do not know the exact location. There may be people in LV R&D that have tools to inspect the heap and figure it out but even that maybe transitory. As we wrote previously LV keeps track of memory for us. It does exactly what we would do if we were explicitly handling memory. When a VI with a Shift Register (SR) starts, LV will take a guess at how much memory will be required. An U8 gets a byte while a string may get 1Kbytes allocated. Now if the SR is a string and the code starts to add to the string such that it too large to fit into the space allocated for the string, LV will move the data that is that mysterious memory address to anther location but it will allocate a larger buffer than previously. After the buffer is moved the LV code resumes just where it left off. LV manages the memory and allocates memory as required.
2. what is the life time of this shift register.
The data in the SR will stay in the memory allocated for the SR as long as the VI is loaded. You can run a VI with a SR and put data into the SR. The VI can stop and the data will still be there. This makes it easy to trouble shoot AEs since you can execute the various action/operations and watch the code run using the data in the SR. Plese note that while the data in the SR may stay there, the validity of that data could change. An example could be a VISA or Queue reference. The references will still be there when the VI stops but the structure the handles points it can go invalid.
3. can i access the shift register value when VI is open and when VI is running.
The SR is a lot like a "static local" in C. You can only access it using the code of the VI containing the SR.
4. The input and output shift register are the same memory location.
Ideally yes. But see above where the space that holds the data in the SR grows beyond the initial allocation. In that case the data gets moved.
5. while and for loop terminal are the oly terminal we can created shift register.
Timed Loops also have SRs.
There is another block diagram object that do the same thing as a SR. it a feedback node. They are a little faster than a SR and have additional functionality available. But in both cases the SR and the Feedback node, they store data from one call so that it can be used in a latter call.
@I started out as a hardware guy doing "012737" moved data that follows to address that follows and then moved on to Macro (Mov . @R7) and then onlt to C. At that time I could get memory maps of the coce that was produced by the code I wrote. It was not long unitl I discovered that C was damn clever about how it structured the machine code. The same thing applies to LabVIEW. it takes care of all of those dirty little details and frees us to think and work with the application we are developing and not have to worry about the low level things.
LabVIEW is wicked smart about how it turns our block diagrams into machine code. The sooner you stop worrying about where data is located, the sooner you will be flying with the eagles!
Now if you really want to read more about memory, please check out the links in this tag cloud that relates to memory.
Ben
Damn! Christian beat me to it again! But only by two minutes since I had to find the links. 
Also note that Christian and myself are saying about the same thing. He is California and I am in Pennsylvania so we are not share notes.
Let go of the memory my dear son and embrace the data flow!
