I have just installed several vibration/temperature sensors at the factory of one of my customers.It is the V2 model with FFT analysis and time domain. The sensors have all been reseted once installed on the machines to perform calibration.
The sensors were configured as accelerometers (mg). As we need to set up threshold alarms according to ISO10816, I use the following conversion equation to convert the values to velocity (mm/s) :
Here is an example in Node-Red of the values obtained by one of the sensors (in mg). The Z axis is the significant axis in this case:
If the conversion formula is applied to this value, a velocity value of 47 mm/s is obtained, which is impossible according to the ISO standard.
To be sure that the conversion equation is not the cause of the error, I also read the values of one of the sensors with the Labview utility application. I got similar results, if I convert from in/s to mm/s
Last point, I use a 900HP-S3B Long Range Wireless Mesh Modem with USB Interface gateway to transmit the data to the data processing computer. In Node-Red, I use ncd-gateway-node to acquire the data from the sensors.
Can you help me find out what’s causing the problem. I’ve been running tests for two days now with no results.
I thought the V2 MEMS sensor could send velocity values. In fact, that’s how our test sensor was configured in the Labview application. See the following screenshot on this subject.
Anyway, whether the values are mg or in/s, the following screenshots clearly indicate that the values are over evaluated.
With macine stopped
With machine running
Regarding the calibration technique, we tried to press the reset button with the machine off the first time and with the machine on a second time. This had no impact on the values.
Another question. We have set the sensor to send the time series data each time so that we can do FFT with our Node-Red application. Does this have a significant impact on battery life? If so, is there a way with Node-Red to receive the time series data only when requested? We have tried in Node-Red to open a read COM port to receive the RMS vibration data and another COM port to send the command for the time series data. This causes serial access errors.
You will also notice that when using the time series data mode, we receive several times a similar message containing the time series data but with a different firmware number and a differents sensor_type number. Why is this?
The Velocity data is something we plan to support in future. Its still under development.
Yes, the time domain data can be requested on demand. The continuous time domain data request will impact the battery life.
In the last picture as you can see its getting 196 bytes of the data. so that indicates the time domain data is being received by UI. You might not see much on the graph is the machine is ruining smoothly and thee is not much wrong going on. The peaks will be really small and the scale goes from -16g to +16g.
In the node red you are seeing some kind of gibberish stuff because it does not support FFT. You might look into integrating some third part node red FFT library. There are few out these which are design for vibration analysis.
@jacob wrote python script to analyze the time domain data as well.
On demand works like this
enable on demand in cfg mode
as soon as PC gets the data send the on demand data command
Sensor will get the command and will send 12 data packets containing time domain data.
let say you see an abnormality in RMS, Max and Min data. Then you can send a command to request the time domain data. This command needs to be sent within 1 sec of data reception.
To enable on demand time domain data send this command in configuration mode
7E 00 14 10 00 00 00 00 00 00 00 FF FF FF FE 00 00 F4 08 00 00 28 04 CC
command – F4 08 00 00 28 04
F4 – command header
08 – sub command
00 – Node id
00,28 – sensor type
04 – enable on command time domain data
Once the gateway receives the data it needs to send a command to request time domain data
7E 00 13 10 01 00 00 00 00 00 00 FF FF FF FE 00 00 F8 99 00 00 28 3A
Command – F8 99 00 00 28
F8 – Command Header
99 – Sub command
00 – node id
00,28 – Sensors type
Once the sensor gets this command it will send RMS, Max,Min, vibration data plus the time domain data.
In your first response to the post, you seemed to think we used a bad calibration technique.
Maybe we did. So, could you please give me the recommended calibration (startup) procedure for these MEMS V2 sensors ? We will be able to test this method quickly and quickly move on to another investigation step if it doesn’t work.
Our customer wants the system up and running as soon as possible. He is therefore very collaborative in the problem solving process.
Now you should see default values in node red ( share here if you can)
tun on the machine
You should be getting the machine vibration readings
The default readings should look something like this
RMS X/g: 0.01655 RMS Y/g: 0.02513 RMS Z/g: 0.02805 MAX X/g: 0.08921 MAX Y/g: 0.1189 MAX Z/g: 0.096 MIN X/g: -0.1171 MIN Y/g: -0.08855 MIN Z/g: -0.05971
I did a factory reset with a test sensor at our shop. It worked. The data matches the values obtained with a manual vibration tester.
At the moment the situation is that 6 out of 6 vibration sensors seem to need a factory reset since their values are erroneous after a standard start-up.
Since this situation means that we have to return to our customer’s plant (4 hours drive there and back) and stop their production line a second time, I would appreciate it very much if this situation does not happen again.
So, do you have any idea what could have caused this? Is there any particular operation that has to be done on the sensors before delivery apart from the standard setup? Do you think it is safer to perform a factory reset every time?
Once again thank you Bhaskar for helping me to solve the situation. Once again, your support is impeccable
Unfortunately, it does not seem to be working. Neither the factory reset nor the calibration procedure gives a good result. We always get much higher values than normal. We even compared the results with a professional SKF vibration meter to validate our results.
This is starting to be annoying because our client, who is responsible for the maintenance of 6 production plants in Canada and Europe, is starting to have doubts about the project. The project we are doing is a pilot project to validate the suitability of using this technology in possibly all the plants of the group. So I’m sure you understand that it is essential that we find the source of the problem.
Here, in bulk, is additional information that could perhaps guide us in the search for a solution.
The sensor is type 40 (MEMS V2)
The USB gateway used is model U900HP-S3BMSR_ZIGMO.
Only the 5 sensors we ordered in April 2020 for the pilot project have the problem. The test sensor we ordered in January 2020 worked the first time (could this be due to a firmware revision?).
Here is the code we use to transform the raw data received from the serial port. “datas” is the array of values read by a node-red serial in module. :
We tested the node-red ncd-red-wireless module version 1.5.14. With this module also the values are over evaluated
Here is the configuration of the sensors having the problem (the 5 sensors of the pilot project have the same configuration). The Labview application is unable to read the delay but it is 900 seconds.
In my opinion, the values when the machine is stopped seem normal as shown in the following two screenshots. The first screenshot shows all the values of the 5 sensors installed at the factory. The second screenshot gives the details of one sensor in particular.
Unfortunately the machine doesn’t run on weekends, so I can’t give you the running values until tomorrow. But from memory, we measured almost 1g on the reference sensor on the machine. This sensor is installed on a fan running at 6050 RPM. If we use the following conversion formula to convert acceleration into velocity :
, whith A in mm/s/s, V in mm/s, f in Hz and g = 9810 mm/s/s, we get the following:
= 15.6 mm/s
This value is about 15 times higher than the value obtained from the SKF instrument (1.1 mm/s).
We’re pretty sure our equations are correct, but if you see anything wrong with them, feel free to point it out to us.
The RMS g value can not be used to convert into Velocity.
v = u + at
Velocity is a function of time and acceleration.
I will recommend setting your meter to “g” value as well and compare the readings.