Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

CAD is OK, but CAM is not a CAM

CAD is OK, but CAM is not a CAM

Yes Bukaj, you are right in regards the Job Manager licensing...

As I said before, I believe PTC had lots of innovation in their product
back 10-15 years ago... they were one of the first companies to research
HSM toolpaths and they have patents about it... but today, what they got
is outdated... looks like everybody else improved and re-designed their
HSM algorithms and Pro/NC ones are now a baby in his first weeks... PTC as
the great marketer it is, still advertising about their 11 old HSM
technology and its patents... what a lot of tosh... there is no
status-quo in technology gentleman...

HSMWorks, a Danish CAM Integrator for Solidworks created a few years ago
a new HSM kernel written from zero, with extensive support 4/8 cores
very well... they designed the software in a partnership with HP back
then... the nice thing on this piece of software is that they have a
distributed CAM services manager which you can install on one or more
PC's on your local area network to enable automatic distribution of CAM
calculations (Even the secretary's machine), and when these machines are
idle or making a low usage of the processor (Like editing a doc in
MS-Word) your HSMWorks seat will search for machines running this
service and distribute the computation of the job for you.

This is a great deal of innovation, because even with everybody else
adding multi-core support on their CAM systems these days, these Danes
went a step ahead and added something that made them unique so far. In
my humble opinion, PTC is not a CAM leader anymore. At the best, they
are followers. You don't see PTC putting things before other companies.
They use to put it years after someone in the market because we push
them to do it... not to mention the time PTC used to charge customers to
develop stuff, like custom cycle functionality... there is not room for
these practices anymore...

Last year Delcam passed PTC in CAM revenues according to CIMData... that
was the first time in years that it happened... 2011, it will be even
harder for the CAM revenue leaders... (and great for us, customers) the
CAM market is boiling... U.S. has a MFG crisis and companies will look
for new systems to be more productive and extract all the potential of
their machines, otherwise they will close their doors and new doors will
be opened in China... it's a matter of survival now, small/medium
companies like Solidcam, HSMWorks, Delcam, OpenMind Tech are re-writing
the future of CAM... Siemens PLM and Dassault are also doing their
homework... so I believe the market will say... how it is possible that
PTC still linearizing helix entry in Volume machining or generating
thousands of tiny points in a ramp move? Their toolpaths are outdated
and do not reflect the reality of the modern CNC controls...

I find Pro/NC a robust product and very capable, and with
functionalities like those shown in the automation webcast David
suggested, you can make very nice things... but it's not easy to
implement those things in a global level when engineers are working from
UK, USA, Singapore, Norway, Brazil, all them connected via Windchill
technology... every site has their own machines and methods, people, so
I can put a great deal of automation in a MUDF and extract this as
annotation features, but perhaps my colleague in UK will not like the
tool set and speeds&feeds I used, or he can't use that on his
machines... so it's great, but hard to fully apply on big companies...
requires lots of discipline and seamless integration with engineering

The good thing is that PTC bought NCGraphics some years ago and the guy
in charge of Pro/NC today was the product manager of Pro/Toolmaker.. so
he knows this thing inside out... the good thing about this acquisition
is that NCGraphics technology is licensed in many products in the
industry, like Mastercam, Depocam, Visi... so these guys knows what
needs to be (re)done... we are eager to see this technology inside
Pro/NC, and that hopefully PTC can re-write their 20 years old code
using modern programming tools focusing in the 64 bits hardware and true
multi-core support (without charging you for an extra license like

I'm not sure if PTC will be able to break this repetitive cycle of not
being able to deliver fast paced innovation in CAM... I don't know how
much attention (Read money for R&D) CAM gets from the big fishes at PTC
or if they are really prepared to fight in this modern CAM market, but
I'm hopeful that CREO will also bring integrated CAM companies to
develop for PTC plattaform, and if Pro/NC do not evolve as we need it to
do, then we can get fast, fancy and powerful CAM systems to run inside
our CAD platform: Pro/E (Creo). One way or another, the market will
dictate PTC future, and it's up to them to do their homework with Creo.

Anyway, in big engineering environments like ours, it's important to
work with PTC to make the software better and to keep it as our global
solution, because of the many benefits of the full associativity with
the CAD model. And that's why I believe PTC deserves a last opportunity
to revamp Pro/NC, because PTC software as a whole also brought us many
good moments in our history.



RE: CAD is OK, but CAM is not a CAM


Talked to a PTC guy today and I need to add a remark to my last statement: If you set your own machine as the remote computation server, then Pro/NC job manager will use the multi-cores you have and it will not attempt to grab another NC license: it will use the license you are using.

I'm not sure which toolpaths supports multi-core processing or if all them do it. It would be good if someone from PTC could clarify this, an old doubt I have...

By the way, HSMWork also licenses the NCGraphics kernel, and two ex-NCGraphics employees are now working as freelancers, coding for Cimco/HSMworks... you can find their blog here: <u></u>- Wikipedia says that aproximately 10 CAM vendors licenses NCGraphics technology... so I think Creo/NC will have an interesting future...



RE: CAD is OK, but CAM is not a CAM


By the way:

My last post was not clear, sorry: Pro/NC does not have multi-core toolpaths... it won't split the computation of any toolpath in multi cores... what it will do is to run Pro/NC in one core and compute the toolpath in another...



CAD is OK, but CAM is not a CAM

No really interesting for my use, I always thought that by using the 'standard' hole features, NC automatically grouped like holes for processing without adding specific NC-based annotations and UDF's to the design model.

My issue is as follows:

I machine graphite electrodes for die sinking. I am die designer and do this to help with the NC programmers workload.

The machining center and tooling package is brought into Pro-E using a standard NC assembly template. I only have options to adjust the overall tool length and flute length of each tool in the package to provide the shortest tool practical.

I need to do approx 4 standard NC sequences:

1) volume roughing using a fairly large tool (1.00" bull nosed end mill)

2) Trajectory finishing of the electrode OD using a similar tool

3) Semi-finishing of the electrode contour only using an intermediate tool (possibly a 1/2" ball mill)

4) finishing the contour using a smaller tool (possibly a 1/4" ball mill)

I have the option to add or subtract NC sequences from this list but these sequences should be able to be brought up from a template of some kind.

The electrode material is graphite, the sequence / cutting tool should be limited by the following:

target surface footage of 250 ft/min

target chip load .003" per tooth

Max spindle RPM 4000 (yes it is an old machine)

Max feed rate 40"/min (did I mention that the machine is old?)

If I choose to change the finishing tool from a 1/4" ball nose mill to a 1/8" ball nose mill (for example) and from 6 flutes to 4 flutes, the speeds and feeds for this sequence must maintain the restrictions listed above.

Problems with sequences:

In the scenario above, the machining sequences are as follows:

1) Volume roughing:

