Ttl Modbus

0 views

Skip to first unread message

Robert

unread,

Aug 3, 2024, 2:06:24 PM8/3/24

to aninovtuan

I have never used modbus protocol before and I am trying to get data from a 3rd party sensor in our facility using Modbus TCP. I have installed the NI Modbus Library v1.2.1.42 using the VI package manager. It looks like I am able to connect, however I can't seem to get the data.

I was able to connect with the provided example in the modbus library but it errored out with any command I gave it. I tried to create my own basic VI to pull the data with no luck (see attached snippet). I incremented/decremented the register number by 1 to see if there was an offset (i read that somewhere) and that did not help.

I was close on my first attempt, just needed to omit the leading 4 from the register input. It also defaults to the first device/unit so I had to specify I wanted the 5th unit/device. Also no idea why the help menu of the "Set unit ID" VI says it won't work for TCP, because it does work and you have to use it if you have multiple devices.

Yes, Set Unit ID definitely works and may be needed for TCP/IP. I think it is a documentation error. I think someone thought that Unit ID isn't needed because the IP address helps identify the device. However, certain devices definitely need a unit ID. For example, a remote serial server working off of ethernet. There is one ethernet port to the device and it has an IP, but if it has multiple serial ports on it, you need the unit ID to know which serial port it is talking to!

I'm looking at a small simple project with a Samba SM70-J. I'm running into quite an issue trying to figure out a modbus tcp connection. I'm able to see the device in modscan, and other PLC's as well. But I can't seem to get my configuration right in Visilogic. Would anyone happen to be available to help me troubleshoot this?

You can't hang the Modbus Read block on the rail. It's initiating a communication every scan and not giving it time to respond. In Modbus TCP land you also have to connect the socket first. If you lose the connection you'll have to trigger your connect logic again. If your application is continuous data transfer, you can leave it connected to the socket. If it's periodic or you change to a different Modbus slave, you'll have to disconnect first before you connect to the new slave.

Unfortunately you can't convert a V280 to an SM70, so I did a little hacking and made it into an SM70 for you. I don't know what your IP addresses are so you'll have to go into the blocks and edit those.

Thanks a lot for your time, Joe. I am only using one device as a slave, and at the end of the project, the goal is to not even need a switch in this panel. I only ever look to read values from the remote IO unit that I'm using.
I hadn't yet encountered the connect/close FB in any of the documentation I had been looking over, thanks for including that with clear instructions. I'm a bit of a millennial and spoiled by the niceties of using autonomous configuration for things like this :D.

I don't have access to this PLC currently, but I will this afternoon. I'm really jazzed to try this program out and see how it does. After working at this for a few days, I really appreciate the rapid response to my question and you taking the time to modify this file to show me what I was doing wrong.

Could I ask you a couple of more questions just for curiosity's sake? This line in the comments says "Below, both Ethernet card initialization and MODBUS Configuration are done as Power-up tasks.
Note that Socket 2 must be initialized, via the Socket Init FB, to function as a TCP Master. Network ID number MUST be 255!"

I noticed that it is set to socket 3 in the demo file, and also set to client, along with the MODBUS IP CONFIG function block socket is set to 3. I had seen in some prior documentation that some were using different socket numbers there in the initialization rung. I was highly confused about how that could ever possibly work? Is that perhaps because they were using the USB port as MODBUS RTU coms potentially?

I'm a bit confused as to how the hex conversion in Visilogic works, if I enter a 3 into the Start of vector box, and set to hex, it doesn't appear to be giving me the actual value for 3(0x0003.) Although I don't suspect this matters whether I enter it there as hex or decimal?

This line in the comments says "Below, both Ethernet card initialization and MODBUS Configuration are done as Power-up tasks.
Note that Socket 2 must be initialized, via the Socket Init FB, to function as a TCP Master. Network ID number MUST be 255!"

