Cycle time 38ms (Slow Scada)

Hi,

We have problems with a way to slow WINCC application. It takes between 5 and 20 seconds to show the actual values when loading a pdl.

CPU 319 PN/DP Cycle time: 38ms with peaks up to 79ms
Scada connected to a company network and that way connected to the CPU.

- Would it be better with a 400 CPU when the cycle time would be much lower ?
- The company network has not-industrial switches, could it cause slow reaction ?
- Default the Scan Cycle load from communication is 20%, it is allready on 50%.



Thanks in advance,
Kind regards,
C

To me, it sounds like there is a bandwidth bottleneck somewhere.

How is the 319 communicating to the SCADA system? Ethernet, assume, since you mention switches? Integrated port or communications card? How much data is being communicated? Are the cycle time ncreases affecting the process, or is your concern strictly related to the SCADA load delay?

"Industrial" switches is mostly about environmental ratings, as well as built in configurations optimized for IO traffic. As long as the company is using at least enterprise gear, the hardware isn't the problem. It is possible that the switches are misconfigured (de-prioritizing SCADA traffic), but I doubt this is the problem. If the whole thing is running on best-buy grade unmanaged switches, I'm not sure if that would cause this.

I doubt that cycle time is your problem ether, but An S7-400 actually probably won't have a lower cycle time than a 319. The fastest 400 is slower at BOOLs but maybe a pinch faster at REALs. The advantage of the 400 isn't cycle time, but extra memory (probably won't help you) and a much faster backplane (could help if using comm cards). Swtching to newer 1500 gets you an even faster backplane, and the 1518 CPU is a fair bit faster than the 319.

If you are communicating to the SCADA out of a communications card, I'd strongly recommend using one of the integrated/built-in interfaces on the 319. The 300 backplane is very slow, and is a huge bottleneck. The integrated ports can talk straight to the CPU.

You can also increase the CPU % that can be used for communications in the HW config. However, my guess is that you're already at 50%, the max. 50% used for comms can up to double the cycle time, which could explan your 38 -> 78 cycle time peaks.

One option you might be able to use, if your FW is new enough (v3.2), is "prioritzed OCM communication". The manual is a bit vague on how it works, but it speeds up communications pretty well, at the cost of a slightly increased cycle time.

This might be obvious but you define how the tags are collected in wincc.

"Cyclic on use" means that the wincc only fetches that value that you see on screen.

But the question is where is the problem? Are you running wincc on a HMI?

Is the problem with the HMI itself (have you tried another one)? Is the problem with wincc bugs? Is the problem with wincc configuration? Is the problem with communication speed to the PLC over switches etc? Is the problem that the PLC can't deliver the values the HMI are requesting?

You need to troubleshoot logically so you can find the real problem.

For instance if you are using a HMI, how does it look when you run the HMI on your programming PC using WinCC runtime?

Have you tried analyzing the network for how much bandwidth is used? Wireshark and portmirroring to see what is sent on the network.

I didn't see your screenshot before.

I'd definitely recommend activating "Prioritized OCM Communication", to help from the PLC.

I may be way off base here, but I have run into this before. Is the local network wired correctly? Is this a 10 base, 100base, or 1000base network.

What I mean about being wired correctly, I have ran into ethernet cables built as "Straight Through" cables, old switches being use that was 10 base only, etc.

This type of problems will drastically slow a network down.

Just some thing to be aware of.

damica1 said:

I may be way off base here, but I have run into this before. Is the local network wired correctly? Is this a 10 base, 100base, or 1000base network.

What I mean about being wired correctly, I have ran into ethernet cables built as "Straight Through" cables, old switches being use that was 10 base only, etc.

This type of problems will drastically slow a network down.

Just some thing to be aware of.

Click to expand...

Oh, good call. This can also happen if one side is set to autonegotiate (S7-300 by default), and the other side is set to 100FD (a legacy IT preference).

Another thing to check is if the wincc page contains a lot of animation. It can really bog down a page. Especially if one value that was stable before starts to change a lot. It doesn't have to be something visible, it can be scripts that runs when a tag changes.

Also to me it seems excessive that a 319 PN/DP has a cycle time of 38 ms. It's a fairly fast PLC, the fastest in the 300 series I think. I can't but wonder what the application can be and what the program looks like.

On a similar note, one of our customers dropped 7 figures into a NEW Extrusion line. Touch a button on the HMI and it was a good 2 minutes to get a reaction. Yes, it was timed! Called the manufacturer of the hardware, and they said they are shoving too much stuff thru a small pipe.