Probing routines

[Moray]

I need to add some probing routines to my milling machine, both for run of the mill offset setting I.e. finding centres/corners, but also with a longer term outlook to more advance probing I.e. perimeter probing/surface probing to create DXF/point files.

Would I be right in thinking this could be done solely via custom screens, and suitable C programs?

[TomKerekes]

Hi Moray,

I don't see why not. Perhaps have a "Probing" Screen that brings up graphical images of available probing operations and buttons to invoke corresponding C Programs to perform them.

[Moray]

That's what I was thinking, but I'm not 100% sure on how to handle everything.

This is what I currently use on my little digitizer - http://www.craftycnc.com/probe-it-wizard-mach3/
On that I primarily use perimeter probing and export to DXF, which I'd really like to do without the need to rely on Mach 3, but that's more something for in the future.

For now, I'd like to have something similar to the XY probing, with options to make the routines more automated I.e. to find a centre, select internal/external, select start side/move, enter approximate distance to opposite side, select how to move to the opposite side (i.e. up and over, or around the side with appropriate safe heights/distances), jog to the start point, hit a button, then ignore until the work offsets are updated to the centre point.
Main thing I'm unsure of, and what i should really of asked in my first post, is this better done in custom screens/C programs, or in a standalone program like your Measure Fiducials?

[Moray]

OK, I've been thinking about this some more trying to build up a general overview in my head, and have been looking at the available probing C programs.

If I do everything via C programs/Custom Screen, it relies on storing the various probe trigger points within the KFlop, then updating offsets in KMotionCNC, which I'm not entirely sure how to do, but I'm sure it's possible.

If I to do it via a standalone program (I've been looking at the measure fiducials source code to see how it works), I'm assuming I need to load a suitable probe program via C, send the required probing move using the C Program/M-code, but then how do I get the trigger point details back into the PC to be useable by the program?
My plan would be to operate in a similar way to the Measure Fiducial's program, whereby KMotionCNC has to be running first to take care of machine initialisation etc, then once the required probing/offset calculations have been done, transfer the information to KMotionCNC and adjust the offset/DROs.

[TomKerekes]

Hi Moray,

If I to do it via a standalone program (I've been looking at the measure fiducials source code to see how it works), I'm assuming I need to load a suitable probe program via C, send the required probing move using the C Program/M-code, but then how do I get the trigger point details back into the PC to be useable by the program?

Good question. This gets complicated when kinematics and Geocorrection is involved as the motor/actuator positions are not directly related to CAD positions.

The simplest method may be to have KFLOP move back to the trigger position (or some fixed distance/known distance away from it) then your Windows Program can request the CAD position from KMotionCNC using the HostComm.GetPositions method.

Otherwise you can always easily read positions or memory from KFLOP via the KMotion_dotNet interface.

Regards

[Moray]

I didn't think it would be too straightforward!

Having just thought about the process more, would it be possible to have a continually running C Program, that monitors for any probe trigger, and processes the trigger?
What I'm thinking is it would save continually loading C Programs, and the probe should be protected during all motion.

That would involve the C program monitoring/storing current motion direction, then on any trigger, stores the trigger point and last motion direction, stops motion, and sets a Triggered flag.

The PC program can then issue motion commands (can this be done via dotnet, with KMotionCNC also running?), and monitor for the Triggered flag or motion to complete. Then to move back from the trigger point, it issues a move in the opposite direction, which the C program should automatically allow, and clear the Triggered flag once the probe has been de-triggered. Although I suspect an additional flag may be needed so we don't end up with a race condition with everything waiting for the Triggered flag to unset/set. I'll think about that, but does this sound feasible?

I'm guessing on a trigger/halted move, the motion buffer would have to be flushed before a reverse move would work?

I'll have a read of the dotnet documentation.
I'll hopefully get my little KFlop/KStep closed loop CMM dragged in to the house this weekend, so I can work on this in comfort with my good laptop.

[TomKerekes]

Hi Moray,

That would involve the C program monitoring/storing current motion direction, then on any trigger, stores the trigger point and last motion direction, stops motion, and sets a Triggered flag.

That should be possible by:

#1 triggering a Feed Hold - StopCoordinatedMotion() and save position
#2 monitor stopping state until stopped - CS0_StoppingState >=3
#3 canceling remaining motion ClearStopImmediately()

This should also allow the probe motion to be commanded as a coordinated motion in CAD space in any direction and with corrections for Kinematics and Geocorrection (as opposed to an independent motor/actuator motion).

[Moray]

Excellent. I see a plan coming together.

I just need to get my CMM into the house, and running directly on KMotionCNC, then I can get started.