585,902 active members*
4,624 visitors online*
Register for free
Login
IndustryArena Forum > Machine Controllers Software and Solutions > G-Code Programing > Parametric Programing > Have started losing Arguments at work as well as at home...
Results 1 to 9 of 9
  1. #1
    Join Date
    Aug 2009
    Posts
    684

    Have started losing Arguments at work as well as at home...

    Have been messing around with my Doomsday Macro and have found something peculiar...if I try to pass too many arguments the values start getting mislaid. More specifically, I and J seem to be being ignored/lost and U value ends up where D should be. This seems to occur when I specify 10+ arguments.

    This has had me scratching my head and looking for a problem in the logic, though it did force me to tidy up the program..which is a good thing.

    Thought I had solved the problem by transferring the values to the common variables before doing any calculations - but apparently not. The only way I have found around it is to place the arguments in a specific order (specify I and/or J first) at the macro call. All other arguments go through okay in both cases, even when I specify the maximum 21...

    Wondered if anyone had come across this and knew a) why it happens and b) a way around it? I don't wan't to have to worry about keeping exactly the right format for every combination of arguments.

    (Fanuc 31i)

    DP

  2. #2
    Join Date
    May 2007
    Posts
    1003
    Quote Originally Posted by christinandavid View Post
    Have been messing around with my Doomsday Macro and have found something peculiar...if I try to pass too many arguments the values start getting mislaid. More specifically, I and J seem to be being ignored/lost and U value ends up where D should be. This seems to occur when I specify 10+ arguments.

    This has had me scratching my head and looking for a problem in the logic, though it did force me to tidy up the program..which is a good thing.

    Thought I had solved the problem by transferring the values to the common variables before doing any calculations - but apparently not. The only way I have found around it is to place the arguments in a specific order (specify I and/or J first) at the macro call. All other arguments go through okay in both cases, even when I specify the maximum 21...

    Wondered if anyone had come across this and knew a) why it happens and b) a way around it? I don't wan't to have to worry about keeping exactly the right format for every combination of arguments.

    (Fanuc 31i)

    DP
    I have no idea why U value is winding up in D. However you are on the right track with I and J. My 21i manual says:

    "Addresses do not need to be specified alphabetically. They conform to word address format. I, J, and K need to be specified alphabetically, however."

    Maybe the U and D switch has to to with the "word address format". Make a toll free call to Fanuc. I have to think they could tell you why.

  3. #3
    Join Date
    Feb 2009
    Posts
    22
    I always write local variables to common almost straight away in the sub call.

    The only thing i do 1st is clear all the common variables.

    I tend to always use #700-#800 and run a quick while loop to set these to #0

    At least your be sure it's not picking up any old info

  4. #4
    Join Date
    Aug 2009
    Posts
    684

    Oh, K...

    Quote Originally Posted by g-codeguy View Post
    "Addresses do not need to be specified alphabetically. They conform to word address format. I, J, and K need to be specified alphabetically, however
    Aaaahhh...I'll see what happens if I make sure K is specified after the I & J. That may hopefully eliminate all the conflicts/confusion, regardless of where I, J & K are positioned on the line. I can live with having to remember that rule, I think, and I'll set up the fixed form sentence that way too.

    Will let you know my findings...

    DP

  5. #5
    Join Date
    Feb 2006
    Posts
    1792

    mixed argument specification

    The problem is because of mixed argument specification. This is tricky and not at all explained in the manual. Read my notes for information.
    Attached Files Attached Files

  6. #6
    Join Date
    Aug 2009
    Posts
    684
    Cheers for that - it does seem to explain that if the arguments are not ordered correctly then values start getting assigned to alternate variable nos.

    Putting I J K in correct order definitely solves all the confusion, and its nice to know there is a reason behind it.

    I wonder if anyone uses argument specification type II and if it has any advantages - and I wonder if I could use it to pass more than 21 arguments over - but to be honest, I think its probably best to leave it well alone for the time being!

    Thanks again

    DP

  7. #7
    Join Date
    Feb 2006
    Posts
    1792
    There is no need to use argument specification II unless you want to pass values to more than 21 (up to 33) variables. Type I is better for common applications because you can choose meaningful letters, for example F for feed, S for spindle speed, A for angle, R for R-point level, and so on. Then you do not have to remember what is F, S, A...

    Type II has a very specific use, when you want to pass 3D coordinates of several points. So, it would be (I1 J1 K1) (I2 J2 K2) ..., indicating coordinates of first and second point, respectively. Obviously, type I would be too clumsy here.

  8. #8
    Join Date
    Aug 2009
    Posts
    684
    Right, reading your attachment again it looks like I1 J1 K1 refer to #4 #5 #6. I2 J2 K2 (the ones I had inadvertantly invoked, like an ancient evil) refer to #7 #8 #9. I3 J3 K3 to #10 #11 #12 and I4 J4 K4 to #13 #14 #15. It seems like to use the bonus variables #12-#16 I would have to specify three or more Is Js and Ks, which would have to be used in place of the meaningful letters and would render the argument specification incomprehensible to anyone other than the author of the macro.

    This still doesn't explain why U was ending up in #7.

    I J K and U V W may be interchangeable. Damn. The more I try to reason it the more confused I am getting. Basically the only way Argument Specification II could be used effectively in my application is if it didn't overwrite the variables specified by Argument Specification I...

    No, I'm definitely going to leave it alone.

    DP

  9. #9
    Join Date
    Feb 2006
    Posts
    1792
    It can be explained. Post your G65 block, along with the values that are passed on to the local variables.
    Mixed argument specification tends to be confusing, but it follows a logic.

Similar Threads

  1. Losing home position after powered down overnight
    By MTWOLFEL in forum Mazak, Mitsubishi, Mazatrol
    Replies: 5
    Last Post: 09-03-2008, 06:11 PM
  2. Arguments for Subroutines (G65)
    By theragust in forum Milltronics
    Replies: 5
    Last Post: 10-17-2007, 04:04 PM
  3. losing work coordinates at power off
    By jlong58 in forum Fanuc
    Replies: 13
    Last Post: 07-27-2007, 11:31 AM
  4. Fanuc Servo Amp losing home
    By FanucIssues in forum Fanuc
    Replies: 4
    Last Post: 05-12-2007, 03:07 AM
  5. passing arguments to a sub program
    By kiprip in forum Mazak, Mitsubishi, Mazatrol
    Replies: 1
    Last Post: 07-13-2006, 05:11 PM

Posting Permissions

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