07-15-2014 01:59 AM
So for those who suggested using a state machine, why would it be a better choice, I mean in my case? Code readability and maintenance?
I know that when the execution of a certain task depends on the outcome of another task (and there are multiple states involved), then state machines are designed for that.
But in my case, once the user selects the data files, then ALL of the following steps must be done irrespective of the previous state.
1. table summary - placed on page 2 of my tab control container
2. type A plots - placed on page 3
2. type B plots - on page 4
4. type C plots - on page 5
5. Output the table and plots into ppt.
What is wrong with a flat sequence? what is the appropriate use of a flat sequence? I know someone must be thinking "flat sequence = amateur, state machine = pro :))
07-15-2014 02:12 AM
@murchak wrote:
So for those who suggested using a state machine, why would it be a better choice, I mean in my case? Code readability and maintenance?
I know that when the execution of a certain task depends on the outcome of another task (and there are multiple states involved), then state machines are designed for that.
But in my case, once the user selects the data files, then ALL of the following steps must be done irrespective of the previous state.
1. table summary - placed on page 2 of my tab control container
2. type A plots - placed on page 3
2. type B plots - on page 4
4. type C plots - on page 5
5. Output the table and plots into ppt.
What is wrong with a flat sequence? what is the appropriate use of a flat sequence? I know someone must be thinking "flat sequence = amateur, state machine = pro :))
Ok let me make it clear.
State Machine: Have a error handling case and exit thrugh that quietly and you don't have to execute any other case when error occurs.
These are only a very few situation where you will feel the importance of the State Machine. I am not saying you cannot use the Flat sequence but from a Modularity stand point using the State Machine design pattern is the wise choice.
Feel free to comment.
07-15-2014 02:32 AM
Since I know the nature of my task at hand, I know I won't face the situations you described, at least not now.
But there is no way I would argue against the power and flexibilty of a state machine. You have good points
and I will try to convert my code to follow the state machine design. I can't argue against good code design.
This is similar to the case made for using the C++ standard library whenever possible.
07-15-2014 02:39 AM
BTW, some of my plots and even the data table require extensive use of property nodes for formatting purpose.
Do the property nodes need to be placed in the same state as the object (either plots or the table)?
07-15-2014 02:47 AM
07-17-2014 01:12 PM
Hi Anand,
I've been updating my code and converting to a state machine. Although I am not facing any significant problems, I do have some questions regarding the design of the code and best practices.
Since a picture is worth a thousand words, see the picture below. I also added the VI associated with the picture.
A few questions:
1. Where does it make sense to place the File Dialog? Outside or inside of the While Loop? Inside any case structures?
2. Does it make sense to create two Enum types, one for different states and one for file type? See the picture below.
3. Does the state machine that I have created have a "correct" or should I say "sensible" design? What should be changed?
4. What is the best way to propagate A files and B files to different states? Brings me to my questions 1.
My thought is that if placed the File Dialog inside the case structure inside the While Loop, then I would have to use Shift Registers to propagate them to different states (waste of memory?).
Any thoughts or suggestions?
07-18-2014 01:19 PM - edited 07-18-2014 01:20 PM
Hello,
As I'm sure you're aware, there are usually multiple solutions in programming. If the two different file types require different functionality, I would have different states for the different file types. The case structure you implemented should work fine, too. It comes down to preference and functionality. If the file is only opened once in the beginning, place the file dialog outside the while loop in the beginning or in an Initialize state. If the user is able to select a file any time within the code, then I would have a "Select File" state. Also, I would have an "Exit" state, because you will need to close file references and things like that in the Exit State.
07-18-2014 01:39 PM
Two things:
The user selects the files once. So I'll place the file dialog outside the while loop. Pretty much the same analysis (with a few small exceptions) is carried on both file types.
One thing I have noticed is that sometimes the File Dialog won't show the new files generated in the folder. I can right-click and select Refresh and it still won't show the new files.
The files are clearly there, as can be seen with Windows File Explorer. I have to close LabVIEW and restart to see the new files.
07-18-2014 02:52 PM - edited 07-18-2014 02:53 PM
I have been unable to reproduce this behavior. I launch just the File Dialog Express VI, and I copy and paste a text file over and over again in the folder. Each time, the file appears in the File Dialog's file window. The update is almost immediate. I'm using LabVIEW 2013 SP1 on Windows 7. If you create a new VI with only the File Dialog function, do you still notice new files missing? Are these files located on locally or on a network?
07-18-2014 04:00 PM
Yes I do.
I believe my VI is corrupt. So that is why I copied all the elements from it, and pasted into a new VI.
I doing so, I also changed the architecture of my VI from flat sequence to state machine. It is not quite ready yet
for me to test the File Dialog. Due to work, I am still using my old VI and multiple times a day I have to restart LabVIEW to see the new files.
I'll update when the new VI is up and running.