Good Design?

[heinesterhuyse]

I am not that experienced in Labview so would like to ask the experts.

I am writing a program, which uses a main state machine and I have multiple sub-Vi's with for each sequence of operation. Within the Sub-Vi's I also use a state machine structure for operation.

In the main VI, I use shift registers to pass data, each Sub-Vi has it's own cluster, containing Sequences and data. I also have variable clusters as well as well as the IO from the a DP DP coupler which is used in all sub-VIs.

These clusters are large in size, each containing Sub-Clusters.

The main VI contains about 15 shift registers

The program is working well, but I want to have a good design structure as well.

Any advice would help.

[.aCe.]

I am no expert, so wait until the experts comment. Here's my two pennies' worth:

Your program does sound intensive, having a state machine inside a statemachine may lead to an unresponsive UI. This could be because one of your subVI is trying to do something while the user presses stop button. So if user interaction is critical, you need to look at an event based producer/consumer design pattern.

You could possibly use FGV's instead of having 15 shift registers to pass data from one iteration to the other, if not bundle all of them in to a type def cluster to make the diagram a bit more readable (I havent looked at your code, so this is just an assumption). Use bundle by name and Unbundle by name to read and write elements in the cluster as this is more or less self documenting.

Try to use type defined data types (especially the clusters you mentioned) where possible.

Error handling is important as well, its also a good way to enforce data flow.

The other thing I would recommend is to go down the certification path as you learn a lot of best practices along the way.

[heinesterhuyse]

The previous code used FGVs, but I did have the problem of data getting over written causing signals not going through to the PLC, that is why I do not like FGVs.

This code was also messy as everything was just a big VI, so maybe I must just incorporate FGVs for the variables and for the IO, I must use shift registers?

User interaction is not so intense, as the user must only load part specifications maybe once a week and reset faults on drives if it happens.

As I stated before, the code is working, but I want to improve the structure and any advice would be appreciated.

I am sorry, but I can't load the code here only snips

[aeastet]

If you post your code you can more quickly get feedback on your programming style. The experts here are not shy in pointing out things that you have done right and things that could be done better. It is a great learning tool.

One thing that I think I would say about having 15 shift registers is that there is probably a better way to do this with one. Use a cluster and one shift register or you could break things into action engines so that you only use and update the data when it is needed vs running it through a shift register every loop execution.

If you want better feedback you will need to post your code or at least pictures of your code.

[cirrusio]

heinesterhuyse,

Without seeing what exactly is going on, it is difficult to say exactly what the best approach is.  However, given your description, it sounds as if your VI might benefit from an object-oriented approach.  Something like a command pattern might work well where you queue up the next object/state to be executed.  This object would contain all the data required to execute as desired.

In either case, I don't think having nested state machines is problematic (unless you have a nested state machine which requires some UI input that can't be delivered), but I do think it is unnecessary - it seems to me that having a nested state machine that goes through a pre-defined sequence of states is no different than having a flat sequence structure in the VI.  Anyways - post the code as suggested and advice may be a little better.

Cheers, Matt

[SteveChandler]

---

@heinesterhuyse wrote:

The previous code used FGVs, but I did have the problem of data getting over written causing signals not going through to the PLC, that is why I do not like FGVs.

This code was also messy as everything was just a big VI, so maybe I must just incorporate FGVs for the variables and for the IO, I must use shift registers?

---

FGVs are not a magic bullet that eliminates race conditions. Yes you need shift registers (uninitialized) for FGVs. Also FGVs are by definition in a subVI. See this writeup on the nature of race conditions, what causes them, and how FGVs do not automatically eliminate the problem.

[heinesterhuyse]

Thanks for all the reply's, it is helpfull.

I don't think that I would get race conditions as everything is in sequence.

I am going to incorporate more FGVs as some area's only use certain data and there is no point in creating large clusters where I just read the data once.

I can't post the code unfortunately, I wish I could as it is for manufacturing purposes.

I would keep you updated and any further advice would be appreciated

[CodePainter2]

I use this design:

Main VI for

-all DAQ

-the sequencer for the test with a state machine (Init, RunTestSteps, Stop, ...)

-one subpanel in which I load the individual test steps
 (so I can change the panel for each teststep :))

Teststeps (Sub-VIs)

-each sub-Vi has its own statemachine

-Input (like parameter) as variant

-output (like results) as variant

Communication between the teststeps and the Main with FGV.
For each FGV I use 3 sub-VIs (Variable_Init, Varianle_Read, Variable_Write) and put them together to 1 polymorph VI.

Perhaps that´s a good design...

[Yamaeda]

It sounds like you're on a good path. The easy solution would be to bundle up some/all of the main vi wires to a cluster and extract the functions you need with Unbundle as you get there ...

/Y