LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Modbus Master/Slave confusion

Solved!
Go to solution

girish_jadhav_0-1616093765500.png

 

We have a communication module which will be connected to a heat pump via CAN bus. This communication module then sends all the sensor values over Modbus TCP/IP to our PC. 

 

I tried with Modbus Slave library to connect to this module but I couldn't read anything.  

ex_mod_slave.png

Why is IP address not needed when PC with LabVIEW acts as a Slave? What am I doing wrong here?

0 Kudos
Message 1 of 13
(3,557 Views)

Typically the slave is the device that holds the data. Master queries the slave and slave responds. Are you sure your diagram for this setup with the PC being slave is correct?

0 Kudos
Message 2 of 13
(3,545 Views)

I spoke to the person who will program this communication module today and he said that module is the Master (and cannot be changed). PC should then be Slave, right? 

0 Kudos
Message 3 of 13
(3,538 Views)

Well the Modbus protocol can only have one master (client) and the master is the only one that can initiate communication so I don't know how you get data to the PC in that situation.

0 Kudos
Message 4 of 13
(3,532 Views)

@girish_jadhav wrote:

I spoke to the person who will program this communication module today and he said that module is the Master (and cannot be changed). PC should then be Slave, right? 


It's possible that this person screwed up this terminology, or perhaps the actual implementation.

 

Normally the PC would be a master, the device is the slave.  It is also very likely there would be multiple modules out there and thus there would be multiple slaves.

 

It's possible that from your picture, you have two different Bus communications going on and that changes things.  That communications module called "Master", might be the master for the CAN bus.  The Modbus comms are a different communication bus.  Typically, the PC would be the master and the device gathering the data, like Steven says, would be the slave.  So that "Master" in the middle would be the master to the CAN bus, but the slave to the Modbus bus.

 

One other thing to throw in on terminology.  The names Master/Slave typically apply to  serial communication.  Your VI shows you are using Modbus TCP/IP.  There the terminology is Client/Server.  I find those terms make it harder to know which is in control and which is the responder.  But the Client is roughly equivalent to Master, it is the one that does the data requesting.    Server is roughly equivalent to the Slave, it is the one that hold the data and "serves" the data back to the client upon request.

 

You can reverse those roles between the "master" and the PC, but that usually means the PC needs a service running on it, or a "daemon", that is constantly running waiting for the the "master" to send the data to it.

Message 5 of 13
(3,515 Views)

girish_jadhav_0-1616097279178.png

girish_jadhav_1-1616097396446.png

 

. You can set the IP address of the Slave in the communication module.

 

0 Kudos
Message 6 of 13
(3,511 Views)

Normally the PC would be a master, the device is the slave.  It is also very likely there would be multiple modules out there and thus there would be multiple slaves.

 

It's possible that from your picture, you have two different Bus communications going on and that changes things.  That communications module called "Master", might be the master for the CAN bus.  The Modbus comms are a different communication bus.  Typically, the PC would be the master and the device gathering the data, like Steven says, would be the slave.  So that "Master" in the middle would be the master to the CAN bus, but the slave to the Modbus bus.


In our case there is only one communication module. Maybe I didn't understand what you meant by that. Thanks for this explanation. I will check with him if there is way to set the comm. module as a server. 

 

 

0 Kudos
Message 7 of 13
(3,505 Views)

@girish_jadhav wrote:

Normally the PC would be a master, the device is the slave.  It is also very likely there would be multiple modules out there and thus there would be multiple slaves.

 

It's possible that from your picture, you have two different Bus communications going on and that changes things.  That communications module called "Master", might be the master for the CAN bus.  The Modbus comms are a different communication bus.  Typically, the PC would be the master and the device gathering the data, like Steven says, would be the slave.  So that "Master" in the middle would be the master to the CAN bus, but the slave to the Modbus bus.


In our case there is only one communication module. Maybe I didn't understand what you meant by that. Thanks for this explanation. I will check with him if there is way to set the comm. module as a server. 

 

 


You have one communication module.  But the left side of it is talking out to a heat pump on the CAN bus.  The right side of it is talking to the PC using Modbus.  That is two different communication paths.

 

Your pictures in message 7.  Is that software on the PC that is getting data from the Communication module?  Or is that software that is to configure the communication module?

0 Kudos
Message 8 of 13
(3,471 Views)

@RavensFan wrote:

@girish_jadhav wrote:

Normally the PC would be a master, the device is the slave.  It is also very likely there would be multiple modules out there and thus there would be multiple slaves.

 

It's possible that from your picture, you have two different Bus communications going on and that changes things.  That communications module called "Master", might be the master for the CAN bus.  The Modbus comms are a different communication bus.  Typically, the PC would be the master and the device gathering the data, like Steven says, would be the slave.  So that "Master" in the middle would be the master to the CAN bus, but the slave to the Modbus bus.


In our case there is only one communication module. Maybe I didn't understand what you meant by that. Thanks for this explanation. I will check with him if there is way to set the comm. module as a server. 

 

 


You have one communication module.  But the left side of it is talking out to a heat pump on the CAN bus.  The right side of it is talking to the PC using Modbus.  That is two different communication paths.

 

Your pictures in message 7.  Is that software on the PC that is getting data from the Communication module?  Or is that software that is to configure the communication module?


It is the web portal to configure the communication module (https://help.ta.co.at/EN/CMIHELP/index.htm)

0 Kudos
Message 9 of 13
(3,415 Views)
Solution
Accepted by topic author girish_jadhav

Okay.  So the IP address in there of 10.92.56.38 is your PC's IP address?  In which case this device does want to be the master and wants your PC to be the slave.  It is the more difficult way to handle the communications.  I'd say it is 10 times more difficult to get this set up.

 

You'll need more than just what you've shown in your basic VI.  You'll need a slave daemon which keeps track of all the registers you define in your PC so that the slave VI's know what data to send when this device master sends requests for data.

 

Look in the palette for the Modbus TCP >>  Slave API and you'll see a VI in there called Modbus Slave Example.  Drop that in to a blank VI and open it up.  It will give you an architecture example of what you'll need to have running on your PC.  The key part is that you need to define registers in your VI and set their values.

 

The other concern I have looking at the example is terminology and the direction of data flow and I can't tell if terminology is reversed in this example, or if there are a couple of cases missing.  In Modbus,  a master can read or write to a holding register on a slave, a master can only read from an input register on a slave.  So all of these registers are essentially memory locations within the slave.  In your case the device is the master, and the PC is the slave with this code running.  I see a set for Set Input Registers.  That makes sense, you Write to the Input Registers on this slave, and the master device is able to send the command to read them.

 

I see a Fetch Holding Registers.   That makes sense if the master is to a Write to the Holding registers and in your VI you want to be able to see what values it wrote.  So that takes care of a Write command on the master.  But your master is using a Read Holding Registers command.  What I don't see in this example is the corresponding case that allows the VI to set the value in the slave (this PC) so that the master can read it.

 

So I think this example VI may be incomplete.  You may need to add another case and a set of controls that allow you to set the holding registers on the PC into the Slave daemon's memory space, so that the master comms device is able to read the values.

0 Kudos
Message 10 of 13
(3,401 Views)