Tool change M6 problem Fanuc OM

[Dustydude]

Hi Bill,

Thanks I will update the parameters, create the o9000 and update the o9001 as you have suggested.
If that works can I bend your ear on the error trapping as I have no idea on that.
Learning all the time
What a great community there is here.
I will let you know how I get on
Best regards
Dusty

 

[Vancbiker]

……..Your current O9001 program could be improved by including error trapping for no tool number being specified and to check that for the tool number specified being with the range of 1 through 10.
Regards,

Bill

Short term, checking for tools outside the range 1-10 is probably good.

Some machines, even with the drum type toolchange have a data table where tool numbers are assigned to drum position. Then if one is using a tool library in CAM, the library number can be set to the drum position. In the case of Mori, that data can be set manually or programmatically. This feature may or may not be available on the OP’s machine, but if it has similar it may be something to consider using in future.

 

[angelw]

Hello Dusty,
The potential issue if you were to inadvertently omit a Tool Call before executing program O9001 with M6, will actually exist at any time when the Variable representing the Tool Number retains the Tool Number after the Tool Change has been executed. Therefore, it would be a good tactic to initialize #100 to Zero before exiting the O9001 program. Accordingly, following on with my suggestion to use the Volatile Common Variable #!00 instead of the Non-volatile #500 Common Variable, add the following Block to just before the M99 Block of program O9001.

G65 H01 P#100 Q0 (INITIALIZE #100 AFTER USE)

Even without error trapping in your program O9001, the following Block in O9001 should raise an error and halt your program, if a "T" Code was omitted in your Main Program, before M6 is executed.

T#100 M06

Regards,

Bill

 

[Dustydude]

Hi Bill
I created the new o9000 and modified the o9001 all fine
But when I updated pwe to 1 to allow me to edit the 40 I got an alarm so I put it back to zero.
The alarm would not reset so I thought best to check back with the guru

 

[dandrummerman21]

That alarm means parameter write enable (PWE) is a 1. That is normal.

You can make the alarm temporarily go away by hitting RESET and CANCEL at the same time. If you restart the machine, the alarm would come back if PWE was still on.

You can change parameter 40 while the machine is in the alarm state with that alarm.

 

[Dustydude]

Thanks

 

[13engines]

A little extra to add to what dandrummerman21 said. Another common Alarm you're likely to run into when changing Parameters is Alarm 000 - Please Turn Off The Power. If you change a Parameter and set PWE back to 0, Reset will most likely clear that Alarm. If after Reset you still have an Alarm present, it will probably be 000. Turning the Control Power off and on at the Control Panel is usually enough. If not you'll also have to turn off the Main Power Switch.

It all seems pretty obvious, but the fact that 100 thru the OP for a little loop, I figured to explain the obvious. When you're a newb like we've all been at one time, even hearing the obvious breeds more confidence that you're not going to screw things up.

PS. Can't recall if the control really says "Please." :-)

 

[Dustydude]

Hi Bill and all.
OK a bit of progress but not there yet.
Created the o9000
Modified the o9001
Changed the parameter
Program made to do a tool change
Images attached.
There could be a problem with my syntax but this is the outcome.

When I run my o0006 program that calls up T0# M06the tool unloads but then carousel just indexes and doesn't stop like a merry go round

I have to e stop out thats a right pain as it stops mud position and messes up a few things.

Any ideas?

Dusty

 

[angelw]

Hello Dusty,
The syntax for the Macro Statements used in your programs looks OK, but the position of
G65 H01 P#502 Q#100
after N100 has the potential of causing an issue if #100 has a wrong value, whilst you have no error trapping in the program. Swap it around so that G65 H01 P#502 Q#100 is immediately before the N100 Block

As a Test:
In your Main program, where the Tool Change is called, change what you currently have,
T_ _ M6
S1000 M3
G4 P5
M30

to the following:

T_ _
G65 H01 P#500 Q#100
M30
%
Where _ _ is a different number between 1 and 10, each time you execute the program.

