Jump to content
Jim C

JKI State Machine as subVI

Recommended Posts

I based a new VI on the JKI State Machine today. I'm developing an ATE that will use an FPGA to load a program into a UUT's flash and then handle generic digital IO. The host VI is going to be used stand-alone during development/debug and it'll be called by TestStand in production.

  • I've put a "Command" string control outside of the main loop to append to the Initialize macro on the first call; subsequent calls will start there, but only execute the new Command.
  • I've added "VI originally closed" to the cluster in "Initialize Core Data", so I can keep the VI running if I'm using it stand-alone. Otherwise, the Idle state will send it to "Macro: Exit" once all states are completed (it won't get to Idle until it's done, so it'll shut down at the first timeout).
  • I use a cluster of control references to avoid using local variables.
  • I use calls to Idle so TestStand can reach in and stop this VI with a LV2 global. (Omar, I didn't miss your comments in the LAVA forum. There's a thread here that says it's OK. :( ) I added a "Profile: Wait" state so I can handle long delays in the sequence without ignoring the UI (or calling program). (I use UI states to disable controls as appropriate to the sequence).
  • I use "UI:" states to disable controls at different points throughout the sequences without putting property nodes all over.

I'd appreciate any comments <_<... I'm not too far in to change direction.

 

Jim

 

BTW - Thanks for sharing this tool. This VI didn't take long to write and I'm confident that I can expand it easily when I (inevitably) find more tasks for it to perform. I'm going to start another project this weekend, and I'm basing it on the same template :) .

_MainFPGAControl.vi

Share this post


Link to post
Share on other sites
I'd appreciate any comments <_ i not too far in to change direction.>

Jim (C.),

 

I'm glad you're trying out the state machine, and even more glad that you're finding it useful.

 

I don't have the FPGA stuff installed on my system, but I can give you a few general comments on your VI. First off, a lot of what you're doing is basically correct. The suggestions I have are relatively minor and are more from a maintainability/readability standpoint. That having been said, there are some areas I think you can use the state machine more efficiently and improve your code:

jcarmody_statemachine_comments.png

 

Colors refer to markup in above attachment

  • (RED) Accessing the data in your controls & indicators by reference breaks the dataflow paradigm of LabVIEW and makes for hard-to-read code. My recommendation is to use controls & indicators only for getting input from the user, or showing information to the user. At all costs, I avoid using them as places to store information. What this means, in practical terms, is that rather than ever doing "real work" with the value of a control or indicator, I tend to store lots of information in the data cluster in the shift register. I use Value Change events from front panel controls to update the information in the cluster, and I use a UI: Update Indicators state (or similar) to sync the front panel indicators to the data cluster when necessary. This decouples the front panel objects from the data & code of the rest of your VI, but without breaking dataflow or relying on references.
  • (GREEN) I'm not a fan of using a numeric state argument to enable/disable controls. In a state name like "UI: SetDIODisabled >> 2", the "2" is a magic number, which hurts readability and maintainability. There are several possible fixes for this that various people might use based on personal preference:
    • You could replace "0", "1", "2" with better arguments, like "Enable", "Disable", and "Grey".
    • You could use a separate state for each condition and do away with the state argument entirely. E.g. you would have multiple states called "UI: Disable DIO controls" and "UI: Enable DIO controls".
    • You could store the "enabled-ness" of the controls in an element of the data cluster and have a state called "UI: Interlocks" that uses that information and acts appropriately. Then when you need to disable or enable the controls you would set the value of that element in the data cluster and then execute the "UI: Interlocks" state.

    [*](PURPLE) If you're going to have a string input for Command, I would make sure to have one VI for each possible Command and use the state machine as a subVI of each of those. This gives you a sort of API to call your state machine through and avoids the (mis-)use of naked string constants on the block diagram of whatever code calls this state machine.

As an additional note, I'm happy to see that you're in North Carolina! I live in Cary. If there's anything I (& the rest of JKI) can ever do for you, please let us know. We want to make sure everyone using our products is as successful as possible.

 

And finally, I want to make sure you're aware that there is an upcoming LabVIEW User's Group meeting in Apex on December 9th (next Tuesday, as I write this). We are trying to arrange to give a presentation on the JKI State Machine at that meeting (arrangements are still pending, so it's TBD). If you're from this area, or anywhere reasonably close, I'd love to see you at the meeting and talk to you directly!

Edited by Justin Goeres

Share this post


Link to post
Share on other sites

Justin, thanks for the great answer. I can implement your advice without much rewriting. (... and here I thought I was being clever using the references that way!)

 

And finally, I want to make sure you're aware that there is an upcoming LabVIEW User's Group meeting in Apex on December 9th (next Tuesday, as I write this). We are trying to arrange to give a presentation on the JKI State Machine at that meeting (arrangements are still pending, so it's TBD). If you're from this area, or anywhere reasonably close, I'd love to see you at the meeting and talk to you directly!

I have the User's Group meeting on my calendar but hadn't planned on going because the current topic is listed as "TBD". Would you let me know if it turns out that JKI is going to present then? I'm in the area (I work in Wilson and live in Selma) and would go for that topic. I worked for G2 up until this past May so I can find the meeting.

 

Thank you,

Jim

Edited by Jim C

Share this post


Link to post
Share on other sites

I have received confirmation from NI that we're good to go for the state machine talk at the Apex User Group meeting next Tuesday, 12/9. Official announcements will be forthcoming, but I wanted to let you know here.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.