hot swapping low-voltage can-fd boards (SAMC21)

tristanryerparke

I'm trying to create a modular tool changing system for a machine that isn't a 3D printer (re the Stratasys patent), that uses pogo pins to switch between several very complicated tools. In any case the system I'm prototyping won't be for sale.

I'm aware of these two threads:
https://forum.duet3d.com/topic/31988/dynamically-changing-tool-connectors-during-a-print/13
https://forum.duet3d.com/topic/18006/are-toolboards-hot-swappable

My current setup has a sammy and a termination resistor connected directly to a duet 3 mini running 3.4.5. I'm pretty sure that the can-bus connection is not broken upon the disconnection of the board, as the resistor stays in place and the board is connected via a short leg.

Ideally each tool would have a Sammy-C21 on a custom pcb with assorted peripherals to drive the tool. Since the sammy can be run on 5v, there seems to be no serious risk of hot-plugging the board during a tool change. However I can't get the mainboard to register/unregister the hot-plugged board correctly. Here is my daemon.g that I am using for testing:

while true
	if {exists(boards[1])}
		if boards[1].uniqueId = "7PX9P-U89R9-N25J0-4AUKW-LAN1Z-RR8YU"
			echo "found board 1"
		else
			echo "found something other than mainboard"
	else
		echo "could not find board 2"
	G4 S1

When plugging the sammy in during operation, daemon.g only echos the "found something other than mainboard" case. M999 B1 does not force the mainboard to acknowledge the Sammy either.
When booting up with the sammy connected, daemon.g echos that it can detect board 1 via its uuid indefinetley even if it is unplugged.

With the introduction of low volatge boards like the sammy and the rp2040, I think hot swapping of can boards could be very useful in some systems, especially the robotic.

So I'm hoping there is a way to reset the can connection in the same way that a reboot does in the current firmware without losing stepper position or other modal settings, and if not I'd like to make a request for this in the future.

Thanks,
T

dc42

@tristanryerparke what echo commands does daemon.g generate if you boot up with the sammyc21 connected, then remove 5V power from it for several seconds, then reapply 5V power?

tristanryerparke

@dc42 the "found board 1" messages continue when removing 5V power from the sammyc21, and continue after re-applying 5V.
Same thing happens when removing canL+canH+5V+GND (simulated pogo pin situation).
My initial test from the first post was just removing canL and canH.
Thanks for the quick response,
T

dc42

@tristanryerparke thanks. So are you saying that:

If the SammyC21 is connected when you start the main board, it recognises it (as expected)
If you then disconnect the SammyC21 it doesn't recognise that it has been lost (this is also expected behaviour for the current firmware)
If you power up with the SammyC21 not connected, and subsequently connect it, it is recognised that a board has been connected but the unique ID is not matched

tristanryerparke

@dc42 Yes, and in the third scenario where the SammyC21 is connected, the unique ID in the object model browser reads "".

tristanryerparke

@dc42 Is there any way to "refresh" the CAN-FD bus with the current firmware? If not what are you thinking for the future of this kind of functionality.
Best,
T

dc42

@tristanryerparke you can send a M999 B# command (where #is the CAN address of the SammyC21). That should cause SammyC21 to reset and then send its details again.

dc42

@tristanryerparke I have not been able to reproduce the issue you reported. If I power up the main board with the sammyc21 not powered, then I later provide power to the sammyc21, the unique Id does appear in the object model. However, I am running firmware 3.5.0-beta.3 on the main board and 3.4.3 on the sammyc21.

tristanryerparke

@dc42 I just did a little more testing and also upgraded to 3.5.0-beta.3 on both boards.

two situations:

When powering the mainboard up with power disconnected from the sammyc21, and then connecting it, I see a similar result to what you mentioned, where the unique Id eventually appears in the OM browser.
When powering the mainboard up with (only) can disconnected on the sammyc21, and then connecting the bus, the OM fields for that board are unpopulated and only the address field is correct. This state does not seem to go away unless I send a M999 B124 to reset the board, and then the fields are populated correctly.
When powering up the mainboard with can and power disconnected from the sammy, and then connecting both, I get the same result as my first bullet point.

Is there any benefit to using 3.4.3 on the sammy like in your test case?
Thanks,
T

dc42

@tristanryerparke said in hot swapping low-voltage can-fd boards (SAMC21):

Is there any benefit to using 3.4.3 on the sammy like in your test case?

Probably not. I will try to replicate your results using 3.5beta3.

dc42

@tristanryerparke I have now tested using 3.5beta3 and the uniqueId field does get populated when I make the CAN connection after powering up both the main board and the SAMMYC21.

The only reason I can see why the uniqueId would not get populated is if the SammyC21 was running firmware earlier than 3.4.0. But in that case the uniqueId field would never be populated.