quote: I knew about this thing but it is trick ,this is not a Mastercam stated feature ,you can not complain . Of course, it is. I read this in Mastercam help file. Anyway, i'm not complain about that and I'm ok to import .stl files only... quote: As an advice you better use parasolid *.X_T file ,bigger chances of success ! I don't think the problem is STL files themselves. They're not corrupted as I can open them correctly with a lot of other softwares. But in Mastercam verify mod...

quote: I would really appreciate any help on the subject because by now I fell dumb If Xform doesn't work (it happens it works correctly:) ), you still can use WCS...

quote: In verify are you checking use custom tool Of course, i do use Custom setting... quote: make a simple sample and send to [email protected] I already did as V9.1SP2 came out and they answered me my custom tool wasn't correctly designed cause there was geometry below Y-axis... so i don't know if they decided to correct/improve verify to match backplot. quote: In the mean time you can apply a tip comp inorder for it to verify correctly. Yeah i know big pain in the rear. Remain the risk to post NC like that... To verify correctly, i usually load my file on V9.0SP1 but with this version there was an annoying bug: tool doesn't verify Z-clearance on 2d contour with compensation control. Nobody's perfect. quote: Your NC code comes out correctly though right? Its just a verify problem? Yes, only verify. Backplot is fine too.

How ?!?!? Load your file with commandbutton in verify mod just as you do with .stl. You probably noticed filter selection in "open file" form ask you to choose a .STL file only but in fact you can choose any .MC9 or .IGS. Give it a try !

I m gonna try to be clearer. First, surfaces axis-5 machining is fine with ball cutter's standard control point (tip or radius center). My problem is mainly with 2d contour toolpath or drilling operations. Example with this disc mill: If you want to control z-point i drew, you need to create/draw a special tool. Therefore, you need to draw cutting area (flutes) below y-axis (as you draw tools in top plane and y-axis represents tools's Z-height). So this trick is working perfectly with backplot and post output but unfortunately not with new Lightworks verify in 9.1 (worked great with 9.0). You may say, in this one case, that i can use a standard disc cutter coming with Mcam and manage height tool into program. Yes, but this is not the way we work... it depends of the tool's use. With this disc cutter if we only machine with top of tool it gives operator larger choice of cutters with different height: flexibility. And this without to tweak the program.

Yes, "box" stock works pretty well and if you save .stl from verify mod it works pretty fine too (that's what i previously said). If you're using WCS for other operations it still works fine. However, if you transform this .stl file (rotation/translation), sometimes it is working pefectly, sometimes not. Major problem occurs as you create .stl file from solid drawn or want directly to load a .mc9 (or IGES...) file into verify mod (yes, you can) including surfaces/solids. Useful to verify special stock and/or fixtures. There, it rarely works even with simple geometry.

Ok, i'll do on monday at the office (no mastercam at home)!

I wonder if someone would love to get this really great feature to me (mcam mill): To be able to define precisely the Z-depth tool tip by mean of a textbox in tool configuration (as it can be defined for diameter compensation control with special tools). Until now we only have 2 choices: radius center and tip. To pass over this limitation i have to draw each tool (even some standards) which Z-depth control point isn't defined at tool tip. As Z-depth control point is defined on tool geometry at the Y-axis origin i'm translating the geometry according to the value i need. Even if this is taking some time i can arrange myself but... yes, there is the "but" word. Tool backplot and post output are correct but new verify mod from Lightworks appeared with V9.1 (it worked fine with the old one in V9.0) doesn't manage anymore tool geometry drawn below Y-axis... So keeping geometry above axis-Y would be feasible if i could define precisely tool control point. For info Vericut do it in standard but my boss don't want to pay for it... However i'm still waiting for an update. Perhaps this is done (or planned) with maintenance program ?

hello all, I come here as i wonder if some others are having same problems. My reseller even don't answer my mail anymore... I'm using V9.1 SP2 (lathe/mill) and have some troubles to use STL (or MC9/IGES/and others...) files made from surface/solid entities with verification mod. As i open them in verify i often get a message box that saying (translation from french version): "STL file doesn't represent a closed solid, approximation will be generated". You can imagine generated solid is never good. Strangely, if i'm creating the .STL file by saving it from verify it works pretty fine. However, if i transform these files from MCam .STL interface (rotation/translation) they sometimes (often) don't work anymore with verify... At start, i thought my surfaces/solid was corrupted but i tried to import my .STL files in other softwares (solidworks 2004) and they worked perfectly. I'm not a maintenance customer yet (still have to convince my boss...) but would appreciate to know if this issue is known/logged and perhaps corrected? Is there another way to make my files working correctly with verify ?

Thanks, i'll try that !

I'm pretty sure I already hit the button and it didn't work. I will retry. And about .stl file: Is it really possible to save it after translation ? How ?

Did you really try this ? I've personnaly never be able to save a .stl file from verify with lathe... However, i don't understand why ! On the other hand, with Mill which can do it: If you open (converters) the .stl file created then translate it (or other xform) you can't save it anymore to .stl format because there is no surface in it...

Did you install V9.1 SP1 ? I had this kind of problem with 9.1 as I was zooming in verify. SP1 solved this.

Mastercam post works very fine with our Deckel DMU60P (with 19-cycle or 5x).

Did you (just to try) to select compensation control by computer? I'm still pretty sure i had this problem before... I did a similar toolpath yesterday and it worked with V9.1 (I'll try V9.0 tomorrow)

