Modbus - How would you do it?

Puddle · Jul 12, 2022

I've been working on a project that requires communication with 40 temperature controllers over modbus RTU. I'm using a Siemens S7-1211 (asked for a 1214 but... lead times) and a KTP400 basic HMI.

The Siemens literature says I can have as many MB_MASTER blocks as I like, but as they have to be linked to the COMM_LOAD block this doesn't seem to strictly be true.

I've ended up with a huge program where the master executes, moves the data out, moves new settings to the master and does it again. I need to read two registers and write two registers so I have to run the master a lot. Once I've added in some error handling, the ability to disable unused controllers and few other bits, it's ended up taking around 80% of the work memory.

As I've been copying and pasting the same string of logic 160 times and using over 1000 tags I can't help but feel that there's a smarter way to be doing this. It's working fine and doing everything it should, but any changes take lots of copy and paste.

Time to learn STL?

goghie · Jul 12, 2022

Just to note that there is 32 device limit on one network due to hardware limits of integrated chips (RS485).
Also with that many devices network update time is very slow.

Puddle · Jul 12, 2022

I should have mentioned, I know about the limit and I've got the program split up and running two seperate communication modules. 20 devices each.

I think the response time will be looking around 20-30 seconds per loop. I had to put in a slight delay of around 25ms after the 'done' signal activates too because otherwise it throws up 'port busy' errors.

The end goal is just to send an alarm signal, so 30 seconds should be fine.

parky · Jul 12, 2022

Could you not use a ring counter to generate the the controller address, decode the return address & indirectly point it to the relevant variables, years since I did Modbus, but did similar system to 10 temperature controllers so the sequencer polls through the controller addresses, sends the commands, waits for the response (also allow for x re-tries or timeout) move on, when valid data comes back use a simple algorithm to generate a pointer to update the returned values.

Puddle · Jul 12, 2022

parky said:
Could you not use a ring counter to generate the the controller address, decode the return address & indirectly point it to the relevant variables, years since I did Modbus, but did similar system to 10 temperature controllers so the sequencer polls through the controller addresses, sends the commands, waits for the response (also allow for x re-tries or timeout) move on, when valid data comes back use a simple algorithm to generate a pointer to update the returned values.

That would be much more simple. I'd only need to have four sequences running and just change address for each cycle.
I could actually do that with my current method now that I'm thinking it through, but unless there's any serious issues I intend to leave the program as it is, but I thought I'd ask for inspiration in case I have to do something like this again.

parky · Jul 12, 2022

Yes it makes sense, no reason to mess with something that works, indirect is definitely the way to go in future, less code to write, once tested just requires the number of nodes to scan.

