Multiple producer one consumer

[johnsold]

VeeJay,

I assume that you know how to separate commands from data in the string and that the issue is how to get the commands and data to the right places within your state machine.

I would do all the string decoding in exactly one place, probably in the state machine.  Each time you identify a command, pair it with the corresponding data values.  In some cases it appears that the data values will be empty.  Use the new command, along with any other state data to determine the next state.  Pass the values to that state via a shift register.  Repeat for the next {command, values} pair.  This decoding could be in a subVI or inline code depending on how complex it is.

Lynn

[VeeJay]

Lynn,

You read my mind. You have describled exactly. what I am trying to do. I was finding it hard to explain. But you did it 🙂 lol

---

I assume that you know how to separate commands from data in the string and that the issue is how to get the commands and data to the right places within your state machine.

---

Well, it isnt difficult to separate. I have a datasheet that tells me what hexa decimal values are commands and what hexa values are data. To get them in the "RIGHT" place is the issue.Currently, I have a working program, with the integration of the 3rd party software, where I have the state machine for states of the device like pretest, start, stop etc. So, when I encounter a command to start (say), I activate the Boolean START=TRUE. The program can actually work without the third party software (if we just press START BOOLEAN = True, the device turns ON) . The data that follows the command, I convert them from hexa decimal to decimal and write them onto numeric controls.

I want the state of device to change according to incoming comnmand directly as opposed to indirectly ( I don't want the command to issue a command to a BOOLEAN to run a state if that makes any sense). The vi shows the way I am decoding string coming in from RS232 port

---

I would do all the string decoding in exactly one place, probably in the state machine.  Each time you identify a command, pair it with the corresponding data values.  In some cases it appears that the data values will be empty.  Use the new command, along with any other state data to determine the next state.  Pass the values to that state via a shift register.  Repeat for the next {command, values} pair.  This decoding could be in a subVI or inline code depending on how complex it is.

---

How do I accomplish this? I tried one way, but I dont think it is right. Please refer attached. How do I bundle up all information to determine the next state? I know this is the right way to go, but not able to figure out the mechanism.

Thanks!

V

[Mark_Yedinak]

I'm still going to advise that you stop using mutually exclusive parallel case structures for your code. This makes your code confusing, and much more difficult to maintain. Just look at the cases you have in each case structure and you will see that you are not duplicating any values. Therefore simply use ONE combined case structure. You will will appreciate this down the road when you need to pick this code up again and work on it. Always remember the KISS principle.

[VeeJay]

Hi Mark,

Yes, I implemented those two parallel case structures into one. Problem that I am facing is that the loop is not iterating fast enough to switch from one case to another and I lose communication with the 3rd party software. Also, When a boolean is set to true in case 160, it immediately sets back to false when status check cases 192, 193, 194 run constantly. Combining them seems to affect the working because as soon as the device starts, it stops. Becuas the start boolean in 160 is set back to False. In the code I posted, I am effectively now touching that case until the next command comes in. I know that this is not a perfect way of doing things, but this is all I have got working. But, I am looking into more ways to integrate the commands and data along with states of the machine.

V

[johnsold]

VeeJay,

I agree with Mark that you will be better off with only one case structure for the implementation of your state machine.

What I see now is that you have gotten so busy trying things (while learning a lot), that you are now in danger of getting lost in the forest because all you can see is the trees.  Please  take some time to design your state machine, probably with pencil and paper, before attempting to write any more LV code.  Make a list of all the tasks which need to be performed.  Add to it the inputs to and outputs from each task.  This includes but is not limited to the commands and values received from the producer.  Determine how many and what kinds of states are required to perform all the tasks.  Map states to tasks.  Define the state transitions - that is, from state xxx, what data, conditions, commands, ... determine which state executes next.  Double check this document against the original requirements for the program.  Then simply write the code which implements each state and the state transitions.

Both top down and bottom up design styles have their places.  I think you have reached the point where you would benefit from doing some careful top down thinking about your project.

Lynn

[VeeJay]

You are absolutely correct. Although, what I have done so far is working fine, I want to make it perfect. And I think the PC architecture with state machines will do that.

I am back to paper and pen because no matter what I try, I end up referring to what I have working so far. And that is constricting my thinking outside of what I have done.

I will post once I have done something different and will change the parallel case structures as well 🙂

V

[Mark_Yedinak]

In addition to Lynn's excellent advice I suggest that you do a few things to make your code more readable and easier to maintain. For example, you read back a command opcode and pass this to a case as a simple number. Think about using a typedefed ENUM to wire into the case structure. Then your case would appear something like "Voltage Status Command" rather than something meaningless like 160. At a minimum at least add a label to each case if your are going to use simple numbers.

Avoid using all the property nodes in your code. Use shift registers for passing that information through your state machine. All those property nodes will impact your performance.

Look for stray Wait commands in your code and well as the timeout values you use for your VISA read and write. You may be setting those too long or too short which lead to some of your performance problems. Well written code can run VERY fast. I haven't had the time to dig through your code extensively but try a few of the ings I have suggested. But first, spend some time defining your state machine like Lynn suggested. When you are doing this don't even open LabVIEW. Just define your tasks and state machine. Worry about code once you have that done.

[VeeJay]

HI Mark,

Quick question. Why does the subvi "Wagner force" have a "TRUE" boolean attached to the while loop STOP? Does this mean it runs one iteration for one iteration of the outer loop ?

Thansk!

V

[VeeJay]

Oh from the example you referred to me before...

[VeeJay]

Hi Mark and Lynn,

I went back to paper and have modified a lot; the way I have structured my program has improved a lot. I have done away with the parallel case construct 🙂

I am still held up with the RS232 communication. (The way I have implemented works fine I must add) . Please find attached just the RS232 communication loop that communicates with a parallel State machine in my actual program.

I have tried queues to implement RS232 communication by it doesnot seem to work for my application which is a complicated one. So, I have stuck to this constant polling method to listen for commands.

Here is where I face a problem (It is a combination of lack of adequate knowledge of this propreitary software from GE that I have that sends commands on the serial port and probably my understanding of queues maybe. ) I run my vi and open the GE software and establish connection and use the icons on the software to control my device. But, if there is a lag in the system or if I use LabVIEW execute highlight to see flow control, "THE SOFTWARE REPORTS LOSS OF COMMUNICATION" and I have to reopen my vi to get back to where I need to be.

So judging from the vi I attached, do you think there is a better way to do this communication to avoid loss of data due to a lag in the system?

Second question) If you see the first read function, I am reading byte by byte. If I attach each byte into a queue, when I dequeue, I dequeue each byte right? What if I read 10 bytes at a time and enqueue them, then would dequeueing spit out 10 bytes at a time?

I would really appreciate any help with this. The vi I write should be in the background and read commands and sends them to the device and send back ACK's.

Thanks!

V