JKI StateMachine - A general query on its scaleability

[MogaRaghu]

Just completed the on line training course of the JKI-SM. Well at least now it  makes sense as many times earlier I have tried to do it myself and given up half way !

So far I have done many automated machine control  + data acquisition projects. The choice of hardware is the PCI-6229 ( for AI / AO )  and PCI-6514 ( for DI / DO ). Typical channel counts are in the region of 40 to 50 all together.  Giving the structure for one such project :

1. On successful Login a MAIN.VI  FP  opens. This has about some dozen buttons for user to choose.  It also has drop down menus to choose what product has to be tested. 

2. The MAIN also inits all the hardware and starts acquiring AI / DI data at about 50mS intervals and populates the values in  FG arrays as required. ( Many times I also have used Globals to pass data ) 

3. Based on the user choice  from the front panel buttons, I close the MAIN FP and load the chosen SUB FP.  The MAIN.VI runs at the background to read and write hardware data. 

4. Hence forth the chosen SUB VI  communicates with the MAIN VI through FG for data passing ( DI/AI data from MAIN and AO/DO data to MAIN ) . The SUB VI has a Queued State Machine architecture to carry out the actual testing and data logging work.  Once that particular test is over the user can choose to do another test or go back to MAIN and choose another SUB VI. 

5. Apart from above machine control VIs there are VIs to Configure the hardware channel data / Test data for acceptable limits and password maintenance etc. 

Finally this is the question : 

Can I implement the whole of above using ONLY the JKI SM ?  

[cbutcher]

---

@MogaRaghu wrote:

Finally this is the question : 

Can I implement the whole of above using ONLY the JKI SM ?  

---

Well, I'd suggest at least some subVIs...

More seriously, it's possible but of course you'll have to write some other code. Whether or not this lives within your description of "ONLY the JKI SM" is probably definition dependent.

Nothing you wrote in the points above sounds like it would necessarily be a problem (I'm assuming FG is Functional Global, more commonly written as FGV (variable)).

The use of global state is probably somewhat outside the bounds of a general state machine design (in which you'd more typically hold the state in the state machine) but it doesn't make it impossible - just something to consider.

The 5th point about maintenance and configuration sounds like it would be well suited to some sort of configuration management system, but you could certainly trigger their dialogs etc via the JKI SM.

If you like the look of the JKI SM, go ahead. If you don't, you can consider something else.

Most things can be made to fit a problem, and the JKI SM doesn't seem like a bad fit for your problem in my opinion. Hopefully I didn't miss some critical point!

[mcduff]

Pay attention to the advanced communication techniques in the course.

I often use multiple JKI State Machines that connected via User Events. This way you can set up independent process for each state machine, for example, one SM acquires data, another SM process the data, etc.

mcduff

[MogaRaghu]

@cbutcher

@mcduff

Thanks for responding. You have opened up additional avenues. Let me do some more ground work and revert.

Appreciate your help !