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

Thu Jul 17 19:59:50 CEST 2014

Hi Thiago!

If I'm not mistaken, the collision resolution mechanism with the random
delays only kicks in if there is a hardware collision on the bus, i.e.
two drivers active at the same time. This can't happen in a switched
network, as there are only point-to-point connections with full duplex
capability. At least in 10BASE-T and faster, but I've never seen a coax
network installation in the last years. A switch could probably actively
generate a collision when it can't handle the received data, but that
would seem stupid to me. Just dropping an undeliverable frame should be
the easiest and safest way.

Consider this case: We have machines A, B and C, all connected through a
switch. Now A sends a frame to C, so the switch forwards the data from A
to C. During the transmission of this frame, B starts to send data to C
as well. I'd now expect the switch to receive and buffer the frame from
B until it finished transmitting the frame from A. If A then continues
sending, it would buffer that frame from A and transmit it afterwards.
Eventually it would then run out of buffer space in which case I would
expect it to simply drop the incoming frames. Generating a collision
condition would not help in any way, this might even destroy data that
could otherwise be delivered without problems. The same holds for
broadcasts as well, as there is no problem to forward a broadcast from A
to B and C while B is sending (full duplex connection).
Or do I miss something?

Thanks,
Philipp

On 16.07.2014 22:32, Thiago A. Corrêa wrote:
> Hi,
> 
>      From those you listed I'm only familiar with modbus and have
> investigated EtherCAT, so you might be right about Profinet.
> 
>      Switches should behave like hubs if their address table is full,
> and there are broadcasts as well, so collisions can occur in switched
> environments too.
> 
> Kind Regards,
>      Thiago A. Correa
> 
> 
> On Wed, Jul 16, 2014 at 5:16 PM, Philipp Burch <phip at hb9etc.ch> wrote:
>> 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
>>>
>>
>>
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> 