"Auto" file naming with clusters

[Mark_Yedinak]

Here is a 2009 version.

[GradStudent]

Thanks for the advice.  I've made changes to the Stop button so that it invokes the stop state.  I've also made a control instead of a typedef for the ENUM. I've tried doing some reading (and YouTube watching) on the different types (typedef, control, etc.) but I haven't found much to thoroughly clarify differences.  I'll consider your suggestion about a subvi. 

So, I now have another problem.  Before, I couldn't get the File Dialog to stop asking me for a file path.  Now, it won't execute.  I've put it in a Case structure so that only when a test button is true will it execute.  But, even when the case is true, it will not execute.  I get Error 118 saying that the supplied folder path does not exist.  I don't think the error occurs when you first run the first test, however, afterwards it starts to occur.  It could also be that I used shift registers to try and link the file path from state to state. 

I've attached my code below along with the .ctl file for the ENUM and screen shots of the Idle and File 1 states for those who have an earlier version of LabVIEW.

[GradStudent]

File 1 screen shot

[Mark_Yedinak]

You should use typedefs for your ENUMs. The primary difference between a typedef and a control is that a control is a single instance. If you put 10 constants of this control on your block and 10 controls/indicators on your front panel each will be a separate, distinct entity. If you modify the control (such as add a "File 4") you will have to make that modification to each and every instance of that control. If you use a typedef you only need to make the change once, in the typedef definition. Every instance of this will be updated automatically.

As for your state machine you didn't seem to make any real changes. Your state machine is actually more like a sequence structure. State machines use logic to decide what state should be run next. In addition, you never call your stop state to check the whether the Stop button has been pressed. The reason I suspect your logic isn't working to display the dialog box to save the file is that the mechanical action on your buttons is set so that once the button has been read it returns to the FALSE state. Therefore you read it in and by the time you test it the values are different.

I would take a look at the style guides. Your code is rather messy (wires running backwards, lots of unnecessary bends, objects on top of wires, etc.) and could stand to be cleaned up. Much of the code in your Filex states looks like it is duplicate. This means they can either be made into a subVI or a state itself. For example, you can have a state that is called "Initialize DAQ". The code you have in your While loops could be a single state (Collect Data). When you run that state get your data, see if you are complete or if the Abort button has been pressed. Depending on those conditions chose the next state. This will either be the Collect Data state again, the Write Data to File (a much better name for that than burying this in the "Idle" state, or a true return to the Idle state.

I don't have time to go through the code and make the changes at this time.