[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]

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,

Firstly though; I've bought a license for Dolphin Partmaster CAM, which so far seems to be ideal. The support from Dolphin UK is splendid and the tutorials and examples have helped me massively. Regarding the post processor, I don't think they have one for KmotionCNC. Would I be right in thinking a Mach3 PP would be pretty much identical to a KmotionCNC PP? Do you have any links to info regarding Kmotions PP requirements?

Yes KMotionCNC's Interpreter was derived from EMC public domain code which Mach3 and LinuxCNC was derived from so the basic codes should be the same or similar. If you find one that works please add it to our wiki here

The problem...... When M6T2 is run during a program for example, the axis moves to the switch, actuates the turret and moves off by 50,000 cnts. Then after the M6 command, as the next line of G-code is run the axis isn't where the controller expects it to be. As such I get a violent movement back to where it should be, before moving off to the next commanded pos.

I need the code to move the axis back to the exact encoder count position just before the M6 was called (instead of the move off limit by 50,000cnts). As you can see in the code above I have entered (and disabled) the intCurX = ch1->Position; line. I was hoping this would save the initial encoder position into a variable. However it doesn't and I'm unsure of how to then tell the axis to move back to this position.

Probably a very basic solution, but if you can help that would be sterling! I'm struggling on this one.

I think there are about 3 issues here:

#1 - You may not have your Max Following Error set to a small reasonable value. If you did and for whatever reason there was a huge jump in the commanded position then the axis should just fault/disable rather than doing something violent.

#2 - I'm not sure that you really need to move back to exactly where you were. If you configure the M6 tool change with "Exec Prog/wait/sync" then after the tool change the Interpreter should sync to where ever the machine actually is and move smoothly to the next commanded position from there.

#3 - If you do want to save where you were and move back there then you might save the last commanded Destination. The Destination as opposed to the Position is probably better because that is where the axis theoretically was commanded to be rather than where it actually is which includes some random servo error. The value is a double precision floating point variable (~17 digits of precision) not an integer variable. So you would need to declare a variable of type "double" and save the Destination there. You can do that with:

double LastDestX = ch1->Dest;

Later you could make a absolute move back to that destination with:

Move(1,LastDestX);
while(!CheckDone(1)) ;

HTH
Regards

[jim_cliff11]

Ideal!

I've gone for option 2 on your previous reply Tom. Changing to Exec/wait/sync sorted the issue right out. There's no need to move back to the previous co-ordinates after M6 as there could be a crash risk without the new tool offsets called.

Dolphin have been brilliant and are modifying their Mach3 post processor to work with KmotionCNC. So as and when we're up and running properly I'll add it to the Dynomotion wiki list of post processors.

On another note though Tom, do you have (or know of) a tutorial / guide / explanation of how to work with lathe tool offsets in KmotionCNC. Basically how to define them, and call the corresponding offset after a tool change etc. This is all completely new to me so I need to do some serious reading. But after brief research on tool offsets, I'm now more confused than ever. But just to clear my points of confusion up:

1. If I call a tool change in KmotionCNC (eg T01M6), would tool 1 be called with the corresponding offsets (from tool table) already enabled? I know in Mach3 offsets can be called by simply executing M6 T0101, with the last two digits specifying offset group, which I presume is defined in the mach3 tool table.

2. What do I use as a reference point for tool offsets? Do I have a master tool in say Slot 1 which is zero'd at the stock face and OD, then change to Slot2, touch off face and diameter. Enter difference shown in DRO into tool table offset for tool in slot 2?

3. I read on another forum, that CAM packages do not need any tool offset information. They simply call a tool change. The controller, in this case KmotionCNC handles all the offset definitions and calls. Is this right?

Thanks,

[TomKerekes]

Hi Jim,

I've gone for option 2 on your previous reply Tom. Changing to Exec/wait/sync sorted the issue right out. There's no need to move back to the previous co-ordinates after M6 as there could be a crash risk without the new tool offsets called.

Great.

Dolphin have been brilliant and are modifying their Mach3 post processor to work with KmotionCNC. So as and when we're up and running properly I'll add it to the Dynomotion wiki list of post processors.

That would be great.

On another note though Tom, do you have (or know of) a tutorial / guide / explanation of how to work with lathe tool offsets in KmotionCNC. Basically how to define them, and call the corresponding offset after a tool change etc. This is all completely new to me so I need to do some serious reading. But after brief research on tool offsets, I'm now more confused than ever.

Offsets can be confusing. I think there are a number of ways of handling them. I'm probably not the best guy to ask.

If I call a tool change in KmotionCNC (eg T01M6), would tool 1 be called with the corresponding offsets (from tool table) already enabled?

Well no.Tool Offsets are enabled with G43 Hxxx and disabled with G49. So they work independently from the loaded tool. Tool Radius compensation is also enabled with G41Dxxx G42Dxxx and disabled with G40 independently from the loaded tool.

I know in Mach3 offsets can be called by simply executing M6 T0101, with the last two digits specifying offset group, which I presume is defined in the mach3 tool table.

I'm not that familiar with Mach3. KMotionCNC doesn't have any "group' concept. Specified tool numbers 99 or less refer to the Tool Slot in the Tool Table. Numbers 100 or higher refer to the Tool ID in the Tool Table.

What do I use as a reference point for tool offsets? Do I have a master tool in say Slot 1 which is zero'd at the stock face and OD, then change to Slot2, touch off face and diameter. Enter difference shown in DRO into tool table offset for tool in slot 2?