After each execution of the program, view the value of Variable #500 in the Macro Variable pages. You navigate to those pages via the Offset Button. On each execution of the program, with a different Tool Number each time, #500 should contain the value of the specified Tool Number. This exercise is to ensure that program O9000 is working correctly.

The reason for recording the Tool Number in #500 and not just view #100, is that M30 is usually linked to Reset and depending on parameter setting, #100 will be initialized to Zero when Reset is executed. Variable #500 won't be reset and therefore, you can see that the correct Tool Numbers are being registered in #100 when program O9000 is executed.

If #100 is being allocated the correct value (as confirmed by viewing the value of #500), edit your Main Program to include M06 after the "T" address, so that Program O9001 will be executed.

Again, as a test, in your O9001 program, insert M00 as the first Block of the Program. When O9001 is called via M06, the program will halt when the M00 is executed. When it does, view the value of #100 in the Macro Variable pages to ensure that it still has the correct value. If it doesn't, I'd expect the value to be Zero and in which case, change the configuration of your Main Program to have the Tool Call (T Code) and M06 on separate lines as in:
T_ _
M06

Report back as to the result.

If the above works, you then have two choices. You can either leave as is with the two programs being executed via the "T" code and M06, or copy the content of program O9001 to program O9000 and include the following Block at the start of the program:
G65 H01 P#100 Q#149
You would then change the value in Parameter 240, from 6 to 0, so that program O9001 is no longer called by M06. Your Tool Change Call in the Main Program will now be called by executing only a "T" code and omitting M06.

Initially, you wouldn't have to change the value in parameter 240, as the M06 in the Tool Change Macro won't call O9001 but will be treated as a normal "M" code and processed by the PMC.

Regards,

Bill

 

[Dustydude]

Hi Bill
Thanks so much. We are successful.
Nevertheless not exactly the same as your instructions but maybe a typo
You ask to check 500 and 100 matches the tool number which it does but you also first mention 502.
502 always says 8
For your instruction to add M00 and check the 100 this worked but only with T# and M06 on different lines in my main program.

I would prefer to have them on the same line but I guess thats not possible?

I'm going to be using fusion 360 so I'm not sure how that would impact the post. In fact I'm not even sure which post I should select but thats another forum post I guess and I need to search first as it may be answered already for OM
Can't thank you all enough
Dusty

 

[Dustydude]

Hi Bill. I think I took a print of your instructions and then they were updated so that sorts out the 502 I mentioned.

 

[angelw]

For your instruction to add M00 and check the 100 this worked but only with T# and M06 on different lines in my main program.

I would prefer to have them on the same line but I guess thats not possible?

Hello Dust,
I expected that to be the case; the reason is that the Subprogram being called by M06 is being called before the Subprogram called by the "T" Code has been executed.

With the type of Tool Changer on your machine, where the Spindle Tool can only be put back in the Pocket Number in the Magazine from whence it came, there is no necessity for a Tool Change Program to be called with "M06". Therefore, you could do as I suggested in my previous Post and copy the content of program O9001 to program O9000 and include the following Block at the start of the program:

G65 H01 P#100 Q#149

The M06 in the Tool Change Program is still required, but because it exists in a program that is called by a "T" Code, it will be treated as a normal "M" Code and it won't call the O9001 program.

If you go this way, when making a Tool Change in the Main Program, you only have to specify a "T" Code.

I'm going to be using fusion 360 so I'm not sure how that would impact the post. In fact I'm not even sure which post I should select but thats another forum post I guess and I need to search first as it may be answered already for OM

If the Posts supplied don't suit exactly, simply modify the Post. A Post Processor for CAM Software is to custom fit the output to the various machines that the Software is used to create programs for; you don't have to modify what is correct for your machine to fall into line with what's offered with the CAM Software.

Regards,

Bill

 

[Mechanola]

Give every block an N0000. Control has to digest a little more stuff. That sometimes prevents it from hopping over too short blocks. My experience with FANUC

 

[angelw]

Give every block an N0000. Control has to digest a little more stuff. That sometimes prevents it from hopping over too short blocks. My experience with FANUC

