Duet Maestro Freefall

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.

Dougal1957

I am just wondering if it maybe caused by those deploy retract files Remember when lots of people had strange CoreXY Movement behaviour at the time of a particular change and the release notes at that time did say to delete them.

IMHO you have nothing to lose by deleting them and trying again.

Doug

PS I have to agree with Ian and David that bed is being driven at high speed in the Positive Z Direction.

deckingman

@dougal1957 said in Duet Maestro Freefall:

I am just wondering if it maybe caused by those deploy retract files Remember when lots of people had strange CoreXY Movement behaviour at the time of a particular change and the release notes at that time did say to delete them.

IMHO you have nothing to lose by deleting them and trying again.

Doug

Good call Doug.

LeonMF

I'm at work and can't test right now but I'm 99% positive that the bed isn't being driven down in the crash situation. I'll try to do some testing tonight.

deckingman

@leonmf said in Duet Maestro Freefall:

I'm at work and can't test right now but I'm 99% positive that the bed isn't being driven down in the crash situation. I'll try to do some testing tonight.

Well whatever. How do you explain that it drops faster in the second two videos with power applied, than it does with no power to the steppers as in the first video?

wilriker

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

I'm sorry, I was not clear enough: I wanted to know which action you had to take that led to your third video. What did you command to printer to do? Home Z? Bed leveling? Start a print? You must have done something so that the printer started moving and eventually this led to the crash. I want to know what was the last thing you did. This information is required to narrow down where to search for the problem.

Re being driven: At least in the third video you linked I can hear the motors and as Ian already pointed out (and you also said somewhere above) it is much too fast to be only due to gravity.

LeonMF

@wilriker I'll do a test to confirm free-fall vs driven tonight.

To make this happen, I stalled the motor by jogging the bed up into the nozzle slowly until it stalled and exhibited the crash behavior.

LeonMF

Slow motion video with object on bed showing that we're not moving faster than unassisted freefall:
https://youtu.be/c3VssMlqBgU