Created Date: September 23,2004

Created by: xterri

Wierdest thing ever with my new 450 today. I 've worked with a lot of 440's and 430's but this is my first 450. So, I want to know if this is a special feature on the 450!

A program is downloaded via the E4 Ethernet module. No problems. This program has bunch of outputs (Y's) turned on. When a totally different program is downloaded into the 450 with different outputs on and off, the outputs that were turned on by the first program REMAIN ON!! That is, the new program does not totally overwrite the old program!

No overrides are on. No retentive Y's either.

The second program takes over (and the outputs start acting according to the second program) only if the PLC key is turned to STOP and then RUN/TERM, or if Directsoft soft keys are changed from RUN to PROGRAM mode and then RUN again.

One more detail, when downloading the second program to overwrite the first program, I simply click on "send to PLC " and the window pops up asking that I need to be in PROGRAM mode, I click YES, there is a short PAUSE, and RUN light comes back on in Directsoft.

Firmware issue, or D450 anomaly?

Please help, it's frustrating and unsafe, because outputs stay on.

Created Date: September 23,2004

Created by: franji1

It's because you are doing a runtime edit. Runtime Edits are, by their very nature, VERY CRITICAL.

Here's one issue problem. Say you have an HMI directly controlling an output that simply turns on a light for some reason (people do this kind of stuff). This output is not directly controled in the ladder program, yet you can change its state via communications (here the HMI).

So for this guy, when he does a runtime edit, if this output was on before he downloaded versus after he downloaded, he wants it to remain on, even though the ladder program has no direct control over the outputs.

If you are doing edits with control programs that are not related at all to your true I/O, you should NEVER do a runtime edit, because outputs that were ON before you downloaded this new program, they will remain on.

The point being, NEVER do Runtime Edits unless you are doing "minor " tweaks to an already existing, working program. The internal state of everything is tried to be MAINTAINED when doing a runtime edit, NOT be reset. If you want to start from scratch, which is more typical, you should always switch to program mode. This is safer.

Runtime Edits can be dangerous and should only be done when you CANNOT go to program mode (i.e. running process, gotta make a minor change, but can't stop the machine).

Created Date: September 24,2004

Created by: franji1

xterri,

I think I may have come across a little harsh. There are very valid times to do runtime edits, as I mentioned above. However, there are issues:

1. The output states are FROZEN (a.k.a. PAUSED, hence the term Pause mode) when actually doing the runtime edit.

2. The time it takes to do a runtime edit is typically on the order of seconds or 10's of seconds, due to the slow speed of xfering larger programs and the flash memory update time. Some of the more recent CPUs have firmware that take care of the flash memory update time, so Ethernet at 10MBit is much better than a 9600 baud serial connection when this is the case.

So what happens is that ALL of the output states can be FROZEN for relatively long periods of time if you have a serial connection on "older " CPU models (such as a 450).

As you stated, this is a safety issue, but like fire, if well understood and precautions are made, can be a powerful feature when used properly.

It may be best to "test " a runtime edit when your machine is in a safe state (e.g. all outputs are OFF) just to see how long it takes to do a runtime edit (get your stop watches ready).

Again, I apologize for my harshness but wanted to emphasize the point because it IS a safety issue.