Vibration/Temperature sensor V2 - Get too high values

[bertrand.gauvreau]

Hello,

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.

Thanks

Bert

[Bhaskar]

Hi Bert,
This sensor does not support Velocity.
can you share the values you get

1. when the machine is off and sensor is installed
2. values when machine is on

I believe during the install the machine was off and after installing the sensor you power reset the sensor.

Thanks

[bertrand.gauvreau]

Hello Bhaskar,

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?

Thanks for your help

Bert

[bertrand.gauvreau]

Hi,

This time, here are the data read by the LabView application.

Even if the sensor is in read mode (the graphs of RMS values show it, and also the improbable 6300 mg value on the Z axis) and the “Request Time-Series Data for Analysis” checkbox is checked …

And the “On Command” option has been selected in the “TIME SERIES DATA” menu…

We are not receiving the FFT analysis data (the machine is running)

Thanks for your support

Bert

[Bhaskar]

Hi Bert,
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

1. enable on demand in cfg mode
2. as soon as PC gets the data send the on demand data command
3. 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.

[bertrand.gauvreau]

Hi Bhaskar,

Thank you for the details about the time series data management. we will work to integrate it this way.

Now, back to the main subjet about this post, do you have any clue about the weird RMS data sent by the 6 MEMS V2 vibration sensors ? Do you have any idea of what’s wrong ?

Thanks

Bert

[bertrand.gauvreau]

Hello Bhaskar,

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.

Bert

[Bhaskar]

Hi Bert,
For calibration do this

1. Turn off the machine
2. install the sensor
3. press reset on the sensor
4. wait for 60 sec
5. Now you should see default values in node red ( share here if you can)
6. tun on the machine
7. 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

Thanks

[bertrand.gauvreau]

@Bhaskar

• Turn off the machine
• install the sensor
• press reset on the sensor
• wait for 60 sec
• Now you should see default values in node red ( share here if you can)
• tun on the machine

Hi Bhaskar,

We’re going to try that this morning. I’ll be right back with the results.

Thank you for your support

Bert

[bertrand.gauvreau]

Hello Bhaskar,

We completed the calibration test on one of my client’s sensors. We used the procedure you provided. Unfortunately, it does not appear to have corrected the situation.

Before the calibration

After the calibration

What other possible cause do you see?

Bert

[Bhaskar]

Hi Bert,
I will recommend doing a factory reset at this point.

Thanks

[bertrand.gauvreau]

Hello Bhaskar,

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

Have a great day

Bert

[Bhaskar]

Hi Bert,
The issue could occur is the velocity data was set. This feature is not supported and it changes the internal settings in so many ways.

Factory reset is not required if sensor is used with acceleration and time domain mode.

Thanks

[bertrand.gauvreau]

Thank you Bhaskar. We’ll take care of that next time.

Have a nice day.

Bert

[bertrand.gauvreau]

Hello Bhaskar,

Thank you for this information.

We did some tests to determine how to apply this algorithm with Node-Red. Unfortunately, we encountered the following difficulty:

1. We used the Node-Red Wireless Gateway node to receive the vibration data pushed by the sensor. This node works well.
2. We added a Node_red Serial Out node to send the command for Time Series data to the sensor.

It doesn’t work. We get the following error message. This message seems to say that it is impossible to connect two Node-Red nodes to the same COM port (the port of the gateway).

How do you think we could make it work with Node-Red

Thanks for your support

Bert

[Bhaskar]

Hi Bert,
the error is coming because the COM9 is already open.

I dont know much about node red. @jacob is the guy who developed it and he might be able to suggest something.

Thanks

[bertrand.gauvreau]

Hello Bhaskar,

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.

1. The sensor is type 40 (MEMS V2)
2. The USB gateway used is model U900HP-S3BMSR_ZIGMO.
3. 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?).
4. 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. :

5. We tested the node-red ncd-red-wireless module version 1.5.14. With this module also the values are over evaluated

6. 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.

7. The firmware version is 4 for all 6 sensors

If you have any questions that might help you better understand the problem, I am available to answer them at any time.

Thank you for your valuable support

Bert

[Bhaskar]

Hi Bert,
There has been no change in firmware.

can you share a screen shot of labview with sensor readings ?
does these read high values even when the machine if off ?

Does all 6 sensors have same configuration ?

Thanks

[bertrand.gauvreau]

Hi Bhaskar,

1. 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.

2. Yes, all 6 sensors have the same configuration.

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.

Thank you for your support

Bert

[Bhaskar]

Bert,
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.

Thanks