Dynomotion

Group: DynoMotion Message: 5827 From: inbilla Date: 10/20/2012
Subject: Probing with Mach3
Hi There,

I'm trying to setup a basic probe on my machine at the moment.
The probe is connected to pin 5, active low.

I'm trying to probe within Mach3 and have installed the NotifyProbeMach3.c program as shown in the setup documentation. I have set the pin to 5, and the active state to 0.

The probe overall appears to work, mach will begin a movement and then stop shortly after I touch the probe.

My problem lies with the "shortly after". I need the machine to pretty much stop as soon as the probe is activated, at the moment it will continue driving into my workpiece for a short distance.

How can I get this to happen? obviously without losing steps..

I'm trying to Mill a PCB and am probing the surface before doing so.

Thanks

Josh
Group: DynoMotion Message: 5828 From: Tom Kerekes Date: 10/20/2012
Subject: Re: Probing with Mach3
Hi Josh,
 
When the probe is detected KFLOP does an immediate hardware feedhold.  Hardware feedhold in KFLOP works by linearly ramping down the "rate of time".
 
To determine the time to stop all the axes currently in motion are examined for their current speed.  Most likely in your case only Z is moving.  The time to stop is computed based on your current speed, and the acceleration and Jerk settings you have programmed in KFLOP using the formula below:
 
// include jerk time as cushion because we won't be limiting jerk
time =  (vel / ch->Accel) + sqrtf(8.0f * vel/ch->Jerk);
 
Do you have your Acceleration and Jerk settings in KFLOP set to optimal values?  Assuming you do you might be able to stop from the slow probing speed at a higher acceleration than what you could from all (higher) speeds. So you could temporarily set the Z axis Acceleration and Jerk to much higher values and reset them back after the probe.   Of course if you attempt to stop too fast you may lose steps.
 
Let me know how much of this makes sense.
Regards
TK
 
 
 

Group: DynoMotion Message: 5830 From: inbilla Date: 10/20/2012
Subject: Re: Probing with Mach3
Ok,

So to do that, I'd record the current value of acceleration and jerk using the same syntax as the init.c file? Then set them to a new value in the notifyprobemach3.c file? What part of that file runs at beginning of probing? I assume I would reset the value straight after the stopcoordinatedmotion call?

To determine if I'm losing steps, I suppose probing the same spot over and over to see if the returned value drifts?

Thanks Tom!

Josh



--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Josh,
>  
> When the probe is detected KFLOP does an immediate hardware feedhold.  Hardware feedhold in KFLOP works by linearly ramping down the "rate of time".
>  
> To determine the time to stop all the axes currently in motion are examined for their current speed.  Most likely in your case only Z is moving.  The time to stop is computed based on your current speed, and the acceleration and Jerk settings you have programmed in KFLOP using the formula below:
>  
> // include jerk time as cushion because we won't be limiting jerkDo you have your Acceleration and Jerk settings in KFLOP set to optimal values?  Assuming you do you might be able to stop from the slow probing speed at a higher acceleration than what you could from all (higher) speeds. So you could temporarily set the Z axis Acceleration and Jerk to much higher values and reset them back after the probe.   Of course if you attempt to stop too fast you may lose steps.
>  
> Let me know how much of this makes sense.
> Regards
> TK
>  
>  
>  
>
> From: inbilla <inbilla@...>
> To: DynoMotion@yahoogroups.com
> Sent: Saturday, October 20, 2012 1:23 AM
> Subject: [DynoMotion] Probing with Mach3
>
>  
> Hi There,
>
> I'm trying to setup a basic probe on my machine at the moment.
> The probe is connected to pin 5, active low.
>
> I'm trying to probe within Mach3 and have installed the NotifyProbeMach3.c program as shown in the setup documentation. I have set the pin to 5, and the active state to 0.
>
> The probe overall appears to work, mach will begin a movement and then stop shortly after I touch the probe.
>
> My problem lies with the "shortly after". I need the machine to pretty much stop as soon as the probe is activated, at the moment it will continue driving into my workpiece for a short distance.
>
> How can I get this to happen? obviously without losing steps..
>
> I'm trying to Mill a PCB and am probing the surface before doing so.
>
> Thanks
>
> Josh
>
>
> time = (vel / ch->Accel) + sqrtf(8.0f * vel/ch->Jerk);  
>
Group: DynoMotion Message: 5831 From: inbilla Date: 10/21/2012
Subject: Re: Probing with Mach3
Ok, so this is what I've got now:

double *d = (double *)&persist.UserData[MACH3_PROBE_RESULTS_VAR];
int flag=1;

// Record the previous values of accel/jerk for the Z axis
double zAccel = ch2->Accel;
double zJerk = ch2->Jerk;

ch2->Accel = zAccel * 4;
ch2->Jerk = zJerk * 4;

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();

// Reset the accel/jerk
ch2->Accel = zAccel;
ch2->Jerk = zJerk;

If I use a feedrate of 30, then I've found I seem to get rather reliable results, so I'm fairly happy with that for now.
The trouble I'm having now is that the reported position of the G31 command is in machine coords, which apparently for mach2 is fine,
but mach3 expects things to be returned in program coords. Any idea how I could achieve that?

Thanks Tom

Josh

--- In DynoMotion@yahoogroups.com, "inbilla" <inbilla@...> wrote:
>
> Ok,
>
> So to do that, I'd record the current value of acceleration and jerk using the same syntax as the init.c file? Then set them to a new value in the notifyprobemach3.c file? What part of that file runs at beginning of probing? I assume I would reset the value straight after the stopcoordinatedmotion call?
>
> To determine if I'm losing steps, I suppose probing the same spot over and over to see if the returned value drifts?
>
> Thanks Tom!
>
> Josh
>
>
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Josh,
> >  
> > When the probe is detected KFLOP does an immediate hardware feedhold.  Hardware feedhold in KFLOP works by linearly ramping down the "rate of time".
> >  
> > To determine the time to stop all the axes currently in motion are examined for their current speed.  Most likely in your case only Z is moving.  The time to stop is computed based on your current speed, and the acceleration and Jerk settings you have programmed in KFLOP using the formula below:
> >  
> > // include jerk time as cushion because we won't be limiting jerkDo you have your Acceleration and Jerk settings in KFLOP set to optimal values?  Assuming you do you might be able to stop from the slow probing speed at a higher acceleration than what you could from all (higher) speeds. So you could temporarily set the Z axis Acceleration and Jerk to much higher values and reset them back after the probe.   Of course if you attempt to stop too fast you may lose steps.
> >  
> > Let me know how much of this makes sense.
> > Regards
> > TK
> >  
> >  
> >  
> >
> > From: inbilla <inbilla@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Saturday, October 20, 2012 1:23 AM
> > Subject: [DynoMotion] Probing with Mach3
> >
> >  
> > Hi There,
> >
> > I'm trying to setup a basic probe on my machine at the moment.
> > The probe is connected to pin 5, active low.
> >
> > I'm trying to probe within Mach3 and have installed the NotifyProbeMach3.c program as shown in the setup documentation. I have set the pin to 5, and the active state to 0.
> >
> > The probe overall appears to work, mach will begin a movement and then stop shortly after I touch the probe.
> >
> > My problem lies with the "shortly after". I need the machine to pretty much stop as soon as the probe is activated, at the moment it will continue driving into my workpiece for a short distance.
> >
> > How can I get this to happen? obviously without losing steps..
> >
> > I'm trying to Mill a PCB and am probing the surface before doing so.
> >
> > Thanks
> >
> > Josh
> >
> >
> > time = (vel / ch->Accel) + sqrtf(8.0f * vel/ch->Jerk);  
> >
>
Group: DynoMotion Message: 5836 From: inbilla Date: 10/21/2012
Subject: Re: Probing with Mach3
So if the returned results are in machine coords. I would need to do something like this:

