MXPA99008705A - Input/output subsystem for a control system - Google Patents

Abstract

A field bus network of input and output devices is coupled to a control system through an I/O interface module, regardless of their data structures. The I/O interface module is coupled to the control system through a serial communication port. Local input and output devices are coupled to the interface I/O module through a local I/O interface and networked input and output devices are coupled to the interface I/O module through a field bus communication adapter. A different adapter is required for each type of field bus protocol. The interface I/O module includes a microprocessor based device to generate and control the various interactions between the local devices, networked devices, and the control system and also to provide for a visual and status display of the fieldbus and local I/O data local. Input and output data to and from control system.

Description

SUB-SYSTEM OF ENTRY / EXIT FOR A CONTROL SYSTEM Technical Field The invention of the Applicant generally relates to the field of microprocessor-based welding controllers, and more particularly to an interface module for coupling a network of input and output devices through a bus communication network. Field connector to the welding controllers. BACKGROUND ART The communication networks that couple input and output devices have been increasingly applied to many different control systems. Welding controllers are no exception. There are a variety of different field link bar communications protocols, including Interbus-S, Ethernet and Profibus. These input devices and output devices allow controllers to receive and process local input / output functions such as isolation contact device control, auxiliary contact device feedback control, bypass trigger, and control stop. These protocols are usually dedicated to a given welding controller or to a network of welding controllers having the same type of control.

With a production line that has different types of controllers and operator interface units coupled to different networks, it becomes difficult to determine which unit is being controlled by which type of network. Each welding controller will require a different network interface unit for each different input / output protocol, due to a mix of dissimilar data structures in the different networks. It would be preferable to have a network interface unit for the welding controller system that allows the interchangeability of the field connector bar protocols, regardless of the functionality of the welding controller, using a common field connector bar for the interface of the network module and the network module interface to the welding controller, one that is generally adaptable to resistance welders that use a variety of control strategies regardless of the types of data handled by each welder. SUMMARY OF THE INVENTION Accordingly, the main objective of the present invention is to provide a network interface for a variety of field linker devices and control protocols using any known control strategy. A further object of the invention is to provide a welding controller system having a self-contained input / output module, having local inputs and outputs independent of the inputs and outputs of the bar field connector. Still a further object of the invention is to provide a welding controller system having a self-contained input / output module with interchangeable field link bar communications adapters. Still another object of the invention is to provide a welding controller system having user-selectable bit exchange between data of the field connector bar, local input / output data, and input / output data of the welding controller. In the preferred embodiment of the invention, the invention comprises a system of elements that include, but are not limited to, at least one welding controller that acts as a slave device, and at least one master device, such as a control unit. operator interface, data acquisition device, or a network input via device, coupled to a common communications network. Each welding controller has a timer module for generating trip signals to a power module that subsequently supplies welding power to the contact tips of the welding gun. The timer module includes a CPU for executing a welding program stored in a memory resident in the timer. The operator interface unit is also coupled to the network through a communications port. The communication between the devices connected to the network is deterministic, with a device acting as a master and the other devices as slaves at any moment in time. Each device has a hierarchy assigned to when and if it can control the network and act as the master. When you have control, you can route another device to either send data or receive data. The physical layer of the network uses a simple connector bus topology, with active nodes to connect the different devices at any point between the two ends of the network. Input and output data to and from the welding controller pass through a welding control input / output module. The welding control input / output module is coupled to the welding control module via a serial communications port. Local input and output devices are coupled to the welding control input / output module through a local input / output interface and network devices are coupled to a field connector bus communications adapter. A different adapter is required for each type of field connector bar protocol. The welding control input / output module includes a microprocessor-based device to generate and control the various interactions between the local devices, network devices, and the welding controller, and also to provide a visual and status representation of the field connector bar and the input data / local output. Other features and advantages of the invention, which are believed to be novel and not obvious, will be apparent from the following description, taken in conjunction with the accompanying drawings, in which a preferred embodiment of the invention is shown. Reference will be made to the claims to interpret the full scope of the invention, which is not necessarily represented by such embodiment. Brief Description of the Drawings Figure 1 is a panoramic block diagram showing a typical welding controller system. Figure 2 is a detailed block diagram showing a typical welding and a typical welding controller system that can implement an operator interface and communications system according to the present diagram. Figure 3 is a simplified block diagram of a series of welding controllers coupled to a communication network in accordance with the present invention. Figure 4 is a block diagram of a master panel, data capture closeup according to the present invention. Figure 5 is a block diagram of an operator interface master panel that functions as a database master device according to the present invention.

