584,808 active members*
5,114 visitors online*
Register for free
Login
Page 5 of 7 34567
Results 81 to 100 of 136
  1. #81

    Re: Mach3 Retrofit to 1989 CNC Lathe

    Hi Tom,

    To be honest the FFV value was just trial and error. I didn't take it much higher in fear of causing instability. I have however tried your value of 0.0122 for the Z axis and funnily enough calculated the same value for X. This value gave me the following step result plots:

    Z:


    X:


    Both axis are now giving me a max following error of about 16 counts, which to seems minimal. I feel like I'm going to be unable to smooth out the dither anymore because of stiction / external forces etc. I've increased I-gain slightly to try and pull the error down further, but I don't thin the system would benefit from increasing I anymore.

    What are your thoughts?

    I've also settled on KmotionCNC for my controller. I've generated my initial startup perimeter file from the axis calibrations, and defined my axis accordingly. As you know the spindle is operating from a closed loop (encoder feedback) DAC axis, but I haven't defined this is the DefineCoordSystem command. Axis velocities / acceleration and counts so far have been loaded into tools, trajectory etc for Z and X. I can now successfully JOG my axis using the on-screen arrow buttons!!

    I've setup spindle control as described here: https://dynomotion.com/Help/KMotionC...dleControl.htm
    And adjusted MySpindleDefs.h accordingly.

    I can now control my spindle CW and CCW using the KmotionCNC spindle controls!! It also shows the RPM reading! When I click 'On CW' the spindle rotates CCW if I am looking straight at it. Vice versa for clicking 'On CCW'. I'm guessing the view is that I should be looking from behind the spindle? I do however feel the spindle will take more tuning as at low speed it will judder as if it's not to sure where it's supposed to be.

    At the bottom of the init file I have adjusted and added the following for spindle threading control, which I'm hoping will work.

    Code:
        
    DefineCoordSystem(1,-1,2,-1);
    ConfigureSpindle(1,0,0.1,0.1,4096.0);
    I need to try various G-code to test threading CSS etc. My problem now is with KmotionCNC. When I try to manually execute G-code I get the error below. This also applies to loading in complete G-code from the samples and trying to run:



    Can you shed any light on this Tom?

    Another thing, I need to add to my initialization file the following IF or case statements for the safety circuit. But in honesty I'm not to sure how to implement this into the file, or where abouts:

    IF OPTO 0 (bit 136) = LOW then disable SW7
    IF OPTO 1 (bit 137) = LOW then disable SW7
    IF OPTO 2 (bit 138) = LOW then disable SW7
    IF OPTO 3 (bit 139) = LOW then disable SW7

    I suppose I could do:

    IF ALL (the above) bits = HIGH then enable SW7, else SW7 = LOW?

    I'll do some more reading tonight on C code. But if you can point me in the right direction on where to place this code in the init file that would be spot on!

    As always, thanks Tom! Things are progressing

  2. #82
    Join Date
    May 2006
    Posts
    4043

    Re: Mach3 Retrofit to 1989 CNC Lathe

    Hi Jim,

    Both axis are now giving me a max following error of about 16 counts, which to seems minimal. I feel like I'm going to be unable to smooth out the dither anymore because of stiction / external forces etc. I've increased I-gain slightly to try and pull the error down further, but I don't thin the system would benefit from increasing I anymore.

    What are your thoughts?
    Plots look good to me.

    When I click 'On CW' the spindle rotates CCW if I am looking straight at it. Vice versa for clicking 'On CCW'. I'm guessing the view is that I should be looking from behind the spindle?
    I'm not sure of the proper convention. Of course you can reverse the direction in KFLOP by changing the Input/Output Gains. I believe the Encoder Position must count Positive with M3 for Threading to work correctly.

    ConfigureSpindle(1,0,0.1,0.1,4096.0);
    You don't need to add this line of C Code. You can simply configure this in KMotionCNC | Tool Setup | Trajectory Planner | Threading

    IF OPTO 0 (bit 136) = LOW then disable SW7
    SW7 is Output Bit 159. So the KFLOP C Syntax would be:
    if (ReadBit(136) == 0) ClearBit(159);

    See also

    I'm not sure why the GCode Error. You might check for any message on the KMotion Console Screen. Please post your KMotionCNC Tool Setup Screens for us to check. Please use the latest Test Version which has many new features and better error reporting.

    Great progress
    Regards
    TK
    http://dynomotion.com

  3. #83

    Re: Mach3 Retrofit to 1989 CNC Lathe

    Hi Tom,

    I've updated to Kmotion 4.34j and flashed the version onto Kflop. I've then loaded the init file to thread1 and reconfigured KmotionCNC to exactly how it was before the update. I can still jog all axis and run the spindle but I can't for the life of me execute G code manually or through a loaded program. Every time I try to run code I get "G Code Error - GCode aborted". The Kmotion console doesn't display any error messages. I can run basic lines of G-code through Kmotion.exe but obviously my resolution isn't configured in Kmotion. I've attached some screenshots of my KmotionCNC tool setup screens:


    I've assigned a very basic C program to STOP which executes ClearBit(159); (disabled RF signal to amps)




    I've tried a few different setup files all to no change.


    Even tried with diameter mode checked, no difference.

    Below is my somab400.c init file as it currently stands:
    Code:
    #include "KMotionDef.h"
    
    
    main()
    {
        int BitA,Change1=0,Change2=0, DiffX2;
        int PosNoWrap, NewPos, Pos=0, wraps;
        double Factor=0;
        
        ch0->InputMode=ENCODER_MODE;
        ch0->OutputMode=DAC_SERVO_MODE;
        ch0->Vel=100000;
        ch0->Accel=75000;
        ch0->Jerk=1e+007;
        ch0->P=0.07;
        ch0->I=0;
        ch0->D=0;
        ch0->FFAccel=0;
        ch0->FFVel=0.003;
        ch0->MaxI=1000;
        ch0->MaxErr=12000;
        ch0->MaxOutput=2000;
        ch0->DeadBandGain=0;
        ch0->DeadBandRange=0;
        ch0->InputChan0=0;
        ch0->InputChan1=1;
        ch0->OutputChan0=0;
        ch0->OutputChan1=1;
        ch0->MasterAxis=-1;
        ch0->LimitSwitchOptions=0x100;
        ch0->LimitSwitchNegBit=0;
        ch0->LimitSwitchPosBit=0;
        ch0->SoftLimitPos=1e+030;
        ch0->SoftLimitNeg=-1e+030;
        ch0->InputGain0=-1;
        ch0->InputGain1=1;
        ch0->InputOffset0=0;
        ch0->InputOffset1=0;
        ch0->OutputGain=1;
        ch0->OutputOffset=0;
        ch0->SlaveGain=1;
        ch0->BacklashMode=BACKLASH_OFF;
        ch0->BacklashAmount=0;
        ch0->BacklashRate=0;
        ch0->invDistPerCycle=1;
        ch0->Lead=0;
        ch0->MaxFollowingError=10000000;
        ch0->StepperAmplitude=250;
    
    
        ch0->iir[0].B0=1;
        ch0->iir[0].B1=0;
        ch0->iir[0].B2=0;
        ch0->iir[0].A1=0;
        ch0->iir[0].A2=0;
    
    
        ch0->iir[1].B0=1;
        ch0->iir[1].B1=0;
        ch0->iir[1].B2=0;
        ch0->iir[1].A1=0;
        ch0->iir[1].A2=0;
    
    
        ch0->iir[2].B0=1;
        ch0->iir[2].B1=0;
        ch0->iir[2].B2=0;
        ch0->iir[2].A1=0;
        ch0->iir[2].A2=0;
        
        ch1->InputMode=ENCODER_MODE;
        ch1->OutputMode=DAC_SERVO_MODE;
        ch1->Vel=50000;
        ch1->Accel=200000;
        ch1->Jerk=2e+008;
        ch1->P=1;
        ch1->I=0.003;
        ch1->D=0;
        ch1->FFAccel=1e-005;
        ch1->FFVel=0.0122;
        ch1->MaxI=3000;
        ch1->MaxErr=500;
        ch1->MaxOutput=2047;
        ch1->DeadBandGain=0.2;
        ch1->DeadBandRange=5;
        ch1->InputChan0=1;
        ch1->InputChan1=1;
        ch1->OutputChan0=1;
        ch1->OutputChan1=1;
        ch1->MasterAxis=-1;
        ch1->LimitSwitchOptions=0x100;
        ch1->LimitSwitchNegBit=0;
        ch1->LimitSwitchPosBit=0;
        ch1->SoftLimitPos=1e+009;
        ch1->SoftLimitNeg=-1e+009;
        ch1->InputGain0=1;
        ch1->InputGain1=1;
        ch1->InputOffset0=0;
        ch1->InputOffset1=0;
        ch1->OutputGain=1;
        ch1->OutputOffset=0;
        ch1->SlaveGain=1;
        ch1->BacklashMode=BACKLASH_OFF;
        ch1->BacklashAmount=0;
        ch1->BacklashRate=0;
        ch1->invDistPerCycle=1;
        ch1->Lead=0;
        ch1->MaxFollowingError=10000000;
        ch1->StepperAmplitude=250;
    
    
        ch1->iir[0].B0=1;
        ch1->iir[0].B1=0;
        ch1->iir[0].B2=0;
        ch1->iir[0].A1=0;
        ch1->iir[0].A2=0;
    
    
        ch1->iir[1].B0=1;
        ch1->iir[1].B1=0;
        ch1->iir[1].B2=0;
        ch1->iir[1].A1=0;
        ch1->iir[1].A2=0;
    
    
        ch1->iir[2].B0=1;
        ch1->iir[2].B1=0;
        ch1->iir[2].B2=0;
        ch1->iir[2].A1=0;
        ch1->iir[2].A2=0;
        
        ch2->InputMode=ENCODER_MODE;
        ch2->OutputMode=DAC_SERVO_MODE;
        ch2->Vel=90000;
        ch2->Accel=300000;
        ch2->Jerk=1e+007;
        ch2->P=3;
        ch2->I=0.003;
        ch2->D=0;
        ch2->FFAccel=1e-005;
        ch2->FFVel=0.0122;
        ch2->MaxI=4000;
        ch2->MaxErr=2000;
        ch2->MaxOutput=2000;
        ch2->DeadBandGain=0;
        ch2->DeadBandRange=5;
        ch2->InputChan0=2;
        ch2->InputChan1=1;
        ch2->OutputChan0=2;
        ch2->OutputChan1=1;
        ch2->MasterAxis=-1;
        ch2->LimitSwitchOptions=0x100;
        ch2->LimitSwitchNegBit=0;
        ch2->LimitSwitchPosBit=0;
        ch2->SoftLimitPos=1e+009;
        ch2->SoftLimitNeg=-1e+009;
        ch2->InputGain0=1;
        ch2->InputGain1=1;
        ch2->InputOffset0=0;
        ch2->InputOffset1=0;
        ch2->OutputGain=1;
        ch2->OutputOffset=0;
        ch2->SlaveGain=1;
        ch2->BacklashMode=BACKLASH_OFF;
        ch2->BacklashAmount=0;
        ch2->BacklashRate=0;
        ch2->invDistPerCycle=1;
        ch2->Lead=0;
        ch2->MaxFollowingError=10000000;
        ch2->StepperAmplitude=250;
    
    
        ch2->iir[0].B0=1;
        ch2->iir[0].B1=0;
        ch2->iir[0].B2=0;
        ch2->iir[0].A1=0;
        ch2->iir[0].A2=0;
    
    
        ch2->iir[1].B0=1;
        ch2->iir[1].B1=0;
        ch2->iir[1].B2=0;
        ch2->iir[1].A1=0;
        ch2->iir[1].A2=0;
    
    
        ch2->iir[2].B0=1;
        ch2->iir[2].B1=0;
        ch2->iir[2].B2=0;
        ch2->iir[2].A1=0;
        ch2->iir[2].A2=0;
        
        DefineCoordSystem(1,-1,2,-1);
        
        EnableAxis(0);
        EnableAxis(1);
        EnableAxis(2);
        SetBit(159);
    
    
        // Monitor for E-stop, limits, mains pwr, drive error signals 
        for (;;) 
        {
            WaitNextTimeSlice();
            
            if (ReadBit(136) == 0 || ReadBit(137) == 0 || ReadBit(138) == 0 || ReadBit(139) == 0) {
     
                if (ch0->Enable) DisableAxis(0);
                if (ch1->Enable) DisableAxis(1);
                if (ch2->Enable) DisableAxis(2);
                ClearBit(159);
            }
        }
    
    
        
    }
    The FOR loop function at the bottom monitors the inputs, and in the case that one of the 4 inputs goes LOW, the axis are disabled and the RF amp signal disabled. Seems to work well.

    The G-code error has always happened, even before I added the additional FOR loop to the init file.

    Hopefully, its just simple setting.... fingers crossed!!

    What do you think?

    Thanks.

  4. #84
    Join Date
    May 2006
    Posts
    4043

    Re: Mach3 Retrofit to 1989 CNC Lathe

    Hi Jim,

    I think the problem is the 0 Y Axis Resolution, Acceleration, and Velocity. Even though the Y axis isn't used the values need to be non-zero. Please set them to something like 1000, 1, 10. Sorry for not having a better error message,

    HTH
    Regards
    TK
    http://dynomotion.com

  5. #85
    Quote Originally Posted by TomKerekes View Post
    Hi Jim,

    I think the problem is the 0 Y Axis Resolution, Acceleration, and Velocity. Even though the Y axis isn't used the values need to be non-zero. Please set them to something like 1000, 1, 10. Sorry for not having a better error message,

    HTH
    Regards
    Hi Tom,

    Sorry on the delay replying. I’ve been away with work for a few days and as you can probably imagine I’ve been chomping at the bit to get back and try it.

    I have, and it worked!! Very, very happy!! I even ran a basic threading test using G32 and the Z axis was geared according to spindle speed!! I’ll know more when I’ve got my head round it fully.

    My next point of focus is now the tool changer. Once I have this boxed off and working I’ll be jumping for joy. I hope you don’t mind, but I have a few questions regarding this in terms of wiring to Kanalog and the options I have available. When I get into the office tomorrow morning I’ll look at my notes and update the thread.

    Once again, many thanks!! I couldn’t have got this far without you!

  6. #86

    Re: Mach3 Retrofit to 1989 CNC Lathe

    Ok,

    Moving on to my tool turret (Sauter 0.5.480.316) which consists of the following electrical components:

    Proximity sensor (location of turret locking position)
    24vdc supply
    PNP-logic
    1 x output @ 24vdc

    Encoder (Turret work position - 1/8)
    24vdc supply
    Even parity
    High side driver
    Outputs in binary form to give position:
    - Bit 1 (1 = 24v / 0 = 0v)
    - Bit 2 (1 = 24v / 0 = 0v)
    - Bit 3 (1 = 24v / 0 = 0v)
    - Bit 4 (1 = 24v / 0 = 0v)
    - Strobe (1 = 24v / 0 = 0v)

    Motor
    3 phase
    Direction controlled through 2 x 24vdc relays
    Motor controls: 1. Turret rotation and 2. Unlocking / locking of turret through Hirth gear.

    Brake
    Spring disc brake mounted on end of motor shaft
    24v = Brake off
    0v = Brake on
    0.77amp


    Would I be right in assuming the following sequence involved in a general index operation:
    1. Brake released (24v).
    2. Motor runs: Unlocking turret from meshed hirth gears followed by CW / CCW rotation of motor.
    3. Encoder feedback to PLC confirms correct tool position.
    4. Proximity sensor detects correct locking / hirth gear mesh position
    5. Motor stops rotating, hirth lock applied.
    6. Brake applied (0v)


    Below is a rough sketch of my wiring as it currently is:



    My problem now is that I have 7 inputs (24vdc) which I need to feed into Kanalog:

    E25 - Proximity switch signal
    E24 - Encoder strobe
    E16 - Bit 1
    E17 - Bit 2
    E18 - Bit 3
    E19 - Bit 4
    E20 - Thermal relay

    I only have 4 Opto-Inputs left on Kanalog So my options as I see it:

    1. Remove non-essential safety circuit opto-inputs from JP15?
    2. Could I leave the turret thermal relay input disconnected? Or the Strobe?
    3. Use the analog inputs (JP6) on Kanalog?

    Or any other thoughts?

    The programming I'll worry about later when I've got the inputs sorted and my correct understand of how the turret operates spot on.

    Thanks,
    Jim

  7. #87
    Join Date
    May 2006
    Posts
    4043

    Re: Mach3 Retrofit to 1989 CNC Lathe

    Hi Jim,

    Some notes:

    Your drawing doesn't show an Kanalog GND connection.

    That arrangement for using the 24V supply for both sides of the relays defeats the isolation that a relay normally supplies.

    I'm not sure how your Turrent Encoder works. Not sure if strobe is an input or an output. One issue to be aware of with reading binary values is if you read them while they are transitioning you can end up reading most any value. For example when changing from 3 (0011) to 4 (0100) you might see 0 (0000) or 7 (0111). The strobe might be a qualifier to indicate the bits are valid.

    Regarding more inputs: Those could all work. You should put resistor dividers to make the voltage less than 10V for the ADC Inputs. You will need a GND connection which will defeat any isolation you may have. I suppose if you are dividing the signals down with resistors and not having isolation you could also divide them down to 3.3V and use the GPIO on KFLOP or Kanalog.

    You can also add a Konnect for lots more easy to use opto isolated IO.

    HTH
    Regards
    TK
    http://dynomotion.com

  8. #88

    Re: Mach3 Retrofit to 1989 CNC Lathe

    Morning Tom,

    Sorry I should have made my drawing more clear. I am running two 24vdc power supplies. One is for opto-isolation I/O and the other for integration into Kanalog with a linked ground. I was going to run the tool turret encoder & proximity through the Kanalog integrated 24v supply so in effect there would be no opto-isolation.

    A very kind Italian gentleman at Sauter has sent me the instruction manual on this Turret. Couldn't quite believe my luck, as usually they don't want to know when its a product with nearly 30 years behind it. I've also got the datasheet for the encoder that is fitted. I've stripped the turret manual down to essential only info and attached. Looking at the datasheets, it seems the strobe is used as an input, probably to validate the bits as you say Tom. Parity check is also shown as being included. However this was never wired up originally, so I think I can still exclude this.

    I'll use a voltage divider on the inputs to bring them down to 3.3v and then wire them into input bits 128-135 on JP12.

    I might start another thread purely for information on how the tool turret works and keep this one dedicated to Kanalog wiring and coding.

    See what you think to the attached info.

    Thanks Tom
    Jim

  9. #89
    Join Date
    May 2006
    Posts
    4043

    Re: Mach3 Retrofit to 1989 CNC Lathe

    Hi Jim,

    That all sounds correct to me. The Strobe is a qualifier.

    Regards
    TK
    http://dynomotion.com

  10. #90

    Re: Mach3 Retrofit to 1989 CNC Lathe

    Have my tool changer working perfectly now under control from KMotionCNC.

    http://81.138.85.180/~jim_cliff11/20...O-00000009.mp4

    Took me the best part of a week to write the code and an immense amount of reading, but I got there eventually

    If it helps anyone else my ToolPosChange.C code is below. It's probably fairly primitive, and there's probably more efficient ways to code it. But it does the job for me.

    Code:
    #include "KMotionDef.h"
    
    
    //Define input pins to macros
    #define IN_STROBE 132
    #define IN_TEMP 134
    #define IN_PROX 133
    #define IN_BIT1 128
    #define IN_BIT2 129
    #define IN_BIT3 130
    #define IN_BIT4 131
    #define OUT_CW 154
    #define OUT_CCW 153
    
    
    //Define function prototypes
    void CurEncoderValues(void);
    void CurToolNo(void);
    void ReqToolNo(void);
    void ReqEncoderValues(void);
    void ReqRotation(void);
    void Actuate(void);
    
    
    //Declare variables for current position
    int intCurBit1;
    int intCurBit2;
    int intCurBit3;
    int intCurBit4;
    int intCurStrobe;
    int intCurToolNo;
    int intCurBin;
    
    
    //Declare variables for new position
    int intReqBit1;
    int intReqBit2;
    int intReqBit3;
    int intReqBit4;
    int intReqStrobe;
    int intReqToolNo;
    int intReqBin;
    
    
    //Declare variables for control
    int intDir;
    int intProx;
    int intTurretActive;
    
    
    
    
    main()
    {
        //Disable limit switches in main INIT program (thread 1)
        intTurretActive = 1;
        
        //Move X axis to safe position
    
    
        //Find current
        CurEncoderValues();
        CurToolNo();
        
        //Find required 
        ReqToolNo();
        ReqEncoderValues();
        
        //Update console
        printf("\nCurrent tool = %d at %d%d%d%d%d\n", intCurToolNo,intCurBit1,intCurBit2,intCurBit3,intCurBit4,intCurStrobe);
        printf("Required tool = %d at %d%d%d%d%d\n", intReqToolNo,intReqBit1,intReqBit2,intReqBit3,intReqBit4,intReqStrobe);
        
        //Determine required rotation
        ReqRotation();
        
        //Actuate turret in required direction if thermal relay OK
        Actuate();
        
        //Re-enable limit switches in main INIT program
        intTurretActive = 0;
    }
    
    
    
    
    //Actuate turret
    void Actuate(void)
    {
    if (intReqToolNo != intCurToolNo) {
        SetBit(152);
        intProx = ReadBit(IN_PROX);
    
    
        while(intCurBit1 != intReqBit1 || intCurBit2 != intReqBit2 || intCurBit3 != intReqBit3 || intCurBit4 != intReqBit4 || intCurStrobe != intReqStrobe || intProx != 1) {
        SetBit(intDir); 
        CurEncoderValues();
        CurToolNo();
        intProx = ReadBit(IN_PROX);
        }
        ClearBit(intDir);
        ClearBit(152);
        printf("Tool change complete\n");
    } else {
        printf("Tool already in position\n");
    }
    }
    
    
    //Determine required rotation for least amount of moves to required position - Set bit No
    void ReqRotation(void)
    {
        int c,r,cw,cc,rr,ccw;
        for(c = intCurToolNo, r = intReqToolNo, cw = 0; c != r; cw++) {
            c++;
            if (c == 9) { c = 1 ;}
        }
        printf("No of positions CW = %d\n", cw);
        for(cc = intCurToolNo, rr = intReqToolNo, ccw = 0; cc != rr; ccw++) {
            cc--;
            if (cc == 0) { cc = 8 ;}
        }
        printf("No of positions CCW = %d\n", ccw);
        
        if (cw < ccw) { intDir = OUT_CW; } else if (ccw < cw) { intDir = OUT_CCW; }
        printf("Rotation of turret will be = %d\n", intDir);
    }
    
    
    //Required encoder values for new tool position
    void ReqEncoderValues(void)
    {
       switch(intReqToolNo) {
          case 1 :
            intReqBit1 = 1;
            intReqBit2 = 0;
            intReqBit3 = 0;
            intReqBit4 = 0;
            intReqStrobe = 1;
            break;
          case 2 :
            intReqBit1 = 0;
            intReqBit2 = 1;
            intReqBit3 = 0;
            intReqBit4 = 0;
            intReqStrobe = 1;
            break;
          case 3 :
            intReqBit1 = 1;
            intReqBit2 = 1;
            intReqBit3 = 0;
            intReqBit4 = 0;
            intReqStrobe = 1;
            break;
          case 4 :
            intReqBit1 = 0;
            intReqBit2 = 0;
            intReqBit3 = 1;
            intReqBit4 = 0;
            intReqStrobe = 1;
            break;
          case 5 :
            intReqBit1 = 1;
            intReqBit2 = 0;
            intReqBit3 = 1;
            intReqBit4 = 0;
            intReqStrobe = 1;
            break;
          case 6 :
            intReqBit1 = 0;
            intReqBit2 = 1;
            intReqBit3 = 1;
            intReqBit4 = 0;
            intReqStrobe = 1;
            break;
          case 7 :
            intReqBit1 = 1;
            intReqBit2 = 1;
            intReqBit3 = 1;
            intReqBit4 = 0;
            intReqStrobe = 1;
            break;
          case 8 :
            intReqBit1 = 0;
            intReqBit2 = 0;
            intReqBit3 = 0;
            intReqBit4 = 1;
            intReqStrobe = 1;
            break;
          default :
            intReqBit1 = 1;
            intReqBit2 = 0;
            intReqBit3 = 0;
            intReqBit4 = 0;
            intReqStrobe = 1;
        }
            
    }    
    
    
    //What is demanded tool number
    void ReqToolNo(void)
    {
        intReqToolNo = persist.UserData[9];
    }
    
    
    //Check encoder values
    void CurEncoderValues(void)
    {
        intCurBit1 = ReadBit(IN_BIT1);
        intCurBit2 = ReadBit(IN_BIT2);
        intCurBit3 = ReadBit(IN_BIT3);
        intCurBit4 = ReadBit(IN_BIT4);
        intCurStrobe = ReadBit(IN_STROBE);
    }
    
    
    //determine current tool number
    void CurToolNo(void)
    {
        if ((intCurBit1 == 1) && (intCurBit2 == 0) && (intCurBit3 == 0) && (intCurBit4 == 0) && (intCurStrobe == 1)) {
            intCurToolNo = 1; } 
        else if ((intCurBit1 == 0) && (intCurBit2 == 1) && (intCurBit3 == 0) && (intCurBit4 == 0) && (intCurStrobe == 1)) {
            intCurToolNo = 2; }
        else if ((intCurBit1 == 1) && (intCurBit2 == 1) && (intCurBit3 == 0) && (intCurBit4 == 0) && (intCurStrobe == 1)) {
            intCurToolNo = 3; }
        else if ((intCurBit1 == 0) && (intCurBit2 == 0) && (intCurBit3 == 1) && (intCurBit4 == 0) && (intCurStrobe == 1)) {
            intCurToolNo = 4; }
        else if ((intCurBit1 == 1) && (intCurBit2 == 0) && (intCurBit3 == 1) && (intCurBit4 == 0) && (intCurStrobe == 1)) {
            intCurToolNo = 5; }
        else if ((intCurBit1 == 0) && (intCurBit2 == 1) && (intCurBit3 == 1) && (intCurBit4 == 0) && (intCurStrobe == 1)) {
            intCurToolNo = 6; }
        else if ((intCurBit1 == 1) && (intCurBit2 == 1) && (intCurBit3 == 1) && (intCurBit4 == 0) && (intCurStrobe == 1)) {
            intCurToolNo = 7; }
        else if ((intCurBit1 == 0) && (intCurBit2 == 0) && (intCurBit3 == 0) && (intCurBit4 == 1) && (intCurStrobe == 1)) {
            intCurToolNo = 8; }
            
    }
    Tom, I do have one question though......

    Ideally, I would like to pass the variable intTurretActive from the above code across to my Init program in thread 1 (which is running continuously). The IF statement in my init program which controls the safety circuit will then have an addition condition:

    Code:
    //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) {
                    //Limit switches in-operable
                } else { 
                
                if (ch0->Enable) DisableAxis(0);
                if (ch1->Enable) DisableAxis(1);
                if (ch2->Enable) DisableAxis(2);
                ClearBit(159);
            }
        }
        }
    My objective is: When the tool turret is active, limit switches are inactive. I will write code into my ToolPosChange.c that moves the Z axis back UNTIL it hits the far limit switch (all wired into same input anyway). Once this limit switch is hit, the turret can rotate safely without risk of collision. When rotation complete, Z will move back to the position it was previously in. intTurretActive will then == 0, which is passed back to the init in thread 1. The limit switches are then re-enabled and machining can continue.

    Thanks,
    Jim

  11. #91
    Join Date
    May 2006
    Posts
    4043

    Re: Mach3 Retrofit to 1989 CNC Lathe

    Hi Jim,

    Nice! But don't quit your day Job to be a videographer

    Regarding the intTurretActive : You should be able to use any unused global persist variable instead. Like maybe #20. It can be referenced as persist.UserData[20].

    I think you will want to clear this in the Init program before the forever loop so there is always limit protection initially.

    I'm not sure if there will be an issue if for some reason the Tool Change Fails or gets aborted the bypass might remain on. An abort will likely disable everything and require a re-initialization so maybe that wont be an issue. Make sure all your normal exit paths turn it back on.

    HTH
    Regards
    TK
    http://dynomotion.com

  12. #92

    Re: Mach3 Retrofit to 1989 CNC Lathe

    Hi Tom,

    Swarf conveyor, coolant, lube pump, pneumatic tail stock, pneumatic chuck, spindle gear change and light all wired in and working.

    Thanks for the help previously posted, I've got so far with this but cracked on with other things. As such I have a few questions:

    1. Is it possible to add 1 user button to turn on the swarf conveyor with the first click and then turn off the conveyor with the second click. I've got a button to turn it on, but I have to turn it off on the kmotion I/O screen.

    2. As mentioned above I've discovered I have a 2 speed spindle gearbox. This gear change is all wired in through bits 145 and 146. Two hall sensors mounted on the gearbox detect which gear is currently selected (wired into bits 140, 141). It turns out the spindle was previously in the high gear which is why it was so unstable at low speed. When in low gear (without altering my drive tuning) I can rotate the spindle at 1RPM in a perfectly stable manor without any judder. I have two user buttons, one for LOW and one for HIGH with the following code:

    High:

    Code:
    #include "KMotionDef.h"
    #define IS_GHIGH 140
    #define IS_GLOW 141
    #define SET_GHIGH 146
    #define SET_GLOW 145
    
    int intIsLow;
    int intIsHigh;
    
    main()
    {
        intIsLow = ReadBit(IS_GLOW);
        intIsHigh = ReadBit(IS_GHIGH);
        
        if (intIsLow == 1) {
    
            while(intIsHigh != 1) {
            SetBit(SET_GHIGH);
            intIsHigh = ReadBit(IS_GHIGH);
            }
        
        ClearBit(SET_GHIGH);
        printf("Spindle in high gear\n");
        
        } else {
        
        printf("Spindle already in high gear\n");
        
        }
         }
    Low:

    Code:
    #include "KMotionDef.h"
    #define IS_GHIGH 140
    #define IS_GLOW 141
    #define SET_GHIGH 146
    #define SET_GLOW 145
    
    int intIsLow;
    int intIsHigh;
    
    main()
    {
        intIsLow = ReadBit(IS_GLOW);
        intIsHigh = ReadBit(IS_GHIGH);
        
        if (intIsHigh == 1) {
    
            while(intIsLow != 1) {
            SetBit(SET_GLOW);
            intIsLow = ReadBit(IS_GLOW);
            }
        
        ClearBit(SET_GLOW);
        printf("Spindle in low gear\n");
        
        } else {
        
        printf("Spindle already in low gear\n");
        
        }
         }
    Is it possible to incorporate this code into my OnCWJog.c and OnCCWJog.c so that when for example a spindle speed of 600+ is passed from M3S601 the spindle stops, high gear change is executed and then the spindle is ran up to speed and machining can continue? If so, I could probably throw the value of the S value into an IF statement and select the appropriate gear according to it's value. The spindle motor has to be at 0RPM in order to switch gears.

    3. At random times since first setting up the KFLOP / KANALOG board I've had slight interference on my VGA monitor. When I enable SWE7 (drive enable etc) my monitor displays lines or interference. I can live with this. However as I've done more wiring and increased functionality through Kmotion this has got worse. Both at random and when a relay (eg. tool change) is powered the screen will go off, the mouse reset to centre and then come back on after a few seconds. The fact the mouse realigns itself to centre of the display makes me think this is more than just capable interference. Is there a possibility I'm receiving a back feed through the USB cable which could cause this, or is it purely down to interference and I need to shield my VGA cable?

    Once again,
    Many thanks Tom!

  13. #93

    Unhappy Re: Mach3 Retrofit to 1989 CNC Lathe

    Ok, so I've started implementing the gear change code into my spindle C programs. I've added the following to my MySpindleDefs.h

    Code:
    #define IS_GHIGH 140
    #define IS_GLOW 141
    #define SET_GHIGH 146
     #define SET_GLOW 145
    The OnCCWJog.c now looks like this:

    Code:
    #include "KMotionDef.h"
    
    #include "MySpindleDefs.h"
    
    int   *css_mode = &persist.UserData[PC_COMM_CSS_MODE];            // Mode 1=Normal RPM mode. 2=CSS
    int intIsLow;
    int intIsHigh;
    // desired speed is passed from KMotionCNC in variable KMVAR
    // save in user variable STATEVAR whether it was off, CW, or CCW (0,1,-1)
    // save in user variable SPEEDVAR the last desired speed
    
    main()
    {
        float speed = *(float *)&persist.UserData[SPEEDVAR];  // value stored is actually a float 
        float LastState = persist.UserData[STATEVAR];  // get last state 
        
        intIsLow = ReadBit(IS_GLOW);
        intIsHigh = ReadBit(IS_GHIGH);
        
        if (LastState==1)  
        {
            // if spindle was CW now we want CCW 
            // spin down
            
            ClearBit(SPINDLECW_BIT);
            ClearBit(SPINDLECCW_BIT);
            Jog(SPINDLEAXIS,0);
            while (!CheckDone(SPINDLEAXIS)) ;
        }
        
        // Is gear change required. If yes execute
        if (speed <= 500) {
            if (intIsHigh == 1) {
    
                ClearBit(SPINDLECW_BIT);
                ClearBit(SPINDLECCW_BIT);
                Jog(SPINDLEAXIS,0);
                while (!CheckDone(SPINDLEAXIS)) ;
                
                while(intIsLow != 1) {
                SetBit(SET_GLOW);
                intIsLow = ReadBit(IS_GLOW);
                }
        
                ClearBit(SET_GLOW);
                printf("Spindle in low gear\n");
            }
                
        } else if (speed >= 501) {
            if (intIsLow == 1) {
    
                ClearBit(SPINDLECW_BIT);
                ClearBit(SPINDLECCW_BIT);
                Jog(SPINDLEAXIS,0);
                while (!CheckDone(SPINDLEAXIS)) ;
                
                while(intIsHigh != 1) {
                SetBit(SET_GHIGH);
                intIsHigh = ReadBit(IS_GHIGH);
                }
        
                ClearBit(SET_GHIGH);
                printf("Spindle in high gear\n");
            }
        }
        
        // turn spindle on CCW and ramp to new speed
        SetBit(SPINDLECCW_BIT);
        
        LastState = -1;
        
        if (*css_mode != 2)
        {
            // spindle is already on, so ramp to new speed
            if (USE_POS_NEG_VOLTAGE)
                Jog(SPINDLEAXIS,speed * FACTOR * LastState);
            else
                Jog(SPINDLEAXIS,speed * FACTOR);
            
            printf("Jogging Spindle %f counts/sec\n",speed * FACTOR);
        }    
        persist.UserData[STATEVAR] = -1;  // remember we are CCW
    }
    I tried going from M4S600 to M4S300 in the KmotionCNC G-code window and the gear change began before the spindle had spun down to a stop. Luckily no damage was caused but it went off with a hell of a bang and grind! Next time I don't think I'll be so lucky.

    It seems that the code is not waiting for the spindle to stop before executing the gear change if. The results are the same if I am in high gear, followed by M5. Then when the spindle is stopped if I run M4S100 the spindle starts rotating before the gear change is complete... causing grinding.

    I presume the
    Code:
    while (!CheckDone(SPINDLEAXIS)) ;
    line is there to wait for the spindle to become stationary? But it doesn't seem to work. This is unfortunately where my in-experience with C lets me down

    Is there anyway I can adjus he code to ensure the spindle is AT commanded 0 before any gear change code is run? Maybe reading the encoder value to confirm stationary and waiting until this is validated. The code doesn't seem to wait in the while loop before moving on to enabling rotation.

    Any help greatly appreciated as I don't want to destroy my gearbox this far down the line.

    Thanks

  14. #94
    Join Date
    May 2006
    Posts
    4043

    Re: Mach3 Retrofit to 1989 CNC Lathe

    Hi Jim,

    1. Is it possible to add 1 user button to turn on the swarf conveyor with the first click and then turn off the conveyor with the second click. I've got a button to turn it on, but I have to turn it off on the kmotion I/O screen.
    You might:

    #1 add a second button to turn it off

    #2 cause the button to toggle the Bit. ie if (ReadBit(XX) ClearBit(XX) else SetBit(XX); // if set then clear and vice versa

    #3 use KMotionCNC Screen Editor to add a Toggle Button.

    here.

    At random times since first setting up the KFLOP / KANALOG board I've had slight interference on my VGA monitor. When I enable SWE7 (drive enable etc) my monitor displays lines or interference. I can live with this. However as I've done more wiring and increased functionality through Kmotion this has got worse. Both at random and when a relay (eg. tool change) is powered the screen will go off, the mouse reset to centre and then come back on after a few seconds. The fact the mouse realigns itself to centre of the display makes me think this is more than just capable interference. Is there a possibility I'm receiving a back feed through the USB cable which could cause this, or is it purely down to interference and I need to shield my VGA cable?
    I'm not sure. Grounding and shielding are complex issues. My guess would be interference from the motor wires which have the full motor supply voltage switching at high frequencies and with fast rise and fall times. You might shield the motor wiring to earth GND and/or shield the display signals to a display Gnd. You might also temporarily uplug the USB connection while there is interference to see if that has an effect.

    I presume the while (!CheckDone(SPINDLEAXIS)) ;

    line is there to wait for the spindle to become stationary? But it doesn't seem to work.
    Yes that is what that line should do. It actually waits until the commanded trajectory comes to a stop and assumes the Spindle is actually stopped. Depending on how your system is tuned you might be decelerating to a stop faster than the Spindle can actually stop. You might use the Step Response Screen to observe how well your Spindle is following commanded trajectories. I assume you have SPINDLEAXIS defined correctly? You might want to add an additional time delay with Delay_sec(3.0); You might observe the Done Status on the KMotion.exe Axis Screen.

    I tried going from M4S600 to M4S300 in the KmotionCNC G-code window and the gear change began before the spindle had spun down to a stop. Luckily no damage was caused but it went off with a hell of a bang and grind! Next time I don't think I'll be so lucky.

    It seems that the code is not waiting for the spindle to stop before executing the gear change if. The results are the same if I am in high gear, followed by M5. Then when the spindle is stopped if I run M4S100 the spindle starts rotating before the gear change is complete... causing grinding.
    Something else to check is whether you have these programs configured as "Exec Prog/Wait" in KMotionCNC. If you don't have the Wait option selected then the programs can step on each other if for example M4 is executed in the middle of an S sequence.

    You might want to change your Gear Change code statements to printf statements or to simply toggle LEDs until it works correctly.

    HTH
    Regards
    TK
    http://dynomotion.com

  15. #95

    Re: Mach3 Retrofit to 1989 CNC Lathe

    Hi Tom,

    Thanks for the reply.

    I ran VGA and USB cables from the PC over the top of the lathe just to try, this fixed the interference issues. I'm going to try and get some shielded cables and re-route them. Shields on all control cables are tied down to Kanalog 0v.

    Re the toggle buttons, thanks for the video, I'll get these done tonight. As for the gear change, I'll rig up a couple of 24v bulbs and use these until the codes right! Good thinking, I should have really thought of this.

    Will keep progress posted.

    Thanks once again

  16. #96

    Re: Mach3 Retrofit to 1989 CNC Lathe

    Good day Tom,

    Update:

    I've got the spindle gear change working successfully and I also ordered and fitted a triple shielded VGA cable with gold plated connectors. Although it cost nearly £40 it's fixed the interference and black out issues I was having. Toggle buttons are now working for coolant and swarf conveyor using individual C programs containing basic IF statements

    I've also updated the tool change program which so far works very well! Although I need a little pointer which I'll explain below.

    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?

    Regarding the tool change, I've implemented the intTurretActive variable into a user data variable. This successfully disables the limit switches during a tool change and re-enables them after. I am using the following code to then move the X axis up until it triggers the switch, actuates the turret and then moves the X axis away from the limit switch by

    Code:
    //Move X axis to safe position
    //intCurX = ch1->Position;
    Jog(1,-50000);        
    while (ReadBit(138)) ; 
    Jog(1,0);
    while(!CheckDone(1)) 
    
    .............
    
    
    //Move X off limit switch
    MoveRel(1,50000);
    while(!CheckDone(1)) ;
    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.

  17. #97
    Join Date
    May 2006
    Posts
    4043

    Re: Mach3 Retrofit to 1989 CNC Lathe

    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
    TK
    http://dynomotion.com

  18. #98

    Re: Mach3 Retrofit to 1989 CNC Lathe

    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,

  19. #99
    Join Date
    May 2006
    Posts
    4043

    Re: Mach3 Retrofit to 1989 CNC Lathe

    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
    TK
    http://dynomotion.com

  20. #100
    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

Page 5 of 7 34567

Similar Threads

  1. 1989 Hurco Km3P retrofit
    By ABFrank in forum Vertical Mill, Lathe Project Log
    Replies: 4
    Last Post: 10-28-2015, 09:15 AM
  2. More troubles with mach3 retrofit
    By billsnogo in forum Bridgeport / Hardinge Mills
    Replies: 19
    Last Post: 09-20-2015, 09:51 PM
  3. Replies: 0
    Last Post: 08-10-2013, 02:31 PM
  4. What should I keep here? - Mach3 retrofit
    By DiyAddicts in forum Uncategorised MetalWorking Machines
    Replies: 3
    Last Post: 09-02-2012, 04:08 AM
  5. Hurco KMB-1 Mach3 Retrofit
    By jalessi in forum HURCO
    Replies: 0
    Last Post: 08-19-2008, 03:19 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •