Improved ergonomics of bCNC (Program Origin Determination on Z))

[JipeB]

For a new bCNC user some parts of the interface are far from intuitive #1685 #1647

The box named common does not naturally indicate its function even if certain input fields (Fast Probe Feed and probe Feed)
suggest that they are related to the Probe function. But then what does the TLO field do in this zone?
In reality, the TLO field is used to enter the height of the Z0 measurement sensor.

Renamed as follows this block would be much more explicit.

Functioning

Pressing set stores the content of the "TLO" field in the .bCNC initialization file in the Probe tlo item.
If bCNC is restarted, the stored value is displayed until the end of the homing then reset to zero.
Since the "TLO" field reflects the height of the measurement sensor, why reset it to 0? It's painful to have to
enter each time the height of a sensor which always has the same value.

Pressing set also causes a shift of the Z0 to compensate for the height of the sensor: ProbePage.py
def tloSet(self, event=None):
try:
CNC.vars["TLO"] = float(ProbeCommonFrame.tlo.get())
cmd = "G43.1Z%s"%(ProbeCommonFrame.tlo.get())
self.sendGCode(cmd)
except:
pass
self.app.mcontrol.viewParameters()

And there, there is a big problem the command G43.1 Z... is inappropriate, it is reserved for the TLO offset and the sensor
probe is not a tool. The command must be G10 L20 P1 Z... to offset the machining datum by the height
of the sensor.

Some would argue that G43.1 does cause this offset and it works. Yes, provided you do not make any changes
tool with the TLO method, because in this case the first call to M6 by the machining program will cancel the offset
previous one and cause the machine to run erratically at the end of the tool change #1281 #1347 #1364, #1371

A closer look at the code reveals that the use of the TLO and tlo variables are ambiguous; it is necessary to separate what is
of the tool (TLO) with regard to the measurement accessories (sensors, touchplate, etc.) The name of the variable must be
explicit enough to avoid any confusion.

I think the operation of bCNC can be improved by using the z-Sensor pad only to input parameters
sounding and automating the determination of the Z0.

JP

[rschell]

I have found several issues with the processing of the TLO variable that need fixed. I also developed some changes to the tool change process for consideration. Both are in a testing mode and have not been pushed yet. In its current state, I would not rely on TLO staying correct, it has a tendency to get set to zero, especially at the end of a run.

When using a hobby based machine without an automatic tool changer, the use of TLO and a height sensor may vary with the machine and user. My use pattern would be to establish the datum with the first tool and use TLO to handle different tool lengths on subsequent tool changes. Your use pattern and experience may be different.

[JipeB]

My use pattern would be to establish the datum with the first tool and use TLO to handle different tool lengths

The TLO procedure, codified for many years, uses the length of the tool from the spindle nose to its tip to activate an offset on Z. This offset is managed by grbl in the form Z+TLO.
For trouble-free operation when calling G43.1 Z..., the TLO reference zero point must be carried out with the bare spindle nose (without collet or tool)
When the program starts, the first M6 will send the spindle to the tool change point, then to the measuring point where the tool length will be measured (TLO). G43.1 Z(TLO) sent to grbl will provide the Z offset.
To mount the next tool, you must first cancel the current TLO using function G49 before launching the tool change procedure which will determine a new TLO to be transmitted to grbl.

The initialization procedure corresponds to the following diagram:

I am at your disposal if you want additional information.

[JipeB]

Modification of the Z0 Program Origin procedure.

As previously indicated, this procedure caused problems for the definition of the work repository on Z.
I modified the code by removing references to TLO which have no place in this procedure and automated the sensor height compensation.

Reminder:

The current procedure:

• manual positioning above the area where to perform the Z0,
• press "Probe" to start searching for the sensor,
• sensor closed: press Z0 to set the reference,
• entering the height of the sensor in the "common" box
• validation of the entry to memorize the Z0 of the O.P.
• in jog mode Z+5 to release the sensor.

With the new procedure:

• manual positioning above the area where to perform the Z,
• press "Probe" to start searching for the sensor,

When the sensor is closed, the position Z0, compensated for the height of the sensor (stored in the initialization file) is validated.
The pin moves up 5mm to release the sensor.
End of procedure.

This automated procedure requires modifying a few lines of code and making each tile in the interface specific to its task.

The Z-Sensor pad has only one function, that of defining and storing the parameters of the probe.
These parameters are available when starting bCNC, it is no longer necessary to enter the height of the sensor each time.

Pressing Probe launches the search procedure at the distance fixed in Z (here -10).
On contact, the WCS Z is set to 0 by integrating the thickness of the sensor as defined in the Z-Sensor box.
After one second the pin rises 5 mm to release the sensor.

Modified files that replace the original files :
OP-Z.zip

Details of code changes.
Op-Z_en.pdf

These modifications have been tested with bCNC-0.9.14.317.
JP

[MARIOBASZ]

Interesting!
I hope to try it soon.

[rschell]

Been investigating these proposed changes and made some modifications to consider:

Ergonomically nothing has changed here, but behind the scenes a number of changes occurred:

