# Modbus UINT16 to decimal?

**URL:** <https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498>\
**Category:** General\
**Tags:** modbus\
**Created:** [11 August 2023 13:20 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498 "2023-08-11T13:20:02Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Darren](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/darren/32/92202_2.png) [@Darren](https://discourse.nodered.org/u/Darren)\
**Post date:** [11 August 2023 13:20 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/1 "2023-08-11T13:20:03Z")

</div>

Hello, I've got a rotation sensor that is returning values via Modbus through a Mitsubishi PLC, and the PLC programming software is calculating and displaying decimal values for a rate in the range 0.2m3/hr to 3 decimal places and stored as FLOAT [Single Precision]. However, when the numbers get to node-red, they're completely different. I'm putting them through **buffer parser** and have to set that to UINT16 to get the same numbers output.

I'm sure there must be some sort of formula I have to put them through, but I'm not sure what I'm dealing with... unsigned 16-bit integers that are off by orders of magnitude and seem to switch between very specific numbers?

Here's an example of what I'm getting in node-red, along with equivalent (?) numbers that appear in GXWorks 3 PLC programming software. The numbers seem to switch between these very specific values.

```auto
64367
63073
57743
49504 = 0.241
46955
41496 = 0.165
36895
32901
32108 = 0.229
28867 = 0.157
18032
15187 = 0.143
13265 = 0.129
455 = 0.149
4700, 7247 = 0.228

```

Has anyone seen weird numbers like this from Modbus and know what sort of formulae are required? [This thread](https://discourse.nodered.org/t/need-some-help-with-float-numbers/48292) is relevant; the problem is superficially similar to [my previous thread about getting garbage from Modbus in node-red](https://discourse.nodered.org/t/modbus-tcp-previews-correct-output-but-receiving-end-gets-garbage/78322/), but is probably a different problem.

At least I'm getting numbers (albeit wrong ones) rather than nothing from the buffer parser node.

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [11 August 2023 17:59 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/2 "2023-08-11T17:59:44Z")

</div>

Your problem could be a number of things.

Typically though, what happens with PLC values is you or reading across the bounds of two different values or the data is byteswapped (little vs big endian).

The easiest way to solve this is to read from a unused area in the PLC. Enter known values directly into the PLC and check the buffer parser outputs what your expect.

More often than not, you need to byte swap or in the case of non IEE 754 compliant data, extract the exponent and whole parts manually.

Lastly, in mitsubishi PLC, the default for values is signed data. So any 16 bit number that goes above 32767 suddenly becomes a negative value, but when read as an unsigned integer, it does not.

If you can capture real data coming from the modbus node (use the debug copy value button) and provide the exact expected value, I'll show you how to use the buffer parser

Seeing the value in the PLC will also help me.

---

<div class="post-metadata">

**Author:** ![Billy\_C](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/billy_c/32/74647_2.png) [@Billy\_C](https://discourse.nodered.org/u/Billy_C)\
**Post date:** [12 August 2023 04:04 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/3 "2023-08-12T04:04:53Z")

</div>

Following this 👍

---

<div class="post-metadata">

**Author:** ![Darren](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/darren/32/92202_2.png) [@Darren](https://discourse.nodered.org/u/Darren)\
**Post date:** [16 August 2023 10:43 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/4 "2023-08-16T10:43:52Z")

</div>

Thank you for your help!

Slightly frustratingly, I've tested reading several other known-value registers from the PLC, and e.g. `60` is broadcast for temperature, and `60` is received, no conversion/buffer parser needed.

Updated values read:

```auto
gfuel_flow_rate, left = node-red, right = GXW3

64367
63073
60645 = 0.240
57743
49504 = 0.241
46955
29258 = 0.166
41496 = 0.165
36895
32901
32108 = 0.229
28867 = 0.157
18032
15187 = 0.143
13265 = 0.129
708, 9444 = 0.232
455 = 0.149
4700, 7247 = 0.228
5287 = 0.166

```

---

<div class="post-metadata">

**Author:** ![Darren](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/darren/32/92202_2.png) [@Darren](https://discourse.nodered.org/u/Darren)\
**Post date:** [16 August 2023 10:54 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/5 "2023-08-16T10:54:18Z")

</div>

Trimmed to useful values, sequential by real number:

### gfuel\_flow\_rate

m3/hr

| node-red (displayed value before buffer parser, unknown format) | GXWorks3 output (expected value, FLOAT [Single Precision]) |
| --- | --- |
| 49504 | 0.241 |
| 60645 | 0.240 |
| 32108 | 0.229 |
| 4700, 7247 | 0.228 |
| 708, 9444 | 0.232 |
| 5287, 29258 | 0.166 |
| 41496 | 0.165 |
| 28867 | 0.157 |
| 455 | 0.149 |
| 15187 | 0.143 |
| 13265 | 0.129 |

Exact expected values are those seen in GXW3. Modbus node output is sequential as it is fed with a large data structure of available devices, and is just a single-number array. It looks like the `0.` might be throwing node-red off.

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [16 August 2023 11:07 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/6 "2023-08-16T11:07:53Z")

</div>

Sorry, it is unclear what you are saying.

Is there a problem or not?

PS, tables are supported in markdown, making it much easier to read

e.g...

```plaintext
GXWorks | Node-red | Expected Value / Type | Info
------- | -------- | --------------------- | ----
49504 | 49504 | 0.241 | buffer parser type set to UINT16 & scale of `/1000` - working ok
60645 | 60645 | 0.240 | buffer parser type set to UINT16 & scale of `/1000` - working ok

```

becomes

| GXWorks | Node-red | Expected Value / Type | Info |
| --- | --- | --- | --- |
| 49504 | 49504 | 0.241 | buffer parser type set to UINT16 & scale of `/1000` - working ok |
| 60645 | 60645 | 0.240 | buffer parser type set to UINT16 & scale of `/1000` - working ok |

---

<div class="post-metadata">

**Author:** ![Darren](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/darren/32/92202_2.png) [@Darren](https://discourse.nodered.org/u/Darren)\
**Post date:** [16 August 2023 11:54 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/7 "2023-08-16T11:54:10Z")

</div>

I have reformatted the data. Issue is node-red seems to be reading single precision floats as garbage (albeit consistent sequential garbage), whereas all other modbus output numbers are read as exported from the PLC without any problems or buffer parsing. I was just wondering if there was a known number format that node-red used in such situations or whether the existing numbers looked like a known particular format that I could apply a transformation formula to? I can't see any pattern.

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [16 August 2023 12:04 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/8 "2023-08-16T12:04:25Z")

</div>

As explained before, the reason they will be garbage will be because of how you address the values.

> [@Steve-Mcl](#):
>
> Typically though, what happens with PLC values is you or reading across the bounds of two different values or the data is byteswapped (little vs big endian).

So if you can provide the right info I can show you how to do this properly.

- I will need a capture of data coming out of the modbus node (use `Copy Value` button)
- I will need you to tell me what the value(s) are supposed to be.

So something like

| Value in PLC | PLC Data Type | Value seen in Modbus | Expected value after parsing |
| --- | --- | --- | --- |
| 65000 | UINT16 | 65000 | 6.5 |
| 1234567.89 | Float | [46143,18838] | 1234567.89 |

* * *

### How to copy value

![chrome_MD52DtN5Eo](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/9/5/95ffd53afa1d2263109bc86f31e0df37db73c05d.gif)

---

<div class="post-metadata">

**Author:** ![Darren](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/darren/32/92202_2.png) [@Darren](https://discourse.nodered.org/u/Darren)\
**Post date:** [16 August 2023 12:29 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/9 "2023-08-16T12:29:23Z")

</div>

That makes sense; apologies for misunderstanding. I will post it here:

### gfuel\_flow\_rate

Double numbers given for some numbers as I have observed both to appear in node-red while the PLC monitoring software GXW3 reports only one value. The numbers are definitely not random/read from the wrong place, as they consistently appear at the same time. I'm not sure if that's all the info required; a colleague who was also helping was saying that the hex values would probably be useful, but the software doesn't have an easy way of monitoring them so I would have to convert the numbers back to hex and hope I didn't mess it up if needed

| Value in PLC (read from GXW3, m3/hr) | PLC Data Type | Value seen in Modbus | Expected value |
| --- | --- | --- | --- |
| 0.241 | Float [Single Precision] | 49504 | 0.241 |
| 0.240 | Float [Single Precision] | 60645, 16420 | 0.240 |
| 0.229 | Float [Single Precision] | 32108 | 0.229 |
| 0.228 | Float [Single Precision] | 4700, 7247 | 0.228 |
| 0.232 | Float [Single Precision] | 708, 9444 | 0.232 |
| 0.166 | Float [Single Precision] | 5287, 29258 | 0.166 |
| 0.165 | Float [Single Precision] | 41496 | 0.165 |
| 0.158 | Float [Single Precision] | 35228 | 0.158 |
| 0.157 | Float [Single Precision] | 28867 | 0.157 |
| 0.149 | Float [Single Precision] | 455 | 0.149 |
| 0.143 | Float [Single Precision] | 15187 | 0.143 |
| 0.129 | Float [Single Precision] | 13265 | 0.129 |

## Screenshots

 ![GXW3_23_08_16_134821](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/f/f/ffb49f058096893f7534e9182d2a7abf64fff446.png)  
 ![GXW3_23_08_16_145749](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/f/6/f6bb44b2e53429df94afb30be32fbf6b65684f2b.png)  
 ![GXW3_23_08_16_145839](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/7/4/7490e2958504daaa7e8adfb3c5815c341c4fbe50.png)  
 ![msedge_23_08_16_150149](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/e/a/ea8f505a59971093db76b0e95411dace060f2736.png)

---

<div class="post-metadata">

**Author:** ![Darren](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/darren/32/92202_2.png) [@Darren](https://discourse.nodered.org/u/Darren)\
**Post date:** [16 August 2023 14:03 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/10 "2023-08-16T14:03:44Z")

</div>

I found this thread: [Modbus 16 bit registers to Float value](https://discourse.nodered.org/t/modbus-16-bit-registers-to-float-value/72784) that sounds quite like my issue, but haven't had much luck copying the measures from that thread.

I'm currently experimenting with reading the hex buffer from the Modbus node.

---

<div class="post-metadata">

**Author:** ![Darren](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/darren/32/92202_2.png) [@Darren](https://discourse.nodered.org/u/Darren)\
**Post date:** [17 August 2023 11:51 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/11 "2023-08-17T11:51:24Z")

</div>

This thread is also similar to my issue: [How to Decode 16 Bit signed Integer](https://discourse.nodered.org/t/how-to-decode-16-bit-signed-integer/8112)

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [17 August 2023 12:29 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/12 "2023-08-17T12:29:25Z")

</div>

If you dont provide REAL SAMPLE data I cannot assist you.

> [@Steve-Mcl](#):
>
> I will need a capture of data coming out of the modbus node (use `Copy Value` button)

> [@Steve-Mcl](#):
>
> ### How to copy value
> 
> ![chrome_MD52DtN5Eo](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/9/5/95ffd53afa1d2263109bc86f31e0df37db73c05d.gif)

---

<div class="post-metadata">

**Author:** ![Darren](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/darren/32/92202_2.png) [@Darren](https://discourse.nodered.org/u/Darren)\
**Post date:** [17 August 2023 13:30 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/13 "2023-08-17T13:30:58Z")

</div>

I must apologise if I have misunderstood, the sample data is real, directly from running systems. Not simulated.

### Do you mean like this?

[screen recording GIF on Imgur](https://imgur.com/a/nshQBaC)  
Or are you asking for the HEX output of the Modbus buffer?

### What I have done so far is this:

[screen recording GIF on Imgur](https://imgur.com/a/82SqJLx)

(Imgur seems to have flagged engineering software as 18+ NSFW, not sure why)

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [17 August 2023 15:00 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/14 "2023-08-17T15:00:51Z")

</div>

In order to develop a solution for you, I need actual data captured using the copy value button and for it to be posted into a reply as text (JSON) ( **not** a screenshot).

The reason for this is I will simulate your device (something I do not have access to) by taking the ACTUAL data that you post and injecting it into a demo flow.

---

<div class="post-metadata">

**Author:** ![Darren](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/darren/32/92202_2.png) [@Darren](https://discourse.nodered.org/u/Darren)\
**Post date:** [17 August 2023 15:31 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/15 "2023-08-17T15:31:04Z")

</div>

The screenshots were not data, only illustrative of my data acquisition process(es), as I'm not sure if we're talking about getting it from the same place.  
My Modbus-flex-getter node is outputting numbers like I previously posted (though if I remember rightly the previous data went through buffer parser set to UINT16), just with square brackets around them. I'm not sure how I can make the data any more real than that. As it is multiplexing across many different devices, I have to use a switch to select individual data streams, all of which are configured the same and all of which, bar one, work perfectly. e.g. like the following, from the malfunctioning `gfuel_flow_rate` data stream:

```auto
[41496]
[65061]
[41496]

```

The buffer output from the Modbus-flex-getter is different, but I'm not sure if that is what you're asking for, hence the screen recordings 😢

```auto
{"data":[41496],"buffer":[162,24]}
{"data":[65061],"buffer":[254,37]}
{"data":[65061],"buffer":[254,37]}

```

### Screen recording

NB. data not copied directly from Modbus node debug because there are 6 simultaneous data streams and I can't pause the node-red debug log or move fast enough to copy the relevant part...  
 ![Screenshot_23-08-17-162648](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/f/1/f1442c4ad0e2c5a831d0189bbb48fcac9ee31299.gif)

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [17 August 2023 16:14 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/16 "2023-08-17T16:14:57Z")

</div>

> [@Darren](#):
>
> data not copied directly from Modbus node debug because there are 6 simultaneous data streams and I can't pause the node-red debug log or move fast enough to copy the relevant part..

Well slow it down then, and/or run it on just one stream initially.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [17 August 2023 16:27 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/17 "2023-08-17T16:27:41Z")

</div>

Or send it through a Delay node set to Rate Limit to 1 every 20 seconds, with Drop Intermediate messages, then feed that into the debug node.

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [17 August 2023 18:51 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/18 "2023-08-17T18:51:12Z")

</div>

@Darren, no need for the apologies. And don't worry, this will all fall into place very soon (you are getting close - and you will learn lots in the process - so its all good)

> [@Darren](#):
>
> The buffer output from the Modbus-flex-getter is different, but I'm not sure if that is what you're asking for, hence the screen recordings 😢
> 
> ```auto
> {"data":[41496],"buffer":[162,24]}
> {"data":[65061],"buffer":[254,37]}
> 
> ```

This ☝ is what I need - **BUT** - what are they supposed to be parsed to? Are these the first 2 from your list?

> | Value in PLC (read from GXW3, m3/hr) | PLC Data Type | Value seen in Modbus | Expected value |
> | --- | --- | --- | --- |
> | 0.241 | Float [Single Precision] | 49504 | 0.241 |
> | 0.240 | Float [Single Precision] | 60645, 16420 | 0.240 |

  

* * *

One more thing: Single precision floats are typically 32bit values. Can you confirm if the PLC occupies uses 2 16 bit WORDS to hold the float values?

If they are 32 Bit, you need to request a length of 2 in the ModBus data.  
In case you are not aware, ModBus always delivers 16 bit data. Thats why floats can be a pain. It doesnt help when the PLC or interface swaps bytes and doesnt adhere to IEE floats.  
That isnt really a worry but it is important to know what size the data is in the PLC.

If you dont know, identify the function in the PLC writing to the address & I will tell you.

* * *
  

Back to the data for parsing:

Let me try to make this clearer 🤞 .

#### I need:

1. The ACTUAL ModBus payload _(you did this when you copied the full payload value - great!)_
2. At the EXACT SAME TIME - I need the ACTUAL equivalent matching value from the PLC - so that I have both the source (ModBus) data AND a target value to achieve - so I can check my work and ensure you get accurate data.

Does that make sense?

---

<div class="post-metadata">

**Author:** ![Darren](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/darren/32/92202_2.png) [@Darren](https://discourse.nodered.org/u/Darren)\
**Post date:** [18 August 2023 08:49 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/19 "2023-08-18T08:49:23Z")

</div>

Understood now! Thank you! I will enter the data here:

| Expected value | Modbus |
| --- | --- |
| 0.165 | {"data":[41496],"buffer":[162,24]} |
| 0.229 | {"data":[32108],"buffer":[125,108]} |
| 0.201 | {"data":[56615],"buffer":[221,39]} |
| 0.235 | {"data":[11439],"buffer":[44,175]} |
| 0.228 | {"data":[52312],"buffer":[204,88]} |
| 0.164 | {"data":[65061],"buffer":[254,37]} |
| 0.228 | {"data":[7247],"buffer":[28,79]} |
| 0.165 | {"data":[65061],"buffer":[254,37]} |
| 0.164 | {"data":[60204],"buffer":[235,44]} |

That is the data from the monitoring software with the concurrent Modbus reading. Strangely, for the same expected value, there are multiple (but consistent) Modbus readings.

* * *

I must admit, it skipped my mind to remove the other data streams; however, I believe the switch implemented serves much the same purpose to separate them out. I didn't think to use a delay note to rate limit things. I think I've got it working now, though. Thank you for the advice

A colleague did mention Modbus output only 16bit, wheras I have read on StackOverflow that JS only uses 32bit by default. I'm looking through the PLC documentation, though in the "Data Type Selection" there are `Double Word [Unsigned]/Bit String [32-bit]`, `Word [Unsigned]/Bit String [16-bit]`, `Word [Signed]`, `Double-Word [Signed]` as well as `FLOAT [Single Precision]`

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [18 August 2023 08:51 UTC](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498/20 "2023-08-18T08:51:57Z")

</div>

Before I do this, please clarify the size of data in PLC:

> [@Steve-Mcl](#):
>
> One more thing: Single precision floats are typically 32bit values. Can you confirm if the PLC occupies uses 2 16 bit WORDS to hold the float values?
> 
> If they are 32 Bit, you need to request a length of 2 in the ModBus data.  
> In case you are not aware, ModBus always delivers 16 bit data. Thats why floats can be a pain. It doesnt help when the PLC or interface swaps bytes and doesnt adhere to IEE floats.  
> That isnt really a worry but it is important to know what size the data is in the PLC.
> 
> If you dont know, identify the function in the PLC writing to the address & I will tell you.

Its just that you have provided 1 WD (2 byte) data for each "Expected value" and typically, single precision floats are 32bit (2 WDs / 4 bytes) and this will be key (critical) to getting this right.

[Next page](https://discourse.nodered.org/t/modbus-uint16-to-decimal/80498.md?page=2)