12.55

gjohn — 2006-11-14 06:58:24

Has anyone had an issue with posting in 12.55? I am getting an errorunable to write operation to output file. This comes up when I am trying to post the cl file.

billator — 2006-11-09 13:19:21

I suggest if is a new topic to start a new topic. In this one looks like we start at least 4 topics in only one. If is an obvious support problem please contact you support guy. If is a bug in software maybe a PCR would be more useful then posting it here. At least regarding PCRs we are paying much attention to them. The forum isn't read regular by all developers and maybe some problems require immediate attention that could be addressed and traced better via PCR system.

cutter — 2006-11-09 10:47:44

This is the latest update on my post problem. About 2.5 years ago I was given a modified post that did not have the correct file extentions on it. Along with it came a set of files that were required to make it work as in essence the correct file path was now broken. When I called to VX to see if I needed to bring any files forward for posting in v12 the answer was no. As it should have been. I then proceeded to use only the modified post and of course without the workaround files it was no good. As it turns out I was I believe the only one out of all of VX's customers that did have this problem but what a headache for me. Jim McDonald became aware of the problem last friday and I had a solution to the issue by Monday, tested on Tuesday and everything for the first time in quite a while looks very good. Thanks Jim. I appreciate your interest in this issue Chris but glad to say no further problems. The earlier posts on this issue by me have been removed by me and not VX. It was my belief at the time that I was being patronised when told this problem had never been seen before. I now know this can be true as it did happen to me that way.

billator — 2006-11-09 10:30:05

Can you send a PCR that exemplify this George? I will have a look and let you know.

gjohn — 2006-11-09 07:39:03

I have been seeing in 12.55 that offset 3d finish is cutting different. It used to be that you could set it for outside in and it would cut in that manner. Now it will start from the outside collapsing in for several passes then decides to go inside out on its own. Anyone else notice this?

gjohn — 2006-11-09 07:12:53

in 12.55 I have been noticing that if I use a copied cam plan and add my new geometry and calc. the cam plan is not going to the depth it should be cutting. There is a basic holder set up that has plenty of clearance, but does not go to depth unless I add .100 to the tool length then it will calc to depth. Has anyone noticed this?

zw_admin — 2006-11-06 08:58:37

Friday we worked on this issue, determined that since your distributor had set up all your posts, and you were not sure exactly what was involved, He was best able to determine your problem. Superior Cad Cam called you and spent several hours supporting you Friday evening. He has talked to me this morning. He narrowed the problem down. The creation of an NC Controller directory at the C: level when attempting to postprocess tends to point at a pathing issue, possibly related to a system variable setting. He is sending me the appropriate files. We are working on a solution.

gjohn — 2006-11-06 06:51:32

I have never been able to get 2d paths to work either.

ChrisW — 2006-11-06 06:21:10

Hello Dave We are unable to collect the vnc file. Could you please winzip the file and re-attach to your forum message.

ChrisW — 2006-11-05 12:00:54

Hello Dave Very sorry to hear of your experience of VX, particularly that you cannot get any output from v12.55 and even your VX Reseller is unable to do so. I am sure that VX HQ Florida will find out the cause of the problem for you - it sounds to me as though the actual install is at fault - Perhaps the common denominator across your four PCs is that the same copy of VX (CD?) has been used but for some reason is not 100% right. What I can tell you is that VX is used world-wide, I have not had reports back about anything like this from the European Resellers and I can assure you that they waste no time in getting problems to me!

billator — 2006-10-12 11:23:05

