In think more information will be needed before your question can be answered. Which version of Mastercam are you using? Which type of Siemens control is it, and how old is the control? Is that DMC 63V a 3 axis machine, or is it a 4 or 5 axis machine? AFAIK, the DMC 63V machine only comes as 3 axis, but I am not certain, and as I am at home now, I cannot check. We, CIMCO Integration, the Danish Mastercam reseller, could probably help you with a post, preferably through you local Mastercam reseller. You can contact us at [email protected]. While your getting a post for free from someone else through this forum will of course be free, you should ask yourself how much free support and customization you will get for that post processor. If you buy one from us (prefereably through your local Mastercam reseller), then it will be customized to your needs, as part of what you pay for when you buy it. I do not know what your local Mastercam reseller's view is on such matters, though.

DO NOT simply delete that 'else' line, that may cause the post processor to update the 'previous position' data, without actually moving to that position. James Mayette and several post editors at CNC Software should be able to verify that I am an experienced post processor editor. Deleting that line may cause the tool to hit the part at rapid feed, you should instead insert the suggested comma. Downloading the update is the best idea, though. [ 07-11-2002, 01:01 PM: Message edited by: Christian Raebild ]

I am afraid you will have to edit your toolpath in Mastercam, IIRC the Acramatic control does not support changing the cutter compensation during arc moves. You might also want to contact your Mastercam dealer, they may be willing to edit your post processor, so you receive a warning if you try to change the cutter compensation during an arc move.

For a Heidenhain control, you should use a post that produces Heidenhain conversational code, as that works better than using ISO code. I recently had to make a post processor for Heidenhain ISO code (for a large company, there was a board level decision to use ISO code on all controls). I found, that there were a number of errors in the Mpheid_i.pst post processor, at least with respect to the machine I had to make a post processor for. If you contact us at [email protected] we might be able to sell you a post processor which works correctly, if you tell us what type of control and machine it is.

I do not think 3D compensation is his problem. I think his problem is that plastic parts change shape due to stresses and heat to a much higter degree than metal parts. Do you have a solution for that problem, James?

Try the following procedure: Go to the Windows Start menu, Programs, Mastercam, CNCReg. Got to ActiveX/DLL components. Select mc8view.dll (or mc8view2.dll if that is displayed instead), mark "Regiser Control" and click "Apply". Repeat that for mcbitmap.ocx and mclstctl.ocx, and then restart windows. Your problem sounds like a graphics driver problem, and that procedure usually solves such problems. If you are using Windows 95 or 98, you might also try to replace the Mfc42.dll found in the Mastercam directory with a newer version for your Windows version, that file has also been known to cause problems on some setups (primarily early Windows 98 versions and OEM versions of any Windows version).

Have you drawn all holes, and selected them as one drilling cycle, or are you using a transform toolpath? You should draw all of the holes and select them as one drilling operation, using a transform toolpath may cause "Null Toolchange" NCI code between each hole. If you are using a transform toolpath, then you should make sure you are using the "Coordinate" transform method.

I do not know that type of grinder, but we have made post processors for grinders, and we have made post processors for lathes and mills with Siemens 810D controls, so it should be possible to make a post processor for that machine. I will need to know more about the machine before I can say anything more. What kind of setup is it, is it a rotary grinder (i.e. similar to a lathe) or a multiaxis grinder (i.e. similar to a multiaxis milling machine)? Which axes are available on the grinder (XYZABC)? Can you supply us with the manual for the grinder? Preferably in electronic format, and if it has to be on paper, can you get a second copy which we can keep?

As I do not have Mastercam v9 installed at home, and do not have a HASP at home even if I had Mastercam v9 installed, I cannot check if it behaves the same to me. Have you selected the right hand side plane as both toolplane and construction plane? Have you defined the drillings as one operation? If you have to answer "no" to either of those questions, then Mastercam will place a "null toolchange" between each hole, which will force the G81 command line to be repeated. If the above suggestions do not solve your problem, you should contact your local Mastercam dealer. I have made post processors for lathes with a C axis, so I know it works as it should. If your local dealer cannot solve the problem, then your local dealer can contact us for a quote at [email protected].

The reverse posting menu item is missing in version 9 because both the reverse post and the post processor have to be customized to maintain the the tool info in a format readable by both, for the reverse posted NCI file to be of any practical use. It can be reinserted by editing the post processor .txt file and the post processor itself, but a customized reverse post processor is also necessary. You should contact your local Mastercam dealer for a quote on the necessary changes. Backplotting a reverse posted NC file, which was reverse posted with a reverse post processor which has not been customized for the post processor and machine it is to be used with may produce incorrect results, and try ask accounting (or your boss) this question: What is the cost in lost production and repairs, if the head assembly hits the part or table at rapid feed?

