Change Z probe pin between probe tests

leadinglights

Can I ask if there is any way of using different controller pins for nozzle height determination and for bed leveling? For example, can the height of each of two nozzles be found by running G30 using RAMPS pin D2 for the probe, then finding a datum for bed leveling by running a further G30 but using RAMPS pin D18, followed by a G32 for bed leveling, again using RAMPS pin D18?

The above sequence of actions can be seen on a YouTube video at https://www.youtube.com/watch?v=ymQ_He1HSKk&t=56s The reason for using two separate sensors is that I have found that dynamic effects can potentially make under bed sensors very inaccurate.

Repetier

No this is not possible. That requires a modification of the firmware to fit the needs. We have this for the felix printers where the nozzle it self is the sensor and both have same z height, so we use them as sensor for extruder z offset and for bed leveling. But they are using same pin. The example here works different so it will not work without code change.

leadinglights

Thank you Repetier. If I modify my two Z sensor controllers so that the active sensor is selected by a spare pin on the RAMPS but that the output of both is wire OR'd to one pin (e.g., RAMPS D18) Is there any obvious reason that this would not work?

Mike

Repetier

As I said they need to have the same z probe height. If one triggers 1.3mm above bed and the other 1.36mm above bed you have an error. There is only one variable for this so same is used on both sensors. So if you can adjust sensors to have same trigger height it would work I think. That is what we did with the felix printers. Both trigger at same height.

leadinglights

I have previously manually selected the sensor controller by physically moving the pin onto D18. This allowed me to use G30 to get values to enter into EXT0_Z_OFFSET and EXT1_Z_OFFSET in the EEPROM before swapping to the other sensor for doing a mesh bed leveling. Using a wired-OR to pin D18 will allow me to partially automate this.

Mike

Repetier

EXT0_Z_OFFSET should always be 0 and EXT1_Z_OFFSET is the height difference to extruder 0. This is not to compensate probing differences! It is the physical height difference between the nozzles.

leadinglights

I didn't realize that EXT_0_OFFSET should always be 0 although I probably did keep it at 0
Modifying my sensors so that the output could be shared with one common pin was just a matter of tri-stating the output of the un-selected sensor. The sequence is now:
1) Select underbed sensor and load extruder 0 then run G30, recording Z
2) Stay on underbed sensor but load extruder 1 and run G30. Calculate and enter EXT1_Z_OFFSET
3) Select touch sensor and run G30. Calculate difference from EXT0_Z_OFFSET and enter in Z_PROBE_Z_OFFSET
A bit manual, but quite do-able. If this all works, may I come back to you with a feature request to implement some or all parts of this into your V2 firmware?

Mike

Repetier

For the nozzle difference there is even a command:

- G134 Px Sx Zx - Calibrate nozzle height difference (need z probe in nozzle!)

Px = reference extruder, Sx = only measure extrude x against reference, Zx = add

to measured z distance for Sx for correction.

The way you describe it, it should be no problem. For z probe difference height does not matter, just difference. So you can use z probe height for the other sensor.

In V2 sensor is currently a fixed class. Would it be a pointer with preset that would make it easier in this case. Then you could just add a g-code to select a z probe and run commands. Some idea for the future.

leadinglights

Thank you Repetier, G134 worked perfectly and stored the Z difference in EEPROM. I have put a video on YouTube https://www.youtube.com/watch?v=waXIr_ytukw which shows this, along with other parts of the calibration procedure.

One thing that is not presently working, is that I haven't found a way to simply set the Z height. While G30 works correctly, G30 S1 which worked on older firmware now fails even to see the trigger from the sensor.
G32 works perfectly, but is referenced to the touch probe - entering a value for Z-probe height in the EEPROM does not seem to change the Z zero position.

Mike

Repetier

In the end all call the same runZProbe function so it should either never work or always work. With G30 S1 this function is run:

void Printer::measureZProbeHeight(float curHeight) {

#if FEATURE_Z_PROBE

currentPositionSteps[Z_AXIS] = curHeight * axisStepsPerMM[Z_AXIS];

updateCurrentPosition(true);

#if NONLINEAR_SYSTEM

transformCartesianStepsToDeltaSteps(currentPositionSteps,

currentNonlinearPositionSteps);

#endif

float startHeight = EEPROM::zProbeBedDistance() + (EEPROM::zProbeHeight() > 0 ? EEPROM::zProbeHeight() : 0);

moveTo(IGNORE_COORDINATE, IGNORE_COORDINATE, startHeight, IGNORE_COORDINATE,

homingFeedrate[Z_AXIS]);

float zheight = Printer::runZProbe(true, true, Z_PROBE_REPETITIONS, true);

if (zheight == ILLEGAL_Z_PROBE) {

return;

}

float zProbeHeight = EEPROM::zProbeHeight() + startHeight - zheight;

#if EEPROM_MODE != 0 // Com::tZProbeHeight is not declared when EEPROM_MODE is 0

EEPROM::setZProbeHeight(zProbeHeight); // will also report on output

#else

Com::printFLN(PSTR("Z-probe height [mm]:"), zProbeHeight);

#endif

}

and sets z probe height from given Zx value.

How do you handle the z signals currently when you say:
> G32 works perfectly, but is referenced to the touch probe - entering a value for Z-probe height in the EEPROM does not seem to change the Z zero position.

G32/G30 should use the same sensor so both use also same z probe height. Only the fact that z probe height is not relevant for extruder z difference makes G134 work regardless of that value.

leadinglights

Thank you for your quick reply.

The input to the RAMPS board is pin D11. One of the two sensors is selected by setting either RAMPS pin D4 for the touch probe, or by setting RAMPS pin D5 to select the underbed sensor. The outputs of the sensors are either low (0V) or are high impedance - the unselected sensor is held at high impedance.

Selecting the touch sensor I can call G30 and the probe works correctly, the Z moving down until it either touches the bed or I simulate a contact by tapping the probe tip.

If the underbed sensor is selected and G30 is called the Z carriage will move down until it either touches the bed or contact is simulated by tapping the bed.

With the underbed sensor still selected, when G30 is called with an S1 parameter, the Z carriage moves down but now a simulated or real contact is not detected and the Z carriage will continue moving down until power is removed.

Selecting the touch sensor and calling G32 functions correctly (7 X 7 array) and the correct value is recorded in Z max length in the EEPROM. G32 would not be useful with the underbed sensor selected as there are positions on the bed of poor sensitivity.

The ideal would be to set the Z max length from the first probe of the G134 which works accurately and reliably

Mike

Repetier

Are you z max homing so that you need z length? Here G32 runs the correction so the touch probe is required. You could change the programming and switch for the z length measurement to other probe go to a proper position and run the rest there, but not with the current code where is is based on touch probe and you need the z probe height of that.

So the main problem and only one is that G30 S1 Z6 or which ever Z you use is not working.
With S1 it runs
float zheight = Printer::runZProbe(true, true, Z_PROBE_REPETITIONS, true);
while without it runs

float z = Printer::runZProbe(p & 1, p & 2, Z_PROBE_REPETITIONS, true, false);

The deafult value for the last parameter is true so that is the only real difference. So S1 has in runZProbe enforceStartHeight true and without it is false.

This means Printer::startProbing is called with enforceStartHeight so this extra block is run eventually:

float maxStartHeight = EEPROM::zProbeBedDistance() + (EEPROM::zProbeHeight() > 0 ? EEPROM::zProbeHeight() : 0) + 0.1;

if (currentPosition[Z_AXIS] > maxStartHeight && enforceStartHeight) {

cz = maxStartHeight;

moveTo(IGNORE_COORDINATE, IGNORE_COORDINATE, maxStartHeight,

IGNORE_COORDINATE, homingFeedrate[Z_AXIS]);

}

Please try if

float zheight = Printer::runZProbe(true, true, Z_PROBE_REPETITIONS, true,false);
in void Printer::measureZProbeHeight(float curHeight) works better. I think this is not good and maybe I added the extra parameter later and did not see it is used here. The move down is without end stop test if it triggers and thinks it is too high so that might be the move you are looking for.