Duet 2 Ethernet and SBC

A Former User

Yes, I was supposed to do some digging, did some ~~bike riding~~ flying instead and in summary i now fully appreciate why planes have landing gears ..

Hope to be up and at'en in a few days unless I somehow manage to have another adventure with Mr Murphy

wilriker

I also got my scope meanwhile but it will most likely be only Monday until I can dig deeper into this problem.

JoergS5

I thought about whether it is possible to connect USB of Raspberry and Duet 2, to avoid changing Ethernet/Wifi hardware. The speed of USB 2 of 480 MBit/s should be sufficient.

A Former User

@JoergS5 said in Duet 2 Ethernet and SBC:

The speed of USB 2 of 480 MBit/s should be sufficient.

but the latency and jitter is not deterministic so that might be an issue, and iirc the duet2 chip only does 11 12mbps usb

JoergS5

@bearer thanks, this are arguments against USB.

A Former User

(Potentially) interesting segway; PCIe to SPI adapter AX99100 PCIe to 2S1SPI Demo Board might allow this to run on x86 etc. Just too bad can't seem to find anyone that sells that model, its all 4S and 2S1P all over the usual chinesium sites.

https://www.asix.com.tw/development.php?op=DBdetail&PItemID=256

edit: chip mode is controlled by 3 GPIO lines and the SPI signals are on the parallell port, so moving some 4k7 pull up/down resistors and attaching to the parallell port ~~should~~ could work (if OS supports the SPI driver and moon has the correct phase)

edit edit: very OT, but what got me thinking was the SAMMY-C21 board might be the easiest option to bridge PCIe to CAN-FD to let linuxcnc use the Duet 3HC/1XD/1LC boards without the 6HC/5LC.

JoergS5

@bearer said in Duet 2 Ethernet and SBC:

AX99100 PCIe to 2S1SPI Demo Board

I cannot find it to buy also. But PCIe would be difficult for me anyway because I use laptops primarily. But your idea led me to the idea of USB3 to SPI as an alternative for PCs, so e.g. AN1999 allows USB hubs with additional SPI interface:
http://ww1.microchip.com/downloads/en/AppNotes/00001999B.pdf
Maybe there are products with this chip. The mentioned USB5734 is very interesting, but I found only single chips or expensive eval board so far. The next little PCB project. Now I have a reason to buy a reflow oven

wilriker

I tried to look into the communication problem and discovered that today is Murphy's law day. Basically everything failed on me today with no reason at all and totally erratic (worst thing was that my router died completely and I have no internet except for my smartphone). I cannot even get it to run anymore being powered solely from the RPi.

So nothing new to report yet, unfortunately.

smoki3

@wilriker this does't sounds good. good luck you get everything running again

wilriker

Finally a short update: it is a firmware issue (or at least one that will somehow needed to be solved in firmware) where the SBC SPI bus and the USART SPI bus polling the TMC driver state interfere although they should not - at least in theory.

smoki3

@wilriker said in Duet 2 Ethernet and SBC:

Finally a short update: it is a firmware issue (or at least one that will somehow needed to be solved in firmware) where the SBC SPI bus and the USART SPI bus polling the TMC driver state interfere although they should not - at least in theory.

Nice to hear that it could be hopefully fixed by software

wilriker

@smoki3 Could you please retest with the latest firmware? It's not fixed but so far I can only reproduce this when trying to flash firmware but no other action leads to this issue anymore. Can you confirm? Or else please give a detailed list of when it happens for you.

smoki3

@wilriker Sure I will test. Which branch should I use?

wilriker

@smoki3 Regular v3.02-dev branch.

wilriker

One intermediate thing I noticed: you definitely need a direct ground connection between your VIN PSU and the Raspberry Pi. The connection on the Ethernet/Wifi header is not sufficient for me.

smoki3

@wilriker said in Duet 2 Ethernet and SBC:

One intermediate thing I noticed: you definitely need a direct ground connection between your VIN PSU and the Raspberry Pi. The connection on the Ethernet/Wifi header is not sufficient for me.

First of all, I connected all Rpi GND Pins directly to Ground of the PSU.

Then I now tested the new build but unfortunately I get the same results as before. After homing my printer is hanging forever. (I think the "finish message" of the homing get lost.) For information: All my axes getting homed by stall detection besides Z axis.

Than also as you already told, I get the checksum errors while flashing a firmware. And it is fine again without VIN connected.

wilriker

@smoki3 Just for completeness: regular status updates (MCU temperatur, input voltage, thermistor temps, etc.) do work normally while VIN is powered, right?

smoki3

@wilriker yes this is fine. But this was also fine with the old firmware.

wilriker

@smoki3 Do you have the possibility to change homing to something other than stallGuard to test with that? Using stallGuard would fit into the issue that was found so far that was blocking updates on my setup.

Also can you please confirm that print simulation is working? And if possible heating of bed/hotend. So far it looks to be bound to the motion system (the communication to the TMC2660 in particular) but it's unclear if there are other things that will trigger fault states.

smoki3

@wilriker said in Duet 2 Ethernet and SBC:

@smoki3 Do you have the possibility to change homing to something other than stallGuard to test with that? Using stallGuard would fit into the issue that was found so far that was blocking updates on my setup.

Also can you please confirm that print simulation is working? And if possible heating of bed/hotend. So far it looks to be bound to the motion system (the communication to the TMC2660 in particular) but it's unclear if there are other things that will trigger fault states.

To disable stallGuard I have to do some more work. (Solder some endstops and so on, I can do but need some time)

Heating my hotend is fine. It is heating up as it should. Then I now tried to simulate a print: Then I get the same issue as when I try to home my printer. The simulation starts but hang forever. Then I also not able to send any command to the printer. But at this time I don't see any checksum errors in the terminal.

[info] Selected file /opt/dsf/sd/gcodes/Dreher.gcode
[info] Starting file print
[info] File: Optional macro file start.g not found

I also tried homing all my axis separately and this is working fine.