Using more than one event structure for the same control within a standard state machine

[sebster]

Hi,

I'm working on a test sequence using a standard state machine from the LabVIEW examples.

At part of my test, I'm displaying a waveform on a scaled graph. The input for this is from a PXI-4070 DMM. This runs in a 'while loop' to continuously update the waveform. The display simulates an oscilloscope. The test operator needs to perform an adjustment while looking at this display. This bit works and I have no problem here.

On my front panel, there is a button to 'continue' to the next part of the test once the adjustment has been made. Some changes are then made to the setup, and the next adjustment needs to be made in the same way, i.e. look at the display, make the adjustment, press 'continue. This is where I have the problem.

I've tried using event structures within the while loop to stop the loop when the continue button is pressed. This works for the first adjustment, but when the test gets to the second adjustment stage, the event seems to be 'remembered' and the loop terminates immediately.

Is there away of resetting the event so that the button can be used again in the correct way

Regards.

[GITA_A]

Hi,

         Just check with boolean Mechanical action specified for the Continue button,reinitialize the button  and one more thing is you cannot use 2 events for the same control.

         Hope this may help you.

[Ray.R]

Can you post your code?

R

[johnsold]

Using a single event structure will prevent that kind of conflict.  In the event case set a notifier or put a command into a queue (or multiple queues) to pass the information about the event to the state machine.

Examples of a queued state machine  and an event driven state machine are in the Design Patterns which come with LV.

Lynn 

[sebster]

I'll attach a simplified version of what I'm seeing.

All this does is count the number of iterations in the loop, until the continue button is pressed.

What I'd obviously like it to do is do test 1, counting iterations until I press to continue - then move on to test 2 to count iterations until I press continue again and so on.... But it doesn't.

How can I change this to get the behavior I need? I'll then be able to apply this to my test sequence.

Regards.

[nathand]

You'll need to restructure your code to use a single event structure.  When your code starts, each event structure starts listening for events, even if that event structure isn't currently executing (this is by design and a good thing, because it lets send events without worrying about whether the event structure is already active - you know that the events will queue and be processed when the event structure executes).  So, all 4 of your event structures start listening for events on the same Continue button, and when you press the button they each receive a notification that an event has occurred.  One possibility would be to create one case for all for Test enumeration values that includes the event structure, and then put another case statement inside that to handle each individual test case.  Also, you don't need both a timeout case and a Wait inside your while loop; just let the event structure timeout handle your timing.  If you're just waiting for an event to occur and don't need to count loop iterations, you don't even need the while loop and the timeout event.

EDIT as an added note:  I find that any time I need copies of a local variable in multiple cases, it's a good indication that I can combine the duplicate cases in a way that eliminates the need for a local variable.

Message Edited by nathand on 10-01-2008 10:01 AM

[altenbach]

You have some basic misunderstanding of event structures.

1. NEVER place event structures inside case structures. Event structures always queue up events, even if they are hidden from dataflow. An event structure needs to be able to service events within a reasonable timeframe. This cannot happen if it is hidden in another case and does not get serviced by dataflow. In addition, all your events are set to "lock front panel until event completes". Since most of your events can never complete, you get to a infinite deadlock.
2. Use latch action on the boolean. A boolean set to Switch until released (doorbell!) triggers an event on press AND on release.
3. Use the outer loop for everything and use case structures inside the event.
4. You can pace loops with the timeout of the event structure, so you don't need a second wait primitive.

Here's a quick modification. See if it makes sense. 🙂

Message Edited by altenbach on 10-01-2008 07:04 AM

[sebster]

 Hi,

yes, looking back at my example, I realised I didn't do the timing very well. It was just a 'quick and dirty' example to show what was happening. And I thought 'this is running too quick, so I'll slow it down with a 'wait'' - not even thinking that the timeout on the event structure would do exactly the same thing.

So now think I'm starting to understand about the event structure itself. But I'm going to need (a lot) more time to fully appreciate it's operation, and how to use it in this application.

I know it's probably a cop out, but I think I shall use multiple buttons in the same place on my front panel, starting with them invisible, and making them visible as and when I need them using property nodes. Not ideal, but it works and gives me what I want without too much time spent trying to get my head around this.

I will come back to event structures when I'm under less pressure to complete the test - honest!!!

Thanks for your inputs.

Regards,

Sebster.

((There are 10 types of people in this world - those who understand binary and those who don't.))

[nathand]

When you do get a chance to investigate event structures you'll probably find that the right way to handle this is to separate your event handling from your test sequence.  Put the test sequence in one while loop, the event handling in another, and use a notifier or a queue to send a message from the event handler to the test sequence.  This would allow you to do exactly what you were trying to do in the first place in an efficient way.  A very simplified version would look something like this.

 

EDIT: Oops, just after posting that I realized that if you code this as shown you'll have a similar problem, just with notifiers instead of events... set the "Ignore Previous" input of "Wait for Notification" to true and it should work.

Message Edited by nathand on 10-01-2008 12:29 PM

[altenbach]

---

sebster wrote:

I know it's probably a cop out, but I think I shall use multiple buttons in the same place on my front panel, starting with them invisible, and making them visible as and when I need them using property nodes.

---

Voted "worst idea ever". Don't do it! 😮