With respect, that strategy is hit and miss, depending on the processing speed of the particular control. Variable #100 is processed only 4 Blocks into the O9001 program, so I doubt Sequence Numbers will help at all. When creating a delay in a program, a method that gives consistent, predictable results should be used. Using a dwell is not the best idea either, as that's hit and miss when first establishing the value to use and any mods to the program in the future may have an effect on the dwell required.

However, I don't think it would work in any regard, because you would be relying on the Control being able to Multi Task and that's not possible. Using Interrupts is about as close as you would get to Multi Tasking and that's not happening here.

A method that would work, if Multi Tasking were possible and would hold the O9001 program up for exactly the right amount of time, would be to create a Loop with a Conditional Statement. The Condition to stay in the Loop would be for the value of #100 to be equal to Zero. In this way, program O9001 would idle in the Loop until a value was allocated to #100 in program O9000. But then another issue is introduced. What if a value of Zero was inadvertently specified for "T" in the Main Program? In this case, a unique number could be allocated to #100 in Program O9000. For example, if Zero was inadvertently specified in the Main Program, a unique number such as "999" could be allocated. That would allow an exit from the Loop in O9001 and an Error Trap used to deal with #100 equaling "999", that is, Tool Number out of range, or Tool Number Omitted (999 is allocated when #149 is Zero). But that's all hypothetical without Multi Tasking.

Regards,

Bill

 

[Mechanola]

With respect, that strategy is hit and miss

I wrote experience, not strategy. I have learnt ISO programming in this country from the base up, the N belongs to each and every block. Admittedly, I had to use older FANUC controls, some from the 1980s.

 

[angelw]

I wrote experience, not strategy. I have learnt ISO programming in this country from the base up, the N belongs to each and every block. Admittedly, I had to use older FANUC controls, some from the 1980s.

This is not quite my first rodeo either.

In your previous Post, you were advising the OP to:
Give every block an N0000. Control has to digest a little more stuff.That sometimes prevents it from hopping over too short blocks.
It's a strategy when a method of operation is being suggested.

How short a Block do you want? Will the following do?

T1
M6
T5
These are three blocks that can't be any shorter and is a very typical format when programming a Machining Centre where the next tool can be pre-staged. I've never seen a machine that can use that format, that couldn't process that example code due to the code being too short. That's simply not the way CNC control systems are designed to operate. As long as the Syntax of the Address and the Block is correct, there is no such thing as too short a Block.

Its a strategy if you're using it to keep the control occupied for a period. I'm saying that its a poor strategy to use a fudge because the results can be wildly variable. If you simply want to hold the control up for a set time, use a Dwell Command. If you want to hold the control up for the occurrence of an event, use a Loop controlled by a Conditional Statement. To use sequence numbers to bog the control down to allow an event to happen is just simply Hit and Miss and an extraordinary number would have to be used to make a significant difference.

If you're saying that N (sequence numbers) should be used on each and every line, or must be used on each and every line, that is totally incorrect. For the most part, sequence numbers on every line simply consume memory, they are generally not required for the successful operation of the machine.

I only apply a Sequence Number at the start of every different tool operation, plus area where sequence numbers are required for the operation of a cycle, a lathe G71 roughing cycle for example, and I advise my clients to do the same. It is extraordinarily uncommon for a program having numerous tools involved, for those tools to be numbered sequentially to match their occurrence in the program; T1 for the first operation, T2 for the second operation and so on. If an operation has to be repeated, or the program restarted from a particular operation, in my opinion, its more likely for an operator to be able to remember the operation sequence, than the tool number for a particular operation, Tool Number 21 for the 3rd operation, or simply the 3rd operation. Therefore, if I have to start the program from the 5th operation, I know that all I have to do is search for N5 and the cursor will be at exactly the right point to restart the program at the 5th operation. I don't have to remember the Tool Number used in the 5th operation and then search for that tool. If you have Sequence Numbers on each Block, finding the correct Sequence Number to start from is not as simple and a lot of memory has been consumed for zero gain.

 

[Vancbiker]

