What's new
What's new

Esprit Cam, a review

What’s next after we standardize posts across CAM companies @EmGo? Do we try to convince all CAM companies to use the same file type next, so we can open CAM files in any CAM system and edit paths and post programs?
There are programs out there that can post from multiple CAM systems. I am not certain.....but I believe most cam systems can output C/L data for toolpaths . I believe that data is then converted using the post which also adds in G and M code logic???
Some larger companies run multiple cam systems but post and sim from a 3rd party program. I am not sure what that 3rd party program is, this is something i have not done....if someone here works for a company doing that they could chime in.
 
I don't know why this concept seems to be so difficult. It's already been done with graphics display, as in OpenGL. It's been done with printers, Postscript. It's been done with plotters, HPGL. It makes life easier for everyone, software companies and users both. Creativity has not been hampered, FrameMaker is still one program while Word is another and Scribus yet another, the world has not become flat and featureless because of this and no one is financing their cadcam software with postprocessors. The way things are sucks but hey now, whatever we do let's not cooperate, Uncle Miltie would get angry, lie on the floor and throw a tantrum with his widdow fisties and feetsers.
 
Elaborating on that a bit, as well as my own previous post, I'd say they need to split that focus maybe some training, sure, but also on improving their post systems. Like I said, a complicated and/or obtuse post system/post dev environment is going to make for lower quality posts no matter how good the dev people are.

I have bias because it is my most familiar cam system, but Featurecam uses a post editor called XBuild, and while certainly not perfect it is head and shoulders above anything else I've seen.

I can compare this to Camworks directly as I helped one of my guys make some solidworks cam posts a couple of years ago, and that was fucking horrendous in comparison.
Training, improving their post system.............................if a reseller is losing money building posts they need to reevaluate.

Experience across the board. I have more experience in CAMWorks and I'd disagree with you, but that is because it was the first CAM system I used, was taught in as well as playing around in the posts and used to do all my own editing, I've messed around with SurfCAM and MasterCAM as well and would say it was terrible in comparison but have heard many say they are the easiest.
 
There are programs out there that can post from multiple CAM systems. I am not certain.....but I believe most cam systems can output C/L data for toolpaths . I believe that data is then converted using the post which also adds in G and M code logic???
Some larger companies run multiple cam systems but post and sim from a 3rd party program. I am not sure what that 3rd party program is, this is something i have not done....if someone here works for a company doing that they could chime in.
CAMplete, I'm not super familiar with the process but I believe you do post your CL data from your CAM system and open it in CAMplete and can post from there, but now were right back to posts, you have to pay CAMplete for a post and from what I've heard is far more expensive.

I was more saying a common file type all CAM systems would read, CAM data would be shareable across platforms, for instance CAMWorks CAM data is saved within the SLDPRT file, if I send a MasterCAM user my SLDPRT file, why can't they see my CAM data and post it?

......................obviously this will never happen, just saying, these are competing companies that are in business to make money.
 
I don't know why this concept seems to be so difficult. It's already been done with graphics display, as in OpenGL. It's been done with printers, Postscript. It's been done with plotters, HPGL. It makes life easier for everyone, software companies and users both. Creativity has not been hampered, FrameMaker is still one program while Word is another and Scribus yet another, the world has not become flat and featureless because of this and no one is financing their cadcam software with postprocessors. The way things are sucks but hey now, whatever we do let's not cooperate, Uncle Miltie would get angry, lie on the floor and throw a tantrum with his widdow fisties and feetsers.
There's some disconnect in your comparison here though. I do understand what you are saying, but with your comparison, lets say printers, go for a walk and ask as many people as you can what a printer is and it's function, how many people do you think will look at you confused? None, a very common household, workplace item for EVERYONE. Now ask what CAM software is, how many people will be confused? 99%

As big and important CAM software seems to us in this industry, it is very small, non existent to most.

Charging ports on phones, or any device, its annoying to 7 billion people in the world to have to have 5 different charges depending on what devices they have, so it makes sense to standardize.....................
 
No, I fully understand that the MTB is not the CAM manufacturer, but from a practical standpoint the problem is when and more importantly WHERE the post validation happens: you can't verify the post if you don't have the machine. While software is relatively inexpensive to ship to another location, people and machines are not. Who has more DMG NTX1000s and associated NTX1000 engineers sitting around and able to spend a week proving out a post, DMG or Hexagon? DMG or Autodesk? DMG or Mastercam? etc etc.

If any MTB (besides Haas who are already seemingly doing a decent job, at least with Fusion) promises to ship their machine with a fully functional, vetted post for any given software, I am personally putting that machine at the top of the list. So while the MTB can certainly legally wash their hands of any responsibility, it's pretty pathetic that few if any of them are putting their hands up and saying "HEY BUY OUR MACHINE BECAUSE WE CAN GUARANTEE YOUR POST ACTUALLY WORKS PROPERLY, FOR WHATEVER SOFTWARE YOU WANT".