Sockets are just defined pathways to specific ports. You can use any of the 4 sockets interchangeably as long as you have initialized them correctly and don't have 2 with identical settings. Each of the 4 sockets have a default initialization, but can be changed at any time (normally at start-up) with a socket initialization function block. The fact that the rung comment and the following ladder rung don't match is just a typo in the comment. Of course, the socket number must match in the initialization FB, MODBUS configuration FB, TCP connect FB, and the MODBUS read or write FB.

So, after testing this file out, I never can get the IP to connect. I'm not sure what I could be doing wrong here. I've looked at this for hours today, and I'm not getting anywhere. I did go through and change the IP's and PLC name to what it should be.

I don't see anything wrong here. Are you able to connect to the PLC from a PC? Are you able to connect to your peripheral from a PC? Have you double-checked all IP addresses and port numbers? I see that you are using port 502 in the PLC and the peripheral. Nothing wrong with that, but just checking. Are you sure the peripheral is set up to be a MODBUS slave on port 502?

Just this morning I was fighting with a PLC that wouldn't connect with MODBUS. I was ready to pull my hair out until I replaced the Ethernet cable. The cable was relatively new and was just recently working. Make sure you troubleshoot the ENTIRE connection, including cables, hub, etc. If you're not using a hub, are you using a crossover cable or adapter?

I was able to connect to the PLC on ethernet before I dropped this program in. I'm just now realizing that no matter what I do with this program, I can't reestablish ethernet coms PC to PLC, I have to use USB.

I'm not necessarily sure what I did differently, but I started from scratch with the file Joe uploaded earlier, and set things one at a time to see which FB or INIT was bugging out, but this time, everything seems to be working but the connection to the remote IO device through modbus.

Here is the last configuration I came up with that would at least show the "connected" bit and allow Ethernet access from my PC. I get a 7, 4, and then 5 from MODBUS error status when trying to read the address. I'll keep trying to play with the start of vector to see if I can get lucky, but it appears to be the case that it just doesn't want to read. I had this set up with a Productivity, and Codesys PLC last night, and neither of them gave me any problems. I'm not necessarily ready to give up, but this is day three on this for me and it's driving me nuts! I appreciate all of the help from everyone who has looked into this with me.

First let's get our Visilogic versions straight here. I created the example in 9.8.65, but I was unable to open what you re-posted. I'm guessing you have the latest version of Visilogic (9.8.96) so I'm downloading that. Unitronics changes the database revision from time to time and older versions can't open something saved with newer stuff. Usually an O/S update in the PLC accompanies this. They have a really nifty tool called the Version Swapper that lets you manage different programs on different machines created at different times, but that discussion can be found elsewhere on the forum.

1. The PLC is set to IP 192.168.1.110. If you're on a network with a router that has DHCP turned on make sure this address hasn't already been assigned. Don't ask how I know to check for this. You can tell by pinging that address from your PC with the PLC disconnected.

2. Socket 3 is set to TCP Master at port 502. I put this in my example but it may be a problem, as Socket 2 defaults to a Modbus Slave also at port 502. I changed the port for Socket 3 to 503. It is perfectly fine to use port 503 on the Master to talk to port 502 on the Slave. Yes, this is confusing.

YAHTZEE!!! That program did it Joe!!! The only difference I can see right away is perhaps the Slave ID being 1 instead of 254 or 255? It is most certainly working with that program now :D. Thank you to everyone who took time out of their day to help troubleshoot this. I'm not the brightest crayon in the box, so lord knows I needed the help. Your help is truly appreciated!!!

It was the port number. I didn't even think of that when I was putting the example program together. By default, Unitronics assigns port 502 to socket 2 and sets it as a TCP Modbus slave. By also assigning port 502 to socket 3 without manually assigning something else to socket 2 we left the PLC in a position where it didn't know whether to shit or go blind.

Well, in all fairness, I didn't know whether to shit or go blind either. Thanks a ton for your help with this, and everyone else who looked into it. I think I should be able to handle the rest of this project. I have 3 other sensors I want to read an analog signal on that same I/O.