Manual

Yes, for the most part. In our typical setup, the slave drives allow us to configure a custom telegram with all the data we want to read, so it happens in a single read. The one that I am having issues with, the customer wanted custom drives, so we're adapting to use those. Unfortunately, this drive doesn't have a way to setup a custom telegram, so we're reading from their standard locations. Normally I would just read one big block of data and selected what I need PLC side, but this drive limits each response to 64 bytes, so I can't get all the data I need. Any thoughts on the latching MBs? It seems so repetitive and wasteful, not to mention if you need to add more reads like we do in this case, you end up having to shift everything around and add even more MBs. I've been thinking about using an integer and incrementing each time to know which command/response set it's on and it would allow me to skip by incrementing in multiples rather than having all these MBs. For reference, here is what a single drive communication looks like, it takes 3 MBs to track. One for the status read, one for data, and one for the write. Now with this drive, I have to do 2, maybe 3 more reads, so it'll take 6 round trips with 6 MBs to track. Then just have rinse and repeat 7 times. I just feel like there should be a better way?

I've long been doing this for a large program that I maintain. Depending on the system, we communicate with 2-8 slaves. From each slave, we do a read coils, read holding registers, and preset holding registers. The number of slaves is also dynamic, since they could fail or be disconnected for maintenance. This has caused issues in the past since the functions timeout and retry, slowing down the whole loop. To resolve this, we short circuit if the first read operation fails for a slave, we skip the registers. In the end, our solution has basically been to use many latching MBs to round-robin through all the requests. We also short circuit if we know the particular setup will have less than 8 slaves. This ends up having a subroutine that has a bunch of rungs that all resemble each other, check a couple of MB to see if the previous request was successful/failed, run this one, set an MB for success/failure. At the end, we reset all MBs and start from the top. Is there a better way? How do you deal with having slaves that might be temporarily taken out so that it doesn't slow the communication down since it is sequential? It doesn't help that many slaves don't support more than 19200. Is going for MODBUS TCP the ideal solution here? One of the reasons I am seeking alternate solutions is that now we're running into slaves that we have to read from multiple times since the telegram has a size limit, so instead of doing 3 MODBUS functions per slave, we might have 5 or 6, and that just makes for some repetitive and slow loop through all slaves.