why does this board operate via CAN bus?

[legacy]

The Duet 3 Tool board looks intended to demonstrate how the *CAN bus* can be used to reduce wiring to direct drive extruders.

But, is it the *only* reason for this?

[jhpadjustable]

Isn't that reason enough? CAN is a natural and reasonably-priced choice for reliably and quickly conveying small data packets under conditions of high electrical noise and ground potential offsets. Would you have them use I2C?

[legacy]

Would you have them use I2C?

RS485.

Even 3d robot arms do use RS485 on their nodes.

[Berni]

The question is what is wrong with using CAN for this? It only needs 2 wires and is resilient against noise since its differential. One of the few commonly used alternatives that can provide the same benefits is RS485.

What bus would you rather see used for this?

EDIT: Btw CAN also does multi-master very well due to its built in arbitration.

[legacy]

The question is what is wrong with using CAN for this?

Nothing is wrong with anything, I am just asking.

[legacy]

What bus would you rather see used for this?

RS485.

[Rerouter]

In volume Can Transceivers and RS485 are about the same in price, with CAN you get hardware in a lot of modern micro's to just listen for its ID in hardware and then react, vs needing to parse the message each time (seen this better fleshed out with CAN vs UART)

I would expect this is one of the main deciding factors, having the micro only having to react when a message specifically for it, and supporting broadcast messaging and firmware uploading out of the box via the existing standards, so the next guy who comes along can play nicely on the same wiring.

[langwadt]

In volume Can Transceivers and RS485 are about the same in price, with CAN you get hardware in a lot of modern micro's to just listen for its ID in hardware and then react, vs needing to parse the message each time (seen this better fleshed out with CAN vs UART)

I would expect this is one of the main deciding factors, having the micro only having to react when a message specifically for it, and supporting broadcast messaging and firmware uploading out of the box via the existing standards, so the next guy who comes along can play nicely on the same wiring.

afaik CAN initially used rs485 transceivers, just with hardwired data pin and data on the enable pin

[jhpadjustable]

Rerouter said almost everything I was going to say.

For my project, I needed to share some sensor information among several devices and have them act autonomously on it, send unicast messages with dictionaries/setpoints/etc. from a loader, and have all nodes assume unique addresses without a central coordinator present. CAN was a perfect match for my use case, and all I needed to add was a 25 cent transceiver to an STM32 chip.  A+++++ would use again

[donotdespisethesnake]

Would you have them use I2C?

RS485.

Old generations of Reprap electronics used RS485 https://reprap.org/wiki/Motherboard_1.2#RS485_Comms_.2B_Power. But clearly CAN is superior, and if cheap micros have a CAN peripheral, it really is a no-brainer.

Even 3d robot arms do use RS485 on their nodes.

"Citation needed", but I've no idea why you regard robot arms as a reference standard design for other systems.

[legacy]

In volume Can Transceivers and RS485 are about the same in price

Bah. A Can bus adapter costs (usb-Peak) 250 euro, a RS485 costs 20 euro. Debugging and monitoring tools are usually *MORE* expensive. A lot of Linux kernel driver for Can bus are a complete mess; Can bus is neither a lan nor a serial, therefore even applications need to have it workarounded, while RS485 is a serial, handled as serial, and it's ready out of the box.

p.s.
my MSO alredy comes with a serial analyzer software, and RS485 is included, Can bus is not -> more money to buy it.

I would expect this is one of the main deciding factors, having the micro only having to react when a message specifically for it, and supporting broadcast messaging and firmware uploading out of the box via the existing standards, so the next guy who comes along can play nicely on the same wiring.

That's more interesting.

[legacy]

and if cheap micros have a CAN peripheral, it really is a no-brainer.

ColdFire v1 was an old MPU made by Motorola/Freescale, and some chips had a built-in Can bus controller. e.g. the AXI board comes with a ColdFire v1, and a few Can bus examples. It randomly appears on eBay for 40 USD. Interesting! But it's not what  I am worried about, but rather tools, and especially those for Linux is what I am worrying.

I mean, I do happen to sometimes use Can bus at work for automotive; in avionics, we prefer to deal with ARINC 429, it supports redundancy, it's what you usually find in an aircraft, even helicopters do use it, it's very simple and reliable with a lot of whistles and bells, and VxWorks/OS and Integrity/OS do support it (Linux is not I am aware of no support) but it's 50 times expensive, and we use it only because it's *the* standard by customers' contracts.

In short, because someone pays for it.

I do have some repaired boards with replaced FPGA I do program myself my own bitstream, I might *theoretically* play with the "Aeronautical Radio INC four two nine", if this did make sense for a 3d printer (does it?  )

I might also *theoretically* play with Can bus, by bringing home some broken boards to be repaired, or buying the Axi card on eBay (which I am really tempted to buy)

But what about tools? That is *THE* problem, not the hardware per se, since generally, I cannot allocate the same budget and time at home for a hobby project.




Anyway, I do find the board in my first post: very very interesting 

[Berni]

In volume Can Transceivers and RS485 are about the same in price

Bah. A Can bus adapter costs (usb-Peak) 250 euro, a RS485 costs 20 euro. Debugging and monitoring tools are usually *MORE* expensive. A lot of Linux kernel driver for Can bus are a complete mess; Can bus is neither a lan nor a serial, therefore even applications need to have it workarounded, while RS485 is a serial, handled as serial, and it's ready out of the box.

