State Machine Architecture Generator NEW!

[PrimaryKey]

PLEASE RATE AND COMMENT THE TOOLKIT. PLEASE PROVIDE INFORMATION ABOUT FEATURES YOU WOULD LIKE TO SEE.

This is the first version of the API for a scripted generator of state machine based architectures. This API allows you to define the architecture of your application, including inter-thread communication, and generates all the VIs for you using templates.

Features:

- allows defining structure of a state machine based architecture with multiple loops communicating with each other using queues

- the element definition for the communication queues is a string + variant for maximum flexibility

- generates architecture (all VIs) based on a definition created in the API

- allows to save and load from a tab delimited text file with the extension .txt (State Machine Architecture file)

- the .txt files can be modified and created in any spreadsheet application allowing for definition of the architecture to be created manually

- provides a method for evaluating if the created, loaded design features any commands that do not have a target state machine to which they should be sent, thus minimizing the time spent searching for flaws in the communication design

- visualization in a tree indicator for the architecture

Pic 1. Example code that generates multiple state machines with the same states and commands and saves the architecture to text file.

Release notes of version 1.1.0.15

- added polymorphic VIs for adding state machines, states and commands

- added licensing information

- added link to the homepage on NI Community

Release notes of version 1.1.2.17

- Added functionality to not load a line during loading of architecture from spreadsheet, if that line doesn't have state machine, type or state specified. That would make that line invalid and invalid lines are ignored.

Release notes of version 1.2.1.24

- Added functionality to visualize the architecture in a tree view. It's an extension of the Evaluate Architecture method. This is reference based. You need to provide the tree reference that you want to update.

Release notes of version 1.2.2.26

- Changed the file extension from .sma to .txt to make it easier to select, edit and open the architectures.

- Updated and rewritten some code to make it more readable.

- Changed description of some VIs.

- Changed the name of tree reference to tree view in the evaluation method and added documentation about it.

Release notes of version 1.3.1.29

- Changed the create method not to remove the existing elements in the target folder.

- Changed the behavior of generator when he is asked to generate empty state machines. He will do it and he will leave the  template cases inside for user reference.

- Added the presentation "SMAG Introduction" to examples for the package.

Release notes of version 1.4.0.30

- Added examples to the example folder created by the package: Simple State Machine, Advanced Architecture, Load Test and Loading SMA from File.

Release notes of version 1.5.1.34

- Added initialization of queues in the main to prevent any race conditions from threads not starting at the same time and to make it easier to send intialization commands to threads.

PLEASE RATE AND COMMENT THE TOOLKIT. PLEASE PROVIDE INFORMATION ABOUT FEATURES YOU WOULD LIKE TO SEE.

[jtagg]

Interesting idea. I haven't tried much with it, but here's my initial feedback.

1. rename the polymorphic text (OSM, OS). I understand it keeps things shorter, but I find them cryptic.

2. the relationships between state and command could be clearer. I had to run it before I understood what the command really did (does it come from the specified state or to the specified state...)

3. Nice that it uses a simple text file to save description. Makes it easier to share and modify configurations.

4. Clean and consistent use of icons.

[edited to add points]

[PrimaryKey]

Thanks for reviewing the API

About your second point, what naming convention would you choose to make it more clear that it's a command going to that target state machine?

[jtagg]

I'm not sure what the best way to put that would be. The term command might be the culprit here because I was expecting the term transition to pop up somewhere in the API. I understand why you don't call them transitions because there are possibly multiple state machines which communicate with each other.

I'm finding more and more that we call things state machines which probably shouldn't be called state machines. I think the distinction between queued message handler (choose your favorite name) and state machine is important and the concepts of both often get merged when they shouldn't as well. I haven't looked into the API deep enough, but this may be what is bothering me.

[PrimaryKey]

The thing is that I wanted to chose a name that makes sense to everyone and is not as long as "Queue Driven Message Handlers Architecture Generator". I agree with you that state machine might be misleading to some but I think it's more clear than not for most. I'm open to namig suggestions or any other ones you can offer.

[Doug]

Hi Piotr - Any chance you can re-save for LV2013?

[PrimaryKey]

I will instal some earlier version of LV and convert the package next week. Probably it will be LV 2011 but i have to check because im not sure if the VI Scripting functons were the same.

[vtphotonics]

Piotr,

I like this idea! I don't see it in the VIPM. How to get it into the Addons section?

[PrimaryKey]

just download the .VIP package from here and install. It will be in addons after that

[vtphotonics]

Hmmm...I don't see a .exe or anything similar in .VIP. Just lots of VIs. Drag and drop? How exactly do I "install" this? (I know, I know, this is basic stuff...)

[PrimaryKey]

does this movie help? https://www.youtube.com/watch?v=SNAaKTpA5I0

[vtphotonics]

Yup! Thanks for the video link! I haven't used the VIPM before, so I needed the step-by-step!