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 » Tue Sep 25, 2018 10:44 am

After installing what must be most of the options for VS2017, I have success!

So do you think it would be possible to add G-code/MDI functionality?

My thinking is, if it can be added, a lot of what I need to do could be done via G-code (i.e. set feed rate, do moves, select offset), otherwise I think I can do most of what I need via juggling KFlop parameters, but it seems a bit wasteful sending an instruction to KFlop via a C program, for it to then command a change in KMotionCNC, when I could potentially do it directly.

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

Re: Position counts to user units?

Post by Moray » Tue Sep 25, 2018 11:31 am

And maybe not.

I thought it did work the first time, as the axis did retract, but at high speed. So I dropped the channel velocity and it's still blocking. I think the first time, due to the speed, it managed to complete the DoMove, before the C Program stopped motin and retracting.

Having just been looking at the KFloptoKMotionCNC example, I see G-codes/MDI can be sent from KFlop to KMotionCNC, so I'm thinking that may be the path of least resistance for now. Push values out to User Vars, for moves, then use virtual bits to signal a C Program to do something with the data.

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

Re: Position counts to user units?

Post by TomKerekes » Tue Sep 25, 2018 2:44 pm

Hi Moray,

Yeah I worried about that. The DoMove code still blocks until until all the motion has been sent to KFLOP. That would be related to the Speed, Distance, and Buffering time. So for example say to move the distance at Speed would take 5 seconds and the Buffering time is 1 second, then KMotionCNC will block for 4 seconds until everything has been sent to KFLOP. If the feedhold occurs within the 4 seconds there can still be a deadlock. A workaround might be to setting the Buffering time to a high value.

The better approach is probably to have KMotionCNC create a worker Thread to do the move and then return immediately.
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 » Tue Sep 25, 2018 5:22 pm

Tom, I was just thinking, if I use the C program route to issue MDI commands, will it still suffer from the same problem?

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

Re: Position counts to user units?

Post by TomKerekes » Wed Sep 26, 2018 2:53 pm

Hi Moray,

I think that may have a somewhat different problem. The MDI command in KFLOP normally waits until the GCode completes before returning. So although KMotionCNC will not be blocked, the communication channel from KFLOP->KMotionCNC will be blocked so it won't be possible to issue the Halt.
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 » Wed Sep 26, 2018 3:46 pm

I'm at work just now, but I did get a chance to try it this morning with a basic C program directly via KMotion, with just enough g-code to issue a G91 G1 X0.5 in a separate thread.
It did block the MDI thread, but the main thread carried out the stop and reverse without any problem.
Switching to the equivalent no wait option (DoPCIntNoWait ?), meant the thread executed the MDI and quit without problem.

The only problem I had inconsistently, which affected both blocking and non-blocking options, was a buffer underflow pop-up error. I'm guessing it's to do with the request to halt KMotionCNC not being received/processed by KMotionCNC, before the buffer is flushed and the move reversed. Adding a 0.1 sec delay before the flush/reverse stopped the error.

At the moment, I'm thinking of moving all the probing functionality to it's own thread, which then does all the interaction between my app, KMotionCNC, and the required probe trigger handling.

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

Re: Position counts to user units?

Post by Moray » Wed Sep 26, 2018 9:42 pm

Now I'm home, I've just added a test button and numericUpDown to my app, that takes the value from the numericUpDown, puts it into a user var, then sets a virtual bit to trigger a move.
I've also edited the C program so it runs continually testing the virtual bit for a probe command request, then reads the user var, builds a string, and MDI's the string to KMotionCNC.
The probing move then takes place, and everything seems to complete successfully.

I also done a bit testing for the buffer underflow error by moving the delay around. Turns out the delay needs to be before the ClearStopImmediately() call.

Now I can hopefully get onto the interesting bit of doing something with probe moves...

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

Re: Position counts to user units?

Post by Moray » Sat Sep 29, 2018 4:41 pm

What is the best way to convert axis distance to units?

The reason I ask, is there a couple times where I'd need the KFlop to know a distance.
First would be if using a double probe (initial fast probe move, followed by a retract then slow probe move for better accuracy), so the KFlop can handle the complete probing cycle with no interaction from the PC.
Second would the clearance move, where the PC would initiate the entire move, but the KFlop handles ensuring the probe clears/detriggers within a set distance, say within 0.5mm movement, which if the probe doesn't de-trigger, the KFlop halts motion and flags a problem to the PC.

I don't think it really matters if the KFlop gets units, or distance sent to it for the required distance, but can I get the units per inch setting for each axis on the PC, so I can calculate the required info?

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

Re: Position counts to user units?

Post by TomKerekes » Sat Sep 29, 2018 7:37 pm

Hi Moray,

Well it gets complicated for systems with nonlinear kinematics or Geocorrections. For example 5 axes CNC systems, robots, etc. In these cases there is no simple linear relationship between axis positions and CAD Space poition or distance. Only the PC has the capability of doing the transformations. I was hoping to do probing in a way that would work for everything.

If you assume the system is linear and orthogonal then you can use the example CheckResFromKMCNC.c to get the linear factors.

So I was thinking not to have KFLOP do all the steps. Instead the PC would be involved. This may cause some extra delays but I would expect them to be minimal on average. (20ms ?)

One thing that came to mind was that instead of simply having KFLOP Feed hold the motion we might have it feed reverse the motion at a slower feed rate until the probe deactivates and optionally further to clear away from the part. Given the programmed feed rate KFLOP could then monitor TimeExecuted to know distance from trip point and so forth. For example given a feedrate of 1mm/sec when TimeExecuted is reversed to 0.5 sec before the point the probe triggered we should be 0.5mm away.

What do you think?
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 Sep 29, 2018 9:14 pm

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.

My aim is the PC does most of the number crunching and move planning, but then the KFlop is directly responsible for handling probe triggers, so any motion halts don't rely on needing the PC to respond.

My general plan is there is extra input values for second probe feedrate and distance. If set to zero, everything moves at the main set feedrate, stops at the probe trigger, reverses to the probe trigger point and stops, ready for the probe point to be read.
If set to a value, then you get a feed at main feedrate, trigger, reverse set distance, feed at second feedrate, trigger, reverse to trigger point, and read the probe point.

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.


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?

Post Reply