CAN-FD Generic IO

drobertson123

I love the idea of an industrial spec IoT communications system for controlling parts of the machine. Reducing wiring to com+power is really attractive, especially after I spent the weekend building out a 38 wire harness to my experimental machine. Just the cost reduction in wire, connectors, cable management, etc.. make this very worth it.

My problem is finding hardware for the random IO bits I want to add. I have some tool boards on order but those are very specific. Regrettably, there isn't a very good ecosystem of inexpensive CAN-FD transceiver boards out there.

I am looking for something that is a simple, inexpensive CAN-FD transceiver that can be paired with a small SoC like an ESP32, Arduino or whatever. Better yet, a board that has the two integrated together on a small package with a nice array of IO pins and maybe some ADC.

This would be used for specialty sensors or possibly even motor control systems. I have a new filament module that I am working on that measures filament availability, tension and movement rate. It would be good to have a way to communicate this over the CAN-FD bus.

Does Duet have any plans for something like this? Is there a suggested 3rd party board we can use? I feel we have a great technology to play with but we are crippled by a lack of ways to use it.

dc42

@drobertson123 said in CAN-FD Generic IO:

I am looking for something that is a simple, inexpensive CAN-FD transceiver that can be paired with a small SoC like an ESP32, Arduino or whatever. Better yet, a board that has the two integrated together on a small package with a nice array of IO pins and maybe some ADC.

That's more or less what our Tool Board does, except that only the IO_n pins are broken our more or less directly. It's soon to be joined by our external stepper driver board. I guess we could make a prototyping board, but I'm not sure there would be enough demand to recoup the design and manufacturing costs. I'll discuss it with my colleagues.

If there is sufficient IO on the stepper board the community might design a board to plug onto the headers and provide a prototyping area. Assuming the step/dir/en pins could also be general purpose.

drobertson123

I respect the business side of this request. I don't expect that everyone has the same needs I do.

Is it possible to tack on some kind of general communications channel to the single stepper board or ideally all the remote boards connected by CAN-FD. Possibly have a generalized protocol that would allow expansion such as exposing an SPI to CAN-FD interface on the remote boards. SPI was just a quick thought but any open communications protocol would be fine.

The MCP2517FD chip is an example of the concept. Build the remote boards for a purpose (and have a solid market for them) but also leave open an extra traditional communications channel that would allow expansion.

The thing that is killing me with CAN-FD right now is that I have no way to easily prototype new things without buying really expensive hardware or laying out a whole communications board from scratch. CAN-FD effectively becomes a closed environment within a great open-source ecosystem.

I would rather see it become the edge connector to whatever people want to add to it. It obviously has a core purpose of controlling motors and reading sensors. These are fairly standard things everyone has. With a bit of firmware and hardware support, it can be a platform for new things.

Obviously this would need to be planned out for additional support in the firmware but a way of defining data I/O sources that could send information over CAN-FD and have incoming data trigger a response would be a great base for developing new printing and CNC technologies. Integrating this with your conditional g-code would be another level of capability.

@drobertson123 said in CAN-FD Generic IO:

The MCP2517FD chip is an example of the concept.

looks like that still needs a host microcontroller? so the ATSAMC21G18A (or others in the same family) used on the toolboard would be a better choice as it has the can controller integrated to the microcontroller and only needs the external transceiver.

drobertson123

Sorry to ramble but a thought occurred after submitting the last comment. If the firmware support for configurable general IO channels is built in a relatively generic way, the same code could support EtherCATbased communications as well as CAN-FD. The only main difference would be the transport layer.

The advantage of EtherCAT is that most SoC boards with an ethernet port already have libraries supporting EtherCAT.There is a decent project here; https://github.com/OpenEtherCATsociety
and support for EtherCAT is available for ESP32, STM32 and even Python Libraries.

Just some ideas.

drobertson123

@bearer I agree that there are probably much better choices. That was just a chip I found with a white paper directly discussing the topic that comes from the same family as the chips in use by Duet.

Most of this is public brainstorming driven by some projects I am currently working on that could really use these features. I am looking forward to people coming up with better suggestions than mine.

The one thing I do believe is that we shouldn't just be looking at CAN-FD and other communications protocols as just a way to do the same old things with a few fewer wires. This is the chance to lay a foundation for the next advances. If a flexible communications capability is built into these devices then someone will find a way to use it in some new and unexpected way.

In a way, this is another arms race. Either the maker community gets out ahead and innovates or the big companies will beat us to the ideas. Personally, I don't want to wait 20 more years for a patent to expire before I can do something cool.

Duet has the chance to create an ecosystem for those innovations. It may sound crazy, but a high-speed deterministic communications bus could be very fertile ground for very creative concepts.

Have you ever heard a print going bad? What if you could place localized microphones around a printer to listen for problems. A little AI and some audio boards and you have Spaghetti Detective with ears. Optical temperature sensors are actually pretty common. What if you could look at the material ahead of where you are printing and use small hot air blowers to preheat the surface for better adhesion. Since we are dreaming, why not just use freaking lasers.

My point isn't that any of these are brilliant ideas. Just that they become far more practical to try with a communication bus like CAN-FD or possibly EtherCAT. Maybe one of my crazy ideas will turn out useful. No clue on the odds of that. But I am confident that someone's crazy idea will make a real innovation for us if they have a chance to try it.

dc42

@drobertson123 said in CAN-FD Generic IO:

The advantage of EtherCAT is that most SoC boards with an ethernet port already have libraries supporting EtherCAT.There is a decent project here; https://github.com/OpenEtherCATsociety
and support for EtherCAT is available for ESP32, STM32 and even Python Libraries.

A disadvantage is that a license fee is payable on any EtherCAT device, although not on on an EtherCAT host (such as a Duet main board that supports communication with EtherCAT devices).

drobertson123

@dc42 Thanks, I did not know that. That is a real barrier to entry to consider. I wonder how that fits in with all the EtherCAT libraries I have been looking at. So far I haven't seen any mention of a lic fee but I rarely read too deep into the Lic files since my work is mainly for myself.

Notes - I did some digging into the license model.
Source: https://www.ethercat.org/en/faq.html

EtherCAT Master License is free and only requires conformity with the EtherCAT standards. This may conflict with any open source lic you are using.

EtherCAT slave licenses are tied to the receiving chip on hardware. This is the part I didn't get before. The master can easily be implemented in code but the slave requires a special ASIC receiver chip. The license fee is automatically paid when the chip is bought. The problem is that just like CAN-FD, special hardware is required and it isn't on hobby boards at this time (and may never be).

We come right back around to the same problems as before.

That is disappointing.

The barrier to make a DIY board ala the toolboard isn't huge; even jlcpcb has the atsam in their smt parts for assembly (though not in stock atm); would set you back about $40 for two board assembled + shipping i guesstimate.

But it might be cheaper and easier to use the external stepper driver board, if the pins can be defined as general purpose IO instead of motor drivers, was thinking to have a look see when the details of these boards are out.

(or even easier! )

dc42

You can buy a SAMC21 development board, see https://uk.farnell.com/microchip/atsamc21-xpro/evaluation-board-xplained-pro/dp/2492013. Also available from Digikey https://www.digikey.com/product-detail/en/microchip-technology/ATSAMC21-XPRO/ATSAMC21-XPRO-ND/5256707 and probably Mouser etc.

dc42

Here's another one: https://www.chip45.com/products/sammy-c21-1.0_atmel_smart_arm_sam_module_board_samc21_usb_dual_two_can.php

And another: https://www.mattairtech.com/index.php/mt-d21e.html

drobertson123

Thanks

The small board looks like what I was envisioning. Small form factor and a reasonable price that can handle 3-4 local sensors or outputs. I am going to order a few and see what I can make them do.

dc42

@drobertson123, by "the small board", do you mean the one from chip45?

If so, you should be able to fork and adapt the tool board code in https://github.com/Duet3D/Duet3Expansion. I think you need to do at least the following:

