@troydeming said in Help with new setup please:

@troydeming

So when I try to home x using g29 x or hitting the home button or the home all button the x will move in the correct direction but stops after about 10 mm.

You don't use G29 to home, you use G28.

Please post your homing files AND be sure and use the </> tag to paste them right into your post so we can all see them without having to download files.

Frederick

@developeralgo222 said in Homeall.g fails when homing all axes:

Does each nozzle have it's own endstop sensor?

Yes, Each Nozzle has its own endstop . With CAM kind of shared axis when it moves down 1 nozzle the other stays at zero or is lifted back to zero point by the spring to where there is a stopper to prevent it from flying over.

OK.

Since you are using NPN sensors the outputs pull the inputs they are connected to to ground (GND)

I'm assuming only one of the sensors has the beam of light blocked when the nozzle is down.

If I am reading the spec sheet correctly the white wire is pulled to ground when the beam is blocked.

If so, you would want to connect both of the white wires to the Duet input and use the ! prefix character to treat the low input signal as active.

As before you would have a G1 H1 move in the direction of the sensor.

Are these nozzles simply up or down OR do they move over a range of vertical travel?

Frederick

@mballin Ended up being the emergency stop switch, after removing was able to print with no problem! Thanks for the help!

@emi100 said in Sensorless Homing problems on Duet 3 Mini 5+:

I have tried changing the V parameter from 500 to 2000. Any value for feed-rate returns the same errors, either too slow or too fast.

The homing speed needs to be faster than that set by the M915 H parameter, and slower than the speed set by the M596 V parameter. I have a 0.9° motor on X, and as you're using a Prusa Mk3 or 4, I expect you are too. For example, if I send:

M569 P0.0 S0 D3 V10 M569 P0.0 Drive 0 runs in reverse, active low enable, timing fast, mode stealthChop, ccr 0x00053, toff 3, tblank 0, tpwmthrs 10 (468.8 mm/sec), tcoolthrs 117 (40.1 mm/sec), pwmScaleSum 21, pwmScaleAuto 2, pwmOfsAuto 205, pwmGradAuto 28, pos 632 M915 X H400 S3 R0 F0 M915 X Driver 0.0: stall threshold 3, full steps/sec 420, coolstep 0, action on stall: none

In M569, the changeover speed from stealthChop (which we need to use for stall homing) is 468.8mm/s, or 28,128mm/minute. Any speed below this for homing is fine.
In M915, H400 sets the minimum speed to 420 full steps/sec (I think it adds 5% to the H parameter value, not sure why). I have x16 microstepping, and 160 steps per mm, so (420 x 16) / 160 = 42mm per second, or 2,520mm/min as the lowest speed.

Here's my configuration for stall homing, on a Mini 5+. It will depend on your M92 steps per mm and M906 current setting,

in config.g

M569 P0.0 S0 D3 V9 ; x0 - low V for high changeover speed M574 X1 S3 ; define endstop for stall detection

My axis speeds, accelerations, steps per mm etc:

; Axes M584 X0.0 Y0.1 Z0.2:0.4 ; set drive mapping M906 X1000 Y1000 Z800 ; set motor currents (mA) and motor idle factor in per cent M350 X16 Y16 Z16 I1 ; configure microstepping with interpolation M92 X160 Y160 Z800 ; set steps per mm M566 X300 Y300 Z12 ; set maximum instantaneous speed changes (mm/min) M203 X9000 Y9000 Z600 ; set maximum speeds (mm/min) M201 X2000 Y2000 Z20 ; set accelerations (mm/s^2)

in homex.g

M915 X H400 S3 R0 F0 ; stall detection M400 ; Wait for current moves to finish M913 X50 ; drop motor current to 50% M400 ; Wait for current moves to finish G91 ; relative positioning G1 H1 X-250 F4000 ; move quickly to X axis endstop and stop there (first pass) G4 S1 ; pause for 1 second G1 X25 ; move +25mm G90 ; absolute positioning M400 ; Wait for current moves to finish M913 Z100 ; return current to 100% M400 ; Wait for current moves to finish M569 P0.0 S0 D3 V2000 ; x0 - high V for low changeover speed

It probably doesn't need all the M400 commands, it's just what I ended up with.

Ian

@dc42

Yes its the DWC

Gettings alternate messages - Disconnected and Connection Established.

Now i have removed the multipled system.

The endstop is not able to communicate when a M119 command is sent from the DWC

@wayneosdias thanks for confirming that

@developeralgo222 If they are not aligned at any height then that's a different problem form the not being aligned at 0 only.

In your original post you mentioned

@developeralgo222 said in Perfect Horizontal Line alignment for Z-Axis Stepper motors:

I command the motor with Gcode to
move a distance 10 mm/Degree , then 5 mm/Degree and then 4 mm/Degree

after moving to the Z20 position are they correctly aligned (or really, is the alignment the same as when they started the move. If not why not? I see you have 1 Z driver, but then also U, and V which are in the comments referred to a Z, each of those in the comments is described as having two motors per driver. what is getting out of sync. the motors on different drivers or the motors on the same drivers, or both?

Your commands are wrong. This works well for me:

M586.4 S"test" O2 M586 P4 H192.168.1.198 R1883 S1

Published messages from other clients come in as expected as generic messages in DWC. But it looks like there was indeed a problem using M118 P6, up to the next version M118 L6 needs to be used instead. I'm going to fix it in the next release. Example:

M118 L6 S"message" T"test"

@Phaedrux over an hour after it hits phase 4 and has settled

@michaelr123 if the 5V LED isn't lit then either the 12V regulator or the 5V regulator has failed. I suggest you use a multimeter to check whether 12V is present at the input to the 5V linear regulator IC.

@fcwilt so far I got a tempral solution till I find a proper solution, I modified the start gcode to position the sensor out of printbed and so it doesnt get all the heat, I leave door open so chamber doesnt get hot. After probing I tape the pin to be sure it stays up, then close the door as soon as print start. LOL

I looked for info and I found it: https://reprap.org/forum/read.php?1,873463,873463 reports something very similar. There are other similar posts on other forums too. and the nice find is:
https://www.reddit.com/r/klippers/comments/102ycc3/bltouch_temperature_drift_over_time_seckit_cube/
and pictures of the process: https://imgur.com/a/bJwce1D/

Basically he reposts the same and his solution was to remove the electronics from bltouch body and take it to a cooler place doing a very surgical cabling work.
I have still 2 working bltouchs so I might give a try to this project.

Sorry for blameing duet electronics in the past!!!!!!

Just a quick note: I am putting some finishing touched to a plugin that supports USB cameras. It should be ready in a few days . I've always found motion can be somewhat heavy in terms of CPU load (its got a lot built into it).
This plugin is fairly minimal: http endpoint, scaling(8 resolutions), rotate (90, 180, 270) and format choices (most will use the default MJPEG).
Its based on an earlier streamer I wrote so it should be pretty robust on day-one.
I'll post details when I'm done.
It won't be for everyone - but I think it has enough for many (and its a plugin 🙂 )

My test platform is Bookworm and DWC 3.6.0-beta.4

@engikeneer thanks for the answer. Can you share your config of bltouch?