1. The "tool" field is linked to the Probe Tool change frame, changes in either location are reflected in the other.
2. The "TLO" field is linked as well.
3. Both CNC.vars values have been moved to a [State] .ini section and loaded early in the Control Frame initialization.
   My thought here is, these values change frequently, reflect the current state of the machine and are not basic
   machine design parameters that would be found in the [CNC] section. I find the values in the [Probe] section
   more suitable for input parameters than results of.

Following on JipeB suggestions:

1. Renamed the common frame to Z-sensor
2. Added a Z-sensor location field and add (MZ) label to it to indicate its in machine coordinates.
3. Added a "get" button to retrieve the current machine Z as one method of populating the value.
4. Added a "Calibrate" button to perform a probing as an alternate method. This field is stored in the [Probe]
   section of the .ini files as a "mzsensor" variable. First time, I used the "get" method, subsequent times the
   "calibrate" method can be used (I have assumed the tool probing distance in this second method). More
   fields could be added to describe this location but sacrifices user friendliness.
5. Added a "Sensor Thickness (WZ)" field to capture the thickness or distance to the work surface. Its stored
   stored in a "sensorheight" variable in the [Probe] section. This is a manually entered field based on hand
   measurement. My machine design is such that the bare spindle nose cannot reach the work surface, to do so
   would restrict its dynamic range significantly. So a precision block is used to elevate the Z-sensor location to
   a reachable level.
6. I have assumed that the Z-sensor is on the same axis as the tool probing axis.
7. Added a New Tool field to track the existing tool vs a future tool requested by the change button.
8. The "Update" button reflects a re-calibration of the existing tool rather than a tool change.

One area I could not follow, are the changes in the probe routine of the ProbeFrame class. I'm concerned that the
autoleveling probing may be impacted. I will leave this for another day and review.

Just some thoughts.

[JipeB]

Hello,

I tried to make the operation of my machine as simple as possible with only one probe sensor.
It is a "flying" sensor which is used both to measure the length of tools and to determine the Z0
of the machining reference.
For tool measurement, its position is materialized by a colored area on the machine table.

For sensor trigger height calibration I use tool change calibration procedure
The measured height is transmitted to the Sensor Height field and stored in .bCNC along with the other calibration data.
A single measurement and you don't touch anything, every time bCNC is restarted, all the data is immediately available

The MZ tag is of little interest to the user; this is the reference 0 for measuring the tools lenght (toolmz in probe file).
For me it is part of the internal management of the software.

In the tab manual tool change 47.500 does not represent the tool length, but the trigger height
of the sensor relative to the machine table (WZ). The variable name is ambiguous (toolheight), one more...

My machine design is such that the bare spindle nose cannot reach the work surface, to do so
would restrict its dynamic range significantly. So a precision block is used to elevate the Z-sensor location to
a reachable level.

This situation is common in the industrial world and the use of wedges or pegs is frequent. It is enough
to validate the WCS Z0 by entering in MDI G10 L20 P1 Z (thickness of the shim).

One area I could not follow, are the changes in the probe routine of the ProbeFrame class. I'm concerned that the
autoleveling probing may be impacted. I will leave this for another day and review.

Normally, the modifications made do not affect the other procedures since they intervene
during the preparatory phase of machining.

I will soon publish the continuation of the modifications made to my machine for the tool change TLO; the
calibration procedure will be detailed on this occasion.

[rschell]

My sensor is also moveable, it can be stacked on top of a 1 inch precision block or placed on top of the corner of the stock material (it's thickness is 9 mm) hence 34.4 mm sensor thickness for tool changes.

In my version, I tried cleaning up a bit and I have removed toolmz, toolheight, the lower case "tlo" variable as they appeared to be redundant and creating confusion (maybe on my part).

I think we will need to better define what these variables are, their particular coordinate system and use. For the sensor position, my thought was to use the machine coordinates as these are less likely to be tweaked by other commands.

Attached is my list of changes I have found with the handling of TLO and tool fields. My main objective was to be able to shut the bCNC down, restart bCNC and have it return to the same state prior to the shutdown.

fix_TLO_and_Tool_handling.txt Also found at "Github.com/rschell/bCNC branch=fix_TLO_and_Tool_handling"

[JipeB]

That's a lot of changes; watch out for the domino effect.

Notes on TLO management:

1- Recovery of the TLO after reboot or program change:
TLO is tied to the tool in use.

• If we reset, we had a problem and bCNC resets the TLO to 0.

• If we load a new program, we are not sure that the 1st tool used will be the one that is in the pin.
  In addition, the preamble must contain a G49 to set the initial security conditions. From the first
  lines of the program a call to M6 T# will ask to mount a tool... which we will need to measure the
  length; so new TLO.

2- TLO is managed by grbl, bCNC only measures and transmits the results to through function G43.1 Z(TLO).

The tool change by the WCS procedure is entirely managed by bCNC. It adjusts the Z0 of the WCS according
to the difference in length of the tools which one after the other. With this procedure TLO is not requested; 
so no interaction between the two procedures. TLO should not appear in the WCS procedure.

The original tool change procedure is perfectly functional for the WCS, the TLO procedure requires only marginal adjustment. Personally I avoid modify what is going well to limit chain reactions.

JP