Figure 6 is a simplified flow chart detailing an overview of the communication control of the master database device according to the present invention. Figure 7 is a detailed flow chart detailing the communications task of the database master device according to the present invention. Figure 8 is a detailed flow diagram detailing the communication response of the slave device according to the present invention. Figure 9 is a detailed block diagram illustrating the interconnections to a welding control input / output module according to the present invention. Figure 10 is a flow diagram detailing the interaction between local and network input / output and the welding controller according to the present invention. Detailed Description Although this invention is susceptible to embodiments of many different types, a preferred embodiment will be described and illustrated in detail herein. The present disclosure exemplifies the principles of the invention and should not be construed as limiting the broader aspects of the invention to the particular embodiment described. Figure 1 illustrates a typical welding system 10 consisting of a welding timer 11, a module of welder energy 13, and a welder 15. The welding timer 11 generates firing signals F + and F- used to energize or activate an SCR switch 16, which is coupled to the welding transformer 17 to supply power to the contact tips and the piece of work that is being welded. The primary current of the welding transformer 17 is monitored using a toroidal current transformer 18 coupled to its primary circuit. A reference transformer 19 monitors incoming line input voltage. In addition to the voltage V and current I signals, the welding timer 11 receives an over-temperature signal from the SCR switch 16 for use in control algorithms within the welding timer 11 as a protection feature to control or turn off the welder 10 if the SCR switch reaches a predetermined temperature. Specific implementation details of a welder system 10 can be found in U.S. Patent 4,945,201, although such details are not necessarily required for a correct understanding of the present invention. Referring to Figure 2, a block diagram details a welding machine 15 and a welding timer 11 adaptable to include a network interface system according to the present invention. The welding timer 11 can be part of a larger system controlled by a programmable logic controller (PLC) 20 or it can be auto- content. A backplane interface 22 provides means for coupling the PLC 20 to the microprocessor (CPU) 23 to a data link bar 25. The CPU 23 is also coupled via the data link bar 25 to the analog / digital converter (A / D) 27, the input / output (I / O) interface 29, the memory 33 comprising both a RAM 34 and a ROM 35, the trigger circuit 39, and light emitting diode (LED) indicators 43 that provide information of state of the welding timer 11. Also coupled to the data link bar 25 are two communication ports 31 and 42. The data entry interface port 31 is used to couple an operator interface unit 47 having a keyboard to the welding timer to manually capture data for control. The network interface port 42 provides the connection to the communications network 50 of the present invention. The interface units 31 and 42 can be activated to communicate individually or simultaneously. The control and timing signals required for the operation of the CPU 23 are not shown, as they are well known to those skilled in the art and are not an object of the present invention. A program stored in the ROM 35 provides control of the power module 13 and the welder 15 and the welding process by operation of the CPU 23. This program will generate SCR firing signals F + and F- through the circuit of. to control the welding sequence in response to various input signals. A two-channel A / D converter 27 converts analog signals I and V of the welder's power module into digitalized signals 45 representing the primary welding current Iw of the welding transformer 17 and the power line input voltage 46, respectively. The digitized signals 45 are placed on the connector bar 25 for storage in RAM 34 and for use as feedback control signals in the execution of a welding control program or schedule 51 resident in ROM 35. The A / D converter 27 also generates a pre-trigger signal 52 for input to the trigger circuit 39. An enable signal is also generated by the control program 51 to prevent erroneous triggering due to a possible "hanging" of the program, as two actions are required , pre-trigger and enable, before the trigger signals F +, F- are generated. The details relating to the trigger circuit 39 and the A / D converter 27 are well known and therefore will not be described further. The input / output interface 29 receives an input 54 of the welding power module 13 if the temperature of the SCR switches 16 reaches a predetermined fixed point, indicative of an over-temperature condition. The temperature is monitored each welding cycle and if it reaches the fixed point, the input 54 will cause the control program 51 to disable the welding current Iw and provide a message of error in the error handler 41, which is actually a portion of the welding control program 51 in the ROM 35. The control stop signal 56 is a signal generated within the welder 15 as a interlock control and will be activated if an operator or external device causes the interlock to open. Again, this signal 56 will cause the control program 51 to disable the welding current I and set an error message in the error handler 41. The external device is normally a button that is depressed to indicate an emergency condition that requires the immediate cancellation of the welding cycle. As a short SCR switch 16 would result in a direct current to the welder 15, a bypass trip circuit breaker is disposed in series within the welder 15 to remove power if a short SCR condition occurs. It is assumed that this condition exists if the current I is detected at a time when it has not been commanded by the welder control 11. The welder control 11 will generate a bypass trigger signal 58 to cause the circuit breaker to trip low. the condition of SCR in short. An additional output 60 controls a magnetic contact device for use within the welder 15 and is energized when a welding sequence is initiated. An electronic memo pad 44 which is accessible to the network 50 for retrieval by means of an interface of user for diagnostic purposes can be used to store user data. This provides a static memory that a user can use to capture data that may be relevant to that particular timer, such as installed date, number of operations on a particular date, and so on. An external memory pack 48 may be coupled to the data link bar 25. This memory pack may be used to provide a backup for the welding control program 51 and other pertinent data. This will allow a defective timer module to be replaced by a new one without having to re-program it. The control program 51 also includes means for a time clock of day 49. This can be a clock of both hardware and software. The value of the clock is used to chronologically mark data captured by the timer. These data may include operating conditions at each point of the welding program, such as number of welds, conduction angle, current and welding voltage, and so on. Faults and invalid commands received by the timer that do not satisfy the criteria that define the validity of the commands can also be stored with the time stamp. These data can therefore be identified and referred in relation to the time of their occurrence. To prevent memory overload, the data can be kept in the memory of the error handler 41 as a sliding window.