Decide whether to upload the code over USB using the optional chip45 bootloader, or upload the code over CAN as we do for tool boards.
If you use the chip45 bootloader, you may need to change the linker input file for your configuration of the expansion board project so that the code starts 4K from the start of flash instead of 16K, because that's probably where the bootloader expects the code to be.
If instead you use our CAN bootloader, you will need an Atmel ICE or similar to program the bootloader into that board. (You may find the ICE useful for debugging too). You will also need to do a variant of our bootloader (https://github.com/Duet3D/Duet3Bootloader) that returns a different board short name to the Duet 3. The board short name determines the file that the Duet 3 main board fetches the firmware from.
The chip45 board uses a 16MHz crystal, whereas our tool board uses a 12MHz crystal. Therefore you will need to change the clock multiplier (also in our bootloader, if you are using it).
There is a simple debug facility in the expansion/tool board firmware for writing messages to a serial port. You could adjust it to use the SERCOM device that is connected to the USB port.
Finally (I think!), you will need to adjust the pin table to name all the available I/O pins on the board.

drobertson123

Thanks a lot for the detailed advice. I did order the Sammy-C21 V1.0 from chip45 but since I couldn't find a supplier in the US the shipping nearly doubled the price (ouch).

I also picked up a pair of NUCLEO-G474RE dev boards that have integrated CAN-FD and a small stack of MCP2558FD chips as transceivers. That actually cost me less than the one Sammy-C21 with shipping. Those dev boards are pretty solid performance-wise and have a lot of IO capability for their $15 price tag on Mouser but I have no doubt there will need to be a lot of tweaking to get things to talk.

If I can get the CAN FD communications sorted out it will dramatically reduce a wiring nightmare I can see coming up and give me flexibility. That will leave me more time to focus on some really hard kinematics problems I need to sort through.

The main project this is going into is effectively a sliding Delta actuator over a rotary axis. It is for printing a soluble support structure on a central tube that is then used for filament winding complex features.

Most of the concepts can be drawn directly from other designs but it effectively has redundant ways to move in the X-Axis and my brain is getting tripped up on how to plan that movement. But I will deal with communications and control first.

JoergS5

Teensy 4 may be an option too. It has a fast 600 MHz MCU and one CAN-FD. The new 4.1 version has some improvements like more IO ports.

dc42

I've added a SAMMYC21 build configuration to project Duet3Expansion. It's designed to work with the bootloader from chip45.com. I won't have a chance to test/debug it until the boards I have ordered arrive.

I've set up the pin table to use the available ports on the Sammy-C21 board as follows:

PA02 "temp0" (thermistor or other analog input)
PA03 "temp1" (thermistor or other analog input)
PA04 "pa04" input, output with PWM
PA05 "pa05" input, output
PA06 "pa06" input, output with PWM
PA07 "pa07" input, output
PA08 "pa08" output
PA09 External driver EN, active low
PA10 External driver DIR, active low
PA11 External driver STEP, active low
PA12 "pa12" input, output with PWM
PA13 "pa13" input, output
PA16 "pa16" input, output
PA17 "pa17" input, output
PA18 "pa18" input, output
PA19 "pa19" input, output with PWM
PA20 "pa20" output
PA21 "pa21" output
PA22 "pa22" output
PA23 "pa23" output with PWM
PB08 "pb08" input, output
PB09 "pb09" input, output

@dc42 said in CAN-FD Generic IO:

I've added a SAMMYC21 build configuration to project Duet3Expansion.

much love!

drobertson123

@dc42 That is great.

I got in some components to play with, not the SAMMYC21 yet, but some CAN-FD compliant transceivers and some NUCLEO STM32 boards that have built-in CAN-FD.

When my SAMMYC21 gets here I should have a decent ecosystem of boards.

When is the CAN-FD Stepper driver you had mentioned earlier estimated to be available? Will it have some IO for endstops? If so it would be a good fit for driving my Delta arms.

I already have the tool board on order(looking forward to filastruder shipping it) and I think I am picking up a second Duet 3 Mainboard for a CoreXY project. I like where you are taking your products. Keep it up.

mwwhited

@dc42 said in CAN-FD Generic IO:

A disadvantage is that a license fee is payable on any EtherCAT device, although not on on an EtherCAT host

As stated in their own FAQ

3.3 How about licences? 
There is a licence for implementing an EtherCAT master which is free of charge - the agreement demands compatibility, ensures that the licence remains free of charge and provides legal certainty. For slave devices EtherCAT has adopted the CAN license model (CAN is an excellent example for a standardized open technology that is protected by patents): The small license fee is "embedded" in the EtherCAT Slave Controller (ESC) chip, so that device manufacturers, end users, system integrators, tool manufacturers etc. do not have to pay a license.

This license is only payable for dedicated embedded controllers. If you used a multi-master configuration there would be no dedicated chip and no payable license. If you did use an embedded chip the license free is included with the chip cost.