@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

@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

Hi,

Just for fun I have been experimenting with dual Z endstop sensors, a "normal" one and a "early warning" one.

My current two printers have moving beds on the Z axis and the beds have quite a bit of mass. To avoid possibly slamming into the endstop switch (or end of travel) and possibly causing damage I have tended, in the past, to home at a "safe" speed.

But when I noticed that in firmware 203 that you can specify which physical endstop input to use it occurred to me that it might be possible to change the active endstop input while homing. Short answer - it is.

So I installed two endstop sensors about 30mm apart. Just to be safe, for this test, I used IR sensors which involved no physical contact. I fit a "beam break blade" to the bed that spanned the 30mm so both sensors, when homed, would be activated.

Homing consists of selecting the lower of the IR sensors and moving at a higher than "safe" rate until that sensor is activated. The bed does indeed come to an abrupt and somewhat startling halt.

Now the upper IR sensor is selected and the "normal" home operation is performed at a nice safe rate and the actual home operation is completed.

Now starting homing when the sensors are already activated is a bit different. The lower sensor is selected AND inverted so it is possible for a "pre homing" command to move DOWN, away from home, until the lower sensor is no longer activated. Then the two "normal" homing commands are issued.

When the lower sensor is already cleared the "pre homing" command doesn't have any effect so there is no downward movement at all.

The same could be done with micro-switches with a somewhat different physical arrangement.

So for the effort of adding an extra endstop sensor and setting them up so they function as described I get high speed Z homing with no wasted motion.

Now I need to see what the long term reliability of this approach is.

Frederick

@johndstrand

Here is the part of config.g which creates the U axis:

; motor direction - drive (P), direction (S1 = normal, S0 = reverse)

M569 P0 S1         ; drive 0  - normal  - X
M569 P1 S0         ; drive 1  - reverse - YL
M569 P2 S1         ; drive 2  - normal  - YR
M569 P3 S0         ; drive 3  - reverse - E
M569 P4 S1         ; drive 4  - normal  - U

M569 P5 S0         ; drive 5  - reverse - Z
M569 P6 S1         ; drive 6  - normal  - spare
M569 P7 S1         ; drive 7  - normal  - spare
M569 P8 S1         ; drive 8  - normal  - spare
M569 P9 S1         ; drive 9  - normal  - spare

; motor assignment

M584 X0 Y1:2 Z5 U4 E3

; motor performance settings

; U (mini linear guide)

M92  U3200                    ; steps per mm (3200 for 1mm lead)
M203 U1200                    ; max speed (mm/min) (max 40 mm/s or 2400 mm/min)
M566 U900                     ; max instant speed change (jerk) (mm/min) (defaults 900)
M201 U500                     ; acceleration (mm/s^2) (defaults 500)
M906 U480                     ; motor current (mA) (rating 600 mA)

Here is the code to mount and unmount the probe:

  ; --- setup to mount probe ---

  G90                      ; absolute moves

  ; --- check if bed is clear of dock - move if needed
  ; the global variable holds the required Z position and was determined by testing

  if move.axes[2].machinePosition < global.g_probe_clearance
    G1 Z{global.g_probe_clearance} F9999

  ; --- pre-pickup positioning

  G1 U0   F1200       ; retract dock (it should already be retracted)
  G1 Y100 F6000       ; move Y to pre-pickup position
  G1 X150 F6000       ; move X to line up with dock
  G1 U50  F1200       ; extend dock

  ; --- mount ---

  G1 Y133 F6000       ; move Y over dock thus picking up probe
  G1 X100 F6000       ; move X away from dock carrying probe

  ; --- post-pickup positioning

  G1 U0   F1200       ; retract dock

  ; --- setup to unmount probe ---

  G90                    ; absolute moves

  ; --- be sure bed is clear of dock ---

  if move.axes[2].machinePosition < global.g_probe_clearance
    G1 Z{global.g_probe_clearance} F9999

  ; --- pre-dropoff positioning ---

  G1 U0   F1200 ; retract dock (it should already be retracted)
  G1 X100 F6000 ; move X to pre-dropoff positon
  G1 Y133 F6000 ; move Y to line up with dock
  G1 U50  F1200 ; extend dock

  ; --- unmount ---

  G1 X150 F6000 ; move X over dock putting probe in dock
  G1 Y100 F6000 ; move Y away from dock leaving probe in dock

  ; --- post-dropoff positioning ---

  G1 U0   F1200 ; retract dock

Of course the code I've shown for mounting/unmounting depends entirely on where the mini-linear rail is mounted on the printer frame, how the probe dock is mounted to the linear rail, the dimensions of the probe dock, etc.

Also the code does not have any testing to determine if the probe is already mounted or not. The probe I have does not provide a fool-proof way to determine it's state. You could use a global variable to track which bit of code was last executed but it would not be a sure thing.

Frederick

@mac said in I could use some help:

@fcwilt knowing what it can do is helpful. Knowing how to code it so it can do those things is what I need to understand. Yes, I know, read the documentation. I'm on it, but I'm also trying to answer the question I asked at the beginning of this thread. Which has not been answered yet, because if it had, my printer would be homing, which it's not.

I'm going to unplug my BLTouch now, and chock it's demise up to some kind of objection of it, even though I enjoyed watching it go across the bed of my BLV-Anet A8 during a 16 point survey.

Mac

Is your BLTouch not working?

Because you do want a working Z probe for the things you need to do such as setting the Z=0 Datum or Bed Leveling.

Frederick

@droftarts said in I could use some help:

What I'm trying to say is please don't encourage a newbie (ie @Mac) to go down a road that suits you, but makes it harder for him to get support with at a later time, because it's not how most people do it as far as I'm aware. That axes are homed X, Y then Z if you command G28 and don't have a homeall.g, it is clearly the intention of the writer of the firmware that it happens in that order.

Ian

You are entitled to your opinion but I absolutely disagree with your view of things.

Try doing this with only a Z probe:

Auto Bed Leveling

Frederick

@bilsch said in Help with M671:

@fcwilt so yea I'm trying to get my bed leveled. This is on a voron 2.4 - I have 4 independent pivot points ( belts, not leadscrew )

M671 is configuring the plane. The problem is I don't get how to derive the numbers for that command.

Well I don't know that printer but the numbers in M671 are in reference to X=0 Y=0.

And you want to specify the places there the bed is actually being lifted, not where the belt is or the stepper is.

In this image you can see the sphere the v-slot is riding on. The position of the sphere is what I use.

Frederick

@droftarts said in I could use some help:

@mac you can use both, but there’s not much point. Homing with the Z endstop requires it to be configured with M574, and then a homing move of the axis to the endstop Homing with the probe does not need to be configured with M574 on Z (ie it doesnt need ‘M575 Z1 S2’ see M574 in the GCode dictionary) it just needs a move so the probe is over the bed, ideally in the centre, before running G30.

Ian

We are going to have to agree to disagree.

Homing with a Z probe requires homing X and Y first.

And since Z hasn't been homed it's position is unknown thus you end up with four Z relative moves (2 for X, 2 for Y) to be sure it is clear of the bed while homing X and Y.

And an endstop can home faster than a BLTouch can.

So to me faster homing and simpler code is more than enough reason to have a Z endstop - it's not like it is an expensive item.

Frederick

@mac said in I could use some help:

@fcwilt I wanted to have both. But selecting one precludes the other. Unless you know a way to have both in RRF?

No it does not.

If it did how could all of my printers have both?

M574 can configure an Z endstop just like your X or Y endstop.

M558 and G31 configure a Z probe.

Frederick

@mac said in I could use some help:

@droftarts @fcwilt Homing update: X homed quite well, Y homed, but didn't come back far enough. When I asked Z to home, the print-head shuddered for a moment, then started to descend. Unfortunately, there was no bed beneath it for the BLTouch to sample.

So that's the latest wrinkle in all of this.

Mac

As you may recall I home with a Z Endstop.

I use the Z Probe for:

• setting the Z=0 Datum
• creating heightmaps
• leveling the bed

Some folks think having a Z Endstop when you have a Z Probe is foolish but I swear by it.

All of my printers have both and the all home with the Z Endstop. It can be quicker and the homing code is simpler.

Did you perhaps disable the M574 for the Z Endstop?

Frederick

@bilsch

Not much to go on there.

I gather you are trying to level the bed?

Did you generate the heightmap just to visualize the result?

Frederick

@owend said in any way to pass parameters to start.g?:

Most slicers will put a temp in the start code if you don't , so if you rely on start.g it'll possibly be over written.

JOOC what slicer do you use?

When faced with the possibility of slicer generated code conflicting with my code I did a number of tests for the slicers I have (Simplify3D, Prusa, Cura, ideaMaker) and found ways to insure there were no conflicts - so I am able to set the temp specified by each filament config.g file in my print start code which is invoked by the slicer using M98 commands.

For example from ideaMaker 4.2.3 - notice there is no slicer generated temperature setting code - so it can be done in print_begin.g or print_filament_start.g which is my code:

M221 T0 S90.00
M98 P"print_begin.g"
M98 P"print_filament_start.g"
M83
M106 S0
M82
M98 P"print_layer_change.g"
M83

Frederick

@mac said in I could use some help:

@fcwilt I’ve never changed where any of the endstops are mounted. If I understand, in RRF, the X and Y endstops should be classified as “LOW”, not HIGH?”, correct?

Yes

And if I change those High to Low classifications, M119 will report that when the are depressed, they will be at Min, not Max?

Hopefully

RRF should change their Low and High to Min and Max, or, change their Min and Max to Low and High. The way RRF is now is creating confusion with how DWC reports the functions of endstops (min and max).

It couldn't hurt to be consistent.

Frederick