PAC Training : PLC Training Best Practices
This is section 8 PAC Training of the PLC Training Best practices. PAC: Process Automation Controller
IEC 61131-3:2013; ISA/IEC 62443; NFPA 79 2015; IEC 60204-1; ICS 21.020: 29 CFR 1910.212; IEEE 1588 PTP.
A PAC is a very different device than a PLC, just like a DCS system is very different than a PLC. The PLC/PAC difference is similar to the difference between SCADA software and HMI software, it is a technologically evolved product combining two or more previous devices into one. So this section is for PAC part of training tips and best practices contained in these 10 sections address. This page is for Section 8 of these 10
The information on this page protected by international copyright laws. You may not copy or distribute any of this page content in anyway without express permission from site owner. You can share this page hyperlink with others though.
PLC Training Tips:
- The very first and most important PAC training advice is to teach the fact that PACs are very different than PLCs, and what those differences are.
- A PAC should always be referred to as a PAC, not a PLC to reduce communication issues between individuals. Just as if someone requested HMI training when they meant SCADA training, they would only know part of the picture, the same is true if they requested PLC training instead of PAC training, but on a larger scale.
- The PLC training (sections 1-7 of plc-training.org) should be taken first before moving on to the more advanced topic of PACs.
- With the computer technology of the PAC, also comes more networking and working with Ethernet. A basic understanding of industrial Ethernet is recommended before learning PACs.
- Just like with other communication types, with Ethernet, you will need to configure the Ethernet/IP on processor and in PAC communication software. additionally you will need to turn off auto IP addressing on your computer you use to communicate with PAC. Place a static IP address on your computer/laptop.
- Recommended PAC learning path after mastering PLCs and IE 101 is PAC architecture, firmware and software revision management, PAC brand specific communication software drivers and troubleshooting, I/O configuration and hardware, memory addressing (including system values), Task/Program flow and priorities, ladder logic, structured text, function block diagrams (brief on other 2 PAC programming languages), motion control, communication modules and practical PAC application.
- Important concept to be taught: with PLC I/O systems the controller polls input modules to obtain their input status. In the PAC, a controller does not poll digital input modules. Instead, the modules multicast their data either upon change of state (COS) or requested packet interval (RPI).
- PAC programming priorities should in this order of priority... first End-user Friendly, then Processing efficiency, then Programming efficiency, then Memory efficiency.
- Note: The training recommendations on this page are from an end-user's (maintenance) perspective. It is recommended that colleges first teach this perspective before moving on to their standard design engineering and programming curriculum. The most common and biggest shortcoming of college industrial automation courses are that they do not emphasize the end-users perspective and user friendliness importance. (Most students come out school placing higher importance on how they can do their job easier, rather than placing highest importance on how they can design a product/program that allows their customer do their job easier.)
Section 8: PAC Training:
The tips and best practices on this page will be helpful for ...
The industrial electrician, instrumentation tech, mechatronics technician, industrial engineer, industrial IT person, industrial software programmer and others.
Bookmark this page or site; as new best ways for PLC technician, industrial electrician, instrumentation technician and others to perform basics task are verified, they will be added here.
PLC Training Best Practices:
8.1 PAC Training Topics:
Besides scholastic PAC topics in manuals, the best way, the safest way and the most reliable to perform task associated with working with the PAC should also be taught.
When seeking out PAC training from providers not recommended by PLC-Training.org, insure their course curriculum covers all the topics recommended below.
More coming soon ...
8.1.1 PAC Training Prerequisites
Complete sections 1-7 on this site first. Depending on occupation, some topics may voluntary to have a stronger foundation in which to build on.
As the PLC was specifically designed to be simple, it is more effective and shortens the learning curve to learn PLC on a PLC not a PAC.
As a PAC was designed with the IT and computer programmer in mind, being computer literate is mandatory to learning a PAC.
As the PLC was specifically designed to be simple, it is more effective and shortens the learning curve to learn PLC on a PLC not a PAC.
As a PAC was designed with the IT and computer programmer in mind, being computer literate is mandatory to learning a PAC.
8.1.2 PAC Architecture
Learning the difference between PLC architecture and the PAC architecture is the best place to start. (different hardware architecture and programming architecture, multitasking and nesting)
Understand the difference between a PLC's Microprocessor and the full multiple processors a PAC uses.
Understand the difference between a PLCs simple single scan cycle method, and a PAC's multi-tasking method and timed method of updating I/O and prioritizing programming task.
Understand the difference between a PLC's Microprocessor and the full multiple processors a PAC uses.
Understand the difference between a PLCs simple single scan cycle method, and a PAC's multi-tasking method and timed method of updating I/O and prioritizing programming task.
8.1.3 PAC Firmware and Software Revision Management
Learn the basics of PAC firmware, updating procedures and management.
Understanding PACs where only introduced 10 or years ago, went through many changes early on and PAC software versions may not be backwards compatible which is a common cause of downtime.
Learn how to developed automation management procedures to reduce downtime associated with PAC firmware and software incompatibilities.
Understanding PACs where only introduced 10 or years ago, went through many changes early on and PAC software versions may not be backwards compatible which is a common cause of downtime.
Learn how to developed automation management procedures to reduce downtime associated with PAC firmware and software incompatibilities.
8.1.4 PAC Brand Specific Communication Software - drivers and troubleshooting
Most PAC vendors have a common communication software that communicates with their legacy PLCs, their PACs, HMIs, VFD, etc. As well as just learning how to connect to the PAC, you need to also know how to install new communications drivers and how to troubleshoot drivers.
Know how to set up USB to RS232 communication converter, on computer and within PAC vendor communication software.
More coming soon ...
Know how to set up USB to RS232 communication converter, on computer and within PAC vendor communication software.
More coming soon ...
8.1.5 PAC I/O Configuration and Hardware
With added functionality of PAC I/O comes added configuration complicity. Understand basic I/O configuration properties and that PAC I/O does not plug and play auto config like PLC I/O does.
Learn inherent time-stamping capabilities for sequence of events (SOE) applications.
I/O diagnostics for detection of both system and field-side failures. Also understanding I/O configuration and module errors.
Learn about electronic keying, point-level output fault states, on-board data alarming, scaling to engineering units.
Remember PAC I/O sends data updates at regular timed intervals, requested packet interval (RPI) or at a Change of State (COS) occurrence, not in a scan cycle method like PLC's input/ladder logic/output scan cycle is.
Remote I/O setup, communication and addressing methods.
The PAC I/O module method of communication uses the Producer/Consumer model and I/O updates are asynchronous to the program scan.
Be extremely cautious when using Disable Keying; if used incorrectly, this option can lead to personal injury or death, property damage, or economic loss.
Learn inherent time-stamping capabilities for sequence of events (SOE) applications.
I/O diagnostics for detection of both system and field-side failures. Also understanding I/O configuration and module errors.
Learn about electronic keying, point-level output fault states, on-board data alarming, scaling to engineering units.
Remember PAC I/O sends data updates at regular timed intervals, requested packet interval (RPI) or at a Change of State (COS) occurrence, not in a scan cycle method like PLC's input/ladder logic/output scan cycle is.
Remote I/O setup, communication and addressing methods.
The PAC I/O module method of communication uses the Producer/Consumer model and I/O updates are asynchronous to the program scan.
Be extremely cautious when using Disable Keying; if used incorrectly, this option can lead to personal injury or death, property damage, or economic loss.
8.1.6 PAC Memory Addressing
Introduction to tags(symbols) and data types.
Data collection with a PAC is very different from a PLC. In a PLC, data type is already pre-defined by data tables so the PLC and communications already know data type and structure. In a PAC, the programmer defines data types and structures, so the PAC and communications does not initially know data types and structures.
To include system values like first Scan bit, real time clock, etc.
Consider PAC as having unlimited memory, don't concern yourself with memory size conservation. (as PAC memory and processing speed are much greater than most applications will ever need.) If you do have exception to the general rule, a super large project/system, you may just need PAC with more memory.
Organizing PAC memory via Tag naming conventions. Keep tags as short as possible so they are easier for humans to work with, smaller programs/projects will result in smaller tag names, inherently larger programs/projects will unfortunately have larger tag names. (naming conventions help keep tag names smaller)
Best practice tag naming convention "ArrayGroupWordBit", or "Array_Group_Word_Bit" (yet to be determined)
Tag names must not have the same name as predefined functions, or UDFs (User Defined Functions) / AOIs (Add On Instructions).
Use tag descriptions to fully document and describe tag names.
Unlike PLCs which store symbols (tags) on computer only as documentation, PACs store tag names in processor too.
To share tags with other devices on the network, use a MSG instruction as preferred method over producer/consumer tag assignment method. Produced/consumed if you want available on timed intervals.
In high speed application, processing efficiency takes priority over memory usage. Remember, unlike PLCs, PACs are optimized on 32bit or 64bit processors. (one Bool bit still takes at least 32 bits of memory, often more. PAC programming priorities should always be 1. End-user user friendly, 2. Processing efficiency, 3. Programmer ease, 4. Memory usage
Understand memory arrays
Understand User Define Type (UDT).User defined data type and tag.
Organizations of tags using UDTs and Arrays is 4-10 times more efficient than individually defined tags.
Organize your data in separate critical and non-critical groups.
PAC programs using Ladder Logic and UDT/DINTs typically result in most efficient use of memory (and processing speed), with Sequential Function Chart (SFC) typically being 5 times more usage or greater.
For optimum memory and communication efficiency, use alias tags to access memory arrays (tags).
Data collection with a PAC is very different from a PLC. In a PLC, data type is already pre-defined by data tables so the PLC and communications already know data type and structure. In a PAC, the programmer defines data types and structures, so the PAC and communications does not initially know data types and structures.
To include system values like first Scan bit, real time clock, etc.
Consider PAC as having unlimited memory, don't concern yourself with memory size conservation. (as PAC memory and processing speed are much greater than most applications will ever need.) If you do have exception to the general rule, a super large project/system, you may just need PAC with more memory.
Organizing PAC memory via Tag naming conventions. Keep tags as short as possible so they are easier for humans to work with, smaller programs/projects will result in smaller tag names, inherently larger programs/projects will unfortunately have larger tag names. (naming conventions help keep tag names smaller)
Best practice tag naming convention "ArrayGroupWordBit", or "Array_Group_Word_Bit" (yet to be determined)
Tag names must not have the same name as predefined functions, or UDFs (User Defined Functions) / AOIs (Add On Instructions).
Use tag descriptions to fully document and describe tag names.
Unlike PLCs which store symbols (tags) on computer only as documentation, PACs store tag names in processor too.
To share tags with other devices on the network, use a MSG instruction as preferred method over producer/consumer tag assignment method. Produced/consumed if you want available on timed intervals.
In high speed application, processing efficiency takes priority over memory usage. Remember, unlike PLCs, PACs are optimized on 32bit or 64bit processors. (one Bool bit still takes at least 32 bits of memory, often more. PAC programming priorities should always be 1. End-user user friendly, 2. Processing efficiency, 3. Programmer ease, 4. Memory usage
Understand memory arrays
Understand User Define Type (UDT).User defined data type and tag.
Organizations of tags using UDTs and Arrays is 4-10 times more efficient than individually defined tags.
Organize your data in separate critical and non-critical groups.
PAC programs using Ladder Logic and UDT/DINTs typically result in most efficient use of memory (and processing speed), with Sequential Function Chart (SFC) typically being 5 times more usage or greater.
For optimum memory and communication efficiency, use alias tags to access memory arrays (tags).
8.1.7 PAC I/O configuration and hardware
In contrast to the the plug and play nature of PLC I/O Modules, PAC I?O modules have many manual configuration attributes that must be reviewed during design and during replacement.
Also keep in mind, unlike PLC I/O modules, PAC I/O modules each have their own microprocessor (smart I/O), are a separate device on network, and their data is transferred on a timed frequency independent of the ladder logic scan or other PAC programming. (there is no input/logic/output scan cycle in PACs.)
Also keep in mind, PAC can have many more I/O points/channels than a PLC. hundreds of thousands of discrete I/O, thousands of analog I/O.
I/O module configuration settings that are other than default should be printed out as a page in the schematics.
Always alias out your I/O as this is equivalent to utilizing the cross reference subroutine (XREF) in PLCs. Aliasing I/O is done for all the same reasons.
Because PAC I/O is updated asynchronous to the program scan, it adds one more reason to have an XREF subroutine. As an I/O buffer.
Only input modules can have multiple owner-controllers, only one controller can own/change output module values.
Just because PAC vendor states I/O is hot swappable, doesn't mean you should. Only when absolutely necessary, as process, PAC program and system configuration may be dependant on I/O module. Not to mention you could be working with live voltages too.
Before you inhibit a module, check its program state transition settings in configuration. (It may be set to make all output off, or all on, or retain last state when switched to program mode (inhibited).
When replacing PAC I/O, pay attention to the module's firmware revision number and electronic keying. Just because it is the same module number does not insure it will be compatible like it does with PLCs, with PAC I/O, additional configuration may be necessary.
When electronic keying is in 'Compatible' mode, module can be replaced by on with same or higher firmware revision number (Major: Minor). IE: A 3.7 can be replaced with a 3.7 or a 3.8 or a 4.1 for example. Do NOT ever use "Disable Keying" mode/configuration.
If remote I/O is connected to owner controller via ControlNet, you will need to reschedule network after adding/changing module or configuration.
Optimize remote I/O by using one requested packet interval (RPI) value for entire remote rack (unless using fused output modules). Reduces communication bandwidth on network.
Change Of State (COS) I/O update configuration is more efficient than RPI because it multicasts data only when a change occurs.
In high-speed applications remember to account for additional 1 ms delay is signal processing, in addition to filter configured, RPI/COS delays, etc.
Critical and safety I/O should be located on local rack with PAC processor owner when ever possible (as opposed to being located in remote I/O rack), for quicker and more reliable reaction.
If critical and safety I/O has to be wired to remote I/O, COS setting on a EtherNet/IP network, use of Immediate Output (IOT) instruction, and associated logic placed in the Continuous task may be best choices.
In design phase, like with the PLC, have 20% spare I/O, and spare slots to add future I/O.
Also keep in mind, unlike PLC I/O modules, PAC I/O modules each have their own microprocessor (smart I/O), are a separate device on network, and their data is transferred on a timed frequency independent of the ladder logic scan or other PAC programming. (there is no input/logic/output scan cycle in PACs.)
Also keep in mind, PAC can have many more I/O points/channels than a PLC. hundreds of thousands of discrete I/O, thousands of analog I/O.
I/O module configuration settings that are other than default should be printed out as a page in the schematics.
Always alias out your I/O as this is equivalent to utilizing the cross reference subroutine (XREF) in PLCs. Aliasing I/O is done for all the same reasons.
Because PAC I/O is updated asynchronous to the program scan, it adds one more reason to have an XREF subroutine. As an I/O buffer.
Only input modules can have multiple owner-controllers, only one controller can own/change output module values.
Just because PAC vendor states I/O is hot swappable, doesn't mean you should. Only when absolutely necessary, as process, PAC program and system configuration may be dependant on I/O module. Not to mention you could be working with live voltages too.
Before you inhibit a module, check its program state transition settings in configuration. (It may be set to make all output off, or all on, or retain last state when switched to program mode (inhibited).
When replacing PAC I/O, pay attention to the module's firmware revision number and electronic keying. Just because it is the same module number does not insure it will be compatible like it does with PLCs, with PAC I/O, additional configuration may be necessary.
When electronic keying is in 'Compatible' mode, module can be replaced by on with same or higher firmware revision number (Major: Minor). IE: A 3.7 can be replaced with a 3.7 or a 3.8 or a 4.1 for example. Do NOT ever use "Disable Keying" mode/configuration.
If remote I/O is connected to owner controller via ControlNet, you will need to reschedule network after adding/changing module or configuration.
Optimize remote I/O by using one requested packet interval (RPI) value for entire remote rack (unless using fused output modules). Reduces communication bandwidth on network.
Change Of State (COS) I/O update configuration is more efficient than RPI because it multicasts data only when a change occurs.
In high-speed applications remember to account for additional 1 ms delay is signal processing, in addition to filter configured, RPI/COS delays, etc.
Critical and safety I/O should be located on local rack with PAC processor owner when ever possible (as opposed to being located in remote I/O rack), for quicker and more reliable reaction.
If critical and safety I/O has to be wired to remote I/O, COS setting on a EtherNet/IP network, use of Immediate Output (IOT) instruction, and associated logic placed in the Continuous task may be best choices.
In design phase, like with the PLC, have 20% spare I/O, and spare slots to add future I/O.
8.1.8 PAC Task/Program Flow and Priorities
Unlike PLCs, PACs processing is grouped into a Continuous Task and Periodic Tasks.
The CPU constantly swaps between running the task and servicing communications.(communicating with motion control, I/O, and messaging)
The code for the control modules (task, programs, subroutines and memory allocation) should be sorted for optimal data flow during execution.
The default task is the Continuous Task, and there can only be one.
Timed period task should only be used when necessary (like for communication functions), and the number of periodic tasks should be kept to the minimum.
Conditional periodic task is preferred over timed periodic task.
Periodic tasks run without being interrupted by communications. Communications are only serviced in-between periodic task executions.
Periodic task should be set to the minimum frequency (rate) required by the controlled process with conditional.
The frequency of scheduling points should be such that one can be reached within a few milliseconds to allow the controller to reach a safe state in the event of a power failure.
Use a fault routine to allow logic to run before the controller faults due to a programming error.
Create your own libraries of task (like fw-rv motor control, zoned conveyor lines, etc.) for better organization and also to re-use on other projects.
The CPU constantly swaps between running the task and servicing communications.(communicating with motion control, I/O, and messaging)
The code for the control modules (task, programs, subroutines and memory allocation) should be sorted for optimal data flow during execution.
The default task is the Continuous Task, and there can only be one.
Timed period task should only be used when necessary (like for communication functions), and the number of periodic tasks should be kept to the minimum.
Conditional periodic task is preferred over timed periodic task.
Periodic tasks run without being interrupted by communications. Communications are only serviced in-between periodic task executions.
Periodic task should be set to the minimum frequency (rate) required by the controlled process with conditional.
The frequency of scheduling points should be such that one can be reached within a few milliseconds to allow the controller to reach a safe state in the event of a power failure.
Use a fault routine to allow logic to run before the controller faults due to a programming error.
Create your own libraries of task (like fw-rv motor control, zoned conveyor lines, etc.) for better organization and also to re-use on other projects.
8.1.9 PAC Ladder Logic
Complete sections 1-7 on this site first. Depending on occupation, some topics may voluntary to have a stronger foundation in which to build on. specifically section 6 and PLC Programming Training -BP6.
Ladder logic in a PAC is pretty much the same as a PLC, with memory addressing/Tags (8.1.6) and processing method (8.1.8) being areas that are different therefore there is a needed for additional learning.
Especially keep aware while programming that unlike a PLC, with a PAC values can be changing state in the middle of the scan (program execution).
Consider whether there is any need to buffer input data, so that its value remains constant during program execution.
With ease of use to the end user (maintenance)being a higher priority than ease of programming to programmer, Ladder Logic should be primary language used in PAC.
PAC programming objectives in order of priority; perform expected functions safely and reliability, make it user friendly and organized for the layperson to understand, make it easily expandable and portable (re-usable) to future projects.
The main subroutine should be reserved for critical safety rungs and program control like jump to subroutine instructions only. (Keep main subroutine a small as possible.)
Object oriented methods for ladder logic (both in PLC and PACs) equates to subroutines. Group your ladder logic into logical subroutines, called by the main subroutine mentioned above.
Best practice is to use JMP instructions sparingly. Jumps in ladder logic often make the program difficult to read and troubleshoot equipment with.
With a PAC, DINT (32 bit integer) memory size is more efficient to use, even if you only have a 8 (SINT) or 16 bit (INT) long word you are dealing with.
Symbols/Tags should be as short as possible, descriptions as detailed as possible, every rung should have a description.
The tag description should have all acronyms and abbreviated words found in tag, spelled out. (IE: Tag PE1 has description Photo Eye 1 load present)
Never use 2 or more output coils in series, even if the PLC programming software allows it.
Processor status bits such as faults, time base, EEPROM/Flash, Real date/time and other commonly used status memory should be made easily accessible in it's own subroutine.
Just as PLC Training using topic arrays is more efficient, so is the frequent use of arrays in your programming.
Avoid PAC programming methods that prevent effective online monitoring (like using indirect address/arrays to loop through 7 duplicate warehouse conveyors using the ladder logic.)
PAC ladder logic programming will consist of additional alarms and programming interlocks provided by I/O module processors. Additional I/O faults to monitor, COS time stamps, breaker tripped bits, etc.)
Place all your fault data in one array, alarm data in another, alarm timers in another array, etc. Use dummy output rungs to display all alarms in a single rung for ease of troubleshooting by end user.
Avoid using constants in ladder logic, use tags/memory areas instead. Realizing there may be exceptions to that general rule in rare occurrences.
Give much thought to end-user before utilizing UDF/AOI in your program and document well if you do. Consider end-user's understanding, troubleshooting and future modification of program over the life of the equipment being controlled. As a general rule do not use them, secondary rule, keep them simple with most data/variables contained outside the proprietary user defined function/instruction.
Also with UDF/AOI, be sure to consider how it reacts on startup and when construct is not scanned, could end-user need access to timers, counters, arrays and other data contained within the UDF/AOI that they will not have access to.
Only use alternate programming languages to ladder logic like structured text, when necessary.
Ladder logic in a PAC is pretty much the same as a PLC, with memory addressing/Tags (8.1.6) and processing method (8.1.8) being areas that are different therefore there is a needed for additional learning.
Especially keep aware while programming that unlike a PLC, with a PAC values can be changing state in the middle of the scan (program execution).
Consider whether there is any need to buffer input data, so that its value remains constant during program execution.
With ease of use to the end user (maintenance)being a higher priority than ease of programming to programmer, Ladder Logic should be primary language used in PAC.
PAC programming objectives in order of priority; perform expected functions safely and reliability, make it user friendly and organized for the layperson to understand, make it easily expandable and portable (re-usable) to future projects.
The main subroutine should be reserved for critical safety rungs and program control like jump to subroutine instructions only. (Keep main subroutine a small as possible.)
Object oriented methods for ladder logic (both in PLC and PACs) equates to subroutines. Group your ladder logic into logical subroutines, called by the main subroutine mentioned above.
Best practice is to use JMP instructions sparingly. Jumps in ladder logic often make the program difficult to read and troubleshoot equipment with.
With a PAC, DINT (32 bit integer) memory size is more efficient to use, even if you only have a 8 (SINT) or 16 bit (INT) long word you are dealing with.
Symbols/Tags should be as short as possible, descriptions as detailed as possible, every rung should have a description.
The tag description should have all acronyms and abbreviated words found in tag, spelled out. (IE: Tag PE1 has description Photo Eye 1 load present)
Never use 2 or more output coils in series, even if the PLC programming software allows it.
Processor status bits such as faults, time base, EEPROM/Flash, Real date/time and other commonly used status memory should be made easily accessible in it's own subroutine.
Just as PLC Training using topic arrays is more efficient, so is the frequent use of arrays in your programming.
Avoid PAC programming methods that prevent effective online monitoring (like using indirect address/arrays to loop through 7 duplicate warehouse conveyors using the ladder logic.)
PAC ladder logic programming will consist of additional alarms and programming interlocks provided by I/O module processors. Additional I/O faults to monitor, COS time stamps, breaker tripped bits, etc.)
Place all your fault data in one array, alarm data in another, alarm timers in another array, etc. Use dummy output rungs to display all alarms in a single rung for ease of troubleshooting by end user.
Avoid using constants in ladder logic, use tags/memory areas instead. Realizing there may be exceptions to that general rule in rare occurrences.
Give much thought to end-user before utilizing UDF/AOI in your program and document well if you do. Consider end-user's understanding, troubleshooting and future modification of program over the life of the equipment being controlled. As a general rule do not use them, secondary rule, keep them simple with most data/variables contained outside the proprietary user defined function/instruction.
Also with UDF/AOI, be sure to consider how it reacts on startup and when construct is not scanned, could end-user need access to timers, counters, arrays and other data contained within the UDF/AOI that they will not have access to.
Only use alternate programming languages to ladder logic like structured text, when necessary.
8.1.10 PAC Structured Text
Structured Text (ST) should be reserved primarily for data manipulation and mathematical calculations that demand it.
The most powerful of the five IEC 61313-3 languages when it comes to iterations whether repeating a fixed number of times or conditionally.
Unlike PLC ladder logic, with structured text it's strengths are also its weakness; you need to watch for loops and syntax errors.
The ST language contains a list of statements, such as assignment statements (variable:= expression), conditional statements (if, then, else, case), iteration statements (for, while, repeat) and control statements (exit, return).
Even with structured text, group code into organized subroutines for easy reading, modification, and troubleshooting.
Although Structured text is not case sensitive, it should be able to display both upper and lower case for documentation purposes. (No auto-all-caps).
Use tabs and carriage returns (separate lines) to make your structured text easier to read.
//comment on all constructs as a minimum. Try to avoid inline comments, comments on their own separate line preferably.
I/O module data updates asynchronously to the execution of logic. If you reference an input multiple times in your logic, the input could change state between separate references. If you need the input to have the same state for each reference, buffer the input value and reference that buffer tag. (Like you do in XREF subroutine, but copying arrays or UDTs at a time.)
Some PACs have a separate tag editor instead of defining your variable names at beginning of structured text.
To make structured text easier to read, use parentheses to group expressions within expressions.
For...Do;While..Do;Repeat..Until loops: Do not iterate within the loop too many times in a single scan. As the controller doesn't execute other statements in the routine until it completes the loop.
In some PACs, you can use ladder logic instructions in structured text. So PACs you can not. You may have to create your own timers in structured text using +1 and a 1 second pulse from controller status for example.
Because structured text /* comments downloads to controller, you can create a structured text file even with comments only, named 'readme', and store additional setup help, notes to end-users other programmers, etc. (For access to those who don't have a documented copy of program, they at least have access to tag names and structured text comments.)
The most powerful of the five IEC 61313-3 languages when it comes to iterations whether repeating a fixed number of times or conditionally.
Unlike PLC ladder logic, with structured text it's strengths are also its weakness; you need to watch for loops and syntax errors.
The ST language contains a list of statements, such as assignment statements (variable:= expression), conditional statements (if, then, else, case), iteration statements (for, while, repeat) and control statements (exit, return).
Even with structured text, group code into organized subroutines for easy reading, modification, and troubleshooting.
Although Structured text is not case sensitive, it should be able to display both upper and lower case for documentation purposes. (No auto-all-caps).
Use tabs and carriage returns (separate lines) to make your structured text easier to read.
//comment on all constructs as a minimum. Try to avoid inline comments, comments on their own separate line preferably.
I/O module data updates asynchronously to the execution of logic. If you reference an input multiple times in your logic, the input could change state between separate references. If you need the input to have the same state for each reference, buffer the input value and reference that buffer tag. (Like you do in XREF subroutine, but copying arrays or UDTs at a time.)
Some PACs have a separate tag editor instead of defining your variable names at beginning of structured text.
To make structured text easier to read, use parentheses to group expressions within expressions.
For...Do;While..Do;Repeat..Until loops: Do not iterate within the loop too many times in a single scan. As the controller doesn't execute other statements in the routine until it completes the loop.
In some PACs, you can use ladder logic instructions in structured text. So PACs you can not. You may have to create your own timers in structured text using +1 and a 1 second pulse from controller status for example.
Because structured text /* comments downloads to controller, you can create a structured text file even with comments only, named 'readme', and store additional setup help, notes to end-users other programmers, etc. (For access to those who don't have a documented copy of program, they at least have access to tag names and structured text comments.)
8.1.11 PAC Function Block Diagrams
Function Block Diagrams (FBD) can be used within the other IEC 61131-3 standard's four programming languages too.
FBD are the integrated circuit (IC) of the 5 PAC programming languages. With input and output pins on boxes, connecting lines to transfer data from one function block to another. Commonly used FBD are timers, counters, and PID constructs.
The execution order is represented by the order of the graphic symbols (boxes) in FBD, from left to right, and from top to bottom.
The line connecting two FBD together may be limited to transferring 40 characters of data (typical string length).
For larger data structures as inputs or outputs on a function block, the in_out parameter type is processed more efficiently. But because a PAC is task driven and a function block can be interrupted by task switching, the in_out parameter type should only be used when absolutely necessary.
Do not call event-driven function blocks in an If or Case statement or SFB as errors may occur.
To include introduction of other 2 PAC programming languages also (IL & SFC).
It is best practice to use Function Block Diagrams (FBD) to program PID loops.
When a function block is disabled (that is, EN = False), it is not processed there by decreasing overall processing time, in comparison with disabling inputs internally within the function block.
Use a latching/unlatching bit combination to monitor Function block Error and Warning parameters as they are only a pulse during one scan.
Be mindful of potential loops between to 2 FBD control modules.
FBD are the integrated circuit (IC) of the 5 PAC programming languages. With input and output pins on boxes, connecting lines to transfer data from one function block to another. Commonly used FBD are timers, counters, and PID constructs.
The execution order is represented by the order of the graphic symbols (boxes) in FBD, from left to right, and from top to bottom.
The line connecting two FBD together may be limited to transferring 40 characters of data (typical string length).
For larger data structures as inputs or outputs on a function block, the in_out parameter type is processed more efficiently. But because a PAC is task driven and a function block can be interrupted by task switching, the in_out parameter type should only be used when absolutely necessary.
Do not call event-driven function blocks in an If or Case statement or SFB as errors may occur.
To include introduction of other 2 PAC programming languages also (IL & SFC).
It is best practice to use Function Block Diagrams (FBD) to program PID loops.
When a function block is disabled (that is, EN = False), it is not processed there by decreasing overall processing time, in comparison with disabling inputs internally within the function block.
Use a latching/unlatching bit combination to monitor Function block Error and Warning parameters as they are only a pulse during one scan.
Be mindful of potential loops between to 2 FBD control modules.
8.1.12 PAC Motion Control
First update your software version to the latest and your firmware.
Have the many servo/drive configuration data reset back to default can be very frustrating and time consuming. So follow PAC and drive vendor's manual step by step. If you rush through it, you may be doing it twice or more.
First configure PAC and its communication module, then configure the drive module and axis, then write program and download.
For all communication modules, use the firmware revision that goes with the firmware revision of your controller.
Do not use default IP addresses for servo modules, at least change the channel.
Motion control typically deals with device like that have further length of travel like robots. So security and reliability are that much more critical.
It is recommended that you take a computer networking course at this point, if you haven't already. At least IT infrastructure.
The TCP and CIP connections need to be fully understood.
The Motion Task should not take more than 50% of the overall PAC controller's average processing time (PAC program scan cycle).
If you have not enabled time synchronization, you may get errors when you try to associate an axis.
You can use feedback only axes, for example, as a master reference for gearing, with PCAM moves, and MAOC output CAMs.
PACs having 486 or Pentium 32bit CPUs can process coordinate data quickly enough to smooth the robot-arm motion, and save the expense of using a step motor. They even process quicker than computers when using RISK computing technique.
Have the many servo/drive configuration data reset back to default can be very frustrating and time consuming. So follow PAC and drive vendor's manual step by step. If you rush through it, you may be doing it twice or more.
First configure PAC and its communication module, then configure the drive module and axis, then write program and download.
For all communication modules, use the firmware revision that goes with the firmware revision of your controller.
Do not use default IP addresses for servo modules, at least change the channel.
Motion control typically deals with device like that have further length of travel like robots. So security and reliability are that much more critical.
It is recommended that you take a computer networking course at this point, if you haven't already. At least IT infrastructure.
The TCP and CIP connections need to be fully understood.
The Motion Task should not take more than 50% of the overall PAC controller's average processing time (PAC program scan cycle).
If you have not enabled time synchronization, you may get errors when you try to associate an axis.
You can use feedback only axes, for example, as a master reference for gearing, with PCAM moves, and MAOC output CAMs.
PACs having 486 or Pentium 32bit CPUs can process coordinate data quickly enough to smooth the robot-arm motion, and save the expense of using a step motor. They even process quicker than computers when using RISK computing technique.
8.1.13 PAC Communication Modules
To include basic understanding of Ethernet, RS232, RS485 and the Common Industrial Protocol (CIP).
Familiarity with configuring and using DeviceNet module and ControlNet module and Modbus module.
PACs more commonly use a produced/consumer communication model where shared device data is sent to an OPC/DDE server to be accessed by allowed devices and to speed up communication speed and handle more data exchange. (In contrast to PLC that commonly uses slower peer to peer, pole device when data need method.)
PACs more commonly use a produced/consumer communication model where shared device data is sent to an OPC/DDE server to be accessed by allowed devices and to speed up communication speed and handle more data exchange. (In contrast to PLC that commonly uses slower peer to peer, pole device when data need method.)
Learn at least one PAC vendor specific protocol like Rockwell's Data Highway+
To reduce hardware cost, make one of the HMI stations the RSLinx Classic Gateway server.
HMI screens can not update at 10ms, so there is not a need to over task your processor by polling data at that rate, start with 250ms.
To reduce hardware cost, make one of the HMI stations the RSLinx Classic Gateway server.
HMI screens can not update at 10ms, so there is not a need to over task your processor by polling data at that rate, start with 250ms.
8.1.14 Study Practical PAC Applications
Start with your particular PAC vendor's sample applications. Ladder Logic, tasking, user defined, Ethernet networking, motion control.
8.2 Working with PACs and Automation
When inventorying all control automation in your facility to distinguish in documentation if PLC or PAC. If it is a PAC their will be higher security measures, firmware/revision number notations among other .critical data collected.
PACs have a lot more configuration data than PLCs do, so make sure you do not overlook some when documenting. It makes additional backup copies that much more important. REF: How to back up a PLC program article.
More coming soon ...
8.2.1 Working with PACs Safely
Documentation is fundamental to safety. Documentation helps through better understanding and direct warnings
Anything to do with PAC forces is a safety issue and and should be handles with standard safety protocols. PAC forces allow the machine to operate other than it was designed for. Even safety sensors like light curtains can be forced ON so machine does not see human in harms way.
Anything to do with PAC forces is a safety issue and and should be handles with standard safety protocols. PAC forces allow the machine to operate other than it was designed for. Even safety sensors like light curtains can be forced ON so machine does not see human in harms way.
8.2.2 Working with PACs Securely
Follow Recommended procedures below for Remote OEM support capabilities...
2.2.3 Working with PACs Reliably
With PAC software being windows compatible, there are several ways to perform each task, but some times one way is more reliable than another.
8.3 PAC commissioning best practices
Never use default node and IP address
Never leave a PLC force in place longer than 24 hours, follow safety protocol.
In control system design phase, place the I/O close to point of use and minimize installation and commissioning time.
Use digitally networked servo drives to simplify commissioning and reduce cabling costs.
8.3.1 Recommended procedures for Remote OEM support capabilities...
Remote access can increase OEM support quality and speed at a lower cost. It can even greatly reduce lifecycle cost. But it can be a challenge, delivering the benefits of remote access while addressing security concerns.
Only leave VPN connection physically connected to the outside world, long enough to do the OEM work.
Save a copy of program before OEM access, and another additional copy after they are done.
Have OEM service techs visiting site review your Machine security policies and signoff on them. (preferably scan their laptop for viruses before allowing access, as they may have been on the hotel's open wifi the night before working on your equipment.)
Always make the mental connection, that "cloud" services, from a security point of view, is "internet" services. 'Cloud" services are typically more secure than just plain old internet, but both are much less secure than VPN or keeping the potential damage to man or machine inside the physical location via physical isolation.
More coming soon ...
Save a copy of program before OEM access, and another additional copy after they are done.
Have OEM service techs visiting site review your Machine security policies and signoff on them. (preferably scan their laptop for viruses before allowing access, as they may have been on the hotel's open wifi the night before working on your equipment.)
Always make the mental connection, that "cloud" services, from a security point of view, is "internet" services. 'Cloud" services are typically more secure than just plain old internet, but both are much less secure than VPN or keeping the potential damage to man or machine inside the physical location via physical isolation.
More coming soon ...
Next ... Section 9: Advanced Automation Training Best Practices.
Want to add a constructive comment, discuss this page? See PLC Training Forum PAC
Recommended PLC training path by occupation...
Mechanic
Industrial Electrician
Industrial Engineer
Commercial Electrician
Instrumentation Tech
Industrial IT
Maintenance Manager
Mechatronics Tech
Software Programmer