Data tables and MODBUS: PC Master

[markw444]

Hello,

I apologize if this question has been answered; I've searched the forum and help files without any luck.

 

I'd like to know where I can find information for MODBUS protocol to read  from Data Tables. For context I have about a dozen Samba 7" controllers networked and connected to my PC (MODBUS TCP/IP). I wrote a C# application that pulls data from all the controller  bits and registers with the standard MODBUS functions--everything works fine. Up until this point, the logic made minimal use of data tables, so I didn't have a reason to read data from them. Now, however, I need to read Data Table information.

There is clearly a MODBUS function block for reading from data tables, but I haven't been able to find any information about the command sequence for this function that would allow me to implement it a Data Table read with a PC master. The "VisiLogic Software Manual: VisiLogic Function Blocks" make brief mention of the information I'm looking for:

"Please note that this is not a standard MODBUS function. Read/Write from Data Tables is compatible with Unitronics' Vision PLC data tables only"

 

Thank-you in advance for any useful information,

 

Mark

[Ausman]

One way that I could see you getting an idea of what you need would be for you to actually write a small program that uses one of your Sambas as a Master to use the Read from Data Table FB.   Once you have that in place (and obviously with a bit of extra cabling) run the FB whilst using a monitor on the line to see what is actually being said b/n the Master and the interrogated Slave.  Something like SmartSniff etc might do the job.

Whether it will translate easily is the unknown, but it will at least give you a fairly definite starting point.

cheers, Aus

[markw444]

Hey Aus,

 

Thanks for the suggestion--I started to implement something along the lines of what you described and then thought I needed to have a PC process listening on the port number (502 for MODBUS) from the MODBUS master logic program--this would allow the TCP handshaking to occur. Not wanting to have to get into writing some code to create a server listening on port 502, I decided to hook two Sambas and my second network card into an unmanaged switch to make a small network.

I made up a VisiLogic program for the MODBUS master PLC and one for the MODBUS slave PC, hoping to capture the communications between them with WireShark. For reference, the IP addresses on this network are 172.16.0.0/2.

After setting the static IP of my second network adapter to 172.16.0.0, the IP of the slave to 172.16.0.1, and the master 172.16.0.2, I tried capturing the traffic in WireShark with the filter "ip.src==172.16.0.0/24 and ip.dst==172.16.0.0/24".  I first successfully pinged and captured traffic to and from both PLCs from my PC and then tried running the read data tables command from the master. Unfortunately, this didn't work--when connecting the socket in my Master's ladder logic, it made  a request to the IP address of the Slave for handshaking, but never received a reply. The attached screenshot shows the extend of the communications--two series of pings and the request from the Master. 

I feel that this may be an error in my ladder logic--I've never programmed a Samba as a MODBUS master before. I've attached both programs with the hope that someone might see an obvious mistake I've overlooked. I appreciate any further help.

 

Thanks,

 

Mark

MODBUSmaster 1902220704.vlp

MODBUSslave 1902220720.vlp

[Flex727]

In your Master program your MODBUS Config and MODBUS Read DT you are identifying the slave IP address as 172.16.0.0, but your slave is 172.16.0.1.

Also in your Slave program, delete the line from your MODBUS config (Index 0) where you identify a slave IP address - that's what gets entered into the Master config, not the Slave config. It probably just ignores it, but delete it anyway.

[markw444]

Hey Flex,

I updated the MODBUS configs in the program, but ended up with the same results: the Slave PLC doesn't respond to the master when the master tries connecting its Socket 3 to 172.16.0.1. I've attached new programs/capture screenshot. I apologize if this is something I should be contacting Unitronics for help with--please let me know if it's outside the scope of the forums.

Thanks,

 

Mark

MODBUSmaster 1902220920.vlp

MODBUSslave 1902220922.vlp

[Flex727]

I loaded up your two latest programs into two PLCs I have here in my office and it seemed to work perfectly. I would suggest, however, that you add an inverted contact of SB 150 in series with the other contacts in your Master Connect ladder rung (rung 6).

[markw444]

Thanks for your help Flex. The program does work properly, I pulled a stupid and was relying on what I'm seeing in WireShark--which monitors only the traffic into and out of my PC's network card, not any traffic occurring on the switch. I think I'll have to follow Ausman's suggestion and write up a program to listen on port 502 on my PC.  At least I now know the MODBUS master program works!

[Flex727]

Also, if you want to get rid of that compile warning about SB 168, SET the Power-Up value on the operand itself instead of using SB 2 in ladder.

[markw444]

Just as an update, I've put together a basic server that echos any information sent to it and have it running as a console application on port 502 on my PC. I also put together a console client application that connects to this server--I can successfully send information from the client application to the server application. I then tried replacing the client application with one of my Samba 7" units, hoping to see the packets coming through my network card. The Samba sets up the initial TCP handshaking with an address resolution request, to which my PC responds, and then the Samba just continually tries connecting. The connection never successfully occurs. 

[Ausman]

Hmmmm. Ensure your A/V isn't blocking anything.  Try using a crossover cable on your first method to eliminate the switch.  I can't see that will help, but perhaps worth a try.

Further thinking needed.  Seemed like a good idea, but I knew it might be hard to do!  It does sound like some crucial bit of info is being stopped somewhere along the route. 

cheers, Aus

[Ausman]

You say that you have 2 cards.

14 hours ago, markw444 said:

decided to hook two Sambas and my second network card

So perhaps your correct layout should be with the PC purely acting as a pass through, with shark monitoring the line.  I was thinking that you might need another card, but when re-reading your post saw that you already have one on board.

And another thought, perhaps all you need might be obvious if you monitor comms using serial.  In theory the contents of packets would be vaguely similar and you might be able to combine this with other methods you are already using that you know works.

cheers, Aus

[Ausman]

And my brain has obviously pondered this all day, because tonight up popped this other idea.   (thanks so very much for keeping my brain active!)

Further to your "Just as an update", I think you should try running everything through a router, which might give you better control and monitoring to ensure that the Samba is indeed correctly on the network.

Or simply wait for someone who actually knows the full details to post their secrets!  But it might be a long wait.

cheers, Aus

[Joe Tauser]

You can use Wireshark to monitor Modbus TCP communications if you can get your hands on an old Ethernet hub - all packets are broadcast out all channels.  I've been told a managed switch can do the same thing but I don't have access to one of those.

This hardware setup has been very helpful in a problem I had troubleshooting Modbus TCP errors that turned out to be caused by packet timeouts.  You are on the right track.

Joe T. 

 

[Ausman]

9 minutes ago, Joe Tauser said:

you can get your hands on an old Ethernet hub -

So Joe,  are you saying I'm old  'cause I've got lots of those?  😀  

As soon as I read your suggestion I was cursing that that thought hadn't popped into my brain.  Maybe the old grey matter was simply thinking along the lines of a hub anyway, forgetting "modern" progress.

cheers, Aus