[En-Nut-Discussion] Industrial interfaces (Modbus TCP, Profinet, etc.)

Thiago A. Corrêa thiago.correa at gmail.com
Wed Jul 16 21:50:45 CEST 2014


Hi Philipp,

     TCP adds checksum to all packets and handles retransmissions. If
the client for some reason sends bogus data, then it must have wanted
to send bogus data, it can not be a transmission problem. The layers
bellow the application layer are responsible to give you guaranteed
consistent and in order deliveries, or a connection failure. There are
no guarantees on sizes for each read, so as you noticed, many
protocols implement a state machine (TCP included).

     Those industrial ethernet protocols usually implement something
in the link layer to get some timming guarantees because normal
Ethernet will wait a random amount of time in case of collisions. So,
there is usually some hardware differences in those, you can't
implement them purely in software AFAIK, your hardware must have
support for them.

Kind Regards,
     Thiago A. Correa





On Wed, Jul 16, 2014 at 4:36 PM, Philipp Burch <phip at hb9etc.ch> wrote:
> Hi JP!
>
> I've just had a look at some of the Modbus docs. Seems like this indeed
> is almost trivial to implement... What I'm unsure about, however, is the
> fact that the protocol uses a packet-based approach over a stream
> oriented channel (TCP). As long as the messages are short and have a
> substantial amount of time between them, this should be no problem. The
> socket will just happily pass every message up to the application as a
> single unit. But what happens if multiple messages end up in a single
> frame and, hence, are passed to the application in a single read
> operation? Or, even worse, if a message gets split into different reads?
> It can be solved with a statemachine on the receiver side as long as
> there is not a single error in any of the packets, but what if the
> client sends bogus data for any reason? I don't see a way for the server
> to ever resynchronize (or detect the mismatch at least) unless the
> client terminates and reestablishes the connection. Am I overlooking
> something, or is it really that simple? Wouldn't look too robust to me...
>
> Regards,
> Philipp
>
> On 16.07.2014 20:55, JP Merle wrote:
>> I've made a program in order to drive a motor using modbus tcp. It was not for industrial purpose, but only for demonstration of CIM concept in a school. I had no original code, so I had to write my own
>>
>> Sent from my iPhone
>>
>>> On Jul 16, 2014, at 8:31 PM, Philipp Burch <phip at hb9etc.ch> wrote:
>>>
>>> Hi everyone,
>>>
>>> I'd like to ask if anyone of you has experience with integrating
>>> Ethernut-driven devices in industrial networks based on Ethernet.
>>> Sometime in the near future, we will need to implement some standardized
>>> industrial interface in one of our devices, such as Modbus TCP or
>>> Profinet. Does someone already have such code at hand by chance? I'm not
>>> concerned about Modbus TCP, this should be fairly simple to implement.
>>> But as far as I understand Profinet, this works below the transport
>>> layer, i.e. it does not (only) use TCP or UDP, but something different.
>>> Or are there other popular interfaces that could be a good choice? We do
>>> have an FPGA on that device, but I'd prefer to do the network stuff only
>>> in the microcontroller, so EtherCAT is not really an option.
>>>
>>> Thank you!
>>>
>>> Best regards,
>>> Philipp
>>> _______________________________________________
>>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion


More information about the En-Nut-Discussion mailing list