CPU S7-1500 - STOP mode after power on

Use the "Support Request" web link on this web page to contact Siemens.

There is the option to have the PLC always go to RUN after a power restart. Consider if your application situation is safe to use that. We have found that a power interruption while the PLC was starting up would cause the PLC to not go to run. We had a plant which was prone to have "brownouts".

I recommend upgrading the firmware to a newer version.  I may be wrong, but I thought the described behavior was one of the things addressed in one of the FW release notes.

The timing of the power off and the PLC stop command as it detects the power off condition may be affected by how much retained data must be written causing the PLC's previous run/stop state to get lost when it finally stops and shuts down (powers off).

If it were me, I would (in the interest of time) change the startup setting to always go to Run mode regardless of the prior state.  That may not always be perfect, but the s7-1500 has a switch you can flip to off which will prevent it from going into run at power up should that ever really be wanted (should be very rare).

Hello,

first of all, thank you all for your advice!

On March 25, I upgraded the firmware to the latest version 3.1.2.

At the beginning of this week, the customer reported that the PLC went into stop again. Unfortunately, maintenance turned on run mode and when I connected the diagnostic buffer was reset and there was no event there when the PLC went into stop mode. I only noticed that the date and time were reset - is it normal that the date resets when switching to stop? Because I don't have the diagnostic file I don't know if the PLC behavior is the same as before the new firmware was uploaded.

By the way - I don't understand why every time maintenance goes into run mode from the LCD it deletes the diagostic buffer?

Regarding the problem with resetting the values in the data block - this problem also occurred after uploading the new firmware.

I began to wonder if this problem is not affected by the communication of the OPC UA with the client sytem. Our PLC is a server and data from the external system is entered into the three data blocks. Theoretically, in OPC UA communication we don't refer to it by address, but by the whole path using the variable name, so it's rather impossible that data in other data blocks are littered by OPC UA. Unfortunately, I don't know what OPC UA communication looks like from the other side, because it was not done by us, but by another company. Nevertheless, to rule out this problem yesterday I turned off OPC UA communication to see if it has an effect.

Meanwhile, I got a response from Siemens support (update firmware, test without OPC UA, save service data, when PLC Stop occurs after firmware update, replace memory card).

I have already bought a new memory card, so if the problems persist, it will be another solution to test.

I will come back with an answer when I have new information.

Does this system have a Siemens HMI?

If yes, add the diagnostics alarm screen(s) to the project so it can or (preferably) will display diagnostics even with the PLC in stop.  Then have the customer update the HMI project - unless you can do that remotely using one of their PCs via remote control software (or VPN).

If no, is it possible to loan the customer a low-end HMI so it can capture and display PLC diag alarms until the root cause has been determined and corrected?

System has Siemens panel PC (IPC477E). I hadn't thought about adding system diagnostics to the HMI before. I will think about more diagnostics to display on the HMI.

I have remote connection, so it is not a problem to connect. The problem is that in most cases, the stop occurs during the night shift and then maintenance switches on run mode so as not to disturb production...

Hmm, since you have remote access, you can set up diagnostics error interupt OB to log data to a retained DB and maybe log to the IPC using its integrated log functions?

kkr1993

System has Siemens panel PC (IPC477E). I hadn't thought about adding system diagnostics to the HMI before. I will think about more diagnostics to display on the HMI.

I have remote connection, so it is not a problem to connect. The problem is that in most cases, the stop occurs during the night shift and then maintenance switches on run mode so as not to disturb production...

Hello,

to check whether the problem was in OPC communication, I disconnected my machine form the customer network so that no information was sent to the PLC from outside. The machine has been working without problems for over two weeks (previously the PLC stop appeared at least a few times a week).

When it comes to OPC UA communication, we received two data bloks from our customer:

• Hydra_zaehl - used to send data from PLC to customer system
• MNR_1 - used to send data from the customer system to the PLC

All data blocks except these two have the "DB access from OPC UA" option disabled. Is it possible that the data sent from the client system is, for example, inconsistent with the declared variable type (string greater than the maximum string length, etc.) and this creates problems in our controller?

I now want to go back to work with the client system to see if the PLC stop problem returns. Do you have any ideas on how to diagnose this data exchange more deeply?