It is the gap settings that govern when those retracts occur. At the top of the gap settings dialog, you can set the maximum distance where the tool will not retract, either as an absolute distance or as a percentage of the stepover. If you set that distance high enough, then the tool will not retract between the passes. You will of course also have to set the behaviour on motion < gap correctly, often either "broken" or "follow surface" works well in such situations. What needs to be set there depends on the part geometry, though.

You could use a canned cycle, combined with a check in the ptlchg postblock to ensure that the usual toolchange sequence isn't output.

It seems i misremembered when ptoolend is called. I am sorry about that, this time I have checked that it works as I say. The variable nextop contains the NCI gcode of the next NCI line. When ptoolend is run, that is either 1000 (for a null toolchange) or 1002 (for a toolchange), so checking on nextop should work for you. Write this in the last line in ptoolend: if nextop = 1002, pcoolantoff You will also need to call pcoolantoff in peof, as ptoolend is not called immediately before peof.

I think I see what you need to get it to work. Call pcoolantoff in ptoolend, i.e. ptoolend should look like this: code: ptoolend #End of tool path, before reading new tool data !speed, !spdir2 if mr1 > zero & opcode <> 3, #all non-drilling ops [ pbld, n, sg00, "Z", no_spc, *mr1, e ] pcoolantoff That will cause pcoolantoff to be called immediately before a toolchange and immediately before peof.

The method I suggested will work if the coolant variable and its previous value (prv_coolant) is used to control the coolants. If the post use more variables to control coolants, then you will need to save and restore those variables, too. Can you post the pcoolantoff postblock, and the postblock used to switch coolants on ?

If it is OK to switch off the coolant at the time the ptlchg1002 is processed, then the simplest way to do it is to save the value for the coolant variable before running the pcoolantoff postblock, and reset the coolant variable afterwards, like this: code: sav_coolant = coolant pcoolantoff coolant = sav_coolant You will of course have to declare the variable sav_coolant before you can use it.

There is surely a reason for that, but I doubt anyone can tell you why it is happening without some more information, much less suggest a solution. Can you post a code sample showing the duplicate lines ?

Change it to this: pccdia #Cutter Compensation #Force Dxx# tloffno = 2 if prv_cc_pos <> cc_pos & cc_pos, prv_tloffno = c9k sccomp if cc_pos, tloffno Then the D number will always be D2, and it will only come out on the line with G41 or G42.

I think the best way to get what you want is this: if not(rigid = 1 & opcode = 3 & nextdc = 3), n, *speed, *spindle, pgear, e

I just tried with mill9m.cfg, mill9m_w.cfg and bob.cfg as the config file names, running Mill version 9.1 MR0304. I did not see any problems, behaviour was as it should be. What kind of problems did you encounter ? What Windows version are you running ?

Nice to hear I could be of help.

To make it work when you hit 10 tools, and to make it work with N number like N0001 and N1234, you need to edit the format definition for the formats. A little explanation is probably in order here. fmt T 4 t The number four means format definition 4 is used for the variable t, so editing format definition 4 changes the output of the variable t. Format definition 4 probably reads something like this now: fs 4 1 0l If you change that to this: fs 4 2 0l Then you will get T01 or T12. However, that will alter all variables that use format definiton 4, so it might be necessary to make a new format definition to handle t. To do that you add a new line to the bottom of the fs format definitons, with a new number, and change the 4 in the format statement for the t variable to that new number. To get n output like N0001 and N1234, you use the same method (either editing the format definition or making a new one), but here the format definition must read like this: fs 12 4 0l It might not be format definition 12 you need to edit or add, but the part after the 12 must read as I wrote it here. Note: In the format definitions I wrote, it is the letter 'L' after the zero, not the number one.

To get an extra space after the N number, you need to modify the format statement for n. It looks like this now: fmt N 4 n You need to change it to this: fmt N 4 n " " The number 4 might be a different number in your post processor, the number should not be changed. It is the bit added after the variable name 'n' that is important.

Lets see if I can help you there, the two guys look like this: Now, the code is this: code: You can also click on the "Instant graemlins" link and then click on the one you want.

If your tool staging is on a lnie by itself, then it is easy to prevent it from coming out if the tool ias already in the spindle. The current line for tool staging would read like this: n, *next_tool, e If you change that to this: if next_tool <> t, n, *next_tool, e Then the tool staging command will only be output if the next tool and the current tool are different.

I have a NVIDIA GeForce 5700 card. Dual monitors are supported. My card did come with an adapter so two analog monitors can be connected, and the software is included in the NVIDIA driver. I have seen (but not tried) a Mastercam session open across two monitors, and it is also posible to have a Mastercam session open on each monitor.

MetalFlake, your line initht_i = initht - refht sets initht_i to the incremental distance from refht to initht. If that is not the incremental value you need, then change that to initht_i = initht - tosz to get the incremental distance from top of stock (i.e. the top of the hole) to initht. I had assumend that the formula for initht_i was correct in your post.

Change your line !initht_i, *initht_a # Output the 'W' word to *initht_i, !initht_a # Output the 'W' word Then you should get incremental W output all the time.

I don't think incremental/absolute is the problem. The only variable I can think of at the moment that could cause that kind of behaviour is brklinestype. brklinestype should only have a non-zero value in polar conversion and axis substitution toolpaths. That is assuming that it is lines that are broken up, and not arcs. If it is arcs, then it could be linarc that is set to 1, or arccheck combined with a too fine tolerance.

Mozilla is e-mail client, newsreader, chat, HTML editor and browser. Firefox is only the browser. The Firefox browser is as far as I know identical to the browser in Mozilla.

As Rekd wrote, it is at 200 posts. See here

Main menu -> Screen -> Next menu -> Plot. With Windows driver active, you can use a normal printer. You can select the scale desired, and select the area to plot by placing a rectangle (the plot area) on the geometry.

Welcome to the forum Nice to see someone who reads the FAQ and look around the forum before posting. Sounds like that saved you a reception. A v9 post won't run with v6, but there should be a Fanuc post on the v6 CD.

Even if the computer clock is wrong, hasp9.exe should still be listing the licenses on the HASP, and the start and end dates of the license period. If the behaviour is the same on two PCs, then it is almost certainly a bad HASP, you will have to contact your dealer about the problem. In the meantime, you can try the parallel HASP, you can always move around the HASPs later. There are only two potential problems with moving around HASPs: Date issues - You must make certain that both PCs have the computer clock set correctly, and are set to the correct time zone. Power spikes (parallel HASP only) - If you also have a printer connected to your parallel port, then you must switch off both the PC and the printer when plugging in or removing the HASP, otherwise you might burn out the HASP (it isn't very likely to happen, but it can happen).

That looks like the HASP is bad, or there could be something wrong with the setup of your USB port. Could you try the HASP on another PC ? You do not need to install Mastercam to test the HASP, you only need to install the HASP driver, and run hasp9.exe. To install the HASP driver on another PC, you need to copy and run the hdd32.exe file, found in the common directory. Did you check the HASP driver as I described ?