[jim_cliff11]

Two quickies Tom, searched high and low and found no answers:

1. Does Knotion have a “return to part zero” button type feature similar to Mach3? Or do I need to write a code for it. If so, how do I call part zero in my c code? I can write code to return to the machine coordinate origin, but I’m not sure how to call part origin.

2. Is there a line of code I can put into my init code to tell KMotionCNC which tool slot is currently loaded? Instead of tool 1 default at power up.

Thanks

[TomKerekes]

Hi Jim,

1. Does Knotion have a “return to part zero” button type feature similar to Mach3? Or do I need to write a code for it. If so, how do I call part zero in my c code? I can write code to return to the machine coordinate origin, but I’m not sure how to call part origin.

I'm not sure exactly what you want to do. But one approach could be to assign a small GCode file to a User Button. You can do this by configuring a button to Exec Prog but specify a file with a GCode extension of *.ngc. The File might be:

G0X0Y0Z0
M0

Is there a line of code I can put into my init code to tell KMotionCNC which tool slot is currently loaded? Instead of tool 1 default at power up

I assume the init code somehow knows which tool is loaded? If so you might send an MDI command of Txxx. To form such a command character string given an integer tool number you might code:

    int iTool=2;  // assume you have an integer tool number
    char s[20];   // allocate a string of 20 characters
    sprintf(s,"T%d",iTool); // form characters of T + tool as decimal number
    MDI(s); // send to KMotionCNC

Waiting for the video

HTH
Regards

[jim_cliff11]

Hi Tom,

I didn't realise I could execute G-code files through a user button. I want to be able to return the current tool to the stock / program datum / zero through a button on Kmotion if I need to. Objective being, it saves me having to find X zero (stock centre line) manually each time. I'll have a play.

On another note, I've changed the limit switch wiring, X and Z limits are now wired into separate opto inputs. I've implemented your SimpleHomeIndexFunctionTest.c and added additional code to disable my limit switches (similar to technique used in tool change script):

#include "KMotionDef.h"#include "SimpleHomeIndexFunction.c" 


int intHomeActive;


main()
{
	int result;
	
	//Disable limit switches in main INIT program (thread 1)
	intHomeActive = 1;
	persist.UserData[83] = intHomeActive;


	// HOME X


	result = SimpleHomeIndexFunction(1,  // axis number to home
			   50000.0,  // speed to move toward home
			   +1,      // direction to move toward home (+1 or -1)
			   142, 	// limit bit number to watch for
			   0,		// limit polarity to wait for (1 or 0)
               300.0,	// speed to move while searching for index
			   37,		// index bit number to watch for (use -1 for none)
			   0, 		// index polarity to wait for (1 or 0)
			   10000);	// amount to move inside limits
			   
	if (result==0)
	{
		printf("Home X succeded\n");
	}
	else
	{
		printf("Home X failed\n");
		return;
	}
	
	// HOME Z
	
	result = SimpleHomeIndexFunction(2,  // axis number to home
			   90000,  // speed to move toward home
			   +1,      // direction to move toward home (+1 or -1)
			   138, 	// limit bit number to watch for
			   0,		// limit polarity to wait for (1 or 0)
               300,	// speed to move while searching for index
			   38,		// index bit number to watch for (use -1 for none)
			   0, 		// index polarity to wait for (1 or 0)
			   20000);	// amount to move inside limits
			   
	if (result==0)
	{
		printf("Home Z succeded\n");
	}
	else
	{
		printf("Home Z failed\n");
		return;
	}
	
	//Re-enable limit switches in main INIT program
	intHomeActive = 0;
	persist.UserData[83] = intHomeActive;


}

X moves up to the limit, stops, moves back and stops in "home" position. Z does the same.... ideal! However I have an odd problem which I was lucky to notice in honesty. Once both axis are homed; If I execute the script again, the axis again move up to the limits, stop, but travel further back past where they stopped the first time (maybe +10mm on Z & +5mm X). If I then run the script yet again, the axis go through the same motions but stop where they did the first time (-10mm Z / -5mm X). The pic below shows the two different positions on the Z axis (you can see where the axis has stopped each time from the two oil slicks).



