Kogna Soft Limits & Feed Hold

[jtremel]

Hi Tom,

I apologize if this should not be in bug reports.... but have run into a couple of issues with Kogna related to soft limits and Feedhold.

#1 Soft Limits
I have a setup with two stepper axis
Axis 0 is using Step/Gen #0 in differential drive mode
Axis 1 is using Step/Gen #1 in differential drive mode
Each Axis has positive and negative soft limits set.

If I jog Axis 0 (ie. Jog0=1000) beyond the limits
- the axis does stop
- I get a console message "Pos Soft Limit FeedHold Axis:0"
- this is the behavior I expect

Now, If I jog Axis 1 (i.e. Jog1=-1000) beyond the soft limit
- the axis DOES NOT stop
- I DO get a console message "Neg Soft Limit FeedHold Axis:1"
- the behavior is similar on a positive limit for Axis 1 (console reports the condition, but motion does not stop)

#2 Feed Hold
While executing an independent move (i.e. Move0=32000)
- If I issue "StopImmediate0" the motion does go into feed hold and stops
- In that state, if I issue "StopImmediate1" the state clears, but motion does not resume.

[TomKerekes]

Hi Jim,

Regarding #1 Soft Limits performs a Feed Hold which stops the Axes defined in the Coordinated Motion System. In your case only axis 0 and 1 should be included. Are they?

Regarding #2 You are correct that is a bug. When the new Trip State Planner was introduced any independent movement large enough to reach constant velocity will not resume properly after a Feed Hold.

What Version are you using? This will be fixed in the next Version. Or we can supply a patch if needed.

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

Code: Select all

#include "KMotionDef.h"

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

[jtremel]

Thanks Tom,

I am still running 5.0.6 on this setup. No need for a specific patch, for now I'll just add in your LastMotionType code. I will upgrade on the next release.

For the soft limit, I didn't realize the axis needed to be defined as part of the Coordinated Motion. In this particular machine I don't have coordinated motion, so I probably didn't define that. I am traveling now, but will check my code when I get back to the computer and add that in.

On last thing. I am also bringing up a CNC lathe. I noticed that when switching to CSS, an S word on the G96 line doesn't seem to update user var 113 for the CSS calculation. If the S parameter is called on the line before the G96 call, it does. Not a huge deal, I can set up my post processor for that, but it did cause some confusion until I realized that.

[TomKerekes]

Hi Jim,

I noticed that when switching to CSS, an S word on the G96 line doesn't seem to update user var 113 for the CSS calculation. If the S parameter is called on the line before the G96 call, it does. Not a huge deal, I can set up my post processor for that, but it did cause some confusion until I realized that.

I can't duplicate this. I tested using using example GCode CSS.ngc. Also it wouldn't normally make sense to issue the S before the G96 because the value could be interpreted as RPM instead of feet/minute. I suppose it would be ok if the Spindle was off.

I used this program running in an unused Thread to put the CSS value into an unused Destination (ch7) so I could monitor it.

Code: Select all

#include "KMotionDef.h"

void main()
{
	for(;;)
		ch7->Dest = *(float*)&persist.UserData[113];

}

Is the persist variable not changing? Or is the Spindle not at the right speed for some other reason?

Note when in G96 the CSS C Code in a forever loop must be running for the speed to change.

[jtremel]

Hey Tom, thats interesting you can't duplicate it.

It will be about a week before I get back to the machine and can write a more detailed description of the behavior and do a little deeper debug.

Until then, I can tell you:
- I am using my own C# GUI
- I have the Mcode callback set to handle an M3.
- When the callback for an M3 executes, UserData[113] will have the value from the previous S word, not the one on the G96 line
- with an Sword on the line immediately before the G96 call, UserData[113] contains the appropriate value for that S word
- My C forever loop does have a serviceSpindle() call to repeatedly calculate and update the spindle speed vs the X axis position. That part works fine, it's just the value of UserData[113] that is in question.
- I should note that my C code only looks at UserData[113] immediately after the M3 callback. Is it possible the M3 callback happens before 113 gets set? I thought I checked that condition. Typing this out now, I realize I should continually check UserData[113] regardless.

[TomKerekes]

Hi Jim,

The S command should always be executed and set the persist variable before the M3 if on the same line.

There is a difference if in G97 or G96 mode.

If the S is placed in the line before G96 (and in G97 mode) the S value of say 100 will be set in the Persist variable as 100 RPM.

If in the same line as G96 then the S value (in inches mode) of say 100 will be assumed to be 100 feet per minute and converted to inches per second so 20 in/s will be placed in the persist variable. Maybe that's the confusion. See the code below.

Code: Select all

					// if in CSS mode then S is not in RPM but rather in feet/min or meters/min
					// convert to standard units of inches/sec and download to KFLOP  
					if (p_setup->spindle_mode==CANON_SPINDLE_CSS)
					{
						if (p_setup->length_units == CANON_UNITS_MM)
							fspeed /= 60.0f * 0.0254f;
						else
							fspeed *= 12.0f/60.0f;
					}
					s.Format("SetPersistHex %d %x",ipersist, *(int *)&fspeed);
					if (CoordMotion->KMotionDLL->WriteLine(s)) {CoordMotion->SetAbort(); return 1;}

[jtremel]

Hey Tom,

I am back in town now and started to troubleshoot this again.

To begin with, I upgraded to Kmotion version 5.1.0.

Next, I integrated your debugging method and am running this code on thread #7

Code: Select all

#include "KMotionDef.h"
main()
{
	for(;;)
		ch5->Dest = *(float*)&persist.UserData[113];
}

For the following testing, I have a simple Gcode file to switch into G96:

Code: Select all

N01 G90 G20     ( absolute inch positioning )  
N02 G97 S500 M3 ( run at 500 RPM )
N03 G00 X2 Z2   ( rapid to radius of 2 inch )

N04 M1      ( option stop - check persit #113)
N05 M5      ( spinde off )
N06 M1      ( option stop )

( switch to CSS mode at 200 feet/min )
( should put 40 inch/sec in persist #113 )
N07 G96 D1500 S200 M3

N08 M1      ( option stop - check persit #113)
N09 M5      ( spinde off )
N10 M1      ( option Stop ) 

N11 G97 S50  ( default back to G97 mode )
M30

Before running the Gcode, I clear the persist variable with a console command:

Code: Select all

SetPersistHex 113 0

When I run the Gcode, this is the behavior I witness:

Before running the code
- Dest5 = 0
- This is expected

While sitting at the optional stop on line N04
- Dest5 = 0
- this is NOT expected
- from your post above, I expect this to be 500

note:
- my program won't be doing anything with persist #113 at thing point any way.
- my .NET code uses the value in .CoordMotion.Interpreter.SetupParams.SpindleSpeed during the Action Code #10 callback to set a persist variable ( UserData[90] )
- while in G97, my c code SpindleService() routine uses the UserData[90] to control the spindle speed
- the .NET value is 500 at this point as expected

While sitting at the optional stop on line N08
- Dest5 = 100
- this is NOT expected
- I expect this to be 40 (conversion of S200 to inches per sec)
- The value of 100 is the conversion of the previous S500 to inches per sec
- note: the .NET CoordMotion.Interpreter.SetupParams.SpindleSpeed parameter is 200 at this point

While sitting at the optional stop on line N10
- Dest5 = 100
- this is NOT expected
- I expect this to be 40 (conversion of S200 to inches per sec)

After the G code program finishes interpreting
- Dest5 = 100
- this is NOT expected
- I would expect this to be 50 (rpm in G97 mode)

In summary:
- my experience is that persist.UserData[113] only gets set during a G96 call (not during a G97 call)
- the value of persist.UserData[113] is based on the conversion of the S parameter before the G96 call, not the S word on the G96 line

It also seems to me that the .NET CoordMotion.Interpreter.SetupParams.SpindleSpeed value is always what I expect and the S (action code 10) callback always gets called when I expect. So, I could just adjust my c SpindleService() code to use a converted value from UserData[90] while in CSS mode and get the behavior I want).

I don't yet understand why my behavior is different than expected and different than what you observe.

[TomKerekes]

Hi Jim,

Thanks for the detailed description.

Just to be clear you are running your own C# .NET App and not running KMotionCNC at all. Correct?

I didn't realize that the S (Action 10) is configured as a User Call Back also.

User Call Back Actions don't put anything in any Persist Variables. Data is only placed in Persist Variable for C Program Actions. The idea is since the Call Back is on the PC and has full access there isn't any reason to place data in KFLOP.

That being said I don't understand how Persist Variable 113 is getting set at all.

Can you debug with VS? If so maybe put a breakpoint in that code fragment I posted and see how it is being called.

[jtremel]

Hi Tom,

I am running my own C#.NET application and the tests I described in my last post were from that.

However - since then - I also decided to rule out anything related to my C# application, so I ran the same testing by single stepping through the posted G code in KmotionCNC. I observed identical behavior when using KmotionCNC to interpret the G code.

Specifically, with persist #113 equal to zero at the start of Gcode, Dest5 (and thus Persist Variable 113) stays at zero unit line N07 executes. After line N07 executes, Dest5 gets set to 100 and stays there throughout the rest of the G code execution.

I just now repeated that test - ensuring that all M and S code actions were set to "None". The behavior is as described above.

I have also combed through my C code and verified that I am not setting persist #113 anywhere - I only read it.

User Call Back Actions don't put anything in any Persist Variables. Data is only placed in Persist Variable for C Program Actions. The idea is since the Call Back is on the PC and has full access there isn't any reason to place data in KFLOP.

I think I struggled to find the D-word Max RPM limit for CSS exposed through the .NET libraries, so I had to pull the value from PC_COMM_CSS_MAX_RPM ( UserData[114] ) and just ended up using the other CSS related persists in my speed calculation strategy.

I'll have to do a little digging to figure out how to attach the VS debugger your library .dll's. I think you had a web page that describes that somewhere, but I don't remember where. Any hints?

[TomKerekes]

Hi Jim,

My apologies, you are correct. I see now G96 will write all the CSS Persist variables including the S value by calling this function:

Code: Select all

int CGCodeInterpreter::SetCSS(int mode)  // set CSS mode

The thinking is that regardless of how the S Action is configured these parameters must be placed into KFLOP in order for KFLOP to perform the real-time CSS.

So only C Program Actions will place related data into Persist Variables. Actions 'None" or 'User Call back' will not.

If your S Callback needs to have a value placed in a Persist Variable your Callback might do this.


You are also correct 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'll have to do a little digging to figure out how to attach the VS debugger your library .dll's. I think you had a web page that describes that somewhere, but I don't remember where. Any hints?

This page in the wiki shows how to enable Native Code Debugging to allow you to set Breakpoints and step into unmanaged C++ libraries.