Hey guys, I think we're overthinking this specific issue... It's not uncommon to let these things to slip through the cracks... Those who believe this needs to be fixed, put a formal request through your dealer and follow up with them. It's not a big deal to fix this... Just needs to have visibility on their likely long to do list... Jm2c

They do. https://www.glassdoor.com/Reviews/CNC-Software-Reviews-E274447.htm

A week or less of work of a software development intern and they can fix the entire product. Tabindex fixing is not difficult, just boring...

Unable to open the port means a few things: The port is being used by an application... That could be Cimco edit itself... The port is damaged or non functional (Drivers, eletricaly damaged...) The port is not being recognized by the O/S

Not sure if this is a bug from V7. Cimco store settings on AppData folder, in the user profile... Depending how you did the cleansing on your PC you deleted the files...

It may be that someone at CNC forgot to check the value of the TabIndex property for each control in the Visual Studio forms... It's a boring job and takes some significant time to sort all them out in a big product like Mastercam... Unless they assign a software development intern to do it, I doubt it will get fixed soon... Anyway, if the problem is in this form only, it's an easy easy fix... But you should report it... I usually spend a lot of time checking the TabIndexes in my applications, and I only do it when the mechanics of the UI are done... When you're trying to get the product out of the door ASAP it's easy to forget about this... Specially because most users don't even know what TAB does on Windows Forms...

Is that Eagle an Ingersoll Eagle? Is it the model suitable for graphite machining?

One thing that set high end trunnion based machines apart is that the majority of them (never heard about one that does not use it) have two servos on each side, in a tandem schema. This nearly eliminates torsion, allow high feeds, generates less heat,higher payloads and facilitates overall thermal stability.

Yes. Go to settings... There's an option there related to backspace merging lines... Can't tell exactly which name as I use it in Portuguese and I'm out of the office now...

APT is that kind of rock solid format most systems that are in the business for a long time enjoy to crunch. They´re initially build to deal with it and only it. VERICUT? An APT cruncher. Not a single G/M code it reverses goes unnoticed. Even a function set to be ignored is printed in the APT stream as PPRINT command or just ignored. VERICUT is an APT simulator since day one. What it does today is to reverse G-Code into APT and then process APT. ICAM? G-Post? IMS? All them convert a native CAM output to APT and process APT. Then they post G-Code from APT. There are many advantages in using proprietary neutral formats, and I think CNC got it right with the NCI. They can enhance their format, create special codes for specific functions without being tied to a legacy format like APT. APT is OK and as long as you have the PPWords to complement it, you can do whatever you want... But it is an old language created in the 50´s/60´s when things we see today in machine tools were not even science fiction. That´s why it is so flavored today, and the APT code from one company may have lots of differences compared with the code from another, due to the PPWords and flavors. With proprietary neutral files like NCI, the software vendor has freedom to implement things the best way in their architecture.

Important to mention that a number of NCI unique tokens does not exist in the standard APT. That means these commands would have to be converted to custom PP words so that APT based post processors could properly convert it. Simple example: In APT the MULTAX/ON statement leads one to think your are going to start a simultaneous 4/5 axis motion. Wrong. It is used also for 3+2. So how do you tell you're using 5axis simultaneously then? You need a PP word... In Mastercam NCI there's a specific NCI code that triggers multiaxis mode... Same for polar milling, axis substitution, etc... Such things are not covered by standard APT... Or aren't covered in a standardized format... So you need a PP word... APT is a flavored language... A translation tool from NCI to APT needs to convert the unique NCI codes to some custom PP words... In fact this is just a remark, because all 3rd party PP tools working with Mastercam that are APT based already do that... Examples: ICAM, IMS, GPost...

Don´t be so sure next time you come around... Consider yourself a lucky guy for what you got here with minimal input from your end and without any evidence you´re a legit user... Just saying...

You're setting it wrong. I agree with 5th axis that safe retracts in between index moves are a safe practice in post processors and that the majority of users are OK with them. It seems you have a training issue, which brings another question... Are you talking to your reseller? Most common thing in the world is people not well trained bashing their systems because they don't know how to properly use them or don't have much experience with certain aspects of machining.

I read your post again and I think I misunderstood your question. Sorry about that. Have you checked the machine programming manual?

I might be wrong about this in the context of your machine. But with DWO you don't need to enter C angles in the workoffsets table... You don't use it as a regular workoffset schema, where your have distinct XYZABC values for each workoffset. With DWO you set, for example, G54, with the machine rotary axes in their home positions (0) and the XYZ where it is supposed to be with the rotaries at 0. You do it the same way you would without a DWO option in the control. In the program you call a single workoffset, moves the table/part like you want and call a DWO command to update the zero location. You don't have to call multiple workoffsets (54,55,56,etc) for each ABC combination. It might be slightly different than what I put tough.

But I'd recommend this one. http://www.cadhistory.net Go to the table of contents. You're going to learn about the roots of this stuff. Read it myself entirely, 3 times. If you know the past it's easier to understand the present.

Yes... The title would be something like "Daddy knows it all - How I was kicked out of the eMc forum"