L D[AR2P#0.0] · Jul 12, 2022

Puddle said:
I've been working on a project that requires communication with 40 temperature controllers over modbus RTU. I'm using a Siemens S7-1211 (asked for a 1214 but... lead times) and a KTP400 basic HMI.

The Siemens literature says I can have as many MB_MASTER blocks as I like, but as they have to be linked to the COMM_LOAD block this doesn't seem to strictly be true.

I've ended up with a huge program where the master executes, moves the data out, moves new settings to the master and does it again. I need to read two registers and write two registers so I have to run the master a lot. Once I've added in some error handling, the ability to disable unused controllers and few other bits, it's ended up taking around 80% of the work memory.

As I've been copying and pasting the same string of logic 160 times and using over 1000 tags I can't help but feel that there's a smarter way to be doing this. It's working fine and doing everything it should, but any changes take lots of copy and paste.

Time to learn STL?

STL not supported in the S7-1200 processors. Did you mean SCL? - in which case arrays will assist, no need for indirect addressing.

jschulze · Jul 12, 2022

goghie said:
Just to note that there is 32 device limit on one network due to hardware limits of integrated chips (RS485).

This is a common misconception. The RS-485 limit is 32 Unit Loads. Historically, most RS-485 devices were 1 Unit Load, so 1 Device = 1 Unit Load. However, modern RS-485 transceivers are a fraction of a Unit Load, such as 1/4, 1/8, 1/10, etc. Therefore, with 1/8 Unit Load devices, for example, you can actually have up to 256 devices on one RS-485 bus (assuming the protocol used can logically support all of those addresses - note that Modbus RTU is limited to addresses 1 - 247).

cardosocea · Jul 12, 2022

Wouldn't an array of UDT's (particularly now that you have the code written) solve this problem for you?

The array bit would help with the scheduling of comms as well.

Siemens had an example for a comms scheduler in their TCP block library that could be used for this too.

Puddle · Jul 13, 2022

L D[AR2 said:
STL not supported in the S7-1200 processors. Did you mean SCL? - in which case arrays will assist, no need for indirect addressing.

Might have got those confused. Told you I didn't know about it.

jschulze said:
This is a common misconception. The RS-485 limit is 32 Unit Loads. Historically, most RS-485 devices were 1 Unit Load, so 1 Device = 1 Unit Load. However, modern RS-485 transceivers are a fraction of a Unit Load, such as 1/4, 1/8, 1/10, etc. Therefore, with 1/8 Unit Load devices, for example, you can actually have up to 256 devices on one RS-485 bus (assuming the protocol used can logically support all of those addresses - note that Modbus RTU is limited to addresses 1 - 247).

I haven't read anything about that, but the manual for the controllers says a maximum of 30 devices on a loop.

cardosocea said:
Wouldn't an array of UDT's (particularly now that you have the code written) solve this problem for you?

The array bit would help with the scheduling of comms as well.

Siemens had an example for a comms scheduler in their TCP block library that could be used for this too.

I'll have to see if I can find that example, it might help me in future.

cardosocea · Jul 13, 2022

Puddle said:
I'll have to see if I can find that example, it might help me in future.

This is similar to what I was thinking, but it only has a single trigger.

https://support.industry.siemens.co...munication-blocks-fc5-and-fc6-?dti=0&lc=en-WW

You can however use the logic for the trigger to increment your variable. You do need to look at your timeouts in order not to block all communications though.

Puddle · Jul 13, 2022

cardosocea said:
You do need to look at your timeouts in order not to block all communications though.

I was hoping there would be a function somewhere that shows the port is busy, but I can't see a way of doing it.

drbitboy · Jul 13, 2022

Puddle said:
I was hoping there would be a function somewhere that shows the port is busy, but I can't see a way of doing it.

The MB_MASTER instruction has a [Busy] output; is that not what you are looking for?

Puddle · Jul 13, 2022

drbitboy said:
The MB_MASTER instruction has a [Busy] output; is that not what you are looking for?

Doesn't seem to be. The master will show busy, then done as it executes. I was using the done signal to trigger the next step in the sequence but kept getting the 8200 error which is "Port is busy processing a send request" which is why I put in a 25ms delay. It's not the right way of doing it as it's theoretically possible for the port to still be busy after 25ms and the program cycle is only around 7-8ms so I've probably slowed it down more than I should have.

drbitboy · Jul 13, 2022

The need for the wait is not too surprising. Modbus requires 3.5 characters between frames (see below; I don't know what your baud rate is; at 9600 that would be 3-4ms). I would expect that to be built into the instruction, but who knows.

Maybe you are already doing this, but you might want to monitor the ERROR output bit, in addition to the DONE output bit, to trigger the next step.

Modbus - How would you do it?

Puddle

Member

goghie

Lifetime Supporting Member

Puddle

Member

parky

Member

Puddle

Member

parky

Member

L D[AR2P#0.0]

Lifetime Supporting Member

jschulze

Member

cardosocea

Member

Puddle

Member

cardosocea

Member

Puddle

Member

drbitboy

Lifetime Supporting Member

Puddle

Member

drbitboy

Lifetime Supporting Member

Similar Topics