Kogna Soft Limits & Feed Hold

[jtremel]

Thanks Tom!

I re-ran the single stepping tests with KmotionCNC and am summarizing for my clarity.

With S code action set "Execute Prog" and specifying VAR as #113
- persist #113 gets updated on all G-code S parameters (regardless of G96/G97 state)
- if in G96 mode, persist #113 value is correctly converted to inches/second
- if in G97 mode, persist #113 value contains the correct RPM value

With S code action set "None" or "User Call Back"
- persist #113 does not get updated in G97 mode
- persist #113 is updated in G96, but the value is (in general) WRONG. It is a conversion of the previous S parameter, not the one on the G96 Block
- the above might not be obvious on repeated runs of a G code program that doesn't change S parameters or switch between G96/G97

I know how to modify my program to work correctly, so I am good here.

That being said, it sounds like you intend for all the CSS persists to get updated regardless of the callback action, so it seems there is a bug that could be ironed out in the setting of persists #113 when the S callback is set to "User Call Back" or "None". Not a big deal to me.

the GCode Current Block 'D' flag/value are not exported to .NET. Only P, Q, and R are. If you would like us to add this we will.

I think it would be a nice addition on the next update. Not a showstopper since persist 114 has the correct value.

Here are a couple of more .NET things I have noticed over the years that you might consider for future releases:

Interpreter Tool, Setup and Vars file getters
Trying to read the Interpreter's current ToolFile, VarsFile, or SetupFile will crash a .NET application. I display these on my GUI (and so maintain my own local variables when I set them). It would be nice to be able to interrogate/verify from the interpreter.

Here is a quick code snippet that will reproduce. Also, if debugging, hovering the mouse over interp will cause the error when VS does reflection on the interpreter object.

Code: Select all

KM_Interpreter interp = kflop.Controller.CoordMotion.Interpreter;
string test = interp.ToolFile;

5 axis TCP status
I made a 5axis machine a while back (4.35B). The current state of TCP/RTCP compensation is not exported to .NET.
To work-around, I exposed it and recompiled the libraries. In-general I would like to not have to maintain modified versions of the Dynomotion dll libraries (prevents me from upgrading the machine to newer releases when they are avialable).

5 axis Trajectory Planning - switch between G49 and G43.4
The details here are far from my memory now, but I needed to add a custom Mcode and callback (I used M117) when switching between the compensation modes. The callback code does nothing but immediately 'return 0'. This forced some synchronization between the look-ahead planner and the G49/G43.4 state. Without it, the motion planner would not honor the correct/switched compensation mode and would continue to generate motion with incorrect kinematics/offsets.

I understand that is not much to go-on, but I can did up some old notes if your interested.

[jtremel]

Good Morning Tom,

Switching topics back to the Feed-Hold issue...

A workaround would be to set the last motion type before resuming from Feed Hold.

Question #1
Did you mean to say before "STARTING" the Feed Hold?

I made the quick program below to understand this issue.

• If I comment-out the chan[0].LastMotionType call before StopCoordinatedMotion() the motion does not resume correctly.

• the chan[0].LastMotionType before ResumeCoordinatedMotion() seems to have no effect if its commented-out or not.

Question #2
When the motion does resume, it does so at the 'default_velocity', not the velocity that it was moving at before the Feed Hold. Is that the intended behavior?

Question #3
I recently upgraded one of my CNC machines to version 5.1.0 (KFLOP), but have not tested the feed hold on that yet. What behavior should I expect on a feed hold while interpreting G-code.

Code: Select all

#include "KMotionDef.h"

main()
{
	double cntsPerMM = 320;						// axis units = 320 counts per mm
	double default_velocity = 10 * cntsPerMM; 	// default chan vel = 10 mm/s
	double move_velocity = 40 * cntsPerMM;	  	// indep move velocity = 40 mm/s
	double move_dist = 100 * cntsPerMM;			// test move distance
	
	ch0->Vel = default_velocity;				
	MoveAtVel(0, move_dist, move_velocity);   	// issue move to 100mm at 40mm/s
	while(ch0->Dest<(0.5*move_dist));			// wait till we are half-way
	
	// this command is a work-around for a Trip State Planner bug introduced in version5?
	chan[0].LastMotionType = LAST_MOTION_MOVE; 
	StopCoordinatedMotion();					// issue feed hold
	
	Delay_sec(3);
	//chan[0].LastMotionType = LAST_MOTION_MOVE;
	ResumeCoordinatedMotion();					// resume from feed hold
	
	while(!CheckDone(0));
	MoveAtVel(0,0,move_velocity);   			// move back to home at 40mm/s
}

[TomKerekes]

Hi Jim,

Thanks for the details.

With S code action set "Execute Prog" and specifying VAR as #113
- persist #113 gets updated on all G-code S parameters (regardless of G96/G97 state)
- if in G96 mode, persist #113 value is correctly converted to inches/second
- if in G97 mode, persist #113 value contains the correct RPM value

good

