Are these times being posted for the regen of the sample file at the beginning of this thread?

If so, then I am getting

1m 48.88s per the event logger

The verify aspect took 28 mins to run.

Is that too slow? I read that it should take approx. 7 mins to verify.

Here are my specs:

Dell Computer w/

Intel Core 2Quad CPU

Q6600 @ 2.40 GHz

2.39 GHz, 3.25 GB Ram

NVIDIA Quadro FX 1700

Windows XP Pro

Service Pack 3

Running Mastercam X5 MU1

Thanks for any suggestions.

I'm seeing the same thing, Tim. It is slow to access the parameters of our tool paths, mainly the tool path page of the parameters. I thought is was just the large surfacing tool paths that were doing it, but we are also getting slow access to the smaller 2d contour tool paths. The whole program (X3) just seems to "think" a lot more than previous versions.

Hi John,

metafile is the culprit, along with having the system set to use OPENGL graphic support. Metafile will not work when OPENGL is selected, according to the help section with C-hooks. If you try and change it to GDI instead of OPENGL, then you start recieving the error and mastercam becomes unstable.

Does anyone here know why we cannot switch to the GDI graphic support instead of OpenGL?

Regards,

Dennis

Thanks Eric, that helped. One thing to add to that, when you make a tool library, the tool length offset # on the parameters page should be set to zero. That's where I was getting it wrong. I had my tools defined with that parameter equal to the tool number.

Hi folks,

We run Fadals in my shop and use a post that outputs an H code in our posted program that equals the length offset. I have mastercam set-up to number the tools sequentially, but the length offset never changes from what is set in the tool library. The H code in our posted program tells our machines what TLO it should use, and if it is different from the tool number then things can get bad really quick. I have struggled with this ever since the new mastercam came out (not sure which one it started in) We run X3 MU1 and I have found in the post where it calls out the lenght offset value, tlngno$. How can I change our post to make it look at the tool number and say that it needs to make H = that?

Thanks for any help.

Dennis

John, did you ever get this accomplished?

Another update, we tried the aladdin diagnostix utility. What are the settings we need? Also, tried the other ideas. The nethasp is located on a computer with Windows 2000 loaded on it. Could this have anything to do with it? And we do have a Novell network here. Thanks for everyones help.

It is set to network, and still nothing. Someone said to download the new driver from aladdin because of some issue with Windows XP SP2 firewall. Could this be it?

Hello,

We have a network installed for our Mcam, and have recently installed X. All works fine on the local computer with the USB hasp, but the other computers with the Mcam X loaded are not finding the sim. Mcam 9 works, and sees the sim, but X doesn't. Any ideas?

We just upgraded our computers to the following components:

AMD Athlon 64 FX-55

2.61 GHz

2.00 GB Ram

My question is what is the suggested amount of allocated ram I should have? I have it set at

points per spline: 25000

patches per surface: 25000

undelete: 1000

database: 100000

Toolpath: 300000

Total = 419.7 mb

When I try to backplot a toolpath, I get a warning -error allocating memory for toolpath functions.

I also cannot go any higher on the allocations without MC resetting them back to the previous setting? What am I doing wrong?

Thanks for the help in advance.

Dennis

PERFECT! Thanks for the code John!! Let me know if there is anything I can help you with.

Hi John,

I came up to WI a while ago, and Jake gave us a copy of your script to use in NC. We were having the same problem w/ 2 of our shop computers and I couldn't figure it out. I'm going to try doing what your last post says and see if that helps. We could get a correct image if the screen backgound was set to white. I'll write back and let you know what happens.

Dennis Archer

This is what i did. That worked great. Thanks alot for the help! Jimmy, when are you coming around?

ptlchg0 # Null tool change

psgwcs ,n, ss

if fg1014 = 1, n, pindex, e

storkman, I'm not sure what you mean, and dood, that will work but if seems more of a hassle. Shouldn't there be a way to edit the post to see the different rpm's like it sees the different feed rate?

I agree with all the parallel finishing posts.

I'd use the surface finish parallel for finishing after you rough. Depending on your finish you would like to achieve, i would also run another parallel finish pass with a stock allowance of .003 before the finish.

