Duet 2 Ethernet and SBC

@wilriker said in Duet 2 Ethernet and SBC:

Basically everything worked for me except flashing new firmware so it must be something in your config that I do not have that might help to narrow down the problem further.

Ditto. I notice hes using a Duex5 - are you? I'm not.

smoki3

@bearer said in Duet 2 Ethernet and SBC:

@wilriker said in Duet 2 Ethernet and SBC:

Basically everything worked for me except flashing new firmware so it must be something in your config that I do not have that might help to narrow down the problem further.

Ditto. I notice hes using a Duex5 - are you? I'm not.

Maybe it also make a difference if you have just 4 Motor drivers active. I actually have all 10 drivers active

@smoki3 said in Duet 2 Ethernet and SBC:

Maybe it also make a difference if you have just 4 Motor drivers active. I actually have all 10 drivers active

if you upload a sliced file we could test if it is the config or physical presence that makes a difference (if either). running just your config doesn't seen to be a problem with or without Vin, but my simulation doesn't use multiple tools.

smoki3

@bearer said in Duet 2 Ethernet and SBC:

@smoki3 said in Duet 2 Ethernet and SBC:

Maybe it also make a difference if you have just 4 Motor drivers active. I actually have all 10 drivers active

if you upload a sliced file we could test if it is the config or physical presence that makes a difference (if either). running just your config doesn't seen to be a problem with or without Vin, but my simulation doesn't use multiple tools.

Without the duex5 you should get a lot of errors that the motor drivers are not connected. My test file also was just one tool head.

wilriker

@bearer said in Duet 2 Ethernet and SBC:

Ditto. I notice hes using a Duex5 - are you? I'm not.

No, I'm not but since the reason so far is that it's caused by interrupts clashing somehow having to handle more interrupts when DueX5 is connected will probably even worsen the situation.

@smoki3 said in Duet 2 Ethernet and SBC:

Maybe it also make a difference if you have just 4 Motor drivers active. I actually have all 10 drivers active

No, it's not even having the drivers active but in a powered state, i.e. input voltage is > ~10V . Whenever this state is detected it will enable an interrupt to receive data from the drivers. On my setup without DueX5 and without stallGuard I can solve the issue of flashing by just disabling the corresponding interrupt handler in the preparation steps for flashing. But of course this cannot be done in regular printer use.

JoergS5

@wilriker said in Duet 2 Ethernet and SBC:

disabling the corresponding interrupt handler

I always wanted to know but did not find the answer yet, but you may know: is the interrupt request lost then or is it queued?

wilriker

@JoergS5 TBH I am not 100% certain but my understanding is that if the IRQ handler is disabled there is no one interested in this event and then it's discarded. Also since interrupts are high priority "look at me NOW!" events I don't think it would even make sense to queue them.

JoergS5

@wilriker thank you! I feared it. I am currently reading books about Cortex MCUs, but this question is not answered yet.

wilriker

@JoergS5 I would assume that this behavior is not limited to microcontrollers but due to the NOW!-nature of interrupts it doesn't make sense on any platform to store them - I imagine this similar to dropping broken/not-fetched-in-time frames in video playback since it would not make sense to insert them at a later point in the stream.

JoergS5

@wilriker the Cortex interrupts can nest, ie a higher priority can interrupt an interrupt, the original one proceeding after. I ask because in RRF is a place with interrupt disabled with the comment to hold execution time as short as possible. Makes sense then.

wilriker

@JoergS5 Oh, you mean when there actually are handlers for different interrupts. I thought you were talking about what happens when the interrupt handler is disabled. Misunderstanding.

That's actually a field of learning for me still, too.

But more relevant to this topic again: it's not simply interrupts clashing but interrupts also using DMA. So there are multiple priorities to juggle.

JoergS5

@wilriker no, you understood me correctly, I meant it the way you answered.
I was talking about nested interrupts (NVIC) only because they are in a sense a queuing mechanism, because if a higher interrupt comes, the interrupt which is running is saved and later proceeded.

smoki3

I give up!
I can not get any stable connection between my raspberry and the duet.

I tried different cables, removed all high current wires in the near of the raspberry. Connected every GND Pin directly to my Power Supply.

@smoki3 said in Duet 2 Ethernet and SBC:

I tried

did you try without the duex? i realize you probably need the duex, but if nothing else it could help narrow down what to focus on

smoki3

@bearer said in Duet 2 Ethernet and SBC:

@smoki3 said in Duet 2 Ethernet and SBC:

I tried

did you try without the duex? i realize you probably need the duex, but if nothing else it could help narrow down what to focus on

Not as easy. Then I have to wire my complete printer again

If I could load and simulate with your config shouldn't you be able to just disconnect the 50 pin ribbon and power and run a simulation as well?

smoki3

@bearer then I already get a lot of errors while booting, because the drivers are missing

wilriker

@smoki3 Don't worry about your wiring. It most likely is a firmware issue. Unfortunately I did not have any time since the last time I wrote here to look into that.

Baenwort

So when this works for the Ethernet model would it be possible to run spaghetti detective?

Also, for the D2E, would this offloading to the SBC enable smoother segments on Delta's using mesh compensation?

@Baenwort said in Duet 2 Ethernet and SBC:

possible to run spaghetti detective?

Presumably you'd need to pause the Duet either by triggering on a input pin or sending g-code to pause - as such how the SBC is connected doesn't really matter much except you can use echo M25 | sudo CodeConsole rather than say curl ..blah blah.. or echo M25 > /dev/ttyAMC0 which might require a little setup and flushing of the usb serial first?

As for smoother I can't say I'm authority on it, but unless the bottleneck was reading g-code from the SD card moving to a SBC isn't going to improve the handling as the realtime motion planning from the g-code is still done on the Duet.