CANBUS Tx/Rx with data length > 8 bytes

Hans-Bernhard Bröker wrote:
> Am 30.11.2015 um 03:29 schrieb Tim Wescott:
>
>> We reduced the
>> wiring harness by more than a factor of two because of all the low-
>> frequency, formerly analog signals that were all put onto CAN.
>
> ... which is of course exactly the kind of application CAN was
> originally designed for.
>
> The late 80s and early 90s saw the use electronics in luxury cars grow
> at a rate that in the foreseeable future the sheer weight of all the
> cables, let alone the complexity of the cable harness, would have become
> untenable.  Mercedes-Benz was among the first to see they would run into
> this limitation in their "S" line, and so they asked Bosch for a
> solution.  The result was CAN: instead of an n:m distribution tree, one
> signal per wire, you run them all on a single pair of wires, strung run
> once around the entire thing.
>
> Cars have since outgrown this scheme quite a bit, both in the absolute
> number of signals and the timing they need.  That's why most current
> models have more than 1 cAN network, with a central gateway to
> cross-connect data that is needed on more than one network.
>
> To get back to what others have suggested here: keep in mind that CAN
> has one major advantage over shared-medium Ethernet (e.g. 10base2): its
> collision handling is a whole lot friendlier.

It is; absolutely.

>  CSMA/CD really sucks if
> bus load ever goes above ca. 20%.

The figure I'm used to is more like 40% for a passive hub. It depends
entirely on how sensitive you are to collisions,

> CSMA/CR still works quite well at 70%.
>
> If you want that Ethernet to offer latencies in the range that 1Mbit/s
> CAN does (~100 microseconds maximum frame duration), the Ethernet frames
> have to be quite short (~128 Bytes), and that, in turn, will hurt your
> usable bandwidth.
>

If you can get the bitrate up to 100 MBit, then it's probably worth it.

> Those would make it quite a challenge for a 10base2 Ethernet to actually
> outperform a 1MBit/s CAN bus in terms of effectively usable bandwidth.


The cabling for CAN is pretty nice.

-- 
Les Cargill

On 01.12.2015 г. 07:37, Les Cargill wrote:
> Dimiter_Popoff wrote:
>> On 30.11.2015 г. 02:53, upsidedown@downunder.com wrote:
> <snip>
>>
>> It will take a while until we see MCU-s with an on chip PHY similar to
>> the DP8392...
>>
>
> You can't really shrink the magnetics.  .....

Well not much anyway. They used to come in a DPI14 (or was it 16)
back in 1992 when I designed them into the first Nukeman...
At the cost of some elevation perhaps the footprint could be
halved, this being just a guess really.

Preserving the galvanic isolation would be beneficial in medium
sized environments where such an interface would be useful.
  Then I am not suggesting this could be a CAN replacement, apparently
CAN is meant for lower level/closer range communication. I am
not familiar with it, back in 1992-a on that same Nukeman
design I would have used it had it been available. As it was
not - not widely at least - I defined an SPI based link, system
to each slot - in order to not need huge latches for all signals
one changes once a day (had many of them). Was not so straight forward
as SPI is meant to be unidirectional, I ended up making the link 7 bit
over 8; the 8-th bit (bit 7) used to tell the slaves the host
is sending data or is just polling for new data from the slave,
and it used to tell the host the slave did actually send
data in this byte. Worked (still does) fine, there was no I2C
back then either.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

On Mon, 30 Nov 2015 23:44:44 -0600, Les Cargill
<lcargill99@comcast.com> wrote:

>upsidedown@downunder.com wrote:
>> On Sun, 29 Nov 2015 09:57:52 -0600, Les Cargill
>> <lcargill99@comcast.com> wrote:
>>
>>>>    You can use standard networking and TCP/IP for ease of development
>>>> (Modbus over TCP/IP handles pretty much everything you need for a
>>>> typical fieldbus application, and you can add other protocols such as
>>>> TFTP for larger transfers).
>>>
>>> Not a big fan of MODBUS over TCP. It's okay.
>>
>> Run Modbus RTU or Modbus/TCP frames in UDP frames.
>>
>
>I haven't tried that. It's full duplex? The turnaround times
>are what kills MODBUS RTU.

Modbus is basically just request/response so there are going to be
latencies and increasing the line speed doesn't help much.