The data can be maintained for a fixed period of time or for a fixed number of operations, for example. A data log file 53 in a non-volatile memory provides an operating file for also storing faults in a fault log 55, invalid commands in a command log 56 and certain conditions in a panic log 59. The log of Panic is used to store events that violate certain fixed rules concerning the operation of the welding controller. The occurrence is stored in a non-volatile memory. A status bit in a message field will be set to indicate that a panic occurrence occurred. The file 53 is always available to the communications network 50. The day time clock can also be used to provide an automatic backup based on the data time to a memory packet and to the electronic memo pad 44 for recovery and storage in a database of the system located in the user interface. In an embodiment of the present invention, the network configuration consists of a communications network 50 having a series of different timer modules 62-64 coupled thereto as shown in Figure 3. Each timer module operates in a manner similar to the timer module 11 of Figure 2 and can have dedicated data capture panels (DEP) 67-68 to capture data, welding programs, and other operating information on it. The DEP 69 provides means for coupling the timers 64-65 to a separate communications network through the secondary 70 of the DEP. Separated DEPs 71 and 72 can be directly coupled to the network 50. A PC-based data capture panel 74 acts as the master interface unit and is used to represent, monitor and edit individual timer modules 62-66. A second PC-based DEP 76 can be present, as can an entry channel 78 that provides a connection to other communication networks. The minimum network connection is a single master device and a single slave unit. A timer module 62-66 is always a slave unit. The other devices in the network are considered master devices, each operating in one of several modes of operation, database master 74, primary master 67, or secondary master 76. A network arbiter is the master device that currently controls the traffic flow through the network. There can be only one network arbitrator at any given time in the network. The PC-based DEP 74, in one mode, acts as the master database device. This has the highest priority and is the only master device that can automatically download data to a slave unit. This device will always try to take control of the network referee. A primary device will attempt to take control of the network arbitrator in the absence of the database device. A secondary teacher will hear the granting of access from current network arbitrator before starting a message packet on the network. If there is no database master or primary master in the network, the secondary device will have the highest priority, as defined during the installation, the role of the network arbiter assumes the role as a pseudo-primary device. It will remain in that role until a database or primary master rejoins the network. A primary device, one of the various operator interfaces 76, DEPs 71-72, or gateway device 78, may be degraded to a pseudo-secondary device if a database device attempts to rejoin the network. A pseudo-secondary device is then a primary device that has ceded arbitration of the network after the database device or other primary device has taken control of the network as an arbitrator. This type of device will assume secondary master functionality unless it connects to the network and does not listen to other network traffic. If no traffic is detected, it will be promoted to primary. In this mode, it will be the net arbiter until a higher arbitration priority device takes over and will be known as a pseudo-primary device as long as it is acting as the network arbiter. It will return to secondary device status if another device of higher arbitration priority takes control of the network. A teacher is considered to be attached if the network referee has granted this teacher the use of the network. Is considered connected a device if the device is physically connected to the network and listening to network traffic. The welding timers 62-66 acting as slaves will operate normally even if no master device is present. They can be programmed and monitored by their individual DEPs 67-70 of network 50. They can transmit data through network 50 only in response to request messages received from the network, and can not initiate any message. A basic block diagram of the essential components of a data capture panel 80 is shown in Figure 4. A CPU 82 has access to the memory 83, which consists of an EPROM 84 and a RAM 85. The EPROM 84 contains the operating program of the device, including communication protocols and data management. A keyboard 86 is used to capture data and can be a full size keyboard, a matrix keyboard, or a pointer (mouse). Screen 87 is used to display data from a selected timer or can be used to display various menus for use in conjunction with a pointer to capture data. There are typically two communication ports 88, 90, each consisting of a UART 91, 93 and a controller 92, 94. Port 88 is used to connect a printer or other data collection device. Port 90 is used to connect network 50, using a RS-485 semi-duplex connection. Other specifications may be used, and this invention is not restricted to the type of connection used. The data capture panel can be used to connect directly to the network 50, thereby functioning as a master device 72, or it can be dedicated to a particular timer for individual monitoring and control of that device only, either as primary master or database master. The PC-based data capture panel 74 has basic components similar to the DEP 80, as shown in Figure 5. As is the database master, its processor 100 controls the database of the system 102 and makes it accessible to the network 50 through its network interface 104. A user 106 can access data from a welder controller through its timer module 11, based on its individual data structures and types, by means of objects attached to the timer within an interface identified as a T interface method 110, which is part of the application program 108. The data can then be monitored by the screen 112 through various graphical methods that are well known and are not an object of the present invention. Object-oriented programming techniques are incorporated into the application program 108. This allows the use of timer object models, inherited from a base class object in the T 110 interface acting as a parent, to provide an interface of layer of data between the data screen layer and the physical devices in the network 50. The physical devices in the network are modeled as objects, with their characteristics and their behaviors codified in data fields and methods. This method, also known as encapsulation, combines a record with procedures and functions that use it to form the object. Once the object is defined in the T 110 interface, it is used to build a hierarchy of descendant objects, the descendant objects inheriting access to all the data and methods of their ancestors. The system is also polymorphic in that a name is used for a particular action throughout a hierarchy of objects, each object in the hierarchy implementing the action in a manner appropriate only to itself. This allows additional and different types of timers to be accessed by the user 106 from the DEP 74, regardless of the data type of the additional timers. The specific data of the welding timer are private to the timer object model in the T 110 interface and are stored in a separate device file 114. This data can only be accessed by methods defined in the T 110 interface. The conversion of all the data received from the network 50 is performed in the device file 114. It contains all the information about the records and data structures and inherits its methods from the interface file T 110. This allows these methods to be maintained through all the device files 114 separated without having to modify each one by special conditions that could occur. Typical data in these files will consist of the most recent welding data, any occurrences of failures, and other pertinent data. As there may be multiple slave units and multiple master devices in a typical configuration of the network 50, there are means to identify the destination, either a timer or a master, and the origin (originator), master or slave, of a message packet . Two address fields, consisting of only one byte, are included in the message packet header that specifies the intended destination and the source network device number. This address information is stored in a configuration file 116 that is created during the installation. This file tells how to install memory images for each timer. In addition to the timer address, its data type is also listed in the configuration file. Although network 50 can be theoretically populated with any number of master and slave devices, the preferred number of slave device loads to maintain the RS-485 standard is 31, with up to 5 master devices. The middle of the network can be an armored twisted pair. The transmitting devices are considered as having tri-state outputs. Each transmitted character consists of a start bit, eight data bits, and a stop bit, which requires ten bit times for transmission. The parity check It is not part of the character. Message packages have two basic forms, either as a master request or as a slave response. Each message packet originated in a master consists of a minimum of three different fields: header, command and short. Additional fields are present only if the master is sending data to the timer via an installation-type command, as would be the case if the master were downloading a welding program, for example. They appear in the package as follows: The header field of all the packets originated in a master consists of the ASCII control sequence DLE-STX, followed by the network address of the slave / master of destination or transmission and then the address of the origin master. The destination address is defined as the physical address of the receiver and the source address is defined as the physical address of the device itself. The address fields are treated as transparent text and the DLE-STX is treated as a literal.

