I installed a Renishaw probe and receiver on my mill. I connected to pin 5 (Bit 44) on the 26 pin connector with a 4.7k ohm resistor as a pull down. I modified my NotifyMach3.c to add the code from the probing example and it seems to work bit there is a delay from when the probe touches to when it sees the touch and stops. Short triggers are missed entirely if I just tap on the stylus the kflop never sees it. I put a scope on the input to the kflop and there is no electrical delay to the input pin.
#include "KMotionDef.h"
//Plugin calls for Mach3 NotifyPlugins Commands
#define X 0
#define Y 1
#define Z 2
float DecelTimeForAxis(int axis);
main()
{
int msg = persist.UserData[6]; // Mach3 notify Message 10000-10999
printf("Mach3 Notify Call, Message = %d\n",msg);
Delay_sec(2.0);
printf("Done\n");
//if (msg==10084)
//{
//Tap();
//}
int msg = persist.UserData[6]; // Mach3 notify Message 10000-10999
printf("Mach3 Notify Call, Message = %d\n",msg);
if (msg==10100)
{
// adjust the commanded position to match the glass scale encoder
DisableAxis(X);
EnableAxisDest(X,chan[X].Position);
}
if (msg==10101)
{
// adjust the commanded position to match the glass scale encoder
DisableAxis(Y);
EnableAxisDest(Y,chan[Y].Position);
}
if (msg==10102)
{
// adjust the commanded position to match the glass scale encoder
DisableAxis(Z);
EnableAxisDest(Z,chan[Z].Position);
}
if (msg==10500)
{
if (CS0_StoppingState == 0)
StopCoordinatedMotion();
else
ResumeCoordinatedMotion();
}
if (msg==10300)
{
// User wants to disable Z (switch to OL)
DisableAxis(Z);
chan[Z].OutputMode = STEP_DIR_MODE;
EnableAxisDest(Z,chan[Z].Position);
}
if (msg==10301)
{
// User wants to enable Z (switch to CL)
DisableAxis(Z);
chan[Z].OutputMode = CL_STEP_DIR_MODE;
EnableAxisDest(Z,chan[Z].Position);
}
// handles probing
//
// flag is 0 - while watching for probe hit
// flag is 1 - if probe was already set from start
// flag is 2 - after successful probe hit
// flag is 3 - Tells Plugin to upload status (3) to
// DRO 1100 and let User handle the error
//
// returns the captured results in User Variables
// X - 50+51
// Y - 52+53
// Z - 54+55
// A - 56+57
// B - 58+59
// C - 60+61
// status result 62
#define PROBE_BIT 44
#define PROBE_ACTIVE_STATE 0
#define PROBE_ERROR_HANDLING 0 // 0 Stops Mach3 on probe error
// #define PROBE_ERROR_HANDLING 3 // 3 User must query DRO 1100 and handle error
if (msg==20000)
{
double *d = (double *)&persist.UserData[MACH3_PROBE_RESULTS_VAR];
int flag=1;
persist.UserData[MACH3_PROBE_STATUS_VAR]=PROBE_ERROR_HANDLING;
while (ReadBit(PROBE_BIT)!=PROBE_ACTIVE_STATE)
{
flag=2;
WaitNextTimeSlice();
}
if (CS0_axis_x>=0) d[0]=chan[CS0_axis_x].Dest;
if (CS0_axis_y>=0) d[1]=chan[CS0_axis_y].Dest;
if (CS0_axis_z>=0) d[2]=chan[CS0_axis_z].Dest;
if (CS0_axis_a>=0) d[3]=chan[CS0_axis_a].Dest;
if (CS0_axis_b>=0) d[4]=chan[CS0_axis_b].Dest;
if (CS0_axis_c>=0) d[5]=chan[CS0_axis_c].Dest;
persist.UserData[MACH3_PROBE_STATUS_VAR]=flag;
StopCoordinatedMotion();
}
}
Doh! Wonder why that was there. I removed the delay and duplicate code.
Anyway, that made a huge difference. There is still a delay though, at 4ipm probing speed it overshoots by .003" so it appears there is a 45ms delay still. Any idea how to get this down?
Based on your velocity, acceleration, and jerk there will be some distance to stop. But the position reported is where the sensor was detected before stopping within a KFLOP time slice (180us)
G31 Z-4.0 F40 (Probe in Z)
G1 Z #2002 (move back to trip point)
M30
Which should return to the trip point, which it does, but that point is 45ms worth of travel below the actual trip point, .0015" at 2ipm, and .0045 at 6ipm.
The way I am currently measuring is I touch off a surface with the MPG to find 0, then use the probe routine to probe the part. Based on where it returns is where I get my numbers from.
Im using a Renishaw HSI probe interface. I have-not measured the amount of delay it introduces into the system, it should not be much. Ill have to hook up a DSO to it and check out the trigger delay.
The mill is a knee mill with pretty large Mitsubishi brushless servos that run off step direction. It has pretty high acceleration rates so I kind of doubt it lags, the follow error display shows a few encoder counts follow error usually at accel/decel but not at a constant speed.
Yeah, I was thinking of doing the double tap method. Has anyone written a .c for that?
135us would be as expected and should be negligible. What is the pink signal you are scoping?
This is an open loop system correct? No encoders? What kind of Drives do you have?
The only thing I can think of is that there is following error where the actual axis position lags behind the commanded position and the following error is proportional to velocity.
Yellow is the probe signal and pink is the signal from the Renishaw interface. I currently have it set to active low.
The machine uses 1kw Mitsubishi servo drives and motors 1kw on X/Y and 1.5kw on the Z. There is almost no follow error, just a few encoder counts at higher speeds with a 32k count encoder.
If I was having follow error to this degree I would not be able to machine parts as accurately as I can with this machine. I can accurately follow complex tool paths at 150ipm. This is a large knee mill, heavier than a generic Bridgeport.