Programming Structures, what is best?

[krispiekream]

hi jdpowell,

thank you for you continuous support on this.

you are right about not putting "main vi diagram fitting on one screen, but I wouldn't make that a goal."

the reason for redoing this because i want to get out of the stacked sequence and with advices from alot of people in this forum, i try to avoid using local variables as possible. 

Due to race conditions if it is used improbably. 

my previous co-worker loves local variables and everything is done in that form. and i want to break away from that. 

cleaning up the mess i had before helps me do more things in the future. i know exactly where things should go and where to modify things if i have to.

a previous friend from india had a code like that and i saw him bundle things together and that's the only way i KINDA learned how to do it. 

but someone suggested that i should change my whole structure to "state machine", then to "producer/consumer"...

i have a working program now..Rev B...

but i am trying to learn different ways of implementing what i have...

does it make any sense?

[jdpowell]

I'm tempted to ask you to post your whole code including the 160 subVI's, but this is more the fascination of watching a car crash than any expectation that I could really help you.  The program you inherited looks like the worst code I've ever seen.  Minimal comments, unintelligible variable names, parts of the code with lines running right to left instead of left to right, etc.   I can't even figure out what it is doing.  Sorry,

-- James 

[krispiekream]

hahaha, wow, its that bad?

you should have seen the version before that..

please tell me that what i have done is better than this version, because if its not, i should stop doing it now..

[jdpowell]

Well, you've done no worse.    But your mostly just rearranging poorly written, hard to read code.  It's not really a noticable improvement.  A better plan might be to try and get the gritty details into subVI's.  For example, get all the weird details of reading pressure (asserting a global called "lock_press_read", calling "pressure_query.vi" with several inputs, then deasserting "lock_press_read") into a simple subVI "read pressure.vi".

-- James

[Wiebe@CARYA]

The only chance to make this a really nice program, is to write it out on
paper, and rewrite it using only some sub vi's.

This might sound like a hell of a job, and it won't be easy in your case.

The trick is to rewrite it in parts. Some part are a bit bigger then the
other. But as you get along, you get more and more familiar with what the
program is supposted to do, and it will get easier and easier. Of course it
helps if you have a good idea about what you want to end up with. A state
machine is a good idea.

To give an example, the top loop isn't that bad. But concatenating strings
and converted numbers is a typical thing that polutes the diagram. Replace
it with one format into string. Replace the two and's with a compound
arithmetic (invert the last input). Staigthen some wires, and move the
stuctures a bit, and it looks a lot better.

The lower loop is very bad. But it is mostly sequencial. In some cases, it
might help to replace the stacked sequences with flat sequences. The code
won't get any better, but you can see what is happening. When things are in
sequences, they are often good candiates for sub vi's. Using error clusters
for synchronisation, you can wire them together. but this will only
optically improve the code. It doesn't help to simply create subvi's of
blocks that look messy. A goed rule is: create a sub vi if you can give it a
descriptive name. "Sequence state 1.vi" is ok. But it is even better if the
sub vi is reused.

The biggest change will happen the moment you realize, that although the
program acts as a big sequence, it is actually event driven. The sequence
loops and loops, and stuff happens of not depending on control values. So,
why not do those things only when the control values change?

Keep in mind the satisfaction you'll get when you have a nice, extendable,
maintainable and understandable program at the end. It will work better too.

Hope it helps.

Regards,

Wiebe.

[Wiebe@CARYA]

BTW.

You don't *have* to rewrite it yourself. If you have a budget, you could
outsource it. I'm not asking for the job, it is much better to get someone
located near you. It happens more then you might think.

I think (I don't know what is in the subvi's, but not much I guess), about
6-8 days would be enough, including one day of training. This might be
cheaper for your boss then letting you do it.

Doing it yourself might seem like a good learning experience, but this is
really something someone with experience should teach you.

Better jet, get an intern to rewrite it (and end up with an even bigger
mess!).

Regards,

Wiebe.

[johnsold · Accepted solution]

Wiebe has some good comments.

I looked at the large "Cycling" loop. In about an hour I eliminated all the local variables which were linked to indicators in "input cluster."  I changed the stacked sequences to flat ones and wired the input cluster and the error cluster through anything which used them.  There are still a few locals for things which were not in the cluster.  Some of what I did probably creates errors because I do not have the subVIs or know what some of these things do, but this may give you an idea of how to approach this kind of change.  I would make a typedef of the input cluster so that when you change it, and you will, the change will propagate though all the subVIs which use it.  Make it a non-strict typedef so you can change the size on most subVI panels where it does not need to be seen.

 It appears that the Press_dir.vi uses a different input cluster.  The broken wire help shows clusters with differing numbers of elements.  The typedef will prevent this.

Lynn 

[krispiekream]

" would make a typedef of the input cluster so that when you change it, and you will, the change will propagate though all the subVIs which use it.  Make it a non-strict typedef so you can change the size on most subVI panels where it does not need to be seen."

yes, i always run into that problem..

when i have a new value or whatever, i have to change all the subvis as well..

"typedef?"..i think thats something i have to move forward to..i have to look into that..

let me go and take a look at Rev C_1 and see..

[johnsold]

I did not put a typedef in the VI I posted.

To create a typedef select the control (or indicator) and then from the Edit menu choose Customize Control...

Any large cluster used in more than one place, any cluster you will be likely to change, and enums used as state controls or commands to subVIs are all things to make into typedefs.  Typedefs will save you a lot of time and programming errors.

Lynn 

[krispiekream]

johnsold,

i was going through the code during lunch and i noticed that you bundled the ADV control in the code.?

why?

what happened if you press on it? the wire carried over will not work if the value of ADV is changed?

this is where i place problems because if the value change in the control, the wire that we transfer from one end to another will not be carry over when the value is change..

 

Message Edited by krispiekream on 02-05-2009 03:12 PM