CANBUS Tx/Rx with data length > 8 bytes

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
Reply to
Tim Wescott
Loading thread data ...

[...]

Without the train stopping (or even slowing down). :)

--
Grant Edwards               grant.b.edwards        Yow! Now I understand the 
                                  at               meaning of "THE MOD SQUAD"! 
 Click to see the full signature
Reply to
Grant Edwards

It's a train for athletes.

--
www.wescottdesign.com
Reply to
Tim Wescott

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 
 Click to see the full signature
Reply to
Grant Edwards

Am 30.11.2015 um 03:29 schrieb Tim Wescott:

... 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 to
Hans-Bernhard Bröker

Many things come now with 2 Ethernet ports. That doesn't much help with power.

Agreed, although I recall 30V for some things, which is still too high.

--
Les Cargill
Reply to
Les Cargill

You can't really shrink the magnetics. USB to Ethernet adapters are getting better - they're slow but better than nothing.

--
Les Cargill
Reply to
Les Cargill

I haven't tried that. It's full duplex? The turnaround times are what kills MODBUS RTU.

ARP is pretty easy.

Very much so.

Yep.

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 to
Les Cargill

Sure. CAN messages look suspiciously like ATM cells. Same basic premise.

But we all know what's happened there...

That must have been faster than 10msec/100Hz sampling then. I've not been so privileged yet.

I've not run into too many cases where the message length put performance at risk.

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
Reply to
Les Cargill

It is; absolutely.

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

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

The cabling for CAN is pretty nice.

--
Les Cargill
Reply to
Les Cargill

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

formatting link

------------------------------------------------------

formatting link

Reply to
Dimiter_Popoff

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.

Reply to
upsidedown

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.

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

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.

Reply to
David Brown

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.

Reply to
David Brown

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

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.

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

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.

Reply to
upsidedown

Am 29.11.2015 um 22:23 schrieb Dimiter_Popoff:

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.

Reply to
Hans-Bernhard Bröker

Am 01.12.2015 um 07:07 schrieb Les Cargill:

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.
Reply to
Hans-Bernhard Bröker

Am 01.12.2015 um 07:14 schrieb Dimiter_Popoff:

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.

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

Reply to
Hans-Bernhard Bröker

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.

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

formatting link

------------------------------------------------------

formatting link

Reply to
Dimiter_Popoff

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.