@dc42 said in [Dave's so proud]

So if P7 worked, he must have his BLTouch connected to the Z endstop input; whereas P9 requires it to be connected to the Z probe input.

One thing I have noticed is that folks who are not good at attention to details often struggle with configuring 3D printers (and other things as well).

Aside from the occasional mistake they we all make from time to time it is clear you very much know what you are doing.

Thank you for your hard work, the Duet family of products has made building my printers so much easier and enjoyable.

Frederick

@dc42

1 - END by itself is easy but if you don't see it in context you don't know what it is the end of. It might be better to have unique keywords - ENDWHILE, ENDIF or something along those lines.

2 - I would make the use of the new keywords mandatory. Yes existing users would have to do a bit of work but it would keep things simple and consistent for all in the future.

3 - While you are implementing the change I would also suggest that a REPEAT/UNTIL or a DO/WHILE loop be implemented - the type of loop that always runs once.

Frederick

@kwad3d-0 said in BL Touch Issues... Again and Again...:

@fcwilt my height map looks better then that however still lifts off on one side by about 1mm. So You don't know what your talking about and are just trolling at this point. You have not contributed anything at all besides criticizing my terminology I use. I don't want you to comment any longer and be on your way now...

I think you are confused about who may be a troll.

But since you are so wise I'm sure you can solve this simple problem on your own.

Have a great day!

Frederick

@alankilian said in My wish : Inputs debouncing:

Thank you for letting me get confused at times.

We all get confused, make mistakes, make assumptions, read things wrong, etc.

It's just the nature of forums.

Generally we as a group get it sorted in the end.

Frederick

@dc42

I am very happy with RRF v3.

I did not find the changes from v2 to v3 as extensive as I first imagined.

As I have progressed from v3.0.0 to v3.1.1 to v3.2.0 to v3.2.2 I have not encountered any changes I had to make.

I did make changes to take advantage of new features but they were changes I chose to make, not had to make.

I am very impressed with the folks who are developing the firmware for the various products.

As in many aspects of life some few folks are hard to please and I see little reward in trying to.

Kudos to you all.

Frederick

@BDPrinters

The last G30 P2 has F550 instead of Y550

Frederick

@fcwilt

Hi,

Here is a link to a quick-and-dirty video showing the mini linear guide at work.

Mini Linear Guide At Work

It was hard to get a good view - sorry.

Frederick

Hi,

It would be nice if you could add some white space at the left margin of the editor.

As it is the cursor tends to be hard to see when at the left margin.

Thanks.

Frederick

@apairofcleats

Just remember to follow the correct procedure.

You must first update to 3.0.0 then to 3.1.1

Upload Duet2and3Firmware-3.0.zip

When asked let the update proceed.

Upload Duet2and3Firmware-3.1.1.zip

When asked let the update proceed.

If all goes well you should be running firmware 3.1.1 and Duet Web Control (DWC) 3.1.1

Frederick

@cando415

You have this in your Y homing file:

G1 H1 Y+360 F6000 ; move quickly to Y axis endstop and stop there (first pass)
G1 Y5 F6000       ; go back a few mm
G1 H1 Y+360 F360  ; move slowly to Y axis endstop once more (second pass)

All three of those moves are in the same direction.

Based on the G1 H1 moves the G1 Y5 should be G1 Y-5.

Frederick

@Timothee-Leblond

Now to risk really confusing you.

Here is my routine for setting the Z=0 datum - and as I warned you I make use of a lot of different routines that encapsulate commonly used chunks of code.

; =========================
; === probe_set_z.g BOF ===
; =========================

M98 P"check_homed.g" W"probe_set_z.g" X{null} Y{null} Z{null}

M291 R"Setting Z=0 Datum" P"Please wait..." S0

M98 P"probe_config.g"           ; insure probe is configured

M98 P"cancel_mesh_bsteps.g"     ; cancel any mesh compensation and zero the baby steps setting

M98 P"move_to_z_home.g"         ; position at Z home for probing

M98 P"probe_to_center.g"        ; move probe to bed center

G30                             ; do single probe - sets Z to probe trigger height

M98 P"move_to_z_home.g"         ; return to Z home

M98 P"tool_to_center.g"         ; move tool to back to bed center

M291 R"Z=0 Datum has been set" P"OK" T3

; =========================
; === probe_set_z.g EOF ===
; =========================

Don't worry if it makes little sense - if you wish I can explain it all in detail.

Just don't get over whelmed by my approach - I've been doing this work for several years.

Frederick

@Timothee-Leblond

With a single tool machine you would typically have zero tools offsets (G10) and the probe would be specified as being offset (G31) with respect to the tool.

I hope I don't confuse you but I will show you how I do things.

I make use of a lot of different routines because I have found I was doing the same thing in several places, so by put that code in a routine I would call the routine.

Don't worry about the details of the first two M98 calls, the routine names should suggest what is being done.

This routine does what it's name says - it moves the probe to the center of the bed, regardless of the current probe offsets, because it uses the current offset values to compute where the center of the bed.

There are two versions - one is just a little shorter but you can always use the longer one in all cases

; =============================
; === probe_to_center.g BOF ===
; =============================

M98 P"check_homed.g" W"probe_to_center.g" X{null} Y{null} Z{null}
 
M98 P"move_to_z_home.g" ; calls set_z_home.g

; --- short form when center of bed is X=0 Y=0 ---

var xpos = 0 - sensors.probes[0].offsets[0]
var ypos = 0 - sensors.probes[0].offsets[1]

; --- Long form when center of bed is X != 0 and Y != 0 ---

;var xpos = ((move.axes[0].max + move.axes[0].min) / 2) - sensors.probes[0].offsets[0]
;var ypos = ((move.axes[1].max + move.axes[1].min) / 2) - sensors.probes[0].offsets[1]

; --- move probe to center of bed ---

G90                               ; absolute moves
G1 X{var.xpos} Y{var.ypos} F99999 ; move to center of bed at max possible speed

; =============================
; === probe_to_center.g EOF ===
; =============================

@Strider007

To save a value from the Object Model (OM) into a local variable you do something like:

var Xvalue = move.axes[0].machinePosition
var Yvalue = move.axes[1].machinePosition

Or it you want it to be persistent so you can use it later or in other code:

global Xvalue = move.axes[0].machinePosition
global Yvalue = move.axes[1].machinePosition

Good Luck.

Frederick

@Timothee-Leblond

Offsets with respect to what?

M206 is deprecated, so you can ignore it.

G31 is going to set the probe offsets, whereas G10 sets tool offsets or coordinate systems offsets.

Frederick

@Strider007

Those are not to be executed - they are merely variables holding those values.

To use such values, say, to move to a position, you would do something like

G1 X{move.axes[0].machinePosition} Y{move.axes[1].machinePosition}

The question is do those variables hold the values you desire. Compare them against what you see in the DWC, assuming the DWC is showing the values you seek.

Frederick

@Strider007

See if this will work:

For the X:

move.axes[0].machinePosition or move.axes[0].userPosition

For the Y:

move.axes[1].machinePosition or move.axes[1].userPosition

Frederick

@Strider007

Are you asking how to get the X and Y values to use in some gcode?

Frederick

@dc42

Sorry to bother you but I'm trying to understand the reason for the G1 H2 moves.

I saw the comment about being sure the motors are not stalled - that is clear.

But what does the G1 H2 approach achieve that the following wouldn't (just talking X axis here)

G1 H1 X0.5

or

M564 H0 
G1 X0.5 
M564 H1

As I understand it the G1 H2 allows movement when the axis is not homed, which I believe my two examples also achieve.

But does the G1 H2 do something unique that the others I listed don't do.

Thanks for the education.

Frederick

@dc42 @jay_s_uk

Thanks very much to you both.

I appear to have overlooked the obvious - once again.

Frederick

@gloomyandy

I used information I found on the Duet sites for most of the relevant values.

As I mentioned, homing seems to be working fine EXCEPT for the odd Y axis increment as appears on the DWC. I suppose I could do enough X homing to get the change to be enough so I could measure it with some accuracy to determine if it is an actual change or just a displayed change.

Here are the relevant parts of config.g

; === X Y ===

M92  X100   Y100   ; steps per mm (80 for 20 tooth, 100 for 16 tooth)
M350 X16    Y16 I1 ; 16x micro-stepping with interpolation

M203 X35000 Y35000 ; max speed (mm/min) 
M201 X2000  Y2000  ; acceleration (mm/s^2) 
M566 X300   Y300   ; max instant speed change (jerk) (mm/min)
M906 X1600  Y1600  ; motor current (mA) (stepper rating 2A) 

M574 X1 S3             ; configure Xmin using stall detection
M574 Y1 S3             ; configure Ymin using stall detection

; this line also appeared in the homing files - I kept them as I found them.

M915 X Y S3 F0 H200 R0 ; set X & Y sensitivity (S), do nothing when stall (R), unfiltered (F) minimum motor full steps per second for stall detection to be considered reliable (H)

Here is homeX.g - this is based on an example I found - with a change to how the logical/physical positions are synced

G91                      ; relative positioning
G1 H2 X0.5 Y-0.5 F10000  ; tiny moves to energize motors to ensure they are not stalled
M400                     ; wait for any moves to complete
M913 X31 Y31             ; drop motor currents to 25% of 2000mA or 31% of 1600mA yielding 500mA
M915 X Y S3 F0 H200 R0   ; (S) set X and Y to sensitivity 3 (F) unfiltered (R) do nothing on stall
G1 H1 X-400 F3000        ; move left 400mm, stalling at the physical endstop (end of travel) - we hope
G1 X185 F2000            ; backoff to center of bed - move determined by testing
G92 X0                   ; sync physical and logical positions
M400                     ; wait for any moves to complete
M913 X100 Y100           ; motor currents back to 100%
G90                      ; absolute positioning

Here is all of homeY.g - this is based on an example I found - with a change to how the logical/physical positions are synced

G91                      ; relative positioning
G1 H2 X0.5 Y-0.5 F10000  ; tiny moves to energize motors to ensure they are not stalled
M400                     ; wait for any moves to complete
M913 X31 Y31             ; drop motor currents to 25% of 2000mA or 31% of 1600mA yielding 500mA
M915 X Y S3 F0 H200 R0   ; (S) set X and Y to sensitivity 3 (F) unfiltered (R) do nothing on stall
G1 H1 Y-300 F3000        ; move to the front, stalling at the physical endstop (adjustable studs) - we hope
G1 Y120 F2000            ; backoff to center of bed - move determined by testing
G92 Y0                   ; sync physical and logical positions
M400                     ; wait for any moves to complete
M913 X100 Y100           ; motor currents back to 100%