p.s.
my MSO alredy comes with a serial analyzer software, and RS485 is included, Can bus is not -> more money to buy it.

You can buy a CANBus to USB adapter dongle on ebay for <20USD or make your own by taking a devboard for a MCU with built in CAN and USB and throwing together your own CAN to USB adapter in a day or so. Tho to be fair you can get UART to USB dongles on ebay for literally 1$ and those can be used to listen in on RS485 or add a 50 cent PHY to make it transmit too, so yes RS485 is easier but then again CAN is not that hard. As long as you wrap an appropriate protocol around it it can be treated as a tty serial port.

So far all the modern scopes with serial decode i came into contact with also supported CAN. Its all that exotic of a bus.

I would expect this is one of the main deciding factors, having the micro only having to react when a message specifically for it, and supporting broadcast messaging and firmware uploading out of the box via the existing standards, so the next guy who comes along can play nicely on the same wiring.

That's more interesting.

You can do the same in a lot of MCUs with RS485 if 9bit mode is used where the UART first waits to see its unique address before it starts listening in.

But you will still have issues with packet collisions if multiple nodes transmit on the bus. CANBus automatically makes everyone except the highest priority node back off in a colision and let the winning node finish its transmission unharmed, then the nodes who lost arbitration automatically retry afterwards.

The case where RS485 is superior to CAN is when a lot of data needs to be moved quickly over a long wire of >10m. The arbitration process limits the length of the cable due to too long signal delays causing the arbitration to fail, also CAN has a best case of 50% overhead in its bulky packet structure so much less data can fit down the pipe. Where as for RS485 you get the typical 20% overhead of a start and stop bit while the speed and cable length is only limited by how far the cable can carry the signal before it gets garbled up.

[Rerouter]

J1939 canbus (the one commonly used for commercial), has frame and data escape packets, essentially a way of saying this is not normal, ignore it until the packet ends, its what is usually done for firmware updates, so instead of sending 8 bytes per packet, you set the escape packet and stream out your 10's of MB firmware image in 1 sequence.

The 2014 standards for canbus are out on the web for free if you know what to look for, its pretty much the industrial flavor of USB with how much extra functionality has been tacked on to the original specification, with great lengths taken to keep things backwards compatible.

The professional tools do cost a pretty penny, but a cheap USB logic analyser gets you 99% of the way to debugging this stuff, half of the pain is specifying the definitions of certain PGN's, there are exceptions to exceptions to exceptions,

The older can standard that used to use RS485 trancievers with a different pinout was called "J1708", think 10400 baud, and really easy to decode (have literally built a decoder for it in an excel template)

As for length, 500KHz J1939 is used in Mercedes buses right now with a 15-22 meter run between the rear mounted engine, gearbox, and a gateway module located near the drivers feet, as long as the capacitance is low, its not really an issue, there is even 1MHz CanFD popping up in the latest sprinter van model, (cant even read its fault codes with a normal reader)

[jhpadjustable]

But it's not what  I am worried about, but rather tools, and especially those for Linux is what I am worrying.

It is perfectly feasible to make good use of CAN as a simple data-link without any standard higher-level protocols, as a reliable, collision-resistant, broadcast-oriented data link, sort of a cousin of Ethernet but more lightweight. In the degenerate case of a digital wiring harness, a node might simply listen for a preset 11-bit CAN address and write the received payload bits to an output port or PWM register, or broadcast samples of its own input port to some preset 11-bit CAN address. Such a system can be adequately monitored by snooping the bus with Wireshark or the command-line tools, using a dime-store CAN-USB adapter, set to simply receive messages from the network device and log/display them as desired. Such a system can often be adequately stimulated through software using the CAN bindings for your language of choice, or even Linux and shell scripts.

The complexity is found in the higher-level protocols that specialize and standardize the CAN bus for various use cases such as automotive, industrial, and home automation, by assigning suitable meanings to parts of the CAN message and values they contain, and specifying when and how a bus node should react in response to various messages. That added complexity calls for more sophisticated tooling, with protocol-specific parsers and databases. They might take account of HLP-specific network state, validate parameters, tally bus and data errors, calculate latency and jitter with respect to another message or a timing reference, calculate bus utilization per node, and so on. Those cost money, in part because the standards themselves are expensive, comprehensive, and sometimes incomprehensible; in part because implementing them isn't especially fun; and in part because... wait for it... they CAN. 

But all that higher-level overhead and the tooling to manage it may be optional for an application where interoperation with standards isn't relevant. If your need goes no further than to multiplex sensor values and commands to/from multiple nodes over a twisted pair, the advantages of using CAN instead of an RS485 link include low CPU/ISR overhead, hardware buffering and data integrity, hardware you may already have in your MCU (including the vast majority of STM32 chips), effective statelessness, and no need for writing and validating an own network protocol implementation based on async serial, CAN is an easy choice. Et voilá, the Duet 3 Tool board.

I do have some repaired boards with replaced FPGA I do program myself my own bitstream, I might *theoretically* play with the "Aeronautical Radio INC four two nine", if this did make sense for a 3d printer (does it?  )

I don't know. Are you building a helo with a giant foam dispenser?