The JKI State Machine makes it’s public debut

[battler.]

The problem I'm having (no doubt - simple for some):

The 4 apps use their own User Events, which are created on their respective block diagrams.

How can I create a User Event for each of the 4 sub-apps which the Main app can use to pass commands?

I'm having trouble passing the user event ref..

[TCPlomp]

Here's a demo to use one user event with multiple event structures:

You can feed the event ref into the sub-vi. The registration is done inside the event.

Ton

[battler.]

Thanks Ton but..

That would mean that I would need to have another (2) event structures in my sub-apps(vis); 1 for the user events already registered on thier BDs and 1 for the 1 which is generated by the main app.

What is a way of avoiding this? (I don't think it would even work)

To explain again:

1. The subVIs are SM with their own user events and Reg Events on their BDs.

2. I want to be able to Generate a user event from the Main VI to send each of the subVIs commands.

Dilema - I cannot merge the Reg Events already on the BD of the subVI with the Reg Events I pass into from Main app using control.

[gchristi1]

I'm glad this thread has been revived. I haven't looked at the JKI template since the original post. My LabVIEW proficiency has advanced since then. It was interesting to take another look from a different experience perspective.

Being able to add arguments is clever, but if I anticipate needing arguments, I'll bundle a variant with the state and use queues.

battler, instead of a user event, I would use the subvi's queues. Don't know if that is the solution the experts would recommend, so I'll be interested in reading the responses to your problem.

[Ben]

---

gchristi1 wrote:

...

battler, instead of a user event, I would use the subvi's queues. ...

---

I use the queues myself.

The exact details depend on the app but a common pattern I use makes the "Idle" state do double duty. The "Idle" state is in most of my state machines because since I like to make sure the developers don't write code tha goobles up CPU.

Inside the Idle state, I use the timout that we would normally apply to a "wait" to control the time Out from the "Dequeue".  If the Dequeue times out, I ignore the queue and just do the normal stuff. If the queeu did not timeout, the data is acted on as dictated by the app.

THis gives my background thread good responsiveness (as fast as a queue entry can propogate) while also keeping the CPU load low.

Ben

[TCPlomp]

A trick I never new worked:

You can merge event registration refnums with a 'insert into cluster'.

But my proposal was to have the Event Registration inside the sub-vi, so it should not be a problem.

Ton

[battler.]

---

TCPlomp wrote:

But my proposal was to have the Event Registration inside the sub-vi, so it should not be a problem.

---

So on the BD of the subVIs I register another user event which the main VI can use... correct?

But, how does the main VI use(generate) the event?  I need the output of the Create User Event which is on the BD of the subVI...

[battler.]

---

Ben wrote:

THis gives my background thread good responsiveness (as fast as a queue entry can propogate) while also keeping the CPU load low.

---

Making the timeout terminal on the event structure in the Idle case IS going to make my application slower.. correct?  Previously, the timeout = -1 and therefore is not polled.

Suppose I wire the event structure timeout with 200(ms), then every 200ms when the subVI is in the Idle state it will run the timeout case; which is more CPU intensive than if it didnt (timeout = -1).

A user event would be more efficient, would it not?

OBJECTIVE:

Add commands to the JKI SM queue(string-based) in a subVI (dynamically called) from the Main VI.

Message Edited by battler. on 05-07-2010 05:29 PM

[TCPlomp]

Here's my idea of such a structure:

I have placed the same VI twice on the Main BD. The inner Snippet shows the code of the sub-vi.

As you can see the only addition to a standard VI is that I added an Event registration and a cluster bundle function to a normal VI.

Good practice would be to register in the 'Data.Initialize' state and unregister in the Exit state. Destroy the user event in the Main VI's 'Exit' state.

Ton

[battler.]

You can merge Reg Events using cluster Bundle - Thanks Ton!

Which method should I use?

1. User Events

Adv - less CPU intensive

Dis - Event Reg control required for each subVI, control needs to be dynamically Set with Reg Event in Main VI

2. Queues

Adv - can just use the queue name to add, no controls

Dis - more CPU intensive since use of Timeout frame of Event Structure required

If you can add to these Adv and Dis then please do.

I would normally opt for the User Events but in this case I'm tending towards the Queues.