I´m afraid your operators have a point there. Poor planning (And used to have a lot of it) creates a lot of inneficiency switching jobs. One of the things that helpd us were fixed toollists for families of parts. Balluf chips (RFID) also helps if tools are measured and values are written on the presseter first. In our case we mixed all these efforts. But planning is the most important part IMHO.

Why would you want to open a WordPerfect file in a CAM system?

Oh sorry if I passed the impression something was better than something else. I swear that it was not my intent in this post. These system are very similar when it comes to crunching APT. Also, when I said only ICAM and NCSimul can solve this, I meant in the entire scope of the original post: post-processing, simulation and optimization. By the way: Where did I say "best" in regards which system is better?

Just a note: ICAM, NC-Simul can offer: PP + Simulation + Optimization IMS: PP + Simulation G-Post: Only PP Only NC-Simul CAM and ICAM can solve this to the best of my knowledge.

CAM Systems supported by IMS: (Anything that outputs APT + Non-APT systems through interfaces CLData2APT) https://www.ims-software.com/sites/default/files/datasheets/Datasheet_IMSpost_EN.pdf

+1 to Ron´s comments. Considering you have 3 CAM systems and a myriad of machine tools and controllers, I´d suggest you to bet your dollar in an universal post-processor solution. Some names comes to my mind, in the respective order: ICAM NC-Simul (Spring) G-Post IMS Intellipost All them have post-solutions that can translate neutral files. Not sure if NC-Simul can handle Mastercam NCI, but I´m sure 1 & 3 can. The 4 solutions are based on parsing APT data and translating to G-Code. However, Mastercam does not have a native APT post-processor, so these applications have interfaces that can parse NCI and convert it to APT, and then from the APT file, they build G-Code. From the 4 above, I believe ICAM is the company that has more customers using Mastercam with their PP suite. I can be wrong about that, but in case I´m right, that means they´re more likely to be up-to-date with latest versions of MC software, advances or changes in the NCI format, etc... AFAIK, Mastercam support by ICAM is a serious part of their business strategy. CAMplete AFAIK also process APT, and I think they have an interface that translates NCI2APT... This is how they process Gibbscam and files from other CAM systems... The system has either a direct interface with CAMplete or they have a CLData2APT post-processor (CLData = NCI in other systems) that enables the CAM system to output APT when APT is not their native CL format. Higher-end systems (Read older systems) like NX, Creo/CAM, CATIA, NCL, CADRA, etc already use their own APT flavors, so they don´t need special interfaces to interpret their native formats into PP systems that are APT based. They need however a PP table to expand the set of PP Words they can interpret, allowing the PP to understand some extra APT dialects (Your own customized words) that are not present in the core APT language. AFAIK, these companies are top notch in customer service, but honestly I don´t know much about IMS. If I was in your shoes I´d try to understand a bit more their post-processor language, that is, the language they use to manipulate APT statements. It´s their equivalent to MP. ICAM uses what they call "Macro language" G-Post uses what they call FIL (Factory Interface Language) - It´s similar to ICAM´s IMS also has a language. I don´t know its name. I don´t know how Spring handles it. There´s a chance they offer only custom posts written in C++. If that´s the case, I think your tweaking abilities are limited. It won´t be a generalized PP builder like ICAM, G-Post and IMS. But please check because chances are high I might be wrong about it. There´s IMS Intellipost as well. If memory serves me correctly, they can also provide interfaces with Mastercam and most CAM systems out there. Their solution is very similar to ICAM and G-Post, whereas G-Post does not offer anything beyond PP, and ICAM and IMS can go as far as providing you the simulation integrated with the PP. HTH

Don´t take it as an offense, but it seems to me you want someone to do your job for you. All factors you´re attempting to gather above are relative. They depend on the skillset and the size of your budget, your machinery, etc. If you guys are a 3 axis shop, and are moving to multiaxis or millturn (Most common reason people go after verification software), it´s going to be a pain regardless the software you use. In the beginning at least. You don´t know a lot of stuff and you don´t know what you don´t know. In this phase, first thing is to blame the software, regardless its brand. We have an old programmer here who joined us after 10 years away from programming. He was a NC-Programmer here 10 years ago, worked 6 years here as a shop supervisor, was let go a year ago and returned this year, joinning our team. When he was the shop supervisor, our team (The team he was a member of years before) was a bunch of idiots that could not make good programs. (Operators were treated as babies on his watch because he used to believe that sleep with them was good politics - Better be up on arms against the programmers... - Long story...) He screams with his monitor on a daily basis and is having a hard time to learn it all. When he worked as a programmer here, he used PencilCAM and AutoCAD to drive HBMs. Now it´s a totally different world and learn to program an Integrex or a Mori NT (Don´t get me started on the WFLs...) it´s painful. We have good laughs watching him to fight with VERICUT - It´s an excellent product, everybody likes it, but he does not get it yet, so he blames it... There´s no flawless or piece of cake to learn CAx software. It requires skilled people, continuous training, proper customization and a will to master them. Then you get an old school guy to learn all this, he´s always trying to shape the world to his way, and not the other way around. (By the way this board is a proof that there are tons of old school guys that can grab it in an eyeblink too ). So then people come to these boards and expect a matrix this vs. that. Is not that simple and you´ll have to dig it up a bit more. No one here will tell you one is better than the other by a long mile... Both are excellent and have excellent support.