My differential Index pulses are wired into JP2. Chan 0 (spindle) to A4, Chan 1 (X) to A5, Chan 2 (Z) to A6.



Would the code above be right calling index bit 37 for X, 38 for Z?

Thanks,
Jim

Ps. Videos will follow, and it will be worth the wait I promise! It is frankly, an awesome machine, and Kflop / Kanalog have well and truely blown my expectations away! Unbelievable!

[TomKerekes]

Hi Jim,

X moves up to the limit, stops, moves back and stops in "home" position. Z does the same.... ideal! However I have an odd problem which I was lucky to notice in honesty. Once both axis are homed; If I execute the script again, the axis again move up to the limits, stop, but travel further back past where they stopped the first time (maybe +10mm on Z & +5mm X). If I then run the script yet again, the axis go through the same motions but stop where they did the first time (-10mm Z / -5mm X). The pic below shows the two different positions on the Z axis (you can see where the axis has stopped each time from the two oil slicks).

Is the homing variation exactly one revolution of the lead screw (or encoder)? The SimpleHomeIndexFunction.c is very simple and makes some assumptions. The assumptions are that the axis can drive to the Home/Limit, reverse, and always find the index on the same revolution. It is helpful when the Home sensor trips at a significant distance away (1/2 rev) from where the Index pulse occurs. The closer the Index and home triggers are together, the more likely that the Index will be detected sometimes on the first rev and sometimes on the second rev.

In your case I think the issue is exacerbated by the relatively high Velocity (and possibly low Acceleration and Jerk) you move with to the Limit/Home switch. How far you happen to start away has an effect on what is the speed when detecting the Limit/Home, which in turn effects the amount of overshoot, which determines if you will detect the Index more immediately or after another revolution.

If you adjust the Index to be 1/2 rev away from the Limit/Home and slow down to always be able to stop within 1/2 rev of the encoder then you should have a guaranteed consistent result.

If that solution is difficult or undesirable. We can enhance the algorithm to detect the Home/Limit, stop, reverse at a slow speed, wait for the Limit/Home to go away, then begin looking for the Index pulse.

Hope that makes sense.

Would the code above be right calling index bit 37 for X, 38 for Z?

No. Because your wiring skips over the B signals the IO bit for X would be 38 and Z would be 40.

Regards

[jim_cliff11]

Hi Tom,

Thanks for the reply. Yes velocity seems to make a big difference. Too high and misses the first index pulse. Reduced homing velocity, setting the correct index input bits and polarity has fixed the issue My only minor issue now is KmotionCNC gives me a pop-up box saying "GUI button waiting on C program taking a long time complete. Continue waiting?" during the home process. Is this a simple fix?

I'm currently setting up the CSS feature. I appreciate having a spindle gear change @ 500rpm isnt ideal, but I'm hoping when I do run CSS on turning operations that the min rpm is above 500rpm anyway. I've incorporated the ServiceCSS() function into my init program forever loop (see below).

#include "KMotionDef.h"

int intTurretActive;
int intHomeActive;
int intXpost;
int intZpost;


main()
{
	int BitA,Change1=0,Change2=0, DiffX2;
	int PosNoWrap, NewPos, Pos=0, wraps;
	double Factor=0;
	
	ch0->InputMode=ENCODER_MODE;
	ch0->

........................................................
	
	DefineCoordSystem(1,-1,2,-1);
	
	EnableAxis(0);
	EnableAxis(1);
	EnableAxis(2);
	SetBit(159);
	
	intXpost = 0;
	intZpost = 0;


	// Safety circuit 
	for (;;) 
    {
        WaitNextTimeSlice();


		ServiceCSS();
        
        intTurretActive = persist.UserData[89];
        intHomeActive = persist.UserData[83];
        
        //Monitor for E-stop, mains pwr, drive error signals
		if (ReadBit(136) == 0 || ReadBit(137) == 0 || ReadBit(139) == 0) {
 
			if (ch0->Enable) DisableAxis(0);
			if (ch1->Enable) DisableAxis(1);
			if (ch2->Enable) DisableAxis(2);
			ClearBit(159);
			ClearBit(152);
			ClearBit(153);
			ClearBit(154);
			
		//Monitor for limit switches (unless during tool turret rotation)
        } else if (ReadBit(138) == 0) {
        
			if ((intTurretActive == 1) || (intHomeActive == 1)) {
				//printf("Limit switches disabled for turret change or homing\n");
				//Limit switches in-operable
			} else { 
			
			if (ch0->Enable) DisableAxis(0);
			if (ch1->Enable) DisableAxis(1);
			if (ch2->Enable) DisableAxis(2);
			ClearBit(159);
			if (intZpost == 0) printf("Z axis limit triggered\n");
			intZpost = 1;
			}
		
		} else if (ReadBit(142) == 0) {
			
			if ((intTurretActive == 1) || (intHomeActive == 1)) {
				//printf("Limit switches disabled for turret change or homing\n");
				//Limit switches in-operable
			} else { 
			
			if (ch0->Enable) DisableAxis(0);
			if (ch1->Enable) DisableAxis(1);
			if (ch2->Enable) DisableAxis(2);
			ClearBit(159);
			if (intXpost == 0) printf("X axis limit triggered\n");
			intXpost = 1;
			}
		}
	}


    
}	