That's the reason they are axioms are considered fundamentaly true. So every argue or discussion needs to take them into account. Using first axiom results in our first theorem: "Never have a discussion with two manufacturing engineers at the same time." Ease to prove negating: can arrive to a paradoxical contradiction after first sentence is emitted by one of them. And using axiom 1 both are the best and one can agree and the other one can disagree upon the sentence. I like bottlecad's seconf theorem easy to prove using the second axiom: "Previous CAM system generates the money to buy current one." However isn't quite clear that need to be the best to do so. First one I don't quite agree a user can use/prospect a product even if isn't employed just for fan to satisfy his soul geekiness that CAM guy don't quite lack it. (Disclaimer: I'm a manufacturing engineer too so my latest replies should be considered a (supposedly funny) diversion!)

bottlecad — 2006-10-12 10:41:37

>> After my hunble knowledge, the first axiom of manufacturing is: >> 1. Each manufacturing engineer is the best! If they are using or considering VX, they are at least employed. >> The second one is: >> 2. Previously used CAM system was the best! It created the money to buy a second.

billator — 2006-10-12 09:48:48

Isn't that an oxymoron? After my hunble knowledge, the first axiom of manufacturing is: 1. Each manufacturing engineer is the best! So (s)he can't be dummy. The second one is: 2. Previously used CAM system was the best!

SteveMackay — 2006-10-12 09:29:02

Now, I think all we need is a "Quick Mill for dummies" book to explain all the settings

billator — 2006-10-12 08:43:35

I just remember last night it is possible in VX to set the default value for a field so changing that field from 30% to 100% will make QM behave like before.

billator — 2006-10-11 15:56:33

Official I fully agree with you and this is the reason you can alter these (sometimes dangerous) parameters in QM too. The path will be calculate according with chosen settings. Be sure I fight a lot to don't allow in QM (and I still disagree to have on the interface): - Steps bigger the 45% - because can leave chips. - XY User containment - because user will break tools if they use it improperly. - Enforce correct stock definition not creation on the fly of a supposedly correct stock- because user will break tools if they don't define it. - Decreasing interpocket interference factor. (I admit after I lost the argue I changed it to 30% myself from 100% because leads to more efficient paths now back to 100% in 12.60). All these safety setting from QM where removed slowly because: "users are professional and they know what they are doing! ". I actually don't know a person that fully understand tool engagement and loading (climb-conventional milling), holder or shank collision against up-to-date stock that can happen inside a complex mold during a mile long roughing path. It is true can have a rough estimation that can lead or no to a broken tool. Luckily we have fast computers and decent simulators these days too to do decent simulations and try to avoid tool breakage. I was intrigued because I didn't hear about a tool break in very long time. Mr. Mackay pointed to a bug that will definitely break a tool that was fixed in the day he reported and the fix is in current VXV12.55. I realize tool breakage happens maybe daily when using CAM systems but I was somehow relieved because no PCRs came from a long time having this invocation as the software fault. Some of the techniques that are cutting edge or quite pioneered in QM are: it fully simulates milling on the fly (it generates a bit of path and simulates it) and correctly fits ramp motions, dynamically alter the feed, calculates rest roughing, does dynamic holder and shank collision against the dynamic altered stock, removes ramp moves when it can approach from safe places and this is what a lot of customers that mill complex molds appreciate. Because in this moment no other CAM system comes close to do all these things at any price level for very complex molds with the disclaimer is: after my knowledge, I can be wrong I admit here. These doesn t means QM is perfect (and we don t pretends it is) for any usage scenarios. I try to characterize it as not-to-bad for milling molds in general and was used to mill parts starting 5x5 mm^2 (watch gears molds in Switzerland) until 50'x15' (15000x4000 mm^2 walls in Holland) and it behaved decent or didnt let the customer down without a usable path in very reasonable running time.

gjohn — 2006-10-11 13:30:25

I think that the user should have control over what they want the software to do. If I want to take a 70% step, I should be able to. If I want to use a 2d boundry, I should be able to. I don't think that not having the exact default settings should be as big of an issue as it is turning out to be. Other CAM systems let the operator decide what they want to do with the tool path. Again, I invite someone to come up here and see what is going on. We are running VX programs on 6 different cnc machines everyday.

billator — 2006-10-11 09:31:09

>> I have been programmming in 12.55 using the settings that were suggested. I have to admit I do not like it at all. It is your right to don't like it. This is a mater of taste and freedom of choice is a thing that I will not argue with. >> Has there been actual comparisons in a machine that prove it to be faster now? When we developed QM for 12.55 it was developed actively comparing its performance against our main competitors and was tweaked until the results are identical or better then theirs. We have a lot of clients that mill very complex molds and choused to use QM and they usually benchmark it against other major products. The only thing I can tell you is V12.55 is by far the best received QM in its history this is usually true for any new VX or QM that we release and this is our main priority to create a competitive product. In version 13 will be many enhancements for roughing. Including separate control for flowing for open and closed pockets much better tool loading control etc. These changes requires serious GUI changes and wasnt possible to do it in V12.xx for reasons discussed here. I regenerate a default toolpath with version 11.82 and 12.55 of QM and the toolpath is identical in active cuts. The only difference is the ramp moves are a bit longer in 12.55 or the product is a bit more protective in newer version. I appended a screen capture with the part disabled because isnt clear to me if we can post pictures of this part on this forum. The old path is white the new one is rainbow. I can say try to use new QM and I believe, it will give you more satisfactions and V13 will be another huge step for the better in its evolution.

gjohn — 2006-10-11 06:40:30

I have been programmming in 12.55 using the settings that were suggested. I have to admit I do not like it at all. Has there been actual comparisons in a machine that prove it to be faster now? It can't be any easier on tools. I would rather see the cutter stay in the cut, not pick up and move around. Is there any way to have version 11 quick mill with the version 12.55 verification? Could you make the 12.55 2d rough offset its own operation, maybe call it an optimsed 2d rough offset or something like that?

billator — 2006-10-10 14:15:00

billator — 2006-10-10 14:14:16

Steve, George Fully agree with you guys about documentation. I think bobf already took action in this regard reading your posts. Probable the project that require that parameter to be added to the forms slipped from 12.0 to 12.55 and in 12.55 we didn't update documentation because supposedly we don't alter the GUI.

billator — 2006-10-10 14:03:46

Was 49% but it was always clipped inside to 45%. The 45% safety, unfortunately, fell down because people wants to go unsafe to more then that. Unfortunately parts that had values bigger the 45% will regenerate now another path that can leave chips and your part is a good example of that. By default now is 45% as an expression of what we consider maximum to mill everything safely and fast. QM since inception had stock as a requirement for roughing because all advanced QM fetures like: AFC, Holder Collision, Shank Collision, Rest Roughing, Ramp Angle calculation, etc relays on it. Of course roughing in special had evolve (we hope) a lot in last years and relays heavily on accurate stock definition for an accurate and tool breakage free toolpath. So with other words if the stock isnt defined accurate a lot of things will be assumed very probable inappropriate by QM and tool crashes are a step away from this! One of the most dangerous things is to use XY containment in roughing this limits valid motions that will remove stock and clips the ends of ramp moves that have the scope of protecting tools against frontal engagements. Around 2 years ago we develop wave propagation roughing or starting from Stock discrete (not using offset2D) the toolpath will progress uniform as a continues wave uniform loading the tool. QM was at that time (and I believe it still is) the only CAM system to support that kind of roughing being very optimal without requiring plunges in complex open pockets and without doing significant full-width cuts. Of course to help this ZigZag cutting mode would help a lot. A lot of guys are scared when hear about ZigZag when climb is a must! but when milling on HSM machines with 1 mm Z step and 45..60% XY step a toolpath is pure climb less then 50% of time in the rest of time is complex loaded so constraining a path as Climb should be analyzed twice in particular when collapsing from stock is used (as recommended). Maybe Mr. Mackay remembers one of the papers that I wrote for some Japanese clients and cc to him too about: Why toolpath changes suddenly from Climb to Conventional and back in complex molds? This is happening because we try to extrapolate our 2.5D knowledge and understanding of Climb-Conventional milling to 3 axis and unfortunately this extrapolation isnt always true. So in general the first thing that you can do is to trust QMs defaults. If we set them how we set them is because this is the most optimal setting in general. Of course things like steps, tolerance, ref tools and ref operations need to be altered but think twice before altering other parameters in special in roughing where tool loading can be significant. The stock status needs always to be kept accurate. Designing the correct stock, chaining correct operations to proper update the stock in subsequent operations. Without this you cant do accurate holder collision, restroughing, AFC, etc.

gjohn — 2006-10-10 13:30:51

Yes, documentation would be a big help. Here is a new setting in 2d offset and the path is being changed to try and make it better, I had no idea that anything was being changed.

gjohn — 2006-10-10 13:17:51

Containment: stock I am not sure when this changed I have always set it for part. Back awhile ago it always defaulted to part, then in one of the versions it started to default to stock and would not calculate at all unless it was set to part. So I have to make a stock for all roughing passes? It would be eaiser to just use a boundry instead of constantly making different stocks all the time. Before the step over was always 49% so now if you have changed it to 45% you are losing even more of the cutter diameter, on a 2" cutter you are losing .090 per step over. How is this any faster. Feed mill type cutters like a larger step over, we are not gaining anything with the feedmills because of the limited step over.

SteveMackay — 2006-10-10 12:45:31

it might just be me, but I really think part of the problem is documentation/help files. There isn't clear/concise documentation on what setting does what on the cam side of things in VX

billator — 2006-10-10 11:27:33

>>As to the issue of a enhancement in a bug fix, I do not like the idea. Save it for major releases. There is enough fixing going on without having something new added. Like you George are thousand of users that sometimes want to see an improvement because the product (in their view) is useless without whatever they want or are used to using another product. We try as much as possible to don't make major changes in dot releases and believe me is much simpler if we don't change it but isn't always possible to do it.

billator — 2006-10-10 11:19:03

(The very short answer) George: here are my suggestions for an acceptable tool path: USE AS MUCH AS POSSIBLE THE DEFAULTS. (The short answer) 1. Containment: STOCK 2. Offset: 100% 3. Step: 45% 4. Cut Pattern: STOCK 5. Interference factor: 30% if you want fewer retracts 100% more conservative like old QM. (The long and somehow geek answer) I spend another 2 hours investigating the part and I found some interesting blend of settings. All the following observations are referring with generic milling NOT with the current analyzed part. 1. Your first roughing had a containment that was "User Defined" BUT nothing was included by the User. 2. Furthermore, the offset was changed to 25% instead of the DEFAULT 100%. To cope with this interesting challenge, QM used the outside Bounding Box offset by 25% (that to small for correct and complete roughing). The clipping region clipped active motions and, more dangerously, clipped ramp moves. Using XY containment in Roughing is definitely NOT RECOMMENDED! Roughing should be limited only by stock. 3. The step is 49% instead the DEFAULT 45% which can lead to leftover material and actually did leave them. 4. The pattern is collapsing from part instead of collapsing from the DEFAULT stock. This leads to many plunges in the middle, many retracts, and many full-width cuts (this also renders the Climb-Conventional setting irrelevant). I simulate with interference at new default 30% and set it to 100% too and in both cases the path looks ok to me. As expected the 30% setting was a bit more aggressive and generated a bit shorter path.

ChrisW — 2006-10-10 08:30:08

Hello again Concerning >> the issue of a enhancement in a bug fix <<, as a general rule, we do not introduce enhancements in a dot release. However, we are flexible, trying to deliver what our customers want as quickly as we can (an advantage that VX has over rival products where you only see annual updates of the software). In this particular case, as described by Billator, the change was critical to the new functionality previously introduced, so not really an enhancement at v12.55, and not really a bug fix, but somewhere in between (essentially, a control that was omitted but should not have been).

ChrisW — 2006-10-10 08:21:04

Hi gjohn It should not be necessary to test on the machine, we should be able to see any major problems in Solid Verification. If it is a "collision with non-machined step" type of problem, then defining a "special" cutter for Solid Ver might help the investigation - the special would have a tool length and flute length that is a tad longer than the op's Z Step Value. This length must exceed the tool radius if a bullnose cutter is used. The shank can be the regular length, but with it's diameter slightly less than the tool diameter, to avoid false negatives from Solid Ver (we want the Solid Ver run looking for Z height problems with the special tool, nothing else). Now, if the cutter hits a region where the op is asking it to plough through too much material, Solid Ver should find a clash.

gjohn — 2006-10-10 08:00:07

In that case I will try and run it to see waht the result is when run in a machine. I hope that I do not have tools crashing. I do not like having broken tools or machines sitting becuase there is a problem. It is a pain when you have to track down a problem like that that, it runs fine one time and then in a new version who knows. I thought that 2d offset rough ran great before. It sayed in the cut pretty good. It went around the geometry nice. The only thing that you could improve and tried to but didn't really work was taking a stepover larger than 49% of the cutter diameter. You can do this but it leaves standups everyhwere so you don't gain anything. As to the issue of a enhancement in a bug fix, I do not like the idea. Save it for major releases. There is enough fixing going on without having something new added.

ChrisW — 2006-10-10 07:27:22

Hi gjohn We do see the differences, but as explained by billator: >> Version 12 2d offset rough does not even cut with the same logic as version 11 2d offset rough did << This is a deliberate change in the design of the code which is expected to deliver more efficient machining that requires less time to complete the op. Setting a 100% interference factor will make the v12.55 solution become closer to the v11 solution, but not identical. So, what we are looking for is not just a difference between the toolpaths, but a difference that will be a problem on the machine.

gjohn — 2006-10-10 07:01:13

Take you're pick. Use op 1, put in the 100% and watch it verify.on the 3rd or 4th step down you can see that it is still dropping down before it should. It does not need containment. The step down In this case does not apper to be a crash but it is still stepping down the way it was before changing the setting to 100%. Version 12 2d offset rough does not even cut with the same logic as version 11 2d offset rough did. Version 11 stayed in the cut better, not like 12 where it jumps in and out of the cut all the time. This causes additional problems for cutters. The file is there for you to compare to. Do you not see the difference? May be we need to get someone up here to see what is going on.

ChrisW — 2006-10-10 06:29:25

Hi gjohn C'mon, help us a little bit more so that we can get you back working as quickly as possible. Which operation? If it is op 1,2 or 4, should it use containment and if so which profile should it be referencing? When you say it is dropping to the next level "before it should", is this because you have detected a crash or gouge?

gjohn — 2006-10-10 06:19:53

You should have the same file that I tried it on that was sent in as a pcr. Just use the 100 % setting and watch it verify. Right now I have alot of work to do and I don't know what version to use.

billator — 2006-10-09 14:54:24

>>Why was % interference added to a bug fix release? It was not in 12.5 but it is in 12.55. It is there because maybe the version 12.5 was a new version with the default of 30% OR 12.55 was the time frame when was possible to add this parameter on the form. >>I am sorry to be so critical but I rely on this software every day to make programs for our company. Is your right to be critical in particular when the product doesn't behave as it use to behave. I will appreciate if you can localize in a part with only one toolpath the problem reported with 100% and if you can zip (rar) it and send it to me if you wabt for a quick inspection.

gjohn — 2006-10-09 14:25:50

I tried to set the interference to 100 and it is still dropping down to the next level before it should(see pic) . I do not consider this issue closed. Isn't anyone else having this problem? Why was % interference added to a bug fix release? It was not in 12.5 but it is in 12.55. I am sorry to be so critical but I rely on this software every day to make programs for our company.

billator — 2006-10-09 13:42:53

If you want to use 12.55 recommended because is a so much better version. Set the interference to 100% and the XY Step in roughing to 40-45%. If you still believe could be crashes set a smaller feed maybe is to high.

gjohn — 2006-10-09 13:30:15

So where do we stand? I would like to move forward and use the latest but there are issues. I have went back to 11.5 but the verify is not up to par, If I solid verify and try to save a workpiece it is metric and does me no good. If I try and keep solid verifying it will get so far then the verify function will fail because of the size of the part. This I know is not a problem in 12.

billator — 2006-10-09 13:02:44

And because I agree with you we will keep the more conservative setting by default to 100% for interference factor this will lead to a bit more links but will recreate nearly the same path like old QMs so will not change the level so fast. I make my fault too for this change because I was too partial and change it by default but this had happen because it really generates more efficient paths, that's the price to pay for efficiency and as George sad if you enable the safe mill level wise the path is very long to mill. Please don't forget milling by region means try to find possibilities to stay local and go in downdirection minimising links. Unfortunately I can't promisse this in VXV12.55 but I hope it will be present in VXV12.60. The PCR is 19490.

billator — 2006-10-09 11:42:38

>>It is a bad thing to not be able to completely finish a level of cut before the next stepdown. I know this isn't a problem with other CAM packages. To go down before finishing a level is a tremendous optimization that isn't trivial to code and is present only in very few products QM included. Milling level wise (perfectly possible in QM disabling CutByRegion) like majority of other CAM products is always worst then region wise. Worst means the same toolpath linked level wise can be 10 times slower to mill then a region wise linked path. The only "problem" (we didn't establish it as a problem) is the feeling that current QM is a bit too greedy to go down now because we (I) reduced interpocket interference factor that reduces in general the length of links (the tool will mill more in a region) and obvious because I hate to let people down and have this discussion (like in this thread) we add the interference parameter on the forms too to make everyone happy. I append a screen capture too. Do I need to recap but I don't believe are any issues to fix/discuss left in this thread? The step for new opperations is by default 45%, the interference is 30% maybe a bit too greddy 100% will reproduce old QM behavior. As usual to be safe the feeds should be set for a full width cut expected. My feeling is are enough settings there to mill safe with version 12.55.

ChrisW — 2006-10-09 11:42:22

Hi Paulverisor, gjohn Quick question - operations 1,2 and 4 all have User Defined Containment selected, but no Containment Profile has been added to each op's features list. Which profile should be associated with which op?

bobf4fun — 2006-10-09 11:42:16

Viewed negatively... heck no! We love you guys... you help us create workable solutions. We are striving to create a stable, reliable, highly-effective product and thank you for helping us accomplish this goal.

Paulverisor — 2006-10-09 10:19:31

Looking at George's screenshot that he attached to this thread I am wondering why the problem that we are having isn't experienced by more customer's. It is a bad thing to not be able to completely finish a level of cut before the next stepdown. I know this isn't a problem with other CAM packages. I hope that we aren't viewed negatively because of our issue. If we hit the panic button it's only because we are very dependant on a resolution.

billator — 2006-10-09 10:01:57

Theoretical XYMaxStep for circular pocket is 100% Tool.Diameter. On a rectangular pocket is ~70% SQRT(2)/2 * 100. In general for complex parts that can have sharp angles this goes down to ~50%. Now in reality toolpaths have a lot of smoothing, spiralization, etc and they are not theoretical by any means so to accommodate for all this extra noise in calculation QM had hard clipped this step at 45% Tool.Diameter and this, in general, don't leave any chips and still allowed quite nice smoothing of the path. Unfortunately (because I will never agree with this by I admit it is some value if you are careful) people decide they want to remove that clamp and move it upper in 85% range. Now QM doesnt have any physical control of the remained chip and if you are like me a nostalgic of old behavior leave the step at 45% as defaulted, because statistically speaking this is the maximum that can be used without leaving chips. You'll probable wonder why QM doesnt create that useful hears in corners like a lot of traditional CAM systems? The answer is simple because that hears are useful only for very simple pockets and will never solve the chips that occur in complex collapsing scenarios. I can't talk here too much but in version 13 we have a better Offset2D roughing that we hope will make you happier.

billator — 2006-10-09 09:26:21

>>It is not just leaving cusps, it is not cutting everything on a level before going down to the next level then it jumps back up to where it should have finished off before going down to the next. I think that this has something to do with why it is crashing. Something is not right. It is true in latest QMs by region optimization works a bit different and QM is greedier to chain together regions before doing the finishing step that usually has wider inter region extent and creates more retracts. George when we alter the product to behave different is because clients ask for this exactly how you ask too. Our goal is to give you the most optimal path and this is the reason why sometimes is changed. We hope that change is an improvement not cripples the product. I suggest you for the moment, if bothers you too much to use an older QM until this problem is fixed to your satisfaction in VX. Thank you for the PCR and I'm investigating it right now.

ChrisW — 2006-10-09 09:17:31

Hello gjohn Thank you for the VX file and marked-up screenshots. We are investigating the issue right now.

gjohn — 2006-10-09 08:32:53

I submitted a pcr on Saturday that contained a file and two screen shots. It is not just leaving cusps, it is not cutting everything on a level before going down to the next level then it jumps back up to where it should have finished off before going down to the next. I think that this has something to do with why it is crashing. Something is not right. The only thing that has changed is different versions of VX. Our models are still made the same way, We program the same way. The customer can't afford to troubleshoot the software every time a new version comes out. I looked up the report on PCR19095 and I mistakingly wrote offset 3d rough when I should have wrote offset 2d rough. That is my fault. There is no such thing as offset 3d rough.

ChrisW — 2006-10-09 07:15:23

Hello again gjohn Before reporting my progress over the weekend, I must repeat that we need your file to see your setup for PCR19462. By the way, PCR19095 was about 3d offset, not 2d offset? I have spent a few hours trying to force a problem to occure in v12.55, based on the screenshot you posted. I think may be you are using bullnose cutters. With a bullnose, there is a chance of leaving small spikes or cusps (artifacts), if the depth of cut is less than the tool end rad. Reproducing the pocket shape in your screenshot, I can define an operation that leaves small cusps. This is of course a roughing op, and it is a matter of judgment as to whether the op should be tweaked to prevent the cusps. Having run solid verification, one is in a position to make that judgement. In my example, selecting "cusp height" for XY step type is the only tweak required. Given that this potential problem is revealed by solid verification, it should be possible to avoid breaking tools. However, your point is that v11 gives a better result. I have used exactly the same geometry in both v12.55 and v11.60 to test this, and "straight out of the box", I can indeed see a difference, so I shall pass my files to the developer for critical examination.

ChrisW — 2006-10-06 17:47:22

Hello again gjohn I have just looked at PCR 19095 (VX v12.46, July10), which was assigned to Jim McDonald, a highly experienced CAM expert, who was unable to reproduce your problem. You didn't supply an example file. I have double-checked with two of the leading VX Resellers in Europe (lots of VX CAM customers), to see if they have heard of a problem, or something similar, as you have described it - negative. It could be just luck that no one else has been hit by the problem, it could be caused by something specific to LC. I know it takes a while to upload a large file (it helps a lot if you can offer a small one), but without seeing what you see, what can we do? Add your sample file to the PCR rather than posting it here, that will be quicker. If you copy the VX file ("Save As" from within VX), you can reduce the file to just the essential geometry and problem operations. To make the file even smaller, select "delete all toolpaths" via the Cam Plan tree operations icon. Also, set display to wireframe, and in the Part Object, via the View menu, select "Clear Facets". You then have a pretty lean VX file to send and using WinZip or WinRar will make it smaller still. We will get there for you! Have a good weekend

gjohn — 2006-10-06 16:43:02

PCR 19095 diary created on July 10 09:24:12 2006 I had first said that offset 2d was jumping around and not staying in the cut like it should in 12.41. In 12.5 it started the crash issue. I know that I had submitted a pcr as well as spoke to VX about it at the IMTS show. I know that you would like samples of customers issuues but it takes a long time to download files. Customers are usually pressed for time enough without having to send samples in everytime there is an issue. Did any one try and make a test to see what it is doing? If so you would see that offset 2d will start a cut on a level make a few passes, jump down to the next level make a few passes, then go back to the previous level and finish cutting that level.(see pic) I will get you a file this weekend.

bobf4fun — 2006-10-06 14:46:33

Aarron, You can post anything you'd like on the forum including complaints and negative comments but please, give us something to work with... We can't find any PCR's or emails from Lake City regarding Offset2D machining. Here's what I've found from your folks regarding CAM requests: 1) Tool change output definition 2) Pecker Tracks: Although not detected in simulation of machining the actual tool makes short dives into the steel 3) Unsupress multiple: When making different versions of NC program it would be nice to be able to multiple select supress or unsupress.

billator — 2006-10-06 10:26:04

"Offset 2d rough is still not working right. It jumps around too much before clearing out material that should be cut. have to set to cut regions to NO which makes it jumps round on each level before going to the next level. z" Cut by region enforces QM to do regionwise optimisation that for complex parts can potentially reduce more than 10 times the length of required links. That switch tells to do levelwise or regionwise linking. What I don't understand, from this a bit incomplete description of the problem, why did you need to enforce the product to do so? Maybe when the PCR will be complete will be easier for us here to understand the entire problem.

bobf4fun — 2006-10-06 09:44:07

Hi George, Dr. Dan and I searched the PCR database for your issue but we couldn't find anything (other than the PCR issued on October 4/06). Please tell us which PCR you're referring to so that we can track it down. A word of advice... if you're submitting PCRs, please give us sample parts and/or pictures which illustrate the current problem and your desired solution. The most recent PCR # 19462 doesn't have enough information. Please give us some sample parts or pictures. "Offset 2d rough is still not working right. It jumps around too much before clearing out material that should be cut. have to set to cut regions to NO which makes it jumps round on each level before going to the next level. z"

ChrisW — 2006-10-05 19:12:05

Hello again LC chaps You are clearly passionate about getting this problem fixed and it is obviously frustrating when things go wrong. I am sorry that it has been such an acute problem on your projects. I need you to help me to help you. I cannot find a PCR record that describes the QM Offset 2d rough behaviour that you are experiencing, except for PCR19462 which was only just submitted (Oct 4) and is currently not supported by an example file that demonstrates the nature of the problem. We do not pull a regression in the software deliberately of course. Sometimes, the kernel will have been moved-on by such an extent that a fault requires some serious coding to fix it as we cannot "rollback" to the earlier code. So, please let us have as simple an example as you can for PCR19462. The senior developer of QuickMill is one of the most innovative and ingenious developers in the industry. I feel he has met very difficult challenges and consistently provided timely solutions. Everybody at VX Corp is doing their best for you.

GorangVX10 — 2006-10-05 12:40:34

Chris We have 12 seats of VX. I'd bet we are the largest user in Michigan. When gjohn post something on here he is speaking for all of us who are frustrated with VX. We are not asking for something VX has never been able to do. We are asking developers, programmers, etc... to stop messing up functions that used to work!!!!!! I don't find 12.55 overall or otherwise to be a really good product, VX keeps regressing. The result of the offset 2d rough not working is longer cut times on our CNC's. For a product like VX who is trying to compete with Delcam and such, longer cut times is not a good thing. I know I'm not supposed to post complaints and negative comments on this forum, but I believe this gets more attention than our numerous PCR's we've submitted. Aaron Gorang

Paulverisor — 2006-10-05 12:35:39

Is there anything that can be done to get the problem that our CAM people are running into fixed? In version 11.5 the Offset 2d rough worked without the tool jumping around. We are running into a problem with a lot of broken tools, we just do not have the time and money to spend on this VX BUG. In the near future our shop will need to get out a lot more dies per month. If there is no resolution soon we will be going back to version 11.5, which I'm not really excited about.

zw_admin — 2006-10-05 11:33:20

I use it for reverse engineering, mainly for taking point clouds to NURBS. It's a very nice piece of software. You should check out their website if you are interested. A side note, they have great service, almost on par with VX

gjohn — 2006-10-05 05:55:26

Thanks for the offer. I can scale it in vx its just that it should not be metric when everything is set for inch. On another note, what do you use Geomagic for?

zw_admin — 2006-10-04 14:03:45

gjohn, If your stl is less than about 5 MB and not top secret, I could try to scale it for you in Geomagic. No charge Just let me know what you need. Clinton

ChrisW — 2006-10-04 11:04:12

Hello gjohn As every VX'er knows, the release of v12.55 has been delayed for a long time. We had some fundamental issues to resolve in order to restore acceptable levels of robustness and performance. Rather than delay the release more, v12.55 has been issued without incorporation of numerous PCR fixes and modifications that we have already coded but require further time to complete QA testing. These fixes will be delivered in v12.60. I do not know the PCR numbers for the specific problems you mention but I can say that we try to prioritise those that are the most important. There will always be something omitted from a release that someone somewhere was really hoping to see, but I hope you will find that overall, v12.55 is a really good product that gives you excellent value for your investment.