About the complacency in CAM, it exists and is more tolerated than in CAV. Machine builders are way more innovative and move in a pace that the software industry don't follow yet. There's always a workaround for the lack of something in CAM. In the end you can always code by hand if necessary. The same is not true in CAV. You simulate or you simulate. There's a lot less tolerance from customers in regards CAV functionality, so these companies usually try follow the pace of machine builders and CNC programmers, not CAM systems. In the CAM world most players do stuff just because a direct competitor did it too. It's like that old story "I bought system A because my competitor uses it too." It's amazing how predictable humans are.

I think every product, skillset or service a company or someone provides is somehow supposed to cover a niche. Like "This is what we're good at and must get our main focus and resources". It's a perfectly valid business / strategical decision if you ask me. A system choosen today may not be the best tool for our business tomorrow. Simply put different strategies on each end. Because strategies change along the way. The market dictates them. Competition forces us to change. A shop may have to embrace MTM in order to survive tomorrow. But for decades 3/5 axis milling went fine for them. That's life. So IMHO there's a place for each tool for a given slice of the pie. I believe CNC is trying to explore the most some specific slices, not the entire pie. (Not sure if this is even possible). For 14 years I have witnessed MC to loose the opportunities they missed for MTM. It's perhaps way too late for them. And we have to consider that maybe they're fine not being 1st class in MTM but doing other stuff well. Their sales surely not tanked yet, otherwise they would be doing something about it. We should refrain from bashing them for their strategy for MTM. It's a business decision, backed up by numbers. In the long run, they may have to do something serious about MTM, but for now I think they're fine like it is. I thought about how many times I bashed them about it, and part of it was that I was projecting my personal goals on them. That's intellectually unfair to the least. I suppose it would take them at least 10 years to develop and consolidate MTM technology in their products, and to build a name in this field. Those who started in the early 2000's are harvesting results now. There are lots of proprietary technologies in those products and component technology will help, but won't do miracles for CNC if they decide to prioritize MTM one day. In the end it's the old story: those who innovate and go to market first will usually take the lead for a long time. The history proves me right, and I'm glad that it works this way because it fosters the progress of the human kind.

By the way way... Out of curiosity... Any of you guys have TeamViewer installed in your machines?

I´d second that strongly!

Glad to hear about a comparison between the two... Not much information about this is available, and as a VERICUT user I have a lot of respect for NCSimul and I wish VERICUT could have some of its features... Whoever told you that, was uninformed. VERICUT don´t have a true solids engine, it also uses tesselated data. They have nice converters to transform B-Rep data (STEP, PRT, ASM, etc) into PLY models, which is a different sort of STL format... But it´s all tesselated.... VERICUT graphics engine is so simple in this sense that in the past it used to perform better with cheap graphics cards since they use the Z-Buffer algorithm to represent pixel on the screen. Not sure if this is still a fact. OpenGL in VERICUT is not the same OpenGL we see in some true CAD systems... It´s just an acceleration solution... But it does not improve graphical output... in fact it often makes it poorer for the same speed settings. You have settings in VERICUT to set the quality of the cut stock in OpenGL mode, the better the quality, the worse the speed, as any other system. NCSimul AFAIK uses OpenGL in a more elaborated way since it was written from ground up for Windows O/S with that in mind. But it´s all speculations from my part since I don´t know NCSimul. About NCSimul being worse than VERICUT for collision detection, I highly doubt it. It seems to be just FUD that was spread around. People in the CAV business make a living providing safety. NCSimul is not a low/mid-end CAV solution. Thanks for you feedback!

1 - Take a honest look into Mastercam MT. If they can cover that machine, you certainly CAN program it well. If they cannot, then look somewhere else too. It's important to make sure your reseller can support you on MT as well. 2 - You're French. That's an advantage IMHO. Do yourselves a favor and take a look into NCSimul package as well. You may like what you are going to see. Being in France you're supposed to get the best support and user base and demos in your very own language. In your shoes I'd take advantage of this moment to evaluate most of my options so in the future I'd not be wondering why I didn't pick that one... 3 - Training curve today is not the nightmare it used to be. Video based training, remote support tools like TeamViewer and online courses like Mastercam University make a whole lot of difference. Most systems have similar curves for the basics, and different ones for advanced stuff. But I would not say it takes an extra 6 months to learn something in one system vs another. This is all relative because it depends on the user as well.

Try different flow control methods... Keep in mind some are pinout dependent to work correctly...

I think both mainstream high-end solutions, NCSimul and VERICUT can handle superimposition through a technique called axis coupling or axis linking. It basically consists in making one axis to be "attached" to another so when the master moves, the slave follows. A simple example of this is used in MoriSeiki NT machines with a dual spindle. In such machines you don´t have a C2 axis on the counter chuck. It´s always C. So you either activate one chuck or another as the main C axis or you can couple them through a M-Code. When you do so, whenever you program the C axis, both chucks move together, with opposite directions, in synch. NCSimul and VERICUT can handle it. I presume the same technique is used to whatever axes combos you might have.