I am having a big problem with Modbus RTU using operation code 3 to a "chinese" IO board. Before I begin let me add that I have connected an IOT2040 running Codesys and had no problem with bi-directional communication. I was even in discussions with tech support at my Siemens distributor and they were at a loss after back and forth communication all day. So anyway here is the problem.

The Modbus master block I am using is v3.0 (Instruction 3.1). The board I have supports Modbus codes 3,6, and 16 (Read Holding register, Write holding register, Write multiple holding registers). For this discussion I limit it to code 3 and 16 as this was what worked flawlessly with Codesys.

First the "Write registers" (code 16). Here I load MODE=2, DATA_ADDR=40113, DATA_LEN=1. The write is performed flawlessly (no error, and requested outputs on). One thing of note. The data sheet for the board lists the address as 112-114. However I do know that some Modbus masters need an offset of 1. In fact if I do use 112 then my error is invalid register address.

Now the problem with reading the boards inputs. Here is loaded MODE=0, DATA_ADDR=40193, DATA_LEN=1. I have inputs hard wired on. I execute the request. The request executes without error. In my code I have even set a "trap" to make sure any returned data is not being flushed immediately out of the received data. For this I have "<data pointer destination>" <> 0 then move data to MW300. Even with this there is not any data returned nor is an error presented from the master.

Let me reitterate that this code worked flawlessly in Codesys even at a 10ms scan time over two separate Modbus slaves (2 slaves 1 input, one output register each). The only thing different is that Codesys did not require the 1 offset. Therefore it was set as CODE=3, ADDRESS=0x00C0 (192) CYCLIC_SCAN=10mS.

Does anybody have any clues how I can make the read happen on my S7-1212 with CB1241?

Edit: 2/18/23 11:32:

I changed out my Modbus RTU function blocks from v3.1 to v2.1. No difference in the issue. However I did do something else new.

I added a tap into the RS-485 line and watched the actual packets online. What showed up is as follows: 01 03 00 C0 00 01 84 36   00 00 01 03 02 00 02 39 85.

01 03 00 C0 00 01 84 36 corresponds to a perfectly formed request packet. 01 03 02 00 02 39 85 seems to conform with a perfectly formed response packet. 01-Slave number, 03-Command code, 02-number of 8 bit values in response according to Wikipedia, 00-high byte, 02-input value 39 85-CRC. Fot the input values I powered first input 2 (0-7) and received 04. Then I changed the input to 1 (again 0-7). As you see the response was 02 (input 1). 

The only thing Im not quite sure of is the two empty bytes leading the response. Apart from that it is the perfect Modbus RTU send and receive telegrams but Siemens is not writing it to the output of the call, rather it seems to simply drop the data.

Now I tried to Write the registers (WHICH WORKS) and had the following data out:

01 10 00 70 00 01 02 00 07 EC A2 Response: 00 00 01 10 00 70 00 01 00 12. On the output of the slave bits 0,1,2 are TRUE physically.

Actual sniffed Modbus data stream:

01 03 00 C0 00 01 84 36   00 00 01 03 02 00 02 39 85.

Master poll: 01 03 00 C0 00 01 84 36 interpreted as

Slave #1, execute FC 03 starting at Holding register 0x00C0 return 1 register's data, CRC

The valid reply should be 01 03 02 00 02 39 85 interpreted as: I'm slave #1 replying to FC03 (read Holding register data), with 2 bytes with the value 00 02, CRC

The actual reply is 00 00 01 03 02 00 02 39 85 which is interpreted as

Slave #0 (all slaves listen, this is a broadcast command from a master), execute FC00 (which doesn't exist); the rest is garbage since there's no protocol for a non-existent Function Code 00.

No wonder the master doesn't do anything. It's not a slave expecting to execute a broadcast command.

The question is where do the  extra bytes come from?  I honestly don't know if a noise spike looking like a start bit starts the receiver UART counting, whether the lack of noise after the fake start bit shows up as zeroes or ones. 

