525,825 active members*
3,270 visitors online*
Register for free
Login
Page 2 of 2 12
Results 21 to 37 of 37
  1. #21
    Junior Member
    Join Date
    May 2006
    Posts
    3423

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

  2. #22
    Registered
    Join Date
    Dec 2012
    Posts
    358

    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
    Junior Member
    Join Date
    May 2006
    Posts
    3423

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

  4. #24
    Registered
    Join Date
    Dec 2012
    Posts
    358

    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

  5. #25
    Junior Member
    Join Date
    May 2006
    Posts
    3423

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

  6. #26
    Registered
    Join Date
    Dec 2012
    Posts
    358

    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
    Registered
    Join Date
    Dec 2012
    Posts
    358

    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

  8. #28
    Junior Member
    Join Date
    May 2006
    Posts
    3423

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

  9. #29
    Junior Member
    Join Date
    May 2006
    Posts
    3423

    Re: Getting variable for scripts

    Here is a simulation finding Top External Center of Stock.

    TK
    http://dynomotion.com

  10. #30
    Registered
    Join Date
    Dec 2012
    Posts
    358

    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

  11. #31
    Junior Member
    Join Date
    May 2006
    Posts
    3423

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

  12. #32
    Registered
    Join Date
    Dec 2012
    Posts
    358

    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
    Registered
    Join Date
    Dec 2012
    Posts
    358

    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

  14. #34
    Junior Member
    Join Date
    May 2006
    Posts
    3423

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

  15. #35
    Registered
    Join Date
    Dec 2012
    Posts
    358

    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

  16. #36
    Junior Member
    Join Date
    May 2006
    Posts
    3423

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

  17. #37
    Registered
    Join Date
    Dec 2012
    Posts
    358

    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

Page 2 of 2 12

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 General 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
  •