Modbus TCP Slave

[micheledarold]

Hi @alejoseb , a question about modbusTCP slave mode, after receiveing a packet and processing it the connection is closed it's right? In this way the master should open the connection before each connection? But this mode is valid for a standard master?

Do you have a tools for PC useful for testing ?

Thank you

[manuel-pchr]

Hello @micheledarold, you are right, the ModbusTCP-Slave in this library closes the connection after it sent the response to a query from a master. I´ve worked with many different ModbusTCP devices and implementations and never encountered such a behaviour. The slave should never close the connection, only the master is allowed to do so.

For Testing i would recommend the following ModbusTCP-Master simulators: QModMaster Radzio! Modbus Master Simulator

[micheledarold]

hello @alejoseb so the modbus slave tcp is not usable in this implementation...

[alejoseb]

Hi @micheledarold , contrary to what @mpu0 said, the slave can close the connection under various circumstances. According to Modbus's official documentation, it is "recommended" to keep the connection open, but it is not mandatory. What is mandatory is that the master handles the disconnection from the slave. The master must handle the disconnection and reopen it when needed. If your master cannot handle the disconnection, then it is not Modbus compliant.

The connection management of this library can be improved to comply with the recommendation. I will do that when having some free time. Meanwhile, I will tag this issue as an enhancement.

Regarding this comment: "hello @alejoseb so the modbus slave tcp is not usable in this implementation..." you should read the documentation and then derive your own conclusions. https://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf

Do you have a tools for PC useful for testing ? I recommended a couple of tools in the Readme file of this library

[manuel-pchr]

Hi @alejoseb, i really like your library and i´m looking forward to this improvement! Thanks for your work.

[micheledarold]

Hi everybody and thank you for the improvment, I'm testing it but I have not found TCPTIMEOUT define used in netconn_set_recvtimeout in all code (also in the example) there are something missing when merging?

[alejoseb]

Yes some files were not included in the commit by mistake. It should be working by now.

[micheledarold]

Hi, thank you,

I suggest you to modify the netconn_close call, if you call netconn_closewith a parameter NULL the function return error so I think is better to call the close function only when the argument is not null

Michele

Il 02/11/2021 20:27, Alejandro Mera ha scritto:

Yes some files were not included in the commit by mistake. It should be working by now.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alejoseb/Modbus-STM32-HAL-FreeRTOS/issues/28#issuecomment-958100937, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACZ4RUEXLACNZ3GE7TOLTQLUKBCSZANCNFSM5EBZWTKA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

--

http://www.ecsproject.com/

Michele Da Rold

/R&D dpt/

ECS s.r.l. http://www.ecsproject.com/

Via dell'Artigianato 24 - 32100 Belluno

T. +39 0437 33101 | F. 0437 359631

LinkedIn https://www.linkedin.com/company/ecs-s-r-l-?trk=biz-companies-cym

[alejoseb]

Yes, Lwip handles that so it is not necessary, but I changed the code to avoid unnecessary error messages.