Some sample code will probably be needed to answer your question, preferably with comments on what you are getting now and what you want to get.

If it is a cancellation of tool length compensation prior to toolchange, then that would be easy to add. In that case, we will still need some sample code to show what you want, and where, before we can tell you how to make the change.

In Mastercam, you do need at least one surface in order to machine a CAD file, but that can be a flat surface below your STL file.

With appropriate toolpath boundaries, that should let you machine your STL file, without having the tool going down to the surface.

While I am not certain where Heavy's "[" at the end of that line came from (it would create a posting error where it is in the posted sample), I think I can get rid of the excess lines.

The bit that says

  n,"(0)",sgplane, "$", e 

should be changed to

  n,'(0)',sgplane, '$', e 

The single quotes means those strings will only be output if there is other output on that line, in this case if sgplane is output.

HTH

G17/G18/G19 work differently on different controls.

On some (many) controls, they control the plane arcs are handled in, but nothing else (neither radius compensation or length compensation).

On some (fewer) controls, the plane arcs are in is controlled differently (often by the axes called), and G17/G18/G19 controls the direction of radius and length compensation.

You have to find out how that works on your control, in order to know whether you can use radius compensation when using your angled head, and whether you can use length compensation for different tools.

Yes, you can e-mail it to me, then I can take a look. At least enough of a look to see how difficult it will be to track down how to make the change you want, I cannot promise more than that.

That doesn't contain the reset I was looking for, now I am getting confused

I don't think I can work out what is going on without a thorough analysis of the entire post processor.

No, the lines to reset work offset do not appear in ptlchg or ptlchg0.

Looking at what is in psof, ptlchg and ptlchg0, I would say that work offset is only reset at actual toolchanges (in which case sub programs are per tool, not per operation), and the place it is reset is in the psrwc postpblock. What does the psrwc postblock contain?

Looking over your code, it looks like swkcs is the saved (initial) value for the work offset, presumably only captured in the psof postblock.

In the ptlchg postblock (and posibly also in the ptlchg0 postblock), you should then have something like this:

wkcs=swkcs

You would need to replace that with this section from the psof postblock:

if mi1>1,wkcs=mi1

Then you should be able to select your work offset in each operation, but this also means that you must set the (starting) work offset correctly in every operation, instead of only having to set it in the first operation.

I think that should work the way you want, but you should of course test it.

You need to look at the string select tables for sgwcs and sgwcso, to see which variables control them, and then find out where in the post they are changed.

The last half of your pwcs block ( if smi2=0,[wkcs=wkcs+1, wkcso=wkcso+1] ) looks like it is set up to increment per call (presumably per subprogram), which means that the ability to specify it per operation may be disabled.

You probably need to find out where the two variables wkcs and wkcso are initially set (they are probably reset at each new operation), and change that code from a reset to a hard coded value, to a reset to an initial value defined in a misc. var.

The variable tool_op can be used. If tool_op = 64, then it is a (lathe) drilling operation. You may also want to check the value of drillcyc, to check which drilling cycle it is.

I have seen problems with tool_op not being updated when it should be, so you may want to force update it with !tool_op before using it.

IZN, I think your problem is the FIFO buffer on the PC's port. You need to disable it or set it to lowest setting (depending on your Windows version, if you can disable it, do that).

What happens is that the PC does receive the signal to stop sending (assuming your handshaking is set correctly), but the data in the FIFO buffer is still sent.

That is relatively easy to change.

First, you need a variable to use for the pallet changer, which must be initialized. You can initialize it like this:

pal_chg : 0

Somewhere in your post there are similar initializations of mach and cont.

Then you need to edit your format question line to this:

fq 2 pal_chg Pallet Changer ( 0=NO 1= YES )

You also need to find theplace the questions are asked, that is most likely in the pheader postblock. At present, it should look like this:

q1

if mach = 5, q2

You need to change that to:

q1

if mach = 5, q2

if pal_chg = 1, q3

You will also need to use the pal_chg variable to create the necessary output in the relevant postblocks.

NOTE: You can use any variable name in place of pal_chg, as long as you do not use a variable name which is predefined in the MP post language (pal_chg is not predefined) and is not used in the post processor already (you can search for pal_chg to check that).

My apologies, it was not intended as being hostile in any way. The FAQ does state, that asking for a post processor as your first posting here can give unpleasant replies, though.

When looking for a post processor, you should first contact your reseller, to ask them if they can help you. I am afraid I do not have a post processor for a Galil on hand, but it is of course possible that someone else here has one.

Perhaps you should have read the FAQ before making your first posting...

There is a link to the FAQ at the top of the page.

EDIT: Forgot to add, welcome to the forum.

[ 08-14-2003, 03:00 PM: Message edited by: Christian Raebild ]

Starting with that version of the Mp.dll (or was it 9.1.9.13?), the implementation of arccheck is reworked to a different syntax, so some changes to your post will be needed to make arccheck work as it did in Mastercam version 9.0. In Mastercam version 9.1 before the reworking, there was a bug with respect to arccheck, where setting arccheck > 1 would cause erroneous output.

