Event structure and initial conditions

[rurban]

Hi,

I have been using event structures for years, yet I am having some difficulties to process initialization via events.

I am using an event structure to acquire images from a camera.  I have set very short timeout (1ms) so images are acquired as quickly as possible (cca 8 fps).  I have set up several events to change number of frames to average, exposure time, and image display brightness (via 8bit mapping and "given range").  The entire case structure is enclosed in a while loop.

In the past, I would set up an initialization to set all these parameters BEFORE entering the while loop (and thus starting to process the events).  This works.  However, it duplicates everything in a way; I have to code it for init script AND inside the case structure.

So, I tried leaving it ONLY inside the case structure and limit my init script to "value (signal)" to forcibly running the events I need (setting exposure, averaging, etc).  However, it seems that "timeout" (it means image acquisition) executes several times BEFORE all forced events are done.  This breaks the code, since necessary parameters are not set (actually I set dummy ones and watched the execution sequence ... and it's wrong.

I know I can always fall back to my initial code and duplicate some parts, but I was wondering, is there a way to do it via event structure only?

Thank you,

Radovan

[RavensFan]

Why not wrap the intialization in a subVI?  Call the subVI before the loop and also call it in your Init case.

What you could do put the timeout value in a shift register and wire that to the timeout node of the event case.  Initialize the shift register with a -1 for an infinite timeout.  Wire that through all cases of the event structure.  When you are done all the code you and you are ready for the timeout case to run, then feed a 0 into the shift register to thus enable the timeout case on the next iteration of the while loop.

[rurban]

Well, now that's clever :-).

I am not crazy running yet another shift-register highway through all cases, but it will work I think.

Any other solutions?

Thanks,

Radovan

[rurban]

Actually, I am not sure how to make that work; sorry I spoke too soon without actually coding it.

The very same events used for initialization will be used later for legitimate value changes on-the-fly.  I am not sure how to distinguish those.  Moreover, I was planning excuting several events as part of init sequence ... back to square one I think :-).

Thanks.

- Radovan

 PS> Sorry for the extra post, I could not figure our editing the previous post ...

[Mark_Yedinak]

Well, as much as I don't regularly like using them, you could use a functional global to store the timeout value. That way you don't have to run the wire through. However, if you have too many shift registers now, I wonder if there isn't room for improvement of the overall code.

I alos wonder if it is a good idea to combine your image capture with the UI handling. Any UI stuff will impact the image capture. Should tehg image capture be its own dedicated state machine? Do you disable configuration changes while you ar eactively capturing images?

If you keep things in a single event structure ytou can always create a user event such as "start capture". This woudl be fired once you initialization is complete and would trigger the image capture to start as well as change the timeout value for the event structure. I would add a corresponding "stop capture" which would set the timeout to -1 as well.

[JÞB]

So I'm just going to ask you have you ever looked at the template for a queued message Handler?  That's right you need two loops! one to handle the events that deal with the user events

and one too deal with the stuff you wanted to do to the stuff you want to do it to.  And a queue to pass messages from the event to the loop that acts.

Kudos for links to my post tagged Grandmas house.  (Or a trip to Grandmas.....)there should even be cross links to help with finding File>>New...From Template Producer Consumer (Events)

@The OP! A producer Consumer Queued Message Handler is what I believe you need.  Search "QSM" and "QMH"  meaning Queued State Machine and Queued Message Handler.   A bit of Googling will help. 

[altenbach]

---

@rurban wrote:

So, I tried leaving it ONLY inside the case structure and limit my init script to "value (signal)" to forcibly running the events I need (setting exposure, averaging, etc).  However, it seems that "timeout" (it means image acquisition) executes several times BEFORE all forced events are done.n

---

This makes no sense. Can you show us some simplified code that demonstrates this behavior? Obviously, the timeout should NOT activate while there are still events in the event queue. (e.g. are you sure to queue up all signaling events before the toplevel loop starts using e.g. the error wire? Is the timeout event shared with other events?)

[mcduff]

---

@rurban wrote:

Actually, I am not sure how to make that work; sorry I spoke too soon without actually coding it.

The very same events used for initialization will be used later for legitimate value changes on-the-fly.  I am not sure how to distinguish those.  Moreover, I was planning excuting several events as part of init sequence ... back to square one I think :-).

Thanks.

- Radovan

 PS> Sorry for the extra post, I could not figure our editing the previous post ...

---

Look into the JKI State Machine. It has an event structure inside of a "String Queue Messaging" while loop. In the JKI setup your events can point to specific states and you can reuse those states without resorting to signaling property nodes for a startup procedure.

mcduff

[rurban]

Hi,

Thank you for your input; it's greatly appreciated. I always learn something new.

I have created a simplified version of my init procedure (attached) as described in the original post above. I have added ample comments alongside the code to explain the ideas behind the implementation.

Basically, I have to make sure the specific events, "Control 1" and "Control 2", and more if needed, are executed BEFORE the VERY  FIRST "timeout" event containing image capture and processing. I have added loop counters to verify the initial order of execution.

I must say it seems to work now. 🙂

The only reason for not working before was absence of strict flow control (sequence) before the main while loop.

If you have any other comment and/or suggestion I greatly appreciate those ...

Is there a reason this SHOULD NOT work?

Thanks,

Radovan

PS. I have saved it in version 17 for greater compatibility (from v20).

[Mark_Yedinak]

It may work but it would not be the way I would go about it. I would have a queued message handler acting as the primary state machine controling the application. JKI's state machine would also work. I would probably have a dedicated loop with an event structure handling the UI stuff. I would have a dedicated loop which would handle your image capture. I very rearely use value signal property nodes to initiate any actions. The vast majority of my applications are all message based systems which trigger actions in state machines. The UI loop simply sends the appropriate messages to the main state machine. If you handle the UI interactions in the same loop as your image capture, there is a very good chance your image capture processing will be impacted by user interactions. Also, it is important to note that the timeout event in an event structure only fires if no events have occurred. If others events are being triggered, your timeout event will not fire and you will not perform your timeout code as expected. In your case, you would not capture an image. This is a strong argument for separating your image capture to a dedicated task.