With S code action set "None" or "User Call Back"
- persist #113 does not get updated in G97 mode
- persist #113 is updated in G96, but the value is (in general) WRONG. It is a conversion of the previous S parameter, not the one on the G96 Block
- the above might not be obvious on repeated runs of a G code program that doesn't change S parameters or switch between G96/G97

I know how to modify my program to work correctly, so I am good here.

This was a bug caused by somewhat of a catch-22. For the S Action to work correctly it needs to know the G96/G97 mode. But for the G97 to work correctly it needs to know the new S value. The following change was made:

Normally a G96 (CSS) line such as this G96 M3 D2500 S500 would be executed in the order of G96, then S, then M3. In this case the G96 could execute with a previous S value, setting an improper value in the Controller’s Persist Variables along with the other CSS parameters. This is not normally an issue as when the S is executed the Persist Variable will be updated to the correct value. However, if the S Action is not configured as a C Program in KFLOP, such as Action ‘None’ or ‘User Callback’ the Persist Value will not be updated to the correct value. The G96 operation now looks ahead to see if a new S value is specified and if so, uses the updated value. The S Action is still executed after the G96.

the GCode Current Block 'D' flag/value are not exported to .NET. Only P, Q, and R are. If you would like us to add this we will.
I think it would be a nice addition on the next update. Not a showstopper since persist 114 has the correct value.

This will be exposed in the next Version

Interpreter Tool, Setup and Vars file getters
Trying to read the Interpreter's current ToolFile, VarsFile, or SetupFile will crash a .NET application. I display these on my GUI (and so maintain my own local variables when I set them). It would be nice to be able to interrogate/verify from the interpreter.

Here is a quick code snippet that will reproduce. Also, if debugging, hovering the mouse over interp will cause the error when VS does reflection on the interpreter object.
CODE: SELECT ALL

KM_Interpreter interp = kflop.Controller.CoordMotion.Interpreter;
string test = interp.ToolFile;

This should be corrected in the next Version. It had to do with the Marshaling of a String from unmanaged C++ to managed C# as a returned value.

5 axis TCP status
I made a 5axis machine a while back (4.35B). The current state of TCP/RTCP compensation is not exported to .NET.
To work-around, I exposed it and recompiled the libraries. In-general I would like to not have to maintain modified versions of the Dynomotion dll libraries (prevents me from upgrading the machine to newer releases when they are avialable).

TCP_Active from KM_MotionParams will be exposed in .NET

5 axis Trajectory Planning - switch between G49 and G43.4
The details here are far from my memory now, but I needed to add a custom Mcode and callback (I used M117) when switching between the compensation modes. The callback code does nothing but immediately 'return 0'. This forced some synchronization between the look-ahead planner and the G49/G43.4 state. Without it, the motion planner would not honor the correct/switched compensation mode and would continue to generate motion with incorrect kinematics/offsets.

I belive this was fixed in Version 4.35e

[jtremel]

Thanks Again Tom!

I appreciate all your replies and look forward to the .NET additions in the next release.

Your description (and the behavior) here makes perfect sense:

Normally a G96 (CSS) line such as this G96 M3 D2500 S500 would be executed in the order of G96, then S, then M3. In this case the G96 could execute with a previous S value, setting an improper value in the Controller’s Persist Variables along with the other CSS parameters. This is not normally an issue as when the S is executed the Persist Variable will be updated to the correct value. However, if the S Action is not configured as a C Program in KFLOP, such as Action ‘None’ or ‘User Callback’ the Persist Value will not be updated to the correct value. The G96 operation now looks ahead to see if a new S value is specified and if so, uses the updated value. The S Action is still executed after the G96.

[TomKerekes]

Question #1
Did you mean to say before "STARTING" the Feed Hold?

I made the quick program below to understand this issue.
If I comment-out the chan[0].LastMotionType call before StopCoordinatedMotion() the motion does not resume correctly.
the chan[0].LastMotionType before ResumeCoordinatedMotion() seems to have no effect if its commented-out or not.

I was confused. The workaround issued just before resuming would be:

Code: Select all

#include "KMotionDef.h"

typedef struct
{
	double Dest;
	int WasMoving;
	int LastMotionType;				// Type of last move - used in Immediate Stop/Resume
} STOP_CONDITION;

extern STOP_CONDITION StopConditions[8];

void main()
{
	StopConditions[0].LastMotionType = LAST_MOTION_MOVE;
	StopConditions[1].LastMotionType = LAST_MOTION_MOVE;
}

Question #2
When the motion does resume, it does so at the 'default_velocity', not the velocity that it was moving at before the Feed Hold. Is that the intended behavior?

Yes. If resuming at an altered velocity would help you we could implement it.

Question #3
I recently upgraded one of my CNC machines to version 5.1.0 (KFLOP), but have not tested the feed hold on that yet. What behavior should I expect on a feed hold while interpreting G-code.

There shouldn't be any difference. Interpreting GCode involves coordinated motion not Independent Motions.

The bug with resuming Independent Motions was introduced in Version 4.35c when the advanced Independent Motion Trip State Planner was added, which is common to both KFLOP and Kogna.