#include "C:\KMotion434j\C Programs\SpindleUsingJogs\CSS\MySpindleDefs.h"
#include "C:\KMotion434j\C Programs\SpindleUsingJogs\CSS\CSSJog.c"


int   *css_mode = &persist.UserData[PC_COMM_CSS_MODE];               // Mode 1=Normal RPM mode. 2=CSS
float *css_xoff = &persist.UserData[PC_COMM_CSS_X_OFFSET];           // X axis counts for Radius zero
float *css_xfactor = &persist.UserData[PC_COMM_CSS_X_FACTOR]; // X axis factor to convert counts to inches
float *css_s = &persist.UserData[PC_COMM_CSS_S];                           // S speed setting in inches/sec
float *css_max_rpm = &persist.UserData[PC_COMM_CSS_MAX_RPM];  // Limit max RPM to this value as Radius approaches zero
double css_T=0;  // update only every so often


#define CSS_UPDATE_DT 0.05


void ServiceCSS(void)


{


    float rpm;


    double T=Time_sec();


 


    if (*css_mode == 2 && T > css_T) // check if we are in CSS mode and it is time to update


    {


        css_T=T+CSS_UPDATE_DT;  // determine next time to update


       


        // convert axis position to distance from center in inches


        float radius = fast_fabs((chan[CS0_axis_x].Dest - *css_xoff) * *css_xfactor);


       


        if (radius > 0.0f)


            rpm = *css_s / (radius * (TWO_PI_F/60.0f));


        else


            rpm = *css_max_rpm;


 


        if (rpm > *css_max_rpm) rpm = *css_max_rpm;


               


        if (persist.UserData[STATEVAR]!=0)  // if spindle is already on, ramp to new speed


        {


            if (USE_POS_NEG_VOLTAGE)
               Jog(SPINDLEAXIS,rpm * FACTOR * persist.UserData[STATEVAR]);
            else
               Jog(SPINDLEAXIS,rpm * FACTOR);


        }
//      printf("xoff=%f radius= %f xfactor=%f s=%f(ips) maxrpm=%f rpm=%f\n",*css_xoff,radius,*css_xfactor,*css_s,*css_max_rpm,rpm);


    }


}

Using the G96 example program on the dynomotion spindle control page I can sucessfully vary the spindle speed according to X radius, but I have two problems:

1. The spindle controller in KmotionCNC shows CSS mode, but the spindle RPM display is wrong. As the actual RPM increases with smaller radius, the display shows the RPM reducing in speed. As the actual RPM decreases, Kmotion shows it as increasing.

2. The spindle doesnt change to the high gear (+500rpm), before starting. It just runs flat out in low gear (see below), varying its speed in corrolation with X.

http://81.138.85.180/~jim_cliff11/css.mp4

When using CSS, would I be right in saying the surface speed (passed in S code - eg. G96 M04 D2500 S159.6), does NOT go through the OnCCWJog.C / OnCWJog.C scripts? The CSSJog.c (incorporated into init.c) solely deals with the S code? If so, could I use the rpm float variable within the ServiceCSS() function to take the required spindle speed, and depending if <500 or >500 implement my gear change code? Basically as I've done in SpindleJog.C (see attached). Tell me if I'm way off track here Tom!

Thanks,
Jim

[TomKerekes]

Hi Jim,

My only minor issue now is KmotionCNC gives me a pop-up box saying "GUI button waiting on C program taking a long time complete. Continue waiting?" during the home process. Is this a simple fix?

You might configure the User Button for Homing to only Execute the C Program without waiting for it to finish.

The spindle controller in KmotionCNC shows CSS mode, but the spindle RPM display is wrong. As the actual RPM increases with smaller radius, the display shows the RPM reducing in speed. As the actual RPM decreases, Kmotion shows it as increasing.

I think the display might actually be correct. KMotionCNC in CSS mode doesn't display RPM but rather Surface Speed. So the display shouldn't really change at all as ideally the surface speed should always be the same. However for some reason I think your Spindle Control has a somewhat slow reaction time to change it's speed.

So for example when there is a large 50mm radius and the spindle is running slow the SS is correct. Then suddenly the radius goes small. The SS is now low until the Spindle RPM ramps up. While the Spindle RPM ramps up the SS is below the desired value. And vice versa when increasing the radius. Hard to tell from your video as you don't have the radius in view. But I think that is what is occurring.

The spindle doesnt change to the high gear (+500rpm), before starting. It just runs flat out in low gear (see below), varying its speed in corrolation with X.

http://81.138.85.180/~jim_cliff11/css.mp4

When using CSS, would I be right in saying the surface speed (passed in S code - eg. G96 M04 D2500 S159.6), does NOT go through the OnCCWJog.C / OnCWJog.C scripts? The CSSJog.c (incorporated into init.c) solely deals with the S code? If so, could I use the rpm float variable within the ServiceCSS() function to take the required spindle speed, and depending if <500 or >500 implement my gear change code? Basically as I've done in SpindleJog.C (see attached). Tell me if I'm way off track here Tom!

That is correct. The ServiceCSS() routine will have to handle any necessary gear changes. However it is going to be a bit complicated because you shouldn't add any waiting or delays within ServiceCSS(). If you do then your forever loop will be blocked for those time periods and things like Estop wouldn't be serviced. So a slightly more complicated approach is required. Normally a "state machine" approach is used. Where a State variable is used to remember what state things are in and ServiceCSS always immediately exits. If ServiceCSS needs to wait for something instead of waiting it remembers what it is waiting on and exits. When it is next called it recalls what it was waiting on and checks that thing. If it still isn't done it just exits again. If it is done it does something and advances to a new state. You might read this and let us know how much of it makes sense.

HTH
Regards

[jim_cliff11]

Cheers Tom,

Removed the wait and changed to exec program which solved the issue of the GUI.

Your right the KmotionCNC spindle speed is actually showing the surface speed in CSS mode. The spindle is slow to respond, but I'd only be using CSS mode occasionally, in turn operations and at slow feed rates.

For trial purposes I've implemented the gear change code in to my init.c serviceCS() routine without the state machine timer. I understand what you mean, as I've used a similar method of delay by measuring current time and interval duration on the Arduino without pausing the loop.

I decided to run CSS in high gear only:

// Safety circuit     for (;;) 
    {
        WaitNextTimeSlice();

        ServiceCSS();
        
        intTurretActive = persist.UserData[89];
        intHomeActive = persist.UserData[83];
        
        //Monitor for E-stop, mains pwr, drive error signals
        if (ReadBit(136) == 0 || ReadBit(137) == 0 || ReadBit(139) == 0) {
 
            if (ch0->Enable) DisableAxis(0);
            if (ch1->Enable) DisableAxis(1);
            if (ch2->Enable) DisableAxis(2);
            ClearBit(159);
            ClearBit(152);
            ClearBit(153);
            ClearBit(154);
            ClearBit(145);
            ClearBit(146);
            
        //Monitor for limit switches (unless during tool turret rotation)
        } else if (ReadBit(138) == 0) {
        
            if ((intTurretActive == 1) || (intHomeActive == 1)) {
                //printf("Limit switches disabled for turret change or homing\n");
                //Limit switches in-operable
            } else { 
            
            if (ch0->Enable) DisableAxis(0);
            if (ch1->Enable) DisableAxis(1);
            if (ch2->Enable) DisableAxis(2);
            ClearBit(159);
            if (intZpost == 0) printf("Z axis limit triggered\n");
            intZpost = 1;
            }
        
        } else if (ReadBit(142) == 0) {
            
            if ((intTurretActive == 1) || (intHomeActive == 1)) {
                //printf("Limit switches disabled for turret change or homing\n");
                //Limit switches in-operable
            } else { 
            
            if (ch0->Enable) DisableAxis(0);
            if (ch1->Enable) DisableAxis(1);
            if (ch2->Enable) DisableAxis(2);
            ClearBit(159);
            if (intXpost == 0) printf("X axis limit triggered\n");
            intXpost = 1;
            }
        }
    }

    
}    

#include "C:\KMotion434j\C Programs\SpindleUsingJogs\CSS\MySpindleDefs.h"
#include "C:\KMotion434j\C Programs\SpindleUsingJogs\CSS\CSSJog.c"

int   *css_mode = &persist.UserData[PC_COMM_CSS_MODE];               // Mode 1=Normal RPM mode. 2=CSS
float *css_xoff = &persist.UserData[PC_COMM_CSS_X_OFFSET];           // X axis counts for Radius zero
float *css_xfactor = &persist.UserData[PC_COMM_CSS_X_FACTOR]; // X axis factor to convert counts to inches
float *css_s = &persist.UserData[PC_COMM_CSS_S];                           // S speed setting in inches/sec
float *css_max_rpm = &persist.UserData[PC_COMM_CSS_MAX_RPM];  // Limit max RPM to this value as Radius approaches zero
double css_T=0;  // update only every so often
int intIsLow;
int intIsHigh;

#define CSS_UPDATE_DT 0.05

void ServiceCSS(void)
{
    
    intIsLow = ReadBit(IS_GLOW);
    intIsHigh = ReadBit(IS_GHIGH);

    float rpm;
    double T=Time_sec();

    if (*css_mode == 2 && T > css_T) // check if we are in CSS mode and it is time to update
    {

        css_T=T+CSS_UPDATE_DT;  // determine next time to update
        // convert axis position to distance from center in inches
        float radius = fast_fabs((chan[CS0_axis_x].Dest - *css_xoff) * *css_xfactor);

        if (radius > 0.0f)
            rpm = *css_s / (radius * (TWO_PI_F/60.0f));
        else
            rpm = *css_max_rpm;
            if (rpm > *css_max_rpm) rpm = *css_max_rpm;
            
        // Select high gear only for CSS
        if (intIsLow == 1) {

            Jog(SPINDLEAXIS,0);
            while (!CheckDone(SPINDLEAXIS)) ;
            Delay_sec(3.0);
            
            //while(intIsHigh != 1) {
            SetBit(SET_GHIGH);
            Delay_sec(2.5);
            intIsHigh = ReadBit(IS_GHIGH);
            //}
    
            ClearBit(SET_GHIGH);
            printf("Spindle in high gear\n");
            Delay_sec(3.0);
        }

        if (persist.UserData[STATEVAR]!=0)  // if spindle is already on, ramp to new speed
        {
            if (USE_POS_NEG_VOLTAGE)
               Jog(SPINDLEAXIS,rpm * FACTOR * persist.UserData[STATEVAR]);
            else
               Jog(SPINDLEAXIS,rpm * FACTOR);
        }
//      printf("xoff=%f radius= %f xfactor=%f s=%f(ips) maxrpm=%f rpm=%f\n",*css_xoff,radius,*css_xfactor,*css_s,*css_max_rpm,rpm);

    }
 }

Although I had to add an additional if (*css_mode != 2) { 'gear change' } statement into my OnCWJog.c and OnCCWJog.c as when the G96 M04 D2500 S300 was called in the program my jog scripts were interpreting S as spindle speed and executing a gear change to low before the change to high by the ServiceCSS(). This extra if solved the issue.

What I'm finding now is that when the G96 code is executed the axis start moving before the spindle has changed to high. I've solved this by adding a 10 second delay to the jog scripts (see attached). Whether this is right way of having the axis wait until the spindle has started I don't know.... but it works. As the serviceCSS() is in my init.c running continuously I cannot add a wait.

