Synchronization preference for State Machine with LV 2009

[Hobbs23]

My coding is inexperienced, I can make things work, but lack many of the basics. In my example below, I calibrate an older Prototype Signal Generator. Although very clunky, it works. I understand that If I were to learn one of the synchronization tools available in the basic LV 2009 package, I could simplify my vi, and remove many SR in the process. However many of the examples use versions or tools that are not available to me. 

What is the best sync method to use for my vi. I have benefited from your criticism of my practices before, and will buckle up for another education experience this time as well. Thanks in advance.  

[Hobbs23 · Accepted solution]

Since I can not find a way to delete this, maybe I can be instructive to someone else. After not seeing any comments for a bit, I was wondering if I missed something. I went back to the help, and went backwards this time. Turns out, in the root of each sync vi, there is just enough info to indicate they are not all basically different ways of doing the same thing. Each has a specific task, and reason to use it. 

The answer to my question, Queue is primarily what I am looking for, but the others are useful if the need arises. So much for the good butt chewing for sloppy code. 😉 

[Kevin_Price]

Ummmmm, how do I put this?

Yikes!   Douible Yikes!   Triple Yikes!

Sooooooooooooo many shift registers.   Sooooooo many cases that don't wire them through.   Sooooooo many default values getting injected into the right-side SR's, defeating (most of) the normal purpose of SR's in a state machine.

Queues, awesome as they are, probably aren't what you should be focused on.  What you *first* need (IMHO) is a typedef'ed cluster to bundle many (all?) of your SR data elements together.  Sometimes it's helpful to organize some of these elements into sub-clusters inside the main cluster, which in turn should be typedef'ed.

Once everything is packed into a cluster that's retained in a single SR, you need to pass that cluster wire into and back out of *every* case and back to the right-side SR.  Naturally, some cases will need to modify a few elements using "Bundle By Name", but then you need to feed the resulting cluster to the case structure output tunnel.

The "Cal 201 points" case in particular cries out to be broken down into subvi's with more description.  (Granted, the terse comments present now are actually surprisingly good considering the code's excessive density and complexity.  But it'll be so much better to break it down into smaller bite-sized subvi's that leave room for more descriptive comments.)

-Kevin P

[Hobbs23]

Thanks Kevin

I was not aware that cluster could do that yet. I built this ahead of the next gen sig gen, and the code has not even been laid. Sometimes I don't wire the SR thru because I want it to forget if I am using a different function, 1% of the time, but it is mostly because I didn't use it during those runs, and so did not include it. (not best practice I guess)

I like that Idea, but need to learn more about how to do that.

Thanks again.

[Hobbs23]

I was going through a sixclear youtube video about State Machines. They talked about how to make a "type def" by right clicking on an Enum Constant, and selecting "Make type Def"... I have no such option. Using LV 2009 Basic, is that possibly why?

     Other than that, my existing Enum Constant does not give me that option, but is this an advantage that takes place when you are building from within a project? This vi is not in a Project.

     When I open a State Machine Templ. up, the Enum does give me:

-Auto-Update from Type Def.

-Open Type Def.

-Disconnect from Type Def.

     Clicking on these does not seem to give me anything close to what the example was, and I could not decipher from the video, what the benefit was in doing it.... other than he was grateful. 

🙂

[Kevin_Price · Accepted solution]

IIRC, circa LV 2009 the way to make a typedef out of <whatever> is to right-click, and then choose "Advanced-->Customize...".   Then in the window that pops up, you change the thingy that says "Control" to "Typedef".  At some point you'll have to save it to disk.

You can do this with a simple enum.   You can also do this with a cluster containing all kinds of different stuff, including that same enum and a whole lot more.

-Kevin P

[billko]

It seems that you have the desire to become more than a LabVIEW hack.  After completing the tutorials, get the LabVIEW Style Book by Peter Blume.  It's old, but all of the things it talks about are still extremely relevant today.

I'd also try to get some formal training under your belt, if possible.

[Hobbs23]

Took quite a bit, but I think I either have it, or at least I am close.

-Right click on Enum Constant on BD, and see Advanced is greyed out.

-Select instead to change to Control.

-Going to FP right click on Enum Control and then click Advanced, and Customize.

-Another FP opens, Select from the drop down menu, "Type Def.".

-Now you have to make enough changes to the coltrol to get the proper save options.

-I removed the up/down arrows, and edited my beginning selections.

-Now the "Apply Changes" selection is available from the file menu, so select it.

-At this point I decided to save it to user lib? and close that window.

-Now in the Original BD, I right click the Enum Control, and change it to an Enum Constant.

     Now in the right click menu for the Enum Constant, my choices are as follows.

-Auto-Update from Type Def. (this is checked)

-Open Type Def.

-Disconnect from Type Def.

There does not seem to be any visible indicator that the "type" has been changed.

Two questions remain at the top of my list.

Did I save it right, and in the right place?

Will I have to include the saved file with the vi, when transferring it to the bosses computer?

[Kevin_Price]

- It sounds like you saved it right

- But probably not in the best place.  User.lib is more for things that every LabVIEW vi you ever work on will be able to use.  This custom typedef is likely unique to your present application, so I'd recommend saving it into the same folder hierarchy as the project you're working on.   (Specifically, with the project that uses this typedef open, open the custom enum and select "Save As..." and then chose "Rename" and put it in your project folder.  Doing it this way also updates any vi's that use the typedef and updates their links to it.)

- Yes you will need to include this .ctl file as part of the source code you deliver

- I'm not sure I remember clearly, but LV2009 may not have shown a distinct appearance on the block diagram for typedef'ed controls and indicators.  Recent versions have been showing that for a while, not sure how long.

-Kevin P

P.S.  Making a typedef for your custom enum is a good step.  But it's a small step.  The bigger gain will come when you can organize all those individual SR's into a very small # of SR's (1 is probably the best choice) that hold a typedef'ed cluster which contains distinct items representing each of today's individual SR's).   You'll access those distinct items using "Unbundle by Name" to read and "Bundle by Name" to write.

[Hobbs23]

Thanks Kevin

     In video training, you can't ask why. So if they don't tell us why, and it is a pain, then it doesn't always get done. The Engineer/owner in this case started the simple vi, and didn't see the need to start a project. I don't remember hearing any benefits, and there are lots of moving the vi from computer to computer, Engineering both the product and the Labview testing platform at the same time.

     So if there are lots of benefits, and many less down sides, then when I redo this vi, I will start it in a Project. Just seems a lot more complicated for what. 🙂

_As far as bundling, and Clusters, I am watching the video's at sixclear now. Hopefully I will be able to update the vi before I need to get back on the bench. The last time, I was gone from LabView for almost a year.

Let the beatings begin! 😉