Using Modbus/TCP framing with a message sequence number, the master
can send multiple frames at once. The slave processes each request,
copies the sequence number to the response, thus the master knows to
which request the received response belongs, thus eliminating much of
the latencies.

On 01/12/15 06:37, Les Cargill wrote:
> Dimiter_Popoff wrote:
>> On 30.11.2015 г. 02:53, upsidedown@downunder.com wrote:
> <snip>
>>
>> It will take a while until we see MCU-s with an on chip PHY similar to
>> the DP8392...

The main problem with putting an Ethernet PHY inside an MCU is that the
idea process for a PHY is very different from that for an MCU.  This
means you need to compromise on the quality (speed, die cost, power
efficiency, analogue characteristics, etc.) of one or other parts, or
both, in order to put both onto the same die.

>>
> 
> You can't really shrink the magnetics. 

Magnetics can be integrated into the RJ45 connector, making it only
slightly larger than normal.

> USB to Ethernet adapters are
> getting better - they're slow but better than nothing.
> 

With USB3, USB to Ethernet adapters are full speed - the latency is not
worse than you would normally live with on the average PC.  But with
USB2 adaptors (the fastest practical for embedded systems), there is a
bit of extra delay and you are a fair way off GBit speeds.

On 01/12/15 06:44, Les Cargill wrote:
> upsidedown@downunder.com wrote:
>> On Sun, 29 Nov 2015 09:57:52 -0600, Les Cargill
>> <lcargill99@comcast.com> wrote:
>>
>>>>    You can use standard networking and TCP/IP for ease of development
>>>> (Modbus over TCP/IP handles pretty much everything you need for a
>>>> typical fieldbus application, and you can add other protocols such as
>>>> TFTP for larger transfers).
>>>
>>> Not a big fan of MODBUS over TCP. It's okay.
>>
>> Run Modbus RTU or Modbus/TCP frames in UDP frames.
>>
> 
> I haven't tried that. It's full duplex? The turnaround times
> are what kills MODBUS RTU.
> 

That question makes no sense - MODBUS is a master/slave or
question/response protocol.  The master sends a question, and the slave
cannot send the response before the question arrives, so it is
necessarily half-duplex.

But being Ethernet, the connection itself is full duplex (normally).
That means you have have multiple master-slave connections and transfers
going on at the same time.  And since you don't have to have a single
bus master at a time, it is quite possible to have multiple Modbus
masters on the same network at the same time.

Using UDP reduces the packet overhead a little in comparison to UDP (you
don't need ACK's and connection handshaking), but typically it makes
very little real-world difference.  And TCP/IP is /far/ easier if you
are doing something beyond a simple closed network, such as routing
traffic around, passing it through firewalls, VPNs, wireless bridges, etc.


And turnaround times are /not/ an issue for carefully implemented MODBUS
RTU.  Unless you have very special bus hardware, the RS485 bus can be
turned around in a bittime or two.  The issue here is how fast the
master can guarantee to switch off its bus drivers - that gives the
minimum latency before the slave can start its reply.  And of course
slave reaction time and latency can be an issue.  So while it is common
to have long delays before slave replies, in order to handle slow
masters, it is certainly not necessary.

On Tue, 01 Dec 2015 10:41:45 +0100, David Brown
<david.brown@hesbynett.no> wrote:

>On 01/12/15 06:44, Les Cargill wrote:
>> upsidedown@downunder.com wrote:
>>> On Sun, 29 Nov 2015 09:57:52 -0600, Les Cargill
>>> <lcargill99@comcast.com> wrote:
>>>
>>>>>    You can use standard networking and TCP/IP for ease of development
>>>>> (Modbus over TCP/IP handles pretty much everything you need for a
>>>>> typical fieldbus application, and you can add other protocols such as
>>>>> TFTP for larger transfers).
>>>>
>>>> Not a big fan of MODBUS over TCP. It's okay.
>>>
>>> Run Modbus RTU or Modbus/TCP frames in UDP frames.
>>>
>> 
>> I haven't tried that. It's full duplex? The turnaround times
>> are what kills MODBUS RTU.
>> 
>
>That question makes no sense - MODBUS is a master/slave or
>question/response protocol.  The master sends a question, and the slave
>cannot send the response before the question arrives, so it is
>necessarily half-duplex.
>
>But being Ethernet, the connection itself is full duplex (normally).
>That means you have have multiple master-slave connections and transfers
>going on at the same time.  And since you don't have to have a single
>bus master at a time, it is quite possible to have multiple Modbus
>masters on the same network at the same time.

For this reason "master" is called Modbus/TCP client and "slave" is
called server in Modbus/TCP nomenclature.

>Using UDP reduces the packet overhead a little in comparison to UDP (you
>don't need ACK's and connection handshaking), but typically it makes
>very little real-world difference.  

I assume that you tried to say "Using TCP..."

I _hate_ TCP in any real time control loops !!!

I hope someone would write a book "How to kill people with TCP/IP" :-)

Buffering is a no-no in real time loops, especially if some obsolete
commands are lurking in some of the TCP/IP buffers.

>And TCP/IP is /far/ easier if you
>are doing something beyond a simple closed network, such as routing
>traffic around, passing it through firewalls, VPNs, wireless bridges, etc.
>
>
>And turnaround times are /not/ an issue for carefully implemented MODBUS
>RTU.  Unless you have very special bus hardware, the RS485 bus can be
>turned around in a bittime or two.  

Proper implementation of the Modbus RTU requires 1.5 or 3.5 character
time pauses, so the timing is very critical.

>The issue here is how fast the
>master can guarantee to switch off its bus drivers - that gives the
>minimum latency before the slave can start its reply.  

In a point-to-point connection or as a Modbus master, you do not need
to observe those latency times very accurately. 

You can use longer delays for conveniences, however dropping
throughput. Only a Modbus RTU slaves needs to observe the time gaps
accurately.
 

Am 29.11.2015 um 22:23 schrieb Dimiter_Popoff:

> It is not about the cable being round, it is about the cabling length.
> With a coaxial cable it can be nodes_count times shorter, just a single
> cable running through all the nodes.

Whether or not that's actually shorter depends a whole lot on where all 
those nodes are, and where cables can go without being in the way.

In somewhat a typical office environment, if you want it to be even 
remotely flexible, coaxial cable tends to have to run from some boundary 
(wall, floor, ceiling) to every node _and_back_again_.

And then of course there's the old one-fault-kills-it-all issue. 
Finding out which of 50 "T"s, spread over 10 offices, is the flaky one 
is really no fun at all.

Am 01.12.2015 um 07:07 schrieb Les Cargill:

> If you can get the bitrate up to 100 MBit, then it's probably worth it.

The proponents of using Ethernet instead of CAN did rather insist on a 
coaxial cable, though, which as far as I'm aware never materialized at 
100 Mbit/s.

Am 01.12.2015 um 07:14 schrieb Dimiter_Popoff:

>   Then I am not suggesting this could be a CAN replacement, apparently
> CAN is meant for lower level/closer range communication.

Not necessarily.  The true limiting factor is essentially the same as it 
is for shared-medium Ethernet, and basically every non-synchronized 
multi-drop network: the diameter of the net must be small enough for a 
signal to make the double round trip in time for collision handling to work.

> Was not so straight forward as SPI is meant to be unidirectional,

Huh?  How do you arrive at classifying a full duplex link like SPI as 
"unidirectional"?

On 02.12.2015 г. 00:51, Hans-Bernhard Bröker wrote:
> Am 01.12.2015 um 07:14 schrieb Dimiter_Popoff:
>
>>   Then I am not suggesting this could be a CAN replacement, apparently
>> CAN is meant for lower level/closer range communication.
>
> Not necessarily.  The true limiting factor is essentially the same as it
> is for shared-medium Ethernet, and basically every non-synchronized
> multi-drop network: the diameter of the net must be small enough for a
> signal to make the double round trip in time for collision handling to
> work.

Like I said before I just do not know CAN, this is only the feeling
I get about it at the few glances I have had. I still think it is meant
for lower level communications than Ethernet (and perhaps misused to
put higher level on top of it) but I am certainly not the person to
listen to about CAN.

>
>> Was not so straight forward as SPI is meant to be unidirectional,
>
> Huh?  How do you arrive at classifying a full duplex link like SPI as
> "unidirectional"?

I am not sure how you define full duplex but it _is_ unidirectional
in that the master has no way of knowing - other that the data contents
it receives from the slave - whether the slave had something to say or
not. Likewise, the slave has no way of knowing other than the contents
of the data byte (word etc., whatever) whether the master did mean to
send data or was just polling the slave for some output.
Try to figure out how you would implement an equivalent of a UART over
SPI - to figure it out down to the lowest detail, that is - and you
will see what I mean.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/