Communication with FAG SmartCheck device

About a one week ago, I put my hands on device I didn’t know. At first glance, it would be a problem to find out its function even from the picture.

After a brief exploration and a Google search, I found out that the FAG SmartCheck is a modern and an innovative device, developed by Schaeffler company, for continuous monitoring of machinery, for example motors, fluid pumps, ventilators, gearboxes, compressors and so on. The FAG SmartCheck device is able to find out approaching machine error by monitoring its vibrations and optionally rotational speed. This sensor is quite intelligent as it can be switched to “learning” mode. In this mode, the sensor maps device characteristics based on collected samples (by default 1000 values) from the monitored device. Based on these characteristics, the sensor will report alarm if the device behaviour starts to differ from the values collected during the “learning” mode.

It is also possible to connect several analog and digital inputs and outputs to the device – for example, it is possible to measure device rotational speed, or to get out information about alarm as an analog signal 4-20 mA (for example to read it by PLC).

What about communication facilities?

The producer offers SmartWeb as a web-based application with an intuitive user interface where it is possible to track “live” data collected by FAG SmartCheck device. Data are refreshed approximately every 5 seconds.

Furthermore, the producer has integrated support for Mitsubishi PLC (System Q and L series). FAG SmartCheck device implements client part of the SLMP protocol, so it is able to read/write values from/to configured PLC addresses. This method of communication would require the implementation of the server part of the SLMP protocol in D2000, which would be quite demanding (and probably would not be reusable). An alternative would be to purchase and install several Mitsubishi PLCs by the customer – which is again expensive and time consuming.

So how to get data to D2000?

Since we needed to get the data into the D2000, we had to retrieve it differently than using a web application. For this purpose, it was necessary to create a FAG SmartCheck communication protocol to communicate with the FAG SmartCheck device.. The communication is established by connecting to device IP address and is performed using XML Soap messages (Simple Object Access Protocol) based on sending http requests to the device and receiving http responses from the device. There are 2 types of Soap messages that are required for communication with the device:

The first type of message is used to log the user in to the device. Only the logged-in user can read the data collected by the FAG SmartCheck device. As a response to this message, the FAG SmartCheck device sends a response about the success of the user’s login.

The second type of message is used to “query” the data that the device collects in real time. This message also verifies that the user’s login and password are correct, so that someone else cannot read the data. The FAG SmartCheck device sends a Soap response to this message, from which the measured values can be read. In the end, the only thing left is to translate the answer into human speech (to parse XML Soap) and to display the obtained data to the end user.

Protocol implementation in D2000

Considering the nature of the protocol, we decided to implement communication in java as a multithreaded server event. One communication thread is reserved for communication with each device.

To start communication, the D2000 user must fill the configuration structure with the necessary data:

• Device IP address
• Username
• Password to log in to the device
• The period (in seconds) with which the data has to be refreshed

Lastly, the user activates communication by setting the value of the Active column to True.

But where are the measured data? They are stored in a separate structured variable. Why? It is assumed that in the future we will also need to read secondary data (alarm data) for some devices, for which we will need another structured variable. Therefore, we separated the configuration from the measured data so that we can flexibly expand both structures without “mixing” the columns.

The user can monitor the vibration, temperature, voltage, load and device rotational speed in the structure with measured data. The Status column indicates the status of the communication – whether the device is connected, disconnected, or it is not possible to communicate with it due to incorrect login data, or due to incorrect IP address.

What happens if the user increases the number of configuration structure rows and then adds a new device? We also thought about this – after adding a new device into the configuration structure, the number of rows in structure with measured data is automatically resized to as many rows as the configuration structure contains.

Conclusion

Communication with the FAG SmartCheck device is functional and fault-tolerant. At the present time, the FAG SmartCheck devices are waiting to be installed at the customer’s site so that we are waiting to deploy the communication to several dozen devices.

One advantage of communication implementation in Java event was not mentioned – it is not necessary to upgrade D2000 to the latest version (as it would be in case of protocol implemented within KOM process). So the communication event can be deployed on any supported version of D2000.

Due to me being a student and beginner in programming, it was the first time I encountered this kind of project (on which I worked all alone). It was quite demanding to understand connection of D2000 to the Java programming language. I would like to thank to my colleagues Marek for helping to establish http communication in Java, Thomas for the idea of multithreading communication and to Peter who always helped me and pointed me in the right direction.