The whole "you get a custom post with our software" thing we get from the CAM companies is really "we're doubling up on our own work to deliver a worse product at a much higher price".
DMG Mori is a partner with esprit, the NTX comes with Esprit on the control. They do guarantee that it works.

But esprit E20XX is cumbersome, aged, and hard to use (also tool building for mill turns is a total shit).
The esprit edge posts for these machines are horribly broken, and the weird thing is they seem to be getting worse, not better.
 
I was more saying a common file type all CAM systems would read, CAM data would be shareable across platforms, for instance CAMWorks CAM data is saved within the SLDPRT file, if I send a MasterCAM user my SLDPRT file, why can't they see my CAM data and post it?

......................obviously this will never happen, just saying, these are competing companies that are in business to make money.
This can't happen, it's not even a possibility. Each software has different functions, different parameters, etc., which must be saved in the file. Each software would have to include all the other software in order to make this work.
 
This can't happen, it's not even a possibility. Each software has different functions, different parameters, etc., which must be saved in the file. Each software would have to include all the other software in order to make this work.
In a shitty way it could.
it would be locked though, not editable.
I actually could do it now, just hit a function in Gibbs that converts tool paths to geometry(lines, arc....) then feeds and speeds are linked to the geometry.
fairly simple, but it couldn't be edit though by the other person, except if they edit the geometry, and the feeds and speeds.
Not like I could save out a Volumill roughing pass and you open it in MasterSCAM without having Volumill.
 
The metaphor relating printer drivers to cam post processors is not relevant.

Windows drivers are developed by printer companies using Windows proprietary WDK development suites. When was the last time you interfaced with your printer to develop new print routines? Its not an open development methodology in any way, shape, or form.

CAM software is the WDK, made available to programmers in order to develop methods that the post processor compiles into G code via the post processor. Forcing companies to adhere to a standard post processor would in essence be pointless, because there will always be an abstraction layer between the cam database methodology and the post processor output. Adding another layer would just make things as difficult if not more difficult and restrictive for development. I do like the idea of making post processors easier to work with, and some cam software has visual code abstraction/interpretation or management engine type software to facilitate this.

It is my opinion that we as users of CAM should demand to stop using garbage software that restricts user ability to facilitate development. Vote with your wallet as they say.
 
This can't happen, it's not even a possibility. Each software has different functions, different parameters, etc., which must be saved in the file. Each software would have to include all the other software in order to make this work.
I was being sarcastic
 
This can't happen, it's not even a possibility. Each software has different functions, different parameters, etc., which must be saved in the file. Each software would have to include all the other software in order to make this work.
This is ignorant. That's like saying "You can't run a Heidenhain on a Mori, one is german and the other japanese !"

They all do the same effing things. They can ALL output CL code already. Every printer on the planet works differently also, but they can ALL accept Postscript as long as the manufacturer has written a postscript engine for that printer.

It's not only possible, it's BEEN DONE.

Software companies don't want to do this because they are afraid users will be able to change programs more easily. Fine, put up with being ass-reamed by software companies all you like, stop it some more it feels so good ! But don't say it's impossible because not only is it possible, it's been done. It's even been done with machine tools because there were working demos of the concept.
 
This is ignorant. That's like saying "You can't run a Heidenhain on a Mori, one is german and the other japanese !"

They all do the same effing things. They can ALL output CL code already. Every printer on the planet works differently also, but they can ALL accept Postscript as long as the manufacturer has written a postscript engine for that printer.

It's not only possible, it's BEEN DONE.

Software companies don't want to do this because they are afraid users will be able to change programs more easily. Fine, put up with being ass-reamed by software companies all you like, stop it some more it feels so good ! But don't say it's impossible because not only is it possible, it's been done. It's even been done with machine tools because there were working demos of the concept.
Can you convert a Gibbs file to Mastercam? An Esprit file to NX? I'm not talking about running a reverse post processor on the gcode, I'm talking about converting and loading the native file. They cannot understand each other not only because of the different file formats, but also because the files contain different information. The functions in one do not map perfectly to another, so a translation is not possible.
 
They cannot understand each other not only because of the different file formats, but also because the files contain different information. The functions in one do not map perfectly to another, so a translation is not possible.
Can people speak english and french ? and japanese, even ? Sure the feeling is different but you can sure as hell say "go straight for three miles at 10 mph then turn left on jackson street, go two blocks then make a 27* right ...."

We're not talking about moving models between cad systems (which has ALSO been done many times) we're talking the output format, motion and accessory commands in a standard universal manner.

It's been done. Many times. It is totally possible.

Just one example :