Further, it appears that you can read the slave with the IOT2040 as a Modbus RTU master, correct?  If you sniff the traffic when IOT2040 is the master, do the extra 00 00 bytes show up?   I can't imagine they do or the IOT2040 would not pay attention either.

I'm stumped, too.

What an interesting problem! I assume you are currently using an S7-1200, deducing from the Modbus RTU versions you are talking of. Stating the full description of what you are testing with would be an advantage.

Extracting some more of the communication strings would be helpful to experts like Mr Dan. It seems as though the sending works correctly, but the receiving does not (Siemens master side). Can you confirm that NULL characters are always added? Perhaps the NULL characters can be filtered out.

This I am guessing, as the Modbus RTU (software) configurations may over write these settings. Consider creating a "Support Request" in parallel to this topic. Having more raw data strings may be of value.

(ADD) Confirming that the same text string pattern leaves/arrives on the working IOT, would be most educational.

Good luck!

Hello,

to me, I recommend check that Chinese board with PC MB RTU application over serial line and check if some same 00 lead bytes are there. If yes then I expect firmware problem of that Chinese board. If not, problem can be with that IOT driver incorporation???? Really I don't understand what things were happened on that IOT as Siemens block functionality. My idea is simple, clearly differ PLC problem or Slave board malfunction, in this case PC app is that case. Simply, your requests/send are accepted by Slave but returned message is wrong due possible firmware problems. Here you can do also different, disconenct Chinese board and attach PC MB Slave application sim and start ask from IOT to PC app. If all is ok, also no 00 bytes there with response, IOT driver is ok and definitelly Chinese board malfunction.

Sry if I missunderstanded your IOT or S7-1200, my tips are same for also S7-1200 tests. Hope that comm settings on S7-1200 PLC you have same as Chinese board has, speed, parity, only for sure.

It could be that the card is not detecting the end of the message frame correctly and performing read of a idle bus.

In PCS7 with a serial card (e.g. CP441, CP341), you can have configure several ways to detect the end of the message frame.

1. On expiry of character delay time - This deems the message frame end as a gap in the data stream of t time.
2. On receipt of fixed number of characters - This deems the message frame end as after a specified number of characters has been received.
3. On receipt of end characters - This deems the message frame end as the receiving a particular character(s). I.e end demarcation characters.

Now for Modbus RTU, option 3 is out as they are no end of frame markers and option 2 is out as the data packets are not fixed sizes.

So that leaves option 1. For Modbus, the end of the message is deemed as a gap of 3.5 character times. To calculate this, first you need to know you character size in bits. You get this by summing the number of start bits, data bits, stop bits, and optional parity bits. E.G. For 1 start bit, 8 data bits, 1 stop bit, and no parity bit = 1 + 8 + 1 + 0 = 10 bits.
Now calculate 1 byte time =  1 / (baudrate / character size) = 1 / (19200 / 10) =  0.52ms.
Now calculate 3.5 character time = 3.5 * 0.52 = 1.82ms.
Round this up to the nearest whole ms = 2ms.

I ave attached the serial configuration setting screen example. I am not sure if you are using TIA or PCS7. In TIA there may be another way of setting this up.

Good luck, and I hope this helps.

Is a USB/RS-485 converter involved?   Some converters have been found to insert a 00 character preceding the slave reply.

There is the possibility of outright bad firmware in the slave that outputs null characters for reasons likely unknown to whomever it was that programmed it.   But, why would the slave work with a one master and not another?   Why would it output a couple null characters when connected to one device but not when connected to another device.

If the null characters are not generated by the slave, then there must be a start bit on the network because the start bit is what starts the bit timer in the master's UART that looks for the bit state at about the middle of the period of each bit.

So where can a false start bit come from?
- malfunctioning USB-485 converter (bad firmware, reported on another forum)
- Reflection(s) from transmission line impedance mismatch - the reflected energy that termination resistors are supposed to absorb.
- EMF noise induced on the transmission cable
- momentary ground fault shifts the signal reference ground to produce what looks like a start bit
- lack of biasing the drive lines to 5V and signal ground

