Jump to content
LoganS

samba third part modbus tcp IO (protos x)

Recommended Posts

Disclaimer- Im self taught PLC programmer so some of the ways I have done things may be unorthodox and I am open to suggestions and always willing to learn.

I had a machine build were the scope of the project changed and I needed more IO.  I had already installed the SAMBA and needed more IO.  I ordered a 16 pt input module and an 8 point out module of the automation direct PROTOS X modbus tcp remote IO.

I have the io working and it suits the needs of the application.  What I am wondering is if you guys could take a look at my code and tell me if it could be optimized.  I had to use a 20ms delay on the read write to get this to work without it having unpredictable behavior.  This 20ms delay makes my total turnaround time to read an input and update and output somewhere around 45ms.  This is acceptable for this application but I would like to do better if it is just a matter of optimizing my way of handling the modbus messaging or something.  I also could use this combo more often if i can make it faster as this combo is cheaper than buying a vision plc and using unitronics IO, just currently it is slower.

 

I have changed my ip so it may appear that it wouldnt work the way it is but the code works.  I dont know enough about network security to go posting the IP on the forum. Im sure that not enough to do anything but I changed them.  I also removed all the subroutines so you may see some stuff called that doesnt exist. 

 

Again, I am looking for ways to optimize my modbus messaging!  Thanks!

redacted forum program.vlp

Share this post


Link to post
Share on other sites