MASTER HEADER DLE STX Address of Destination Address of Origin Each master device has two physical addresses assigned to it. When the device tries to connect to the network, it can promote itself to a pseudo-primary state or it can degrade to a pseudo-secondary state if a higher-status device connects to the network. The set of commands is divided into several subsets, which contain related commands. Each command has two parts, the requestor's data packet and the response of the slave. The data packet of the requester may be in the form of installation data (write) or status data (read). The command field consists of four bytes. The first byte contains the message transaction code (device command code). The second byte of the four-byte command field may contain optional welding program code, as defined by the application device command layer. The third byte indicates the index of the program number or escalation number applicable to the command. The fourth byte is defined by the device command layer as a secondary program. If a field is not required for the given command, it is set to $ 00. The entire command field is presented in the form of transparent text.

COMMAND Command Index Program Code Secondary Program Welding The packet short is composed of the sequence of ASCII DLE-ETX control, followed by the block verification character (BCC). The length of the short field is three bytes and is treated as a literal. If the BCC equals a DLE value, no additional DLE is added.

SHORT DLE ETX Verification Character The block verification character byte is the complement two of the eight-bit sum (module 256) of all transparent text bytes, excluding inserted DLEs. In this way, the block check character covers the actual withheld data of the address fields, commands, text length and text. When the block control check sum byte is added to this sum (module 256), the result must be zero. Each packet of slave response messages consists of a minimum of four different fields: header, command, state and short. Additional fields are present only if there is data. They appear in the package as follows: The header field of all slave response packets consists of the ASCII control sequence DLE-SOH, followed by the network address of the master that originates the request and then the address of the responding slave. The Destination address is defined as the physical address of the receiver and the source address is defined as the physical address of the device. The address fields are treated as transparent text and DLE-SOH is treated as a literal.