There are a number of useful discussions about it... It's just one of those subjects that always end up nowhere... What machines and part envelopes you expect to cover? Both are excellent products. Search for NCSimul and pick the threads you like...

here we go again... Please, do a search in the forum or Google it again...

Don´t worry about working with other products... They´re all great stuff... I imagined you shared to help other guys in a similar situation... We used to have this problem with driven points in our WFL VMCs, then I changed some switches in this macro and we never missed an error in our code or in VERICUT ToolManager anymore... It´s good to share these things... most software these days are highly customizable but seldom we spend time reading the help file...

In case you want to change Vericut behavior in regards how driven points are parsed, there's a macro you use in the start of processing that gives you low level control about how Vericut must behave when reading a driven point, or even in the lack of one defined in the tool. There are switches that can be passed to the macro.

My pleasure Frank. I´m at your disposal. If you want to have a phone call so I can explain you some of the quirks we learned in our implementation, send me a PM. It´s always a pleasure to help people to start right from the ground up and avoid the mistakes we make in the beginning. Daniel

Frank, I manipulate WinTool and Zoller databases on a weekly basis. I've written half dozen applications to query WinTool and CIMCO databases. Don't bother to waste time building MC databases if you are going to have WinTool2Mastercam interface. Not a technical constrain, but anyway WinTool is MS-SQL or MS-Access and Mastercam is SQLite. It's like saying your are going from TCP/IP data transfer to save stuff in a file. Besides, their tables don't have much interoperability with each other in terms of how data is structured. They're designed with different purposes in mind.

Weird... When we code software, although there are millions of ways to achieve the same results, it's a logical process. Read this, put it there, sort it, format it... professional development like in an enterprise level as Mastercam, is done using robust code, internal proven APIs... Then sometimes you code something that shows a glitch like this... When you're debugging code, block by block... it never happens... Very hard to reproduce... Sometimes it's even a bug in the framework or at the compiler level... Just saying because sometimes we think people don't care about fixing small glitches but the truth is that often is because they can't reproduce them...

More here: http://www.cnczone.com/forums/opensource-software/297958-notepad-gcode-lexer.html https://community.plm.automation.siemens.com/t5/NX-Programming-Customization/Notepad-customizations-for-NX/td-p/267169

This was my start point... Yes, you can enhance it to provide intellisense... keep in mind Notepad++ is widely used by programmers to automate tasks in several languages... http://www.addyourservice.net/notepadppcncsyntax.php

I don't know but hopefully I finished my application as expected... :B

Tomorrow I'll send you a Notepad++ user defined language file for Sinumerik840d It does all the highlighting you mention, colors... Not that you need to use but it's nice to see Notepad++ doing specific things from NC Programming world... If you like it you can make a copy and change it to another G code flavor...

http://www.emastercam.com/board/topic/84096-tool-management-software-reccomendations/

Notepad++ is free and can do it too.

WinTool admin here... Your efforts in other systems will be pretty much useless datawise speaking... There's a thread here about Tool Management software... It's worth a read... You mentioned Cimco? For tool management?

You need a post-processor tailored to handle it. Probably a miscellaneous value in the operations level.

Funny how there are professionals and professionals. There are people with amazing opportunities, technologies and resources at their disposal, or reachable if they want to have them, but they never bother to walk the extra mile. Some even feel they´re are entitled to the privilege they have, because in many cases they never had to walk the walk and work for years without resources or honing their skills with what they had at the time. It´s a privilege to know people who walk the extra mile just because it´s how their minds operate. People who take pride in what they do and don´t make excuses or a lazy job no matter what.

Not really... If you´re talking about embedded CAM simulation, their algorithms use inverse kinematics to find ABC based on IJK from the NCI... if there are degrees of freedom available, the better for them to find the solution... If you are talking about simulating G-Code, it´s also a breeze for them... If you´re passing vectors, they find ABC as well... if you are passing ABC, then they don´t even have to compute the angles... just move the rotaries... VERICUT and NC-Simul handles this hands down... Their TCPM macros can handle crazy stuff...

If you look carefully to this Zimmermann 6 axis head, you´re going to notice it´s actually ABC. And they´re ortogonal to each other, which means that they fit perfectly into IJK definition... in the machine A0B0C0, the vectors are 0 0 1. I could bet my best beef these machines are programmed simply with Sinumerik TRAORI A3,B3,C3 or Heidenhain TN... only the vector normals and XYZ are passed to the CNC... the PP don´t do a thing... just prefix NCI coordinates with X= Y= Z= A3= B3= C3=... for example... In the example below it is TRAORI because it´s a Sinumerik 840D Powerline control.... More about these heads here: I think that the original video I posted, it´s actually a table / head... it gives you the wrong impression...