PLCS.net - Interactive Q & A

PLCS.net - Interactive Q & A (http://www.plctalk.net/qanda/index.php)
-   LIVE PLC Questions And Answers (http://www.plctalk.net/qanda/forumdisplay.php?f=2)
-   -   S7-1512 CPU load regarding Technological objects (http://www.plctalk.net/qanda/showthread.php?t=123330)

JEANST January 13th, 2020 10:58 AM

S7-1512 CPU load regarding Technological objects
 
Hello
I am currenlty facing a problem on cpu load with using Technological Objects (TO) with a ET200S CPU 1512F. i have two axis drives S210 on profinet that i command with motion control TO's. Moreover, i use the safety features with profisafe. Without the TO's i think the cycle time would be around 2 3ms. In my case, the cycle time goes up to more than 20ms, and last week the cpu stopped because a cycle time overflow.. I know this cpu is not the most powerful of the simatic 1500 range but it is normally scheduled to implement the motion control functions. And i would like to know is there something to do to reduce a little the cycle time ? If somebody have an idea :)

mk42 January 13th, 2020 12:17 PM

What application cycle is your MC servo set to?

You can increase that to speed up the regular PLC scan, at the trade off of decreased precision in the motion.

4ms is I think the recommended starting place for "typical" applications, whatever typical means. It is very situation dependent.

JEANST January 14th, 2020 03:59 AM

1 Attachment(s)
Hello mk42 thanks for replying, you are right, 4ms should be ok most of the time.
I attached a file with the (new) settings of the MC Servo block
originally it was set to 4ms, these settings I sent to I have not already test on the real cpu. I wonder if the emission cycle 2ms is not a little bit short.

mk42 January 14th, 2020 08:33 AM

In your screenshot, the 2ms is just the communications cycle. The PLC & drive are communicating every 2ms. This is often 1ms, so 2ms shouldn't be too fast. The IO communication should be minimal overhead, regardless.



The 10ms is how often the motion loops are actually calculated in the PLC (application cycle). If your 1512 is set at a 10ms application cycle for only two technology objects, and your PLC scan time is 10x what you were expecting (2 or 3ms -> 20ms), then I'm not sure what's going on. I've done a 5 axis machine with a 1512, and the scan times weren't that bad with a faster application cycle.

JesperMP January 14th, 2020 10:16 AM

Quote:

Originally Posted by JEANST (Post 836906)
In my case, the cycle time goes up to more than 20ms, and last week the cpu stopped because a cycle time overflow..

Do you mean that the CPU cycle time was a little more than 20 ms, and that caused the CPU fault ?
The default maximum cycle time is 150 ms.
Did you change the maximum cycle time to 20 ms ?
If it is acceptable to your application, you could set it somewhat higher, maybe even the 150 ms that is the default.
If you have some time-critical program parts, you could consider to split your program into time-critical (called from the OB "cyclic interrupt") and non time-critical (called from the OB "program cycle").

JEANST January 14th, 2020 10:20 AM

Ok thanks for informations, we currently check with the trace function in tia what can cause this increasing of cycle time by inhibiting some parts of the program. Did you leave 4ms for the cycle application time in your 5 axis application ? and did you remember what was the cycle time you had approximately ?

JEANST January 14th, 2020 10:33 AM

Quote:

Do you mean that the CPU cycle time was a little more than 20 ms, and that caused the CPU fault ?
The default maximum cycle time is 150 ms.
Hello thanks for replying
The default maximum cycle time is 150 ms i didn't modify it.
the average cycle time is around 20ms (I find it's long regarding a basic program without TO which usually running around 2 3ms)
and only one time but we don't know why at the moment, the cpu cycle time goes over the 150ms.. It can be an option to split the program as you explain, I will check what can I do with this thank you

JesperMP January 14th, 2020 01:31 PM

If the cycle time exceeded 150 ms, it is most likely a program error. In that case splitting the code as suggested wont help.

When it happens again you should investigate the diagnostic buffer and other diagnostics which will point to where in the program it stopped, If it is in the middle of a loop you may well know how to fix it.

JEANST January 15th, 2020 04:44 AM

I'm agree, there are some nested loops that we have to check.. Something I forgot to tell and I think is important is that it is a Safety CPU 1512F (sorry for unaccuracy :) ). So there is a 100ms interruption in the OB1 moreover the using of technological object. I wonder if it's too much for the processor? Using the trace in TIA portal we can observe cycle time goes from 10ms up to 30ms, it is not really stable..


All times are GMT -5. The time now is 04:48 PM.

.