Setup results in error "Named parameter #<_ini[change_position]z>not defined"

The Ini calls the postgui_call_list hal, which in turn calls the custom_postgui.hal. I guess the intermediate step is unnecessary, if you dont break the HAL down into functional blocks (which I believe Norbert recommends). That should not be an issue here though, as the custom_postgui.hal is loading and working. The Multiplexed buttons and hydraulic release buttons out of that HAL work fine.
Mark

I didn't recognise the entry in postgui_call_list hal. Another thing is the Z home position. It seems retracted Z is at 375 and going to -1. Maybe the probing is made for machines retract Z to 0 and travel minus, so the diving into the probe could have been go to change position.

Norberts set up infor for Gmoccapy says that probing uses absolute machine position, so there would not normally be any minus travel would there?

The MAHO has no home switches, it uses the index marks of the glass scale encoders for homing. It is a stationary head with a moving table, so here is here is a the layout showing table position...

___ -1 upper limit switch
--- 0 software upper limit

--- 140 Tool length sensor.(this is just a number I threw in for testing)

--- 250 tool change position (this is just a number I threw in for testing)

--- 370 home position
--- 375 software lower limit
___ 376 lower limit switch

The initial retract up to the Z250 worked fine (I havent tested what happens if the machine is already at Z>250.) It is the rapid from 250 toward the probe where it fails to stop at 140 and start the slow probe motion.
Mark

Norbert, if you get a chance, I would appreciate if you could please review my config files and see where I made a mistake with this set up please.

Mark

Hallo Mark,

Toolchange Position must be in absolute coordinates!
Normally that would mean that the Z Position would have a negative value, as spindle all up is zero and going downwards is negative direction.

Change the DRO to display absolute coordinates (normally blue background) and move the machine to the toolchange position, what does the DRO show? Now move to the tool sensor and give also that coordinates.

Does this help?

Norbert

Hello Norbert, Thanks for taking a look at this.
If I understand correctly, it is normal to set up a CNC machine which ABS Z=0 at the top of travel and all movement negative. (LH Picture). Is that a standard convention for CNC? Should I alter my machine INI?


I have top of travel Z=375, with bottom of travel Z=0, so downward movement is still in the negative direction. To my mind this should make no difference. My machine is just offset by 375 relative to the norm.

With my INI (The full INI and configuration are in post #153283 of this thread) :
[CHANGE_POSITION]
X = 46
Y = 100
Z = 250
[TOOLSENSOR]
X = 46
Y = 100
Z = 140
MAXPROBE= -10

An M6 Txxx command first rapids in Z to Z[ABS] = 250, then rapids to X[ABS]= 46, Y[ABS] = 100, (The tool change position, where it diplayed the absolute positions of
X=46
Y=100,
Z=250 .
It immediately rapids down, but fails to slow down at Z[ABS]= 140 or perform the probing feedrate move down 10mm. I have to E-stop it.

If I jog it to the tool change position, it displays:
X = 46
Y= 100
Z = 131,323 when the sensor switches.

Would it help if I made a short video showing the behaviour?
Mark

While setting up your machine that way will work. There is at least one gotcha you will need to watch out for. And that is, most CAM software will assume that machine Z0 will be a safe position for rapid positioning moves in the other axis and will often call for moving there at the start or end of a file and at tool changes. How your machine coordinates are laid out should not matter otherwise, since the g-code you run will ordinarily be using a work space coordinate system, and that can have it's zero point set where ever you like, usually either at the parts top or bottom.

If you think about it it makes more sense from a generic machine view point to have Z0 at the top of travel. If you are trying to create a convention that works on all machines z0 at the top works on and would be the same for most any machine no matter it's length of Z travel.

Thanks Todd and Norbert for pointing out that this is a normal convention. I can easily change this in the INI, but that alone wont solve the issue of the tool probing move rapiding straight through the assigned level.

Mark

Depending on how the probing routine you are using is written, it could. (I have not used Gmoccapy and I have not looked at the probing routines it uses, so I can't comment further.)

Tonight I modified the INI to reflect Norbert and Todds advice. Zmax is Z[abs]=0 and Zmin is now Z[abs]=-375.

The behaviour has improved, in that it is no longer trying to ram the spindle through the table, but is still creating an error.

I made a short movie to hopefully make the issue clearer, and would appreciate help in addressing the remaining error:


Mark