Reflection noise
Although I've seen termination only needed at higher baud rates and longer transmiission cables, it is a possibility.

Is the cable typical 120 Ohm impedance cable?   Is a termination resistor installed at the slave end?
Can the master's termination be turned on or off, enabled or disabled?

EMF noise
Is the testing being done on a bench with less than 3 m of cable, or in the field with hundreds of meters of cable running past VFD's?

Is the cable shielded twisted pair?  Profibus started grounding both ends of the shield, but Profibus assumes an 'equipotential' ground plane.   I come from the ground one end of the shield school.

Is the 485 signal ground on the slave the same as chassis earth ground? (ohm it out)

Is the cable not running with high voltage, high current power cabling?

Lack of Biasing
Opto 22's note on RS-485 biasing says, "When the line is floating in the tri-state mode, noise on the line can falsely trigger a receiver. To ensure that the RS-485 line is in a defined state when all transmitters are off, we can use failsafe biasing on the line."
https://blog.opto22.com/optoblog/rs-485-to-terminate-bias-or-both

The failsafe biasing is accomplished by the connection from the 485 driver lines to a pull-up resistor to the RS-485 5V supply line and a pull-down resistor to the DC common/ground.

Profibus DP runs on a RS-485 port and its biasing resistors are located in the DB9 connector.  The trick is to have the mating DB9 connector make the connections from the pull-up/pull-down resistors on the driver lines to the 5V Vcc supply and common/ground.  The Vcc and ground connections on the vast majority of RS-485 ports are not brought out for public access connections.  Profibus was designed from the ground up so they took biasing into account.

Lunar phase
If the regular things check out and the slave does not send null characters with the IOT2040, then I'd invoke my Shaman solution: an RS-485 repeater/isolator at the slave, just to see if the situation changes, and if it doesn't, add an isolator at master.   Sometimes an isolator or two make the network work.
 

Well, I am at the "phase of the moon" option. This test was conducted with the v3x Modbus RTU libraries. I seem to have lost the leading double nulls 0x00 0x00. Now however I cannot even write the outputs. What follows is the result of the RS-485 "tap"

As before the IOT2040 w/ Codesys works fast and perfectly. Read register Codesys, 01 03 00 C0 00 01 84 36  Response 01 03 02 00 04 B9 87. This is with Bit 4 set.

Write register bit 4, 01 10 00 70 00 01 02 00 04 AC A3 Response 01 10 00 70 00 01 00 12

Now the 1200 with the CB and v3 modbus blocks. Read Register, 01 03 00 C0 00 01 84 36. Response 01 03 02 00 04 B9 87. This all seems good but there is no output at the block interface.

Write register 0x07 (First 3 bits on), 01 10 00 70 00 01 02 00 00 AD 60. Response 01 10 00 70 00 01 00 12. As you can see Im no longer even turning the outputs on.

Now I changed my blocks version back to 2.0. First thing is the 00 00 came back. With this, in the hardware config I set the "start of message to 00 00. Now I sent a read, 01 03 00 C0 00 01 84 36. Response 01 03 02 00 04 B9 87. I quadruple checked and everything is the same each time. There is no output to the data block though.

The write is same as above parameters. Packet sent 01 10 00 70 00 01 02 00 07 EC A2. Response 01 10 00 70 00 01 00 12. My outputs are now on as commanded (first 3 bits).

Corruption of the v3x blocks is about the only conclusion I myself can come to at this point. I just dont know how to get this corrected.

As for the v2x blocks writing is the only thing that works properly. To the best of my knowledge, everything looks right on the line tap. Its just not output to the block interface. Even if ignoring the "DONE" bit of the block and just going by <receive register> <> 0 doesnt give me anything out even when the incoming telegram indicates the third bit should be on (16#04).

The Codesys telegrams are identical to the 1200 telegrams. Codesys however performs flawlessly, fast and easy. Siemens however drops the ball.

My next attempt will be through a Modbus RTU to Modbus TCP gateway into Siemens.