Queues within an event structure...

[johnsold]

James,

... do state machines not loop endlessly (albeit with a default blank state)?

Yes.  If the blank state includes a small wait or just waits for a new element in the command queue, very little CPU resources are required.

... were I to implement a state machine, it would go where I now have a normal case statement in the Test Procedure while loop?

Yes.

... The Test Procedure is by far the longest and I want it to run when called, but once it's started for it to run on its own.

If it really needs to run independently, it can be controlled through the VI server.  Depending upon what it actually does, it might be reasonable to keep exiting and returning to the same Test Procedure state until it is finished.  On each iteration of the loop, the queue can be checked for higher priority commands (like Halt!), the graphs updated, and errors checked.  This approach is a bit more complex, but allows the state machine to be very responsive.  Another approach is to make Test Procedure a parallel loop with a simple state machine.  The loop runs all the time, but does nothing until the Start Test command is received.  The state machine might have as few as two states: Idle and Test.  The data would be passed via queues as you are now doing.

I have put together several systems with three loops.  The first is a GUI loop with event structure and queues and very little else.  The second loop is a state machine and does most of the number crunching and control logic.  The third loop is also a state machine which handles I/O to hardware.  If there is a lot of File I/O, I have been known to put that in its own independent state machine loop as well.  All loops are interconnected by pairs of queues.  No local variables.

You may have noticed that I tend to like state machines?

Lynn 

[J.Mamakos]

The test takes about 5-10 minutes and merely rattles through several different frequencies and power levels for the unit under test, and records the output(s). There is already an 'emergency stop' in the main test subVI (the one with an icon that looks remotely like an old-style meter).

I am now using a state machine in the area you suggested, and it accounts for all the main 'actions' of the VI. I do have one problem though... How can I only allow the Test Procedure to happen if the SetUp has happened at least once? Both are included in the state machine. I actually have a few cases like this, but this example is the most important.

Also, what exactly is the VI server and how/when/why is it used?

Message Edited by James Mamakos on 07-02-2009 12:12 PM

[RavensFan]

Maintain a boolean value on a shift register.  The initial value will be false.  Within the Setup state, wire a true constant to the shift register.  All other states just wire the value through from one shift register to the other.

In your test procedure state, check the value of the shift register.  Only allow the test procedure to run if the value is True.

[johnsold]

James,

Ravens Fan said it well.   This is a very common procedure in state machines.  For more complex cases you can also use type def enums rather than boolean.  For example suppose that both initialization and a login were required to occur sequentially before the test could run.  You could use several booleans or an enum with values like Uninitialized, Initialized, Logged in, Running, and Complete.

Vi server relates to the use of properties and methods  to control what a VI is doing.  Using the VI server, you can launch aVI to run independently from the VI which called it.  And many other things.

Lynn 

[J.Mamakos]

Having developed this further, I can't help wondering about a couple of local variables I've got.  I have taken a snapshot of the BD when it is closing due to an 'Application Exiting' event being triggered.  I have a write then a read local variable for the stop button, which I have highlighted on the picture.  Variable 1 should be written before variable 2 is read, but don't think there's anything actually forcing the issue.  It seems to work okay with the lightbulb on, but is this a potentially problematic race condition?

Please advise. Thank you.

James

 

Message Edited by James Mamakos on 07-09-2009 02:44 PM

[johnsold]

James,

That is the kind of situation which can often produce race conditions.   Because local (1) and the case structure with the Set Occurrence are parallel, in principle either could execute before the other.

To assure that it does not occur, you would need to force the write to the local (1) before the occurrence is set.  You could enclose the local in a single frame sequence and wire the boolean value through the sequence and then to the case structure containing the Set Occurrence function (similarly to the way you read the local (2) below).

A better approach would probably use a separate queue or notifier to send a stop command to the Update Graphs loop or to incorporate that function into the Main processes loop state machine.

Lynn 

[J.Mamakos]

I now seem to have a couple of problems with my front panel (enclosed).

Firstly, I find that some buttons, although set to 'Latch on release' do not ping back once read but stay depressed as if they had a 'Switch on release' action. Is this a by-product of giving them an event case, or what is the likely cause of this?

Secondly, the 'NEW' boolean button seems to permanently have key focus, no matter which tab I'm on or where I'm typing. There are several arrays to be filled in on the SetUp tab whilst the program is running, and the graph scales can also be edited by typing a new value. To finish entering a value in either of these locations using only the keyboard, the 'enter' or 'return' keys must be pressed. However, this then also acts as if the 'NEW' button had been pressed thereby making the program embark on a lengthy process to create an Excel workbook. How can I stop this from happening and how did the 'NEW' button get permanent overiding key focus in the first place?

Thank you.

[johnsold]

James,

To get Latch action to work properly the button must be read.   The diagram you posted yesterday show all the terminals outside any structure.  Therefore, each control gets read exactly once, probably just as the program begins, for each time the program executes.  Move the terminals into the event cases for their value changed events.  The event case will respond regardless of where the terminal is located, but the latch action depend on the node containing the terminal executing.

From a picture it is impossible to tell why the key focus is there.  Did you set it manually or programmatically?  Do you change any other control's focus programatically?

Lynn 

[J.Mamakos]

That would explain the latching problem - I'll just put the controls in their respective events.

As for the key focus, at no stage throughout the whole development process of this program have I ever set the key focus of anything, which is partly why I'm confused as to why it's happening. In other things I've written there is initially no key focus to anything, so why there is now I do not know.

[Newton2this1]

Hi, this may be unrelated but I would like to concatenate two strings together continuously using an event structure.  I found the following example of how to continuously increment a number.  What would be the easiest way to modify this to concatenate two strings together?  Would a queue be needed?

https://forums.ni.com/t5/Example-Programs/Basic-Functional-Global-Variable-Example/ta-p/3503982