Top 10 Reasons Why I Hate Programming Automation Direct Controllers

After 4 years, I am working on a new project with an Automation Direct controller. Wow, I forgot much of a pain they are to program. So...

The Top 10 reasons why I Hate Programming Automation Direct controllers...

1. Too many numbering systems... did I stick a BCD, Binary, or Real number in that register?

2. Comparison contacts only work with BCD values.

3. Loading and storing the accumulator all the time. Seems like half my program is LD and OUT instructions.

4. Octal addressing.

5. Registers used in IBOX instructions don't always show up in the cross reference.

6. Doing math functions with BCD or Binary numbers is tedious. Especially when dealing with positive and negative values.

7. Difficult to navigate through all the rungs of logic. Would be nice if I could separate all my subroutines and jump between them from an explorer pane with just a mouse click.

8. The $ we saved in hardware is spent in software development time.

9. Dead hardware out of the box. Me to tech support, "What da ya mean my t/c module configuration is wrong, I copied it right out of the manual?"

10. OK, so that's only 9 reasons, but I'm sure I forgot one somewhere along the line.

While you do have some legitimate beefs, I don't understand a few.

1. Don't other PLCs support multiple number types? Yes, keeping track of them in AD can take some time.

2. Comparison contacts most certainly DO work with binary numbers. They do not work with Reals, perhaps this is what you meant?

3. How are these functions done on the platform you are used to? It doesn't seem that bad to me. In fact, use of the accumulator stack can lead to compact code when combined with some of the functions available on the more advanced processors.

4 and 5, agreed.

