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

[Philipp Burch]

Hi Thiago,

thanks for your response. TCP clearly provides a very reliable channel,
but "if bogus data, then intentionally" sounds a bit too easy. Anyway,
if that's the way to go, then ok, makes life easier. Can't be too bad if
everyone's doing it this way.

As far as I know, hubs aren't used anymore for Ethernet, so there should
be no possibility for hardware collisions. A switch might start to drop
packets if it can't transmit them fast enough (probably because two NICs
are sending data in full speed to a single third one), but this should
not happen in an automation application usually. As far as I understand
Profinet, they use TCP/IP for some tasks, different transport (or even
link-layer) protocols for other, but everything in standard Ethernet
frames. So there should be no need for special hardware for that. I
haven't found a real in-depth documentation of the whole Profinet stuff
however, so probably I'm wrong.

Kind regards,
Philipp

On 16.07.2014 21:50, Thiago A. Corrêa wrote:
> 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
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>