Duet 2 Ethernet and SBC

wilriker

@smoki3 As you can see it's simply something cobbled together on my desk. It is configured as a simple 3 axis Cartesian and is only pseudo-homed using G92 XYZ. So maybe that is the problem already. If possible you could test if it works for you if you use G92 as well. Maybe it's just stallDetect that fails.

smoki3

@wilriker said in Duet 2 Ethernet and SBC:

@smoki3 As you can see it's simply something cobbled together on my desk. It is configured as a simple 3 axis Cartesian and is only pseudo-homed using G92 XYZ. So maybe that is the problem already. If possible you could test if it works for you if you use G92 as well. Maybe it's just stallDetect that fails.

As far I remember homing was one of the main issue. But let me check again with beta 2. I will come back to you

seraser

Can anybody explain me advantages of sbc attached to duet?

wilriker

@smoki3 said in Duet 2 Ethernet and SBC:

As far I remember homing was one of the main issue. But let me check again with beta 2. I will come back to you

I tried stallGuard as endstop now (manually blocking the motor shafts) and still no problems. So maybe putting the LinuxInterface into its own FreeRTOS task solved it eventually. Looking forward to your feedback.

A Former User

@seraser said in Duet 2 Ethernet and SBC:

Can anybody explain me advantages of sbc attached to duet?

for now not much more than being able to run DWC on a hdmi touch screen instead of paneldue (and more flexible networking as you'll have both wifi and ethernet).

but as plugins are added to DSF it will offer added functionality (and of course its easier to develop your own stuff on the pi rather than in the reprap firmware)

arhi

@seraser said in Duet 2 Ethernet and SBC:

Can anybody explain me advantages of sbc attached to duet?

none attm

probbly "plugins" in future, plugins that will be capable of modifying g-code real time while printing (like octoprint for e.g.)

seraser

Thank you @bearer and @arhi so I will not play with my rasp4.

jay_s_uk

@seraser the wifi is much better using an SBC than the wifi onboard. That's about it

seraser

@jay_s_uk I know WiFi is weak in duetwifi so I've installed wifi repetier near for three printers with duetwifi, thank you.

arhi

@jay_s_uk rpi's wifi is not that good neither

smoki3

@wilriker so I assembled again my duet 2 ethernet/sbc today to my tool changer. I tried beta 2 and self compiled version from today. Both are not working. Still not able to home my axis. The printer is hanging for ever.

I still get some of these in my console:

	Warning: Lost connection to Duet (Timeout while waiting for transfer ready pin)

Please find attached the macros and config

https://drive.google.com/file/d/1FoRAUD1e0sretY_o9-dE64mefawPdo6K/view?usp=sharing
https://drive.google.com/file/d/1e9l60tG5hqTCH676g0_RTc9dDypd09Uk/view?usp=sharing

jay_s_uk

@smoki3 that error pretty much always points to a wiring issue.
We get that a lot on the LPC/STM port when new users first start out so I would go back to inspecting your wiring.

arhi

@smoki3 are you using duex too? if I remember correctly duet2+sbc is not working if you use duex too ... I might be wrong

gloomyandy

@smoki3 "Warning: Lost connection to Duet" may mean that the firmware has stopped responding. Are you getting any sort of firmware reset/crash?

smoki3

@arhi said in Duet 2 Ethernet and SBC:

@smoki3 are you using duex too? if I remember correctly duet2+sbc is not working if you use duex too ... I might be wrong

We try to debug it. As you read this thread completely... This was the reason for starting of this thread. It never was about the hardware/pcb design

smoki3

@jay_s_uk doesn't seems to be any wiring issue. As you read in the thread I already tested all of different wirings...

smoki3

@gloomyandy said in Duet 2 Ethernet and SBC:

@smoki3 "Warning: Lost connection to Duet" may mean that the firmware has stopped responding. Are you getting any sort of firmware reset/crash?

Sometimes it crashes sometimes it hangs forever until I do a manual reset.

gloomyandy

@smoki3 It is unusual for the firmware to hang (the watchdog timer usually catches those and causes a timeout). But if you are getting resets then the output from M122 may tell you more about the cause and the stack trace may allow you (with the use of a map file) to track down where the reset happened. If you are building your own firmware you should have (or be able to generate) a map file. Doesn't always work out but a lot of times it helps!

smoki3

@gloomyandy I assume that there a some communication issues between the firmware and the rpi. So messages get lost and the raspberry wait for a confirmation from the firmware.

Lets see if wilriker find something. As he also mentioned before in this thread he also assume that this is a firmware issue.

gloomyandy

@smoki3 Fair enough, but you might still want to save the output from m122 after any resets (and perhaps make them available to wilriker). I look after the LPC/STM port and that information is very useful when trying to track down what is going on.