584,866 active members*
4,882 visitors online*
Register for free
Login
Page 1 of 3 123
Results 1 to 20 of 43
  1. #1
    Join Date
    Dec 2012
    Posts
    390

    Getting variable for scripts

    Hi, all.

    I've just ordered a Drewtronic probe and since I haven't found any screens for probing, I've started to make one myself. I can't be the only one wanting to use a probe for setting up stock instead of just using it to make a point cloud, but I haven't been able to find any proper scripts for probing. I've started on a script, using the script from Jeremy Brown as a starting point, and, since I'm not a programmer, I've hit a few snags.

    I'm using TTS, so the probe will have a tool offset (which I'll measure offline, same as the other tools) and I want to get this tool offset in the script. Am I correct in that I can get this with GetToolLength(99-1, &Length) (probe being tool 99)? Is there a list somewhere (without wading through source codes) which lists all available commands and variables? I had a look through the wiki and online help without finding much useful. I've been looking through several of the included scripts without getting much wiser.

    At the start of the script, I'll show a message box to check that the probe is installed. If the answer is No, I want to stop running the script. Would the correct command for this be DoPC(PC_COMMS_HALT);? Or is this basically the same as E-stop?

    I'll probably have several other questions as I progress...

    Br,
    Stig

  2. #2
    Join Date
    May 2006
    Posts
    4043

    Re: Getting variable for scripts

    Hi Stig,

    I want to get this tool offset in the script. Am I correct in that I can get this with GetToolLength(99-1, &Length) (probe being tool 99)?
    The parameter for the GetToolLength() function is actually the tool table index not the tool ID or Slot. Currently the only way to get a particular Tool Length based on its Slot is to first select it. Here is an example:

    Code:
    #include "KMotionDef.h"
    
    #define TMP 10 // which spare persist to use to transfer data
    #include "KflopToKMotionCNCFunctions.c"
    
    main()
    {
        int Units, TWORD, HWORD, DWORD;
        double Length;
    
        MDI("T99");  // select probe tool
        
        GetMiscSettings(&Units, &TWORD, &HWORD, &DWORD);
        GetToolLength(TWORD, &Length);
        printf("T = %d Length = %f\n",TWORD, Length);
    
        return;
    }

    Note this assumes the Probe will be executed from a User Button. If invoked from GCode the MDI command is not allowed while running GCode. The T99 command will need to be inserted in the GCode instead.



    Is there a list somewhere (without wading through source codes) which lists all available commands and variables?
    KMotionDef.h and PC-DSP.h lists all the available Functions, Variables and Defines.



    At the start of the script, I'll show a message box to check that the probe is installed. If the answer is No, I want to stop running the script. Would the correct command for this be DoPC(PC_COMMS_HALT);?
    If a User Button initiated the Probe then there isn't a need to Halt. Just exit the C Program.



    Would the correct command for this be DoPC(PC_COMMS_HALT);? Or is this basically the same as E-stop?
    PC_COMMS_HALT can be used to Halt GCode. It is different from EStop. PC_COMM_ESTOP would be equivalent to E-stop.


    Attached is a somewhat updated version of Jeremy Brown's Probe routine cleaned up a bit and where the Probe polarity can be defined.

    HTH
    TK
    http://dynomotion.com

  3. #3
    Join Date
    Dec 2012
    Posts
    390

    Re: Getting variable for scripts

    Hi, Tom.

    Thanks for the answers.

    The probing would be started from a user button, so to exit the script, would that be done by using "return;"? Would the correct way to do this be like this?
    Code:
    int Answer;
    
    	Answer = MsgBox("Is Probe installed in Spindle?",MB_YESNO|MB_ICONEXCLAMATION);
    	if (Answer == IDNO)
    	{
    		printf("Probe is NOT installed\n");
    		return;
    	}
    	else
    		printf("Probe is installed\n");
    I'm planning, for now, to set up the probing screen to allow me to find each side, each corner or find center of stock by clicking one of nine buttons. Is there a way to pass a variable to the script, or some other way, to find out which button was pressed so I can have only one probing script instead of 9 different scripts?

    Issuing a MDI("T99"); from the script would only select the tool, wouldn't it? Would I need to do a MDI("H99"); to activate the tool offset as well?

    The Jeremy script seems to work in inches, while I work in metric. Is there a way to make the script units agnostic? I'll have a couple of edit boxes to input approx stock dimensions for the center-finding probe routine, so knowing if the numbers are in inches or metric would be kind of important... :-) I guess I can use a togglebutton to toggle a virtual bit to select this. Is there a range of virtual bits which can be used for this without creating inputs or outputs to suddenly change?

    I plan to share the screens and script when I'm finished. Otherwise I would just make everything in metric.

    Br,
    Stig

  4. #4
    Join Date
    Dec 2012
    Posts
    390

    Re: Getting variable for scripts

    Another question, are the speeds in the script in motor pulses per second or units (in/mm) per second? From the size (1000 & 500) it looks like it is motor pulses per second.

    Br,
    Stig

  5. #5
    Join Date
    May 2006
    Posts
    4043

    Re: Getting variable for scripts

    Hi Stig,

    The probing would be started from a user button, so to exit the script, would that be done by using "return;"? Would the correct way to do this be like this?
    That should work.



    I'm planning, for now, to set up the probing screen to allow me to find each side, each corner or find center of stock by clicking one of nine buttons. Is there a way to pass a variable to the script, or some other way, to find out which button was pressed so I can have only one probing script instead of 9 different scripts?
    Screen Script Buttons don't have a means of identifying which button was pushed. You might make 9 different C Programs where each just defines which button it is and then includes the main probing code. So for example the "Middle" Button could be:

    Code:
    enum {TOP_LEFT, TOP,    TOP_RIGHT, 
          LEFT,     MIDDLE, RIGHT,
          BOT_LEFT, BOT,    BOT_RIGHT};
          
    int Button = MIDDLE;
    
    #include "ProbeMain.c"
    With the ProbeMain.c common file something like:

    Code:
    #include "KMotionDef.h"
    
    void main()
    {
    	if (Button == MIDDLE)
    		printf("Middle Button Pushed\n");
    	else if (Button == TOP)	
    		printf("Top Button Pushed\n");
    }



    Issuing a MDI("T99"); from the script would only select the tool, wouldn't it? Would I need to do a MDI("H99"); to activate the tool offset as well?
    Actually "G43H99" would be needed to turn on Tool Length Compensation for Tool 99 in the Interpreter. But Jeremy's code doesn't use the Interpreter to do the movements. The movements are just made in raw machine counts. So you would need to factor in the Length that we described reading from the Tool Table in the previous post.



    The Jeremy script seems to work in inches, while I work in metric. Is there a way to make the script units agnostic? I'll have a couple of edit boxes to input approx stock dimensions for the center-finding probe routine, so knowing if the numbers are in inches or metric would be kind of important... :-)
    The GetMiscSettings(&Units, &TWORD, &HWORD, &DWORD); used in the previous example to get the Tool Length also returns the current Interpreter Units. So I would think you could use that. Such as:

    if (Units==CANON_UNITS_INCHES)
    ...
    else
    ...


    I plan to share the screens and script when I'm finished. Otherwise I would just make everything in metric.
    That would be very considerate. Thank you.



    are the speeds in the script in motor pulses per second or units (in/mm) per second? From the size (1000 & 500) it looks like it is motor pulses per second.
    Yes, they are in raw KFLOP units of counts/sec. But like Jeremy does with the distances, the resolutions can be factored in to use inches/sec, or also factor in another 25.4 to use mm/sec.

    HTH
    TK
    http://dynomotion.com

  6. #6
    Join Date
    Dec 2012
    Posts
    390

    Re: Getting variable for scripts

    Quote Originally Posted by TomKerekes View Post
    Screen Script Buttons don't have a means of identifying which button was pushed. You might make 9 different C Programs where each just defines which button it is and then includes the main probing code. So for example the "Middle" Button could be:
    Good thinking. Thanks! It should be possible to use switch/case instead of multiple if/then, wouldn't it? It should make it a bit cleaner looking.


    Quote Originally Posted by TomKerekes View Post
    Actually "G43H99" would be needed to turn on Tool Length Compensation for Tool 99 in the Interpreter. But Jeremy's code doesn't use the Interpreter to do the movements.
    True, but Jeremy isn't using a probe either. He is using the actual tool. Since I use TTS where tool "0" is the spindle face, I need to use tool length compensation to correct for the length of the probe.


    Quote Originally Posted by TomKerekes View Post
    That would be very considerate. Thank you.
    Since I didn't start this from scratch, it would only be fair for me to share my changes. It'll probably take a bit of time before I have it in a state where I can have someone else take a look at it, especially since it'll take a week or two before I receive my new probe and can actually test it myself.

    Br,
    Stig

  7. #7
    Join Date
    May 2006
    Posts
    4043

    Re: Getting variable for scripts

    Hi Stig,


    Good thinking. Thanks! It should be possible to use switch/case instead of multiple if/then, wouldn't it? It should make it a bit cleaner looking.
    Sure


    True, but Jeremy isn't using a probe either. He is using the actual tool. Since I use TTS where tool "0" is the spindle face, I need to use tool length compensation to correct for the length of the probe.
    Sorry I don't understand the issue. I'm thinking your probing will set some Fixture or G92 offset. So to do that properly the calculations will need to consider the probe length. Also the probe motions will want to consider the Probe Length to probe efficiently and without crashing. But the Tool Length Compensation for the Probe Length wouldn't ever need to be enabled for the Interpreter. Later when you run the Job using other Tools the corresponding Length Comp for those Tools will need to be enabled appropriately.
    TK
    http://dynomotion.com

  8. #8
    Join Date
    Dec 2012
    Posts
    390

    Re: Getting variable for scripts

    Quote Originally Posted by TomKerekes View Post
    Sorry I don't understand the issue. I'm thinking your probing will set some Fixture or G92 offset. So to do that properly the calculations will need to consider the probe length. Also the probe motions will want to consider the Probe Length to probe efficiently and without crashing. But the Tool Length Compensation for the Probe Length wouldn't ever need to be enabled for the Interpreter. Later when you run the Job using other Tools the corresponding Length Comp for those Tools will need to be enabled appropriately.
    My thinking is that I'll treat the probe as any other tool, so I'll set Z DRO to "0" when the probe is activated. I'm far from an expert, but my understanding is that probing (like this) is mostly used for setting the fixture position. The correct fixture would need to be set first before probing. If I enable G43, I wouldn't need to take the length of the probe into consideration. The bottom tip of the probe will be Z0. When I change to a different tool, the tip of the tool should be the exact same point in space. If I don't enable G43, I would need to add the length of the probe before I set Z0. Or am I way out of my depth here? Of course, I still need to make sure I lift up the probe between sideways moves. I'll also check that it isn't tripping during moves.

    Br,
    Stig

  9. #9
    Join Date
    May 2006
    Posts
    4043

    Re: Getting variable for scripts

    Hi Stig,

    My thinking is that I'll treat the probe as any other tool, so I'll set Z DRO to "0" when the probe is activated. I'm far from an expert, but my understanding is that probing (like this) is mostly used for setting the fixture position. The correct fixture would need to be set first before probing. If I enable G43, I wouldn't need to take the length of the probe into consideration. The bottom tip of the probe will be Z0. When I change to a different tool, the tip of the tool should be the exact same point in space. If I don't enable G43, I would need to add the length of the probe before I set Z0. Or am I way out of my depth here? Of course, I still need to make sure I lift up the probe between sideways moves. I'll also check that it isn't tripping during moves.
    Well there are a number of approaches that could be used. Setting Z DRO to zero with Tool (Probe) Length Enabled should work. But I think setting the Z DRO to the Tool Length without Tool Length Enabled would be simpler. I'm not sure how that would work for X and Y if the probe has a diameter or such. I think the length needs to be factored in order to determine where to move to begin the probing. Unless you use the Interpreter to do moves with GCode instead of Jeremy's KFLOP Functions.
    TK
    http://dynomotion.com

  10. #10
    Join Date
    Dec 2012
    Posts
    390

    Re: Getting variable for scripts

    Quote Originally Posted by TomKerekes View Post
    I'm not sure how that would work for X and Y if the probe has a diameter or such.
    Diameter , X and Y offsets would need to be set to 0.

    Attached is a pre-alpha version of the screens and scripts. The screens are made for more or less 1920*1080 monitors. All the usual caveats apply, if it kills your house and/or burns down your cat, don't blame me... :-)

    For some reason, I can't get it to compile. I was running it from the same folder as the other included screens and it was complaining about not finding KflopToKMotionCNCFunctions.c, so I copied this file to the same folder as the scripts and now it is complaining about expecting ";" on line 81 in ProbeMain.c, which is just a curly bracket for an if-statement. The Script and Images folders should be in the same folder as the screens. There's bound to be more mistakes in there, but I haven't found them yet since I've hit this stumbling block and can't get past it.

    Is there a way to get 2 lines of text in the labels/buttons? Other than using images?

    Br,
    Stig

  11. #11
    Join Date
    May 2006
    Posts
    4043

    Re: Getting variable for scripts

    Hi Stig,

    Diameter , X and Y offsets would need to be set to 0.
    Wouldn't offsets be needed to compensate for the probe diameter? But I see you are using fPROBETIPDIAMETER so it should be factored in. My point was more why use the Interpreter Compensation for Length and not for XY. Anyways many ways to do things.



    now it is complaining about expecting ";" on line 81 in ProbeMain.c, which is just a curly bracket for an if-statement. The Script and Images folders should be in the same folder as the screens. There's bound to be more mistakes in there, but I haven't found them yet since I've hit this stumbling block and can't get past it.
    The C Language is case sensitive:

    ProbeMain.c line 80 has "If" instead of "if"

    ProbeMain.c line 114 has "UNITS" instead of "Units"

    ProbeMain.c line 131 has "*BUTTON" instead of "Button"

    ProbeMain.c line 377 is missing a close bracket

    fBUFFERDISTANCE is declared inside the main() function. It's scope is therefore limited to main() and can't be referenced from other functions. To make a variable globally accessible move it to the top outside any function.

    Confusion between StockWidth/Depth string variables and double floating point variables

    Use of '!' (NOT) instead of '|' (BITWISE OR)

    PC_COMMS_HALT instead of PC_COMM_HALT

    Printf instead of printf

    BITWISE AND '&' instead of Logical AND '&&'


    These unused variable (but I left in as you probably aren't finished)

    "C:\KMotion435b\PC VC Examples\KMotionCNC\Screens\Scripts\ProbeMain.c", line 88: warning: variable "nHole" was declared but never referenced
    "C:\KMotion435b\PC VC Examples\KMotionCNC\Screens\Scripts\ProbeMain.c", line 88: warning: variable "sHole" was declared but never referenced
    "C:\KMotion435b\PC VC Examples\KMotionCNC\Screens\Scripts\ProbeMain.c", line 88: warning: variable "wHole" was declared but never referenced
    "C:\KMotion435b\PC VC Examples\KMotionCNC\Screens\Scripts\ProbeMain.c", line 88: warning: variable "eHole" was declared but never referenced
    "C:\KMotion435b\PC VC Examples\KMotionCNC\Screens\Scripts\ProbeMain.c", line 89: warning: variable "approxXAxisHoleZero" was declared but never referenced
    "C:\KMotion435b\PC VC Examples\KMotionCNC\Screens\Scripts\ProbeMain.c", line 89: warning: variable "approxYAxisHoleZero" was declared but never referenced

    See attached file. It compiles for me.



    Is there a way to get 2 lines of text in the labels/buttons? Other than using images?
    Not currently


    Nice start on the screen

    Attachment 445930


    On a minor note it sounds a bit demeaning to refer to Compiled C Programs as Scripts
    TK
    http://dynomotion.com

  12. #12
    Join Date
    Dec 2012
    Posts
    390

    Re: Getting variable for scripts

    Hi, Tom.

    Thanks for finding all those errors. Told you there would be more of them... :-)

    I know C is case-sensitive, but sometimes you can't see the forest for all the trees...

    I'll go through this tomorrow and try to do some testing with a pair of wires pretending to be the probe since I haven't received the proper probe yet.

    The screen is a bit crowded right now, so I may split it into external and internal probing.

    Edit: What is the correct way to exit the script/C program when it is currently in a function? Doing a return; would just exit the function, so is it correct to use PC_COMMS_HALT?

    Br,
    Stig

  13. #13
    Join Date
    Dec 2012
    Posts
    390

    Re: Getting variable for scripts

    Hi, Tom.

    I fixed the errors you mentioned, along with a bunch of other woopsies, so now I can get it to compile.

    During testing, it was behaving quite strange. When it was supposed to move only a few millimeters, it often ran out of travel range. I also had to replace MoveRel with MoveRelAtVel because it just took off on some of the moves.I created a short video showing the behavior when trying to probe the right edge on the outside of the stock. The button in the picture is my probe simulator. Something else which is quite strange when doing this test is that suddenly the Y-axis is starting to move when only Z and X should move.
    Link to the video: https://www.dropbox.com/s/w71p1p07s5...33740.mp4?dl=0

    How should the C programs be started from the screen? Program, program/wait or program/wait/sync?

    How should I exit the program when the program is currently inside a function? It seems PC_COMM_HALT doesn't exit the program when the probe is activated during moves. The move just continues when the message box is cleared.

  14. #14
    Join Date
    Dec 2012
    Posts
    390

    Re: Getting variable for scripts

    Made a new probe simulator, which made it easier to do testing (don't mind all the chips...).
    Attachment 446008

    I found why it was moving the Y-axis when it should have moved only X-axis. It was doing what it was told. I had a woopsie in ProbeWest, where I had set it to move Y-axis to reset the probe instead of X-axis.

    I also found why it was moving way further than it was supposed to. Turns out MoveRelAtVel is moving in inches even if the units are set to millimeter. I don't know if that is by design or a "feature"?

    Stig

  15. #15
    Join Date
    May 2006
    Posts
    4043

    Re: Getting variable for scripts

    Hi Stig,

    This looks like a bug. I see two places with:

    while (!ReadBit(PROBEBIT) !=PROBE_ACTIVE);

    instead of:

    while (ReadBit(PROBEBIT) !=PROBE_ACTIVE);


    I also found why it was moving way further than it was supposed to. Turns out MoveRelAtVel is moving in inches even if the units are set to millimeter. I don't know if that is by design or a "feature"?
    MoveRelAtVel moves in counts not inches or mm.

    I think the strategy is wrong.

    I'm assuming the defined distances are in inches. So this:

    #define SAFEZ 1.0f // #122

    defines SAFEZ as 1 inch (regardless of the Interpreter units)

    KMotionCNC will always return zRes in units of counts/inch (regardless of the Interpreter units)

    So this routine:

    Code:
    void MoveUp(double distance)
    {
    	printf("Moving Up by %f\n", distance);
    	MoveRelAtVel(ZAXIS, distance * zRes, MOVESPEED);
    	while (!CheckDone(ZAXIS));
    }
    is expecting the distance to be specified in inches

    This code:

    Code:
    	if (Units == CANON_UNITS_INCHES)
    	{
    		fSAFEZ = SAFEZ;
    		fBUFFERDISTANCE = BUFFERDISTANCE;
    		fPROBEDEPTH = PROBEDEPTH;
    		fDISTANCETOMOVE = DISTANCETOMOVE;
    		fPROBETIPDIAMETER = PROBETIPDIAMETER;
    		printf("Units are Inches");
    	}
    	else
    	{
    		fSAFEZ = SAFEZ * 25.4;
    		fBUFFERDISTANCE = BUFFERDISTANCE * 25.4;
    		fPROBEDEPTH = PROBEDEPTH * 25.4;
    		fDISTANCETOMOVE = DISTANCETOMOVE * 25.4;
    		fPROBETIPDIAMETER = PROBETIPDIAMETER * 25.4;
    		printf("Units are millimeters");
    	}
    then erroneously makes fSAFEZ 25.4 inches instead of 1 inch.

    There are many ways to handle units, but I find simplest to just have all the code work in inches without any conversions at all. The only time conversions are needed are when asking the Operator the Stock Size or something. Or when setting Interpreter offsets the Interpreter Units must be considered,

    HTH
    TK
    http://dynomotion.com

  16. #16
    Join Date
    Dec 2012
    Posts
    390

    Re: Getting variable for scripts

    Hi, Tom.


    Quote Originally Posted by TomKerekes View Post
    This looks like a bug. I see two places with:

    while (!ReadBit(PROBEBIT) !=PROBE_ACTIVE);

    instead of:

    while (ReadBit(PROBEBIT) !=PROBE_ACTIVE);
    There should be some of them, as they are used when detecting the resetting of the probe, but I have fixed several of this type of bugs already. I also had the active state of the probe inverted, so all the (correct) checks were inverted.

    Quote Originally Posted by TomKerekes View Post
    MoveRelAtVel moves in counts not inches or mm.
    That makes sense since the distance was multiplied with the axis resolution

    I have changed it so that all the speeds are in in/min in the defines and then I'll convert them to counts/sec in the program. And all distances are in inches.
    I've also removed all the original f<something> except fPROBETIPDIAMETER and this is only used for printing the stock dimensions when using metric.

    Next version will have the external and internal probing split into two screens and the buttons/pictures are bigger.

    Br,
    Stig

  17. #17
    Join Date
    May 2006
    Posts
    4043

    Re: Getting variable for scripts

    while (!ReadBit(PROBEBIT) !=PROBE_ACTIVE);
    Ahh, Well I think:

    while (ReadBit(PROBEBIT) == PROBE_ACTIVE);

    would be more readable not involving a double negative.
    TK
    http://dynomotion.com

  18. #18
    Join Date
    Dec 2012
    Posts
    390

    Re: Getting variable for scripts

    How is the best way to transfer a bit value from the screen to the C program? I have tried to find something in the documentation, but not really found anything. I've tried to use bit 46 (since this was used in several of the examples), controlled by a ToggleButton, but it looks like it isn't working correctly. Is there any other bit I can safely use?

    How do I exit the C program completely, even if it is currently inside a local function? When I use PC_COMM_HALT as part of the checking if the probe is hitting something while traversing, I get the message box I have set up, but as soon as I have acknowledged it and triggered the probe, the program continues on its merry way until it has finished instead of exiting.

    Br,
    Stig

  19. #19
    Join Date
    May 2006
    Posts
    4043

    Re: Getting variable for scripts

    Hi Stig,

    How is the best way to transfer a bit value from the screen to the C program? I have tried to find something in the documentation, but not really found anything. I've tried to use bit 46 (since this was used in several of the examples), controlled by a ToggleButton, but it looks like it isn't working correctly. Is there any other bit I can safely use?
    Bits 46 and 47 are the KFLOP LEDs which is helpful for debugging. There are also Virtual Bits 48-63 and Extended Virtual Bits 1024-2047.

    Here is a Video:






    How do I exit the C program completely, even if it is currently inside a local function? When I use PC_COMM_HALT as part of the checking if the probe is hitting something while traversing, I get the message box I have set up, but as soon as I have acknowledged it and triggered the probe, the program continues on its merry way until it has finished instead of exiting.
    PC_COMM_HALT tells KMotionCNC on the PC to stop the GCode Interpreter. Here we are running a C Program in KFLOP so there will be no effect.

    The approach I like best is to have each function return an integer success/error code. 0 can indicate success, and non zero can indicate failure and the code can indicate what type of failure occurred if necessary. Although a bit of a pain, it is very flexible and the caller is fully aware of what happened and can handle it however it wishes. ie exit, retry, ask for help, ...

    Here is an example"

    Code:
    #include "KMotionDef.h"
    
    #define error1 FALSE
    #define error2 TRUE
    
    int Sub(void);
    
    void main()
    {
        printf("start\n");
    
        if (Sub()) return;  // call Sub and exit on any error
    
        printf("here\n");
    }
    
    
    int Sub(void)
    {
        if (error1) return 1; // return error code 1
        
        if (error2) return 2; // return error code 2
        
        return 0;  // return success
    }
    TK
    http://dynomotion.com

  20. #20
    Join Date
    Dec 2012
    Posts
    390

    Re: Getting variable for scripts

    Quote Originally Posted by TomKerekes View Post
    Hi Stig,

    Bits 46 and 47 are the KFLOP LEDs which is helpful for debugging. There are also Virtual Bits 48-63 and Extended Virtual Bits 1024-2047.
    Bits 48 - 63 are mapped to the outputs on the first Konnect and Extended Virtual Bits 1024 - 1247 are used for Konnect boards, so they wouldn't work. Are Extended Virtual Bits above 1247 used for anything?

    Br,
    Stig

Page 1 of 3 123

Similar Threads

  1. Assigning post variable to Vbscript variable
    By vfsi in forum BobCad Post Processors
    Replies: 6
    Last Post: 10-18-2016, 01:30 PM
  2. Need help with scripts
    By joewaterjet in forum BobCad-Cam
    Replies: 1
    Last Post: 03-13-2012, 05:24 AM
  3. EMC2 variable pitch / variable diameter threading.
    By samco in forum MetalWork Discussion
    Replies: 0
    Last Post: 03-09-2008, 07:40 PM
  4. Scripts
    By tjones in forum Tutorials
    Replies: 0
    Last Post: 01-25-2006, 07:06 PM
  5. vb scripts
    By HuFlungDung in forum Mastercam
    Replies: 2
    Last Post: 07-08-2003, 05:53 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
  •