10-24-2019 09:48 AM
So essentially, I want a boolean switch to control a modbus register to a Control By Web modbus slave (manual attached). I can read from the modbus holding registers of the slave perfectly fine, but that is really only there for testing it. What I want to do, is when the boolean switch is on (1), it sets the register to a value of 1.
I have registers assigned in addresses 0000 - 0094. What I've been trying to get working is writing to 0044. I keep getting an error that states something along the lines of 'Modbus slave does not accept address from query". Of course, the read function works, but write doesn't. I've included as much information as I can think of. I appreciate any help.
Solved! Go to Solution.
10-24-2019 10:41 AM
Let's start with some tips.
My gut feel is this whole VI could be combined into a single loop if it had the right architecture.
10-24-2019 12:53 PM
1. Labels don't matter, those are holding positions and will be erased as soon as possible. The LEDs are for aesthetic purposes; unless I can re-skin the buttons easily, those must remain for now.
2. I've changed it to have one loop, the New TCP Master is placed outside of the loop, and all read/write functions are happening inside. This seems to have changed nothing.
3. Like I said, I've changed it to only open the modbus instance once, but it changed nothing. I have also tried eliminating the Read Register, and conditional, meaning that there was only one Write Register total. This resulted in the same error. This leads me to believe that the problem lies solely within the Write block.
4. That is not updating the tables, but the scrollbar. It doesn't necessarily need to be 2ms, but it will be reasonably small in the final iteration to make movement smooth.
5. The loops are there for my own organization so that I can separate out processes. There is no need to have a large loop including two portions that relate in no way.
10-24-2019 01:52 PM
@kyle.prouty wrote:
1. Labels don't matter, those are holding positions and will be erased as soon as possible. The LEDs are for aesthetic purposes; unless I can re-skin the buttons easily, those must remain for now.
Actually they do matter. As a programmer, I want to know what is the purpose of each terminal when I'm looking at the block diagram. As for the LEDs, they are redundant. You can certainly use them if you want, but did you notice the button itself has an LED built into it to help show whether they are pressed? You can also custom controls if you need to.
2. I've changed it to have one loop, the New TCP Master is placed outside of the loop, and all read/write functions are happening inside. This seems to have changed nothing. I don't see any updated code attached.
3. Like I said, I've changed it to only open the modbus instance once, but it changed nothing. I have also tried eliminating the Read Register, and conditional, meaning that there was only one Write Register total. This resulted in the same error. This leads me to believe that the problem lies solely within the Write block. I don't know how you can draw that conclusion. Best bet is to make a simple program that does just one thing that writes to that register and sees if it works by itself. Then try adding a read before and a read after that all acts in series.
4. That is not updating the tables, but the scrollbar. It doesn't necessarily need to be 2ms, but it will be reasonably small in the final iteration to make movement smooth. 2 milliseconds is faster than any human can realize. If you need to do it that way, may it more like 100 milliseconds and it will still seem responsive. Or 50 milliseconds. But an event for the scroll bar will be better as it will only execute when the scroll bar actually changes.
5. The loops are there for my own organization so that I can separate out processes. There is no need to have a large loop including two portions that relate in no way. You may not need a single loop, but you don't need so many loops. At least 2 of your current loops do relate and should be combined.
10-24-2019 02:00 PM
I just had a quick look, but one thing that's interesting is the table of supported function codes on page 100 (PDF page 102) of the manual you attached. You are using the Write Single Holding Register function which is function code 0x06 but the device doesn't seem to actually support that function.
The LabVIEW API has a separate function for writing to multiple holding registers which the device does support so I would probably see if you can use that function.
10-24-2019 02:03 PM
The LEDs are there to make the front-end look better. But I have removed it all for a simpler setup. That is attached, with the only modbus instance being used to write to a holding register. I've also revised the address to 0 since it is 'easier' for the sake of finding it on the device (for me).
10-24-2019 02:04 PM
I've seen that it isn't listed with the other functions, but on page 100 in the table, it shows that Function 06 (Write Single Register) is there. My guess was it was not included in the following pages due to coverage by other functions. However, I have also tried using Write Multiple Holding Registers, and I receive the same error.
10-24-2019 02:35 PM - edited 10-24-2019 02:36 PM
@kyle.prouty wrote:
The LEDs are there to make the front-end look better. But I have removed it all for a simpler setup. That is attached, with the only modbus instance being used to write to a holding register. I've also revised the address to 0 since it is 'easier' for the sake of finding it on the device (for me).
I don't recommend making the address 0. Address 0 is usually used for broadcast messages to all devices on that line. (Which applies more to multi-drop serial rather than TCP/IP).
But that does remind me of something I came across one of the few times I did Modbus TCP/IP. Most of my Modbus has been Serial RTU.. What was the slave address before you changed it to 0? I think the LabVIEW VI's default to slave address 1. And the purple TCP/IP versions don't really give you an spot on the Configure Server to make it something else.
Add a property node to the Modbus reference and explicitly set your Unit ID to match whatever you configured on the device.
You may also want to try download an older Modbus library through VI Package Manager called NI Modbus Library 1.2.1.42. It is older, but it is much more open to seeing what goes on inside of it. I still use it frequently.
10-24-2019 02:39 PM
The API is actually on GitHub now.
https://github.com/NISystemsEngineering/LabVIEW-Modbus-API
10-24-2019 03:25 PM
Which modbus API is that?
And what are you supposed to do with it from Github? I just see a long list of stuff with no explanation that was last updated 11months to 1 year ago.