Homemade Queuing Machine

[IEC]

Hey everybody,

I was just playing around writing a quick VI which does some simple queuing of a small number of parameters.  As it is my first queuing machine I figured I'd post it on here hoping that you guys/gals can show me ways of making it better....

It does work fine though, you can put things into the queue and pull things out (obviously when integrated into the program there'll be no buttons, the boolians will be programatically controlled.  But if anyone wants to use it or take a look feel free!

[IEC]

One more thing... can someone take a look at the VI above and let me know if you know a way of making the array functions more dynamic... ie- i would like it to just figure out how many boxes it has to add or subtract and then do it, rather than having to have each box have it's own formatting functions.

thanks,

jonathan

[tst]

Some structural suggestions:

First, use a typedef cluster instead of individual elements. That way you can also simply place it into an array and use that to add more than one element.

Second, definitely use the uninitialized shift register, but you can create an enum with several actions (create queue, enqueue, dequeue and so on) and use a single case structure.

Third, and most important, why not use the built in queue VIs (in the Advanced>>Synchronization palette)? That will be the best solution by far...

[tbob]

I modified your vi to use the event structure rather than polling for the Add and Read buttons.  If these buttons are to not appear in a main vi, you could use dummy booleans (use buttons and hide them off the front panel screen, and use the Value (Signaling) property instead of Value Change in the event structure.  Then you could programatically set the booleans and the event would fire just as if someone had clicked a button.  I also changed the enum and added a 0 to the top.  The numbers were all one off.  You might want to put in some kind of error warning when trying to read from an empty queue.

[jasonhill]

Interesting.  I assume there is some reason you are not using a real queue.

I played around a bit.  I use the format into and scan from string in place of all those format blocks. 

I also tried my hand at using a single long string to hold the data instead of a 2D array.  But I admit that I do not understand how to get the formatting correct so it shows up properly in the table.  And I suspect that a randomly growing string is no better than a randomly growing array from a memory utilization standpoint.  This is an advantage for traditional queues, labview takes care of all the memory issues for us.

I also hooked the error out up to the loop so it will definitely execute first.  I assume this was your intent.

It needs an error check for when the "queue" string is empty and more data is requested (another advantage for real queues).

[MRedRaider]

Without changing your architecture (I would suggest researching the Producer-Consumer that ships with LV 😎
I have made a few modifications just to remove some "bad coding practices" according to the style guide.

BTW, I modified the copy using events, but the changes really apply to both copies equally.

As for the copy that was created by JasonHill:
***Add a short wait in the loop, even a few milliseconds will prevent your program from using 100% of the processor!

Message Edited by MattH on 07-05-2006 04:36 PM

[IEC]

Hehe... thanks, everyone.... I didn't know there was a built in queue VI.  I'll check it out first thing this morning.

[IEC]

Jason,

Your version of the queue (just fyi) did not enter the data into the multicolumn listbox properly... i'm not quite sure why, I think it's just the string formatting before going into the item names, but it puts all the info into the first box of the listbox.

Thanks for the help,

Jonathan

[IEC]

Whoa... I just checked out the queue stuff in advanced>synchronization....  amazing.  At least I didn't spend more than twenty minutes getting mine working before finding out it was already done!

🙂