|
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:
1. Read all connected inputs (chassis-based I/O cards and
remote I/O)
2. Solve logic top-to-bottom, left-to-right (typically
relay ladder logic (RLL))
3. Write to all outputs, regardless of state
4. 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
|