peterservo
Joined on 03-10-2007
Posts 2
SNAP PAC R1/2 Application Performance?
My background is in providing controls for Industrial Automation, particularly Machine Tools and Automated Assembly machines.
We are a new Opto distributor and of course we run up against PLC people on a daily basis.
I saw a question recently in which a person asked what the scan time of an Opto controller was? The person who answered the question went on to explain that a PAC is different from a PLC. While I understand that concept, the question remains un-answered in my mind.
What I would like to see is empirical data that shows what the typical response time would be for a “typical” Machine Tool application.
For example, if I had an application in which I had 4-5 differnt charts running and one of the charts was coummnicating with an HMI using Modbus TCP, how often would any of my IO points or the communication channel be “serviced”?
I understand that it is difficult to quantify this due to application variables, but with other multi-threaded controllers I’ve worked with, there is a definite task scheduling mechanism (sometimes user adjustable with the ability to prioritize tasks) whereby a user is able to predict how often any of the individual threads are serviced. Further, it would be nice to know the average number of instructions the controller is able to process per timeslice?
I think that this information will be most useful to people like me who are coming from the PLC world and need to have some assurance that an OPTO product is a viable solution.
Report
04-04-2008, 10:45 AM
Mr. Bill
Joined on 09-23-2003
Posts 18
Re: SNAP PAC R1/2 Application Performance?
The question of “scan time” is one we get often when comparing Opto 22 PAC control systems with typical PLC systems. The answer lies in the fundamental differences in the architecture and design of each system.
PLCs follow a sequential method for working with I/O and control logic. As defined within the industry, this is called a “scan-based” system in that the performance can be measured by how quickly the PLC can do these four sequential steps, repeatedly:
-
Read all connected inputs (chassis-based I/O cards and remote I/O)
-
Solve logic top-to-bottom, left-to-right (typically relay ladder logic (RLL))
-
Write to all outputs, regardless of state
-
Perform host communications to HMIs, OPC servers, operator interfaces, etc.
Therefore, the “scan time” is the barometer by which most PLCs are measured. While it is easier to determine a worst-case scenario in any given system’s architecture, it also ties a system’s performance directly to the amount of I/O and logic present, which can limit the system’s scalability. In other words, as logic or I/O is added, overall system performance diminishes. This is because the PLC system is completely centralized and typically runs on a single processor for all functions, including scanning I/O and solving logic.
Opto 22 PAC systems, on the other hand, are not scan-based and therefore don’t perform the above functions in a sequential and repeated manner. Opto 22 PACs are architecturally different in that there are a multitude of processors in any given system. For example, there is the main PAC controller where the program–or strategy—is executed, similar to the PLC architecture. But that’s where the similarities end. Beyond the main processor, there are dedicated processors for each group of I/O. These dedicated processors–or brains in Opto lingo–are capable of solving numerous control-related tasks, ranging from complex closed-loop PID control to simpler tasks such as counting on a discrete input channel, generating pulses, linearizing thermocouple readings, reacting to local digital events, and more. Further, these brains are also capable of communicating autonomously on event, and can even send email messages or SNMP traps.
Because of this distributed, intelligent approach to control system design, the simple “scan-solve-set” methodology used with PLCs isn’t appropriate, nor is it the best use of the intelligence distributed among the Opto PAC system’s brains. So the PAC controller doesn’t “scan” the brains on a preset interval. Instead, it queries the brains when and where data is needed to solve the logic. This translates into a system that communicates only as necessary. Because the brains offload time-sensitive and/or complex tasks from the main PAC (like PID, counting, ramping, pulse generation, etc.), the PACs are no longer required to scan inputs to do these tasks locally; they simply “ask” for values like counts, or “command” the brains to ramp an analog value or generate a square wave.
Also important to note is how engineering units are scaled. When programming a strategy, the developer can create logic based on real engineering units rather than raw units. PAC Control automatically sets up engineering unit conversion when an I/O point is configured. The engineering unit conversion takes place at the distributed brain level. When the program logic needs I/O point values, the PAC requests the values from the brain, and then logic solving continues.
- Bill