I don't know the Chevalier machines, but from what Jamman mentioned, I would guess that machine is similar in size to the larger Shaublin lathes. Shaublin lathes may be expensive, but I have only heard good words about Shaublin lathes. They are rigid, they are very accurate (+/- 0.002 mm or better for repeating positioning), and they just keep running with next to no maintenance. I have seen a Shaublin lathe which could still stay within that accuracy after 10 years of running 24/7, and the only maintenance it had required was new oil and coolant at appropriate intervals. After those 10 years, it got an overhaul (regrinding the guideways and a control update), and for all I know, it is still running within 0.002 mm, 9 years after that overhaul.

My best guess for the cause of induced magnetism in a lathe would be poor grounding and/or nearby power cables. How can you be sure it is the orientation, have you tried orienting it east-west? And if you have, what changes were made to the cabling when it was turned around?

What kind of Nakamura-Tome lathe is that? We have developed a post processor for a Nakamura-Tome lathe with C and Y axes, rotary tools, two tool stations, bar feeder and subspindle. The post does not support two tools in use simultaneously, as Mastercam does not support that, and the subspindle functions have not been tested, as the customer does not use the subspindle. Other than those two points (and certain rules to be followed when selecting toolplanes), it works fine. I might add, that the Mplfan post does not work very well with Y and C axis machining. The changes needed are fairly minor, if I remember correctly it is only three lines that have to be edited to post process correctly (plus all of the special codes for the Nakamura-Tome, of course), but it took me over a week to track down what the problems were. I don't think my boss would be very happy if I told on this newsgroup, what those changes are Oops, forgot to mention this: If you are interested in the post processor, you can e-mail us at [email protected] for a quote. [ 04-13-2002, 04:11 PM: Message edited by: Christian Raebild ]

Mpbin can: 1. Restrict to a specific sim number (possibly also running on any dealer sim). 2. Restrict to a specific sim type (most commonly educational). 3. Require an access code tied to the sim number. Since any dealer can generate this sim number, I doubt that option is used very often. We rarely use Mpbin, as most special post processors we make use .dll files which create a temporary NCI file, and these .dll files require an access code (and a .prm file to set the machine configuration). A warning to anyone out there who use post processors that run by special .dll files (from us or from other sources): Our version 8 .dll files process all but one of my post test files correctly when copied to version 9. In other words, they fail on one file. Try ask accounting this question: What does it cost in repairs and lost production, if the head assembly hits the part or table at rapid feed? I believe that price tag will be much higher than the cost of an updated .dll file. I recently told a dealer who had noticed that the version 8 .dll files seemed to work in version 9 this, and told him that the customer was free to gamble if they wanted to. The following day, there was an order for an update... [ 04-13-2002, 03:45 PM: Message edited by: Christian Raebild ]

I hope to receive a reply from CMS soon, so there should be progress on the CMS post processor soon. I cannot make any progress before I receive the relevant documentation.

Copenhagen is pretty far from Brisbane, so a personal visit from me is unlikely, but I do know Heidenhain controls fairly well. If cycle 203 works on the control, then it should also work from the post processor. If you can post a sample of the output from the post processor, then I can most likely see what is wrong with the output from the post processor.

I have not heard of that control before, so I cannot offer any immediate help. For a post processor for a 3 axis machine, it will proably be cheaper for you to contact your local Mastercam dealer.

Cycle 10 rotates around the Z axis, and can be found on most Heidenhain controls. Cycle 19 creates a new toolplane (any orientation), but is only found on newer TNC 426/439 controls and the iTNC 530 control

There is a manual for editing post processors, and it is available both as books and on CD-ROM. You should contact your local Mastercam dealer if you want that manual. The change you desire is a change I could make in less than 5 minutes, though I would usually spend 15-30 minutes checking for possible errors in the post processor before sending it back to the customer.

That sounds like a 5 axis machine. I have not heard of the specific machine, but if you can tell us what type of control it has, and what the axis configuration is, then we might be able to help you.

IIRC, the Q### line after a line ending with a "~" must start with one or more space characters (ASCII 32). When I write post processors for Heidenhain controls, I use three space characters. You should also remember, that the last Q### line describing the cycle must not have a "~" character at the end of the line.

I use the name "Autosave.mc9" for autosave files, as I use the prefix "Backup" for intentional backups of files. When playing around with customer files which creates errors, it is often useful to be able to retrieve the original file. If you use the autosave function, then the autosave file will be a correctly saved mc9 file, which will not produce that error. You will loose up to 15 minutes of work if the autosave function is set to autosave every 15 minutes, but how much work will you loose if you have to start from scratch?

Setting rotaxtyp : 3 will disable that error message for single axis rotations, but if you set rotaxtyp : 3, you may also get erroneous output with two axis rotations without getting a warning, so you should check your code.

If your toolpath or database allocation is too low, MC will use the HD instead, which slows down any program, and can cause crashes. In addition, using the 'binary series' values I mentioned earlier in this thread will improve both speed and stability. I have seen systems go from several crashes a day to completely stable by changing to those values. It is not only MC that is to blame for that, though, most of the blame should be sent to Microsoft.

Good to hear you are up and running now.