With the finish, i would use tolerance of .0003, step over of .003, zigzag, and angle of 45.

Gap size set to .15, following surfaces, and check gap motion for gouge the only box checked under gap setttings.

Under advance settings, I would pick the only between surfaces for roll tool. These options gave me one rapid move to start, and one at finish. The tool stayed down through the entire part.

This may work for you???

Hello everyone!

Got another question.

We are running a Fadal VMC 6030 machine and seem to have a bit of trouble getting our post processor to reconginze two different RPM's for one tool. An example is say doing a contour w/ an endmill and roughing first at 10000 rpms. We would then make another contour operation using the same path and slow the rpms down. In our posted file, it changes the feed rate, but does not change the rpm's. What in the post needs to be changed? Does it have something to do with the following?

pss # set rpm to ssmax

if ss > ssmax, ss = ssmax

savess = ss

ssrigid = ss + .2

if rigid = 1 & opcode = 3 & nextdc = 3, n, *ssrigid, "M5M90", e

else, n, *spdlon, *ss, e

Thanks again for everyone's help

I'm still getting the same problem. And yeah, they are good computers. Could it be our graphic card? (NVIDIA)

I have a question concerning metafile. We use a vb scribt that imports a file created by metafile into a word doc. Two out of our four computers import the file correctly. The image is a wireframe on a white background. The other two computers import a black background with a very faint image of the part from mastercam. I have come to the conclusion that it has something to do with the hardware of the two computers since all of the files are the same( vbs, metafile, etc.. I copied from one to another). OpenGl is off on the computers w/ the problem. Any suggestions? Thank you.

The job setup is set as you describe. The problem is not that the tool parameter page is not set, its when we post the program. The tool stays the same speed throughout the entire operations. The first time the tool is used, say with a contour, we set the speed like 8500 and feed at 120 ipm. Then we go w/ another contour at full depth right after, we then set the speed slower and feed slower. The program doesn't reflect this change, it just runs it at the 8500 and 120.

Hey People,

Got a question. We are running 9.1 MR0304 and have been using a post that will post to a Fadal VMC. The problem that we are running into is having two operations of the same type using the same tool (e.g. 2 contours, etc..) and trying to get one operation to run at one Feed and Speed, while the other one(usually a clean up) to run either slower, or faster. We are changing the program, but when it gets posted, the program ignores the different speeds that were in the mc9 file. What can I look for in the post to see where this is being overlooked? Any help will help.

Thanks,

Dennis

Its V9.1 SP2, mostly in surface finish operations (that we've seen).

Hey people,

Got a question, our post program works great for our Fadal programs, but sometimes we get a funny result. We can program something at 40 ipm for the feed rate, but sometimes it will only post it at the plunge rate feed. This seems to happen on surface toolpaths mostly. Any ideas??

Thanks,

Dennis

Hello people,

I have a question regarding programming a toolpath. Let's say we have a few points displayed on the screen. All of these points are located at Z 0.000. Now let's say we want to machine a path from one point to another point at -.100 deep. I know that we could draw lines connecting these points together and then chain the lines producing the toolpath, and also we could use the point to point method where we input the tool up, and tool down commands. My question, is there another way we could do this without having to draw lines, or go through the point to point drama(cause it's usually a couple hundred points we need to connect). We have looked at this for awhile, and could not come up with any successful ideas. Maybe a contour where we can window the points,(like drilling)and let mastercam connect the points.

Thank you for any help!

Dennis Archer

MCAM 9.1

Plastic Ingenuity

A G75 is Multi-quadrant circle input on. I have tried to use filter, but I don't completely understand it. The tolarances that was mentioned, we normaly use .001-.0005. Thats cut tolerance. How can I reduce the starvation. Changing controllers is probably not an option. Does corner rounding have any effect on it? I was just running a pocket on a plate, and used the helix entry method. The machine near about chased me across the shop. So its not just the surfaces.

Thanks

Dennis Archer

If drip feeding is also DNC'ing, then yes, most all of the programs are to large to load. The baud rate is at 9600.

As for the top of the program, what am i looking for?