NC does a good job creating the stock model to use for cutting. I can offset the stock model by about 1/8 inch to allow for rough stock in any direction.

I have pre-defined sequence parameters in *.mil files for particular combinations of cutting tool, and processing parameters, but these do not update for cutter / cutting conditions automatically.

2) Trajectory machining:

I now have to use 'custom trajectory' vs 'trajectory' for a sketch to define the 2D OD profile for cutting. I have to manually define the lead-in and lead-out along with defining the offset side twice, as the system seems to forget the offset direction after exiting the custom trajectory dialog. I use pre-defined *.mil files for this sequence and conditions. Small changes in the model can cause this feature to fail.

3) Semi-finishing:

I would like to use (and have used prior to pro-e) 'window' machining to 'lace' across the contour at a prescribed angle but the window-finishing sequence does not allow this. So I have to create a manufacturing surface and then use surface machining to lace across the surface. Again I have pre-defined *.mil parameter files for this. The manufacturing surface is created by seed and boundary, but is prone to failure with minor model changes.

4) Finishing:

This works OK. I can create a 'window' to use for machining, set the depth of the window, and then using the 'finishing' sequence options to finish the contour. Using 'Smart retract' often causes the cutter to crash into the model during rapid positioning, so I use retract-always and this creates a lot of redundant retract moves (the retract plane is 3" above the top of the part being machined). I have pre-defined *.mil parameter files for this sequence.

Now, I have been told (since WF2 or so) that by using the machinability database, I could set up 'seed' values of surface speed and chip load for combinations of materials and cutting types (roughing / finishing) and processes (milling/drilling/turning). This never seemed to work. Also setting up the machinability database directory structure for the cutting tools worked, but caused the *.xml files in this directory structure to be overwritten every time they were used.

I like the idea that the .xml files can have some intelligence but because of the problems using the .xml tool definitions listed above, I use the older *.mil files. These files have the cutting parameters listed as speed and feed which must be manually compared with the desired surface speed / chip load per tooth as these parameters are not parametric.

RE: CAD is OK, but CAM is not a CAM

In Reply to Daniel Santos:

My last post was not clear, sorry: Pro/NC does not have multi-core toolpaths... it won't split the computation of any toolpath in multi cores... what it will do is to run Pro/NC in one core and compute the toolpath in another...

Hey Daniel

Is there a better guide to setting up the job manager to process toolpaths on multiple cores? The help files seem to be lacking some details. would there be a diffrence between xp and 7?

CAD is OK, but CAM is not a CAM

I don't think there is any difference between XP and 7.

I can help with a guide. Let me find one here on my stuff... François Lamy created one a few years ago...


CAD is OK, but CAM is not a CAM


Please find attached material created by Flamy some years ago.

First off, you need to install the PTC Distributed Services option in
the machine you want to serve as the remote computation server.

Some tips:

In the machine you want to use as the remote server (It can be your own
machine), create a batch file calling the Distributed Services
(dcadsetup -f) manager upon your Windows startup. This will make the
daemon awake and therefore Pro/E will be able to send the computations
to the remote server.

Put this .bat file in the Startup folder so that the script runs
everytime Windows starts... - Make sure you have the loadpoint\bin &
\obj folders in your PATH variable so that the .bat script can find the
files in the loadpoint.

The dcadsetup is a .bat is a file stored in your loadpoint\bin - It
also establishes a communication between the job manager daemon &
pro_comm_msg.exe & the Name Service Daemon (nmsd.exe), the last two are
solely responsibles for any communication between Pro/E and external
Apps (Toolkit). Pro/E does not talk directly with other apps... it needs
to be done through these two guys...

That said, it might be necessary to edit the two sections of the
dcadsetup.bat file to match your .bat and .psf files, if you have
different ones to launch Pro/E with NC license modules.
If you use your own machine as the remote server, I think it won't be an
issue... but if you use a remote server, then Pro/E (xtop) will be
launched as a process, just like in your machine, but it won't show any
GUI. Anyway, it needs to load the necessary NC licenses, and if these
are set in specific .psf files (And the .bat associated to them), they
need to be set here.

Since Pro/E will be launched to computed the toolpaths (In case the
server is a different machine), it is important to install the DCAD
server with the same datecode and release of the client machines. You
expect to get the same result you'd get at your machine right? So in
case of an update/upgrade in Pro/E, keep in mind you need to update the
remote server as well. If you don't, you can get unexpected results.
(More than the usual ones ;->)

Hope that helps,

Best regards,


CAD is OK, but CAM is not a CAM

When the dcadsetup.bat runs at startup, does it 'grab' a license of NC
right away, or only when distributed services are requested?

If it only grabs a license of NC when requested, what happens when one
is not available?

Christopher F. Gosnell

FPD Company

124 Hidden Valley Road

McMurray, PA 15317



CAD is OK, but CAM is not a CAM

"of NC right away, or only when distributed services are requested?"

Only when requested. (If you use a remote server and not the machine
your running Pro/NC)

"what happens when one is not available?"

If you use your machine as the remote server, that will never happen. If
you use a remote server, the toolpath won't be computed.


CAD is OK, but CAM is not a CAM

OK. In my situation, all of the NC licenses are floating, and I 'grab'
or 'release' a license as needed.

If I am currently using an NC license, and have my computer setup for
distributed services on my machine, are you saying that the
dcadsetup.bat will use my existing activated floating license?

And while the distributed services are calculating my cl file, will I be
able to do other tasks in Pro-E? Currently, when a CL file is being
calculated locally, the software is 'busy' and unresponsive.

Thanks for taking the time to explain this feature; I don't mean to take
up so much of your time,

Christopher F. Gosnell

FPD Company

124 Hidden Valley Road

McMurray, PA 15317