Duet Maestro Freefall

LeonMF

I hope this printer becomes a solid workhorse but, I'm afraid, it is still more of a beta solution and this particular problem is one of the more vexing ones!

LeonMF

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

mrehorstdmd

Wow! I'd say something needs to be done about that.......

deckingman

@leonmf OK. So what seems to be happening is that the bed is being driven in minus Z because those moves are very much faster than gravity with no power. So if it's being driven, then there must be something in your files telling it to move to Znnn at a feedrate (speed) of Fnnn. Might be an idea to post your home Z file, or at least take a look at it and see what is being commanded after the probe or stall detection or whatever method you use to home, has been triggered.

Edit. And/or you have the steps per mm for Z set wildly wrong.

wilriker

@leonmf For one @deckingman is right, the last one is definitely driven by the motor. You can even hear the high pitched sound of the motor running at a very high speed. Please post homez.g, homeall.g and maybe also your config.g.

deckingman

@wilriker said in Duet Maestro Freefall:

@leonmf For one @deckingman is right, ...................

Manuel, mind if I correct your translation? That sounds a bit like "For once deckingman is right" To a native English speaker, that means the person is usually wrong but on this occasion was right. Now of course, you might have meant that I'm usually wrong, in which case no correction is needed

wilriker

@deckingman said in Duet Maestro Freefall:

Manuel, mind if I correct your translation? That sounds a bit like "For once deckingman is right" To a native English speaker, that means the person is usually wrong but on this occasion was right. Now of course, you might have meant that I'm usually wrong, in which case no correction is needed

Thanks and I never mind being corrected! Also I definitely did not want to say that you are usually wrong because I know better. (And I don't mean I know better not to say it but I know better that this would not be true).

But one thing I wonder now: I wrote "For one" and wanted to say "First of all" whereas you corrected "For on_c_e" (which I would have known to have the meaning to described). So would my wording have expressed what I wanted to say?

dc42

I agree, the motor is definitely driving the bed down.

Is the printer definitely being controlled by a Duet Maestro? I believe M3D used other Duets in early machines, before the Maestro became available. So I am wondering whether your machine is running a Duet 2 Ethernet and the stall detection is configured to do something silly.

deckingman

@wilriker said in Duet Maestro Freefall:

But one thing I wonder now: I wrote "For one" and wanted to say "First of all" whereas you corrected "For on_c_e" (which I would have known to have the meaning to described). So would my wording have expressed what I wanted to say?

Yes, you did say "for one" but it's not a common or normal expression. So the meaning of what you wrote was clear but it's an unusual thing to say. Hence it could easily be misinterpreted as a typo and the actual meaning was something else. Whilst I always enjoy these little chats, this probably isn't the time or place to discuss the finer points of English grammar.

wilriker

@deckingman said in Duet Maestro Freefall:

Whilst I always enjoy these little chats, this probably isn't the time or place to discuss the finer points of English grammar.

You are right and we should put a stop to hijacking this thread. Thanks for clarification, though.

LeonMF

@dc42 This is definitely a Duet Maestro. I can post a board picture later if you want confirmation.

Firmware Name: RepRapFirmware for Duet 2 Maestro
Firmware Electronics: Duet Maestro 1.0
Firmware Version: 2.01beta1(RTOS) (2018-06-23b1)
Web Interface Version: 1.22.1

Here is my current config:

https://www.dropbox.com/s/aeppocjnft4zg4q/Promega Config.zip?dl=0

I looked for an a M915 command in the files but found nothing, Typing M915 into the gcode console says not supported. Is there something else I should be looking at?

Dougal1957

Could this by due to the fact that you have Deploy/retractprobe files in the sys directory there was a note on one of the firmware updates to remove them as they caused issues?

wilriker

What confuses me more is that on the one hand the config defines

M574 X2 Y2 Z2 S0 ; Set xy end-stops types (S0 is active low, applied to XY)

a Z-max switch as an endstop in machine_endstoptypes.g and then also

M574 X2 Y2 Z2 S0 ; Set xy end-stops types (S0 is active low, applied to XY)

a switch-based Z-probe in machine-zprobe.g.

Additionally at the start of homez.g there is

; Ignore Machine boundaries
M564 H0 S0

and I am not sure how this influences the latter

; Rapid Z until limit switch triggers
G0 Z450 F1500 S1

in the same file.

So @LeonMF can you give some more information on what your endstop for Z actually is?

Dougal1957

The way the config has been written with all those called macros is very confusing that's for sure it seems to be very over complicated

wilriker

@dougal1957 said in Duet Maestro Freefall:

The way the config has been written with all those called macros is very confusing that's for sure it seems to be very over complicated

Hehe, I was in the process of changing my config to the same style a couple of days ago until I realized that this will make it less readable then before and reverted everything back.

LeonMF

@dougal1957 I'm with you. That's the way it came from M3D and I haven't taken the steps to merge them yet. I see what they were trying for but I don't think they realize how painful it is to dig through!

LeonMF

@wilriker The system has a max travel Z-endstop at the bottom of Z travel used for homing. There is also a manually deployed limit switch probe and an IR probe attached to the hot end. The deployable probe and the IR probe are either/or changed in one of the files.

@Dougal1957 I don't know about the deploy/retract files. The system can't use them and they are in the M3D default image. They left Homedelta, too and I'm pretty sure that's not needed.

wilriker

@leonmf said in Duet Maestro Freefall:

@wilriker The system has a max travel Z-endstop at the bottom of Z travel used for homing. There is also a manually deployed limit switch probe and an IR probe attached to the hot end. The deployable probe and the IR probe are either/or changed in one of the files.

OK, I see.
So what exactly are you doing to get this horrible bed race towards the bottom effect? Is it homing Z or bed leveling?

I don't know about the deploy/retract files.

They are empty anyway.

LeonMF

@wilriker The bed crash is caused when the z is driven into an immovable object like the hot end and stalls out. This is, presumably, triggering a fault of some sort and the user theory on the M3D discord is that a mosfet disconnects the motor connection and lets it freewheel.

I'm not electrically savvy enough to know if this is what's going on. I'm pretty good with config files but when we get into esoteric electrical properties I get lost!

deckingman

@leonmf said in Duet Maestro Freefall:

@wilriker The bed crash is caused when the z is driven into an immovable object like the hot end and stalls out. This is, presumably, triggering a fault of some sort and the user theory on the M3D discord is that a mosfet disconnects the motor connection and lets it freewheel.

I'm not electrically savvy enough to know if this is what's going on. I'm pretty good with config files but when we get into esoteric electrical properties I get lost!

That might be the intent, but the behaviour on the videos isn't free-wheeling - that's being driven fast away from the hot end. Free wheeling would be like you get when switching the power off. As I said earlier, somewhere there is a command to drive Z at high speed away from the hot end. Maybe it's trying to home to Z max but the Z max stop isn't triggering.