Archive for the ‘architecture’ Tag

Making the number of shift registers programmable

Thursday, January 27th, 2011

Shift register is very handy in LabVIEW programming. To add one more shift register (say, shift one more time), what you need is only click and drag down the shift register. If you want to recall the data generated in a loop 5 times ago, you drag down 4 more shift registers and pick the bottom one.

But the drawbacks are obvious,
1. It is not neat nor scalable in coding.
2. User cannot modify it without modifying the code.

So here is a alternative method for large/unstable number of shift registers — using the queue in the loop. The thought was quite straightforward, just to find something that can buffer the data. I’m sure there are many cleverer ways.


So the queue is used to store the data. With enqueuing and dequeuing we can do the shifting. The case structure is to determine if we shifted the right number, and the condition can be modified (e.g. if(get queue state==#shift regisiters) ).

The problem is solved now. Please let me know if you got better solutions:)

Advertisements

Run consumer loop without waiting

Thursday, December 9th, 2010

Producer/Consumer loop (PC loop) is one of the most important architectures in LabVIEW. It gives a good solution when your data producing rate is faster than your consuming rate. A typical example is analysing/storing the data while acquiring new ones. We dont want any slowness or jag of the post-process  interrupt the acqusition. Thus PC loop create a space from the memory and uses it as a buffer to deal with the asynchronous tasks.

In this architecture, the consumer loop will wait (for timeout period) until there is a new element in the queue. What if we want to run the consumer loop regardless the queue is empty or not? Sometime, we want to output waveforms until new waveform is generated. I modified the PC loop as following:

 

Note: Since the consumer loop runs all the time, we need a ‘wait until‘ node in it to save the CPU. It is not shown in the figure and sorry about that.

So the consumer loop does the normal things (like output pre-defined signals) when there is no element in the queue (determined by state of queue.vi). And when there is, the consumer loop dequeues it and updates the state (like updating signals). I think this thought is logical and similar to human thought. An alternative method is to enqueue the same element after we de-queue it. In this case the loops will be keeping enqueuing and de-queuing. I don’t quite like this method, of which the thought is not straightforward.