Duet Maestro Freefall

LeonMF

The current behavior is that when the bed is pushed up into the nozzle, I would expect this to overcome the motor torque and cause a skipped step. Instead the motor seems to reach current limit, the driver shuts off(?) and the the bed drops at a high rate of speed (gravity? Feels like faster than gravity) and crashes to the bottom. I could take the hit and provide a video if needed for diagnostics.

fcwilt

@leonmf said in Duet Maestro Freefall:

Instead the motor seems to reach current limit, the driver shuts off(?) and the the bed drops at a high rate of speed (gravity? Feels like faster than gravity) and crashes to the bottom
Hi,

Is the movement in the axis so free the the bed will drop on it's own due to gravity?

Could you post a picture of your machine?

Thanks.

Frederick

LeonMF

@fcwilt Yes, the bed is belt driven from a single Z axis motor. With the stepper disabled, the bed will slowly drop while acting as a generator. When the stall detection kicks in (I just learned this was a feature and I presume they may be using M915? I'm going to check when I get home) the motors are disconnected from the stepper and the bed falls like a rock. Given that it's a 15x15 glass bed with aluminum frame... this is undesirable behavior and will break things!

https://store.printm3d.com/pages/promega

I can post a picture later if you still want one.

fcwilt

@leonmf said in Duet Maestro Freefall:

I can post a picture later if you still want one.

Thanks much. That is a large and pricey printer. I guess for that kind of money that can provide a low friction setup.

My FT5 moves smoothly but it slowly sinks down without crashing.

Frederick

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!