"In 1983, the Electronics Industries Association published the standard RS-494, commonly referred to as BCL (binary cutter location) data exchange format. BCL is a means of standardising the formats for NC part programs. Its aim is to eliminate the cost and confusion associated with multiple postprocessors and enable the portability of part programs among different machine tools. In this article we give a short review of BCL and its introduction. We also discuss the nature of BCL data, its implementation aspects and the advantages it offers the NC industry."

There's many more. It never took off for various reasons, none of them technical. It's no more impossible than g-code was impossible.

In fact, in today's world g-code probably would be impossible. This is one fucked up place now. It's really too bad that Milton Friedman's mom didn't have a miscarriage which ended up with that blob of shit flushed down the toilet instead of ruining the wold for the next fifty years.

Here's a corollary : there's tens of 3d modellers. They are all internally different. Yet all of them that wish to be relevant can output r.i.b. files to go through renderman (and whatever that has morphed into at pixar) to be rendered. It's not only possible, it's done all the time in the artistic 3d world. In fact if your program can't output files suitable for a rendering progam to operate on, you are at a disadvantage.
 
Last edited:
Can people speak english and french ? and japanese, even ? Sure the feeling is different but you can sure as hell say "go straight for three miles at 10 mph then turn left on jackson street, go two blocks then make a 27* right ...."

We're not talking about moving models between cad systems (which has ALSO been done many times) we're talking the output format, motion and accessory commands in a standard universal manner.

It's been done. Many times. It is totally possible.

Just one example :




There's many more. It never took off for various reasons, none of them technical. It's no more impossible than g-code was impossible.

In fact, in today's world g-code probably would be impossible. This is one fucked up place now. It's really too bad that Milton Friedman's mom didn't have a miscarriage which ended up with that blob of shit flushed down the toilet instead of ruining the wold for the next fifty years.

Here's a corollary : there's tens of 3d modellers. They are all internally different. Yet all of them that wish to be relevant can output r.i.b. files to go through renderman (and whatever that has morphed into at pixar) to be rendered. It's not only possible, it's done all the time in the artistic 3d world. In fact if your program can't output files suitable for a rendering progam to operate on, you are at a disadvantage.

There is a huge delta between what was output from or expected from a cam system in 1983 and modern cam systems.

If it was only CL data then yes, possible, been done. Some ancient cams systems (not as ancient as you are speaking about) generated intermediate APT and used an APT post processor.

But modern cam generates a lot more, and the posts have to handle a lot more, than just raw toolpaths.
 
This is ignorant. That's like saying "You can't run a Heidenhain on a Mori, one is german and the other japanese !"

They all do the same effing things. They can ALL output CL code already. Every printer on the planet works differently also, but they can ALL accept Postscript as long as the manufacturer has written a postscript engine for that printer.

It's not only possible, it's BEEN DONE.

Software companies don't want to do this because they are afraid users will be able to change programs more easily. Fine, put up with being ass-reamed by software companies all you like, stop it some more it feels so good ! But don't say it's impossible because not only is it possible, it's been done. It's even been done with machine tools because there were working demos of the concept.
how long can you beat a dead horse until its no longer a horse?
 
how long can you beat a dead horse until its no longer a horse?
I dunno ... how long are you guys going to continue to beat on this stupid claim that this can't be done ? when it has been done, in manufacturing, in cadcam, in other areas of computing time and time again, for the past thirty or forty years ?

"It's impossible !"

No, actually, it isn't. In fact it's not even very difficult.

gregormarqwick said:
But modern cam generates a lot more, and the posts have to handle a lot more, than just raw toolpaths.
Point out a few of these magical technical features that modern cnc controls need and which can't be standardized. Thank you.
 
I dunno ... how long are you guys going to continue to beat on this stupid claim that this can't be done ? when it has been done, in manufacturing, in cadcam, in other areas of computing time and time again, for the past thirty or forty years ?

"It's impossible !"

No, actually, it isn't. In fact it's not even very difficult.


Point out a few of these magical technical features that modern cnc controls need and which can't be standardized. Thank you.
it is impossible, for the simple reason that it makes NO sense for any of the cam companies to do it. you can scream at the top of your lungs for eternity about it, wont change a damn thing. dont you get tired of it?
 
Point out a few of these magical technical features that modern cnc controls need and which can't be standardized. Thank you.

Literally anything that is related to machine control rather than basic motion.

Trying to write a universal post system that works just as well for eg. a 9ax multichannel millturn as a 5ax mill as a sliding head swiss is patently absurd, as in by the time it covers all those bases it will be 10x more complicated than anything that currently exists.

You're talking about this from the perspective of cam systems that generated bare centreline toolpaths for 5 axis mills 40-50 years ago. A modern b axis multitasking millturn machine can have literally hundreds of mcodes to control advanced machine functions most of which have nothing to do with toolpaths.
 








 
Back
Top