LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reading/Writing to Modbus Holding Registers

Solved!
Go to solution

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.

Download All
0 Kudos
Message 1 of 11
(8,223 Views)

Let's start with some tips.

  1. Every terminal on your block diagram should have a meaningful label.  Not a bunch of "blank"  button write to "blank" LED like it is now.  You can hide the labels on the front panel if you want.  I'm not even sure why you need the LED's since the status of the button indicates the same thing the LED does.
  2. You should open the Modbus once before the loop, and close it after the loop like you do in that one small loop.  Not on every iteration like in your bigger loop.
  3. I wound not start separate processes for different reads and writes to the same device.  It would not surprise me if the opening and closing of the resource might not be interfering with the other place you are doing.  If this was serial, I'd really expect that.  But this is TCP/IP, so maybe not a problem.  But yet perhaps the device only allows one connection to it in which case it would be a problem.  Combine all Modbus communications into a single loop.
  4. Do you really need to update those tables every 2 milliseconds?  It seems like that should be an event structure that only acts on a change.
  5. Check your coercion dots.  For instance you have a 1000 wired to the wait timer, but they are different datatypes.  While it won't cause a problem in this case, you won't have any problem if you use the correct datatype when possible.  The easiest way to do that is when you create a constant, indicator, or control, right click on the terminal of the function and pick "Create ..."

My gut feel is this whole VI could be combined into a single loop if it had the right architecture.

0 Kudos
Message 2 of 11
(8,190 Views)

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.

0 Kudos
Message 3 of 11
(8,145 Views)

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


 

0 Kudos
Message 4 of 11
(8,123 Views)

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.

Matt J | National Instruments | CLA
0 Kudos
Message 5 of 11
(8,118 Views)

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

0 Kudos
Message 6 of 11
(8,117 Views)

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.

0 Kudos
Message 7 of 11
(8,113 Views)

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

0 Kudos
Message 8 of 11
(8,100 Views)

The API is actually on GitHub now.

 

https://github.com/NISystemsEngineering/LabVIEW-Modbus-API

Matt J | National Instruments | CLA
0 Kudos
Message 9 of 11
(8,094 Views)

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.

0 Kudos
Message 10 of 11
(8,080 Views)