As mentioned in the other similar thread, 2018 Beta was shipped with temp keys. The dialog box above is clear that temp keys are not converted. Like you said, if it is a OEM key, an investigation needs to be done.

This process is not valid for generic keys issued for Mastercam. The update key works flawlessly for products purchased through Cimco or their resellers.

Any Haas specific cycles on you program? In not, switch to the Fanuc filter and see if times are closer. Even if you have Haas cycles, try with Fanuc or ISO milling filters. Backplot filters do influence toolpath statistics and there are known issues with some filters. If Fanuc Milling or ISO Milling gives you a better time, please send your Haas program to [email protected] describing your issue. I'm sure one of their Russian PhDs will fix it. They did it for us several times for a few filters and they actively enhance or fix their filters. Make sure also that your units and feed modes are correctly set in the machine settings within the editor.

Double post... sorry...

Which filter are you using?

Inverse time is tied to a time constrain. It has to do with the motion occurring based on a 60 seconds constant. Some controls consider the value 1 second rather than 60. Inverse time was invented in the 60's when controls didn't have TCP and could not handle feed calculations. Feed interpolation does not have anything to do with time. The constrains are the initial and the final feedrate. Last but not least, inverse time on a ZX toolpath (Lathe) ? Lathe mode don't even support G93. Hypothetically speaking, if inverse time was the answer, then in my example above, I'd have to have lots of G1's with different F's. See now why inverse time is not the answer?

Nope. We're not talking about the same thing. Siemens supports inverse time as well just like a Fanuc would. And it has nothing to do with the above.

James, I have a doubt about how this reasonably complex subject could be handled in a Fanuc or Fanuc based control. I believe that there´s a way, I just don´t know how. It´s called feedrate interpolation - Here we go - I extracted some images from Sinumerik manuals and commented them so we can have a good understanding... Sometimes, it would be interesting to be able to interpolate your feeds just like you interpolate coordinates. Basically, in the majority of CNC controls, if not all them, if you say for example: G0 X0 Y0 Z0 G1 X100 Y200 Z500 F500 Essentially the control will interpolate the axes, calculating the feedrate for every servo so that all axes reach the final destination together right? But the majority of controls don´t allow you to do that for your feedrate. Let´s see this simple example in a simple 2 axis lathe: G0 X500 Z0 G1 Z-1000 F0.5 I think we all agree that the machine will do a parallel motion along Z axis with a constant feed of 0.5 units/rev - That is, when I´m at Z-500 the feed will still be 0.5 units/rev right? Regardless the Z coordinate, it is always the same feed. Now let´s imagine that for whatever reason, you need to interpolate your feedrate? Let´s say that you have a carbon steel part mixed with Inconel inlays, or you need to progressively vary your surface finish along the 1000 units above, or that you have a raw material that is very difficult to cut in the ends but Ok in the middle. Or even, you need to have a more sophisticated method to control chip break, let´s say, you have a long boring bar, needs to enter gently in the material to avoid insert damage, but can gradually increase the feedrates while the bar moves into the material because you need to have short chips while deep inside, so that they don't accumulate in the rear side of you boring bar and make it to bend... So in the pic below, we can see the concept of regular feedrate control (What 100% of controls do support) Vs interpolated feedrate: Now let´s visit that simple piece of code again: G0 X500 Z0 G1 Z-1000 F0.5 What if I wanted to have the feedrate as 0.3 units/rev at Z-500 ? Let me be more comprehensive here - What if I wanted to have the following feedrates at the given coordinates, for the same geometry: Z 0 = F0.1 Z-100 = F0.14 Z-200 = F0.18 Z-300 = F0.22 Z-400 = F0.26 Z-500 = F0.30 Z-600 = F0.34 Z-700 = F0.38 Z-800 = F0.42 Z-900 = F0.46 Z-1000 = F0.5 And what if the feedrate had to be interpolated, not programmed by a series of G1 commands - That is, at Z-50 the feedrate should be half of what it would be between F0.1 and F0.14? And so on for every micron Z axis moves? Ok, one may say, well, this can be programmed by thousands of G1's with different F values... Ok.. let´s have a look in a more useful example... I wanted to start with a simple lathe example in order to share a common milling problem in machines with MTM capabilities, but if fact it applies for everything that has a rotary axis... In the problem below, we want to machine a groove or simply use the C axis of our machine (It could be a cylindrical part in the center of the table of a HMC as well) so that with a face mill or a large bull mill we could open a wide groove in the part, by performing a spiral cut from the O.D. to I.D., using as many C axis turns as we want. Typical scenario would be to avoid a regular turning groove tool (Wide inserts cause vibration and small ones would make it time consuming) or special tooling to open a wide groove in a super alloy. Let´s suppose that better chip control is also necessary. Well, there´s a problem with that. Because we´re cutting using a rotary axis, the tangential speed plays an important role here. The feedrates we would use in linear axes are not suitable for tangential machining, and to make it worse, they´re dependent of the Ø we´re cutting. That means even if we convert a feed of 1000 mm/min to a diameter of Ø400, this feedrate would not be suitable to cut a diameter of Ø280, because while cutting the last the rotary would complete a full turn in less time right? So if you have a scenario like that, your feedrate needs to change for every second of angle the rotary moves, since it is a spiral motion towards the I.D., your tangential speed is constantly changing. It´s highly desirable that you keep your tangential speed constant, otherwise you won't be able to keep a constant tool load, and you will reap all side effects that comes with that. And this is where feedrate interpolation makes a huge difference in the result. So in a Sinumerik control, we would achieve the result above with our simple lathe program this way: G0 X500 Z0 ; Start position F0.1 ; Initial feedrate at Z0 G1 Z-1000 F0.5 FLIN ;Interpolate feeds - Sets final feedrate at Z-1000 FNORM ; Restore regular feedrate control I commented the pic below, I hope it´s clear for everybody. BTW: James, I know you understand all the stuff I put above. The reason I was very didactic is because not everybody understand Siemens code and also because due to my language limitations I wanted to make sure I was understood. So I have this doubt: In a Fanuc control, how can we address this problem - I´d like to learn: How we interpolate feeds in a simple straight motion like that turning example? How we interpolate feeds in a rotary motion? This is an old doubt I have because I bumped into the situations above in Moris, Mazaks, and never found a "clean" solution. How a Fanuc expert would handle that?

