Modbus TCP FC3 act weirdly

Hello.
I’m trying to make a SW which will read lot of data from modbus server.
I made my own function block, which use MB_TCP_FC3_3 FB, but it acts very weirdly.
I want to do RHR on request, without any delay and only once. But for some reason, the MB_TCP FB always makes 3 requests and more, and the output xNDR is set to true after all these requests (which take together lot of time).
I attach export of my block and wireshark, where can be seen the communication from the PLC.
The MyModbusRHR block is called in state machine for different registers. Sample of code attached too.
Also I think that the description of input xActivate of MB_TCP block in help is misleading. It says „Rising edge: Activates the function block.“. In such case, making impulse on the input should be enough to activate the block for a one run. But when you set FALSE, the block is stopped immediately. So the input is level state, not rising edge…
Thank you
modbus.zip

modbus.zip

Hi!

                1. Where did you lost MB_TCP_CLient FB?
                2. You have to remove calls of MB_TCP_FC3 out from IF/CASE scopes. And operate only with MB_TCP_FC3 inputs and outputs in that scopes.

That is the first approach to improve operation behavior.
BR

Hi!
Thank you for reply.
You are right, I forgot the client FB in the example :smiley: I attach updated example including FB MyModbusClient.
I had already MB_TCP_FC3 FB call out of IF/CASE, so the FB was called each cycle of my FB, but the behavior was the same. What is the problem of having the FB call inside IF/CASE?
Thank you
modbus2.zip

modbus2.zip

All because some mess in your state machine.
Please find out simplified sample attached. There is no unwanted polls figure out.
PROPER_MB_TCP.zipAdapt to your servers ip and manually trigger MAN_POLL_REQUEST.
You have to organize your poll by triggering xActivate input of FC3. And make tUpdateTime greater than T#1s. You have to update wStartRegister and uiQuantity of registers wile xActive = FALSE, to ensure FC3 will properly process them later.
BR

PROPER_MB_TCP.zip

Thank you! I will check it out.
„And make tUpdateTime greater than T#1s“ - But this means, that I will not be able to make faster request then 1s, or not? Because that wouldn’t be acceptable.

It will make polls as soon, as possible in case of operation with FC3.xActivate.

Hello
I tried your FB, it looks working as it should. But the one read cycle between 2 queries takes around 700ms.
What I tested, the MB_TCP block needs at least 5 cycles to operate. Only solution for this is probably using faster cycle task (I tried 10ms cycle just for test and it looks working fine, 80ms between each read). I tested it with modbus server simulator which has response time < 20ms.
I rewrote the MyModbusRHR block and now it looks also working fine. I found out, that for resetting the tUpdateTime, full cycle is necessary.
Thank you for your help!

Hi
Also you can try several FC3 blocks, joined in queue via iMT_ID.
Probably it can reduce several cycles too…
BR