@dc42 and again I have to send a "Thank you" to you! Your hints for the limits use of G10 and workplaces is something I just experienced directly: After G55 for my Z offseted print bed, I issued a G29 and it promptly crashed the hotend into the print bed and bent off the mount part for the precision piezo probe! Very bad, its the 2nd time I have to glue it until I get a better mounting...

I had already considered to do the needed adjustments using some script and a few calculations myself. I guess I will shift my experiments into that direction. Looks like I first have to find a way to stop the nozzle crashing into any obstacle before playing with (Z-)probes

I will check those OM properties, they might help me setting up some more safety guides.

@dc42 Thank you again! I have played around with the commands "G10 L2 P2 X0 Y0 Z14.0" (for a print bed Z offset of 14.0 after reset and doing a "G30 S-1") and the issuing a switch to workplace 2 with "G55". I was able to see that the DWC shows then Z = 0.0 and also an adjusted max Z of 300.0 - 14.0 = 286.0 (for the print bed) and swapping back to "G54" did correctly reset the z range to 0.0 .. 300.0. This looks promising and I started to experiment:
1/ After doing a G54, I moved the nozzle with "G1 X0 Y0 Z10.0" to a lower coord than the print bed, which is possible as the print bed is smaller than the complete XY plane. Switching back to "G55" promptly shows a negative Z coord! So far, I assume that I can "leave" a set wokplace for some 0 <= Z <= P2 workplace offset?

2/ Any use of a "G10 Px ..." command that sets offsets for a wokplace relative to the machine coord system, will adjust the max-coords properly. Is there a command variant that allows to reduce the max coord values additionally to defined a workplace which is smaller in min- as well as max range? Something like "G10 L2 P2 X100:400 ..."?

3/ I tried to locate the workplace definition values somewhere in the OM for use in the conditional meta-commands, and also the "active" workplace (G53, G54, G55...) But could not find this information. May you point me to this info, please.

I guess that the workplace commands may fulfill most of my current requirements and help me defined some flexible macros / scripts to start a safe printing state. Thank you so much for your help!

@dc42 Thank you for this reference, it is helpful and starts a whole set of new information. Regarding your additional comment: is the command G29 also belonging to those "system macro files"? As far as I found, when issuing G29, it first travels to some coord near(?) the first matrix coord (of M557 X... Y...) but also moves along the Z-axis to some low (?) value. This caused my troubles when I had not set Z = 0.0 to the height of the print-bed (Z = 14.61 mm).

Hi, I have fighted through the print bed levelling with Bltouch and piezo z-probe but am now at a point where I can calibrate my machine but step into new questions:

My machine has y-axes going from 0...490mm (min-stopend), X-Axis 0..500mm (min-stopend) and Z-axis 0..300mm (max-stopend). So far my "physical coord system" is defined (in the config.g) and should be stable and all coords within it are reachable as well dont causes things carshing into end-positions.
But one of my print-beds sits higher than the pysical Z=0.0 coord (about 14.61 mm), and the nozzle - depending of which make I use - will have different offsets reletive to the X-Y space because of diffrent mounting parts.

What I want to define is a "relative coord system" which is for example (X-offset = 0.0, Y-offset = -21.5, Z-offset = 14.61) when I choose a specific printbed (level spring, heater, glass etc) and/or a specific hotend. Ans this definition should be separate from the config.g as I hate it to reset the complete machine to activate such specific settings.

Is there an option to achieve this in RRF 3 (my current firmware) ?

With such an option to shift the perceived coord system with such "profiles", I could set the Z = 0.0 level plane exactly to the specific nozzle and also make sure that G29 is not trying to move the nozzle into a position below the print bed when its 14.61 mm higher than the pyhysical Z 0.0 origin.

Currently I only found a solution by redefining the Z-axis to be 0..258.31 and using G30 to set the Z=0.0 level with the probe BEFORE doing G29. Doing this I can not reach the physical level Z=0.0 anymore (my print bed is smaller than the complete X-Y plane).

For any change of the nozzle I have to re-check for a new Z = 0.0 level and have to adapt the config.g (and do resets) to stabilize endstops etc. I really would like to "calibrate" with separate profiles and on-the-fly commands/macros. Is this too much wishful thinking?

Perhaps I can help my adding a bit of my experience with the BLTOUCH probe. My current config for the probe was

....
M208 X0 Y0 Z0 S1                        ; set axis minima
M208 X500 Y490 Z300.0 S0                  ; set axis maxima  X: 500mm,  Y: 500mm,  Z: 300mm

; Endstops
M574 X1 S1 P"!xstop"
M574 Y1 S1 P"!ystop"
M574 Z2 S1 P"!zstop"
M574 E2 S1 P"!e1stop"
 ....
; Z-Probe
; BLTouch - via exp.heater7
M307 H7 A-1 C-1 D-1                              ; Disable the 7th Heater to free up PWM channel 5 on the Duex board.
M558 P9 C"^zprobe.in" H5 R0.2 F500 T4000 X0 Y0 Z1           ; Set Z probe type/mode 9. H=Dive Height. F=Speed the bed 
M950 S0 C"exp.heater7"
G31 P25 X11.5 Y-10 Z2.15                      ; Z probe trigger value, offset in relation to nozzle. And trigger height adjustment
M557 X100:400 Y80:380 P5:5                ; Define mesh grid
....

I use RRF 3.11 (I believe the newest one) and have wired the probe exactly as you did. My 3 axes are all with endstops and homing is also done to reach these endstops. After homing, I usually go to the print bed center and lower the Z-axes down to about 100 mm above the print bed surface. I used "G30 S-1" to check for Z0.0 and adjusted the Z-axes max value accordingly for max = 286.5 mm. After this, the nozzle (probe offset 2.15 mm) will touch the bed when I move the hotend to Z = 0.0.

Normal G30 is then working fine (hotend + probe sty 5mm above the bed) and a subsequent G29 for the height map also is done for all requested matrix points.

The BLTOUCH docs mention several macros for Pin down/up and other actions, be sure to use the same Port P0 (from the M950 S0 C"exp.heater7" command) for example in Pin Down "M280 P0 10". I always get confused about the inconsistent namings in different commands but it is as it is.

I have run G29 several times and the results stay stable as well no hickups with the probe. I will keep it as a 2nd choice as I now have the Precision-piezo Orion 2 working and could get rid of that offsetting nozzle-probe with that variant.

@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?

@bearer : hmm, taking your last sentence, is this a problem when I home the Z axis to the max-position (i.e. far away from the printing bed) and before print start, do some z-probe process to get the first layer levelling done independent of the homing?
To state it in the "what" format: When I do Z-axes Home, I want to move the Z-axes to the highest possible position relative to the printing bed for a "safest position". I do not want to use Z-axis homing to level down to the printing bed for some Z-coordinate = 0.0

@StevePS3 said in Splitting Z-axis steppers:

D-bot

As far as I can find that D-Bot seems to be a cartesian printer, I am wondering why you want to have 2 "independent" Z axes?

I have built my machine as a "portal" style one (Y movement is done by moving the bed/table and the protal has 2 leadscrew drives (each with stepper motor) and the X-axes leadscrew moved up/down by these two synchroneously working steppers. With the DUET 2 this is quite simple as it directly supports this solution. With the two leadscrews + each stepper, I am quite sure to be able to move even drilling motors instead of a printing head.

As far as I did understand the different kinds of printer axes modes, you need independently working steppers for the non-cartesian modes?

to all: I have to apologize for an unneccessary discusion caused by several missunderstandings from my side. I found that the information I was looking for is already in the OM. To access the current state of the endstops, I have to use "sensors.endstops[0..].triggered" and NOT "move.axes[0..].homed". I can only explain my wrong use from having seen a mentioning of the ***.homed property and no hint to the actual state property for endstops.

I changed my scripts for homing to shortcut the movements when the home position is already active and all axis now work nicely.

Thanky you all for your understanding and help!

@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!