Download the basic and advanced Sinumerik programming manuals. Most powerful control out there IMHO, not necessarily the most complex to learn. For subs, make sure to use "RET" to return to the program that called the sub, rather than using "M17" as return code. The last disables G64, which provides smooth motion. Siemens commands make sense and are usually acronyms. Like CFTCP, "Constant Feed Tool Center Point." I love Sinumeriks and like to think I'm deeply versed on them. If you need help, drop us a message here. It will be a pleasure to help.

Send me your email via PM and I'll send you a proven pinout + DNC-Settings.

I´ve seen them to try the same subscription approach with SpiroGroove program generator... Guess what.. never took off... They´re tooling builders... People usually don´t put up with technology lock-in for their cutting tools... Guess what... Probably some 25 years old machining marketing PPT genius told them otherwise...

VERICUT doesn´t care much about high-end graphic cards... It uses Z-Buffer technique to perform pixel representation... It often plays better with cheap graphic cards since higher end ones don´t put as much effort in solving low complexity data as they put in high end graphics... Weird but true... OpenGL Turned on in VERICUT makes the graphical details much coarser (though configurable to a certain level) and therefore it speeds up the view graphics. Jm2C

J, I got a new workstation and probably forgot to transfer some files to the current one... Would you mind to convert that image for me again? The link is still valid, it´s just before your post... Probably attachments were deleted on site migration... Tks!

Wireless is OK with Moxa... Big advantage is that DNC Max can connect directly to Moxa and and Quatech devices without intermediate drivers installed in the server... Moxa quality is Ok... But 2 years and they're gone... it used to be like that previous hardware generation... I suppose it is better now... Best brand in my opinion is COMTROL...

Send it over to QC.

My take on this... If a custom tool is required anyway, I'd start with a custom tap. 2nd option thread mill. I'd get a tap made by one of the big players (OSG, Emuge, Titex, etc) because they master this sort of profile and are well familiar with the standards.

A mod should remove the Sim number above...

B.S.

I built applications that integrate systems with each other... A good example is that we store tool lists in cimco Nc-base, and every day my application finds which tool lists, assemblies or components were modified in WinTool and create fresh tool list PDFs for all programs in cimco database that reference an affected tool list from WinTool. I also wrote an application to integrate cimco ncbase with our SAP ERP. Engineering drawings revised by our engineering worldwide, if any program in ncbase references a drawing that was revised in SAP, I lock the program in ncbase and add a file note in the program saying the revision level does not match SAP´s... such programs cannot be sent to or requested by the machine. This would be an example of making SQL applications talk to each other... In these two examples, Crystal reports can't do much because it requires specific logic to interpret and manipulate data... requires an application... For reports, WinTool comes with a report builder, Stimulsoft. The principles are the same used in Crystal reports...

I'd love to know more about it Ron... Honestly I don't think it is healthy to know only one tool in the box... There are many rumors and one of them is that the other does not play well in terms of stock accuracy for large parts... But as I said, all rumors... I'd love to have an opportunity to walk the walk... In my experience with our current software, it's pretty doable but not a breeze to process our complex parts... I'd say it's the same you guys experience with the Mastercam with hundreds of operations and complex models... I'd say it's pretty smooth for 95% of the equipment out there... but the WFLs and our large parts just push it to the limits... I think a side by side comparison, same dataset with our parts, programs and tool models would be the only way to say what works best for our company...

Our products and machines are a terrible combination for verification software. They're large, (2500mm long, O.D. 1600mm) with a mix of turning with B axis and a bunch of milling. This turns into massive memory usage...

The new engine to handle variables is the culprit behind our problems. Our WFL VMCs have THOUSANDs of variables, I think at least 5000... And this brought some issues to the surface... For simples machines or even complex controls with lean variable sets, it´s not a big deal... We´re seeing crashes as well while moving sectioned models, and zooming into them... Got a new patch today... keeping an eye on it...

I've been asking for this low hanging fruit to be implemented in CIMCO Edit for 5 years... There's a ticket I opened in Phabricator to get it implemented... I hope they hear you...

Wise man. Wait for 8.0.2 or higher. It's not awful but not as stable as 7.4.2 Lots of crashes and performance issues for us. In one case the reset time with our 3 WFL VMCs went from 5 seconds to 4 minutes. They fixed it and sent us a patch though.