LabVIEW
Converting VI to State Machine
It was kindly suggested that I convert my VI to a State Machine, allowing me more flexibility in the future. This is a good idea! The converting task involved a lot of re-thinking and learning but it is starting to work.
I am trying to find out how the motor is set up in the State Machine - It is very different to my VI.
(The original VI takes a .csv file and sends it to a chart and graph. That is followed by sending the data to the SLEW command of the motor then the motor moves to the data. Before all that happens the VI set up the motor ports and settings.)
My current State Machine loads the file, chart, and graph. But I don't think the motor is setting up.
This is my original VI motor control
The motor is a Lexium MDrive NEMA 23
The MDrive has a IMS MDRIVE SET PARAM
This is the new State Machine:
Here is what is inside the IMS MDRIVE SET PARAM:
The question is:
How do I make the info in the original VI work in the State Machine?
I will attach the files as usual to help others.
Many thanks!
Mike
In the Init case you add the Motor port to the cluster wire, then you use your Set Param as normal but with Motor port from the cluster.
/Y
What it sounds like you are trying to do is refactoring your code, and good for you because of it! (bonus points for the JKI State machine in my book) Refactoring code is always one of those things that the end user, and even managers don't often see value in since in most cases the software does exactly what it did before. Of course the difference is a bit less tangible because it is hard to put a metric on how easily modifiable code is.
Anyway, the best person to make suggestions on refactoring code, or shoving it into a new design patter is the person who originally wrote the code. We can make suggestions on where the code should be doing what, but in the end we may give poor suggestions, not fully knowing what it should be doing or pit falls of doing one thing over the other.
You've probably found these already but here are some videos by JKI that describe some of the features of it and how to use it.
Remember there is nothing magical about the state machine. You are just putting data into a cluster (bundle by name) or pulling data out (unbundle by name). The data you want will only be available to the other state, if you bundled data into it, before attempting to unbundle. I think this is the suggestion Yamaeda was trying to make. For instance in your Read Spreadsheet file you aren't at the moment, doing anything with the read data. If you were you would be putting what you read back into the shift register so it could be used in other states. I notice in your "Data: Initialize" state you are reading from a file and putting it into that shift register. A better design might be to just leave an empty constant wired to that bundle function, and instead call the Read Spreadsheet state as part of your init. Then if you ever need to update your code to read differently, you just need to update the one case responsible for performing the read, instead of every place you do the read. This helps ensure the Smores principle. Basically saying how code should be Scable, Modular, Reusable, Extensible, and Simple.
