Schneider M580 HSBY High Scan Time

Hello,

Wondering if anyone else out there has experienced issue with Scan Time on H58-6040 m580 processor. These controllers have a periodic scan due to HSBY application. Current duration basically doubles when you sync the controllers. Medium sized program scans quite close to 100ms which seems like poor performance.

We have dropped off our sync'd HSBY pair, effectively reducing scan cycle to half. Biggest issue we are experiencing is loss of frequency input pulses to DDI cards. Seems to me like periodic setting / adjusted period in Unity Pro application is not trustable. Even when we lower programmed period to 80ms, we still miss 100 ms pulses with 50% duty. Not much help from Schneider getting to the bottom of math surrounding total cycle. Anyone else experiencing issues like this?

Likely the next move is to go with a high speed counter module.

For catching all 80ms pulse, you should have at least 2 or 3 program scans inside 80ms. (25-40ms scan cycle).


Thinking that you can add FAST section also on hot standby.
You need also configure DI-card inputs for FAST-program.
Then make all counting on FAST cycle and other on normal.


Note.

It is advisible to look all FAST marked IO on FAST sections.
Had some odd behaviour with P57 series if FAST marked IO was readed directly to normal sections.


If you need some IO also on normal scan, then copy then to some memory area first on FAST scan.
FAST should go 5ms or even less if it available on Hot standby PLCs also.

Thanks a lot for information. I would like to know more on your thoughts regarding "have at least 2 or 3 program scans inside 80 ms". Wondering if this is something you have determined by trial /error? What is the reasoning behind this rule of thumb? Assume on a timing diagram that 20 to 30 ms below the scan period should be enough to catch pulses.

Schneider Electric has told me they do not recommend use of FAST task with HSBY because its periodic scan. My understanding is variables declared in FAST cannot be referenced in MAST, and they also do not transfer state from primary to standby on HSBY application.

I see you are in Finland? Are m580s popular over there? Thanks!

I sound little bit odd, even that I haven't used M580 hot standbys CPUs with fast task.
Variables are configured only on one place and Master PLC should see all variables and them values. That is case at least on single PLC.



Periodic scan.

Even mast task can adjusted to periodic, so not sure why fast task should then avoided.
According this fast task variables are synced, but only them which are used inside fast task. All others are synced by mast-task.
https://www.proface.com/support/ind..._GLOBAL&lang=en&locale=en_US&id=FA279276&prd=


2-3 scan time thumb rule comes from triggering and syncronous PLC scan.
I assume that M580 is syncronous plc.
PLC followed the standard (synchronous) scan cycle:



So scan flow goes.
1) read inputs
2) process code
3) write outputs


If you have scan time lets say 20ms and pulse 25ms with pause 10ms.


For knowing that pulse is 1->0->1 (R_trig), you need at least one scan between pulses to see false state and another rising edge.



On this case, first scan see pulse, second scan can maybe see 1st pulse still, 3third scan will see second pulse, but PLC code won't know if 1-3 scans have same pulse or different. PLC read input state haven't reconized false state at all now.

It won't work as pulse period is too fast for scan time and counting all pulses, PLC won't see pulses false state is detected 100% sure.


if we have 10ms scan time and again pulse 25ms and pause.
1st scan to 3rd scan would see pulse then, 4th will see false state and 5th next pulse.


- PLC needs extra 3 scan to see false state of pulse.



If M580 would be asyncronous (non syncronous) then it could read inputs more than one time with one scan.



OK. We can assume that pulse can be less than plc scan time, then it won't work at all with normal input.
Lets assume that PLC scan time is 20ms, pulse on time 10ms and pause between pulses 5ms.

Then

First plc scan we see pulse (10ms +5ms), another pulse starts on 15ms time and last to 25ms. So we see next pulse on 2nd scan.

But then third pulse would be time 25-35ms, still on 2nd plc scan and plc would not count it and one pulse is missed again.


You can't count if plc can't see off state.


Pulse needs to be longer than scan time and for rising detection you need another plc scan time, when pulse is at false state.
It depend pulse on and off times, so 2-3 faster scan time is good thumb rule.


There can be hardware setting for latching shorten pulses than plc scan time is. Again after that you need 2-3 scan times more for latching surely all pulses.
Latching is longer than one plc scan and needs still more scans for working.




You need also to check if your DI card is even capable to even count your fast pulses.
If it is, then you need also 2-3 faster scan time.


My example can have writing and timing errors, but you probably understand what I try to describe.




p.s


Googling opened this nice timing chart and pulse problem explanation for 2scans.

https://home.isr.uc.pt/~lino/AIR/Arquivo/PLC_Tutor/whatmeans.htm