Archive for January, 2011

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:)

7 sins of IMAQ module

Monday, January 10th, 2011

I have been using IMAQ module in LabVIEW these days, and the integration of many algorithms saved me a lot of time. It is the core module when we want to do Machine Vision. I haven’t digged into it since the subset seems OK for my job. But in this post I’m not saying the beauty of it, instead, I’m going to tell seven sins of the IMAQ module. Just to clarify, I splitted some up in order to make it “7”. All the problems are based on vision development module 2009.

1. It has to be in IMAQ. Sometime I just want a simple “2D array filter” to proceed my 2D data, but there is no such a node in the core functions, although I though it’s not complex. And the fact is, if I want to proceed my raw 2D array in any ‘image’ way, I have to buy and call IMAQ module to do that, plus conversion back and forth. That’s not handy.

2.  Non-standard connector layout. Here is the connector  layout:

It’s not using standard 4224 layout pattern, and the wiring becomes a chaos in this case.

3. Old style front panel. Here is the front panel comparison of the “IMAQ” and “Open/Create/Replace”

As you can see, the controls and indicators are different in two VIs. So if we have IMAQ VIs with other VIs in the same top level, we will have diffrent front panel controls if we just create controls by right clicking.

4.IMAQ VIs should support all image types which makes sense” as described in the NI idea exchange.

5. Along with the last sin, there is no boolean array input/ output in “IMAQ” and “IMAQ”. Actually boolean 2D array is quite useful in many pattern recognization applications. (Yeah, this is the extra sin I just divided from last one)

6. “Image Dsc Out” missing in some VIs. E.g, after the proceeding of the image and we want to convert it back to an array, do we need to release the buffer we created? If yes, there is no such a connector on the output. I assume all the VI without the “Image out” connector is to be used as indicators, but still, it’s better to keep it uniform.

7. We have to create buffer to manipulate images. In this module it’s not as smart as in Array functions, we need to create one buffer to proceed an image, mutiple buffers for mutiple ones (or, use one buffer one by one). It would be nicer if NI can make this easier.

Anyway, IMAQ is a very useful module and hope I’ll study ultilize it better in the future.