My 2 cents worth is just a tiny bit of personal experience. I also started out working on PLC's because no one else wanted to bother and the subcontractor who did our installation folded up. Obviously if you are already comfortable with the numbering format conversions (e.g. binary to hexadecimal and vice versa) you should have your basics covered. The ONE thing that took my a while to figure out though, is (ok don't laugh now) what BCD (binary coded digits) stands for!
Aside from reading through the books already mentioned by others here, the only good way to learn is to get your hands on one and do some programming. All vendors have introduction courses, which is a start if you don't mind paying. If you are a familiar with basic programming you should be able to adapt quite quickly. There are just too many behaviours particular to vendor systems (e.g. how one PLC handle the scanning cycle of looking at the IO's, apply the logics, and update the IO's) and/or real scenarios (e.g. noise problems or bad cabling) it would really be impossible to sufficiently tell you.
I'm also an Allen-Bradley SLC5/05 user, and virtually all my basic understanding were from the basic troubleshooting course I went through with Rockwell/AB. To sum it up, at least for RSLogix (AB's SLC/PLC programming language), it's just like programming in logical sequence with symbols, and/or designing circuits (e.g. what ahppens when relay switch "A" closes). In some cases the key word is actually "logical sequence", e.g. if you have 2 rungs both showing a condition when output X should be turned ON, the LAST (or latest, bottom-most) rung has dominance. So e.g. if your rung-10 logic is telling X to turn ON, but rung-11 is telling X to stay OFF, X will stay OFF. In fact when you look at the run states, rung-10 will look to be faulty as all the logic conditions are met but the output will not turn ON. Things like that sometimes can catch people out. There are ways around this, but you have to know first how the codes will behave first to design around them.
Another lesson that I spent days to pick up
is that you could program in a loop even though logically it doesn't appear to be one: the key is that PLC programs run in cycles, and sometimes (depend on coding) IO/memory registers doesn't update to the new state until the cycle finishes. So if you want to say put in a handshake, e.g. wait for Input W, do something, send an acknowledge bit and then try to turn W back off for the next occasion, you will find that it won't work because when you are waiting to read in the scan cycle, within the same scan cycle you can't write to the same bit. It makes sense when you think about it, but not that obvious until you get into a real situation.
It's usually things like THESE that get you and the experience of knowing how to deal with these sets a PLC programmer apart from someone only needing to maintain them. But it's more fun to program them
Hope I haven't bored everyone with my half-baked newbie "pointers". If anyone sees any mistakes I made in my examples please point it out too! If you would like more details just let me know.
p.s. in case this hasn't been pointed out, aside from the forum here there is also the very informative "Learn PLCs" button on top of this site (just above and to the left of the "PLC.NET" logo). I usually miss these kinda things so ...
