10-05-2009 05:38 PM
10-06-2009 08:34 AM - edited 10-06-2009 08:42 AM
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)
10-06-2009 09:27 AM
10-06-2009 09:59 AM
10-07-2009 04:02 PM - edited 10-07-2009 04:08 PM
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.
10-07-2009 08:56 PM
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.
10-08-2009 07:37 AM
10-09-2009 02:19 PM
10-09-2009 02:33 PM
10-09-2009 02:42 PM