DLE SOH Address of Destination Address of Origin The command and short fields are the same as the command and short fields sent by the master device. Within each slave response packet, there are two status fields, timer and error. The status fields are considered as transparent text. Timer status refers to the existence of certain timer elements, such as memory and co-processors, operating conditions, communications port connection, data transfers, panic conditions, discharge mode readings, and so on . The error status provides an indication of various operating conditions that can cause a timer to fail. These conditions have pre-programmed fault codes and include points such as voltage, current and temperature faults, invalid welding program data, and any other pertinent data peculiar to welding control systems.

The text length field indicates the total bytes which form the text field that follows, not including transparent DLE bytes. If no text is present, then the field is $ 0000. The field length is two bytes presented as an integer and is presented in the form of transparent text. The data requested by the specified command of the master are present in the text field. This field is also presented in the form of transparent text. Certain fields in a message packet (specifically the command fields, status, length of text and text, and address data in the header field, are presented in the form of transparent text.) As the link protocol uses DLE sequences as delimiters of message and field, it is necessary to distinguish between the start of a control sequence (DLE) and the appearance of a byte with DLE value in the command or text data streams.This distinction is provided by insertion DLE, which requires that any data with a DLE value be preceded by a DLE prefix.Thus, the DLE-DLE sequence is considered as a single byte of DLE value data when it occurs within such a data stream and only needs to include a DLE in the construction of the block control character field, any DLE only found in such a stream is interpreted as a link control prefix All data indicated to be of the tran type Sparent are included in the construction of the character field of patent block verification.

