Advance Manufacturing Engineering Book of Implementation Guidelines AMS 0220 Section 11.3.1 Revision Date: 08/01/07 Page 1 of 25 Revision: 1.3
Proprietary Notice This document comprises legally protected subject matter proprietary to Chrysler, and is loaned on the basis of confidential relationship. All use and disclosure is strictly controlled. Reproduction is prohibited without the permission of Chrysler. Documentation Standards, Version 2.0 Copyright 2007, Chrysler. All Rights Reserved. Revision Date: 08/01/07 Page 2 of 25 Revision: 1.3
Table of Contents 1.0 GENERAL...5 1.1 PURPOSE...5 1.2 SCOPE...5 1.3 USERS...5 2.0 GENERAL DESCRIPTION...6 2.1 MEMORY AND SCAN TIME...6 2.2 PROGRAM FILES...6 3.0 INSTALLING THE DRIVER...7 3.1 INSTALLING THE PFCS DRIVER LOGIC IN THE PROCESS CONTROLLER...7 3.2 INSTALLING THE PFCS DRIVER LOGIC IN A SEPARATE ITM CONTROLLER...9 4.0 PFCS DRIVER CONFIGURATION...10 4.1 MESSAGE INSTRUCTION CONFIGURATION...10 4.2 PFCS DRIVER CONFIGURATION...14 4.3 PFCS CONTROLLER CONFIGURATION...16 4.4 DRIVER JSR CONFIGURATION...18 5.0 COMMANDS...19 5.1 SOLICITED DATA REQUEST...19 5.2 DATA SEND...20 5.3 UNSOLICITED DATA RECEIVE...21 5.4 DRIVER STATUS TAGS...21 6.0 SOFTWARE SEQUENCE OF OPERATIONS...22 6.1 SOLICITED DATA REQUEST...22 6.2 UNSOLICITED DATA SEND...22 6.3 UNSOLICITED DATA RECEIVE...23 APPENDIX A: SUPPORTING DOCUMENTATION...24 APPENDIX B: GLOSSARY & CONDITIONS...24 TERMS & CONVENTIONS...24 USE OF SHALL, MAY AND SHOULD...24 REVISION HISTORY...25 Revision Date: 08/01/07 Page 3 of 25 Revision: 1.3
Table of Tables Table 1: Supporting Documentation...24 Table 2: Terms and Conventions...24 Table of Tables Figure 1: Copy UDTs...7 Figure 2: Copy Controller-Scoped Tags...8 Figure 3: Copy the PFCS Program Tags...9 Figure 4: Rung 25 Main_Comm Configuration Message Verification...10 Figure 5: Rung 39 Main_Comm Configuration Message Verification...11 Figure 6: Rung 51 Main_Comm Configuration Message Verification...12 Figure 7: Rung 65 Main_Comm Configuration Message Verification...13 Figure 8: PFCS General Configuration...14 Figure 9: PFCS Controller Configuration...16 Figure 10: JSR Configuration...18 Figure 11: Solicited Data Request Example - Main Routine Rung 3...19 Figure 12: Data Send Example - Main Routine Rung 4...20 Revision Date: 08/01/07 Page 4 of 25 Revision: 1.3
1.0 GENERAL 1.1 PURPOSE The purpose of this document is to provide ControlLogix (CLx) driver integration guidelines for Plant Floor Communication System (PFCS) networks as defined by Chrysler - North American Operations. 1.2 SCOPE 1.2.1 This document provides CLx driver integration guidelines that shall be followed for all PFCS applications developed for Chrysler machinery and equipment. 1.3 USERS - Suppliers (e.g. Suppliers, Suppliers, Integrators, Vendors) - Chrysler (e.g. Launch Engineers, Control Engineers, Process Engineers) - Any individual and or organization involved in the design and installation of control systems for Chrysler. Revision Date: 08/01/07 Page 5 of 25 Revision: 1.3
2.0 GENERAL DESCRIPTION Note throughout this document build data/information downloads from PFCS are mentioned, the user should have in mind that the origin of these data are either Chrysler Broadcast System or AVI WCC and PFCS WCC only receives, logs and redirects these messages between floor equipment and WCCs. The purpose of the PFCS (Plant Floor Communication System) communication driver is to provide a common interface to the PFS (Performance Feedback System). Communication from the plant floor to PFCS occurs through the PFCS Driver. This logic will allow the CLx processor to send quality information to PFS and receive build or style-specific information from PFS. The logic provides two communication channels to send and receive information from PFCS. For this driver, the channels are EtherNet/IP. All configuration and interfacing logic required is documented herein. For more information on the PFCS interface, refer to the Chrysler document titled PFCS Vendor Specification. 2.1 MEMORY AND SCAN TIME The logic requires approximately 170K bytes of CLx memory (data and program), and will add approximately 0.5ms of scan time, peaking at approximately 4 ms of scan time. 2.2 PROGRAM FILES The driver logic uses the following program files to interface the Chrysler PFCS system: Main_Comm MsgDecode Msg_Build Main communication routine (send & receive data, report status) Interrogate incoming messages and route to SUPPLIER data tables Format message string Cont_Comm Communication with remote PFCS controllers (This part of the application is an add-on module, if the processor with PFCS application should communicate with other processors, ask an APICS Engineer for instructions and logic) Revision Date: 08/01/07 Page 6 of 25 Revision: 1.3
3.0 INSTALLING THE DRIVER Before installing the driver, verify the driver installation requirements. The driver may be installed in the same controller as the process program, or in a separate ITM controller, i.e. this driver could reside in the same ControlLogix processor as the program that ultimately consumes PFCS data or a different processor. 3.1 INSTALLING THE PFCS DRIVER LOGIC IN THE PROCESS CONTROLLER To install the PFCS driver logic in the same controller as the process program, perform the following steps: 1. Open two sessions of RSLogix5000. 2. In session #1, open the USPx_PFCSMaster.acd file. 3. In session #2, open the process program where the driver is to be installed. 4. Copy all UDTs with the z_pfcs prefix from the master file in session #1 into the user defined data table area for the process program in session #2. UDTs (z_pfcs) SESSION #1 SESSION #2 Figure 1: Copy UDTs Revision Date: 08/01/07 Page 7 of 25 Revision: 1.3
5. Copy all controller-scoped tags in session #1 into the process program in session #2. CONTROLLER- SCOPED TAGS SESSION #1 SESSION #2 Figure 2: Copy Controller-Scoped Tags Revision Date: 08/01/07 Page 8 of 25 Revision: 1.3
6. Copy the PFCS program from the main task of session #1 into the main task in session #2 7. Verify that the program scoped tags in the PFCS Program in session #1 copied with the PFCS Program in step #6. 8. Verify that the program routines in the PFCS Program in session #1 copied with the PFCS Program in step #6. 9. Close session #1. The PFCS driver logic has been installed. 10. Save session 2 with a new name in accordance with the BOIG AMS 0220 Section 2 EQUIPMENT NAMING. SESSION #1 SESSION #2 Figure 3: Copy the PFCS Program Tags 3.2 INSTALLING THE PFCS DRIVER LOGIC IN A SEPARATE ITM CONTROLLER The PFCS driver logic is pre-installed in ITM controllers supplied by Chrysler ITM. Revision Date: 08/01/07 Page 9 of 25 Revision: 1.3
4.0 PFCS DRIVER CONFIGURATION 4.1 MESSAGE INSTRUCTION CONFIGURATION Eight messages must be verified at four rungs to confirm configuration. The following configurations should be set automatically by the driver, but should be verified and modified to match, if necessary. If entries are made, please note that entries are case sensitive. 4.1.1 Verify the message instruction at rung 25 of the Main_Comm routine is configured as follows: At the Configuration Tab, verify that all entries match the screen shown in Figure 4. 25 Figure 4: Rung 25 Main_Comm Configuration Message Verification Revision Date: 08/01/07 Page 10 of 25 Revision: 1.3
4.1.2 Verify the message instruction at rung 39 of the Main_Comm routine is configured as follows: At the Configuration Tab, verify that all entries match the screen shown in Figure 5. 39 Figure 5: Rung 39 Main_Comm Configuration Message Verification Revision Date: 08/01/07 Page 11 of 25 Revision: 1.3
4.1.3 Verify the message instruction at rung 51 of the Main_Comm routine is configured as follows: At the Configuration Tab, verify that all entries match the screen shown in Figure 6. 51 Figure 6: Rung 51 Main_Comm Configuration Message Verification Revision Date: 08/01/07 Page 12 of 25 Revision: 1.3
4.1.4 Verify the message instruction at rung 65 of the Main_Comm routine is configured as follows: At the Configuration Tab, verify that all entries match the screen shown in Figure 7. Figure 7: Rung 65 Main_Comm Configuration Message Verification Revision Date: 08/01/07 Page 13 of 25 Revision: 1.3
4.2 PFCS DRIVER CONFIGURATION Configuration takes place in the PFCS program-scoped tag (PFCSConfig): Figure 8: PFCS General Configuration Driver Enable Sub-element Name: PFCSConfig.Enable Set the value of this variable to 1 to enable or to 0 to disable the PFCS Driver. Driver Initialize Request Sub-element Name: PFCSConfig.Init This bit initializes driver pointers and sets all static driver configurations. Whenever configuration changes are made, the value of this bit must be set to 1 for values to take effect. Revision Date: 08/01/07 Page 14 of 25 Revision: 1.3
Driver Slot Location Sub-element Name: PFCSConfig.DriverSlotLoc Set the value of this variable to equal the slot location of the controller or where the PFCS driver is located. Data Controller Quantity Sub-element Name: PFCSConfig.DataCntlrQty Set the value of this configuration element to the correct number of ControlLogix Memory Tag block controllers this driver will communicate with. If ControlLogix Memory Tag blocks are only located in the controller where the PFCS driver is located, the value is set to 1. Unsolicited Communication Enable Sub-element Name: PFCSConfig.UnSolCommEnable Enables unsolicited communication. 1 = enabled, 0 = not enabled Note 1: Solicited communication is automatically enabled. Note 2: For a detail application and specification of different PFCS message types refer to Appendix A (Supporting Documents). Type 1 Time Out Sub-element Name: PFCSConfig.TimeOutType1 Acknowledges time out for Type 1 messages (how long the driver will wait for response to a Type 1 message). Typically set to 5000 ms. Type 2 Time Out Sub-element Name: PFCSConfig.TimeOutType2 Acknowledges time out for Type 2, 4, 5, or 6 messages (how long the driver will wait for response to a Type 2 message). Typically set to 5000 ms. Type 3 Time Out Sub-element Name: PFCSConfig.TimeOutType3 Acknowledges time out for Type 3 messages (how long the driver will wait for response to a Type 3 message). Typically set to 5000 ms. Solicited Machine ID Sub-element Name: PFCSConfig.SolMachineID Value for PFCS solicited machine ID set up in arrays of 10. Position 0 is the base machine ID. Unsolicited Machine ID Sub-element Name: PFCSConfig.UnSolMachID Value for PFCS unsolicited machine ID. ENBT Location Sub-element Name: PFCSConfig.ENBTSlot Slot location of 1756-ENBT Communication Module that communicates with the PFCS WCC. Set the value of this variable for the correct slot number. WCC IP Address Sub-element Name: PFCSConfig.WCC_IP IP Address of the WCC the PFCS driver needs to communicate with. Set the value of this tag to the correct IP address of the PFCS WCC. Note, this value is set in ASCII. Revision Date: 08/01/07 Page 15 of 25 Revision: 1.3
4.3 PFCS CONTROLLER CONFIGURATION PFCS controller configuration is an array of configurations for each process controller that has status ControlLogix Memory Tag blocks to be shipped to the WCC. The PFCS driver will automatically retrieve ControlLogix Memory Tag blocks from each configured process controller. The quantity of process controllers processed by the PFCS driver is configured in the General Drivers Configuration: Figure 9: PFCS Controller Configuration Location Sub-element Name: PFCSControllerConfig[*].Location Location of the PFCS ControlLogix Memory Tag blocks to be processed in relation to the PFCS driver. A value of 1 indicates local (same controller as PFCS driver), a value of 2 indicates remote (different controller as PFCS driver). Communication Type Sub-element Name: PFCSControllerConfig[*].CommType The communication type used to retrieve ControlLogix Memory Tag blocks: 1 = Backplane 2 = ControlNet 3 = EtherNet Revision Date: 08/01/07 Page 16 of 25 Revision: 1.3
Communication Slot Sub-element Name: PFCSControllerConfig[*].CommSlot Location of the communication module used to retrieve ControlLogix Memory Tag blocks. Target Node Sub-element Name: PFCSControllerConfig[*].TargetNode This is the ControlNet node address of the ControlNet module in the remote rack housing the PFCS ControlLogix Memory Tag block controller. This is only applicable when ControlNet is used. Target Slot Sub-element Name: PFCSControllerConfig[*].TargetSlot This is the slot number of the PFCS ControlLogix Memory Tag block controller. Target IP Sub-element Name: PFCSControllerConfig[*].TargetIP This is the IP address of the EtherNet module in the remote rack housing the PFCS ControlLogix Memory Tag block controller. This is only applicable when EtherNet is used. Revision Date: 08/01/07 Page 17 of 25 Revision: 1.3
4.4 DRIVER JSR CONFIGURATION The command interface to the PFCS Driver is a Jump-to-Subroutine (JSR) instruction to the Msg_Build routine. The values of the input parameters in the JSR Instruction determine the command request and configuration. For every command request required, a JSR command as shown in rung 3 of figure 10 below is required. Note, the AFI instruction in the rung should be replaced with trigger logic. The JSR should be programmed in the Main_Routine of the PFCS Program. JSR CONFIG Figure 10: JSR Configuration The input parameters (numbered 1-6) and associated functions for the Msg_Build JSR are described below. 1. Command Type the type of command message required to send to PFCS. Message values are: 1 = Data Request 2, 4, 5, 6 = Unsolicited Data Send 9999 = Keep Alive (Keep Alive messages are only generated by the PFCS Driver) 2. Output Data Buffer Pointer numeric value (0-4) determines which position within the array (PFCSSolOutDataBuffer(x) ) to retrieve the data to be shipped to PFCS. 3. Message Byte Length this is the number of bytes of data from the Output Data Buffer to send to PFCS. 4. Input Data Buffer Pointer - numeric value (0-4) determines which position within the array (PFCSSolInDataBuffer(x) ) to put data delivered from PFCS. 5. Machine ID Pointer numeric value (0-9) passed to the subroutine to indicate which machine ID a data-block is being generated for. A 0 indicates the base machine ID, a positive number between 1 and 9 refers to the first to the ninth additional machine ID. 6. Build Message Comm Type determines which Comm channel to send message to: 0 = Solicited Message Channel 1 = Unsolicited Message Channel Revision Date: 08/01/07 Page 18 of 25 Revision: 1.3
5.0 COMMANDS 5.1 SOLICITED DATA REQUEST This is a request for build/vehicle information from the host system. A one-shot jump to subroutine trigger is required to replace the AFI instruction shown in Figure 11. The following JSR information is also required: Command type - this is a value of 1 for command type 1. Output Data Buffer Pointer numeric value (0-4) determines which position within the array (PFCSSolOutDataBuffer(x) ) to retrieve the data to be shipped to PFCS. Message Byte Length this is the number of bytes of data from the Output Data Buffer to send to PFCS. Input Data Buffer Pointer - numeric value (0-4) determines which position within the array (PFCSSolInDataBuffer(x) ) to put data delivered from PFCS. Machine ID Pointer numeric value (0-9) passed to the subroutine to indicate which machine ID a data-block is being generated for. A 0 indicates the base machine ID, a positive number between 1 and 9 refers to the first to the ninth additional machine ID. Build Message Comm Type Set to a value of 0 for solicited communication channel. The driver logic uses the given information to generate the request to PFCS. The driver waits for a response. When a response is received, the data is placed in the buffer word location specified by the SUPPLIER in the JSR command. The SUPPLIER is responsible for decoding the data response from PFCS. All header information will be removed, but the requested build/vehicle information will be in the raw ASCII format received from PFCS. RUNG 3 Figure 11: Solicited Data Request Example - Main Routine Rung 3 Revision Date: 08/01/07 Page 19 of 25 Revision: 1.3
5.2 DATA SEND This data is sent to the host system. An example of this could be torque data. A one-shot jump to subroutine trigger is required to replace the AFI instruction shown in Figure 12. The following JSR information is also required: Command type - this is a value of 2, 4, 5 or 6. All are the same command type, but PFCS will use the different command types to forward the information to another system. Normally this will be command type 2. Output Data Buffer Pointer numeric value (0-4) determines which position within the array (PFCSSolOutDataBuffer(x) ) to retrieve the data to be shipped to PFCS. Message Byte Length this is the number of bytes of data from the Output Data Buffer to send to PFCS. Input Data Buffer Pointer Set to 0. Not used for data send. Machine ID Pointer numeric value (0-9) passed to the subroutine to indicate which machine ID a data-block is being generated for. A 0 indicates the base machine ID, a positive number between 1 and 9 refers to the first to the ninth additional machine ID. Build Message Comm Type Set to a value of 0 for solicited communication channel. The driver logic copies the given information from the data buffer area specified and generates the message to the host system. Changes to this data buffer area after subroutine execution will not be sent to the host system until the subroutine is executed again. RUNG 4 Figure 12: Data Send Example - Main Routine Rung 4 Revision Date: 08/01/07 Page 20 of 25 Revision: 1.3
5.3 UNSOLICITED DATA RECEIVE This is build/vehicle information received from the host system. This data is sent when a vehicle is placed in an associated queue. The data is not requested; it is automatically forwarded by PFCS. When unsolicited data is received from the host, the data is placed in the tag PFCSUnSolInDataBuffer The SUPPLIER is responsible for maintaining a queue of the unsolicited data received, if it is required for the equipment. The SUPPLIER is also responsible for decoding the data received from PFCS. All header information is removed and the build/vehicle information is in the raw ASCII format received from PFCS. Since the data is sent from PFCS unsolicited, the incoming data must be polled for new data and handled appropriately. 5.4 DRIVER STATUS TAGS The program tags PFCSStatus and PFCSProgCtl contain status information on the operation of the driver: PFCSStatus.SolMsgInProg, PFCSStatus.UnsolMsgInProg - will indicate that a message has been sent, and is waiting a reply (for solicited and unsolicited ports respectively). PFCSProgCtl.MsgErrorDetect, PFCSProgCtl.UnsolMsgErrorDet will indicate the message instruction erred or that the command could not be built by subroutine because the parameters passed to the message build routine were invalid. PFCSProgCtl.MsgBuildRunning - There is a message already in progress. PFCSStatus.MsgRespTO, PFCSStatus.UnsolMsgRespTO - will indicate that a message response time-out has occurred. PFCS did not respond to the message sent. PFCSProgCtl.RespError, PFCSProgCtl.UnSolRespError - indicate that there was an error in the response from PFCS. Revision Date: 08/01/07 Page 21 of 25 Revision: 1.3
6.0 SOFTWARE SEQUENCE OF OPERATIONS 6.1 SOLICITED DATA REQUEST The SUPPLIER logic triggers the Driver logic to request data from PFCS The driver logic formats the header and command PFCSStatus.SolMsgInProg is set and the message is sent to PFCS A message time-out timer is started (configurable) If a data message is received, the header is verified. If the header is OK, then an ACK message is sent to PFCS and the data is copied to the buffer specified in the trigger parameters. If a NAK is received, a status bit is set, the NAK is interrogated, and the message is resent to PFCS. The message will be resent up to 3 times before it is scrapped. If the message times out, then a status bit will be set. The message is aborted and status bit is reset. This could occur if the message is lost, PFCS is not functioning, or PFS has no data to send. 6.2 UNSOLICITED DATA SEND The following is a detailed sequence of operations: The SUPPLIER logic triggers the Driver logic to send data to PFCS The driver logic formats the header and appends the SUPPLIER data using the parameters passed to the subroutine PFCSStatus.UnSolMsgInProg is set and the message is sent to PFCS A message time-out timer is started (configurable) If an ACK is received, then the sequence number is incremented and status bit is reset to allow the SUPPLIER logic to trigger another message If a NAK is received, a status bit is set, the NAK is interrogated, and the message is resent to PFCS. The message will be resent up to 3 times before it is scrapped. If the message times out, then a status bit will be set and the message will be resent. This could occur if the message is lost or PFCS is not functioning. The message will be resent up to 3 times before being scrapped. Revision Date: 08/01/07 Page 22 of 25 Revision: 1.3
6.3 UNSOLICITED DATA RECEIVE Note: The unsolicited data buffer specified is PFCSUnsolInDataBuffer (0). If a data message is received, the header is verified. If the header is OK, then an ACK message is sent to PFCS and the data is copied to the unsolicited data buffer specified in the configuration parameters. If the header information is not OK, a NAK message with the appropriate error code is formatted and sent to PFCS The SUPPLIER must monitor the data table to determine if new data has been received Revision Date: 08/01/07 Page 23 of 25 Revision: 1.3
APPENDIX A: SUPPORTING DOCUMENTATION The user should have a good understanding of the following documents and shall ensure that the latest revision of each document is used. Table 1: Supporting Documentation Doc. No. AMS 0220 Section 11.1.1 Title Chrysler PFCS Vendor Specification (BOIG) APPENDIX B: GLOSSARY & CONDITIONS TERMS & CONVENTIONS Table 2: Terms and Conventions BOIG CLx Chrysler ID JSR ms N/A SUPPLIER PFCS PFS PLC WCC Book of Implementation Guidelines ControlLogix Chrysler - North American Operations Identification Jump-to-Subroutine Millisecond Not Applicable Original Equipment Manufacturer Plant Floor Communication System Performance Feedback System Programmable Logic Controller Work Cell Controller USE OF SHALL, MAY AND SHOULD The word shall is understood as a requirement. The word should is understood as a recommendation or preference. The word may is understood to specify a specification that is condition dependent. The designer or vendor may be required to justify a deviation from the standard, and may be required by an authorized Chrysler representative to make alterations so as to conform. Revision Date: 08/01/07 Page 24 of 25 Revision: 1.3
REVISION HISTORY Date Revision Number Name Description 8/01/07 1.3 J. E. Dupuie Changed document to reflect company name change. 8/01/05 1.2 N. Bayan J. E. Dupuie Doc No. in Appendix. A; Note 2 p.15; Clarification at the beginning of Chapters 2 and 3. Added Table of Tables and Table of Figures. 1/05/04 1.11 J. Tyson No content was changed. The document remained the same amount of pages. Updated footers to reflect new Revisions, Dates and Filenames. Page 5 - Moved the text box UDTs (z_pfcs) and added an arrow and parentheses to help identify what data tags to use. Repeated same procedure for Page 6 the Controller Scoped Tags text box. Page 10, 12 and 14 I enclosed the note in a text box with an arrow and pointed the arrow to the Path Box in the software screen picture. 10/1/03 1.0 M. Kaunelis Section 11.3.1 Initial Release Revision Date: 08/01/07 Page 25 of 25 Revision: 1.3