Given existing Automation Direct code, way more complicated than I imagined

Hey all,

I'm working on a project where there are some existing remote sites that are using Automation Direct DL05 PLCs. They're very simple, the one I'm working on literally just has three discrete inputs; Power Fail, Pump 1 Status, and Pump 2 Status. My task is to add a few discrete Fail input bits, and a 4-20mA loop for a tank level.

I've extracted the code from the DL05 and it's completely different from what I was expecting. There's only a single rung, with multiple LD and OUT boxes in parallel. Absolutely no documentation, no notes.

I've been reading through the DA user guide and it looks like the programmer who originally did the work is doing some moving around of bits with the info I'm seeing in the Memory Map (aliased inputs, etc). I'm thinking he's packing bits into certain memory locations for the communcations (MODBUS over a serial radio, no store and forward).

Here's the code in case anyone wants to crack it open, and I've put a screen shot of the ladder logic below. I'm thinking if someone more knowledgeable than me saw it, it could very easily be a five minute explanation and it would save me a boat load of time perusing the user manual and learning the nuances of AD programming, which I have absolutely no experience with. Here's what I've come up with so far:



1. LD moves the input bits to the accumulator
2. OUT moves the accumulator to V1400
3. LD moves the data in V1401 to accumulator
4. OUT moves output bits to discrete outputs
5. LD moves constant value of 8400 to accumulator
6. OUT moves accumulator to V7700
7. LDA converts octal 1402 to hex, puts in accumulator
8. OUT moves accumulator to V7701

Here are my questions:

1. What's the order of operation here? Is it vertical, since eveything is on one rung? Why not put everything on separate rungs?

2. (Step 1 from above) Why are the input bits moved to the accumulator, then immediately moved to a memory address? Why not just move them directly? Why is the accumulator used so often, even though no operations are being performed?

3. Is there any rhyme or reason to the memory locations that are addressed in the various steps?

4. (Step 7 from above) what's up with the octal 1402 value being loaded into the accumulator? I've searched around and can't figure out what that does (I'm assuming it's an instruction of some type).

5. Any other observations in general?

Thanks for any help guys!

Quick update:

I've been able to figure out what the steps 5-8 are; apparently loading K8400 into V7700 tells the controller that there is an analog input card installed, and that the input should be stored as decimal. Loading O1402 to V7701 tells the controller where to store the channel's data.

So this is VERY odd, since I had no idea someone already programmed in this functionality; apparently there has been conversation I wasn't privy to, since the program seems to be ready and waiting for me to install the card. I guess the old programmer foresaw this additional functionality at some point? Bizarre.

So it seems like what the programmer did was simply set this up as a data collector, that has a general scheme; package inputs into a specific data location, then unpack outputs (though there are none at this location, so it seems like he's trying to use general code at all the remote sites) and then do all the 4-20 channel inputs (but no scaling apparently, that must be done at the master).

I think I've got the gist figured out, but if anyone has any input on what they're seeing I'd certainly appreciate it. Thanks!

No help from me, but I can see that I'm not looking forward to any DL05 programming.

Looks like just mapping the DL05 as remote I/O to me... No real control locally.

It looks like it is just mapping analog in CH1 VX0 and analog out CH1 VY0 to internal memory locations.

Somewhere on the network there is another device that is reading in V1400 as the discrete inputs, it is writing to V1401 as discrete outputs, and it is reading V1402 as an analog input.
As has already been said, there is no actual control logic in this PLC.

defcon.klaxon said:

Hey all,

1. What's the order of operation here? Is it vertical, since eveything is on one rung? Why not put everything on separate rungs?

Click to expand...

Yes, it's executed vertically. It could also have been placed on separate rungs.

defcon.klaxon said:

2. (Step 1 from above) Why are the input bits moved to the accumulator, then immediately moved to a memory address? Why not just move them directly? Why is the accumulator used so often, even though no operations are being performed?

Click to expand...

With DirectLogic PLCs, there was no direct move until the addition of iBoxes. A set of LD/OUT instructions performs the exact same operation as a MOV instruction in RSLogix, you are just seeing both steps of the process.

defcon.klaxon said:

3. Is there any rhyme or reason to the memory locations that are addressed in the various steps?

Click to expand...

Aside from predefined memory locations (ie: VX0) memory is pretty wide open in DirectLogic PLCs. Likely, the programmer picked V1400 as a starting point for the data block to communicate just as a convenience.

jawolthuis said:

Somewhere on the network there is another device that is reading in V1400 as the discrete inputs, it is writing to V1401 as discrete outputs, and it is reading V1402 as an analog input.
As has already been said, there is no actual control logic in this PLC.

Click to expand...

Yes, this is correct; the actual control is in a Lookout program (we're replacing it with a PLC and Wonderware) and all the remote PLCs are just working as I/O. Once I figured out that all the memory locations are in octal, I converted to decimal and boom, all of the sudden I realized that all the MODBUS addresses lined up perfectly (discrete inputs at o1400, discrete outputs at o1401, analog input at o1402).

jgreenewv said:

Yes, it's executed vertically. It could also have been placed on separate rungs.

Click to expand...

OK thanks! Seems like it was just the previous programmer's preference, rather than a requirement.

With DirectLogic PLCs, there was no direct move until the addition of iBoxes. A set of LD/OUT instructions performs the exact same operation as a MOV instruction in RSLogix, you are just seeing both steps of the process.

Click to expand...

Thanks for explaining this, that was pretty much the most confusing part of the whole thing. I kept digging into the user manuals and it eventually became clear that the LD instruction does 16 bits of transfer, so it seems like the previous programmer simply loads all the inputs into one memory location, sends all outputs with the next location (though there aren't any physically connected) and then loads the raw analog value into the following memory location. What was confusing was that there's obviously only 8 inputs and 6 outputs, so I was trying to figure out where those limitations were defined (I'm used to manually mapping the inputs in Logix with contacts and coils) but all you have to do is ignore the bits that aren't being used.

OK, I think I've got this pretty well sorted so thanks for all the help guys, I really appreciate it.