Wireless Machine Monitoring System

Introduction The Wireless machine monitoring system provides an efficient, friendly, machine independent and cost effective way to collect data from many type of industrial machinery or equipment without the hassle that comes from running wires to each one of them. Data is recorded on each Node by a self-activated embedded system running software with simple sub-routines accessible to the technician via few parameters. The first system developed was capable of collecting data for a few days before running out of memory, but with the help of a new and much powerful micro-controller now it is able to collect data for several weeks. In reality there is no need for such accumulation since each Node is call by a master controller every 2 to 15 minutes, depends on the network traffic, and all the accumulated data is transfer to the Master control that then transfer all collected data into a PC. After the Node finishes the communication session with the Master, all register are reset with the exception of an ongoing “machine under cycle” event, which accumulate on a sub register that is not be

affected by the reset call. Accumulation then starts all over again on all other registers. At the moment we obtain different types of data that include: (Time in seconds):

1- Cycle time = time it takes to completely machine a part or a full process. 2- Idle time = the amount of time the machine is not under a cycle with no alarm condition present. 3- Alarm Time = the amount of time the machine has been under an alarm condition. 4- Machine Status = the actual status in which the machine is at the time of transmission session. 5-Temperature = up to two temperature probe can be connected to the module or one temperature sensor and one pressure transducer.

Possibilities of expansion are real. Since the Nodes or modules are fully programmable, new functions are possible including extension to the machine functions. With just this five data types mentioned above, the PC software can trigger events as wanted, and logs special events to a log file. This might help in understanding the capacity of each machine or in other cases find why the equipment is not performing like it is supposed to. Some of actual decision making capabilities those are available currently in the system:

• Alarms are saved into a log file array which in turn entered to an Access database table on a record that corresponds to the machine under supervision.

• Excessive idle time is, part count per hour and other parameters are also the log to the files. Each log entry is a time-stamp of the event occurred; and the user will be able to determine the amount of time the machine was under a particular status.

• The log file is nothing more than a column on the database table with a memo type format. The reports are yet to be automated that will allow the user to create new events to be logged dynamically, or select the ones which are of interest.

Software Overview:

The software is made out of many different function and subroutines. Some of the features like event-loggers and dynamic updates are already discussed above. The system is managed using five different types of software. Some of the software suffered significant changes especially in the End/Device or Slave module. We have numbered these changes but since this is totally different module than the first one we name the version as follow:

• The Slave or End/Device module which runs the Slave Wireless Monitoring System as Version 1.0.

• The Master which runs the Master Wireless Monitoring System as Version 1.0

• The version of the PC software went through 3 version changes. The PC also runs an .ASP 2.0 (ASP DOT NET) applications that provide the means for users on the intranet to view the Database tables under a friendly web site.

• User can view the data but can’t make changes to the database, since the tables are connected through a virtual XML copy of the original database in which we had made updates as impossible.

• When a user requests to enter the web site, the server runs the script and sends the user a compiled version of the page. This prevent user from viewing the source code (For data security purposes). It also eliminates the need of installing software in each user machine since the results are view in any web browser like Internet Explorer. The last and the fifth software is used to configure and load parameters into the End/Device module, eliminating the need of going into the source code to make changes. The module is configured by the selection of few parameters. More on this under the slave configuration process section.

The PC software running in Amtec Elgin Plant #2 is capable to detecting the machines under an alarm status and sends a text message to the responsible personnel in a hierarchal way, based on the alarm rules set on database. The persons to be contacted, the amount of time the machine is allowed under an alarm status and the interval between the hierarchies (people hierarchy) are dynamically obtained from this Microsoft Access table. Rules for directing the phone calls are established by the authorized persons. We just equipped the software with the means to make these a dynamic function. Shift change summary reports had also been tested and they works. A separated table is used by the software to get the email address of each person that is authorized to get this report.

The XBEEPROO