The transmitted messages can be sent to all the devices connected to the network 50. Only a master device can transmit messages. A master-originated package with a destination address of zero ($ 00) is interpreted as a message transmitted to all slave units, and a destination address originating from a $ 80 master is interpreted as a master-to-master transmission. No slave unit can originate a message transmitted on the network. The only message that should be sent as "transmitted" is the fault reset action queue. The timer will not test inappropriate transmitted messages, it simply will not respond and the teacher will not know if the request was acted correctly by all the timers. As part of the timing requirements of the network, there are certain conditions to maintain control. After a request for data, the responding device must complete the response within certain time-out values. This varies between 100 milliseconds for master-to-master requests and up to 2,000 milliseconds for slave response. The master can not initiate messages in any interval of less than 35 milliseconds to the network or to any individual timer. The three modes of operation of the master device have been described as database master 74, primary master 76, and secondary master 72. During the installation of the network of communications, a physical address is assigned to the master devices, which defines their type and priority within the network. The database master 74 is the only device that can automatically download data to a timer 62-66 based on a revision status. It has the highest priority as a network referee. The primary teacher 76 will act as the network arbitrator in the absence of a database master. A secondary teacher should listen to an access grant from the network's current arbitrator, before initiating a message packet in network 50. When there is no database or primary device in a network, the secondary device with the most High priority, as defined by its address during startup, assumes the role of network arbitrator as a pseudo-primary. As a pseudo-primary device, it can be "killed" and re-started as a secondary device, by a database or primary device by the time it rejoins the network. The communication between master devices consists of a set of commands, defined below, that control or arbitrate the network 50. A secondary granting message is issued only by the network arbitrator to allow the periodic joining of the physically directed secondary device. If the secondary device can not receive a grant within a predetermined time period and no other traffic is heard, a network re-start sequence will result that the master device with the highest arbitration priority tries to take control as the network's arbitrator. The periodic rate of grants is determined by the application layer for a given teacher. The master will always attempt to grant access to the network 50 to a given secondary device even if the secondary device does not respond to each grant. The secondary device that has the physical address contained in the last grant message will send a secondary response message. If a response is not heard by the network arbitrator, the network arbitrator will continue its normal operation, assuming that the secondary device is not present at present. After receiving a secondary response, the system referee will send a secondary proceed message immediately back to the secondary device. If you listen to this message after responding to a grant, you assume temporary control of the network. During this control time, you can send any number of messages to any number of slaves as long as you continue to maintain valid traffic on the network. However, you can not grant access to the network to any other device. After completing its network requirements, it releases control of network 50 back to the arbiter, sending a secondary release message to the network arbiter to allow it to take control of the network as soon as possible after the secondary device. Complete your network requirements. However, if this message is not received by the arbitrator and no valid traffic is heard by the arbitrator, after a period of time out, it will take back control of the network. A secondary kill message is sent with a message transmitted to all the devices connected to the network whenever a master device that believes to have the highest arbitration state is connected to the network. Before this message is sent, the newly connected device expects to receive a secondary grant from the current arbitrator master and then successfully join the network as a secondary device. Immediately after joining, you will send this message. After listening to the message, all other master devices will try to re-start as a secondary device or as a pseudo-secondary device. A secondary clock synchronization message is sent only by the network arbitrator in an attempt to synchronize all the real-time clocks of the secondary devices. It can be sent as a message transmitted to the timers to synchronize their individual clocks. The data flow diagram shown in Figure 6 provides an overview of the operation of the preferred embodiment of a database master 74 of the present invention. At the beginning 120, the database master will create configuration files 124 which identify which types of timers 11 (slaves) are present in network 50 and will allocate sufficient memory 122 as determined by a user. These files 124 tell how to install images in memory in device files for each slave device in the network. The database administrator will determine whether the boot mode is a normal boot operation 130, load 132 or load 134. If it is a download, it will read data 128 from the device file in the database file for control of device revision. Once the database master is in control of network 50 as arbitrator, it will wait for a user request 136 or after a predetermined time, whereby the database administrator will scan the network for status changes or changes in data, as determined by a regular review. The user request may be in the form of a keyboard entry or a pointer operation 86 in response to stimuli from a graphic menu on the screen 87. The database manager 74 will attempt to send the message through the message. of the communication task 140. Once a response 142 is received, the appropriate screens will be updated to 144 and the database administrator will determine at 146 whether the received data should be stored in 148 in the system database , or not . If it does not receive a response 150 from the addressed device within a predetermined period of time, the master will decide that the device is not present and carry out some type of error routine, as established by the user. The administrator of the base of data will then wait for the next request. You can also relinquish your status as a network arbitrator and let other primary and secondary teachers take over as arbitrator at this time, until another user request 136 is received. Figure 7 details the communications task 140 of the master device of database according to the present invention. Once a user request 136 has been received and decoded, the request will be identified at 152 as a loading or unloading command. The receiving device will also be identified at 154. Using this information, the master will construct the message pack 156 using the data structure contained in the device device file identified in the master database files. The data packet will be built through the T 110 interface file and will have the necessary header, address and short codes. If the user request is a download command 158, such as loading a new timer welding program, the master will obtain the data from the system database and insert the particular command code 162 to download the program to the timer. If the request is a load command 164, the particular command code for the requested data will be inserted into the message packet, as previously discussed. Once the message pack has been built, it will be sent in 168 to the addressed device by network 50. When sent, a response timer will start at 170 the timing. If a return message is not received within a pre-set time 172, the teacher will assume that the device is not present at 174 and will set a time flag out of response 176. The teacher will then go to some kind of routine as determined by the user's program. Once a response has been received at 180, the master will determine whether the received message is a load message 182 or download 184. A stop signal 186 will also stop the response timer 170 from operating at this time. For a load command, the requested data will be extracted in 188 from the packet and stored in the device file 190 of the responding device. If the response is from a download command, the status code in the data packet will be read at 194 to determine if the data that was sent by master 168 was received and accepted at 196 by the addressed device. If the data was not accepted, an error routine 198 will be started. This routine can take various forms and depends on the application program. It can take the form of only re-sending the original message several times, for example, before determining that the device is not present in 174. If the data has been accepted in 196, the teacher will determine if the request has been completed in 200 If a welder program is being downloaded, it will take several commands 202 and run them through communications task 140 to complete downloading as many message packets will have to be sent before the request is completed. Once the request has been completed, the system database files will be updated to 142 with the current state of the addressed timer. The communication response of the slave device is detailed in the flow diagram of Figure 8 according to the present invention. The individual slave devices are continuously listening to the messages on the network 50 about their addresses. Once its address is detected at 210, the attached command will be decoded at 212 in the message packet, the command will be stored at 213 in the command register 59, and it will be determined whether the command received is a valid command 214 in itself. same. For a load command 216, the requested data will be extracted in 218 from the data files resident in the timer and inserted into the response message packet. The status code and command codes in the message packet will also be updated to 220. If the response is from a download command 222, the received data will be extracted in 224 and stored in 226 in the data files resident in the timer The status code in the data package will be updated in 220 to indicate that the data sent by the teacher was received and accepted. If the received command is not valid at 214, the command will be stored at 228 in the command register 57 as an invalid command, the status field of the message pack will be updated to 230 to indicate that an invalid command has been received. Once the data has been extracted or added, and the status codes have also been updated, the device will construct the response message packet 232 and send the packet back to the origin 234. Figure 9 provides a detailed block diagram illustrating the interconnections to a welding control input / output module 300 according to the present invention. The description of the data flow for the welding timer input / output module is as follows: 1. The input data is loaded asynchronously in the serial ATII to parallel converter from the communication adapter, after having been received in the field connector bar. Using an internal time base, the local microprocessor reads these entries and the local input registers to its memory. Based on the configuration switches, the processor logic combines the ATII inputs and the local inputs to produce a common data structure that is loaded into the parallel to serial converters of the timer input / output interface. The welding timer changes its data to its memory. the. The processor can act in an ATII or local input state by setting the status of either or both of the external outputs or local outputs. 2. The output data is loaded asynchronously in the parallel to serial converter of the welding timer input / output interface via the welding timer. Using an internal time base, the registers of the serial to parallel converter are read by the processor to its memory. The processor, based on the configuration switches, can modify the data before loading it to the ATII converter from parallel to serial to be read by the communications adapter and sent through the field connector bar, using the connector bar protocol of desired field. 2a. The processor can modify the state of the local outputs based on the configuration switches and the status of the data received from the welding timer and the state of the local inputs. 3. The processor displays the status of the data presented to ATII as outputs and the status of the data as it is received from the ATII entries. Indicators are also provided for local input / output states. 4. The configuration switches allow the user to specify a field connector bar data format different from the weld timer input / output data format. Figure 10 is a flow diagram detailing the interactions between local and network input / output and the network welding controller, according to the present invention. The methods detailed above are applicable to many different types of applications within and without welder control systems. The welding control input / output module provides a field path device between the field connector and input devices and countless other control systems. Although specific embodiments have been illustrated and described, numerous modifications are possible without departing from the scope or spirit of the invention. Although the system is described for use with a welder controller, the system may be adaptable for use with any type of communication control system having devices with different data structures that communicate and pass data between themselves.

Claims (1)

1. A control input / output module for interfacing a field connector bar network of input and output devices with a control system, the control input / output module comprising: A. an adapter field connector bus communications, to couple the field connector bar network of input and output devices with the control input / output module; B. a local input / output connector for coupling a plurality of local input and output devices to the control input / output module; C. a serial controller interface for coupling the control input / output module to the control system; D. an input / output processor for controlling interactions between the local input and output devices, the field connector bus input and output devices, and the control system; E. wherein said field connector bus communications adapter allows interchangeability of field connector bus protocols for the network of input and output devices regardless of the functionality of the control system, using a common field connector bar protocol between the control input / output module and the control system.