I think I had this problem before with closed chains 2D contour. Lead in/out with arcs saved me. Check you didn't checked 'use only clearance on start/end of operation' [ 07-31-2003, 11:42 AM: Message edited by: David Colin ]

This is not really helpful, but for info CimcoEdit do it in standard. Why don't you use it ?

The verify module programmer at CNC just came back from vacation (i got a mail today). He's on some b... i recently found. I'll send a file with clearance prob tomorrow. EDIT: Here are some files for those who always think : "There is only a few b... in MCam and you probably do something wrong !" Just download 2 last files (.MC9 file+stock model .STL) and try verify mod on both V9.0 and V9.1... You're gonna laugh. http://perso.wanadoo.fr/anorec/ [ 07-31-2003, 04:35 AM: Message edited by: David Colin ]

Of course if you're not using tool radius compensation you can uncheck 'simulate compensation control'...

>Try turning off the "cutter compensation in >control" check box in the verify misc. If you're turning it off, what's the goal of solid verification in that case? I've also noticed this b.. (I'd go in prison if i type the word here) since V9.1. And there are some others in verify mod... (by example, if you are using tool geometry files). I'm crossing my fingers by waiting for SP2...

Hello, I exactly know why optimize checkbox is used for. First part I killed made me understand: avoid check it as you're machining finish contour with tool radius = arcs entities radius in contour: If real cutter radius used by operator is slightly inferior to arcs in contour then arcs of the part will become the same as tool radius. With optimization: if arcs (a pocket) in the geometry chained are inferior or equal to tool radius, MCam calculates points that cnc machine tools can manage to calculate tool compensation. It works fine. Of course, With some couple contour geometry/tool if you don't check optimize MCam can't create a toolpath (or partially). That is normal. However in that case, there is no (or partially) post output. Not the same as in my example in which post output is complete and correct. I repeat: in the example if you check or not the 'optimize' checkbox there is no difference because there is no optimization to make (radius tool < lead-in/out arcs and contour arc). Optimize checkbox has nothing to do with gouge control in lead-in/out. There is another checkbox for that in lead-in/out form. And in my example it also has no effect cause there is no gouge and mcam doesn't find gauge. It's OK. Prob is backplot only.

Thanks to you. I checked your file. It works fine to me! But this is definately a bug ... Optimize checkbox has no effect (it s ok). The prob seems to be lead-in arc angle: If you type 155° it works, you type 156° and above it fails (lead-in/out is backploted but 360° contour is missing)... no reason. Anyway, did you compare special tool-7 verify (chanfer) with both V9.0 and V9.1? I found today some other weird things about verify but i'm keeping them for CNC software. [ 07-22-2003, 12:03 PM: Message edited by: David Colin ]

>Yes it DOES change ! >I don`t say without checking . >I did it on your file with success ! >Turn it off and see yourself . >As I said before I will explain later. Really weird. Nothing changes here... perhaps you changed control compensation simulation off ?

>you can not enter to G42 or g43 with first >movement -arc ! I'm OK with that too! But in my example MCam is making the missing line move (entry towards start of the arc point). This is a standard move. >You know that when you choose compensation by >control and check in toolpath optimization MC >will not gouge the toolpath. In my example optimization doesn't change anything because arcs (entities chained and leads/in-out) are smaller than tool's arc. It's very important to have exact toolpath post output. I must go to the office right now. See you soon.

>Are you satisfied with my answer ? Not really... Of course if i enter without an arc it works. But i need this entry with 180deg-arc in this machining case to progressively take chip. I'm not ok with you: Mcam has all informations to create this toolpath and it's doing fine. I said post output was correct. In my example, every machine with compensation control capabilities can theorically run post-output made by Mcam (but sometimes cnc machine tool bug too...). Parts of the example have been machined last week and the gorge doesn't look like verify/backplot seen in MCam. That's all. by te way,i spent about 10hours today in front of Mcam and i'm pretty sure that verify (backplot is ok) doesn't work at all with special tools geometry. So be careful if you are drawing your tools! I also received a mail from CNC software and they wrote the bug into their log book. Wait and see. [ 07-21-2003, 12:36 PM: Message edited by: David Colin ]