I think it is possible to use any reference you wish as long as you are consistent. For example if you have one tool installed with a defined length of 5 inches relative to some reference and zero that tool tip to the stock. Then load a different tool which is 1 inch shorter which has a defined length of 4 inches, then zero will also be when its tool tip is on the stock.

I read on another forum, that CAM packages do not need any tool offset information. They simply call a tool change. The controller, in this case KmotionCNC handles all the offset definitions and calls. Is this right?

Again I think there can be different approaches. But yes I think the basic idea is to not have the tool lengths known to the CAD system. In that way if a tool length changes you just change the Tool Table value and there is no need to go back to the CAD system.

HTH
Regards

[jim_cliff11]

Big thanks to Tom for clearing that up me.

Hopefully others will find this thread useful, I honestly couldn’t have done it without the help of Tom! So once again, many thanks.

When everything’s right and the machine is working I’ll post my complete C codes and wiring diagram (when it’s drawn) for others contemplating a similar conversion.

Jim

[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,

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

[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]

Thanks Al,

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

[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

[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

[jim_cliff11]

Hi Tom,

Ok, so i set PrintRigidTapParams.c to run in thread 6. M-code M119 is set to VAR 60 (also adjusted in the C-program), thread 6 and Exec, wait, sync. When I enter and execute

G21G98 G84 Z-30 R40 Q3 F1.5
M30

the console prints:

MCode = -1
Bottom = -30.000000
Retract = 40.000000
Peck = 3.000000
Rate = 1.500000
RPM = 400.000000
Units = mm
Axis = 2
AxisRes = 25400.000000

So we know the G-code is being interpreted correctly by the C-program.

I've then copied your complete example program RigidTapCycle+M119 Feedhold Rev 6. and modified the properties needed to suit my machine:

#define ZAXIS 2			// Axis to slave
#define MAXERROR 0.05	// MAX slave error in inches
#define SPINDLE_AXIS 0	// Spindle Axis With Encoder Feedback 
#define SPINDLECW 		// SPINDLE CW Bit number
#define SPINDLECCW 		// SPINDLE CCW Bit number
#define Z_CPI 25400		// Counts per inch of slave axis
#define CPR 4096		// Counts per rev of spindle encoder
#define TAU 0.001		// Smoothing time
#define MAXTAPSPEED 150 // Maximum Tapping speed in rpm
#define OSFACTOR 0.0077	// Overshoot Factor (higher number reduces overshoot at higher rpms)
#define OSCONSTANT 0.034// Overshoot Constant (constant amount of compensation applied at all rpms, in inches)
#define ESTOP 137		// Emergency stop bit number 
#define ESTOPSTATE 0	// Emergency stop triggered by ClearBit = 0, SetBit = 1
#define STOPFACTOR 2.0	// Stop delay Factor (increase number to allow more time for spindle to stop while still slaving after hole in finished)
#define SPINDLE_STOP_TIME 1.0 // for Job aborts, don't exit to keep Slaving until this much time after the Spindle was turned off 
double SlaveGain,ToCut,Z0,S0,OS,SpindleStopTime;

I originally left SPINDLECW and SPINDLECCW bits without values in MySpindleDefs.h as I'm using USE_POS_NEG_VOLTAGE 1 for analog +/-10v spindle control. As such I deleted the bit values in your example above. Is this correct?

If I try and run the same G-code as above KmotionCNC then moves the Z axis to the retract position and gives me

:130: too few arguments to function

.

Is that purely because my G-code is incomplete, not specifying a spindle RPM? Or is it to with the spindle rotation config?

Thanks
Jim

[TomKerekes]

Hi Jim,

It isn't clear how your Spindle is controlled, but you can't set the CW and CCW to be nothing. If you don't need any bits to be activated assign them to some dummy bits that won't do anything such as KFLOP's LEDs 46 and 47. Or go down and remove any code that uses them.

HTH

[jim_cliff11]

Hmmm so I fired the lathe up this morning, usual start up procedure. Enabled all axis through KmotionCNC. The Z and X axis came to life and function accordingly. But the spindle has a mind of its own....

It simply does nothing, I can rotate it manually by hand. Usually it locks into position, judders slightly, and awaits a Gcode command. The axis tab on kmotion shows channel 0 (spindle) as enabled. If I rotate the spindle back and forth by hand I can see the encoder counting + and - as expected. Back to KmotionCNC, and I issued M4S1300 with no initial response. 5 minutes later the spindle came alive and sat at 1300rpm (I think) before accelerating, slowing and restabilising for a few minutes. Finally, it slowly crawled down to a stop and back to its unresponsive state. A few more attempts had the same results, but now it wont respond at all.

One thing that struck me as odd, when the spindle did jump into life as described above, KMotionCNC did not show its rpm. The commanded rpm is displayed above the spindle speed slider as usual. But the actual rpm remained at 0 the whole time the spindle was running. Even though kmotion shows the encoder count climbing. Why would this be?

I've done the usual hardware checks and found nothing untoward. The KDV power supply and TBM bleeder are both energised and ready. The KDA spindle drive is energising after receiving the RF signal. As per usual there are no error or fault lights on any hardware.

I also tried to run a step response on channel 0. The graph display showed an output and command, but the position flat lined completely.

What would be the best way to trouble this? Is there a way I can test the output from the Kanalog and test the drive separately?

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