Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Little vs big endianness #453

Closed
ihitsov opened this issue Mar 18, 2024 · 8 comments
Closed

Little vs big endianness #453

ihitsov opened this issue Mar 18, 2024 · 8 comments

Comments

@ihitsov
Copy link

ihitsov commented Mar 18, 2024

Describe the requested feature

I have a device that has a modbus address (unitid) of 1. When I read this address I get this:
{"data":[256],"buffer":[1,0]}. The address should be 01 (address 1), but instead it is read [1,0] or 01 00, so 256. For this, its not a problem since I can read the buffer and work with this. However, I am not sure how to write to this value a new unitid. I would like to send new address (unitid) of 3, but the write fails and my device restarts and has again the same address. I suspect that the write function has problem with the little vs big endianness. I think what happens is the modbus function sends 00 03 instead of 03 00. Since the device flips the position of the bytes it then becomes 03 00 which is then read as 768 which is outside of the address range and is ignored.

For writing I am using an inject node to inject a number and a write function with FC6 and the same address that I used read the default unitid.

This is from the manual of the device:

2 bytes in total
00~01: Device address
The settable range is 1~247
For example, the data obtained is 02 00 (low first, which means the address is 2)
Taking address 15 as an example, write 0F 00 (low first) to the corresponding address. When the current device address is unknown, FF can be used as the general device address to query the current device address.

Motivation

To tackle cases where little vs big endian is needed

@biancode
Copy link
Contributor

In this case I want to suggest you to give it a try via the modbus-serial lib directly if you get it to work in this use case. Is it allowed from your device to write the UnitId from the client? Mostly it is a parameter to set in the device or some jumpers to set.

@ihitsov
Copy link
Author

ihitsov commented Mar 22, 2024

Thanks for the reply! The address is definitely settable via modbus as also stated in the manual. Besides this I also had the same problem with another device with 4-20mA outputs that also expected small endian and I couldnt get it to work with this library.
I will follow your suggestion to try the other library, but I am a bit hesitant as the whole lab runs on this server and if I break the library my colleagues wont be happy :) Sometimes similar libraries break one another in my experience.

Best regards
Ivaylo

@biancode
Copy link
Contributor

See the package.json of our contrib - you can use the existing or same modbus-serial lib to get no conflicts.

@biancode
Copy link
Contributor

biancode commented Mar 22, 2024

Did you try the flex-writer to send LE buffer data? Check the buffers of the nodes if you read, what you get there.

@ihitsov
Copy link
Author

ihitsov commented Mar 22, 2024

I only tried to send it a modified buffer with the normal write function, but this didint work. I will try the flex writer next week.

Best regards
Ivaylo

@ihitsov
Copy link
Author

ihitsov commented Apr 9, 2024

I really appreciate your help!

I tried the modbus flex write node, but it doesnt seem to work. I tried all kinds of combinations, but no luck. Can you please suggest how I should make the modbus flex-writer message? I am able to write to devices that are big endian with this library, no problem at all. Just devices that expect LE are problematic. Thanks in advance!

@ihitsov
Copy link
Author

ihitsov commented Apr 24, 2024

Hi, I wanted to ask for help with this once more. Is there any chance to change the endianness of the messages being sent to my devices? I dont know how to proceed further with this. Thanks in advance!

Copy link

This issue is stale because it has been open 60 days with no activity. It will be closed in 30 days, but can be saved by removing the stale label or commenting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants