Steve-Mcl
commented
2 years ago Hi,
Often when issues like this arise, it is due to the implementation by the device manufacturer and how they decide to arrange values in the 16 bit registers.
Under the hood, Buffer-Parser uses the well defined nodejs Buffer and calls its well tested functions based on your choices so I am confident it is doing the right thing. Whether that means it will compute the correct output for an IEEE float as defined by your device is another matter.
However, I wont close this issue until I have double checked the code.
In the meantime, could you tell me...
- what the actual float value you expect from this data? is it 93.51555633544922? or perhaps -0.002974929055199027?
- what register you are reading first?
Also, can you provide a demo flow with data captured from your device (use the "copy value" button on the debug output & paste as text not picture) in an inject node (so I can test it without needing access to your device)
- Please include info like what the actual values SHOULD be
Cheers.
On Wed, 15 Dec 2021 at 10:18, chiarafaes @.***> wrote:
Hello,
We are using your node-red block "buffer-parser" and noticed something weird.
When we use your parser on integers; we get results which are correct. But whenever we use the parser for a float, the swapping doesn't return the values we expect ...
We need a value stored in 2 registers, each register is 1 word and the manual of the device says = <4 bytes>
[image: image] https://user-images.githubusercontent.com/26067234/146168104-81b1e9ef-5781-4e18-95fe-7acf103adaae.png
[image: image] https://user-images.githubusercontent.com/26067234/146168051-8bdb8131-1a3b-421f-ad68-a3411ed53bce.png
Buffer we use to test: data: 0: 0 1: 0
2: 0x7f7 3: 0x42bb
buffer: 0: 0x0 1: 0x0 2: 0x0 3: 0x0
4: 0xf7 5: 0x7 6: 0xbb 7: 0x42
[image: image] https://user-images.githubusercontent.com/26067234/146164845-c39bdf06-6951-412c-be51-b3441d8d5dee.png
we expect 0x42bb07f7
but we get 0xf707bb42
so we started to flay around with your block and noticed the following:
type Swap Result floatbe none 0x07f742bb floatbe swap16 0xf707bb42 floatle none 0xbb42f707 floatle swap16 0x42bb07f7
which means we should use the parser with floatle and a swap of 16 to get the correct value while we expected to use a floatbe and no swap
However, The other types like UINT32BE are correct without setting a swap or setting the type to little endian
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Steve-Mcl/node-red-contrib-buffer-parser/issues/10, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKRPUGMWXYI3FN5HKOT64NDURBTO5ANCNFSM5KDHIXQA .
chiarafaes
Hello,
We are using your node-red block "buffer-parser" and noticed something weird.
When we use your parser on integers; we get results which are correct. But whenever we use the parser for a float, the swapping doesn't return the values we expect ...
We need a value stored in 2 registers, each register is 1 word and the manual of the device says = <4 bytes>
Buffer we use to test: data: 0: 0 1: 0 2: 0x7f7 3: 0x42bb
buffer: 0: 0x0 1: 0x0 2: 0x0 3: 0x0 4: 0xf7 5: 0x7 6: 0xbb 7: 0x42
we expect 0x42bb07f7
but we get 0xf707bb42
so we started to flay around with your block and noticed the following:
type Swap Result floatbe none 0x07f742bb floatbe swap16 0xf707bb42 floatle none 0xbb42f707
floatle swap16 0x42bb07f7
which means we should use the parser with floatle and a swap of 16 to get the correct value while we expected to use a floatbe and no swap
However, The other types like UINT32BE are correct without setting a swap or setting the type to little endian