I think in understand what they are doing but I am not sure I understand WHY. I have a 1771-OFE2 with 2 BTWs for the same card the first is to configure the card on the FS 13 words long. The second is the data that is only 5 words long only after the system is up and running. So my question is what are the savings of doing this? Processor power? I just don't see it.

Are you sure they a both "BTW"?
The "BTW" will have 13 words, the "BTR" will have 5 words.

Yes sir I have been all over the program looking for a BTR for this. The BTR would only allow me to read the current value.
The real different part of this is that there are 2 different DATA blocks for these cards. I have at least 4 of these cards setup this way, with different FirstScan BTW and regular program blocks. If it was just one of them that had this I could see where someone FAT fingered the BTR BTW but 4 of them.

I think your assumption is correct. The 13 word BTW is to send all the initial config stuff to the smart card. After that the programmer is just sending the actual output values to the card (the fifth word has the sign information). I have seen this done before. I guess it is more efficient on the traffic, but I am with you - I doubt it is necessary. I prefer boring logic that is easy to follow and works.

Russell

That code is straight out of the A-B manual for the card. As you say, the 1st BTW sets up the card config, the other handles the transfer of data to it when running.

OK I can't find it I have looked in all the old manuals around here. I have looked on RA website and can only find Current manuals no older stuff. Am i just missing it in the new manuals? If I had to guess this is an old school programming tool to reduce the load on the system. This sytem was originally built with a 5/25 and now we are running a 5/80C so I have a little extra horsepower to spare in the battle of easy to follow BTR & BTW and scalling.

I love this reverse engineering a system!!! You get to learn all the old school tricks. I have to say that we are a little spoiled by all of the "INSERT LADDER RUNGS" and autopick and not doing a lot of scaling in the PLC

I've had some AB cards that actually crash if you write the configuration data to them too often. But those are input cards. Never had that issue with an output card.

Normally I just use the auto-config stuff in the configuration to write the BTW/BTR instructions at least initially because I've never had good luck writing my own.

The difference in raw speed between a 13 word and a 5 word packet is probably miniscule at best. I know 56 kbps sounds very slow but the overhead involved in a packet on Remote I/O (if this is remote I/O) more than overshadows the gain in packet size.

I found several point in the program that the OFE was using BCD but he cards have been changed to 2's comp. binary.
What a mystery? I keep hearing those guys that setup that line didn't know rhat they where doing. Have you ever notices that nobody every programs as good as you do. The same person that made hat statement also said that he tries to configure those cards but the other guys had it to screwed up. He did fail to offer this when the operators can't get a manyal mode on a PID to work.

What I've found is that my coding style is significantly different from others. I like it. Others hate it or are at least neutral about it. I can read theirs. They can usually read mine. If I work on their code, I often find myself rewriting everything over time. So we just agree to disagree. Everyone has their own particular "style", for better or worse. Some are better than others.

My worst hangup is that I can't stand seeing "MOV 0 xxx" (I convert it to CLR) or worse yet, CPT xxx <-- xxx+1. I always strength reduce whenever possible.

I've had countless folks demonstrate why they don't understand BCD arithmetic. For instance one plant I worked at converted everything into BCD and then back again in the same program and never used the intermediate result. After doing a little searching I found out that at one time, they had the old thumbwheel devices that actually use BCD arithmetic for inputs so you'd get settings of 000-999. Later on to save time in programming, they simply converted the HMI values into BCD and then left the rest of the code alone. The local electrical department didn't understand all this so they started using it without understanding the purpose (there wasn't any) and mostly felt that it must be "right" because it automatically limited the operator inputs to values of 0000-9999! Imagine how much they freaked out when I rewrote everything without any BCD arithmetic...since they actually believed this stuff was a necessity and had to be done on all numerical inputs.



That sounds like a simple training issue. Most people aren't actually trained how to write code for PLC's, or trained poorly at best. They usually get thrown into it or figure it out on their own. Very few colleges offer courses in PLC's, and I've never seen a computer science department that teaches PLC programming or PLC programming methodologies. The result is that most PLC programs are very, very bad.

In terms of methodologies, it is frequent to see very bad programs with lots of one shots and latching instructions. This is characteristic of transition logic instead of state-based logic. Similarly, folks that have never been exposed to state machines often write code based almost purely on external state. The result is a nasty "onion skin" type logic that is also very hard to debug and often breaks if events occur out of order. In terms of basic skills, logic skills such as strength reduction (MOV 0 xxx becomes CLR xxx) and logic simplification are not taught, leading to very ugly input logic statements that are again, hard to debug and read. All of these lead to even uglier programming practices down the road.