Scan time versus Boolean Execution Time

[Ingeniero]

I was going through the BRX manual, CH 11.

Scan Time is given as 50 micro seconds per 1 K boolean instructions. Boolean execution time as 50 Msec per 1k boolean.Is this a Typo? Sounds like the same thing.

I need a fast PLC.

[Controls Guy]

It's got to be 50us per K.  I've got a 200 rung program with around 200 MATH boxes, a couple of which replace 32 rungs of boolean apiece, and typical scan time is 6-10ms (though it can get higher when I run some programs that iterate a lot).

[Ingeniero]

How can I calculate runtime without spending time and money to move my old AB programs over to a BRX.

the analog scan times on the BRX are given as 1 millisec, very fast.

5 millisecond scan time should use 100,000 boolean expressions. 20,000 per millisecond.

[BobO]

Boolean and most integer math functions are executed by a coprocessor. The actual execution time can vary due to cache conditions, but is generally around 50ns per instruction. There is about 250us of scan overhead, plus communications time. Ethernet on the local port will cause the biggest bump. If you want Ethernet and want to minimize the scan bump, you should probably use an ECOMLT POM.

Non-coprocessor instructions are considerably slower, although still pretty fast.

The BRX local analog input channels do update at roughly 1ms.

[Ingeniero]

So the processor has an overhead of about 250usec.

Each boolean and most integer functions uses about 50 nano seconds, so 20 to a micro second and and 50 micro seconds would equal (50X20) 1,000 boolean commands. ok ok.

Wow, I have no idea on how to estimate what an AB program would use as a scan time without converting it to domore. no easy way to estimate.

[BobO]

Wow, I have no idea on how to estimate what an AB program would use as a scan time without converting it to domore. no easy way to estimate.

I'm sorry. I'm not that familiar with AB instructions or performance.

[ATU]

Its difficult to compare and depends greatly on which Rockwell series you are talking about. The BRX will probably blow Micrologix, SLC500 or 800 series out of the water. CompactLogix  varies. Newer units are much faster than the older series.  As in the BRX, communications has an effect on scan time. But how you write your program makes a huge difference too. if it is mostly Boolean and you rewrite the program in the BRX using stage, you could see a huge improvement in scan time.

[Ingeniero]

If you want Ethernet and want to minimize the scan bump, you should probably use an ECOMLT POM.


So if I set fixed scan time to 5 Milli sec it will be delayed when the ethernet server is updated?

The ECOMLT lowers but does not stop the bump.

I think I need stable control, at about 5 millisecons.

[BobO]

Do-more does not have a fixed scan option.

If you are doing mostly Boolean logic you will have a hard time getting the scan time up to 5ms...It's very fast.

[Mike Nash]

Do-more does not have a fixed scan option.

If you are doing mostly Boolean logic you will have a hard time getting the scan time up to 5ms...It's very fast.

You can get in the ballpark with a nice big ugly infinite loop in a program and set yield a little shy.

 

[Ingeniero]

A couple more questions:

--How big is the ethernet bump?  Is there a way to make the ethernet a low priority? Ethernet can skip a few scans or be done partially.

--Does the simulator actually track or simulate what scan time would be? somehow I doubt this.

Thanks for the help BRX buddies.

[BobO]

--How big is the ethernet bump?  Is there a way to make the ethernet a low priority? Ethernet can skip a few scans or be done partially.

It's about 1ms on scans that the IP stack does work. You cannot change that. The ECOMLT POM uses a high speed serial connection and the IP stack exists in the module itself, so it's hit to the PLC scan is much smaller.

--Does the simulator actually track or simulate what scan time would be? somehow I doubt this.

No.

[Ingeniero]

thanks BobO. great answers.