LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Process Failure when communicating over MODBUS using LabVIEW 2011 and DSC

Solved!
Go to solution

I'm currently trying to read from a PLC's holding registers using MODBUS/TCP. I've confirmed that the PLC is updating the values and responding to MODBUS communication correctly using a third party program called Modbus Poll. However, when I try to poll the PLC using LabVIEW's shared variable engine, I am unable to read any values from the same addresses that I'm viewing with Modbus Poll.

 

My setup simply consists of a PC connected directly to the PLC over Ethernet, with no router in between. I am using LabVIEW 2011 SP1 with the DSC module.

 

I opened the NI Distributed Systems Manager to view the status of all shared variables in the Modbus library that I created and I've noticed that the CommFail bit is permanently set to "true". All other variables with a "read" access mode report "Process Failure". I've tried restarting the process as well as stopping and starting the local variable engine with no success. I've also restarted my computer several times to see if any services were failing, but this does not seem to have fixed the problem.

 

I finally resorted to monitoring communications over the network card that I have the PLC plugged into via Ethernet using Wireshark and I've found that while Modbus Poll is communicating with the PLC, many MODBUS and TCP packets are sent and received. However, when solely using LabVIEW or the NI DSM to communicate with the PLC, there does not appear to be any communication over the network card.

 

Something that may be worth noting is that I was able to communicate with the PLC and read values from it with the DSM on just one occasion, when I first figured out which addresses I should be reading from. It all stopped working shortly thereafter. Prior to this, "CommFail" was not usually set to "true" with my current configuration. Thinking that it was my firewall, I have since turned my firewall off, but this seems to have had no effect on the problem either.

 

Any help on this matter would be appreciated.

0 Kudos
Message 1 of 3
(2,953 Views)

Just a thought but I think the  register addresses used by LabVIEW are one off of the actual register #.  I was using a CRIO as a modbus IO Server and had to shift the register addresses by 1 to get things to work correctly (can;t recall if it was +1 or -1).  This is documented somewhere on ni.com but can;t seem to find it now.  But here is another  link that may help:

 

 

http://zone.ni.com/reference/en-XX/help/371618E-01/lvmve/dsc_modbus_using/

 

Dan

 

0 Kudos
Message 2 of 3
(2,948 Views)
Solution
Accepted by topic author Griffon2-6

All right, I've figured it out. It turns out that the IP address of the MODBUS I/O server needs to be set to the address of the MODBUS slave device, not the local machine. The address of the MODBUS I/O server is set by navigating to the Project Explorer window, expanding the MODBUS shared variable engine library, and right-clicking the MODBUS server item (e.g. Modbus1) and selecting properties.

 

Also, the addresses do indeed appear to be shifted by +1.

 

Thanks for the tip though.

0 Kudos
Message 3 of 3
(2,935 Views)