originalProgramCoords = getCurrentProgramCoords(zAxis)
originalMachineCoords = getCurrentDest(zAxis)

while(probeState != Active)
{
waitForNextTimeSlice()
}

newMachineCoords = getCurrentDest(zAxis)

#2002 = originalProgramCoords + (newMachineCoords - originalMachineCoords )

But from the KFLOP, I don't believe I have any way of accessing the current program coords, unless the KFlop plugin makes those values available to the KFlop in some way as user data?

Is the only way to resolve this to modify the Mach3 KFlop plugin?

Josh


--- In DynoMotion@yahoogroups.com, "inbilla" <inbilla@...> wrote:
>
> Ok, so this is what I've got now:
>
> double *d = (double *)&persist.UserData[MACH3_PROBE_RESULTS_VAR];
> int flag=1;
>
> // Record the previous values of accel/jerk for the Z axis
> double zAccel = ch2->Accel;
> double zJerk = ch2->Jerk;
>
> ch2->Accel = zAccel * 4;
> ch2->Jerk = zJerk * 4;
>
> 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();
>
> // Reset the accel/jerk
> ch2->Accel = zAccel;
> ch2->Jerk = zJerk;
>
> If I use a feedrate of 30, then I've found I seem to get rather reliable results, so I'm fairly happy with that for now.
> The trouble I'm having now is that the reported position of the G31 command is in machine coords, which apparently for mach2 is fine,
> but mach3 expects things to be returned in program coords. Any idea how I could achieve that?
>
> Thanks Tom
>
> Josh
>
> --- In DynoMotion@yahoogroups.com, "inbilla" <inbilla@> wrote:
> >
> > Ok,
> >
> > So to do that, I'd record the current value of acceleration and jerk using the same syntax as the init.c file? Then set them to a new value in the notifyprobemach3.c file? What part of that file runs at beginning of probing? I assume I would reset the value straight after the stopcoordinatedmotion call?
> >
> > To determine if I'm losing steps, I suppose probing the same spot over and over to see if the returned value drifts?
> >
> > Thanks Tom!
> >
> > Josh
> >
> >
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Josh,
> > >  
> > > When the probe is detected KFLOP does an immediate hardware feedhold.  Hardware feedhold in KFLOP works by linearly ramping down the "rate of time".
> > >  
> > > To determine the time to stop all the axes currently in motion are examined for their current speed.  Most likely in your case only Z is moving.  The time to stop is computed based on your current speed, and the acceleration and Jerk settings you have programmed in KFLOP using the formula below:
> > >  
> > > // include jerk time as cushion because we won't be limiting jerkDo you have your Acceleration and Jerk settings in KFLOP set to optimal values?  Assuming you do you might be able to stop from the slow probing speed at a higher acceleration than what you could from all (higher) speeds. So you could temporarily set the Z axis Acceleration and Jerk to much higher values and reset them back after the probe.   Of course if you attempt to stop too fast you may lose steps.
> > >  
> > > Let me know how much of this makes sense.
> > > Regards
> > > TK
> > >  
> > >  
> > >  
> > >
> > > From: inbilla <inbilla@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Saturday, October 20, 2012 1:23 AM
> > > Subject: [DynoMotion] Probing with Mach3
> > >
> > >  
> > > Hi There,
> > >
> > > I'm trying to setup a basic probe on my machine at the moment.
> > > The probe is connected to pin 5, active low.
> > >
> > > I'm trying to probe within Mach3 and have installed the NotifyProbeMach3.c program as shown in the setup documentation. I have set the pin to 5, and the active state to 0.
> > >
> > > The probe overall appears to work, mach will begin a movement and then stop shortly after I touch the probe.
> > >
> > > My problem lies with the "shortly after". I need the machine to pretty much stop as soon as the probe is activated, at the moment it will continue driving into my workpiece for a short distance.
> > >
> > > How can I get this to happen? obviously without losing steps..
> > >
> > > I'm trying to Mill a PCB and am probing the surface before doing so.
> > >
> > > Thanks
> > >
> > > Josh
> > >
> > >
> > > time = (vel / ch->Accel) + sqrtf(8.0f * vel/ch->Jerk);  
> > >
> >
>
Group: DynoMotion Message: 5837 From: TK Date: 10/21/2012
Subject: Re: Probing with Mach3
Hi Josh,

