Position counts to user units?

[Moray]

Hi Moray,
Instead of delaying you might wait for the previous command to complete instead.

I was already waiting for CheckDoneBuf() to go true, to signify the end of the previous command, but I'm guessing there is some overlap between the buffer emptying, and KMCNC becoming ready for the next MDI?
If I was to improve this, I guess it would be a case of checking for the PC_COMM_PERSIST persist to go greater than 0 before sending the next command?
During the DoPC command, at what point does PC_COMM_PERSIST get set to 0?
The reason I ask, is with also needing to get/set offsets, I should really add some kind of check to ensure KMCNC is not currently handling some other command, before sending another command.

Yes I expected that more commands would be needed. The DROs should basically be:

Machine Coordinates = DRO + Fixture Offset + Global Offset + Tool Offset

or

DRO = Machine Coordinates - Fixture Offset - Global Offset - Tool Offset


I would think you would need to know all the offsets instead of the DRO value.

Yes, I think I would need to ultimately know all of the offsets.
My initial thoughts are I would like to be able to select the offset in my app, and possibly show what offsets are in effect to get the current DRO displays. I think there would also need to be some level of communication between KMCNC and my app to update if offsets are changed in either during a probe routine.

However, that's a bit away yet.
My current plan is, get basic corner probing working, which needs handling offsets and move planning (this is the current thing that's bouncing around my head, as I want a setup that isn't going to need a major re-work for future probing routines).
Then work on alignment/edge probing, which will involve creating a basic geometric correction file to allow for angular offsets.
Then expand the basic probing routines to include the various other options that might be needed aka bore/spigot/slot/ridge probing.
After that, I'll get onto probe radius/offset correction.

[TomKerekes]

Hi Moray,

I was already waiting for CheckDoneBuf() to go true, to signify the end of the previous command, but I'm guessing there is some overlap between the buffer emptying, and KMCNC becoming ready for the next MDI?
If I was to improve this, I guess it would be a case of checking for the PC_COMM_PERSIST persist to go greater than 0 before sending the next command?
During the DoPC command, at what point does PC_COMM_PERSIST get set to 0?
The reason I ask, is with also needing to get/set offsets, I should really add some kind of check to ensure KMCNC is not currently handling some other command, before sending another command.

The mechanism works like this:

1. PC_COMM_PERSIST should be zero indicating idle mode
2. KFLOP sets all parameters for a Command
3. KFLOP sets PC_COMM_PERSIST with a command (value > 0)
4. PC polls PC_COMM_PERSIST as it reads Status ~every 100ms and detects the command>0
5. PC executes the command
6. if the command succeeds PC sets PC_COMM_PERSIST to zero, on failure a negative error code is set

I think in your senario:

1. motion finishes
2. CheckDoneBuf() goes true and detect this immediately in KFLOP
3. you then set a new command
4. the PC now detects CheckDoneBuf() is true
5. PC then sets "success" by clearing the command (your new command is lost)

HTH

[Moray]

That makes sense, and explains why the error only occured after the clearance move, as after a succesful probe trigger move, there is already a 0.1sec delay before the ClearStopImmediately() call, which was needed to stop KMCNC showing a buffer underflow error.

So all I really need to add, is to check PC_COMM_PERSIST has been set to less than 1 before issuing the next command.

[TomKerekes]

So all I really need to add, is to check PC_COMM_PERSIST has been set to less than 1 before issuing the next command

Correct

[Moray]

Just a quick update, but after various reworks of code, I can now build a list of moves, reliably carry out the moves, and store the resulting trigger points.
So the basics are finally working, but are in need of some refinement.

[Moray]

Tom, one thing I'm wanting to implement, is double touch (fast initial probe, then back off slightly, then do a slow probe).

Obviously if I approach this by repeating my current approach, each probing move is going to take a noticeable amount of time due to the various delays in transferring relevant data.
I'm aware you can reverse motion. How quick can this happen?

Would it be fast enough to replace using StopCoordMotion, or would it involve a delay in getting KMCNC to reverse the motion?

If it was instantaneous in the KFlop, then it would allow me to reverse a set time after the initial probe, then go forward at a reduced speed and probe as normal.

[TomKerekes]

Tom, one thing I'm wanting to implement, is double touch (fast initial probe, then back off slightly, then do a slow probe).

Obviously if I approach this by repeating my current approach, each probing move is going to take a noticeable amount of time due to the various delays in transferring relevant data.
I'm aware you can reverse motion. How quick can this happen?

Would it be fast enough to replace using StopCoordMotion, or would it involve a delay in getting KMCNC to reverse the motion?

If it was instantaneous in the KFlop, then it would allow me to reverse a set time after the initial probe, then go forward at a reduced speed and probe as normal.

Sorry just noticed this was never answered.

Reversing within KFLOP using FRO is instantaneous. Or rather it begins deceleration and direction reversal (along the path) instantaneously.

This function can be used to change the FRO immediately to some positive, negative, or zero value. StopCoordMotion essentially sets the desired value to zero. The rate it changes (Time it takes) is based on an analysis of all the axes in the coordinate system and the worst case time for all the axes to stop from their maximum speed. Which might not be optimal if you know you are moving slow. The second function allows you to specify a Time.

void SetFROTemp(float FRO); // Temporarily change from current to the specified FRO using a nominal rate, override FeedHold, don't save as LastFRO

void SetFROwRateTemp(float FRO, float DecelTime); // Temporarily change from current to the specified FRO using a rate based on caller specified time, override FeedHold, don't save as LastFRO

[Moray]

Sorry just noticed this was never answered.

Reversing within KFLOP using FRO is instantaneous. Or rather it begins deceleration and direction reversal (along the path) instantaneously.

This function can be used to change the FRO immediately to some positive, negative, or zero value. StopCoordMotion essentially sets the desired value to zero. The rate it changes (Time it takes) is based on an analysis of all the axes in the coordinate system and the worst case time for all the axes to stop from their maximum speed. Which might not be optimal if you know you are moving slow. The second function allows you to specify a Time.

void SetFROTemp(float FRO); // Temporarily change from current to the specified FRO using a nominal rate, override FeedHold, don't save as LastFRO

void SetFROwRateTemp(float FRO, float DecelTime); // Temporarily change from current to the specified FRO using a rate based on caller specified time, override FeedHold, don't save as LastFRO

That should work for me.
The plan is approach as normal, probe triggers, reverse FRO gets called, motion is reversed for a calculated time (I suspect this may need a bit additional calculation to reliably clear the trigger event the set distance to allow for acceleration/deceleration) to clear the probe trigger the set distance, FRO is set forward again at the lower feedrate, then the probe trigger is handled as previously with the trigger point stored, stopcoordmotion() called, followed by a move back to the trigger point, before my program reads the DROs from KMCNC.

[TomKerekes]

Hi Moray,

motion is reversed for a calculated time (I suspect this may need a bit additional calculation to reliably clear the trigger event the set distance to allow for acceleration/deceleration)

Any reason not to reverse until the probe active goes away?

[Moray]

Hi Moray,

motion is reversed for a calculated time (I suspect this may need a bit additional calculation to reliably clear the trigger event the set distance to allow for acceleration/deceleration)

Any reason not to reverse until the probe active goes away?

That could be an option, but personally I'd like the option to ensure the clearance distance is far enough away that the probing moves are done at constant speed, and not while still accelerating.

Including both options shouldn't be that much of a problem.