LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error handling in simulatenous loops

Solved!
Go to solution
Take a look at state machines. This should help you to accomplish what you would like without the need to use sequence structures. In addition, you can always use data flow itself to determine the order of execution, assuming you have a data dependency. Error clusters are often used for this purpose.


Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 11 of 34
(3,657 Views)

I have version 8.0 of LabVIEW so unfortunately I could not look at that vi. I did try error clusters, but it did not work in this setup I have because of that several subVI's are parallel loops that run till I press stop, so the error signal would never leave the loops.

 

I will take a look at state machines right now

 

 

p.s. Is there a reason why to not use sequence structuers? Bad performance? (too me they make the code a bit easier to follow, speaking from a beginners perspective)

Message Edited by Siniz on 10-06-2009 08:42 AM
0 Kudos
Message 12 of 34
(3,647 Views)
I posted a version that I saved for LabVIEW 8.0. As for sequence structures the main reason not to use them is thta they effectively turn LabVIEW, a data flow language, into a sequential language. The power of LabVIEW comes from the fact that it is a data flow language. You loose all of those benefits by using sequence structures. Granted, single frame sequence structures are normally used to wrap a small piece of code that has no direct data dependency allowing you to inpose an artificial dependency. Beyond that you should architect your code to take full advantage of data flow. In addition, using state machines is a much more flexible than a flat or stacked sequence structure. A state machine allows you to control the flow or execution. You can't do so when using sequence structures. They are like a one way street, once you enter there is no turning back and you have to go all the way to the end.


Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 13 of 34
(3,640 Views)
It makes a lot of sense Mark. I'm going to go back and redo parts of my code again.
0 Kudos
Message 14 of 34
(3,633 Views)

Mark, I am making some slow progress here, but I have run into a few hurdles that I need to pass. I have attached a zip with a file with VI files.

 

Some questions:

1) How come the error? in the event structure never gets registered when I change the value in my error handler? Because of this, the event loop never stops and I have to abort the program execution via the built-in LabVIEW button.

 

2) The wiring gets messy with notifiers and queues. To me the code feels much less userfriendly than if I would have gone the route with e.g. global vars. Is this a common problem or am I doing the wiring in a funky way?

 

3) I had some trouble figuring out on how to handle an event (the Connect button pressed) and to pass this to the state machine loop. I am now using a notifier, but to me it gets messy with all the wiring. Is notifiers the correct way to make states in the state machine wait for user input, or do you know another way? I was thinking that moving some buttons OUT of the event loop into the state machine and there wait in a loop on the button value to change. But to me this kind of defeates the purpose of the event handler loop when I have to place GUI user buttons outside of it to take care of certain things.

 

4) If you look in the wagner force gage subVI and look at the I have wired an empty I/O port to the shift register. It tells me I need something wired, even though I do not want it in this case. I do not think I handle it the right way (the reason for this is that when i step through the program I have to manually close this subVI and it won't finish it when I step through it. I am thinking this is because of the shift-register, but I am not sure).

 

5) Anything else you can think of?  Overall I just think the code looks very messy now.

 

I know I am asking for a lot of you to look at this and answer this, and frankly, you have given enough help so far so if you do not have time or feel like looking at it again, I understand.

 

edit: I might quickly add what  I am trying to achieve. I have this program start up. I am wait for the user to press connect. When this happens, all the serial/whatever devices should start connecting. If ANY errors occurs, the program stops and puts up an error code. If no device fails connecting, the program should start several parallel loops running and fetching data from each device. In the meantime the user should be able to input things into several GUI buttons and fields; which can affect how the program behaves e.g. stop certain loops.

Message Edited by Siniz on 10-07-2009 04:08 PM
0 Kudos
Message 15 of 34
(3,617 Views)

Siniz wrote:

Mark, I am making some slow progress here, but I have run into a few hurdles that I need to pass. I have attached a zip with a file with VI files.

 

Some questions:

1) How come the error? in the event structure never gets registered when I change the value in my error handler? Because of this, the event loop never stops and I have to abort the program execution via the built-in LabVIEW button.

 

2) The wiring gets messy with notifiers and queues. To me the code feels much less userfriendly than if I would have gone the route with e.g. global vars. Is this a common problem or am I doing the wiring in a funky way?

 

3) I had some trouble figuring out on how to handle an event (the Connect button pressed) and to pass this to the state machine loop. I am now using a notifier, but to me it gets messy with all the wiring. Is notifiers the correct way to make states in the state machine wait for user input, or do you know another way? I was thinking that moving some buttons OUT of the event loop into the state machine and there wait in a loop on the button value to change. But to me this kind of defeates the purpose of the event handler loop when I have to place GUI user buttons outside of it to take care of certain things.

 

4) If you look in the wagner force gage subVI and look at the I have wired an empty I/O port to the shift register. It tells me I need something wired, even though I do not want it in this case. I do not think I handle it the right way (the reason for this is that when i step through the program I have to manually close this subVI and it won't finish it when I step through it. I am thinking this is because of the shift-register, but I am not sure).

 

5) Anything else you can think of?  Overall I just think the code looks very messy now.

 

I know I am asking for a lot of you to look at this and answer this, and frankly, you have given enough help so far so if you do not have time or feel like looking at it again, I understand.

 

edit: I might quickly add what  I am trying to achieve. I have this program start up. I am wait for the user to press connect. When this happens, all the serial/whatever devices should start connecting. If ANY errors occurs, the program stops and puts up an error code. If no device fails connecting, the program should start several parallel loops running and fetching data from each device. In the meantime the user should be able to input things into several GUI buttons and fields; which can affect how the program behaves e.g. stop certain loops.

Message Edited by Siniz on 10-07-2009 04:08 PM

Here is a modified version of your application. This should give you something to start with.

 

To answer your specific questions:

1. In your first attempt at the code you were not truly linking your various tasks with notifiers and events. My example has either event messages posted to a queue or a user generated event to keep all the tasks synchronized.

2. See the example that I have attached. Wiring can get messy but with a little bit of effort and practice you can keep things pretty clean. If I were doing this application I would most likely make the state machine and error handling tasks subVIs. That would help to clean up the diagram even further.

3. Again, refer to the example I posted. You will see that the UI task catches the button presses and then sends the appropriate message to the state machine via a queue.

4. Tunnels must always be wired in a Case statement. That was not what was causing your problem. I am not sure what exactly was causing that but it definitely was not the shift register.

5. Yes, I would agree that your code is a bit messy. As I stated above you simply need to put the effort into keeping it looking clean. With experience this becomes much easier.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 16 of 34
(3,606 Views)
I should have posted this screen shot last night when I posted the code.


Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 17 of 34
(3,596 Views)
Thanks Mark, I was busy yesterday and today but I will start afresh this coming Monday. I took a quick peak at the code and realize you just gave me even more homework haha (never used the Generate User Event block). I see you put in quite a bit of effort into this, so yet again, thanks!
0 Kudos
Message 18 of 34
(3,579 Views)
You're welcome. And it didn't take too long to throw this together but I hope this gives you something solid to build on.


Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 19 of 34
(3,576 Views)
I have one question though about the zip file I posted: Why does the event case not register when the boolean for the error? front panel object changes? I do have it as a case in the event structure.
0 Kudos
Message 20 of 34
(3,574 Views)