The Master controller has unique software that allows the module to act as a Master on a PAN system. The wireless system use the XBEEPRO sub-module which is a ZigBee/IEEE 802.15.4 (http://www.maxstream.net/wireless/zigbee.php) compliant operating on a Non/Beacon mode under a specific PAN (Personal Area Network) RF protocol. Mesh routing is needed depending on the amount of machines connected to the system, 14 machines and 6 routers for the master module and each router can again have the same amount. This configuration allows the master to connect to modules that in other situation will be out of range. The 60 mill watt of transmission power allows this module to reach other modules directly by up to 100 meters away inside a warehouse type building and over 1000 meter open field. The routing feature makes possible the creation of a mesh topology network, extending the communication range to greater distances. All the modules are FCC approved in the United States, and the technology has worldwide acceptances. Data is transfer wirelessly at a rate up to 250 kbps in a 2.4 GHz carrier frequency. Each communication session travels in preformatted packets carrying the address ID of the End/Device Node, the source module ID address, join with any user data up to 100 bytes per packet.

At the power up condition, the X-BEE runs it’s built on a Boot loader. The Basic Micro handshakes with the XBEE loading the needed parameters that in turn configure the X-BEE Node as a Coordinator that resides on the Master module. Any error on the configuration process causes a recall to the function until the XBEE agrees to accept the parameters. Once the agreement is Ok by the XBEE the Master sends an op-code to the PC requesting the address of the Nodes the Master would be talking (communicating) to. The PC does not inform the user about this process since it repeats every communication Cycle, but if an error occurred inside this function the PC results in an error message displayed on the Message Box area. This informs the user of communication problems and any other abnormally. Complete disconnection between the PC and the Master is sensed and displayed with a windows message box. I wish to bring the software to the point where it will display the Error, possible cause and the remedy.

The Basic Micro Atom Pro 28

Communication betweens the PC and the Master is done via an RS232 connection with a 57600 Baud rate, non inverted, 8 bit, and 1 stop bit protocol using a DB9 to DB9 Serial communication cable. Operating voltages for the module ranges from 6 to 24 volts DC. Two built-in voltage regulators provide the Basic Micro with the +5 volts TTL level necessary for Micro Controller and the IO operations. A secondary voltage regulator provides around +3.125 volts CMOS level for the XBEEPROO module. The Atom Pro 28 module executes around 100,000 instructions per second and used a Basic type language to program it. It has 8 analogs to Digital 10 bit resolution inputs that can be used also as simple digital inputs/output, plus 12 more 0 to +5 volts TTL logical level IO for a total of 20. A built-in EPROM allows the programmer to save data to the non-volatile registers and have this data ready for use in the event of power failure. Analog data capture is possible at a rate of 6,000 samples per second. Even this is a 16 bit micro-controller is possible to allocate variables up to a 32 bit resolution. The controller also supports floating-point math. Each pin can be use to produce PWM signals, serial communication routines and a regular TTL voltage of +5 volts digital level output. Pin 14 and 15 provide

access to a build in UART with a one byte long buffer size. The UART is shared with the chip the TX and RX lines used to load the programs and talk to the PC. We use most of this feature on this chip with the exception of the PWM.

Master Module Overview:

The Master save any incoming data from a Node and it can either send a request for more or drop the session. Each communication session results are reported to the PC thought the serial port in an RS232 protocol. After the Node session is terminated the Master move on and open a new session with another Node.

With the array of Nodes address ID’s in the Basic Micro RAM the Basic Micro start to call the Nodes in the order received from the PC. The Master tries to engage a conversation with the End/Device if the End/Device “respond timeout” parameter is overcome then the Master retries to establish the connection and keeps on trying until the “Number of Retries” parameter is overcome. If the “Number of Retries finish” event is trigger

the Master informs the PC with a Node address ID unreachable message. The PC saves the event into the “Fail to connect” array with a Node ID index. If the “Fail to Connect Count (NodeID)” array is overcome the Node is flagged, the PC do not requests a connection to this module until the “Time to try the Flagged Node” parameter is overcome by the “Accumulation for Flagged Nodes” array with a Node ID Index. If it fail to connect at the first time, after the PC granted the permission by “ try to reach the Node again” event, the Node remains flag until the next permission is obtain and the process continues forever unless the Node is permanent flag on the PC by the use of the Node select check box. Taking “not reachable Nodes” out of the communication cycle speeds the system. The retrying to communicate routine with a dead Node can cost several second on each communication cycle. If there are more than one Node down, maybe the machine is down and has been locked/tagged out, or any other reason, this seconds can add up to several minutes. The Master pings the Node with a “AA” up code and then sits and wait for a response from the Node until the “respond timeout” parameter is overcome like we talked above, but if the Node is reach the Master is granted with a packet from the Node having a double copy of the accumulated values of the register on the End/Devices. The double copy of the accumulated values is then passed to the PC. The PC splits the two copies and compares them for data integrity analysis purpose. If the copies do not match then an event is recorded to the log file and the “Data Corrupted “array index flag is set to a true condition. The “Data Corrupted counter” array is incremented also. If a “Data Corrupted” = true is present, future data corrupted events are not log to the file but the “Data Corrupted Counter” array continue to increment, the “Data Corrupted” flag remains in the true condition. If new data packet from the Node comes with exact copies and the “Data corrupted” flag for the node is true then the “Data corrupted Counter (NodeID)” accumulated value is send to the log file, the “Data Corrupted Counter (NodeID)” is reset to zero. This helps on troubleshooting communication problems, which might require a channel change or the need of new router installation to boost the signal, ensure data integrity and prevent data lost. A Data corrupted session will be analyzed by the PC anyway and the algorithm try to recover any possible data from the packet, this prevent completely data lose and at least provide the user with an approximation of the Node registers values. This is not the ideal situation, since we don’t want uncompleted reports from the machines, we are looking instead for reliable data, but since the system still

on the developing process I’m arming the software with any possible tool that can be used on future analysis and debugging process. Is hard to fix a problem if the problem can be see, and to me the best way to find it is to go back and look at the data to determine what went wrong. So far the system has been put under test very few times and turns out to be correct. Few of the data discrepancies were found to be overlaid on the operator side and not the Node computing calculations, but there is definitely a room for improvements. After the Node Address ID array index has been incremented enough to overcome the “NodesCount” parameter, the Basic Micro calls a sleep Routine that last for a period of time result of to the amount of Nodes minus “Minimum Cycle Delay” parameter with a normal value around 90 seconds. The Purpose of this delay is mostly used on Networks with a small amount of Nodes. The time each Node invests in sending packets to the Master affects the ability of the Slave to provide exact values accumulated on the registers. Having the Slave spending most of the time on communication routines deprives the main task of monitoring the IO to execute. The application does not require a constant data stream from each Node and on the contrary we want the End/Devices to take care of accumulating the data most of the time. We need to inform the reader that this is not real multitasking system. Multitasking is done virtually because of the hardware limitation, so we need to use the micro-controller execution time mostly on calculating rather than talking. When the Master comes back from the sleep period it sends a “Starting” op-code message to the PC. The PC catches this message and triggers a “start loading sequence” event. When the event is latch it calls a data loader subroutine. The Master also jumps to a loading subroutine sequence. After a handshake, the PC starts loading the Nodes addresses together with any extra information wanted to pass into the Master. Each Node ID address is passed to the Master and the Master responds with a Data Acknowledge. The amount of Node ID Addresses to load into the Master is specified by the first data value coming from the PC, after that the Master makes sure the amount of data addresses received match this value. If something goes wrong on this process the function watchdog catch this event and forces a request to start over again call. The process continues until data integrity is acknowledged by the Master. This loading process is essential to ensure that changes to the network topology are pass dynamically which can be cause by the addition of new Nodes or the

subtraction of Nodes no longer in use. Once the Master have the Nodes addresses saved on the “AddressID” array it goes and start requesting the attention of each Node again. Each communication session between the two modules takes around 1 to 2 seconds. The Master module and the Slave module are electrically identical. Most of the electronics components are not use by the Master and they are intended for the Slave operation. See the installation section for more information. Slave Module Overview:

The XBEEPROO and Basic Micro Atom Pro 28 section applied in the most to the slave module, with a difference that the Slave module runs the Slave software. I explain the Slave configuration software together with the Slave module explanation since it is a very small application.

Slave Configuration Process: When the Slave module power up it goes into a 5 seconds waiting period which is used to allow the module to accept a connection to a PC running the configuration software. If the Slave is running when the PC connects via the RS232 port with a Baud Rate of 9600 kbps, non-inverted, 8 bit, 1 stop bit protocol, the event cause a hardware interrupt into the micro-controller. The 5 seconds delay now provide more than enough time for the micro-controller to handshake with the PC and start loading the parameters. Every parameter been loaded by the PC is granted with the acknowledge feedback from the

module. If for any reason this process is interrupted a communication error is display on the PC message window. The module responds with a parameter loading error as well. The algorithm does not provide ways to recover from this error and will not attempt to figure out where is the problem even though some of the problems can come from the PC, so the user have to locate the problem and try to load the parameters again. There are only few reason for this situation to happen which can be: no power going into the Slave module, the RS232 serial cable is not connected properly, wrong cable (a null modem cable maybe), wrong PC port configuration, port on the PC in use by another application, Slave module might be running the Master software, bad module board. Each module board has an onboard green LED that provides a visual confirmation of the power status going to the module. If power is present, we know we are using the right cable, and the cable is connected properly, and then try to used any communication terminal or the one provided by slave configuration software. A common terminal that comes with windows is the hyper terminal. Open the communication port on the PC and then cycle the power to the module. The module should feedback the booting process which include software version on the module and XBEE module. Having this data on the display helps to determine if the right software is installed on the module. If communication is not possible try to reboot the PC, or try a different port if available. Each Parameter is acknowledged by the modules is saved to the on board EPROM. Saving this setting to EPROM as you might know, allow the module to load the right setting after a power failure occurrence. After loading the settings to the RAM the module used the values on the RAM entries to configure the XBEEPRO and set the module into a Slave operating condition. There are very few parameters to be loaded since I don’t see the need to provide access to the user with all of them and most the parameters are defaulted to constants values at this moment. The slave configuration software is equipped with a communication terminal that allows the used to see incoming data from the Slave and also send commands to the module. This is a useful tool in my case for debugging purpose. To used this terminal just click on the “Capture Now” button. If the “trigger a reset when connecting” is check, which is check by default, clicking the “Capture Now” button causes a hardware interrupt to the module and the module goes into the boot up process. If the “Trigger a

Reset When Connecting” check box is un-check when button is click, then no reset is performed but the terminal is ready to receive and send data. The communication protocol is set by the two entries on the main form. An example of the entry format is display when the tool tip appears over the text box. The communication ports available on the PC are automatically acquired by the program and ready for selection through the pull down combo box. Access to the parameter is obtained by clicking on the “Show Parameters” button. Every time the program is close the current settings are save into a file. The next time the program opens it will look for this file and load these values into the corresponding entry. Parameters Explanation:

Actual parameters inside the module can be view by clicking the “Retrieve” command button. This will cause a reset to the modules and after the PC and Basic Micro handshake, the PC puts an up code requesting the actual parameters values. The parameters are automatically display in the corresponding data entries.

To set new parameters, set all the values as desire and then click the “Send” command button. A reset to the modules is forces and after the hand shake the parameters are load as explained on the above paragraphs. The following are the list of few parameters. Parameters Form

A-Module ID Number: Set a unique address number from the module. Range from 1 to 1000. B-Mode: There are only 8 modes available, 3 of which the user don’t

need we use them for debugging purpose. The other 5 are in use in Plant #2 in Elgin. There is enough programs space to add more. Every time a mode is selected the picture on the form displays the proper IO connection. The parameter sets which program will run during normal operation. The differences on this programs is on the way the module looks at the IO and make an analysis of machine process. The registers will be fill with the results of this analysis.

Modes available: 1-Program Error Only use for debugging the abstract involve make it impossible for me to explain this parameter in this publication. 2-Semi-Auto Mode: Set the running program to monitor a semi automatic operated machines. Two inputs are needed; “Alarm” and “Cycle is running” conditions. 3-Automatic Mode: Set the running program to monitor an Automatic operated Machine. Three inputs are needed; “Alarm”, “Cycle is running” and “Cycle Start” conditions. 4-Counter Mode: Set the program to monitor the equipment where the cycle time and any other data is not need by the exception of the part out put count. One input is needed; “Count” condition. 5-Air Compressor Mode: Set the program to monitor an air compressor type of equipment. Since Cycle time does not apply to this machine, I wrote a separate routine, which spend most of the type calculating Temperature and Pressure reading. Four inputs are needed; “Alarm”, “Running”, “Temperature probe” and “Air pressure transducer” conditions. 6-Virtual Switch: Set the program to monitor a machine with a very difficult to monitor IO. I encounter this situation on some of the Chiron we have in Plant #2 where there is no interfaces possible with the machine status. I used instead an M code from the machine and in the case of the Chiron the pallet change event to calculate the data. With only one M code free on these machines it was very hard to come with a reliable interfaces. So far it has shown to be very close to the real behavior of the machine. The machine does not have the light tower option so I’m want to have the Module generate this signal for the machine, using the two option M codes provided by the module.

7-IO test Mode: Set the program to monitor each Digital Input on the board and send the status through the UART port to the PC. This mode is used only for troubleshooting the module IO. 8-Analog Input test Mode: Set the program to monitor the two analog inputs on the module and send the values through the UART port to the PC. This mode is used for troubleshooting the module analog to digital inputs.

C- De-bounce Time: Sets the minimum cycle time expected before the

part count is accepted as an ongoing true cycle. This prevents the part count register from incrementing when the machine is under a setup issue or the tool replacement processes.

D- Timing Factor: Sets the multiplier value on the PC and the divided

value on the Basic Micro from with the calculation will measure a one second period. The actual programs on the Slave module takes around 110 milliseconds to executed, this will require a division by 9 to provide a one second count.

E- PAN ID: Sets the PAN ID number. The Slaves and Master needs to

agree on the PAN ID number in order to communicate. If the PAN ID is different on a Node then that Node will not be able to be reach or not be able to reach others. Since the ZigBee standard has world wide acceptances the possibilities of a near by building running a similar protocol are possible. Forcing the modules to talk on a specific PAN number will provide the technician with a way to avoid other networks interferences.

F- Communication Channel: Sets the communication channel where

the Nodes and Master will be exchanging there conversations. This is another way to avoid

interferences from other networks since the Nodes need to be on the same channel in order to engage on a conversation. Another used is to find the channel with the most effective decibels of reception and transmission power.

G- A1 or A2 Register: This will be rarely used by the technician I put

just for debugging purpose. Leave it at 0 please. How the programs on the Slave module collect the data? I will explain the Semi-Auto mode and Automatic mode sub-routines. The virtual switch mode is one of the more abstract one. One I which to try is give the Slave module the ability to request machine programs from the server and have them ready to be downloaded into the machine. Semi-Auto mode: There are two registers to handle cycle time timings, one register for alarm status, one for idle status timings and one for part-count purpose. The semi-auto mode sequences looks at input number two for an alarm status if no alarm is present then it looks at input number one for a cycle running condition. If no cycle is running then the program declares the machine status as idling. Every condition starts the corresponding timer register increment. If a cycle is running then like said before the cycle time first register will start accumulating. If the signal is dropped before a minimum cycle time parameter is bigger than the accumulated cycle time the accumulated time is reset to zero, no part is count. If the signal is dropped and the accumulated time is more than the minimum cycle time the register one is copied onto the register two, register one is set to zero, and a part count is saved on the parts counter register. If the master module engages a conversation with the slave module under an ongoing cycle running period the cycle running time register one is not affected, but the register two is transferred and the other register are also transferred to the master module, this register transferred are reset to zero. Before handling the values to the

master module the values are divided by the proper timing factor. The actual status of the IO is also sent with the packet. There are algorithms in between these sequences to filter incoming noise on the IO, and prevent false trigger of the status events.