Inputs and outputs to bits

Hello all,

I am looking at a printout of a Bosch PC400 PLC. The printout is some hundred pages long, I am looking into upgrading to a new PLC as the program needs to be modified and I am unable to locate the software. The chap who programmed the PLC initially assigned all inputs and outputs to memory bits and used the bits througout the program. Is there any specific reason in doing this? I can only thing of one advantage: an output blows, to change the program to another one all you have to do is change one line in the program. Considering the PLC has 64 inputs and 50 outputs in use, quite some writing to do.

I do that in some respect

Inputs and outputs can only be used once. I list all the in's and out's on a subroutine. I use internal "M" memory markers to reference the inputs and outputs. The M bits can be used hundreds of times.

It's a simple way for me to keep function and behavior in check. I don't have to check 780 line of code to find where I hid the output. Just go to the subroutine.
T/S is a breeze too. Watch the output find out which part of your code isn't acting right, go to that part of the MAIN program, see what I did wrong.

But keep in mind, we manufacture single purpose machines, so there is no high speed programing which could affect scan time, listing I/O's the way I do.

That's my reason for doing it.

Good point, John, thnaks for that, I'll bear this in mind.

Buffering I/O is fairly common, especially on Allen-Bradley Logix family PLC's. The primary reason for this on Logix PLC's is that the I/O is updated asynchronously to the execution of the program - so the state of your inputs (and outputs) can change partway through the code. By buffering the I/O, you ensure that your logic flow is going to work as expected (or at least, as expected on onlder model PLC's: scan inputs, execute code, write outputs). I can't speak for Bosch to tell you whether that particular reason applies to them as well, but it's a possibility.

IMO there are a lot of other reasons to do it regardless. One of them, yes, is the ability to rearrange I/O quickly and easily. It means you can do your software development before the control panel design is finished, and then all you have to do once you get to site to commission is map the I/O from the as-built drawings.

The biggest one for me is that I can create Add-On Instructions and User-Defined Data Types, and 90% of my I/O gets mapped directly into pre-written code without me having to do anything else. Motor 1's Overload input gets mapped to Motor_1.Overload. Motor 1's local isolator feedback gets mapped to Motor_1.Isolator. Once you get into that, you realise that over half your code is written already, and all the boring bits are taken care of without having to look at them! Again, I can't say whether or not Bosch have similar options - in Siemens land you could use FB's to do the same thing.

As for being time consuming - I have an excel template. With 64 inputs and 50 outputs, it'd take me about 15 minutes to fill it in, and another 5 to import it - all my I/O mapping, comments included - done.