Duet 2 Ethernet and SBC

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.

A Former User

@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

A Former User

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?

A Former User

@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.

Baenwort

@bearer the spaghetti detective bit was because with a SBC to act as the plugin host it would be potentially easier to port the octoprint plugin.

The comment about smoothness is because I was told once that because of the complexity of the Delta math that on Duet 2 if you enabled mesh bed compensation that it no longer calculated every point to move but fell back on arcs and segments like ordinary RAMPS. But if a SBC offloads some work from the duet I wondered if more could be calculated with the now freed up resources.

It presumes that the DWC takes up some amount of resources to run on the Duet processor.

deadwood83

OK, here's my thinking on an easy way to connect SBC regardless of ethernet or wifi version.

The header on the side is a 2.54mm, could accept female or male, protrudes past the board edge and sits forward and next to the paneldue header. The adapter is soldered to the bottom in the same manner the ESP is attached to the top. It could also be mounted with pins through it.

Hole for plastic push-fitting to reinforce.

Relief is left for up to a 7mm diameter fastening post around the board mounting screw. Resistors are 470-Ohm.

Anything I am missing?

A Former User

@deadwood83 said in Duet 2 Ethernet and SBC:

Anything I am missing?

maybe some pull downs to the reset/enable lines to ensure no interference (unless rff 3.2 handles that in firmware) could be jumpered for flexibility i guess.

deadwood83

@bearer I think it would be much less intrusive to figure out a way to pull PE4 and PE5 low in firmware.

I poked around in the Duet3 designs and I see that someone (Tony?) had a great idea for v1.1.

Input buffers. With that in mind, I present version two! All parts available for SMT from JLC, incorporates the design guidelines laid out in the duet3, comes to $19.5USD per 10 (please note I am not selling these, this is the price from JLCPCB) (plus shipping). Sadly I did have to bump it to a dual layer PCB.

For V1.04 Duet Wifi, the CS/NPCS0 pin already has a 2k2 resistor. R2 can be bridged in that case.

Fixed the dims.

arhi

@deadwood83 why solder to board instead plugin in to the header?

A Former User

@arhi said in Duet 2 Ethernet and SBC:

@deadwood83 why solder to board instead plugin in to the header?

presumably because wifi boards don't have headers?