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

[Thiago A. Corrêa]

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