Modbus TCP Master Limitation

I just checked and it seems that it is possible to configure generic TCP output in iba. You can map basically any signal to the output from the configured input signals. Going this way the architecture does get a little messy, but if the license supports it, wouldn't require any new hardware.

I will be testing this next week if I have time, I can post update on how it went if you would like.

Do you only need read from device or also write setpoints via modbus.
If you need only read data, then small PLC between would be alternative.
If you need also write data from both masters, then programming goes messy as you need also read setpoints to another master if they are changed form other and only write from newest changes.

Thank you so much everyone for all the support and alternatives. I spent quite some time now going through all the options and they all seem to exist along the same price points. From field device, gateway, micro PLC and alternate direct manufacturer devices from Waukee, they all run about $500-700.

Project Managers ended up requesting alarming; audible and notification for each furnace location. As a result, I figured my easiest path to solve both issues is some audible IFM buzzers, a small 1215C Siemens micro controller and pulling the alarm data to the Proface screen. At the same time I can pull the Waukee single TCP master signal to the Siemens Micro PLC and then have all the other masters get the data from that acquisition since it's real time in the human eye sense. Kills two birds with one stone or so they say.

I have however logged a lot of data devices discovered from this conversation I haven't utilized before and may come into play in the future. One thing I don't seem to see an answer to regarding Modbus Gateways is whether it acts as a single broker (acting TCP master) for dual masters behind it (essentially whether it stacks requests and ensures the single device is only one transaction for the limitation) or whether it's still a switch that suffers the same problem and is only really meant to convert real serial pin to Ethernet. The device catalogs don't seem to specify how the architecture exactly works for that interface exchange unless it's obvious and I just don't know because I haven't needed to use one before (due mostly to modern PLC circuits everywhere in my building).

Thank you everyone, it has helped out a lot!

I hope I speak for the forum when I say thank you for the feedback.

Sounds like a great choice: in your wheelhouse so implementation and development time is minimal; kills a second bird (and maybe more down the road).

Well done.

just one more thought.
It all comes down to the slowest device as the bottle-neck.
i.e. modbus serial = one msg at a time.
In my case it is 19.2k baud. I know newer devices can speak at a faster baud rate.
So master msg + transmission rate + latency + reply rate + latency and repeat.
In my plcs (both the M340 and Wago) it is aprox 50ms.

Hi Ganutenator,

Yes, good consideration. I think it would still be acceptable real time given the furnace operation running so slow as is but that reasoning is also the same reason I chose not to use the IBA data logger as any form of OPC UA or forwarding services because the output has a 50ms delay to process any information packets outward to the next device and it starts to add up. It further pointed me toward the Siemens micro controller operating at microseconds and letting the TCP Masters continue to request as I felt that was the quickest path to victory or best bang for the buck as they say given their price range.

Always a million ways to butter your bread with these things lol.