Homing axis when already homed
-
Testing for machinePosition and .homed are not the same.
You can't really know the machine position until after the axis has been homed.
I suggest you try
If !move.axes[0].homed
... blah blah
else
.... blah blah -
Hi to @Phaedrux and @OwenD : I will answer with one text:
I should have included the complete homex.g, it will provide answers to both of you (hopefully):
; homex.g ; called to home the X axis ; M119 ; echo "X: homed state = "^{move.axes[0].homed}^" , position = "^{move.axes[0].machinePosition} if move.axes[0].homed ; this is currently not working ... echo "X: axis is in home position, set to min" G92 X{move.axes[0].min} elif move.axes[0].machinePosition == move.axes[0].max-1 echo "X: axis is in unverified state, machinePosition is unknown" else if move.axes[0].machinePosition == move.axes[0].min echo "X: axis is at min position, but not homed - check endstop switch" else echo "X: axis is verified to be at "^{move.axes[0].machinePosition}^" , do homing from there" ; ; echo "X: put Z-axis to safe place" M98 P"homez.g" ; echo "X: Z-axis done" G91 ; relative positioning if move.axes[2].machinePosition < move.axes[2].max echo "X: retract Z-axis for 5mm" G1 H2 Z5 F600 ; lift Z 5mm relative to current position ; if move.axes[0].machinePosition > move.axes[0].min echo "X: position > min, retract axis to min" G1 H1 X{-move.axes[0].max} F1400 ; move quickly to X axis endstop and stop there (first pass) G1 H2 X5 F1000 ; go back a few mm G1 H1 X-15 F800 ; move slowly to X axis endstop once more (second pass) else G1 H1 X-1 F200 G1 H1 X1 F200 ; ; if move.axes[2].machinePosition < move.axes[2].max ; echo "Z: reposition Z-axis again" ; G1 H2 Z-5 F600 ; lower Z again ; G90 ; absolute positioning if move.axes[0].homed if move.axes[0].machinePosition > move.axes[0].min ; echo "X: finally homed, reset position to min : "^{move.axes[0].min} G92 X{move.axes[0].min} ; ; echo "X: homed state = "^{move.axes[0].homed}^" , position = "^{move.axes[0].machinePosition}Just a few additional remarks:
1/ if you follow lines 5..16, you will notice that I am aware of (at least) 3 states that each axix may have: (a) homed (i.e. the endstop switch is Triggered, the indicator LED is ON), (b) the machine is in a state of "just started up and machinePosition has been set to min" but the physical axis is at an unknown position" or (c) AFTER a successful HOME, the machinePosition is ASSUMED to be correct. NOTE: Several events (executing commands, power failures, manuell interventions...) may revert to state (b) after a successful Home. I have looked into the preliminary OM - via the few docs pieces - and have only seen "move.axes[0...].homed" to reflect the endstop switch state and "move.axes[0..].machinePosition which is an internal value of what the firmware believes where the axis is positioned. The config.g values for "min position" and "max position" are also held in the OM. What I would like is the "machinePosition is UNVERIFIED" (or whatever you like to name it) as long as a successful HOME was not done, which used a triggered endstop switch and move.axes[0..].machinePosition should be the min resp max value, depending of you endstop mounting +config settings of that switch.As I currently did not have such a "unverified" state property, I choose a deliberate position value (i.e. (move.axes[0..].max-1)) which is easily checked and is mostly not in conflict with normal operations [see line 9 in the script].
2/ the comment in line 6 is the current situation (see different thread in the forum) where I found that move.axes[0..].homed is always "false" whereas M119 properly outputs the real state of the endstop. Nevertheless I did include the code already in the hoped that a future version will remedy this
3/ The y-axis uses almost the same script coding, except referencing move.axes[1].*** instead of move.axes[0].*** and other values specific for each axis. I do hope that we get functions with parameters in some future to avoid redundand (almost identical coding).
The z-axis also uses equivalent coding for its 3 states of the axis and I simply call "homez.g" inside of homex/y.g (see line 18). After this call, the Z-axis is at its home-position (for me its move.axes[2].max), the endstop switch is triggered and machinePosition is "verified" = in sync with endstop state).
4/ From lines (19..) the homing of the X- (or Y-)axis is done with
4.a/ Lines 22..25 would lift the Z-axes for 5mm (relative movement)
4.b/ Lines 26..34 do the X-axis home just as it was done in the originally generated code (i.e. fast move towards the endstop until it triggers, slowly retract for a few mm, and finally touch the endstop pposition again.
4.c/ I have added the lines 31..33 even as I did not see a need for it, but without those lines, some software (firmware or DWC) complain with "Homing failed" when this block is not executed because the axis is already in correct (verified) home position.5/ Ok, for the last parts: lines 36..39 would reposition if lines 22.25 had done a small shift. I have commented this out, as I currently need some variable to remember that line 24 (G1 H2 Z5...) was done at all.
Lines 41..45 are a final check for a trivial "***.homed and ***.machinePosition are in sync"6/ I have not looked into that "stall detection feature" which may be used when a machine has no endstops (for one or more axes). I would like a verified doc that tells me how machinePosition vs endstop are handled for such events. Same situation may happen if a moved axis is blocked by some obstacle while moving.
7/ A final remark for the many echo "..." commands in that script. I am an absolute fan of properly added debugging and meaningful messages in my coding as it helps me to produce working code. In a productive script state I would like to have an externally controlled debug ON/OFF switch without modifiying the script! But with my nice messages I seem to have stepped into a next "feature": When executing the script, something accumulates all text output and finally sens it to DWC to show in the console. This is nice BUT: there is a limit for the total length of this output and there is a error stop for the script when that total text overflows. I have not yet found the doc that explains this, but I had to remove a few echo outputs (+M119 call) to stay below that limit. Another funny side-effect using commands
Oh well, even these simple scripts open a whole can of worms (questions, and more questions...) but I hope I could answer your questions with this wall of text and expect more input from you ... the experts.
Have a nice weekend!
-
@hlwerschner said in Homing axis when already homed:
(a) homed (i.e. the endstop switch is Triggered, the indicator LED is ON)
Well for starters that is not correct. The "homed" state simply tells you that at some point the position of a given axis was set to some known value.
This usually happens when you do a G1 command with the H1 parameter and the end stop switch is eventually triggered thus setting the position of that axis to the min/max value for that axis, depending on where the end stop switch is located (either the min or max end of the axis).
A G92 command will also set the homed state for whatever axis is included in the command, G92 X123 for example, even though the position of the X axis may not be 123.
You are making the process of homing an axis far more difficult than it needs to be.
Let's assume your X axis range is 0 to 300 and the end stop triggers at exactly 0.
G91
G1 H1 X-301 F6000
G1 X10
G1 H1 X-11 F600Is all you need to home the axis. The F values are just for illustration to show that the first G1 H1 move is normally done at a fast speed while the second is done at a slow speed. That actual speeds are not terribly important.
When the homing process is complete the actual position and presumed position of the X axis will be X=0.
If you want to skip homing if the axis is already homed you can place those 4 commands under a test for that axis already being homed.
I would not do that, however, because, when homing, I want to insure that the axis is homed and the actual position of the axis is in sync with the presumed position.
Frederick
-
@fcwilt : yes I mostly agree with you. I was not ready to understand what happens in the software and too optimistic about being able to code for "higher safety". My last findings about the OM have stopped me here and I will reduce my scripts again to basic functioning and accept random effects for which I not yet know why they happen (and hope that not too much gets destroyed).
But as this project of mine is also something to learn from, this is the path to follow (and hope for future helpful enhancements in the hardware/firmware).I will set this thread to "solved".
-
It sounds like you would desire a machine that has hardware to provide feedback as to the actual position of each axis.
That is certainly doable but I don't know if the current firmware supports such hardware.
Frederick
-
@fcwilt : yes, that is true -- for a future where I have a machine ready to do productive work (which, as I have noticed, means to run for several hours for print jobs). But meanwhile, just looking what the current software running in a DUET 2 / 3 with connected endstops and some other sensors can do, I (simply and very optimistic) would be happy if the sensor states that the hardware already has (and uses) are reflected and are readable in the OM and useable in meta-commands. You see, I do not need better mainboards (my current DUET2 Wifi is excellent for my project) but I would like to see that its features are made part of the "programmable level" of scripting i.e. the OM should make them visible to the meta-level commands.
I recognize that the historically grown GCode commands are being created with the view of a one-way communication from print-script to dumb machines to move heads and print along. But that origin is far behind us, we now (with RepRap Firmware and the powerful ARM processors) have capabilities like real multitasking and faster actions but those better capapbilties also demand a more solid software and faster reactions to malfunctioning. The only way to achieve this - just as it is done in industrial machines, which we hobbyists try to simulate/build - is to look into the concepts of event handling, effective reactions to the actual state of the machine and being able to create scripts that are not "dumb" anymore. The DUET 2/3 as they are today are providing a broad and solid basis which can be exploited for our needs and I do not see reasons why we should not do it now. Therefore I am asking funny questions and try to point to enhancements (from my personal point of view). Discussions are then wanted and help all of us to learn and achieve better results. Btw: I know that I am a bit impatient waiting for those promising features of meta-command stuff
I can not deny that I am a software developer and not a mechanics guy! -
Many, if not all, of the sensor states are available via the OM.
You can also create triggers that react to changes in the state of inputs pins.
See M581 and M950.
Frederick
-
Hi,
I forgot to mention that the state of the end stop sensor should not be presumed to say anything about the actual axis position.
For example I use IR beam break sensors and they are active over a range of some 20mm.
It's the transition from inactive to active that tells the firmware that the sensor has been reached and thus the axis position can now be determined.
But the static state of being active simply says that the axis position is somewhere in that 20mm range and that information is not terribly useful.
Frederick
-
@fcwilt : You are sure about that 20mm range? And what is the resulting home position accuracy regarding your experience?
After reading your comment, I have attached a very primitive distance metering (please accept that most of my building is in a stage to test/experiment with materials etc). I will try to upload an image taken after homing the axis and reset the meter:
If I move the X-axis away (in this example I choose 100mm but any distance did produce almost the same results), I get: 
. You will notice that the meter shows some irrelevant value as it is not touching that small plate anymore. I did a video while running one Home X action , but it is too large.
But in all attempts to return via Home X, the meter display shows values between -0.01 ... 0.02 mm. I even powered down the machine (either in homed position as well as moved somwhere away), but homing that axis stayed in the above range. I noticed one exception when I moved the axis just a few mm to turn off the endstop leds and then did the home for this short distance. In this case I occasionally did see values like 0.03..0.04
I have done about 20 runs (including returning to coord 0.0 via G1 H1 X... instead of homing) and the metering stayed in the above range. Personally I am surprised that the accuracy is so good, maybe I am doing something wrong? I do not know if that meter really is so precise and the stop-plate for the meter is somewhat flexible, therefore I added that alu profile to stabilize it a bit. More experience will come when I add the z-probe stuff and start calibrating the other axes as well as the bed level height map.
Btw: did you do some testing/measuring of vibrations while moving axes and how did you get measuring data about vibrations and/or torques on the printer frame that will influence the preciseness of returning to the same coords again during long time print jobs? -
Hi,
You've been busy.
Are you using a Hall effect device for your end stop sensor? Interesting.
As to my sensors keep in mind they they are IR beam break devices. They are attached to the frame. On the moving part (be it X,Y,Z) there is a printed part that moves into place and breaks the beam.
Since these is nothing about the sensor that prohibits further movement the moving part can continue past the point where the sensor is first activated, assuming nothing else gets in the way.
Since the point of these sensors is to determine that the moving part has reached a certain position there is no real requirement that the sensor activate at the extreme end of travel or at the min or max axis position.
My sensors activate some 10 mm away from the min end of each axis. It is a simple matter to determine what the actual position is. So rather than adjust sensor position to yield a specific axis position I set the axis position using G92 to the actual position.
The result is the same using either approach, the firmware now knows where the moving part is.
As to accuracy I have taken no measurements. It is good enough to allow pausing and resuming a print. If that is not of concern it doesn't really matter if the X or Y position is off a mm or two at the start of a print.
As to the Z position I use a BLTouch probe to set the Z=0 datum independent of the Z end stop sensor. The Z end stop sensor gets the bed where it needs to be for homing purposes. The probe determines where it actually is for printing purposes.
Frederick
