Not sure if this is the correct forum but I am trying to get a Samsung MIM-B19N (Nasa to Modbus bridge) running. The bridge is connected to a Modbus RTU-to-TCP Gateway and the PLC is approaching the Modbus TCP gateway.
I have communication and as well in a separate Modbus RTU program, as well as with my PLC.
Problem with the PLC is that it somehow only seems to be able to either only read holding registers or only write holding registers. If writing works, all read-only holding registers show up as 0 on the PLC. If reading works, the heat pump does not respond to writing registers.
All the time it is possible to read correct values using a separate modbus TCP app even when the PLC shows 0 values. Other way around; if the PLC is reading correct but not writing I am able to write using that same app.
Shutting down the app to eliminate the possibility of the app interfering with the PLC showed no change in behavior.
Refreshing interval is at 1s on the PLC. Siemens has their PLC programmed in such a way that at each refresh interval all holding registers are re-read and all to-be-written holding registers are written. Regardless if their values have changed or not, every second the whole set is written.
Does anyone have any experience how to troubleshoot this?
On an Intesis Modbus to NASA gateway I can just do it like below;
On the MIM-B19N I even experimented with all the read-only registers in 1 connection and all write registers in the otherâŚwithout satisfactory result.
What is the gap between modbus reads from the PLC? I had trouble when the inter-request gap was 10ms, upping the gap to 50ms seems to have been stable. The write requests have to wait for bus quiet times on the NASA side before they can be sent, they only occur every few seconds, so chances are you have filled up the Tx Q in the B19M and it has thrown a wobbly.
Personally, I would reduce it to reading one holding register, then writing one holding register. If that works up it to 2 until you find where it is breaking.
Well, that sounds like a recipe for wearing out the EEPROM, unless Samsung have coded some sort of intelligent write filter in their firmware so that values are only written if they have changed, to mitigate such stupidity.
Nothing to do with MIM-B19N or Modbus, but based on writing an unchanged FSV value to the EEPROM from SNET, it appears not. I see the same outgoing NASA packet on F1/F2 (apart from the payload) for an FSV write, irrespective of whether the value has changed. So it wouldnât surprise me if Samsung havenât error-trapped unnecessary writes via the B19N either.
The write filter would be buried deep in the firmware of the Micom, just before it actually physically writes to the EEPROM, so you may well see redundant writes on the NASA bus, question is does the Micom firmware just dumbly physically write the value.
To the extent that the MIM-E03EN immediately responds the same (unchanged) FSV value onto the NASA bus, it looks like it does just that (âdumbly writeâ):
[2026-04-16 11:41:29.421] [OUTGOING] (120 bytes): (100 x 0x55) 32 00 12 80 FF 00 20 00 00 C0 12 E5 01 42 56 02 08 5E AB 34
[2026-04-16 11:41:29.696] [INCOMING] (25 bytes): FD FD FD FD FE 32 00 12 20 00 00 80 FF 00 C0 15 E5 01 42 56 02 08 D6 74 34
Not sure you can deduce that from information available. Itâs likely there is a RAM based database in the Micom that buffers the values (cos EEPROM is real slow to access) and that values are only written to the EEPROM when they change (intelligent) or on every write (dumb). I have even worked on firmware (SMETS2 smart meters, shock, horror) where the data only gets written to the EEPROM periodically or on power fail (needs a big capacitor in the power supply).
But what is the timing between the first read and second read in the burst of 4 reads, and similarly the time between first write and second write in the burst of 3 writes?
I had naively assumed that the EEPROM stored the âmasterâ FSV values, and that the Micom routinely read from it for its parser calculations (and wrote to it if an FSV was changed, for example from the WRC via F3/F4 or from SNET via F1/F2.)
As you say it would make more sense (i.e. quicker) to operate the parser from a Micom RAM database that is initialised from EEPROM on start-up, and to write any FSV update to this database, only revising the EEPROM values periodically or (maybe) at shutdown to maximise its life.
But this begs the question: Would over-frequent Modbus calls result in âwearing out the EEPROMâ if â like SNET may be â they are only directly accessing the Micom RAM database?
If only we had the Micom parser code we (i.e. you ) might be able to disassemble it, then weâd know for sureâŚ
To be honest I donât have a clue how to time that but if you have a method that does not require me to buy expensive software or equipment I will be happy to try
I remembered that the current Intesis Modbus gateway I want to replace with the MIM-B19N has a log function for the Modbus data. Below is a snapshot of that data. Not sure if it accurately resembles timing of each read request in a âburst of readsâ but at least itâs better than nothing.
âscope job, so no way without relatively (300GBP) expensive equipment. So all I can suggest is you reduce it to a single read and write, if that works and the bursts donât then it probably is a timing issue. You could try reducing the baud rate to the lowest possible as that will artificially throttle the throughput.
It looks like all that comms is happening in the same millisecond, so the PLC is really hammering the Modbus, the Intesis can take it, the B19 canât. Does the PLC have a setting to control the minimum inter message gap? I would be surprised if it didnât.
It was quite a day of trying (and not-so-fast-thinking due to recovery from the flue) but I think I solved the issue. The trick is:
I made 3 separate Modbus connections:
Connection 1: Read a whole bunch of holding registers (about 60 even though I only need 4 or so at the moment) every 1.00 second
Connection 2: Write 1 set of 2 holding registers every 1.01 seconds
Connection 3: Write 1 set of 1 holding register every 1.02 seconds
This way I barely ever have an overlap and if I do it only happens for 1s. So far it seems that the system is slow enough to not cause an undesired stop of the heat pump.
I did not find a setting to set the intermessage gap @toadhall
Did quite the amount of searching and also had quite the discussion with Gemini AI but it seems to not be there.
Now I still have to find a way to add registers to the MIM-B19N. Modbus TCP returns âIllegal data adressâ as soon as I try to do anything with the 6000 series of holding registers.
) might be able to disassemble it, then weâd know for sureâŚ