Getting variable for scripts - Page 2


Page 2 of 3 FirstFirst 123 LastLast
Results 21 to 40 of 42

Thread: Getting variable for scripts

  1. #21
    Member TomKerekes's Avatar
    Join Date
    May 2006
    Location
    USA
    Posts
    4042
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Hi Stig,

    I think Konnect normally is configured to use Bits 1024 - 1055 for its 32 inputs. But those above that should all be available unless you are using them for something.

    Regards
    TK http://dynomotion.com


  2. #22
    Member
    Join Date
    Dec 2012
    Location
    Norway
    Posts
    390
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Quote Originally Posted by TomKerekes View Post
    Hi Stig,

    I think Konnect normally is configured to use Bits 1024 - 1055 for its 32 inputs. But those above that should all be available unless you are using them for something.
    Hi, Tom.

    According to your documentation for Konnect, the first Konnect uses bits 48-63 for the outputs and I'm using output 0 (bit 48) for a solenoid, which started clicking when I toggled the bit. This was how I noticed the problem of using bits 40-63. I don't know how many are using more than 1 Konnect, but to make the probe screen as universal as possible, I think it's best to use a bit 1248 or higher.

    I have a button for controlling coolant on the screen. Is there a way to set the variable/bit in a configuration file instead of hardcoding it in the screen file? Since I plan to release the probe screen set and I highly doubt everyone use the same bit as me for the coolant control, it would be beneficial if there was one place to set it instead of having to change it in multiple screen files.

    Br,
    Stig



  3. #23
    Member TomKerekes's Avatar
    Join Date
    May 2006
    Location
    USA
    Posts
    4042
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    According to your documentation for Konnect, the first Konnect uses bits 48-63 for the outputs and I'm using output 0 (bit 48) for a solenoid, which started clicking when I toggled the bit. This was how I noticed the problem of using bits 40-63. I don't know how many are using more than 1 Konnect, but to make the probe screen as universal as possible, I think it's best to use a bit 1248 or higher.
    Yes that is probably a good idea.


    I have a button for controlling coolant on the screen. Is there a way to set the variable/bit in a configuration file instead of hardcoding it in the screen file? Since I plan to release the probe screen set and I highly doubt everyone use the same bit as me for the coolant control, it would be beneficial if there was one place to set it instead of having to change it in multiple screen files.
    We don't currently have a means for configuration files.

    The Screen Editor does have a Copy/Paste function to help with that. Any changes made to controls in one screen file can be copied, then pasted into other screens to update them to match.

    Regards
    TK http://dynomotion.com


  4. #24
    Member
    Join Date
    Dec 2012
    Location
    Norway
    Posts
    390
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Quote Originally Posted by TomKerekes View Post
    The Screen Editor does have a Copy/Paste function to help with that. Any changes made to controls in one screen file can be copied, then pasted into other screens to update them to match.
    Now you tell me...

    Attached is what we can call a beta version of the ProbeScreen. The content of the zip-file should be placed in the same folder as the original screen files. I have only limited possibilities to do full testing until I get the proper probe so there may still be some bugs, but my limited testing hasn't revealed any bugs.

    The probe screen has been split into two screens, external and internal probing. Bottom right button on both screens is for setting Z0. DRO is not reset unless "Reset DRO" has been ticked.

    Some things to be aware of:
    - "Reset DRO" selects if DRO will be set to 0 or not during probing.
    - The blue point shows were to put the probe before starting
    - External Center, CenterHor and CenterVert will move the table the full width/depth of listed stock + 1 inch, so make sure you have enough room. If you don't, move the table close to south and/or west end of stock.
    - If stock is close to max available size of the travel range, instead of using Center, you can use Ext Left/Right/North/South instead and Zero DRO manually and DRO/2
    - Internal probing will not move Z before probing, so set correct probing height first.
    - Speeds are defined in in/min in ProbeMain.c
    - Distances to move are defined in Inch in ProbeMain.c
    - Stock dimensions should be input in the same units as the system is set to (in/mm)
    - The Coolant button is currently operating bit 52 (Output 4 on Konnect). This would need to be changed to suit for all Screen files.

    This is not perfect, but I think it's a good starting point... :-)

    For Tom: I've used "if (some sub()) return;", but it looks like it doesn't stop right away when the probe hit something. It finishes what it was doing before it ends. How can I get it to stop right away? If you look at the Move<somewhere> subs, you'll see how I have tried to get it to stop.

    Isn't it possible to get the ToggleButton to both control a variable(bit) and run a C program? I tried to control bit 1249 with the Coolant button and at the same time run a C program which would check this bit and set or clear the correct bit for the coolant, but the C program wasn't run when clicking the button. If I tried setting the variable to 1249 in the form for selecting Thread and C program, I got the error message that the variable was invalid. The bit 1249 did get toggled by the button when it was selected under Var on the control for the button.

    Br,
    Stig

    Attached Files Attached Files


  5. #25
    Member TomKerekes's Avatar
    Join Date
    May 2006
    Location
    USA
    Posts
    4042
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Hi Stig,

    This is great.

    So far I found a few minor things.

    #1 Coolant bitmaps missing

    #2 Using hard coded axes in places such as: Jog(0,0); instead of Jog(XAXIS,0); in fact I see MoveNorth moves Y but if it hits something it Jog(0,0); which would stop X not Y

    #3 Screen Switch buttons should have the color of the currently selected screen (itself) a different color (orange).

    #4 we might change to this which backs up the directories to get to the C Programs folder to avoid needing a local copy
    #include "..\..\..\..\C Programs\KflopToKMotionCNCFunctions.c"

    I've used "if (some sub()) return;", but it looks like it doesn't stop right away when the probe hit something. It finishes what it was doing before it ends. How can I get it to stop right away? If you look at the Move<somewhere> subs, you'll see how I have tried to get it to stop.
    I think the problem is for example:

    void MoveNorth(double distance)

    has a void return type but is returning an integer. The TI Compiler has better errors and warnings. If you right-click Compile Code (using TI Compiler) it will flag inconsistencies like that

    Isn't it possible to get the ToggleButton to both control a variable(bit) and run a C program? I tried to control bit 1249 with the Coolant button and at the same time run a C program which would check this bit and set or clear the correct bit for the coolant, but the C program wasn't run when clicking the button.
    Right now if a Var is specified for a Toggle Button it doesn't do any associated Button Action. I suppose we could change/fix that.

    btw I created a program to simulate a 3 x 4 x 1 inch stock and a probe for testing if it helps. It activates the probe bit whenever the probe tip would be in. See attached.

    Attached Files Attached Files
    Regards
    TK http://dynomotion.com


  6. #26
    Member
    Join Date
    Dec 2012
    Location
    Norway
    Posts
    390
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Quote Originally Posted by TomKerekes View Post
    #1 Coolant bitmaps missing
    Woops... I had forgotten to copy them over when I made the new images.

    Quote Originally Posted by TomKerekes View Post
    #2 Using hard coded axes in places such as: Jog(0,0); instead of Jog(XAXIS,0); in fact I see MoveNorth moves Y but if it hits something it Jog(0,0); which would stop X not Y
    Another woops. As I said earlier, forrest for all the trees... I had actually mixed X and Y axis for both directions.

    Quote Originally Posted by TomKerekes View Post
    #3 Screen Switch buttons should have the color of the currently selected screen (itself) a different color (orange).
    Fixed.

    Quote Originally Posted by TomKerekes View Post
    #4 we might change to this which backs up the directories to get to the C Programs folder to avoid needing a local copy
    #include "..\..\..\..\C Programs\KflopToKMotionCNCFunctions.c"
    If we keep it like this, it would be much more self-contained and would be easier to put it somewhere else, except it would probably screw up the image location. Is it possible to reference the images relative to the where the script is, similar to the C program?

    Quote Originally Posted by TomKerekes View Post
    I think the problem is for example:

    void MoveNorth(double distance)

    has a void return type but is returning an integer. The TI Compiler has better errors and warnings. If you right-click Compile Code (using TI Compiler) it will flag inconsistencies like that
    Nope. The problem was trying to stop the wrong axis.

    Quote Originally Posted by TomKerekes View Post
    Right now if a Var is specified for a Toggle Button it doesn't do any associated Button Action. I suppose we could change/fix that.
    I think that would be beneficial, not only for this screen set, but also in the future.

    Quote Originally Posted by TomKerekes View Post
    btw I created a program to simulate a 3 x 4 x 1 inch stock and a probe for testing if it helps. It activates the probe bit whenever the probe tip would be in. See attached.
    I followed it to "for (;; )", then you lost me... I'm not a programmer, I'm just able to hack together pieces found here and there... I think x = ch0->Dest / xRes gets the position of X, but I have no idea what fast_fabs(x) does and SetStateBit is used differently from what the help page says it should be used. Not so sure you want to put Z0, which I think is what it does, in the middle of the stock heigth.

    Br,
    Stig



  7. #27
    Member
    Join Date
    Dec 2012
    Location
    Norway
    Posts
    390
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Hi, Tom.

    I've looked over the program and I haven't found any more bugs (found at least one, which was rectified). I think I have managed to include everything now... Still not fully tested since I still haven't received my probe.

    Another thing which would be nice if it could be changed, in addition to being able to set a variable and run a program at the same time, is if images and C programs would be referenced relative to the screen script file. This way it would be easier to share screen sets, or whenever a new version is released. As it is now, everyone would need to keep them in the same location. With my screen set, whenever a new version is released, either the old folder need to be kept or all screen script files need to be updated.

    Br,
    Stig

    Attached Files Attached Files


  8. #28
    Member TomKerekes's Avatar
    Join Date
    May 2006
    Location
    USA
    Posts
    4042
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Hi Stig,

    Thanks for the update!

    if images and C programs would be referenced relative to the screen script file. This way it would be easier to share screen sets, or whenever a new version is released. As it is now, everyone would need to keep them in the same location. With my screen set, whenever a new version is released, either the old folder need to be kept or all screen script files need to be updated.
    We are working on this.

    Regards
    TK http://dynomotion.com


  9. #29
    Member TomKerekes's Avatar
    Join Date
    May 2006
    Location
    USA
    Posts
    4042
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Here is a simulation finding Top External Center of Stock.



    Regards
    TK http://dynomotion.com


  10. #30
    Member
    Join Date
    Dec 2012
    Location
    Norway
    Posts
    390
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    I found a few mistakes in the ProbeScreens. View didn't have the coolant button set correctly (Button instead of ToggleButton) and Int didn't reset the color of the Split-button.

    I updated the ProbeMain code to move to the corner when it's finished when probing any of the corners, also when ResetDRO is not selected, so now it will move to the corner for all corner probings. Earlier it would stop above the edge in the X-axis, but it would be off DISTANCETOMOVE in the Y-axis if ResetDRO was not selected.

    Attached are just the updated files.

    Br,
    Stig

    Attached Files Attached Files


  11. #31
    Member TomKerekes's Avatar
    Join Date
    May 2006
    Location
    USA
    Posts
    4042
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Hi Stig,

    I found some minor bugs and will merge them soon. I also made changes for functions that returns values that are tested by the caller to return int instead of void. I don't think testing a void value will always work.

    Doesn't this code:

    Code:
    void FindOutTopLeft()
    {
    	MoveUp(BUFFERDISTANCE);
    	if (MoveNorth(DISTANCETOMOVE)) return;
    	if (MoveDown(BUFFERDISTANCE + PROBEDEPTH)) return;
    	ProbeSouth();
    	MoveUp(BUFFERDISTANCE + PROBEDEPTH);
    Drag the probe up the edge of the stock? ProbeSouth finishes with the probe at the stock. Then it moves up.

    Actually simulating I found small deviations because of the probing sequence.

    Here is how ProbeSouth finishes:

    Code:
        Jog(YAXIS, -fSLOWSPEEDY);
        printf("Waiting for probe to activate\n");
        while (ReadBit(PROBEBIT) != PROBE_ACTIVE);   		
        printf("Stopping\n");
        Jog(YAXIS, 0);
        printf("Waiting for Y motion to stop\n");
        while (!CheckDone(YAXIS));
    }
    Its moving the probe away from the stock waiting for it to de-activate. Then it does a printf which might delay for a millisecond or so. Then it begins to stop. Then it decelerates to a stop. So the probe is some distance from the stock which varies a small amount based on timings, speeds, acceleration, and jerk. Its a small error but I think we could be more accurate. Maybe you are expecting this to give some clearance to move up?

    I found this to be more exact:


    Code:
        printf("Waiting for probe to activate\n");
        while (ReadBit(PROBEBIT) != PROBE_ACTIVE);   		
        Trig = chan[YAXIS].Dest; // save trigger position
        printf("Stopping\n");
        Jog(YAXIS, 0);
        printf("Waiting for Y motion to stop\n");
        while (!CheckDone(YAXIS));
        printf("Moving Y back to trigger position\n");
        Move(YAXIS, Trig);
        printf("Waiting for Y motion to stop\n");
        while (!CheckDone(YAXIS));
    }
    As soon as the Probe deactivates it captures the commanded Destination into "Trig" then stops and moves back to where it triggered.

    What do you think?

    Regards
    TK http://dynomotion.com


  12. #32
    Member
    Join Date
    Dec 2012
    Location
    Norway
    Posts
    390
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Quote Originally Posted by TomKerekes View Post
    I found this to be more exact:


    Code:
        printf("Waiting for probe to activate\n");
        while (ReadBit(PROBEBIT) != PROBE_ACTIVE);   
        Trig = chan[YAXIS].Dest; // save trigger position
        printf("Stopping\n");
        Jog(YAXIS, 0);
        printf("Waiting for Y motion to stop\n");
        while (!CheckDone(YAXIS));
        printf("Moving Y back to trigger position\n");
        Move(YAXIS, Trig);
        printf("Waiting for Y motion to stop\n");
        while (!CheckDone(YAXIS));
    }
    As soon as the Probe deactivates it captures the commanded Destination into "Trig" then stops and moves back to where it triggered.

    What do you think?
    Hi, Tom

    It'll probably drag on the side of the stock. I don't know how much of an effect it will have on the tip, though. I was just following what others have done before me. Moving just a touch off the stock before moving up would probably be a good idea. All these printf are probably not needed in the finished version, in my view, they're more for troubleshooting and verification of the code. Your idea of saving the trigger position could be incorporated fairly easy. I don't know how much the likely position error would be in my original version, since the final probing is done quite slow.

    Br,
    Stig



  13. #33
    Member
    Join Date
    Dec 2012
    Location
    Norway
    Posts
    390
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Hi, Tom.

    In a previous post, you mentioned it wasn't quite kosher to use void when returning a value. I guess I should have used int MoveNorth(double distance) instead of void MoveNorth(double distance)? Since that's what I believe is what you meant, I have changed most of the functions to account for this.

    I also incorporated your suggestion to record the trigger point and also to move slightly off the stock before raising the probe, but due to testing if the probe is hitting something during moves, I had to update the MoveXXXXX functions to also turn off the checking when moving away from the stock as the probe was already activated when moving away from the stock.

    I found that I had a slightly wrong name on the programs for the 3 bottom external probe routines, so they are included in the attached, updated ProbeMain.

    Initial testing doesn't show any new introduced bugs, but that's not to say there aren't any. I hope to receive my new probe some time the coming week. This will make it a lot easier to do proper testing.

    Now we just need to be able to set a variable and run a script, and relative addressing of programs and images...

    Br,
    Stig

    Attached Files Attached Files


  14. #34
    Member TomKerekes's Avatar
    Join Date
    May 2006
    Location
    USA
    Posts
    4042
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Hi Stig,

    In a previous post, you mentioned it wasn't quite kosher to use void when returning a value. I guess I should have used int MoveNorth(double distance) instead of void MoveNorth(double distance)? Since that's what I believe is what you meant, I have changed most of the functions to account for this.
    Yes good. But many error returns still aren't specifying a value to return. So the returned value will be indeterminate. Basically most all "return;" should be "return 1;". If you compile with the TI Compiler it will flag those as errors.

    Not sure why the error checking in GetStockSize was removed.

    MoveUp() isn't returning a 0 value at the end.

    It would be good to make the 0.05 offset a #defined value.

    The file is getting pretty big and is now greater than the Thread spaces 1-6 without overflowing into the next Thread. Removing all the debug prints will probably reduce it a lot. We could have been smarter and made the probe routine more general to be able to probe in any direction. This would have been smaller and eliminated so much duplicated code. It would reduce the chances of bugs as well at the expense of somewhat more complex code.

    Still working on your requests

    Thanks again.

    Regards
    TK http://dynomotion.com


  15. #35
    Member
    Join Date
    Dec 2012
    Location
    Norway
    Posts
    390
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Quote Originally Posted by TomKerekes View Post
    Not sure why the error checking in GetStockSize was removed.
    There is no movement in GetStockSize, so shouldn't be any other error checking than if there is a problem getting the values from the screen.

    Quote Originally Posted by TomKerekes View Post
    MoveUp() isn't returning a 0 value at the end.

    It would be good to make the 0.05 offset a #defined value.
    Fixed

    Quote Originally Posted by TomKerekes View Post
    The file is getting pretty big and is now greater than the Thread spaces 1-6 without overflowing into the next Thread. Removing all the debug prints will probably reduce it a lot. We could have been smarter and made the probe routine more general to be able to probe in any direction. This would have been smaller and eliminated so much duplicated code. It would reduce the chances of bugs as well at the expense of somewhat more complex code.
    Agree. It's getting a bit unwieldy, but as you've probably understood already (or I have said it earlier), I'm not a programmer...
    I have made an attempt at reducing the size. Both the actual probing and moving have now been moved into a single function for each instead of a function for each direction. This makes it a bit more difficult to understand and troubleshoot, though. Another option to reduce the size more, is to split the file into two different files, one for external probing and one for internal probing. Or move everything from the switch/case into each calling program, keep the definitions, MoveDirection and Probe functions still in the main file..

    Br,
    Stig

    Attached Files Attached Files


  16. #36
    Member TomKerekes's Avatar
    Join Date
    May 2006
    Location
    USA
    Posts
    4042
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Hi Stig,

    There were still a number of return void vs int mix ups, mainly in main(). I fixed those.

    Also set a ToUserUnits factor that is either 1 or 25.4 to avoid checking Units multiple places.

    This brought it 300 bytes under the 65,536 byte limit



    I'm not a programmer...
    I think you are

    Attached Files Attached Files
    Regards
    TK http://dynomotion.com


  17. #37
    Member
    Join Date
    Dec 2012
    Location
    Norway
    Posts
    390
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Quote Originally Posted by TomKerekes View Post
    There were still a number of return void vs int mix ups, mainly in main(). I fixed those.
    Thanks.

    Quote Originally Posted by TomKerekes View Post
    Also set a ToUserUnits factor that is either 1 or 25.4 to avoid checking Units multiple places.
    Good call! Sometimes the most obvious things are the hardest to see... Your change in the MoveDirection routine will cause it to print that the distance to move is mm, even if the units are inches, though.

    A couple of other things...
    Currently, for external center probings, it will move the claimed width or depth of the stock plus DISTANCETOMOVE to make sure that the probe will go outside the stock no matter where the probe was positioned before starting the probe routine, as long as it was over the stock. If the probe is close to east side or north side of stock, it will move about stock width or depth of stock outside of the actual stock, which can cause problems with travel range. Maybe it's better to require the probe to be positioned close to center of stock before starting the probe routine and only move half of stock width or depth plus DISTANCETOMOVE to prevent running out of travel?

    I received my new Drewtronic probe today, but when I wired it up and tested, the input bit didn't change when the probe was activated. How little current is needed to trigger the opto on the Konnect? The probe has a LED with a 10k resistor in parallel with the contact, so there will be a current going through the LED of about 2.something mA when the contacts open. I guess this is too much for the opto and it will not turn off? Instead of opening the probe to disconnect the LED, I can just reverse the leads in one of the connectors.
    Edit: Swapped the leads in one of the connectors and now it's working as it should (minus lighting up the LED when it activates).

    Br,
    Stig

    Last edited by Stigoe; 08-04-2020 at 08:34 AM.


  18. #38
    Member
    Join Date
    Dec 2012
    Location
    Norway
    Posts
    390
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Took some time to make an adapter for my new probe. It came with 3/8" shank (TTS version was $80 more expensive). I was going for a shrink fit, but it ended up with a superglue fit...

    Quote Originally Posted by TomKerekes View Post
    Not sure why the error checking in GetStockSize was removed.
    Quote Originally Posted by Stigoe View Post
    There is no movement in GetStockSize, so shouldn't be any other error checking than if there is a problem getting the values from the screen.
    Which was not a good call on my part... Found during testing that, when I had forgotten to input stock values when doing center probing, the system only moved DISTANCETOMOVE before lowering the probe, so the error checking of stock values are back.

    I also found that all right bottom corner probings would call left bottom corner instead, so the program called when doing right bottom corner has been updated to the correct program. In addition, the debug text was inverted when it came to Reset DRO. This has also been fixed.

    When doing Find_Z, the probe would stop right at the top of stock. I have now changed it to raise to SAFEZ.

    Still need to decide on how much to move when doing centers. The full stock width/depth plus some extra with the risk of running out of travel or require the starting position to be close to center of stock and travel only half the stock width/depth plus some extra. What are other peoples opinion?

    To check how big the program is, is it correct to copy the content from one of the calling programs into KMotion.exe -> C program and hit Compile? If so, I got a total of this current version of 65456. Is that the correct size of the program as it is now? If so, I guess removing a bunch of the debug printf's would get it down under 64k.

    I have tested all outer probing and the internal edges, but no corners or centers. I'll leave for work on Friday, so I won't have the chance to do any more testing until I'm back home in about 2 months time.

    Br,
    Stig

    Attached Files Attached Files


  19. #39
    Member TomKerekes's Avatar
    Join Date
    May 2006
    Location
    USA
    Posts
    4042
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Hi Stig,

    Quote Originally Posted by Stigoe View Post
    There is no movement in GetStockSize, so shouldn't be any other error checking than if there is a problem getting the values from the screen.
    Which was not a good call on my part... Found during testing that, when I had forgotten to input stock values when doing center probing, the system only moved DISTANCETOMOVE before lowering the probe, so the error checking of stock values are back.
    Yes I had put that back in also

    I made a number of changes also. I made some routines more general sort of table driven.

    A feature for C Program Actions to pass a code was also added (another thing you asked for). This allows a single ProbeMain routine to be used.

    Getting variable for scripts-param-png

    We can cherry pick the changes at some point.


    Still need to decide on how much to move when doing centers. The full stock width/depth plus some extra with the risk of running out of travel or require the starting position to be close to center of stock and travel only half the stock width/depth plus some extra. What are other peoples opinion?
    My preference would be to position the probe within 1 inch of the left or bottom.

    Question: Why do the "Internal Probes" not FindZ in a similar manner to the "External Probes"? And the couldn't finding say the Left Side of a Stock be exactly the same as finding the right side of a pocket?


    To check how big the program is, is it correct to copy the content from one of the calling programs into KMotion.exe -> C program and hit Compile? If so, I got a total of this current version of 65456. Is that the correct size of the program as it is now? If so, I guess removing a bunch of the debug printf's would get it down under 64k.
    Yest the Total should be less than 64K. My Version is somewhat smaller. Actually "64K" is 2^16 = 65536 so you are just ok.


    I'll leave for work on Friday, so I won't have the chance to do any more testing until I'm back home in about 2 months time.
    Sorry for our delays, but the changes took longer than expected. We hope to come out with a release soon with the Relative Paths, Toggle button with Script Actions, Button Code Parameters, and a number of other updates, fixes, and features. I'll attach the ProbeMain.c program in case you are interested although it only will work with the new version with all the updates. Have a good trip.

    Attached Files Attached Files
    Regards
    TK http://dynomotion.com


  20. #40
    Member
    Join Date
    Dec 2012
    Location
    Norway
    Posts
    390
    Downloads
    0
    Uploads
    0

    Default Re: Getting variable for scripts

    Quote Originally Posted by TomKerekes View Post
    Yes I had put that back in also

    I made a number of changes also. I made some routines more general sort of table driven.

    A feature for C Program Actions to pass a code was also added (another thing you asked for). This allows a single ProbeMain routine to be used.
    Good, but when you start with struct and pointers, it starts to throw me. I can sort of follow it after looking it over a few times, but I'm not sure I can expand it much. You still had the inversed ResetDRO check at the start of the program (just after finding the axis resolution), which I fixed yesterday.

    Quote Originally Posted by TomKerekes View Post
    My preference would be to position the probe within 1 inch of the left or bottom.
    Then the drawings for these buttons should be changed to better reflect this. I'll try to do this today.

    Quote Originally Posted by TomKerekes View Post
    Question: Why do the "Internal Probes" not FindZ in a similar manner to the "External Probes"? And the couldn't finding say the Left Side of a Stock be exactly the same as finding the right side of a pocket?
    I was trying to use the same routine for both, but my thinking is that if you do internal probing, you don't necessary know where top of stock is. If you uncheck ResetDRO, it would be possible to do a Find_Z before probing internal (in case you want to probe an internal feature which is lower than Z0), but then it wouldn't reset DRO to center or edges when it is finished probing. It would only be a couple of extra button presses, though. For the corners, it would move 2x DISTANCETOMOVE when doing E/W probing. This may or may not be a problem. It could also be that you want to probe small, internal features or it may have multiple depths, where finding Z first would not work. Difficult to cater for every conceivable scenario, though.

    Quote Originally Posted by TomKerekes View Post
    Yest the Total should be less than 64K. My Version is somewhat smaller. Actually "64K" is 2^16 = 65536 so you are just ok.
    Yes, I know, but I wasn't thinking straight, it was getting late and I was a bit in a hurry to finish the post...

    Quote Originally Posted by TomKerekes View Post
    Have a good trip.
    Thanks!

    Br,
    Stig



Page 2 of 3 FirstFirst 123 LastLast

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
  •  


About CNCzone.com

    We are the largest and most active discussion forum for manufacturing industry. The site is 100% free to join and use, so join today!

Follow us on


Our Brands

Getting variable for scripts

Getting variable for scripts