Results 1 to 17 of 17

Thread: Tool change problem

  1. #1
    Join Date
    Feb 2011
    Posts
    19
    Thanks
    0
    Thanked 1 Time in 1 Post

    Default Tool change problem

    Please help me find the reason for this peculiar behaviour of Fanuc controlled machines.

    The program:

    %
    O9023
    G40G80
    M6T#4
    .
    .
    .


    %

    The program O9023 is assigned to command M100 through parameter 6083.

    If the command is executed like this:

    G65 P9023 I12.

    everything is working always on all machines and controls.

    But if the program is executed like this:

    M100 I12.

    on some machines it works smoothly, on other it stops during the M6 procedure. In such case the flag FIN is ON on the screen. Nothing happens even for hours.

    I couldn't find the solution.

  2. #2
    Join Date
    Jan 2012
    Posts
    350
    Thanks
    0
    Thanked 74 Times in 65 Posts

    Default Re: Tool change problem

    Quote Originally Posted by Probe View Post
    Please help me find the reason for this peculiar behaviour of Fanuc controlled machines.

    The program:

    %
    O9023
    G40G80
    M6T#4
    .
    .
    .


    %

    The program O9023 is assigned to command M100 through parameter 6083.

    If the command is executed like this:

    G65 P9023 I12.

    everything is working always on all machines and controls.

    But if the program is executed like this:

    M100 I12.

    on some machines it works smoothly, on other it stops during the M6 procedure. In such case the flag FIN is ON on the screen. Nothing happens even for hours.

    I couldn't find the solution.
    Hi Probe,
    This may not be the case in your application, but I've tracked a few very similar issue to the following, and is about the only reason I can see that will give results like those you have described.

    In one case, G100 was used to call a Macro program to carry out tool length measuring. The Macro call passed a T and S arguments to specify a range of tools to set, or just a T argument to set just one tool. The problem occurred in the Macro program called by G100. In that program the values passed to #19 and #20 were processed in a WHILE / DO loop and used in the following block

    T#19 M6

    and therein was the problem. The machine used M6 to call a tool change Macro program, and because the above block was in a Macro program being called by a G code, the M code was treated as an ordinary M code, not an M code to call a Macro program. The resolve was to include the Macro called my M6, in the Macro program called by G100.

    You may have already thought of this, but it would be worth checking to see if any of the parameters associated with Macro call by M code have a 6 registered, or if bit #6001.5 is set to call a Macro program via T code. Both these scenarios will give you issues if they are executed within a Macro called by a G or M code.

    Regards,

    Bill
    Last edited by angelw; 04-05-12 at 04:57 AM.

  3. #3
    Join Date
    Feb 2011
    Posts
    19
    Thanks
    0
    Thanked 1 Time in 1 Post

    Default Re: Tool change problem

    Hi Bill,
    Look what a coincidence.
    These few lines are in fact part of tool setting program which I wrote . I also tried to cancel the M6 assignment, but the problem remained as it was, when M6 sequence started. What is fascinating, that on some machines it is working, on some not.

    I am not too familiar with Fanuc's ladder troubleshooting. Maybe there is a way to find why when calling the program through M100 FIN is waiting for input, while if calling through G65P9023 is not.

  4. #4
    Join Date
    Jan 2012
    Posts
    350
    Thanks
    0
    Thanked 74 Times in 65 Posts

    Default Re: Tool change problem

    Quote Originally Posted by Probe View Post
    Hi Bill,
    Look what a coincidence.
    These few lines are in fact part of tool setting program which I wrote . I also tried to cancel the M6 assignment, but the problem remained as it was, when M6 sequence started. What is fascinating, that on some machines it is working, on some not.

    I am not too familiar with Fanuc's ladder troubleshooting. Maybe there is a way to find why when calling the program through M100 FIN is waiting for input, while if calling through G65P9023 is not.
    Hi Probe,
    I don't think there is an M FIN for M codes used to call Macro programs. There aren't always M FIN for some conventional M codes either. If you're sure there is no reference to M6 being used to call a Macro, I would check that #6001.5 is not set. This calls program number O9000 via a T code.

    You say that you tried to cancel the M6 assignment. Do you mean by this that their was a Macro program being called by M6. If so, and the assignment is removed, M6 would be treated as a normal M code by a Macro program called by an M code, or by G65P9023. If it were a case of a Tool Change Macro being called by M6, removing the assignment without incorporating the program called by M6 into O9023 will not improve matters.

    You could also try deleting the M100 reference from the parameter, and set a G code to call the Macro to see if the problem still exists with a G code call. If it does, I'd be fairly confident that it has something to do with either the T or M code in the Macro being treated as a normal code, rather than being able to call the Macro, and not that M100 is not finishing.

    You could also try another test by setting a parameter to call a different program number with M100, and write a short Macro program under this new number to exercise the machine in some way. Maybe some short axes moves and include M codes to start/stop the spindle and coolant on/off. If this Macro program works, it would add weight to the argument that is has something to do with the M6 or T code in O9023 when called with an M code.

    Keep in touch. I'd be interested in the resolve.

    Regards,

    Bill
    Last edited by angelw; 04-05-12 at 06:38 AM.

  5. #5
    Join Date
    Feb 2011
    Posts
    19
    Thanks
    0
    Thanked 1 Time in 1 Post

    Default Re: Tool change problem

    Quote Originally Posted by angelw View Post
    Hi Probe,
    I don't think there is an M FIN for M codes used to call Macro programs. There aren't always M FIN for some conventional M codes either. If you're sure there is no reference to M6 being used to call a Macro, I would check that #6001.5 is not set. This calls program number O9000 via a T code.

    You say that you tried to cancel the M6 assignment. Do you mean by this that their was a Macro program being called by M6. If so, and the assignment is removed, M6 would be treated as a normal M code by a Macro program called by an M code, or by G65P9023. If it were a case of a Tool Change Macro being called by M6, removing the assignment without incorporating the program called by M6 into O9023 will not improve matters.



    You could also try deleting the M100 reference from the parameter, and set a G code to call the Macro to see if the problem still exists with a G code call. If it does, I'd be fairly confident that it has something to do with either the T or M code in the Macro being treated as a normal code, rather than being able to call the Macro, and not that M100 is not finishing.

    You could also try another test by setting a parameter to call a different program number with M100, and write a short Macro program under this new number to exercise the machine in some way. Maybe some short axes moves and include M codes to start/stop the spindle and coolant on/off. If this Macro program works, it would add weight to the argument that is has something to do with the M6 or T code in O9023 when called with an M code.

    Keep in touch. I'd be interested in the resolve.

    Regards,

    Bill
    Hi Bill,
    OK, it is working. I couldn't find the reason for this problem, but I found the way to overcome it without jeopardizing the tool changing routine. Here is the revised program:

    %
    O9023
    G40G80
    M98P9001T#4 (INSTEAD OF M6 T#4)
    .
    .
    .


    %

    M6 is assigned to program O9001.

  6. #6
    Join Date
    Jan 2012
    Posts
    350
    Thanks
    0
    Thanked 74 Times in 65 Posts

    Default Re: Tool change problem

    Quote Originally Posted by Probe View Post
    Hi Bill,
    OK, it is working. I couldn't find the reason for this problem, but I found the way to overcome it without jeopardizing the tool changing routine. Here is the revised program:

    %
    O9023
    G40G80
    M98P9001T#4 (INSTEAD OF M6 T#4)
    .
    .
    .


    %

    M6 is assigned to program O9001.
    Hi Probe,
    I'm assuming that O9023 is still being called by M100. That being the case, that's why the program hangs when M6 T#4 was being used. As I suggested in an earlier Post, an M code executed from within a Macro Program that has been called by an M, G, or T code, is treated as a normal M code and can't be used to to call another Macro Program. This would have been the case when executing M6 from within O9023 called by M100.

    If the reference to M6 was removed from the associated parameter, and still used in the program O9023, it will be treated as a normal M code because that's exactly what it is with the reference removed. Accordingly, the program will hang in exactly the same way.

    The T#4 wouldn't be passed to O9001 when using M98P9001, so is this just calling the tool into the Tool Change Ready Position, and in O9001, M06 does the change, or are you using #4120 with M06 in O9001?

    Regards,

    Bill
    Last edited by angelw; 04-10-12 at 08:47 AM.

  7. #7
    Join Date
    Feb 2011
    Posts
    19
    Thanks
    0
    Thanked 1 Time in 1 Post

    Default Re: Tool change problem

    Quote Originally Posted by angelw View Post
    Hi Probe,
    I'm assuming that O9023 is still being called by M100. That being the case, that's why the program hangs when M6 T#4 was being used. As I suggested in an earlier Post, an M code executed from within a Macro Program that has been called by an M, G, or T code, is treated as a normal M code and can't be used to to call another Macro Program. This would have been the case when executing M6 from within O9023 called by M100.

    If the reference to M6 was removed from the associated parameter, and still used in the program O9023, it will be treated as a normal M code because that's exactly what it is with the reference removed. Accordingly, the program will hang in exactly the same way.

    The T#4 wouldn't be passed to O9001 when using M98P9001, so is this just calling the tool into the Tool Change Ready Position, and in O9001, M06 does the change, or are you using #4120 with M06 in O9001?

    Regards,

    Bill
    Hi Bill,
    I used this routine in hundreds of installation of tool setting systems which I performed, majority on Fanuc controlled machines.
    I thought too that using "nested" assigned M calls is the cause of the problem. But the fact is that in some cases it caused problem, and in many others - it worked OK.
    The O9001 performs just the positioning of the machine to tool change position and M6. No tool information is passed to O9001, as it is called by M98. The reason is quite simple: in all my prgrams I am making all effort to stay in the first layer of G65. In the past, when I used probe producer's routines, which quite frequently go 4 layers deep, I found myself in big problem while installing on FMS machines. The program management of FMS itself frequently uses 2 layers of G65 - and problem appears.

  8. #8
    Join Date
    Jan 2012
    Posts
    350
    Thanks
    0
    Thanked 74 Times in 65 Posts

    Default Re: Tool change problem

    Quote Originally Posted by Probe View Post
    Hi Bill,
    I used this routine in hundreds of installation of tool setting systems which I performed, majority on Fanuc controlled machines.
    I thought too that using "nested" assigned M calls is the cause of the problem. But the fact is that in some cases it caused problem, and in many others - it worked OK.
    The O9001 performs just the positioning of the machine to tool change position and M6. No tool information is passed to O9001, as it is called by M98. The reason is quite simple: in all my prgrams I am making all effort to stay in the first layer of G65. In the past, when I used probe producer's routines, which quite frequently go 4 layers deep, I found myself in big problem while installing on FMS machines. The program management of FMS itself frequently uses 2 layers of G65 - and problem appears.
    Hi Probe,
    Iím sure what youíre saying is correct, however, in all Fanuc manuals it states quite clearly that M and G codes are treated as normal codes when used in a Macro Program called by a M, G, or T code. What they state is logical. Take for example a Tool Change Macro Program called with M6. If the M code was not treated as a conventional M code in the Macro Program the M6 that is executed in the Macro Program would call another iteration of the same Macro Program, then again in the next iteration of the Macro Program, and so on.

    Regards,

    Bill

  9. #9
    Join Date
    Mar 2010
    Posts
    166
    Thanks
    0
    Thanked 17 Times in 16 Posts

    Default Re: Tool change problem

    Quote Originally Posted by angelw View Post
    Hi Probe,
    Iím sure what youíre saying is correct, however, in all Fanuc manuals it states quite clearly that M and G codes are treated as normal codes when used in a Macro Program called by a M, G, or T code. What they state is logical. Take for example a Tool Change Macro Program called with M6. If the M code was not treated as a conventional M code in the Macro Program the M6 that is executed in the Macro Program would call another iteration of the same Macro Program, then again in the next iteration of the Macro Program, and so on.

    Regards,

    Bill
    That is right.
    M6, if assigned to 9001, would work differently inside 9023 when 9023 is called by
    (1) G65
    (2) M100.

  10. #10
    Join Date
    Feb 2011
    Posts
    19
    Thanks
    0
    Thanked 1 Time in 1 Post

    Default Re: Tool change problem

    Quote Originally Posted by sinha_nsit View Post
    That is right.
    M6, if assigned to 9001, would work differently inside 9023 when 9023 is called by
    (1) G65
    (2) M100.
    Hi Sinha,
    Just today I rechecked it on YCM and AWEA machines. In both cases M6 is assigned to program O9001.

    On YCM machine with Fanuc 18i control the format

    M100
    .
    .
    M6T#20

    works OK despite "nested" assigned M calls.

    On AWEA machine with same control, it is not working and I have to use the format

    M100
    .
    .
    M98P9001T#20

    Of course the later format works always, but the consistency of Fanuc controls is questionable, isn't it ?

    Anyhow thank you for taking part in this discussion.

  11. #11
    Join Date
    Mar 2010
    Posts
    166
    Thanks
    0
    Thanked 17 Times in 16 Posts

    Default Re: Tool change problem

    Fanuc does have some shortcomings, but its logic is never wrong; at least this has been my experience. I believe there might be some point which you have possibly overlooked. If you post all the programs, exactly as being used, we can look for problems, if any.

  12. #12
    Join Date
    Jan 2012
    Posts
    350
    Thanks
    0
    Thanked 74 Times in 65 Posts

    Default Re: Tool change problem

    Quote Originally Posted by Probe View Post
    Hi Sinha,
    Just today I rechecked it on YCM and AWEA machines. In both cases M6 is assigned to program O9001.

    On YCM machine with Fanuc 18i control the format

    M100
    .
    .
    M6T#20

    works OK despite "nested" assigned M calls.

    On AWEA machine with same control, it is not working and I have to use the format

    M100
    .
    .
    M98P9001T#20

    Of course the later format works always, but the consistency of Fanuc controls is questionable, isn't it ?

    Anyhow thank you for taking part in this discussion.
    Hi Probe,
    The manner in which the Macro behaves with the AWEA machine is conventional and in accordance with all instruction I've encountered in Fanuc Manuals and with Fanuc controls.

    The YCM machine with Fanuc 18i control using the following format and with M6 successfully calling the Tool Change Macro Program O9001, is not conventional. If M6 is not treated as a normal M code in a program called by an M code and is able to call another program, it would be reasonable to expect that M100 would also be able to call another program from within a program called by an M code, M100 perhaps. I can see why this arrangement has been made, its to avoid recursive calls being made. It would be interesting to see what happens if a program containing M100 is called by another assigned M code and also what happens if the program containing M100 is called by M100, and observe how the M100 is treated in the called program.

    M100
    .
    .
    M6T#20


    To get more of a handle on whats actually occurring with the YCM machine, as I believe it is the odd one out, is to assign other conventional M codes such as M08 to call a Sub Program to carry out their conventional function, and have the program containing that assigned M code called by M100. For example:
    1. Assign M100 to call O9023
    2. Assign M08 to call Sub Program O9002
    3. Then register the following programs
    %
    O9023
    M08
    M99
    %

    %
    O9002
    M08
    M99
    %

    4. Execute M100 from a main program and trace to see if the coolant is turned on in O9023, or O9002.

    The other thing that's unusual with the program when used with the YCM machine is that as M6 is assigned to O9001, the program is being called as a Sub Program, not a Macro Program. This being the case, Argument specification is not allowed. How then is T#20 being passed to O9001?

    Tool Change Macro programs are not a requirement on all machines. In most cases they are provided so as to automate the spindle being in the correct position for the tool change to occur, and not much, if anything, more. In many cases M6 need not be assigned to a Macro or Sub Program and can simply be used as a normal M code from wherever to execute a tool change, its highly dependent on the PLC (PMC) program used by the MTB. In this case, it would be the responsibility of the programmer to ensure that commands to home the spindle in Z etc are provided each time a tool change is to occur. You may be more familiar with a Tool Change Macro or Sub Program normally not being used with turning centres. Because there is usually far less going on to complete a lathe tool change, to write the logic into the PLC is easy. But as various proximity switches are involved in the tool change of a Machining Centre, so it is with the Turning Centre. Accordingly, in terms of PLC (PMC) programming, the two are not dissimilar. There is nothing stopping you from writing a Tool Change Macro Program for a lathe to be called with a "T" code, or in fact M6, to ensure that whenever a tool change is commanded, that the turret is move out of harms way. However, in the overwhelming cases, a Tool Change Macro is not required for a lathe, and I think this is the case with your YCM.

    If a "T" argument is being passed when O9023 is being called by M100, and the YCM machine is one where the Tool Change logic is all in the PLC program, I can well imagine that the following program would be successful and the rules specified by Fanuc observed.
    M100
    .
    .
    M6T#20

    In this case M6 would be treated as an ordinary M code in the O9023 called by M100, and the value passed to #20 used to select the correct tool, with a successful tool change being the result. I would not be surprised at all if you were to find that O9001 is not called at all, but that the tool change is executed via the PLC from a normal M6 code executed from within O9023.

    Regards,


    Bill
    Last edited by angelw; 04-21-12 at 02:02 AM.

  13. #13
    Join Date
    Feb 2011
    Posts
    19
    Thanks
    0
    Thanked 1 Time in 1 Post

    Default Re: Tool change problem

    Quote Originally Posted by angelw View Post
    Hi Probe,
    The manner in which the Macro behaves with the AWEA machine is conventional and in accordance with all instruction I've encountered in Fanuc Manuals and with Fanuc controls.

    The YCM machine with Fanuc 18i control using the following format and with M6 successfully calling the Tool Change Macro Program O9001, is not conventional. If M6 is not treated as a normal M code in a program called by an M code and is able to call another program, it would be reasonable to expect that M100 would also be able to call another program from within a program called by an M code, M100 perhaps. I can see why this arrangement has been made, its to avoid recursive calls being made. It would be interesting to see what happens if a program containing M100 is called by another assigned M code and also what happens if the program containing M100 is called by M100, and observe how the M100 is treated in the called program.

    M100
    .
    .
    M6T#20


    To get more of a handle on whats actually occurring with the YCM machine, as I believe it is the odd one out, is to assign other conventional M codes such as M08 to call a Sub Program to carry out their conventional function, and have the program containing that assigned M code called by M100. For example:
    1. Assign M100 to call O9023
    2. Assign M08 to call Sub Program O9002
    3. Then register the following programs
    %
    O9023
    M08
    M99
    %

    %
    O9002
    M08
    M99
    %

    4. Execute M100 from a main program and trace to see if the coolant is turned on in O9023, or O9002.

    The other thing that's unusual with the program when used with the YCM machine is that as M6 is assigned to O9001, the program is being called as a Sub Program, not a Macro Program. This being the case, Argument specification is not allowed. How then is T#20 being passed to O9001?

    Tool Change Macro programs are not a requirement on all machines. In most cases they are provided so as to automate the spindle being in the correct position for the tool change to occur, and not much, if anything, more. In many cases M6 need not be assigned to a Macro or Sub Program and can simply be used as a normal M code from wherever to execute a tool change, its highly dependent on the PLC (PMC) program used by the MTB. In this case, it would be the responsibility of the programmer to ensure that commands to home the spindle in Z etc are provided each time a tool change is to occur. You may be more familiar with a Tool Change Macro or Sub Program normally not being used with turning centres. Because there is usually far less going on to complete a lathe tool change, to write the logic into the PLC is easy. But as various proximity switches are involved in the tool change of a Machining Centre, so it is with the Turning Centre. Accordingly, in terms of PLC (PMC) programming, the two are not dissimilar. There is nothing stopping you from writing a Tool Change Macro Program for a lathe to be called with a "T" code, or in fact M6, to ensure that whenever a tool change is commanded, that the turret is move out of harms way. However, in the overwhelming cases, a Tool Change Macro is not required for a lathe, and I think this is the case with your YCM.

    If a "T" argument is being passed when O9023 is being called by M100, and the YCM machine is one where the Tool Change logic is all in the PLC program, I can well imagine that the following program would be successful and the rules specified by Fanuc observed.
    M100
    .
    .
    M6T#20

    In this case M6 would be treated as an ordinary M code in the O9023 called by M100, and the value passed to #20 used to select the correct tool, with a successful tool change being the result. I would not be surprised at all if you were to find that O9001 is not called at all, but that the tool change is executed via the PLC from a normal M6 code executed from within O9023.

    Regards,


    Bill
    Hi Bill,
    Thank you for your responce. I agree with each and every word. But as an engineer and not theorethical phisicist my approach to problems is pragmatic: if I found working solution which covers all aspects of the problem, I use it. This way I make myself available to solve another problem. And there are plenty of those.

    Here is another example of fenomena to which I have no answer yet.
    This is tool breakage detection routine which i wrote beeing unhappy with probes producer's macros. I call it high speed, as it approaches in rapid to measuring depth, uses radial approach to the setter rather then axial. It is much quicker then conventional macros. Works smoothly on Fanucs, Mazaks and Meldas.

    Here is the program for HAAS:

    %
    O9953(HS BROKEN/LONG TOOL)
    (G65P9953H.05D20.M1F1500)
    (IF H POSITIVE - DETECT BREAKAGE)
    (IF H NEGATIVE - DETECT BREAKAGE AND LONG TOOL)

    G103P1
    (*********************************)
    #14=12.7 (TS DIAMETER)
    #15=1. (TS ORIENT)
    #16=582. (BASE NUMBER)
    (*********************************)
    M5
    IF[#4111EQ0]GOTO5
    IF[#4111NE#0]GOTO10
    N5
    #3000=97(NO H OFFSET)
    N10
    IF[#11NE#0]GOTO12
    #11=-0.5
    N12
    IF[#7NE#0]GOTO14
    #7=30.
    N14
    IF[#9NE#0]GOTO15
    #9=1500
    N15
    G40G80
    G0G91G28Z0
    IF[ABS[#15]EQ1.]GOTO16
    X[#[#16+3]-#5021]Y[#[#16+4]-#5022+#15*[#7/2+#14]/2]
    #1=#5021
    #2=#5022
    GOTO20
    N16
    X[#[#16+3]-#5021+#15*[#7/2+#14]]Y[#[#16+4]-#5022]
    #1=#5021
    #2=#5022
    N20
    Z[#[#16]-ABS[#11]+#[#4111+2000]+#[#4111+2200]-#5023]
    N40
    M79G31X[#[#16+3]-#5021]Y[#[#16+4]-#5022]F#9
    G4P300
    G0X[#1-#5021]Y[#2-#5022]
    IF[#11GT0]GOTO99
    Z-[#11*2]
    (!!!)M78G31X[#[#16+3]-#5021]Y[#[#16+4]-#5022]F#9
    G4P300
    N99
    G0G91G28Z0
    G90
    G103P0
    M99
    %

    If H parameter is positive - everything works OK.
    If H negative, execution of line signed (!!!) is peculiar. Instead of moving the tool to the center of the Tool Setter (in this case 27.7 mm) it moves much shorter distance.
    I rechecked the program many times, recorded the variables, everything looks OK except of the execution.

    Any ideas ?

  14. #14
    Join Date
    Jan 2012
    Posts
    350
    Thanks
    0
    Thanked 74 Times in 65 Posts

    Default Re: Tool change problem

    Quote Originally Posted by Probe View Post
    Hi Bill,
    Thank you for your responce. I agree with each and every word. But as an engineer and not theorethical phisicist my approach to problems is pragmatic: if I found working solution which covers all aspects of the problem, I use it. This way I make myself available to solve another problem. And there are plenty of those.

    Hi Probe,
    I agree with your sentiment. I often use "Work Arounds" simply to achieve a result in a timely manner, but it bugs the heck out of me not to find the cause of an issue. In many cases, there is no resolve other than the Work Around that's been used, but at least I gain an understanding of the cause. I'm a mech engineer, but I write quite a lot of CAM based software and software for automation projects. Accordingly, I spend a lot of time involved with logic.

    The proof of my theory relating to the YCM and with regards to the issue in your previous post, could be made one way or the other by removing the assignment of M6 to a Sub or Macro program and attempt a Tool Change from the main program with the spindle correctly positioned prior to the tool change. If the tool change is successful, then all of the tool change logic is contained in the PLC program, and accordingly, O9001 is not being called from O9023 when its called with M100. That being the case, both the AWEA and the YCM are processing the M codes in the same way.

    With regards to this latest example, I will take a close look at it and come back. However, in the following code, what value do you expect Z-[#11*2] to be? A Minus or a Positive value?

    In the following conditional statement, the program will fall through to N99 if H (#11) is > than Zero (a Positive value). Accordingly, to drop through to Z-[#11*2] #11 must be a negative value, but will be made Positive by the "-" used outside the brackets.

    Regards,

    Bill

    IF[#11GT0]GOTO99
    Z-[#11*2]
    (!!!)M78G31X[#[#16+3]-#5021]Y[#[#16+4]-#5022]F#9
    G4P300
    N99
    G0G91G28Z0
    G90
    G103P0
    M99
    %

  15. #15
    Join Date
    Feb 2011
    Posts
    19
    Thanks
    0
    Thanked 1 Time in 1 Post

    Default Re: Tool change problem

    Quote Originally Posted by angelw View Post
    Hi Probe,
    I agree with your sentiment. I often use "Work Arounds" simply to achieve a result in a timely manner, but it bugs the heck out of me not to find the cause of an issue. In many cases, there is no resolve other than the Work Around that's been used, but at least I gain an understanding of the cause. I'm a mech engineer, but I write quite a lot of CAM based software and software for automation projects. Accordingly, I spend a lot of time involved with logic.

    The proof of my theory relating to the YCM and with regards to the issue in your previous post, could be made one way or the other by removing the assignment of M6 to a Sub or Macro program and attempt a Tool Change from the main program with the spindle correctly positioned prior to the tool change. If the tool change is successful, then all of the tool change logic is contained in the PLC program, and accordingly, O9001 is not being called from O9023 when its called with M100. That being the case, both the AWEA and the YCM are processing the M codes in the same way.

    With regards to this latest example, I will take a close look at it and come back. However, in the following code, what value do you expect Z-[#11*2] to be? A Minus or a Positive value?

    In the following conditional statement, the program will fall through to N99 if H (#11) is > than Zero (a Positive value). Accordingly, to drop through to Z-[#11*2] #11 must be a negative value, but will be made Positive by the "-" used outside the brackets.

    Regards,

    Bill

    IF[#11GT0]GOTO99
    Z-[#11*2]
    (!!!)M78G31X[#[#16+3]-#5021]Y[#[#16+4]-#5022]F#9
    G4P300
    N99
    G0G91G28Z0
    G90
    G103P0
    M99
    %
    Sorry I did not explain the operation of the program. It's task is to check the tool for breakage and optionally for long tool (sometimes tools are pulled out from collet during the machining). If parameter H (tolerance) is positive, tool breakage only is executed. Negative H indicates that both breakage / long tool detection have to be executed. The tool first goes down to the tool seter level minus the tolerance, and if this test is passed successfully, it goes up 2 times the tolerance and long tool test is executed.

  16. #16
    Join Date
    Mar 2010
    Posts
    166
    Thanks
    0
    Thanked 17 Times in 16 Posts

    Default Re: Tool change problem

    Some problem with "instant email notification?"

  17. #17
    Join Date
    Dec 2012
    Posts
    10
    Thanks
    1
    Thanked 0 Times in 0 Posts

    Default Re: Tool change problem

    Any body need CNC help?
    hello
    im daivid; i am a cnc engineer.
    can you mail me your machine parameter.
    i think your parameter have a problem.
    my mail is (maleky.davoud@hotmail.com)

Similar Threads

  1. HAAS TM3P Tool Change Problem
    By 1000yards in forum Machine Repair & Troubleshooting
    Replies: 0
    Last Post: 11-18-11, 09:35 AM
  2. Feeler FTCL Tool change problem
    By rod.dms in forum ALL Other Builders not listed below
    Replies: 3
    Last Post: 09-23-11, 02:43 PM
  3. EC-400 tool change problem
    By WSMITH in forum Haas, Hardinge, Hermle, Hurco, Hitachi
    Replies: 4
    Last Post: 08-09-10, 09:43 PM
  4. mcfv 1260 tool change problem
    By kazzu in forum ALL Other Builders not listed below
    Replies: 0
    Last Post: 05-24-10, 07:11 PM
  5. tool change position
    By eire in forum Programming / Applications
    Replies: 3
    Last Post: 07-25-09, 04:16 AM

Posting Permissions

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