Posted in a separate comment for clarity.

Some time ago, I used to run my home automation system on Raspberry Pi. Then, after that, I ran my home audio on Raspberry Pis. They did work pretty well but were more prone to corruption than I'd like.

The beauty of an embedded board like the Duet 2 is that powering it down and back up meant that it was still going to come back up fine.

My experience with Raspberry Pis were that they are a full OS and don't particularly love being shut down without going through a clean shutdown. Something that a device with an off-switch isn't all that great for. Perhaps my early experiences with Raspberry Pis reflect a fear about dirty shutdown corruption that isn't a reality any more. Do I have any reason to be concerned on this or are my fears several years out of date?

Defining U in config.g before then combining worked for me. Thanks for the help!

Here are some videos highlighting the issue:

Duet Power off free-fall:
https://youtu.be/WCvHGXi6jxs

Duet Power On Free-Fall
https://youtu.be/7uG-6czPOVY

Duet Bed Stall crash
https://youtu.be/QH9c-w1Nbgg

@dc42 said in Duet Maestro Freefall:

M569 P2 D2

Also, thank you everyone for the help. You've helped a whole community of users who were struggling with this issue!

Defining U in config.g before then combining worked for me. Thanks for the help!

@phaedrux There's no reason to treat this like a Promega. I've gutted it, changed the Z drive system to dual lead screws, the rails, the carriage, the board, the bed...

@dc42 @Phaedrux OK, I can certainly modify my config to create the U axis and then combine them. The posted wiki page doesn't say to do that so I missed the obvious!

@phaedrux said in Independent Z with Independent Sensors U steps/mm wrong:

https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors

Yes, that's what I based my config on!

Here is a dropbox link to my config:
https://www.dropbox.com/s/a6954n6rumxr327/MonkeyMega-Config-2019-09-07.zip?dl=0

A whole bunch of months ago, I retrofitted my Promega to have dual Z lead screws with independent sensors for homing. Then I had so many issues with the Maestro board skipping steps, the extruder system behaving badly, and a work trip that kept me busy for several months.

I'm back to it now, I've redesigned the X carriage, swapped in a Duet WiFi that I had lying around while waiting for the Duet 3 and I've got everything pretty much back to working but the Z homing is behaving weird.

I set the U axis at the same steps/mm as Z but in the commented out line the U axis gets 837.20steps/mm and E0 gets 420. When use the second option where I try to set U to 400 after the fact, I get U and E as 420.

[0_1567892760893_MonkeyMega-Config-2019-09-07.zip](Uploading 100%)

I'm on firmware 2.03 and, at this point, I'm at a complete loss as to what to do. I can try putting some overrides in the homez file but I'd rather find out if I'm doing something wrong first!

Posted in a separate comment for clarity.

Some time ago, I used to run my home automation system on Raspberry Pi. Then, after that, I ran my home audio on Raspberry Pis. They did work pretty well but were more prone to corruption than I'd like.

The beauty of an embedded board like the Duet 2 is that powering it down and back up meant that it was still going to come back up fine.

My experience with Raspberry Pis were that they are a full OS and don't particularly love being shut down without going through a clean shutdown. Something that a device with an off-switch isn't all that great for. Perhaps my early experiences with Raspberry Pis reflect a fear about dirty shutdown corruption that isn't a reality any more. Do I have any reason to be concerned on this or are my fears several years out of date?

Thanks everyone!

@T3P3Tony I had this argument with the M3D team when they argued that the PanelDue was a waste of time.

The PanelDue is certainly limited in what it does and how it operates but that's part of the benefit. Fundamentally, it just works and the M3D argument of buying a cheap tablet and using it as a UI completely missed the point that you just need the ability to poke a jog or home button without the drama of maybe the tablet went to sleep or the UI wasn't built for touch.

But... if you're saying that there will likely be a touch friendly UI that works with the SBC and the SBC being operational is required for the unit then I likely have little to complain about!

I've already bought my board (looking forward to it!). I totally didn't even read the specs before buying so I'm now catching up on the whole SBC thing.

So, with the new SBC interface, does that mean that the PanelDue is deprecated? Is/will there be another touchscreen replacement to fill the gap?

Also, is there any reason to avoid or go for a Pi 4 over the 3+?

I've confirmed a loose connector that was still tight enough to work sometimes. Thank you.