@Phaedrux Haha, my whole rambling description of my printer was off-topic, so no worries.
Not sure if this will trigger a spam alert, but here is the link to the keyboard.
I mainly use it when I am testing the printer inside the cabinet. Otherwise, I just browse to the web page from my big computer 3 ft away. In general, I am pleased with it, but I wouldn't want to use it as my main keyboard.
@dc42 Thank you for that update of the configurator. I worked with it last night and the new options do seem to line up better with what I want to do.
I should have a chance to do some testing later today and will report back on how things go.
I am officially naming this machine the "wassaPrusa" since it is a heavily modified Prusa I3 MK3s. It now has a Hemera hotend joined to the Prusa PINDA v2 Z-Probe. The X & Y axis now have more powerful steppers (and I am also evaluating closed-loop drives). The X-Axis also is being upgraded with a linear rail to fix some sticking issues.
Many of the printed parts are being upgraded to work in a temp controlled enclosure. That enclosure was one of the main drivers for shifting over to the Duet boards. The Prusa printer is great, but it just didn't have the ability to support the expansion I wanted to do.
Now I can control enclosure heaters, fans and other add ons I am working with.
Sorry for rambling about the project. I think I can see the final solution coming for these config issues and it is getting a bit exciting.
Here is the in-progress wassaPrusa;
I am looking for some general advice or to be told it can't be done.
I have a Duet 3 Mainboard that connects over CAN-FD to a Tool Board 1LC running a Hemera. I want to use a PINDA v2 sensor with thermal compensation as my z-axis probe but I keep running into roadblocks.
My initial plan was to connect the PINDA signal line (black) to the io0.in port of the tool board, then wire the temp sensor of the PINDA (white) to temp1, also on the board.
temp0 would be used for the extruder temp and the rest would be a fairly typical setup of fans and extruder stepper.
The problem I keep running into is that io0.in does not seem to be capable of being used as a Z-Probe input. All configuration examples and the configurator seem to want me to plug the PINDA v2 into Temp 0 or 1. If I do this there won't be enough temp ports to support the PINDA temp probe on the tool board.
Does anyone have some advice on this? I would appreciate any guidance.
At this point, I only see two options. The first would be adding wires for a temp sensor all the way back to the Duet 3 mainboard or piggybacking a second tool board 1LC on the extruder. Neither option excites me.
@Phaedrux The perceived voltage issue was a real blocker for me. I am doing some additional debugging now that I am past that.
I don't mind leaving this here as an object lesson for others. My only worry was the title being misconstrued as an indication of poor quality or a problem when it was in no way justified.
I am now trying to sort out the details of getting a PINDA v2 sensor and a Hemera extruder configured on the Tool Board 1LC.
My goal is to eventually have the thermal compensation in the PINDA v2 probe working but let's call that a stretch goal. Now I just need it to act as a basic endstop.
If this gets beyond me I will start a new thread with an appropriate title.
Note - I would have no issue with deleting this post and starting another with a better focus on the issues I am experiencing if you would like.
The title implies a problem that doesn't exist and that was my fault. I don't want to create a false impression.
@drobertson123 Obviously this is an IQ test for me that I failed. The voltage offset happened because the ground wire on my probe was in the wrong port of the multimeter.
The 24v reference was showing that value because I tuned the power supply using the same multimeter.
The voltages on the board look perfectly fine, just as I would expect from a Duet product.
I still have other issues. CAN-FD will only sync when the cable from the Main Board is on the Dist Board Out port and I can't seem to get the board to do anything. I am going to spend some additional time debugging now that I embarrassed myself publicly with this.
Hopefully, I can sort out the issues.
I have a Tool Board 1LC v1.0 that I ordered from Filistruder.
I am having issues with it that make me think it is a defective board but I wanted to check if I am doing anything wrong.
I am connecting the Tool Board through a Tool Distribution Board. The voltage is at a solid 24.1v and nothing seems damaged on the Dist Board or the Tool Board.
The Tool Board CAN-FD will sync with the Duet 3 Mainboard only when the cable is connected to the Distribution Board CAN Out port. A M115 B121 command responds with this;
M115 B121
Board TOOL1LC firmware 3.1.0 (2020-05-15b1)
The Mainboard info is;
Board: Duet 3 MB6HC (MB6HC)
DSF Version: 3.1.1
Firmware: RepRapFirmware for Duet 3 MB6HC 3.1.1 (2020-05-19b2)
The main problem is the voltages across the board are all running significantly low.
The Power input is a solid 24.1v
12v outputs are measuring at 8.33v
5v outputs are 1.745v
3.3v outputs are 0.49v
None of the inputs or outputs seem to do anything and I can’t seem to get any values back or make anything work from the board. These voltages stay stable with or without any equipment connected to the board.
Am I missing some jumper or configuration settings? Is the board just broken?
I would like to get this working and am open to any suggestions you have.
@dc42 Thanks, this is exactly what I needed.
I am working on some tweaks to my Duet 3 6HC Mainboard setup. One issue I have had is that the switching power supply powering the system has enough internal capacitance that it powers the mainboard and the Raspberry Pi for almost a minute after I sure off mains power.
Maybe I am just being paranoid, but I really don't like the slow dropoff of power for the mainboard and SBC.
I am considering leaving the power supply on but having a switch that shuts power off to the Duet 3 Vin and the SBC power. Effectively shutting off the system.
The issue comes from finding a switch that can also handle the current I am using for the bed heater. Without that item in the mix, I have some great illuminated switched that would work great. But none of them will also handle the bed current that I am supplying separately.
My question is if leaving the High Current Input powered while shutting off the Vin will damage the board in any way. Will it end up powering the board somehow? Is it going to damage any of the high current control circuits? I am hoping to just be able to leave the high current Input unmanaged but before I go this route I want to be sure I won't damage anything.
If needed I can set up a relay that turns on when the board power comes on. This would allow me to shut down the High Current supply at the same time as Vin, but it is more parts and effort.
Any suggestions would be welcome.
Thanks for the information and good luck with the current challenges. It is easier to wait when I have a clear idea of what is going on.
Is there a place to watch for updates on this?
Any updates on the Toolboard availability? I have had one on backorder from Filastruder since mid-April. Their web site still says they expect them in mid-May.
Is there a timeline on when these will be arriving?
I understand the disruptions going on and am just interested in getting an update.
Having filastruder stock them would be good.
I am ok with paying a bit of a premium but it doubles the price for the board to order it from the US. At that price point, I am looking at more local solutions despite the SAMMYC21 board looking good. I still have one coming to test but I am also playing with the STM Nucleo boards that I can get local for $15, add on the transceiver for $2 and I have a good base to work with.
@JoergS5 said in CAN-FD Generic IO:
I ordered the sammy also, it is available through eb..
What is eb? Is it a source in the US?
The SAMMYC21 is great but the shipping to the US doubles the price. I am hoping that someone here stocks them so we can get them at a more reasonable price.
@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.
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.
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 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.
@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.
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.
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.