I wrote experience, not strategy. I have learnt ISO programming in this country from the base up, the N belongs to each and every block. Admittedly, I had to use older FANUC controls, some from the 1980s.

While having an N address on each line was extremely handy on old controls without a CRT display it was not required. Finding a line number when the display is only a single line was quite helpful to have an N address. As CRT displays came into prominence by the early 80s the usefulness of an N on each line disappeared. Most folks now only use an N address to indicate the beginning of a new operation, tool, or safe restart point.

 

[Mechanola]

T1
M6
T5
I've never seen a machine that can use that format, that couldn't process that example code due to the code being too short.

It is too short, it lacks the semicolons that close every block. Entailed automatically nowadays. Of course are you right that numerals aren’t necessary for the functioning of a CNC setup. I say should in view of help to the problem posted. I am certain that controls take a little time only to sort out activating code from auxiliary stuff.

In 2020 I had three crashes with a two-spindle, two-turret center where the counter spindle raced into the butterfly turret. Code was correct, turret move was not read. Boss angry, to add numerals was my only idea and still is. Nobody in the shop has ever found out why it happened but I lost the job.

 

[angelw]

It is too short, it lacks the semicolons that close every block. Entailed automatically nowadays. Of course are you right that numerals aren’t necessary for the functioning of a CNC setup. I say should in view of help to the problem posted. I am certain that controls take a little time only to sort out activating code from auxiliary stuff.

In 2020 I had three crashes with a two-spindle, two-turret center where the counter spindle raced into the butterfly turret. Code was correct, turret move was not read. Boss angry, to add numerals was my only idea and still is. Nobody in the shop has ever found out why it happened but I lost the job.

Most informed members of this Forum accept that code listed as example has an EOB without specifically listing it.

The following picture is a screen capture of an Editor/Comms application, showing the program exactly how it was opened; you will note that no EOB symbols are displayed. Typically when creating a program with Editor Software (any Text Editor can be used to create the file) a Carriage Return (CR - Ascii 13) and Line Feed (LF - Ascii 10) are used to terminate the line and advance to the next block. Both of these character are known as Control Characters and either one can be recognized as an EOB, but their symbols look nothing like what you see as an EOB on the program display of Fanuc and many other controls.



Fanuc use, and it can be set via parameter, either "*". or ";" characters as a representation of EOB in their program display. Neither of these characters are actual symbols of Ascii 10 or 13. Accordingly, my following listing from my previous Post
T1
M6
T5
is entirely correct, except for the pedantic few, who are actually ill-informed.

I say should in view of help to the problem posted. I am certain that controls take a little time only to sort out activating code from auxiliary stuff.

The only time Sequence Numbers account for any time is when a Sequence Number is searched for in a program, test it for yourself in the following method:
1. Set System Variable #3001 (#3012 for the OP's control) to Zero at the head of a long program such as, say, 500 blocks, with each block containing only G04 (no time delay). When G04 is programmed by itself, it has the same function as G09 (Exact Stop).
2. At the end of the program, read the value of the #3001 into a Variable that won't be set to Null when M30 is executed. Note down the time.
3. Now add a Sequence Number to each of the 500 blocks and repeat the test.

If you had bothered to look at the OP's O9001 program, you would have noticed that Variable #100 is accessed only 7 blocks in from the start of the program. That gives you only seven opportunities to add sequence numbers to the focus program. Further, as I stated in an earlier Post, for this to even be possible to work, the control would have to be capable of Multi Tasking (more than one program running at the one time); that is just not possible.

In 2020 I had three crashes with a two-spindle, two-turret center where the counter spindle raced into the butterfly turret. Code was correct, turret move was not read. Boss angry, to add numerals was my only idea and still is. Nobody in the shop has ever found out why it happened but I lost the job.

I'm calling BS on that. There is no way that the omission of sequence numbers was the cause of that situation, unless there was some process in the program where a specific Sequence Number was required, in a branch execution for example. In that case it would be program error.

 

[Mechanola]

I had found it BS as well. What would you have said or done in that situation? The program run hundreds of times faultlessly. It happened each time after a single-block run back in continuous mode. Enigma