On Sat, 28 Nov 2015 23:19:42 -0600, Les Cargill wrote:> Oliver Betz wrote: >> "Marco T." wrote: >> >>> Hi to everybody! >>> I should implement a function on my uC (Freescale MAC7121) that will >>> receive and/or send data with length > 8 bytes: is it possible? >> >> I wonder when (whether) CAN FD will be supported widely. >> >> Oliver >> >> > I'd kind of like to see CAN expire in general. There are different > versions of an Ethernet PHY that can replace it. For other domains, > there's PROFIBUS, which is weird but at least supports variable length > PDUs.The one time I've used CAN for a serious product it provided exactly what I needed, and part of providing that was the enforcement of short messages. Of course, I was working on something that all lived in a box one could get one's arms around, and which closed a bunch of analog control loops. Guaranteed-short runs meant high speed, and short messages meant that the high-priority ones always got through in a timely manner. 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. -- www.wescottdesign.com
CANBUS Tx/Rx with data length > 8 bytes
Started by ●November 19, 2015
Reply by ●November 29, 20152015-11-29
Reply by ●November 30, 20152015-11-30
On 2015-11-29, upsidedown@downunder.com <upsidedown@downunder.com> wrote:> The problem with Ethernet protocols is the requirement of at least 64 > bytes total, so for most small I/O nodes, they do not even fill that > minimum size frame. > > One exception is EtherCAT https://en.wikipedia.org/wiki/EtherCAT[...]> Think about a local train, in which passengers are leaving at each > station and others will enter at each station.Without the train stopping (or even slowing down). :) -- Grant Edwards grant.b.edwards Yow! Now I understand the at meaning of "THE MOD SQUAD"! gmail.com
Reply by ●November 30, 20152015-11-30
On Mon, 30 Nov 2015 16:19:03 +0000, Grant Edwards wrote:> On 2015-11-29, upsidedown@downunder.com <upsidedown@downunder.com> > wrote: > >> The problem with Ethernet protocols is the requirement of at least 64 >> bytes total, so for most small I/O nodes, they do not even fill that >> minimum size frame. >> >> One exception is EtherCAT https://en.wikipedia.org/wiki/EtherCAT > > [...] > >> Think about a local train, in which passengers are leaving at each >> station and others will enter at each station. > > Without the train stopping (or even slowing down). :)It's a train for athletes. -- www.wescottdesign.com
Reply by ●November 30, 20152015-11-30
On 2015-11-29, upsidedown@downunder.com <upsidedown@downunder.com> wrote:> One exception is EtherCAT https://en.wikipedia.org/wiki/EtherCAT > in which the master sends out a big Ethernet frame, which then passes > through each slave. Each slave picks the bytes it is interested in. It > can also reuse a slot in the frame and insert input data into a free > slot and finally the frame is passed back to the master, extracting > all input data inserted into the frame during the pass through each > slave. Of course, this requires specialized hardware in each node. The > delay is only a few Ethernet bit times in each slave. > > Think about a local train, in which passengers are leaving at each > station and others will enter at each station.One thing I've wondered about for a long time is can the slots get re-used after they're "vacated"? For example, if bits X-Y contain data sourced by the controller and destined for node A, can that those bits then be re-used for data sourced from node B or C (assuming B and C are downstream from A)? There doesn't seem to be any technical reason why it couldn't be set up that way, but all the fancy animate graphical demos I've seen always seem show each slot being used exactly once. -- Grant Edwards grant.b.edwards Yow! ... the HIGHWAY is at made out of LIME JELLO and gmail.com my HONDA is a barbequeued OYSTER! Yum!
Reply by ●November 30, 20152015-11-30
Sounds a bit like Cambridge ring. "Grant Edwards" <invalid@invalid.invalid> wrote in message news:n3i1jp$onv$1@reader1.panix.com...> On 2015-11-29, upsidedown@downunder.com <upsidedown@downunder.com> wrote: > >> One exception is EtherCAT https://en.wikipedia.org/wiki/EtherCAT >> in which the master sends out a big Ethernet frame, which then passes >> through each slave. Each slave picks the bytes it is interested in. It >> can also reuse a slot in the frame and insert input data into a free >> slot and finally the frame is passed back to the master, extracting >> all input data inserted into the frame during the pass through each >> slave. Of course, this requires specialized hardware in each node. The >> delay is only a few Ethernet bit times in each slave. >> >> Think about a local train, in which passengers are leaving at each >> station and others will enter at each station. > > One thing I've wondered about for a long time is can the slots get > re-used after they're "vacated"? For example, if bits X-Y contain > data sourced by the controller and destined for node A, can that those > bits then be re-used for data sourced from node B or C (assuming B and > C are downstream from A)? > > There doesn't seem to be any technical reason why it couldn't be set > up that way, but all the fancy animate graphical demos I've seen > always seem show each slot being used exactly once. > > -- > Grant Edwards grant.b.edwards Yow! ... the HIGHWAY is > at made out of LIME JELLO > and > gmail.com my HONDA is a > barbequeued > OYSTER! Yum!
Reply by ●November 30, 20152015-11-30
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. CSMA/CD really sucks if bus load ever goes above ca. 20%. 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. 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.
Reply by ●December 1, 20152015-12-01
Dimiter_Popoff wrote:> On 29.11.2015 г. 08:47, Les Cargill wrote: >> Dimiter_Popoff wrote: >>> On 29.11.2015 г. 07:19, Les Cargill wrote: >>>> Oliver Betz wrote: >>>>> "Marco T." wrote: >>>>> >>>>>> Hi to everybody! >>>>>> I should implement a function on my uC (Freescale MAC7121) that will >>>>>> receive and/or send data with length > 8 bytes: is it possible? >>>>> >>>>> I wonder when (whether) CAN FD will be supported widely. >>>>> >>>>> Oliver >>>>> >>>> >>>> I'd kind of like to see CAN expire in general. There are >>>> different versions of an Ethernet PHY that can replace it. For >>>> other domains, there's PROFIBUS, which is weird but at least >>>> supports variable length PDUs. >>>> >>> >>> I am not familiar with CAN but I would like to see a standardized >>> Ethernet connector for coaxial cable plus power pins (12V?). Have been >>> dreaming of that for may be 25 years. >> >> What's wrong with PoE? You can run it over round cables with 4-conductor >> M12 connectors*. Works a treat. > > 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. And no switch necessary. >Many things come now with 2 Ethernet ports. That doesn't much help with power.> Then the 70V is somewhat too high,Agreed, although I recall 30V for some things, which is still too high.> one cannot just use a trivial > stepdown convertor as with say 12V for smallish things. > I had designed PoE in our netMCA as an option on the board, well, > was never used. Nobody had any thoughts on having a wall adapter, > in fact need for a PoE capable router would have been more of a > barrier in user perception. > >>> Apparently there has been no interest. Nowadays as we have more >>> RAM for buffer memory and they promote that IoT thing the necessity >>> has eventually become obvious - hopefully... >>> >> >> IoT looks a lot like hype to me. > > Which is what it is of course. But this does not mean devices will > not be connected over the net, our netMCA is one of those "things" > quite some years before they coined the phrase. > It will take just some more RAM on the MCUs, a few MB, and tcp/ip > stacks will be practical even at higher speeds/transfer rates. > > Dimiter > > ------------------------------------------------------ > Dimiter Popoff, TGI http://www.tgi-sci.com > ------------------------------------------------------ > http://www.flickr.com/photos/didi_tgi/ >-- Les Cargill
Reply by ●December 1, 20152015-12-01
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. USB to Ethernet adapters are getting better - they're slow but better than nothing.> Dimiter > >-- Les Cargill
Reply by ●December 1, 20152015-12-01
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.>>> Or you can use direct Ethernet frames for >>> maximal efficiency. > > The raw Ethernet or UDP is nearly as efficient, Of course, you would > have to implement the ARP protocol, but this helps configuration > somewhat. >ARP is pretty easy.> No need to implement the TCP stack. > >> I find that really basic ASCII protocols over UDP or TCP work just >> fine. At about 100 individual elements/registers, it starts to show >> real advantages over MODBUS. > > Of course if you insist of using ASCII, there is also Modbus ASCII, > the frame fits nicely into an Ethernet or UDP frame :-) >Very much so.>> My measurements of trying to go directly to Ethernet instead of using >> UDP or TCP don't support that choice. > > Some old Siemens Ethernet protocols used raw MAC addresses and there > were always problems getting it to work in a real world environment > with multiple vendors. >Yep.> UDP+ARP simplifies life. >Agreed, although for a variety of reasons, having DHCP and some subset of DNS available is also nice if you have to move nodes. -- Les Cargill
Reply by ●December 1, 20152015-12-01
Tim Wescott wrote:> On Sat, 28 Nov 2015 23:19:42 -0600, Les Cargill wrote: > >> Oliver Betz wrote: >>> "Marco T." wrote: >>> >>>> Hi to everybody! >>>> I should implement a function on my uC (Freescale MAC7121) that will >>>> receive and/or send data with length > 8 bytes: is it possible? >>> >>> I wonder when (whether) CAN FD will be supported widely. >>> >>> Oliver >>> >>> >> I'd kind of like to see CAN expire in general. There are different >> versions of an Ethernet PHY that can replace it. For other domains, >> there's PROFIBUS, which is weird but at least supports variable length >> PDUs. > > The one time I've used CAN for a serious product it provided exactly what > I needed, and part of providing that was the enforcement of short > messages. >Sure. CAN messages look suspiciously like ATM cells. Same basic premise. But we all know what's happened there...> Of course, I was working on something that all lived in a box one could > get one's arms around, and which closed a bunch of analog control loops.That must have been faster than 10msec/100Hz sampling then. I've not been so privileged yet.> Guaranteed-short runs meant high speed, and short messages meant that the > high-priority ones always got through in a timely manner.I've not run into too many cases where the message length put performance at risk.> 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. >CAN is a huge improvement on that front. It just doesn't scale, and the marshalling/unmarshalling is always a PITA. Of course, you accrue a set of converter routines for that and it stops being quite so painful. you're still left with some unpleasant CM duties - when a sensor goes out, for example. I will bet that if there were small concentrators of analog inputs and asynchronous UDP from them to a central box that replaces the box you used to put your arms around, it'd be cheaper ( ignoring Ethernet switches and power ). Latency may well suffer though. -- Les Cargill
