MODBUS RTU Feature

[JimBesselman]

Is there, or can there be, a way for the Do-more serial port behave as a Modbus RTU Slave but still use the MRX and MWX instructions. Once I select Modbus RTU Server in the configuration MRX and MWX can no longer access the device. Our use case is using Modbus RTU over radio. We currently use the Clicks and other PLCs in this manner. I know this can be done by configuring the serial port for Program Control and using the STREAMIN/OUT type instructions, but I'm hoping for an easier way.

[BobO]

Is there, or can there be, a way for the Do-more serial port behave as a Modbus RTU Slave but still use the MRX and MWX instructions. Once I select Modbus RTU Server in the configuration MRX and MWX can no longer access the device. Our use case is using Modbus RTU over radio. We currently use the Clicks and other PLCs in this manner. I know this can be done by configuring the serial port for Program Control and using the STREAMIN/OUT type instructions, but I'm hoping for an easier way.

Sorry, no. The device-centric architecture makes this challenging.

Is the PLC's role changing from master to slave during normal use?

[JimBesselman]

BobO;

The PLCs role is actually both. We are essentially building a report by exception peer to peer network using the Modbus protocol. Our use is controlling tanks and pump stations with monitoring and recording by a plant site. The pump stations report status changes to the plant as they occur and the tanks report their levels to one or more pump stations. Some of this can be done with a polling method but at some point every site has to send a heartbeat. Our customers like the almost instant updates they get with this method.

All we really need is the protocol to be separated from the device, basically just stream in and out Modbus. I'm sure it's easier to say than to do! While I'm wishing, at some point we'll probably have to use some sort of encryption as people are starting to ask about it.

We love the product and look forward to the ongoing evolution.

[BobO]

BobO;

The PLCs role is actually both. We are essentially building a report by exception peer to peer network using the Modbus protocol. Our use is controlling tanks and pump stations with monitoring and recording by a plant site. The pump stations report status changes to the plant as they occur and the tanks report their levels to one or more pump stations. Some of this can be done with a polling method but at some point every site has to send a heartbeat. Our customers like the almost instant updates they get with this method.

All we really need is the protocol to be separated from the device, basically just stream in and out Modbus. I'm sure it's easier to say than to do! While I'm wishing, at some point we'll probably have to use some sort of encryption as people are starting to ask about it.

We love the product and look forward to the ongoing evolution.

I assume the network is RS485? How do you manage role changes and collisions?

In terms of rolling your own, Modbus is pretty simple if you can make certain assumptions. Do-more program blocks and stages make it almost painless to build custom clients and server, and it supports the required CRC16 through the CHECKSUM instruction (just be sure to pass -1 as the initial value).

[Evilbeard]

BobO, would peerlink be a possible solution to this? I'm just going over it in my head.

[JimBesselman]

Actually the network is radio, but it basically functions as if it were RS-485. Collisions are managed via a timer. The radio modem can hold off transmission if the channel is busy but we usually don't use this feature because interference can prevent a transmission that should occur. We seem to get better performance by letting collisions occur and just using the timed retry. An unsuccessful MRX or MWX starts a timer, when the timer is done a retry occurs. Sort of a crude version of the collision avoidance with Ethernet. Each PLC just listens on it com port, if a Modbus message is received with the proper address the PLC responds, otherwise it ignores the message. If the PLC needs to send an update it just sends the Modbus message and the appropriate listener responds. We can actually mix protocols using this method. There is at one protocol we use that is similar to Modbus but handles more datatypes and has provisions for routing messages. I'm working on doing this with the Do-more. I've gotten as far as having the Do-more receive the packets, next I've got to assemble the packets for transmission.

Are there any plans for high level add on modules supporting additional programming languages?

[BobO]

Are there any plans for high level add on modules supporting additional programming languages?

We've talked about doing a media module that would run an OS suitable for running user code, but it isn't a high priority. The WinPLC was an experiment in that vein and it wasn't as successful as we hoped. Products like that tend to become cult favorites, greatly loved by a small group. For at least the next couple years, Host will be focusing on products that can be successful in a larger market.

[JimBesselman]

That makes perfect sense. With the existing features of the Do-more it's easy enough to just make an Ethernet connection to any of the plethora of low cost Linux SBCs to use other languages when it's appropriate.

[BobO]

That makes perfect sense. With the existing features of the Do-more it's easy enough to just make an Ethernet connection to any of the plethora of low cost Linux SBCs to use other languages when it's appropriate.

Absolutely...for the folks skilled enough to use the Linux SBC to start with.

A big revelation for us at Host (with some guidance from ADC's company captain) is that we have historically been more focused on higher tech products that serve a fairly small part of ADC's market. This has limited our ability to grow. BRX is the first of several products intended to shift us toward the meaty part of the their market. If it works as expected, it will allow us to grow considerably, giving us even more resources for product development. The funny part is that if successful, we'll be in a better position to do the higher tech products than we were when we focused on them.