Position counts to user units?

Moderators: TomKerekes, dynomotion

Moray
Posts: 282
Joined: Thu Apr 26, 2018 10:16 pm

Re: Position counts to user units?

Post by Moray » Sat Sep 29, 2018 9:28 pm

And looking at the CheckResFromKMCNC.c example, and doing a bit tracing through the KMCNC code, I've found what I want is (very obviously!) called CountsPerInch_().

User avatar
TomKerekes
Posts: 2529
Joined: Mon Dec 04, 2017 1:49 am

Re: Position counts to user units?

Post by TomKerekes » Sun Sep 30, 2018 6:51 pm

Hi Moray,
I should of said I was looking to get the information from KMCNC/dotNet, so the PC could do the heavy work, but I couldn't find an obviously named function in the dotNet help file.

And looking at the CheckResFromKMCNC.c example, and doing a bit tracing through the KMCNC code, I've found what I want is (very obviously!) called CountsPerInch_().
I don't think that might be the right approach.

Again the issue is your App is separate from KMotionCNC. KMotionCNC creates some objects (CKMotionDLL, CCoordMotion, CGCodeInterpreter) and reads in its configuration files and configures all the parameters appropriately and uses those objects. If you use .NET to create objects from your App they will be different objects and uninitialized unless you initialize them. So the only .NET commands that would make sense for you to use would be those that talk to KFLOP directly. Otherwise the idea is to send a Windows message from your App to KMotionCNC to please do the requested thing using its objects.
I'm open to ideas on exactly how that occurs, but for now I was thinking of basic 3 linear axis, however I'm trying to write the code so things can be modified relatively easily if the work flow changes.
If you assume 3 linear orthogonal axes the entire approach will need to change to later handle nonlinear kinematics.

KFLOP can request from KMotionCNC its counts per inch settings. And your App can then read them from KFLOP in a round about manner. That's why I suggested that approach. But again I'm hoping that isn't the approach you use. If you request KMotionCNC to do the moves and conversions it should never need to know the resolutions and such.
Reversing the motion would work, however not until I can get the CAD space coordinates from KFlop positions, unless you can think of some way to pause at the exact trigger point, before continuing with the reverse?
Good point. I hadn't considered this or can think of an easy way to do this.

I'm thinking it might be simpler to bite the bullet and add in the "automation" functionality into KMotionCNC to do what you need to do. So the approach would be:

#1 Rapid to start of Probe position - This functionality exists with DoMove where your App tells KMotionCNC to do it
#2 Your App configures KFLOP directly to capture actuator positions on probe trigger, optionally reverse slow then Feedhold, then Halt (functionality for this exists)
#3 Feed to Position at specified Feed Rate - need to add DoFeed command to KMotionCNC that doesn't block and wait to finish
#4 Your App polls KFLOP directly, determines success or failure, uploads captured actuator positions
#5 Your App requests KMotionCNC to convert Actuator to CAD - need to add DoConvert functionality

Thoughts?
Regards,

Tom Kerekes
Dynomotion, Inc.

Moray
Posts: 282
Joined: Thu Apr 26, 2018 10:16 pm

Re: Position counts to user units?

Post by Moray » Sun Sep 30, 2018 8:50 pm

All understood.

Adding the functionality sounds best, but for now I can just do two separate moves after the stop at the trigger point. One to the point the probe should be cleared ignoring any probe input, then another to the start of the next probing point with probe monitoring. It may mean an additional pause, but I don't see any major problem with that during development.

It'll let me get on with the code that'll do something with the trigger points, and I can modify the probing code later, as that's all in it's own separate functions.

Moray
Posts: 282
Joined: Thu Apr 26, 2018 10:16 pm

Re: Position counts to user units?

Post by Moray » Tue Oct 02, 2018 9:45 pm

Tom,
after I issue an MDI via the KFlop, what's the best way to test for it being finished in the KFlop?

Is JOB_ACTIVE set for MDI motion?

User avatar
TomKerekes
Posts: 2529
Joined: Mon Dec 04, 2017 1:49 am

Re: Position counts to user units?

Post by TomKerekes » Wed Oct 03, 2018 5:54 pm

Hi Moray,

The MDI() call blocks and only returns when the PC has finished the command and sent the completed status.

JOB_STATUS might be tricky as there may be delays or in some cases may never get set at all for a very quick operation.

CheckDoneBuf() might also work if you verify motion has already started by it returning not done first.
Regards,

