Hi,

I want to ask about S7-1200 Cpu programming: I wrote program code for concrete bricks automation. It's perfect work's in manual mode (see manual.jpg): You can press any button in the HMI screen and pneumatic valve make special function: open concrete mixer with cylinders, cements, etc. Also you can turn on mixer and vibration motors, conveyor, etc. It's very hard to press buttons all work day (turn on conveyor, mixer motors, calculate graver moisture, pour cement, wait 1 min,  pour plasticizer, wait 1 min, pour calculated water to the mixer, wait 2 min, open mixer cylinder and turn on conveyor, wait 1 min, close mixer cylinder). And cycle repeat all days, weeks, months, year's. I want to  automate this process, but have confilct with manual outputs: if you use the same outputs in manual and automatic modes, your function doesn't t works at all.

My solution:  I saw how works automatic and manual modes on Multilayer machine Zenith 844. They use 3 position key switch. If you want  enable  manual mode, you must switch  key to ,,manual mode" position. Then automatic mode doesn't work. If you want enable automatic mode, you must switch key to ,,automatic mode" position. Then manual mode doesn't works. Perhaps it's possible lock in manual programming networks (see attachment) and  unlock automatic programming networks. It's would be great, no conflict no problem with outputs. It's something like that you  have 2 CPU (1 cpu has programmed in manual mode, second cpu has programmed in automatic mode) and you just choose what mode do you want to use.

2 CPU's?  Far too complicated for what you are trying to accomplish.

Hardware.  A key switch is normal to select between Manual and Auto, since the operator can remove the key in Manual to prevent things happening automatically while someone is in the machine area.

Software.  Your problem is you have an existing machine with working code and you want to change it.  Adding a second CPU does not help you much, since your final outputs don't change.  As a general principle, you DO NOT write to an output more than one time.

The strategy that I would use would be to put the Manual/Auto interlock before the output coil and OR with your Auto control.  Your automatic control can be done by adding exiting program blocks and your intrusion to the existing code would be minimal.  Your testing would have to be done during planned outages, since this machine is already in production.

Jeff Casagrande

<snip>
As a general principle, you DO NOT write to an output more than one time.

The strategy that I would use would be to put the Manual/Auto interlock before the output coil and OR with your Auto control.  Your automatic control can be done by adding exiting program blocks and your intrusion to the existing code would be minimal.  Your testing would have to be done during planned outages, since this machine is already in production.

</snip>

Jeff - I do not agree. The screen shot of OB1 is very telling.
You have already given essential notes (as quoted).
Please allow me to put some thoughts down too.

My assumption is that all the code has been coded inside OB1 and M-bits has been used for memory. This code will need re-structuring (into FBs) before adding new code.

It is possible to restructure to a "manual task" code block (FB) and "automatic task" code block, as to make the process work as if 2 CPUs are running the process.

The risk is that the manual should be able to take over from automatic and visa versa. For example.. when a motor is started and a mode switch occurs - should the motor stop or continue running..

It becomes complicated if the operator has a choice of running the process in auto or to take over in manual. It is unpredictable where the operator will stop the auto running and unpredictable on where he will need to continue in auto.

Just some food for thought.
w

William_B

Jeff Casagrande

<snip>
As a general principle, you DO NOT write to an output more than one time.

The strategy that I would use would be to put the Manual/Auto interlock before the output coil and OR with your Auto control.  Your automatic control can be done by adding exiting program blocks and your intrusion to the existing code would be minimal.  Your testing would have to be done during planned outages, since this machine is already in production.

</snip>

Jeff - I do not agree. The screen shot of OB1 is very telling.
You have already given essential notes (as quoted).
Please allow me to put some thoughts down too.

Oh dear.  If this was all done in OB1, then all bets are off.  This is not adding additional blocks and some simple output interlocks.   This is 100% recode.

Hi!

Here is one idea to start with.

In order to avoid the outputs to change when the working mode is changed, you could set/reset the outputs with pulses from your auto or manual cycle.

Most probably you will have to reset your auto cycle  when coming back from manual cycle.

I would set/reset one output only in one place. As William said, you could create a separate FC/FB for your manual cycle, one for the auto cycle and another for writing the outputs.

As I said, it is just an idea, it is OK for assembly machines but might not work out for your application.