LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Synchronizing State Machines in Queue

Solved!
Go to solution

I have a queue that takes info from a text file. I then pass that info as an array and then take each individual elemnt to control state machines. 

Bottom line: trying to parse a text file into controlling LEDs/Front Panel Objects. 

 

Ive successfully passed the info thru the queue, however my state machines in my consumer loop are not synchronized. (i.e. if I am trying to turn on LED 2, it either doesn't turn on the correct LED or doesn't turn on an LED at all. How can I fix this?

0 Kudos
Message 1 of 11
(4,349 Views)

I think your code is too complicated.  You have subVI's with loops, inside other subVI's with loops inside another VI with a loop.

You have a queue where you pass an array, but then you dequeue an element, and pick out just an index from that array.

Don't enqueue an array, enqueue the elements of the array.

How many times do you need to read your text file?

That and many of your case structures have identical code in every case.  If every case has the same code, that code belongs outside of the case structure.

 

Also, when posting a project, unless it is obvious like it is called Main.vi, tell us which VI is the top-level VI.

Message 2 of 11
(4,315 Views)

Thank you for your answer. 

 

I can remove the loop in the text read file. 

 

Should I instead pass the data from fileread.vi already indexed then pass the elements into array? I wasn't sure how to do this because I would need to add multiple queues and then bring them together for the state machine?

 

The text file neesd to be read once per cycle. The idea is to have a fully customizable text command file that would then be parsed in labview. 

 

Every case doesn't have the same code (I just filled in one case right now). The comparisons are for switching between states. 

 

I apologize--I forgot to specify the main file. It's queue_data_error.vi

0 Kudos
Message 3 of 11
(4,299 Views)

@RavensFan I simplified a little per your suggestion

Download All
0 Kudos
Message 4 of 11
(4,278 Views)

There was a lot more simplification you could have done.  (Like the case structures that all had identical code!)

And multiple index arrays when you only needed 1 or 2.

 

I cleaned it up.  Now I may have overstepped on the clean up a little bit because a lot of code looked identical, but then I discovered there is a confusing structure where you seem to be bouncing between comparison of values 2, 4, 6 that are in enums, and values of "2", "4", "6" that are in a string.  It really doesn't make sense.  So it can either be simplified even further, or I simplified it too much and there is some actual significance you have with those enums vs. strings.

 

Also, I found a race condition where you set the boolean value in one case structure and read it in a different one.  There is no control over whether the value is read or written to first.  Seems like a mistake and there should probably be a wire that does from one case structure to the other passing along the boolean value.

 

There were a lot of value property nodes.  They should either be wires, or local variables.

 

Attached is what I modified.  It may or may not be correct, but it definitely is simpler code than what you had last posted.

Message 5 of 11
(4,270 Views)

Thank you for simplifying! 

I used strings to control the state machine and also had enum because I'm getting the strings from the text file. I don't know how to store the strings as enum. 

 

Anyways-- I ran the simplification you sent me and it still has the same problem of synchronizing the state machines so that the LEDs correspond with the text command. i.e. when "setLED, 2, on" are read at the same time, the LED 2 turns on.

0 Kudos
Message 6 of 11
(4,259 Views)
Solution
Accepted by sam18

You are trying to use a state machine, but do you really need one?  State machines are something that maintain state between one run and another, and the decision of what the next state to execute is based on what happened in the current state.

 

You seem to be just executing a series of commands.  And More confusing, you have 3 different shift registers holding enums.  That makes it seem like you have 3 different state machines blended together.  Factor in that the case structures are very convoluted and what happens is based on the value of the enum from the previous iteration....   And the string vs. enum confusion...  

 

Where does "SetColor" come into play.  What do the "default" cases do?

 

Why is the text file read continually inside the For loop inside a while loop?  And the indexing of that 2-D array may have been wrong.

 

Here is a simple VI that is producer consumer, but does what you have described you wanted so far.

Message 7 of 11
(4,251 Views)

I haven't implemented setcolor yet because I wanted to focus on one functionality. 

 

Let me give you an overview of what I'm trying to do: 

 

I will be using DAQs to switch states of a certain device, and set delays, select certain lines, etc. All these commands will come from a .txt file. 

 

For the purpose of the application I attached, I want to programatically control the LEDs with a text file. I.e. turn the leds on or off based on what I have in the text file. Maybe I add a line in-between turn on led and turn off led that changes the color of the led displayed. I do need state machines because the command won't always be to turn the led on/off. It may also be to select a different set of LEDs to control or to wait for a few seconds or to change the color of the LED. I added state machines for flexibility. 

however, I am open to other design patterns--Im just not familiar with another way to accomplish this task.

 

Thank you.

0 Kudos
Message 8 of 11
(4,244 Views)

But it is not a state machine.  Nothing next state is determined by the previous state.  A state machine goes Init >> State 1 >>  State 2>> State 3>> Close.  Perhap a decision is made to return to state 1.  Perhap a decision is made in state 1 to skip state 2 and to go state 3.

 

All you have is an array of commands you want too perform.  Execute item 1, execute item 2, execute item 3,   so on until you hit the end.  You can still do something to change the color of the LED.  It will be just a different command that executes a different case of that case structure.

 

Look at my latest attachment.

Message 9 of 11
(4,235 Views)

Perfect--thank you for your help! I was using the case structure as an if statement. Now I know not to do that. 

0 Kudos
Message 10 of 11
(4,210 Views)