We are trying to add that to the Plugin.  Hope to have something soon. A work around might be to add in the work offset (variable #5220) in the GCode. 

Regards
TK

On Oct 21, 2012, at 9:11 PM, "inbilla" <inbilla@...> wrote:

 

So if the returned results are in machine coords. I would need to do something like this:

originalProgramCoords = getCurrentProgramCoords(zAxis)
originalMachineCoords = getCurrentDest(zAxis)

while(probeState != Active)
{
waitForNextTimeSlice()
}

newMachineCoords = getCurrentDest(zAxis)

#2002 = originalProgramCoords + (newMachineCoords - originalMachineCoords )

But from the KFLOP, I don't believe I have any way of accessing the current program coords, unless the KFlop plugin makes those values available to the KFlop in some way as user data?

Is the only way to resolve this to modify the Mach3 KFlop plugin?

Josh

--- In DynoMotion@yahoogroups.com, "inbilla" <inbilla@...> wrote:
>
> Ok, so this is what I've got now:
>
> double *d = (double *)&persist.UserData[MACH3_PROBE_RESULTS_VAR];
> int flag=1;
>
> // Record the previous values of accel/jerk for the Z axis
> double zAccel = ch2->Accel;
> double zJerk = ch2->Jerk;
>
> ch2->Accel = zAccel * 4;
> ch2->Jerk = zJerk * 4;
>
> 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();
>
> // Reset the accel/jerk
> ch2->Accel = zAccel;
> ch2->Jerk = zJerk;
>
> If I use a feedrate of 30, then I've found I seem to get rather reliable results, so I'm fairly happy with that for now.
> The trouble I'm having now is that the reported position of the G31 command is in machine coords, which apparently for mach2 is fine,
> but mach3 expects things to be returned in program coords. Any idea how I could achieve that?
>
> Thanks Tom
>
> Josh
>
> --- In DynoMotion@yahoogroups.com, "inbilla" <inbilla@> wrote:
> >
> > Ok,
> >
> > So to do that, I'd record the current value of acceleration and jerk using the same syntax as the init.c file? Then set them to a new value in the notifyprobemach3.c file? What part of that file runs at beginning of probing? I assume I would reset the value straight after the stopcoordinatedmotion call?
> >
> > To determine if I'm losing steps, I suppose probing the same spot over and over to see if the returned value drifts?
> >
> > Thanks Tom!
> >
> > Josh
> >
> >
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Josh,
> > >  
> > > When the probe is detected KFLOP does an immediate hardware feedhold.  Hardware feedhold in KFLOP works by linearly ramping down the "rate of time".
> > >  
> > > To determine the time to stop all the axes currently in motion are examined for their current speed.  Most likely in your case only Z is moving.  The time to stop is computed based on your current speed, and the acceleration and Jerk settings you have programmed in KFLOP using the formula below:
> > >  
> > > // include jerk time as cushion because we won't be limiting jerkDo you have your Acceleration and Jerk settings in KFLOP set to optimal values?  Assuming you do you might be able to stop from the slow probing speed at a higher acceleration than what you could from all (higher) speeds. So you could temporarily set the Z axis Acceleration and Jerk to much higher values and reset them back after the probe.   Of course if you attempt to stop too fast you may lose steps.
> > >  
> > > Let me know how much of this makes sense.
> > > Regards
> > > TK
> > >  
> > >  
> > >  
> > >
> > > From: inbilla <inbilla@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Saturday, October 20, 2012 1:23 AM
> > > Subject: [DynoMotion] Probing with Mach3
> > >
> > >  
> > > Hi There,
> > >
> > > I'm trying to setup a basic probe on my machine at the moment.
> > > The probe is connected to pin 5, active low.
> > >
> > > I'm trying to probe within Mach3 and have installed the NotifyProbeMach3.c program as shown in the setup documentation. I have set the pin to 5, and the active state to 0.
> > >
> > > The probe overall appears to work, mach will begin a movement and then stop shortly after I touch the probe.
> > >
> > > My problem lies with the "shortly after". I need the machine to pretty much stop as soon as the probe is activated, at the moment it will continue driving into my workpiece for a short distance.
> > >
> > > How can I get this to happen? obviously without losing steps..
> > >
> > > I'm trying to Mill a PCB and am probing the surface before doing so.
> > >
> > > Thanks
> > >
> > > Josh
> > >
> > >
> > > time = (vel / ch->Accel) + sqrtf(8.0f * vel/ch->Jerk);  
> > >
> >
>
Group: DynoMotion Message: 5838 From: inbilla Date: 10/22/2012
Subject: Re: Probing with Mach3
Hi Tom,

Ok then, thanks, I'll probably wait for the update then if it'll be relatively soon :)

I honestly don't think a 5220 workaround will work at this point as it's my understanding that the G31 code in Mach3 ignores offsets, and the generated PCB milling gcode relies upon the G31 surface profiling to make sure it only takes a certain amount off the surface of the piece.

Let me know when you have something, and I'm more than happy to test alpha/beta code.

Thanks Tom, I appreciate it.

Josh

