@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

@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

@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

@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

@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

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

@BDPrinters

The last G30 P2 has F550 instead of Y550

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

@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

@Duncan

To activate tool zero you need a T0 command - you can put it after the other tool commands in config.g if you want.

Frederick

@Leonard03 said in G30 during G28 issue:

I'm referring to G1 H4 command. It was better to measure from let's say X80 to the endstop?

I'm not sure what you mean by "measure".

Frederick

@martin7404

I re-read all of the posts and that seems to be the case M92 only, no M350

Frederick

@Leonard03

Just FYI - G92 is not a movement command, it merely sets the current axis position to whatever value present.

So G92 X123 Y456 sets the logical X position to 123 and the logical Y position to 456.

Frederick

@FelixUCF

I seem to recall there is a jumper that determines what appears on that pin.

Did you check it?

Did you check

@Triet

Is moving away from the end-stop sensor 5mm enough to deactivate it?

If the end-stop sensor is activated a G1 H1 move will be skipped over.

Frederick

@sebastianwac said in Homing X triggers before reaching endstop:

G91                ; relative positioning
G1 H2 Z10 F3000    ; lift Z relative to current position
G1 H1 X-1205 F3000 ; move quickly to X axis endstop and stop there (first pass)
G1 H2 X5 F3000     ; go back a few mm
G1 H1 X-1205 F1500 ; move slowly to X axis endstop once more (second pass)
G1 H2 Z-10 F3000   ; lower Z again
G90                ; absolute positioning

One small observation. The G1 H2 X5 F3000 command - you don't need H2 since the preceding G1 H1 X-1205 F3000 will have marked the X axis as homed and at the point plain G1 moves will work as expected.

Is it possible that the cable length (approx. 5 meters) is introducing additional resistance, making the controller interpret the switch as open?
Or could it be due to electrical noise from nearby signal or motor cables?

5 meters is a lot. It could be picking up noise.

Is the wire twisted or shielded? Is the end-stop device a simple switch, like a micro-switch? Is it normally closed? Normally closed is the best as the signal wire is connected to ground, making it resistant to noise.

Frederick

@dc42

Where can I find the versions 2.2.1 and 2.3.0 for the WiFi server?

Thanks.

Frederick

@Leonard03 said in G30 during G28 issue:

I feel really sorry... Looking at commits on GitHub between those dates, there were many and substantial changes in RRF.. I feel sorry because only now I came across this bug (?) after so much time

There was a time when I would install beta or rc firmware - but no longer - I have things to print.

So I am still using 3.5.4.

Frederick

@dc42 said in Mini 5+ Wifi Problem Revisited:

We are aware of an issue whereby in some machine configurations running firmware 3.5.x the object model becomes too large for both DWC and PanelDue to fetch it simultaneously. One of the symptoms is dropped network connections. In version 3.5.1 of PanelDueFirmware we made some changes to mitigate this, and in RRF 3.6 we made some more.

Both of the PanelDue units are running firmware 3.5.1.

I am not running any version of RRF 3.6 as I do not install alpha/beta/rc firmware.

I will update the WiFi firmware to 2.2.1 and see if changes anything.

If you can get 2.3.0 to me I will test that as well.

Thanks.

Frederick