I am afraid I do not have time right now to work out what the settings will have to be with the reworked arccheck to match your settings, as I am going out the door shortly, but I might take a look at the problem this evening (my time is CEST, i.e. GMT+2).

MachineSMMC, if I understand you correctly, you want that M00 after each operation (when there is not a toolchange), not after each retract.

As far as I can work out, Steve's suggestion will not insert the M00 only after each operation, it will insert it after each null toolchange that has been preceded by a retract (i.e. after each island, or with some settings after each Z depth).

I believe the following changes will do what you want:

At the end of the psof and ptlchg postblocks (as the last line in each, insert:

!op_id

In the ptlchg0 postblock, in the postion you want the M00 if it is the end of an operation, insert:

if op_id <> prv_op_id, n, "M00", e

!op_id

(EDIT)

After rereading your initial post, I realise that what I wrote first won't do what you want. What I outlined above will insert a M00 after each operation, not only when you set it in the canned text. It is possible that changing the two lines in the ptlchg0 postblock to

if op_id <> prv_op_id, pcan

!op_id

will do the trick. It might also be something else that has to be changed, though.

(END EDIT)

HTH

[ 07-25-2003, 05:11 PM: Message edited by: Christian Raebild ]

You may have to turn down the hardware acceleration for your graphics card a notch or two, it sounds like that might be the problem.

You could also try to download and install the newest driver package from NVIDIA's website, if you have not tried that already. You will probably receive a warning about the driver not being signed by Microsoft when you install it, you should ignore that warning.

I remember reading about not installing the NetHASP on the server, too. I think it was in the NetHASP documentation on the v8.1 CD.

As far as I remember, the reason stated was that leaving it on a PC on the network would allow one license to be used if the network was down. While I don't think that was mentioned, there is a good chance the sysadmin will be using the server if the network is down.

The difference is that the "Shallow" button makes the toolpath take smaller steps in the Z direction in shallow areas, to ensure that the steps in the XY direction are kept within a defined limit.

The absence of such additional cuts in your experience could either be a question of your geometry, or it could be inappropriate settings in the "Shallow" dialog.

Try setting the "Shallow" dialog to the following:

Add cuts... selected

Minimum stepdown 0 (zero)

Limiting angle 45

Limiting stepover ½ your cutter diameter

That will add cuts to shallow areas, including completely horizontal areas. Those settings may add more cuts than desired, depending on your other operations, but then you can try changing the settings.

The above field names are taken from version 9.1 SP1, if you are using an earlier version, they may be different.

I don't know of any place you can check if a bug has already been reported, but I believe that bug has been reported.

To report a bug in mastercam, send an e-mail to [email protected] with a description of the bug, and the necessary files to reproduce the bug (if any files are necessary to reproduce the bug).

My error, I thought that bug had been corrected long ago. I can see that it has not been corrected yet by v9.1 SP1.

Your understanding of the way the function is supposed to work is correct.

The fact that it does not function as it is supposed to is a bug.

Changing the feed and/or speed does not require a regeneration, as that does not change the path the tool has to follow.

Changing the tool geometry, on the other hand, will require a regeneration, as that will most likely change the path the tool has to follow.

There have been a couple of threads recently on converting raster (i.e. bitmap) files to vector formats readable by Mastercam.

Try the "search" link at the top of this page, and search for the word "raster", then you should find a number of good suggestions.

HTH

Mark, I will try to explain the difference between filtering in Mastercam and using cycle 32.

As has already been described in this thread, filtering in Mastercam replaces linear moves in the main planes with arcs, if arcs can be made that fits within the tolerance.

Cycle 32 does not move the tool through arcs, it creates a third degree polynomial curve in three dimensions, making the entire toolpath (from one rapid move to the next rapid move) one curve through space, with no sharp corners. Small local radii are possible on that curve, where the tool has to go through sudden direction changes, but that only happens where the toolpath demands it. A third degree polynomial curve is very similar to a spline, the main difference is in the mathematical definition of the curve.

Cycle 32 thus uses a more effective method of filtering, which can filter all toolpaths, where Mastercam's filter works best when the toolpaths are in one of the main planes. This more effective filtering is possible because the filtering is done in the control, where Mastercam's filter has to output somthing that can be understood by practically any control, including older controls.

Mark, with a Heidenhain TNC 426 control, You will probably get better results by using cycle 32 with an appropriate tolerance setting than by trying to use arcs. If you activate cycle 32 and feed the control with a lot of points (i.e. L commands), then the control approximates the curve described by the points with a third degree polynomial curve, in three dimensions. With cycle 32, you don't want any arcs, and if you can transfer the ensuing program to the control before you run it, then you should leave the filter off entirely. That is what I hear from the moldmakers I have spoken with, at least.

The above does assume that you are using the control in Heidenhain conversational code, though.