6. Sort of, generally only in the positive/negative situations. Even those can be handled without too much trouble (maybe I don't know how easy it is on other platforms.)

7. Agreed

8. I would wager that for some of the more experienced programmers (bcarlton comes to mind), dev time would be roughly the same for the various platforms.

9. Dead hardware can happen to any manufacturer.

10. You forgot "AND above a join".

Just my humble opinion,
Brian

I seem to have multiple parts of my brain. One part is for AB (subdivided of course into SLC and Controllogix) and AD (Which now has a Click subdivision). I seem to have no problem switching over from one to an other. All have strengths and weaknesses. None are perfect.

Some may call that schizophrenic. But I disagree ... and so do I.

Originally posted by agarb:

1. Too many numbering systems... did I stick a BCD, Binary, or Real number in that register?

Click to expand...

That's not quite the right way to think about it. AD doesn't support too many numbering systems. They just don't enforce a specific data type onto a given register. What the data mean is simply based on how you look at it and operate on it. This is similar to what Siemens does. Once you get used to it it does have some power. If this causes you an issue segregate your data into conceptual blocks and only use a specific data type in a given block.

Originally posted by agarb:
3. Loading and storing the accumulator all the time. Seems like half my program is LD and OUT instructions.

Click to expand...

I'm with Brian123 on this one. Use the accumulator to your advantage. This was one of the most wasteful aspects of the AB processors until the compute instruction came along. If you had a complex equation in the early firmware SLC or classic PLC5 you HAD TO put the intermediate result somewhere. With AD you can just leave the intermediate result in the accumulator and perform the next operation on it. Evaluate your equations in this light and you may also see the power it brings.

Originally posted by agarb:

8. The $ we saved in hardware is spent in software development time.

Click to expand...

This is the nature of the beast for a first time user. And after a 4-year hiatus you can be considered a first-time user. See if that paradigm holds after you rap off five or six more AD projects. My guess is it won't.

By the way, this is all from a dyed-in-the-wool AB CLX guy. While I myself prefer the AB stuff it is mostly because of familiarity, not a lack of features in the AD stuff. I'm not big on the development environment holding my hand. I can do that pretty well all by myself. So a more free-form programming experience like the AD or even Siemens provides is sometimes refreshing.

Keith

OK, maybe I was a little hard on A/D. They are a fine company and I do use a lot of their other components like pushbuttons, motor starters, fuses, fuseholders, power supplies, etc. I also think their PLCs are fine for simple on/off control, I'm just struggling when trying to implement math and more complex algorithms.

As Brian123 pointed out, I was incorrect in saying that the comparison instructions only work for BCD. They do work for unsigned binary, but the values are displayed in the ladder as BCD/Hex and I haven't found a way to change it.

Brian123 - What is "and above a join" - maybe this hasn't bit me yet...

As far as the accumulator, it may be powerful in some circumstances, but I find the the readablilty of the program is diminished.

kamenges, I understand what you are saying about my comment on too many numbering systems. You are correct in stating that it is really all in how the data is interpreted. I would really prefer an enforced data type for each register. If this was done, it could make things like comparison and math instructions much more flexible.

Can somebody explain the advantage of using BCD? I know that it is easy for us humans to look at the HEX data and immediately know decimal value it represents, but every HMI I've ever seen already does this for me! In my mind BCD format seems wasteful in the sense that I am using an entire 16 bit register when 10 bits would do! The TMR instruction, for example, can only time up to 999.9 seconds which is only about 16 minutes. Which leads to using an accumulating timer in some cases.

The BCD thing for Timers and Counters seems to be an historical artifact that, give backward compatibility, seems tough to root out. If it's weren't for them I would never use BCD at all. The math instructions for BCD take at least twice as long as the equivalent binary math instructions.

Bernie has a good explanation on his site.

http://www.theplcguy.com/ABtoAD/InstructionSet.htm

He also covers a few other differences between AD and AB. Might be worth a read if you are more familiar with AB than AD.

Brian

I'm with Bernie on the BCD. Although, I did have an opportunity to use a double BCD register that simplified things over a Hex number. The number was too big to fit into one Hex register, but small enough to use a double BCD. The number represented a pressure reading and the reading covered several orders of magnitude. I placed the decimal point at the word boundary. In some machine states, I was only working with the integer portion of the number; in other states, only the decimal part of the number. It was simple to refer to a single word and get the data I was needing. If I had stored the number as a double Hex (or Integer) I would have had to use the compare command all over the place. I have to say, I really appreciated having BCD to work with in that case.

Brian

I think a real-world example is needed, but I'll start a new topic. I feel kind of bad for starting a thread where I bashed A/D over my lack of knowledge.

New topic here: http://www.plctalk.net/qanda/showthread.php?t=51586

Brian123 - What is "and above a join"??

See the link in my previous post. I should have said that the link explains "and above a join". Scroll to the "Gotcha 1" section.

Brian

AD's definition of PID 'action' opposite everyone else's

AD's definition of control action is on page 14 of the CL05/06 chapter on PID (http://www.automationdirect.com/static/manuals/d0user/ch8.pdf)

AD quote, "if SP > PV, then a reverse acting controller will decrease the output to increase the PV."

That "inverts" the ISA 'standard' (what I learned in an ISA course 25 years ago).

The ISA standard for reverse action is:
PV > SP, output decreases
SP < PV, output decreases
PV < SP, output increases
SP > PV, output increases

The ISA standard for direct action is:
PV > SP, output increases
SP < PV, output increases
PV < SP, output decreases
SP > PV, output decreases

I recall encountering this with a TI 5xx 20 years ago, and wonder if there's a connection.

Actually I think the AD statement for a reverse acting controller is correct.

Forward acting is like a heater control. More output causes the PV (temperature) to rise.

Reverse acting is like an air conditioning control, more output causes the PV (temperature) to decrease.

The following is from the ISA

http://www.isa.org/InTechTemplate.c...Management/ContentDisplay.cfm&ContentID=72543

Direct/reverse acting: If an output is supposed to increase if the error between PV and SP is increasing in a positive direction, then a controller is direct acting. Conversely, if the output is supposed to increase if the error is decreasing, it is reverse acting. An example of a direct acting loop would be a cooling water loop. As temperature increases, the amount of cooling water would need to increase. Tank level would be an example of a reverse acting loop. As level increases, the amount of water fed to it would need to decrease.

Click to expand...

[Edit - actually as I read a little more it does seem that the AD definition, while much more intuitive to me, seems to be opposite what I read in other references. Very strange.]

Bit off topic

danw said:

I recall encountering this with a TI 5xx 20 years ago, and wonder if there's a connection.

Click to expand...

Actually that is a very good observation. Infact you can directly replace a TI 2XX series with an AD equilevant.

Think of TI as AD's grandfather. When TI stopped making PLC's Koyo (AD) and Siemens bought their technology.

Actually I believe Koyo always made the controller. TI just private labeled them.

bernie_carlton said:

Actually I believe Koyo always made the controller. TI just private labeled them.

Click to expand...

I am suprised at that. When I had to replace the TI I mentioned I first tried to figure out what failed on the board. The board had the TI Logo all over it and the chipset with the exception of the processor was TI also.

If you take apart an LM90 which is a Koyo rebranded as a GE you find Koyo's logo and name all over it.

Maybe TI paid the extra for their name at the componet level....LOL