Community Tip - When posting, your subject should be specific and summarize your question. Here are some additional tips on asking a great question. X
I am in Creo Parametric 9.0.8.0. I am attempting to generate an MCD in Creo NC. I am able to generate an NCL file with no issues. However, when I try to generate an MCD file, after all of the prompts, I check my working directory and there is no file for the g-code output. I have attached an image of the log. Am I missing something here?
Image shows OneDrive.asc - are you by chance using a OneDrive location as your working directory?
I would suggest using a working directory location on C:\ for testing.
Can you send an image of your working directory?
Do you have experience with the PPROC you are trying to use, are you anticipating a specific file extension to be generated for your MCD file?
I don't see any reference to what post processor is being applied to your .ncl file to generate the g-code. For example, this is a typical log file I see when I post process my tooling paths:
Log File
NC-GPOST Mill, Version 6.8 P-20.0, Copyright(c) 2023
Build number=0284
Date=04-02-2025 Time=12:36:38
Input File=toolpaths.ncl.1
Option File=uncx01.p04
Filter File=uncx01.f04
*** Tape length 544.21 Cycle time 206.86 Warnings 0 ***
Begin Generating *.tab files...
End
Date=04-02-2025 Time=12:36:51
There are a lot of setup things that need to be done to post-process .ncl files. For example, I have a directory specified for gpostpp_dir in my config.pro that tells Creo where to look for my Gpost files. The "unx01.p04" and "unx01.f04" files referenced in the log file are custom setups to process code in a format specifically for the machines we use.
It's been so long I don't remember what happens if I try to post-process .ncl files without these things set up.
You may wish to check the path to the NCL file to make sure there are no "-" characters or such in the path names. While these are acceptable in Windows paths, other programs don't always accept them.
We had issues with our "OneDrive" path to the user's desktop having a " - " [space dash space] in the name, and the GPOST program was trying to interpret the "space dash" as a command line option instead of a being the path to the NCL file.
EX: C:\Users\abc.xyz\OneDrive - XXXXXXXXX\Desktop\NCLFiles\test.ncl
Oh yeah. Another problem I've seen, which generates a useless error message, is there is a hard limit on the number of characters that can be in the full path to a file you are trying to post-process. I can't remember, but maybe 260 characters? A big problem when your co-workers like to name directories with lengthy sentences.
I don't know the character limit, but we use links to avoid all the long names and special characters.
We typically create a very simple link at C:\ called NCLFiles and point it to the actual path. The programs then just use C:\NCLFiles\<filename>.ncl as the path to the file.
Open a DOS/CMD window and type mklink /? to get basic help or do an internet search for more detailed information. There are some caveats if you're remoting to other machines and such.
Regards,
Dan N.
Yeah I have been using c:\ptc\NCFiles as my .ncl writing area for years. Don't have to navigate the byzantine directory structure on the server to find my g-code, and it's really easy to clean up all the extraneous files the post-processor generates. It does pump out a lot of intermediate files that it doesn't clean up itself, doesn't it.