Macro suddenly stopped working - Page 2
Close
Login to Your Account
Page 2 of 2 FirstFirst 12
Results 21 to 30 of 30
  1. #21
    Join Date
    May 2017
    Country
    UNITED STATES
    State/Province
    Minnesota
    Posts
    416
    Post Thanks / Like
    Likes (Given)
    330
    Likes (Received)
    222

    Default

    Could the machine be messing up the macro by using look-ahead?

  2. #22
    Join Date
    Feb 2007
    Location
    Aberdeen, UK
    Posts
    3,081
    Post Thanks / Like
    Likes (Given)
    1087
    Likes (Received)
    1099

    Default

    Yes, after some revision of system variable numbers

    [13980+[#4130*20]]

    appears to be calculating the base variable number for the current G54.1 offset.

    It seems that you are using this to calculate the distance from the work coordinate zero the centre of rotation?

    Do you use any other macros besides this one? Anything that might have been in the process of changing the external work offset when the computer died, and not setting it back?

  3. #23
    Join Date
    Jun 2014
    Location
    United States
    Posts
    31
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    5

    Default

    Yes, this macro takes the base value from the current work offset and takes the value of of the parts true location vs the programmed location and does math while factoring in the current B axis position then updates offset 59, all parts are ran using G59, each face of the tombstone has it's own initial offset that way each face can be dialed in perfectly, since the machine is a 2001 and the rotary axis gears are not wore evenly.
    Yes I use other macros, RENISHAW inspection plus.
    Based on the tool in the spindle, it is possible that the bore inspection cycle may have called up the tool to re run the bearing bore based on the probe result.

  4. #24
    Join Date
    Sep 2010
    Location
    Victoria Australia
    Posts
    3,171
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    1246

    Default

    Quote Originally Posted by meandean77 View Post
    Yes, this macro takes the base value from the current work offset and takes the value of of the parts true location vs the programmed location and does math while factoring in the current B axis position then updates offset 59, all parts are ran using G59, each face of the tombstone has it's own initial offset that way each face can be dialed in perfectly, since the machine is a 2001 and the rotary axis gears are not wore evenly.
    Yes I use other macros, RENISHAW inspection plus.
    Based on the tool in the spindle, it is possible that the bore inspection cycle may have called up the tool to re run the bearing bore based on the probe result.
    Hello meandean77,
    Have you used the Renishaw Inspection Macros before without upsetting your O9010 Macro? This is the risk you run when using Common Nonvolatile Variables unless you are absolutely positive that they are not being used by other Macro Programs. Apart from System Variables, your program uses only Common Nonvolatile Variables, when Local Variables would have worked just as well and without the fear of upsetting other Macro Programs.


    With regards to the suggestion of Program Buffering being a possible cause of your problem, that would only be an issue if the B axis was not stationary before calling your O9010 Macro? If Not Stationary, variable #713 is the only variable in your program that could be affected by program buffering. If Stationary, you can rule buffering out as an issue.

    Regards,

    Bill
    Last edited by angelw; 05-20-2018 at 05:42 AM.

  5. #25
    Join Date
    Feb 2007
    Location
    Aberdeen, UK
    Posts
    3,081
    Post Thanks / Like
    Likes (Given)
    1087
    Likes (Received)
    1099

    Default

    You say that you've checked all the variables are set correctly.

    Have you noted each of them down and done the calculations on paper? Do you get the expected result or the erroneous one? I.e. do you arrive at the same answers as the machine?

    The reason I ask about other macros is if the machine was mid-macro drip-feeding from DNC when the DNC source died, and something was left in an abnormal state in the machine. I'm thinking things that are non-volatile that would not be reset to modal defaults over a restart, like the work offsets.

    Logically it seems that short of any parameters being changed, the machine should not be affected by the DNC source crapping out. Do you any of your macros change parameters on the fly? Something that might have been changed and not been changed back because the program didn't complete?

    If you can guarantee that the macro and the program calling the macro are 100% bit-identical to before the failure, and you can rule out parameters being changed in the machine, the only thing that's left is incorrect data in the machine being used by the macro.

    Try and prove it out with paper, pen, calculator using the extant values in the machine.

  6. Likes Tonytn36 liked this post
  7. #26
    Join Date
    Dec 2007
    Location
    Southeastern US
    Posts
    6,309
    Post Thanks / Like
    Likes (Given)
    794
    Likes (Received)
    2699

    Default

    One other thing to do....

    If this was the program being DNC'd. I would open it in PSPad and check it for erroneous characters in the file. You could have a Japanese or Greek character in your code and it won't show up in a normal windows text editor.

  8. #27
    Join Date
    Sep 2010
    Location
    Victoria Australia
    Posts
    3,171
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    1246

    Default

    Quote Originally Posted by Tonytn36 View Post
    One other thing to do....

    If this was the program being DNC'd. I would open it in PSPad and check it for erroneous characters in the file. You could have a Japanese or Greek character in your code and it won't show up in a normal windows text editor.
    Hello Tony,
    The OP's Macro Program would have to be stored in memory of the control as its program number is O9010 and being called, it seems, by G100. With a Custom G Code set to call the Macro, it would be the same as executing G65 P9010, or if a G Code is not being used, the Call Command would still have to be G65 P9010, if called as a Macro Program. No arguments are being passed, therefore it could/would at least be called as a Subprogram. In all cases, the program would have to be in memory.

    Regards,

    Bill

  9. #28
    Join Date
    Jun 2014
    Location
    United States
    Posts
    31
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    5

    Default

    Thanks everyone for your suggestions.
    My dynamic work offset macro is proven to work with RENISHAW inspection plus. Inspection plus uses #500 series variables for storage of probe set up values and #100 series variables for holding results of probing, my macro uses variables #690 and up, so there is no interference between my macro and inspection plus and this is all proven, I have made hundreds of parts with this combo, wen I first got the probe setup approximately a month I did have to change some of the variables I used in order to be compatible with inspection plus, since then they have been working perfectly together and have made hundreds of parts.

  10. #29
    Join Date
    Jun 2014
    Location
    United States
    Posts
    31
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    5

    Default

    Thanks again to everyone for your help. I figured out the problem. As would seem likely, it was operator error. I changed my postprossor and cam software to be compatible with RENISHAW inspection plus and how I use it. I had reposted the part program but had not changed the cam settings to the new settings so In the calling program or program that makes parts instead of #703=#601, the part program had #703=601, so when the dynamic work offset macro was doing it's thing it was using 601 as the value rather than the value of what was in variable #601. Thanks again for everyone's help.

  11. Likes mhajicek liked this post
  12. #30
    Join Date
    Dec 2007
    Location
    Southeastern US
    Posts
    6,309
    Post Thanks / Like
    Likes (Given)
    794
    Likes (Received)
    2699

    Default

    Quote Originally Posted by angelw View Post
    Hello Tony,
    The OP's Macro Program would have to be stored in memory of the control as its program number is O9010 and being called, it seems, by G100. With a Custom G Code set to call the Macro, it would be the same as executing G65 P9010, or if a G Code is not being used, the Call Command would still have to be G65 P9010, if called as a Macro Program. No arguments are being passed, therefore it could/would at least be called as a Subprogram. In all cases, the program would have to be in memory.

    Regards,

    Bill
    Bill,
    True....but I've seen controls put odd characters in memory programs with power glitches so just tossing that out as a possibility. Never hurts to check. The macro looked fine to me, so had to be some other cause.


Tags for this Thread

Bookmarks

Posting Permissions

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