I'm now going to program in the machine state current time and duration delays as you've suggested, then move on to making sure threading works next week. After this, it's just a case of finishing the post processor and a few wiring issues... hopefully.

Thanks Tom!

[jim_cliff11]

Hi Tom,

Me again, and I'm 99% sure this is the final major issue that needs solving.... threading! Practically the reason I've done this conversion, as the parts I'll be making are all threaded. I wont sleep tonight, worrying about this now, I hope it's fixable / solvable!

As you know I've configured chan 0 (spindle) for encoder feedback in KmotionCNC:



I've modified and run the threading example that comes with Kmotion:

G21G0 X17.5 Z0
M4S300
M100
(Pass1)
G00 X17.5
G32 Z-60 F1.5
G00 X18.5
G00 Z0
(Pass2)
G00 X17.4
G32 Z-60 F1.5
G00 X18.5
G00 Z0
(Pass3)
G00 X17.4
G32 Z-60 F1.5
G00 X18.5
G00 Z0
(Pass4)
G00 X17.4
G32 Z-60 F1.5
G00 X18.5
G00 Z0
(Pass5)
G00 X17.4
G32 Z-60 F1.5
G00 X18.5
G00 Z0
(Pass6)
G00 X17.4
G32 Z-60 F1.5
G00 X18.5
G00 Z0
(Pass7)
G00 X17.4
G32 Z-60 F1.5
G00 X18.5
G00 Z0
(Pass8)
G00 X17.4
G32 Z-60 F1.5
G00 X18.5
G00 Z0
(Pass9)
G00 X17.4
G32 Z-60 F1.5
G00 X18.5
G00 Z0
(Pass10)
G00 X17.4
G32 Z-60 F1.5
G00 X18.5
G00 Z0
(Pass11)
G00 X17.4
G32 Z-60 F1.5
G00 X18.5
G00 Z0


M30

The above code starts a 1.5mm pitch thread, taking a .2mm cut in the 2nd pass from a bar 35mm in diameter. The following 9 passes are simply meant to trace the start of the thread for test purposes (sync testing).

However, on each following pass I'm at a guess 0.15mm out of sync each time. So by the end of the 11th pass I'm just over 1.5mm out of sync on the Z axis and the bar has been turned smooth. See below:



If I pause the program after the second pass and measure the thread root, it's spot on 1.5mm pitch.

Upon changing the code again to cut a full thread this was the result as expected:



I've tensioned up the spindle motor drive belt, the encoder belt, checked for stock slip in the chuck, checked the tool is secure and even tightened the bed. All to no avail

Given the consistency and linear type characteristics of the increased sync error with each pass I'd say it's an electrical or software issue.

The spindle encoder is 1024 ppr giving 4096 cpr with a differential index pulse connected to bit 36, the latter is not actually specified or used in software though. The spindle performance curves as you know from earlier in this thread were not great, but the spindle handles cutting forces and maintains a stable rpm well. Given that spindle actual position is used in threading the poor spindle accuracy shouldn't matter to much anyway. The Z axis has 2500 ppr giving 10000 cpr @ 10mm pitch lead screws. I'm 99% sure that the Z axis is consistent and accurate with every G0 / G1 move, but I'll check again tomorrow and confirm. For now let's assume that it is.

Have you any ideas on this Tom? Or any methods of further diagnosis? Could I use the encoder index pulse to sync the axis instead maybe?

I'd be quite happy to strip the machine back down and completely re-wire Kanalog if it meant accurate threading. But hopefully this doesn't need to happen.

Thanks again,
Jim

[TomKerekes]

Hi Jim,

I wouldn't panic I'm sure we will be able to find something wrong and correct it.

The first thing to check would be the Spindle Encoder. It might have noise causing the angular position to slowly drift, or you might have the wrong cpr. Could it really be 4000cpr instead of 4096?

To determine if the Spindle Encoder is working correctly do a simple test:

#1 Put a pencil mark or something on the spindle so you can tell when the spindle is at some angle.
#2 run KMotion.exe and zero the encoder position.
#3 run the Spindle for a random number of many revolutions.
#4 Stop the Spindle.
#5 manually move the Spindle to the same angle as in step #1
#6 record the Spindle Position in counts of the KMotion.exe Axis screen.

The final Position should be an exact multiple of 4096 counts (within a few counts depending on how accurately you positioned it to the mark). To determine if the Position is a multiple of 4096, divide the position by 4096 and the number should be nearly an exact integer.

Let us know the result.

Regards

[jim_cliff11]

Thanks for the reply Tom!

I followed your instruction and the result was a decimal every time. I marked a line as best I could on the spindle and head stock then used a set square to line them up. I measured 4108 pretty much every time, which seems odd!!

Anyway, after adjusting the code and settings to 4108 the thread is 95% better sync wise. After about 20 passes it still shaved the tiniest amount off. But it’s practically fine.

I can’t find any information regarding the encoder online. I just assumed as it was 1024 ppr it would be x4 for cpr as it’s differential. But onviiiusly not.

Is there a way I can find out exactly how many counts per rev the encoder kicks out through KMotion?

Can’t tell u how relieved I am that it’s an incorrect CPR, as I know it can be fixed. Other than trial and error I need to figure a way out of accurately measuring it. Could I write a program to count all the pulses between index pulses?

[TomKerekes]

Hi Jim,

That's good to know, but I think it is extremely unlikely that the CPR could really be that 4018 number. Something else is more likely going on.

One suspect would be noise adding or loosing counts. Sometime noise works in a statistical manner where something like 1 in 1000 counts gets missed so it appears as if the CPR is off. Its usually easy to tell if you have noise or not because there will most likely be accumulated drift over time. So you might play around moving forward and backwards hundreds of revs multiple times and see if there is any observed drift.

Here is a little background on how encoder noise usually manifests itself. The A B quadrature signals should normally only change one at a time in quadrature sequence. Which one changes next determines the direction (+ or - 1 count). A noise glitch (pulse) on one channel normally isn't a problem as it results in a +1 count and then a -1 count. Its when one of the channels happens to be changing exactly when the glitch happens on the other channel causing 2 channels to change at the same time. This causes confusion and the result is the position ends up being off by 4 counts.

I forget what encoder you ended up using, how/where it is mechanically connected, how it is wired, if the cables are shielded, etc...

If you can determine there is noise drift, then the next step would be to try to identify the source. So you might for example turn off the power to your XZ servos to see if the drift goes away.

The easy way to accurately measure the CPR is to simply go many revs. For example if you go 1000 revs the encoder should change by 4096000 counts.so dividing by the 1000 revs gives 4096.000 CPR.

Regards

[jim_cliff11]

Hi Tom,

Sorry on the slow reply. I’ve spent the last few evenings going through the wiring to find anything that could cause an issue. Not having much joy at the moment. When the drives are disabled (rf signal) there seems to be no interference. Only when enabled do I seem to get issues. X and z axis are spot on, it’s just the spindle which is causing issues.

The spindle encoder is attached to the spindle shaft via a toothed belt driving a 1:1 pulley. Wiring goes through a 12 pin plug half way down thto loom and straight back to Kanalog diff inputs and +5v / 0v. Thinking about it I should check the plug! Missed that one.

Another thing which may or may not be of relevance (but is still annoying).... every now and again on executing a tool change Kanalog / Kflop reboots. It’s basically when the relays are triggered I think. The relays for he 3 phase tool change motor direction are driven from SWE relay drivers directly. Grounding through Kanalog. The relays are only 200milliamps, so Its within tolerance.

All relays on the machine I initially fitted with freewheeling diodes for protection of Kanalog.

Everything else on the opto-outputs is on another 24vdc supply.

Thanks,
Jim

[TomKerekes]

Hi Jim,

When the drives are disabled (rf signal) there seems to be no interference. Only when enabled do I seem to get issues. X and Z axis are spot on, it’s just the spindle which is causing issues.

So I understand this to mean that only with XZ motor power on and XZ Amplifiers enabled the Spindle encoder miss counts?

Are the motor cables close together to the encoder cables? Either shielded?

You might check the A+ A- B+ B- voltage levels at Kanalog. They should all toggle between about 0.5V and 3V. Sometimes they operate marginally correct with a broken wire and floating signal.

Kanalog has only moderate termination on the encoder inputs of 470 ohms. Ideally the Termination should be ~120 ohms. So you might consider paralleling 160~200 ohms across each + to - input.

KFLOP has digital filtering to reject noise glitches. KFLOP samples the A B signals at 16.67 MHz and requires them to be stable for 7 samples (by default) before considering the signal to have a valid new changed state. 7 samples = 0.42us. You might try increasing the filter value. Numbers higher than 14 will start reducing the max count rate below 1Mhz. The setting is global to all Encoders and can be changed by executing the statement below with the number 7 changed to a larger value (255 max):

FPGAW(ENC_NOISE_FILTER_ADD)=7;

Another thing which may or may not be of relevance (but is still annoying).... every now and again on executing a tool change Kanalog / Kflop reboots. It’s basically when the relays are triggered I think. The relays for he 3 phase tool change motor direction are driven from SWE relay drivers directly. Grounding through Kanalog. The relays are only 200milliamps, so Its within tolerance.

Hard to say what could be causing this without knowing your wiring and grounding. It is most likely a separate issue from the Encoder noise problem. I assume the relays are driven from a 24V supply? If so where is the +24V GND connected? or the 5V? Does the +5V supply have sufficient power? Most of the KFLOP connectors contain a Reset signal. Noise injected into the cables might be causing a KFLOP Reset. This was more of a problem in KFLOP Hardware Versions before V1.3. V1.3 has added filtering on the reset input and is not usually a problem. Otherwise you will probably need to do some trouble shooting to isolate what is the cause.

HTH
Regards

[jim_cliff11]

Hi Tom,

Happy new year to you and all the other CNCZone users! Thought I'd update this thread as its been a while.

The Lathe is now fully functioning and has been for the last few months. There's still a few bits to finish off, but I'll do this when we move her to the new part of the workshop. She's surpassed all my expectations so far and I'm happy to say we now have a productive and profitable machine running KMotionCNC front end and Dolphin Partmaster CAM. Similar to yourself Tom, the Dolphin guys have been exceptional in their support and dedication to the creation of a compatible post processor to run with kmotion.

In terms of the missing pulses on the spindle, I triple checked all encoder wiring when I removed the power chuck. I also had the encoder off, and found it had play in its shaft. I managed to repair this and so far its counting 4,096 pulses dead on every time per rev. Thread consistency is perfect in both metric and imperial.

I also identified (but not solved) the issue of the spindle judder which was causing so many problems when tuning. The Redex BVR35/3 spindle motor gearbox has excessive play between meshing gears. Without the drive belt attached I can rock the output pulley back and forth the same amount the spindle was juddering. The encoders are obviously registering this movement and the Kflop is trying to correct it. Ultimately, I'll have to remove and strip the gearbox and see if I can repair it. But Redex are now part of Andantex and the BVR has been replaced with the MSD series......parts are few and far between.

Attached a few videos below:

http://81.138.85.180/~jim_cliff11/Lathe1.mp4
http://81.138.85.180/~jim_cliff11/Lathe2.mp4
http://81.138.85.180/~jim_cliff11/Lathe3.mp4

Once again, a massive thank you is needed!
Jim

[Al_The_Man]

Nice Video's.
What kind of counter balance is on the X axis?
Al.

[jim_cliff11]

Thanks Al,

No counter balance on the X axis. The servo motor simply drives the lead screw directly with a built in 24v brake.

[Al_The_Man]

I'm surprised! that tool turret looks quite heavy!
Al.

[TomKerekes]

Hi Jim,

Thanks for the nice videos.

I hope you don't mine us putting them on our channel:

https://youtu.be/9GskwsA4NoE

[jim_cliff11]

Not a problem Tom. I hope they inspire others.

Quick example of the benefits we're seeing already..... The last video was the machining of a ball coupling directly into the end of a 50mm diameter chrome hardened rod. This was to fit into the socket of a self-levelling foot on a batch of outrigger stabiliser rams we built. Prior to the somab retrofit we would purchase the balls complete and weld them onto the rods with a small amount of prep work. Now we can reduce labour and material costs by removing a process from the manufacture. Win Win!

I will eventually get round to producing a wiring diagram!

Thanks again Tom

[TomKerekes]

Hi Jim,

Nice, BTW it doesn’t seem you have CSS functional. We could help you with that if it would be useful.