--- In DynoMotion@yahoogroups.com, TK <tk@...> wrote:
>
> Hi Josh,
>
> We are trying to add that to the Plugin. Hope to have something soon. A work around might be to add in the work offset (variable #5220) in the GCode.
>
> Regards
> TK
>
> On Oct 21, 2012, at 9:11 PM, "inbilla" <inbilla@...> wrote:
>
> > So if the returned results are in machine coords. I would need to do something like this:
> >
> > originalProgramCoords = getCurrentProgramCoords(zAxis)
> > originalMachineCoords = getCurrentDest(zAxis)
> >
> > while(probeState != Active)
> > {
> > waitForNextTimeSlice()
> > }
> >
> > newMachineCoords = getCurrentDest(zAxis)
> >
> > #2002 = originalProgramCoords + (newMachineCoords - originalMachineCoords )
> >
> > But from the KFLOP, I don't believe I have any way of accessing the current program coords, unless the KFlop plugin makes those values available to the KFlop in some way as user data?
> >
> > Is the only way to resolve this to modify the Mach3 KFlop plugin?
> >
> > Josh
> >
> > --- In DynoMotion@yahoogroups.com, "inbilla" <inbilla@> wrote:
> > >
> > > Ok, so this is what I've got now:
> > >
> > > double *d = (double *)&persist.UserData[MACH3_PROBE_RESULTS_VAR];
> > > int flag=1;
> > >
> > > // Record the previous values of accel/jerk for the Z axis
> > > double zAccel = ch2->Accel;
> > > double zJerk = ch2->Jerk;
> > >
> > > ch2->Accel = zAccel * 4;
> > > ch2->Jerk = zJerk * 4;
> > >
> > > 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();
> > >
> > > // Reset the accel/jerk
> > > ch2->Accel = zAccel;
> > > ch2->Jerk = zJerk;
> > >
> > > If I use a feedrate of 30, then I've found I seem to get rather reliable results, so I'm fairly happy with that for now.
> > > The trouble I'm having now is that the reported position of the G31 command is in machine coords, which apparently for mach2 is fine,
> > > but mach3 expects things to be returned in program coords. Any idea how I could achieve that?
> > >
> > > Thanks Tom
> > >
> > > Josh
> > >
> > > --- In DynoMotion@yahoogroups.com, "inbilla" <inbilla@> wrote:
> > > >
> > > > Ok,
> > > >
> > > > So to do that, I'd record the current value of acceleration and jerk using the same syntax as the init.c file? Then set them to a new value in the notifyprobemach3.c file? What part of that file runs at beginning of probing? I assume I would reset the value straight after the stopcoordinatedmotion call?
> > > >
> > > > To determine if I'm losing steps, I suppose probing the same spot over and over to see if the returned value drifts?
> > > >
> > > > Thanks Tom!
> > > >
> > > > Josh
> > > >
> > > >
> > > >
> > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > >
> > > > > Hi Josh,
> > > > >
> > > > > When the probe is detected KFLOP does an immediate hardware feedhold. Hardware feedhold in KFLOP works by linearly ramping down the "rate of time".
> > > > >
> > > > > To determine the time to stop all the axes currently in motion are examined for their current speed. Most likely in your case only Z is moving. The time to stop is computed based on your current speed, and the acceleration and Jerk settings you have programmed in KFLOP using the formula below:
> > > > >
> > > > > // include jerk time as cushion because we won't be limiting jerkDo you have your Acceleration and Jerk settings in KFLOP set to optimal values? Assuming you do you might be able to stop from the slow probing speed at a higher acceleration than what you could from all (higher) speeds. So you could temporarily set the Z axis Acceleration and Jerk to much higher values and reset them back after the probe. Of course if you attempt to stop too fast you may lose steps.
> > > > >
> > > > > Let me know how much of this makes sense.
> > > > > Regards
> > > > > TK
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > From: inbilla <inbilla@>
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Sent: Saturday, October 20, 2012 1:23 AM
> > > > > Subject: [DynoMotion] Probing with Mach3
> > > > >
> > > > >
> > > > > Hi There,
> > > > >
> > > > > I'm trying to setup a basic probe on my machine at the moment.
> > > > > The probe is connected to pin 5, active low.
> > > > >
> > > > > I'm trying to probe within Mach3 and have installed the NotifyProbeMach3.c program as shown in the setup documentation. I have set the pin to 5, and the active state to 0.
> > > > >
> > > > > The probe overall appears to work, mach will begin a movement and then stop shortly after I touch the probe.
> > > > >
> > > > > My problem lies with the "shortly after". I need the machine to pretty much stop as soon as the probe is activated, at the moment it will continue driving into my workpiece for a short distance.
> > > > >
> > > > > How can I get this to happen? obviously without losing steps..
> > > > >
> > > > > I'm trying to Mill a PCB and am probing the surface before doing so.
> > > > >
> > > > > Thanks
> > > > >
> > > > > Josh
> > > > >
> > > > >
> > > > > time = (vel / ch->Accel) + sqrtf(8.0f * vel/ch->Jerk);
> > > > >
> > > >
> > >
> >
> >
>
Group: DynoMotion Message: 5839 From: himykabibble Date: 10/22/2012
Subject: Re: Probing with Mach3
FWIW - I do probing in two steps - a fast probe, which does over-shoot, to find the surface/edge, then back-up a bit, and do a second probe as a series of small, discrete steps (0.0001"). Works very well.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, "inbilla" <inbilla@...> wrote:
>
> Hi Tom,
>
> Ok then, thanks, I'll probably wait for the update then if it'll be relatively soon :)
>
> I honestly don't think a 5220 workaround will work at this point as it's my understanding that the G31 code in Mach3 ignores offsets, and the generated PCB milling gcode relies upon the G31 surface profiling to make sure it only takes a certain amount off the surface of the piece.
>
> Let me know when you have something, and I'm more than happy to test alpha/beta code.
>
> Thanks Tom, I appreciate it.
>
> Josh
>
> --- In DynoMotion@yahoogroups.com, TK <tk@> wrote:
> >
> > Hi Josh,
> >
> > We are trying to add that to the Plugin. Hope to have something soon. A work around might be to add in the work offset (variable #5220) in the GCode.
> >
> > Regards
> > TK
> >
> > On Oct 21, 2012, at 9:11 PM, "inbilla" <inbilla@> wrote:
> >
> > > So if the returned results are in machine coords. I would need to do something like this:
> > >
> > > originalProgramCoords = getCurrentProgramCoords(zAxis)
> > > originalMachineCoords = getCurrentDest(zAxis)
> > >
> > > while(probeState != Active)
> > > {
> > > waitForNextTimeSlice()
> > > }
> > >
> > > newMachineCoords = getCurrentDest(zAxis)
> > >
> > > #2002 = originalProgramCoords + (newMachineCoords - originalMachineCoords )
> > >
> > > But from the KFLOP, I don't believe I have any way of accessing the current program coords, unless the KFlop plugin makes those values available to the KFlop in some way as user data?
> > >
> > > Is the only way to resolve this to modify the Mach3 KFlop plugin?
> > >
> > > Josh
> > >
> > > --- In DynoMotion@yahoogroups.com, "inbilla" <inbilla@> wrote:
> > > >
> > > > Ok, so this is what I've got now:
> > > >
> > > > double *d = (double *)&persist.UserData[MACH3_PROBE_RESULTS_VAR];
> > > > int flag=1;
> > > >
> > > > // Record the previous values of accel/jerk for the Z axis
> > > > double zAccel = ch2->Accel;
> > > > double zJerk = ch2->Jerk;
> > > >
> > > > ch2->Accel = zAccel * 4;
> > > > ch2->Jerk = zJerk * 4;
> > > >
> > > > 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();
> > > >
> > > > // Reset the accel/jerk
> > > > ch2->Accel = zAccel;
> > > > ch2->Jerk = zJerk;
> > > >
> > > > If I use a feedrate of 30, then I've found I seem to get rather reliable results, so I'm fairly happy with that for now.
> > > > The trouble I'm having now is that the reported position of the G31 command is in machine coords, which apparently for mach2 is fine,
> > > > but mach3 expects things to be returned in program coords. Any idea how I could achieve that?
> > > >
> > > > Thanks Tom
> > > >
> > > > Josh
> > > >
> > > > --- In DynoMotion@yahoogroups.com, "inbilla" <inbilla@> wrote:
> > > > >
> > > > > Ok,
> > > > >
> > > > > So to do that, I'd record the current value of acceleration and jerk using the same syntax as the init.c file? Then set them to a new value in the notifyprobemach3.c file? What part of that file runs at beginning of probing? I assume I would reset the value straight after the stopcoordinatedmotion call?
> > > > >
> > > > > To determine if I'm losing steps, I suppose probing the same spot over and over to see if the returned value drifts?
> > > > >
> > > > > Thanks Tom!
> > > > >
> > > > > Josh
> > > > >
> > > > >
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > >
> > > > > > Hi Josh,
> > > > > >
> > > > > > When the probe is detected KFLOP does an immediate hardware feedhold. Hardware feedhold in KFLOP works by linearly ramping down the "rate of time".
> > > > > >
> > > > > > To determine the time to stop all the axes currently in motion are examined for their current speed. Most likely in your case only Z is moving. The time to stop is computed based on your current speed, and the acceleration and Jerk settings you have programmed in KFLOP using the formula below:
> > > > > >
> > > > > > // include jerk time as cushion because we won't be limiting jerkDo you have your Acceleration and Jerk settings in KFLOP set to optimal values? Assuming you do you might be able to stop from the slow probing speed at a higher acceleration than what you could from all (higher) speeds. So you could temporarily set the Z axis Acceleration and Jerk to much higher values and reset them back after the probe. Of course if you attempt to stop too fast you may lose steps.
> > > > > >
> > > > > > Let me know how much of this makes sense.
> > > > > > Regards
> > > > > > TK
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: inbilla <inbilla@>
> > > > > > To: DynoMotion@yahoogroups.com
> > > > > > Sent: Saturday, October 20, 2012 1:23 AM
> > > > > > Subject: [DynoMotion] Probing with Mach3
> > > > > >
> > > > > >
> > > > > > Hi There,
> > > > > >
> > > > > > I'm trying to setup a basic probe on my machine at the moment.
> > > > > > The probe is connected to pin 5, active low.
> > > > > >
> > > > > > I'm trying to probe within Mach3 and have installed the NotifyProbeMach3.c program as shown in the setup documentation. I have set the pin to 5, and the active state to 0.
> > > > > >
> > > > > > The probe overall appears to work, mach will begin a movement and then stop shortly after I touch the probe.
> > > > > >
> > > > > > My problem lies with the "shortly after". I need the machine to pretty much stop as soon as the probe is activated, at the moment it will continue driving into my workpiece for a short distance.
> > > > > >
> > > > > > How can I get this to happen? obviously without losing steps..
> > > > > >
> > > > > > I'm trying to Mill a PCB and am probing the surface before doing so.
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > Josh
> > > > > >
> > > > > >
> > > > > > time = (vel / ch->Accel) + sqrtf(8.0f * vel/ch->Jerk);
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
>
Group: DynoMotion Message: 5840 From: Tom Kerekes Date: 10/22/2012
Subject: Re: Probing with Mach3
Hi Josh,
 
Here is a version where the Mach3 Plugin should return GCode Coordinates rather than Machine Coordinates.  I hope this doesn't break other Users' code.
 
 
Please let us know if it works for you.
 
Regards
TK


Group: DynoMotion Message: 5843 From: inbilla Date: 10/22/2012
Subject: Re: Probing with Mach3
Thanks Tom,

I hope not too,
I'll check this out in about 9 hours.

If the relevant variables were available to the KFlop as UserData then
I imagine anyone wishing to have the old behavior could simply use the old notify.c, and anyone needing program coords could use a new notify.c...

Speaking of which,

I assume I don't have to modify the existing notifyProbe.c for this plugin? it's all done internally i assume?

Thanks again, I'll let you know how it goes

Josh

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Josh,
>  
> Here is a version where the Mach3 Plugin should return GCode Coordinates rather than Machine Coordinates.  I hope this doesn't break other Users' code.
>  
> http://dynomotion.com/Software/KMotion430e.exe
>  
> Please let us know if it works for you.
>  
> Regards
> TK
>
>
>
> ________________________________
> From: inbilla <inbilla@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, October 22, 2012 12:54 AM
> Subject: [DynoMotion] Re: Probing with Mach3
>
>  
> Hi Tom,
>
> Ok then, thanks, I'll probably wait for the update then if it'll be relatively soon :)
>
> I honestly don't think a 5220 workaround will work at this point as it's my understanding that the G31 code in Mach3 ignores offsets, and the generated PCB milling gcode relies upon the G31 surface profiling to make sure it only takes a certain amount off the surface of the piece.
>
> Let me know when you have something, and I'm more than happy to test alpha/beta code.
>
> Thanks Tom, I appreciate it.
>
> Josh
>
> --- In mailto:DynoMotion%40yahoogroups.com, TK <tk@> wrote:
> >
> > Hi Josh,
> >
> > We are trying to add that to the Plugin. Hope to have something soon. A work around might be to add in the work offset (variable #5220) in the GCode.
> >
> > Regards
> > TK
> >
> > On Oct 21, 2012, at 9:11 PM, "inbilla" <inbilla@> wrote:
> >
> > > So if the returned results are in machine coords. I would need to do something like this:
> > >
> > > originalProgramCoords = getCurrentProgramCoords(zAxis)
> > > originalMachineCoords = getCurrentDest(zAxis)
> > >
> > > while(probeState != Active)
> > > {
> > > waitForNextTimeSlice()
> > > }
> > >
> > > newMachineCoords = getCurrentDest(zAxis)
> > >
> > > #2002 = originalProgramCoords + (newMachineCoords - originalMachineCoords )
> > >
> > > But from the KFLOP, I don't believe I have any way of accessing the current program coords, unless the KFlop plugin makes those values available to the KFlop in some way as user data?
> > >
> > > Is the only way to resolve this to modify the Mach3 KFlop plugin?
> > >
> > > Josh
> > >
> > > --- In mailto:DynoMotion%40yahoogroups.com, "inbilla" <inbilla@> wrote:
> > > >
> > > > Ok, so this is what I've got now:
> > > >
> > > > double *d = (double *)&persist.UserData[MACH3_PROBE_RESULTS_VAR];
> > > > int flag=1;
> > > >
> > > > // Record the previous values of accel/jerk for the Z axis
> > > > double zAccel = ch2->Accel;
> > > > double zJerk = ch2->Jerk;
> > > >
> > > > ch2->Accel = zAccel * 4;
> > > > ch2->Jerk = zJerk * 4;
> > > >
> > > > 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();
> > > >
> > > > // Reset the accel/jerk
> > > > ch2->Accel = zAccel;
> > > > ch2->Jerk = zJerk;
> > > >
> > > > If I use a feedrate of 30, then I've found I seem to get rather reliable results, so I'm fairly happy with that for now.
> > > > The trouble I'm having now is that the reported position of the G31 command is in machine coords, which apparently for mach2 is fine,
> > > > but mach3 expects things to be returned in program coords. Any idea how I could achieve that?
> > > >
> > > > Thanks Tom
> > > >
> > > > Josh
> > > >
> > > > --- In mailto:DynoMotion%40yahoogroups.com, "inbilla" <inbilla@> wrote:
> > > > >
> > > > > Ok,
> > > > >
> > > > > So to do that, I'd record the current value of acceleration and jerk using the same syntax as the init.c file? Then set them to a new value in the notifyprobemach3.c file? What part of that file runs at beginning of probing? I assume I would reset the value straight after the stopcoordinatedmotion call?
> > > > >
> > > > > To determine if I'm losing steps, I suppose probing the same spot over and over to see if the returned value drifts?
> > > > >
> > > > > Thanks Tom!
> > > > >
> > > > > Josh
> > > > >
> > > > >
> > > > >
> > > > > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > >
> > > > > > Hi Josh,
> > > > > >
> > > > > > When the probe is detected KFLOP does an immediate hardware feedhold. Hardware feedhold in KFLOP works by linearly ramping down the "rate of time".
> > > > > >
> > > > > > To determine the time to stop all the axes currently in motion are examined for their current speed. Most likely in your case only Z is moving. The time to stop is computed based on your current speed, and the acceleration and Jerk settings you have programmed in KFLOP using the formula below:
> > > > > >
> > > > > > // include jerk time as cushion because we won't be limiting jerkDo you have your Acceleration and Jerk settings in KFLOP set to optimal values? Assuming you do you might be able to stop from the slow probing speed at a higher acceleration than what you could from all (higher) speeds. So you could temporarily set the Z axis Acceleration and Jerk to much higher values and reset them back after the probe. Of course if you attempt to stop too fast you may lose steps.
> > > > > >
> > > > > > Let me know how much of this makes sense.
> > > > > > Regards
> > > > > > TK
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: inbilla <inbilla@>
> > > > > > To: mailto:DynoMotion%40yahoogroups.com
> > > > > > Sent: Saturday, October 20, 2012 1:23 AM
> > > > > > Subject: [DynoMotion] Probing with Mach3
> > > > > >
> > > > > >
> > > > > > Hi There,
> > > > > >
> > > > > > I'm trying to setup a basic probe on my machine at the moment.
> > > > > > The probe is connected to pin 5, active low.
> > > > > >
> > > > > > I'm trying to probe within Mach3 and have installed the NotifyProbeMach3.c program as shown in the setup documentation. I have set the pin to 5, and the active state to 0.
> > > > > >
> > > > > > The probe overall appears to work, mach will begin a movement and then stop shortly after I touch the probe.
> > > > > >
> > > > > > My problem lies with the "shortly after". I need the machine to pretty much stop as soon as the probe is activated, at the moment it will continue driving into my workpiece for a short distance.
> > > > > >
> > > > > > How can I get this to happen? obviously without losing steps..
> > > > > >
> > > > > > I'm trying to Mill a PCB and am probing the surface before doing so.
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > Josh
> > > > > >
> > > > > >
> > > > > > time = (vel / ch->Accel) + sqrtf(8.0f * vel/ch->Jerk);
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
>
Group: DynoMotion Message: 5845 From: Tom Kerekes Date: 10/22/2012
Subject: Re: Probing with Mach3
Hi Josh,
 
Interesting point.  Yes the change was internal to the Plugin so no change to the NotifyProbe.c should be required.
 
Regards
TK

Group: DynoMotion Message: 5852 From: inbilla Date: 10/23/2012
Subject: Re: Probing with Mach3
Hi Tom,

I've just downloaded it and given it a shot, it certainly seems to be working in program coordinates now which is fantastic! Thank you very much!

Now I can go ahead and tune for accuracy and get milling some test PCB's!

Much appreciated!

Josh

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Josh,
>  
> Interesting point.  Yes the change was internal to the Plugin so no change to the NotifyProbe.c should be required.
>  
> Regards
> TK
>
>
> ________________________________
> From: inbilla <inbilla@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, October 22, 2012 5:31 PM
> Subject: [DynoMotion] Re: Probing with Mach3
>
>  
> Thanks Tom,
>
> I hope not too,
> I'll check this out in about 9 hours.
>
> If the relevant variables were available to the KFlop as UserData then
> I imagine anyone wishing to have the old behavior could simply use the old notify.c, and anyone needing program coords could use a new notify.c...
>
> Speaking of which,
>
> I assume I don't have to modify the existing notifyProbe.c for this plugin? it's all done internally i assume?
>
> Thanks again, I'll let you know how it goes
>
> Josh
>
> --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Josh,
> >  
> > Here is a version where the Mach3 Plugin should return GCode Coordinates rather than Machine Coordinates.  I hope this doesn't break other Users' code.
> >  
> > http://dynomotion.com/Software/KMotion430e.exe
> >  
> > Please let us know if it works for you.
> >  
> > Regards
> > TK
> >
> >
> >
> > ________________________________
> > From: inbilla <inbilla@>
> > To: mailto:DynoMotion%40yahoogroups.com
> > Sent: Monday, October 22, 2012 12:54 AM
> > Subject: [DynoMotion] Re: Probing with Mach3
> >
> >  
> > Hi Tom,
> >
> > Ok then, thanks, I'll probably wait for the update then if it'll be relatively soon :)
> >
> > I honestly don't think a 5220 workaround will work at this point as it's my understanding that the G31 code in Mach3 ignores offsets, and the generated PCB milling gcode relies upon the G31 surface profiling to make sure it only takes a certain amount off the surface of the piece.
> >
> > Let me know when you have something, and I'm more than happy to test alpha/beta code.
> >
> > Thanks Tom, I appreciate it.
> >
> > Josh
> >
> > --- In mailto:DynoMotion%40yahoogroups.com, TK <tk@> wrote:
> > >
> > > Hi Josh,
> > >
> > > We are trying to add that to the Plugin. Hope to have something soon. A work around might be to add in the work offset (variable #5220) in the GCode.
> > >
> > > Regards
> > > TK
> > >
> > > On Oct 21, 2012, at 9:11 PM, "inbilla" <inbilla@> wrote:
> > >
> > > > So if the returned results are in machine coords. I would need to do something like this:
> > > >
> > > > originalProgramCoords = getCurrentProgramCoords(zAxis)
> > > > originalMachineCoords = getCurrentDest(zAxis)
> > > >
> > > > while(probeState != Active)
> > > > {
> > > > waitForNextTimeSlice()
> > > > }
> > > >
> > > > newMachineCoords = getCurrentDest(zAxis)
> > > >
> > > > #2002 = originalProgramCoords + (newMachineCoords - originalMachineCoords )
> > > >
> > > > But from the KFLOP, I don't believe I have any way of accessing the current program coords, unless the KFlop plugin makes those values available to the KFlop in some way as user data?
> > > >
> > > > Is the only way to resolve this to modify the Mach3 KFlop plugin?
> > > >
> > > > Josh
> > > >
> > > > --- In mailto:DynoMotion%40yahoogroups.com, "inbilla" <inbilla@> wrote:
> > > > >
> > > > > Ok, so this is what I've got now:
> > > > >
> > > > > double *d = (double *)&persist.UserData[MACH3_PROBE_RESULTS_VAR];
> > > > > int flag=1;
> > > > >
> > > > > // Record the previous values of accel/jerk for the Z axis
> > > > > double zAccel = ch2->Accel;
> > > > > double zJerk = ch2->Jerk;
> > > > >
> > > > > ch2->Accel = zAccel * 4;
> > > > > ch2->Jerk = zJerk * 4;
> > > > >
> > > > > 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();
> > > > >
> > > > > // Reset the accel/jerk
> > > > > ch2->Accel = zAccel;
> > > > > ch2->Jerk = zJerk;
> > > > >
> > > > > If I use a feedrate of 30, then I've found I seem to get rather reliable results, so I'm fairly happy with that for now.
> > > > > The trouble I'm having now is that the reported position of the G31 command is in machine coords, which apparently for mach2 is fine,
> > > > > but mach3 expects things to be returned in program coords. Any idea how I could achieve that?
> > > > >
> > > > > Thanks Tom
> > > > >
> > > > > Josh
> > > > >
> > > > > --- In mailto:DynoMotion%40yahoogroups.com, "inbilla" <inbilla@> wrote:
> > > > > >
> > > > > > Ok,
> > > > > >
> > > > > > So to do that, I'd record the current value of acceleration and jerk using the same syntax as the init.c file? Then set them to a new value in the notifyprobemach3.c file? What part of that file runs at beginning of probing? I assume I would reset the value straight after the stopcoordinatedmotion call?
> > > > > >
> > > > > > To determine if I'm losing steps, I suppose probing the same spot over and over to see if the returned value drifts?
> > > > > >
> > > > > > Thanks Tom!
> > > > > >
> > > > > > Josh
> > > > > >
> > > > > >
> > > > > >
> > > > > > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > > >
> > > > > > > Hi Josh,
> > > > > > >
> > > > > > > When the probe is detected KFLOP does an immediate hardware feedhold. Hardware feedhold in KFLOP works by linearly ramping down the "rate of time".
> > > > > > >
> > > > > > > To determine the time to stop all the axes currently in motion are examined for their current speed. Most likely in your case only Z is moving. The time to stop is computed based on your current speed, and the acceleration and Jerk settings you have programmed in KFLOP using the formula below:
> > > > > > >
> > > > > > > // include jerk time as cushion because we won't be limiting jerkDo you have your Acceleration and Jerk settings in KFLOP set to optimal values? Assuming you do you might be able to stop from the slow probing speed at a higher acceleration than what you could from all (higher) speeds. So you could temporarily set the Z axis Acceleration and Jerk to much higher values and reset them back after the probe. Of course if you attempt to stop too fast you may lose steps.
> > > > > > >
> > > > > > > Let me know how much of this makes sense.
> > > > > > > Regards
> > > > > > > TK
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > From: inbilla <inbilla@>
> > > > > > > To: mailto:DynoMotion%40yahoogroups.com
> > > > > > > Sent: Saturday, October 20, 2012 1:23 AM
> > > > > > > Subject: [DynoMotion] Probing with Mach3
> > > > > > >
> > > > > > >
> > > > > > > Hi There,
> > > > > > >
> > > > > > > I'm trying to setup a basic probe on my machine at the moment.
> > > > > > > The probe is connected to pin 5, active low.
> > > > > > >
> > > > > > > I'm trying to probe within Mach3 and have installed the NotifyProbeMach3.c program as shown in the setup documentation. I have set the pin to 5, and the active state to 0.
> > > > > > >
> > > > > > > The probe overall appears to work, mach will begin a movement and then stop shortly after I touch the probe.
> > > > > > >
> > > > > > > My problem lies with the "shortly after". I need the machine to pretty much stop as soon as the probe is activated, at the moment it will continue driving into my workpiece for a short distance.
> > > > > > >
> > > > > > > How can I get this to happen? obviously without losing steps..
> > > > > > >
> > > > > > > I'm trying to Mill a PCB and am probing the surface before doing so.
> > > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > Josh
> > > > > > >
> > > > > > >
> > > > > > > time = (vel / ch->Accel) + sqrtf(8.0f * vel/ch->Jerk);
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
>
Group: DynoMotion Message: 5983 From: frank_19_88 Date: 11/8/2012
Subject: Re: Probing with Mach3
Hi TK and Josh,

Thank you for the update,

I am going to use it tomorrow.

With kind regards,

Frank


--- In DynoMotion@yahoogroups.com, "inbilla" <inbilla@...> wrote:
>
> Hi Tom,
>
> I've just downloaded it and given it a shot, it certainly seems to be working in program coordinates now which is fantastic! Thank you very much!
>
> Now I can go ahead and tune for accuracy and get milling some test PCB's!
>
> Much appreciated!
>
> Josh
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Josh,
> >  
> > Interesting point.  Yes the change was internal to the Plugin so no change to the NotifyProbe.c should be required.
> >  
> > Regards
> > TK
> >
> >
> > ________________________________
> > From: inbilla <inbilla@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Monday, October 22, 2012 5:31 PM
> > Subject: [DynoMotion] Re: Probing with Mach3
> >
> >  
> > Thanks Tom,
> >
> > I hope not too,
> > I'll check this out in about 9 hours.
> >
> > If the relevant variables were available to the KFlop as UserData then
> > I imagine anyone wishing to have the old behavior could simply use the old notify.c, and anyone needing program coords could use a new notify.c...
> >
> > Speaking of which,
> >
> > I assume I don't have to modify the existing notifyProbe.c for this plugin? it's all done internally i assume?
> >
> > Thanks again, I'll let you know how it goes
> >
> > Josh
> >
> > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Josh,
> > >  
> > > Here is a version where the Mach3 Plugin should return GCode Coordinates rather than Machine Coordinates.  I hope this doesn't break other Users' code.
> > >  
> > > http://dynomotion.com/Software/KMotion430e.exe
> > >  
> > > Please let us know if it works for you.
> > >  
> > > Regards
> > > TK
> > >
> > >
> > >
> > > ________________________________
> > > From: inbilla <inbilla@>
> > > To: mailto:DynoMotion%40yahoogroups.com
> > > Sent: Monday, October 22, 2012 12:54 AM
> > > Subject: [DynoMotion] Re: Probing with Mach3
> > >
> > >  
> > > Hi Tom,
> > >
> > > Ok then, thanks, I'll probably wait for the update then if it'll be relatively soon :)
> > >
> > > I honestly don't think a 5220 workaround will work at this point as it's my understanding that the G31 code in Mach3 ignores offsets, and the generated PCB milling gcode relies upon the G31 surface profiling to make sure it only takes a certain amount off the surface of the piece.
> > >
> > > Let me know when you have something, and I'm more than happy to test alpha/beta code.
> > >
> > > Thanks Tom, I appreciate it.
> > >
> > > Josh
> > >
> > > --- In mailto:DynoMotion%40yahoogroups.com, TK <tk@> wrote:
> > > >
> > > > Hi Josh,
> > > >
> > > > We are trying to add that to the Plugin. Hope to have something soon. A work around might be to add in the work offset (variable #5220) in the GCode.
> > > >
> > > > Regards
> > > > TK
> > > >
> > > > On Oct 21, 2012, at 9:11 PM, "inbilla" <inbilla@> wrote:
> > > >
> > > > > So if the returned results are in machine coords. I would need to do something like this:
> > > > >
> > > > > originalProgramCoords = getCurrentProgramCoords(zAxis)
> > > > > originalMachineCoords = getCurrentDest(zAxis)
> > > > >
> > > > > while(probeState != Active)
> > > > > {
> > > > > waitForNextTimeSlice()
> > > > > }
> > > > >
> > > > > newMachineCoords = getCurrentDest(zAxis)
> > > > >
> > > > > #2002 = originalProgramCoords + (newMachineCoords - originalMachineCoords )
> > > > >
> > > > > But from the KFLOP, I don't believe I have any way of accessing the current program coords, unless the KFlop plugin makes those values available to the KFlop in some way as user data?
> > > > >
> > > > > Is the only way to resolve this to modify the Mach3 KFlop plugin?
> > > > >
> > > > > Josh
> > > > >
> > > > > --- In mailto:DynoMotion%40yahoogroups.com, "inbilla" <inbilla@> wrote:
> > > > > >
> > > > > > Ok, so this is what I've got now:
> > > > > >
> > > > > > double *d = (double *)&persist.UserData[MACH3_PROBE_RESULTS_VAR];
> > > > > > int flag=1;
> > > > > >
> > > > > > // Record the previous values of accel/jerk for the Z axis
> > > > > > double zAccel = ch2->Accel;
> > > > > > double zJerk = ch2->Jerk;
> > > > > >
> > > > > > ch2->Accel = zAccel * 4;
> > > > > > ch2->Jerk = zJerk * 4;
> > > > > >
> > > > > > 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();
> > > > > >
> > > > > > // Reset the accel/jerk
> > > > > > ch2->Accel = zAccel;
> > > > > > ch2->Jerk = zJerk;
> > > > > >
> > > > > > If I use a feedrate of 30, then I've found I seem to get rather reliable results, so I'm fairly happy with that for now.
> > > > > > The trouble I'm having now is that the reported position of the G31 command is in machine coords, which apparently for mach2 is fine,
> > > > > > but mach3 expects things to be returned in program coords. Any idea how I could achieve that?
> > > > > >
> > > > > > Thanks Tom
> > > > > >
> > > > > > Josh
> > > > > >
> > > > > > --- In mailto:DynoMotion%40yahoogroups.com, "inbilla" <inbilla@> wrote:
> > > > > > >
> > > > > > > Ok,
> > > > > > >
> > > > > > > So to do that, I'd record the current value of acceleration and jerk using the same syntax as the init.c file? Then set them to a new value in the notifyprobemach3.c file? What part of that file runs at beginning of probing? I assume I would reset the value straight after the stopcoordinatedmotion call?
> > > > > > >
> > > > > > > To determine if I'm losing steps, I suppose probing the same spot over and over to see if the returned value drifts?
> > > > > > >
> > > > > > > Thanks Tom!
> > > > > > >
> > > > > > > Josh
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > > > >
> > > > > > > > Hi Josh,
> > > > > > > >
> > > > > > > > When the probe is detected KFLOP does an immediate hardware feedhold. Hardware feedhold in KFLOP works by linearly ramping down the "rate of time".
> > > > > > > >
> > > > > > > > To determine the time to stop all the axes currently in motion are examined for their current speed. Most likely in your case only Z is moving. The time to stop is computed based on your current speed, and the acceleration and Jerk settings you have programmed in KFLOP using the formula below:
> > > > > > > >
> > > > > > > > // include jerk time as cushion because we won't be limiting jerkDo you have your Acceleration and Jerk settings in KFLOP set to optimal values? Assuming you do you might be able to stop from the slow probing speed at a higher acceleration than what you could from all (higher) speeds. So you could temporarily set the Z axis Acceleration and Jerk to much higher values and reset them back after the probe. Of course if you attempt to stop too fast you may lose steps.
> > > > > > > >
> > > > > > > > Let me know how much of this makes sense.
> > > > > > > > Regards
> > > > > > > > TK
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > From: inbilla <inbilla@>
> > > > > > > > To: mailto:DynoMotion%40yahoogroups.com
> > > > > > > > Sent: Saturday, October 20, 2012 1:23 AM
> > > > > > > > Subject: [DynoMotion] Probing with Mach3
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi There,
> > > > > > > >
> > > > > > > > I'm trying to setup a basic probe on my machine at the moment.
> > > > > > > > The probe is connected to pin 5, active low.
> > > > > > > >
> > > > > > > > I'm trying to probe within Mach3 and have installed the NotifyProbeMach3.c program as shown in the setup documentation. I have set the pin to 5, and the active state to 0.
> > > > > > > >
> > > > > > > > The probe overall appears to work, mach will begin a movement and then stop shortly after I touch the probe.
> > > > > > > >
> > > > > > > > My problem lies with the "shortly after". I need the machine to pretty much stop as soon as the probe is activated, at the moment it will continue driving into my workpiece for a short distance.
> > > > > > > >
> > > > > > > > How can I get this to happen? obviously without losing steps..
> > > > > > > >
> > > > > > > > I'm trying to Mill a PCB and am probing the surface before doing so.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > >
> > > > > > > > Josh
> > > > > > > >
> > > > > > > >
> > > > > > > > time = (vel / ch->Accel) + sqrtf(8.0f * vel/ch->Jerk);
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>