Tom Kerekes
Dynomotion, Inc.

Moray
Posts: 282
Joined: Thu Apr 26, 2018 10:16 pm

Re: Position counts to user units?

Post by Moray » Thu Oct 04, 2018 4:47 pm

I'll write some code and see what happens with those suggestions.

I'm currently calling the MDI move using the non-blocking DoPCIntNoWait, and it appears to be working how I'd like it.

What I'm looking for is someway to know if an MDI move has completed, and set a flag. I know I could acheive the same by monitoring the DROs in the PC, but I'm hoping doing it directly in the KFlop would minimise delays. This is so I can detect when a probing move has failed to trigger (i.e. has moved the distance requested without touching anything), or clearance moves have completed.

Moray
Posts: 282
Joined: Thu Apr 26, 2018 10:16 pm

Re: Position counts to user units?

Post by Moray » Thu Oct 04, 2018 6:28 pm

Testing done, and it appears CheckDoneBuf() is quicker than JOB_ACTIVE.

Using this thrown together code to do the testing -

Code: Select all

int last_cd;
int last_ja;
main()
{
	for(;;)
	{
		CheckMove();
		if(CheckDoneBuf() != last_cd)
		{
			last_cd = CheckDoneBuf();
			if(CheckDoneBuf()) printf("CheckDoneBuf true:%f\n", Time_sec());
			else printf("CheckDoneBuf false:%f\n", Time_sec());
		}
		if(JOB_ACTIVE != last_ja)
		{
			last_ja = JOB_ACTIVE;
			if(JOB_ACTIVE) printf("JOB_ACTIVE true:%f\n", Time_sec());
			else printf("JOB_ACTIVE false:%f\n", Time_sec());
		}
	}
}
We get this result -
MDI sent,751.652132
CheckDoneBuf false:751.755010
JOB_ACTIVE true:751.796588
CheckDoneBuf true:754.763341
JOB_ACTIVE false:754.857842

User avatar
TomKerekes
Posts: 2529
Joined: Mon Dec 04, 2017 1:49 am

Re: Position counts to user units?

Post by TomKerekes » Thu Oct 04, 2018 6:38 pm

Nice test!
Regards,

Tom Kerekes
Dynomotion, Inc.

Moray
Posts: 282
Joined: Thu Apr 26, 2018 10:16 pm

Re: Position counts to user units?

Post by Moray » Sat Oct 06, 2018 9:28 pm

So I've spent the past couple evenings working out an intermittent glitch, whereby the final return MDI call failed to produce any motion.

After outputting what was happening in the KFlop, I found that CheckDoneBuf() was never going false after the final MDI call, and I thought motion was stalling. Turns out the final MDI call was never reaching KMotionCNC, and inserting a 0.1sec delay before the KFlop sends the MDI has fixed the issue. I'm guessing it's because I'm not using the blocking call, and KMCNC is still essentially blocked when I'm sending the next MDI, so it gets ignored.

I know that shouldn't be a problem if we get the added functionality into KMCNC to avoid the KFlop route.
So I'm now at the point where by I can reliably do a probing move, get the trigger point, then return to the original start point.

However during that, I did discover another step that will need dealt with. KMCNC returns the machine position DROs, not the current (offset) DROs, which I only realised after going through my code to try and figure out why my probing moves were going at an angle.
I can manage without the offsets just now, but getting the offsets is something that will need added at some point.

User avatar
TomKerekes
Posts: 2529
Joined: Mon Dec 04, 2017 1:49 am

Re: Position counts to user units?

Post by TomKerekes » Sun Oct 07, 2018 4:49 pm

Hi Moray,
After outputting what was happening in the KFlop, I found that CheckDoneBuf() was never going false after the final MDI call, and I thought motion was stalling. Turns out the final MDI call was never reaching KMotionCNC, and inserting a 0.1sec delay before the KFlop sends the MDI has fixed the issue. I'm guessing it's because I'm not using the blocking call, and KMCNC is still essentially blocked when I'm sending the next MDI, so it gets ignored.
Instead of delaying you might wait for the previous command to complete instead.

I did discover another step that will need dealt with. KMCNC returns the machine position DROs, not the current (offset) DROs, which I only realised after going through my code to try and figure out why my probing moves were going at an angle.
I can manage without the offsets just now, but getting the offsets is something that will need added at some point.
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.
Regards,

Tom Kerekes
Dynomotion, Inc.

Post Reply