The JKI State Machine makes it’s public debut

[TCPlomp]

There is a much bigger problem with the queue cheking in the timeout case. This might mean that you fill up your queue or handle them late.

You could check the size of the queue after the case structure and add a 'queue handler' in the message queue.

Ton

[battler.]

Please elaborate.  I don't understand.

Are you saying that a queue needs to be flushed?  Can't it be limited in size?  How would it cause late processing?

Could you post an example of a queue handler. 

Is it necessary to have a 'queue handler' for all implementations of queues?

[TCPlomp]

What if the timeout never happens?

There is no rule that the State Machine even enters the event structure. That only happens when the State queue is empty.

And if the event state is enetered LabVIEW will pick the first event on the event queue, and only if that is empty and the timeout has passed the timeout case will be executed.

So I would put such a code when using a queue:

Note that this puts the Get QueueData after the current message queue, you could also insert it before the current message queue.

Ton

[battler.]

---

TCPlomp wrote:

What if the timeout never happens?

---

But the Dequeue function has 0 connected to timeout.  If queue is empty and Dequeue immediately timesout then nothing "" is inserted into SM queue (string) which returns to Idle state.

---

TCPlomp wrote:

So I would put such a code when using a queue:

---

Where would you place it in the JKI SM?

The following image is what I think we are talking about:

What can go wrong with this?

Thanks,

Battler. 

Message Edited by battler. on 05-10-2010 07:12 AM

[TCPlomp]

Yes your dequeue has an empty timeout. But the event timeout is 200 ms.

And as I said earlier there is no secure reason that the State queue is empty at one moment.

Ton

[battler.]

I think I understand now Ton.

I wouldn't want a command sent to the queue from the main VI to interrupt the sequence running in the subVI.  I can avoid this by adding commands to the end of the queue (string).

However, with this added complexity, the user event approach is possibly more attractive.

The user (dynamic) event method should avoid these issues.

[battler.]

User Events - Having trouble with some commands being sent are lost.

Does the JKI SM need to be in "Idle" state for User Event to work?

Ton, are you still recommending User Events or should it be Queues?

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

[TCPlomp]

I don't really have an opinion sometimes I pick a queue and sometimes a user event.

However you should never lose events.

The event structure should return to the 'Idle' state to handle events.

It should receive every event sent after it registers for the event.

Ton

[battler.]

I have found a continual source for crashing LV 2009 (SP1) using the JKI State Machine.  To replicate:

1. Open new VI and drop JKI SM onto BD.

2. Save the VI.

3. Go to any of the States, right-click case structure and select Add Case.

4. Undo add case by pushing Ctrl+Z.

(continue with steps 3-4 a few times until crash)