Duet 2 Ethernet and SBC

A Former User

@wilriker said in Duet 2 Ethernet and SBC:

But it also happens if the internal regulators are not even used

still use the 3.3v one i suspect, which is where the load from the Ethernet module would be; but it shouldn't be affected by Vin.

i've just been to collect my 8 channel thingy and hope to take a look later if I get some helping hands

update: Pi died (likely unrelated to SBC testing, as it died over night with no SBC connected) but further testing on hold pending a new Pi.

smoki3

Anyone found a solution?

Could it be a software issue?

wilriker

@smoki3 Unfortunately not yet. @bearer wanted to put a scope on it and I am still waiting for my scope to finally arrive so I can also have a look at what happens there, too.

I think software is unlikely.

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?