UpDating DOs

[MogaRaghu]

I have an "unenviable"  task to  update about 21  DOs  from a State Machine . These DOs in turn control things like Solenoids, Motor contactors, status lamps etc.

The problem is the way to update these DOs. There are two ways that I normally do - one with the use of a Boolean Array Constant and the other with an Insert Element function and shift register.

I am not sure if there is ay other better way to do this and with descriptive names for the concerned outputs ? In both of my methods there is no facility for naming the individual DOs.

Attached is a sample VI in LV7.1 ( If posting back code kindly do so either in LV7.1 or 8.0 )

Thanks for any better suggestions.

Raghunathan

[andre.buurman@carya]

---

@Raghunathan wrote:

I am not sure if there is ay other better way to do this and with descriptive names for the concerned outputs ? In both of my methods there is no facility for naming the individual DOs.

---

Use enum type def to replace the constants. This will give you a description for each output.

A future enum change will update the names everywhere.

André

[altenbach]

Well, how you do this is not that important, but the shift register is certainly not needed because it forces you to reset booleans back to FALSE when the cases changes. Also, since you don't reset all booleans, you'll run into problem if you would change the order of states. Each state needs to define all ON and OFF booleans else you run into potential problems hater.

You also make your life way too complicated. You don't need to wire all these indices. If they are in consecutive order, all you need is to wire the topmost if they should not start counting at zero. You also don't need a seperate bolean diagram constant for each element, use one TRUE and one FALSE and brach the wire.

Also, you have the state indicator after the case structure, meaning you'll display the next state instead of the current state most of the time spend in a state. Is that what you want?

The attached modification shows a few more ways (LV 8.0). All are simpler and take less diagram space than yours.

[MogaRaghu]

The sample that I posted is just to convey the concept and the real thing is far more complex with no establishable pattern - so pattern for  Output_4 is not practical. And the method for Output_3 though simple is highly error prone - after working and debugging a large number of such states all in front look either a 0 or 1.

That leaves the other two  patterns as  options. And as I said  the posted VI was a sample and I did it elobarately - in real code I do not wire ALL the indexes and only keep track of those outputs which changed to TRUE state. But mostly I stick with the option of updating using the Booelan Array and have a descriptive label array that is placed in alignment outside the case structure to know what is on and what is not.

Looks like my options are far and few to choose from...

Thanks

Raghunathan

Message Edited by Raghunathan on 09-04-2007 03:42 AM

[MogaRaghu]

---

andre.buurman@carya wrote:

Use enum type def to replace the constants. This will give you a description for each output.

---

Sounds interesting. But I am not sure as of now how to go about implementing it. Let me give it a try and come back if I can't

Thanks

Raghunathan

[MogaRaghu]

---

andre.buurman@carya wrote:

Use enum type def to replace the constants. This will give you a description for each output.

---

Though not exactly what was suggested, I have made some modification to the VI that is now atleast easy to check if the right DOT is on. Working on the ENUM Type Def still. Let me see if I get THAT right...

Raghunathan

[Ben]

Have you looked at my Action Engine Nugget ?

Reply #2 in that thread has an action engine that handles DO's.

BTW an enum for the offsets is a good idea.

Ben

[johnsold]

If you use a cluster of booleans, you can name each output. Using the Bundle by Name and Unbundle by Name primitives, you can look at and modify only the values of interest at any point in the program and the By Name blocks document the code to show what you are changing. No indexing or enums required. It can take a bit of diagram space if you change many of the bits simultaneously. You do need to convert the cluster to an array or a numeric type if you are writing a port at a time, so the cluster does have that disadvantage.

Lynn

[altenbach]

---

@johnsold wrote:
If you use a cluster of booleans, you can name each output.

---

Since only one state can be active at any given time, you might as well use a "radiobutton control".

If you wire the radiobutton control to a case structure, it will act like an enum using the control names as items. Try it, it is actually pretty cool! 🙂

[MogaRaghu]

---

@Ben wrote:

Have you looked at my Action Engine Nugget ?

Reply #2 in that thread has an action engine that handles DO's.

---

Yes of course I have read the Action Engine thread many times over. Interesting stuff.

As to the handling of the DO, I do feel that if there are many DOs ( about 21 in my case ) and multiple switch ON / OFF combinations , then the  "Port Controller" option would work out to be cumbersome ?

In such an event don't you feel that the Cluster with grouped Booleans as in the example that I posted  ( UpDateDOs_Mod01.vi) is more  easy to handle  ?

>>BTW an enum for the offsets is a good idea.

How does one go about doing that ??

Thanks

Raghunathan