Here is a list of issues that I noticed at a glance (the first 3 items are just about best programming practice - they won't prevent your code from working):

Rung 1 - Use the Power up with the operand instead of SB 2.

Rungs 7-10 - ALWAYS use a transition contact to load an HMI display (I recognize that your code would have the power flow on for only 1 PLC cycle, which is why it works). Also, don't add any code in the same ladder rung after an HMI call FB.

Rung 11 - Just use SB 2 for all your comm initializations. I'm finding it surprising that your tap machine (or whatever the MODBUS slave is) takes that much longer than the PLC to boot up, but if so, then I suppose you have to do it the way you are. However, use SB 2 to initialize everything, then place your delay on the connect only. The PLC doesn't care, but it's better programming practice.

Rungs 19-22 - You need to SET a bit for your read and write, then RESET the bit at the end of the MODBUS read & write (similar to what you correctly do for the connect & close functions) to allow for the busy bit to be on. This may be why you were seeing unpredictable results without the timers. 

Share this post


Link to post
Share on other sites
2 hours ago, Flex727 said:

Here is a list of issues that I noticed at a glance (the first 3 items are just about best programming practice - they won't prevent your code from working):

Rung 1 - Use the Power up with the operand instead of SB 2.

Rungs 7-10 - ALWAYS use a transition contact to load an HMI display (I recognize that your code would have the power flow on for only 1 PLC cycle, which is why it works). Also, don't add any code in the same ladder rung after an HMI call FB.

Rung 11 - Just use SB 2 for all your comm initializations. I'm finding it surprising that your tap machine (or whatever the MODBUS slave is) takes that much longer than the PLC to boot up, but if so, then I suppose you have to do it the way you are. However, use SB 2 to initialize everything, then place your delay on the connect only. The PLC doesn't care, but it's better programming practice.

Rungs 19-22 - You need to SET a bit for your read and write, then RESET the bit at the end of the MODBUS read & write (similar to what you correctly do for the connect & close functions) to allow for the busy bit to be on. This may be why you were seeing unpredictable results without the timers. 

yes i found the boot time on the remote io to be ridiculous. Prior to the timer, the PLC would stop trying to connect by the time it was online. I got so frustrated I put a 1 minute timer and it worked... I decreased the timer untill it didnt work again and landed on the timer that I have... Perhaps Its a setting on the IO side that I could play with but the machine is rarely turned off and I have to wait for a servo to home anyways so I left it.  

 

Regarading your suggestions, Thank you!  I will work those into my programs for now on.  If you saw my code a year ago you'd realize I have come a long way lol but always room to improve. 

 

For the modbus, are u suggesting that instead of using the timer based one shot, I replace with something that will just continually set a bit to request the modbus read and write, having the end of the FB reset that bit? And in theory it will just run as fast as the PLC scans?  This was how I assumed i would have it work but failed at implementing somehow and ended up using the "hammerhead approach" with the timers... I decided to post this question because I knew there had to be a better way as the tcp packet and modbus data CANT take 20 ms over ethernet surely.... 

 

Could you elaborate a bit on how to implement? 

Share this post


Link to post
Share on other sites
17 hours ago, LoganS said:

For the modbus, are u suggesting that instead of using the timer based one shot, I replace with something that will just continually set a bit to request the modbus read and write, having the end of the FB reset that bit?

No, I am suggesting that whatever you use to trigger the MODBUS read or write, whether a timer, or an HMI pushbutton, or anything else, have that trigger set a bit and then use a direct contact of that bit to trigger the MODBUS read with a reset of the bit at the end of the rung, like this:

image.png.76b537d8ce54537246dd9ed1c004e982.png

Share this post


Link to post
Share on other sites
6 hours ago, Flex727 said:

No, I am suggesting that whatever you use to trigger the MODBUS read or write, whether a timer, or an HMI pushbutton, or anything else, have that trigger set a bit and then use a direct contact of that bit to trigger the MODBUS read with a reset of the bit at the end of the rung, like this:

image.png.76b537d8ce54537246dd9ed1c004e982.png

I changed both the read and write to how you show above and the erratic  behavior cam back which is why I think i ended up going to the one shots.  I didnt even try reducing my read write timer and the behavior returned.  By erratic, I mean when i look at the total sessions, the modbus read is outpacing the modbus write by a factor of three.  All I changed is what you list above but did it to both the read and write.

When I change it back to the one shot contacts it works again and the total sessions stay equal to each other (well technically they are not equal because the read is always 1 higher)

 

 

 

Share this post


Link to post
Share on other sites

Do MB 21 and MB 30 stay on? If so, you may be trying to communicate too fast. Use something like this, but replace MB 21 & MB 30 with what you REALLY want to initiate the comm (or just delete them entirely if you want to continuously run the data transfer). You can change TD 20 preset to whatever works for you, but 100ms should be plenty slow to avoid dropped packets.

image.png.2369c093d7d0665244e1ecd9165c2e7f.png

Share this post


Link to post
Share on other sites

mb 30 stays on once the remote IO is online.  Since this a remote IO device I want to continuouly read the inputs and write the outputs as fast as possible with out missing packets and with predictable behaviour.  I have this currently working with a 20ms timer for read and write making for a 45 ms round trip.  I am just trying to improve the performance to maybe a 10 ms (which in my application is about 8 PLC scans which I thought was easily doable) maybe not tho.  Im sure it would work with 100ms delay, as I currently have it working with 2oms delay

Attached is a capture of the logic I built to get the read right to continuoulsy execute.  I started with a high number and reduced until the behaviour of the read writes became erratic and landed at 20ms.  My whole reason for posting is to see If I can do better than 20ms.

 

As you can see, once socket 2 is online, there is a 1 second delay, then "rx tx start" is latched.  Then there is what I intended to be a standard PLC flasher logic (maybe this is where I went wrong?).  This flasher sequence controls "IO read write".  "IO read write" is then feeding the read write bit via a direct contact to the read, and an inverted contact to the write.  These just turn on the "request to read" and "request to write coils" and the rising edge of each is what kicks off the respective modbus FB's.  This works well IF 20 ms is the fastest I can go.  If there is something fundamentally wrong with this preventing me from going faster, I would like to hear.  

 

 

 

 

1111.PNG

Share this post


Link to post
Share on other sites

I have a system currently running that has MODBUS TCP communications between 2 Unitronics PLCs that does a MODBUS read and write on EVERY PLC cycle (about every 7ms). If you have to build in delays, it's due to the device you're communicating with, not the Unitronics PLC.

Share this post


Link to post
Share on other sites
16 hours ago, Flex727 said:

I have a system currently running that has MODBUS TCP communications between 2 Unitronics PLCs that does a MODBUS read and write on EVERY PLC cycle (about every 7ms). If you have to build in delays, it's due to the device you're communicating with, not the Unitronics PLC.

Could you show me a code snippet of how you are initiating the read write FB's continuoulsy every scan??  All of the examples in Uni are of someone pushing an HMI button and sending the data.  I also couldnt find any examples online... I cant believe that continuously scanning IO slices as fast as possible isnt a question more people are asking.  I guess maybe I'm just the only one struggling with it, or like you said, maybe the device is just slow.  I doubt that however, im sure its some setting I have

Share this post


Link to post
Share on other sites

I was able to almost double my performance using the code below.  Thought i would share for anyone else that may find this post down the road.  I am getting about a 22ms round trip to read an input and update an output.  I was around 45ms before.  This may still not be technically proper the way I am setting and resetting coils after the FB but it is working and now it is not timer based so theoretically executing as fast as PLC scan-data transmission-device scan will allow.  

 

application details:  my plc scan is 2 ms for this application, I am reading 16 inputs and writing 8 outputs over standard CAT5 cable. 

 

1112.PNG

Share this post


Link to post
Share on other sites
3 minutes ago, LoganS said:

This may still not be technically proper the way I am setting and resetting coils after the FB

Nothing improper about this code. Congratulations on getting your cycle time down to 22ms.

  • Like 1

Share this post


Link to post
Share on other sites

FYI had to roll back my program to the older, slower version.  After a couple of hours the remote IO module would glitch out and stop responding giving no watch dog errors or anything.  Swapped all hardware with new to no avail.  Reverting program made the problem go away.  Makes no sense but figured I would share.  

Share this post


Link to post
Share on other sites

Logan, I thought about entering into this topic with some personal observations, but decided not to as it was running along quite well.

I've had instances of something similar when using a serial modbus line with quite a few slaves.  I'd lower the speed b/n calls until it became unstable, then back it off (hmmm "raise it up"?) until it all ran ok.  Would do other jobs around the site for the day and it would still be going fine on leaving.  A few days later it would fall over, and the cure was a slight increase in delay times.  I can only theorise that my initial time was running very close to not allowing the buffer to clear properly, and eventually the accumulated(ing) stuff reached a tipping point where it cracked the poops.  All the info being derived was always the same amount of transmission. 

Whether this can happen using TCP I don't know, but it does sound awfully familiar.  For me, buffers in Unitronics land sometimes pose issues that have to be allowed for.

cheers, Aus

  • Upvote 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...