Don't waste your time hacking at a post for this. There is a perfectly good MultiCAM post available to your reseller. Just ask him to get you a copy.

Open the .pst file in any text editor and change this setting from 2 to 3: code: tool_info : 2 #Output tooltable information? #0 = Off - Do not output any tool comments or toolpable #1 = Tool comments only #2 = Tooltable in header - no tool comments at T/C #3 = Tooltable in header - with tool comments at T/C

Your existing posts will work in X3.

Travis, shoot me an email in the AM with the files and I will convert them for you (should take about 5 minutes). As far as your question as to what would someone do with a customer that wished to run both a Mill and a Router, It would depend entirely upon the Router machine configuration. Router supports all of the Mill toolpaths and allows for support of multi-heads and block drills so it would obviously be the correct choice for a customer that wished to drive a multi-headed machine or a machine with a block drill. But, if the machine was a simple 3 or 4-axis single spindle router then there would be no reason they could not use the Mill product to drive it.

Try this: if (mi1$ < 1 & mi1$ > 2) & (mi1$ < 81 & mi1$ > 82), mi1$ = 85 Then you will want to format the output. You should have something like this in your post: #Common format statements fs2 4 1 0 1 0 #Integer, not leading If so, look for a section with a bunch of fmt's and add this line: fmt M 4 mi1$ #Misc Integer 1 output Then you can output the information: n$, *mi1$, e$

Install the IE Tab add-on once you have Firefox installed. Like Bernie says, there are some sites that do require IE or perhaps work better in IE. The IE Tab add-in allows you to define pages to always display as if you are running IE.

People still use Internet Explorer? Hmmm, I was pretty sure everyone saw the light and moved to Firefox a long time ago.

File locking... is coming... That's all I can say... (and I'm likely in trouble just for saying that )

Check the first tab of the Machine Group Properties dialog. There will be a section that looks amazingly like the comment settings that you previously looked at in the CD (for bonus points, guess where the defaults for the Machine Group Properties dialog come from). Make sure you have the correct comment types selected. The next thing to check is to make sure that the operation comment is in the .nci file. Look for the comment that you entered (it should appear just under a 1008 line). If it is there and you have the correct check boxes selected in the Machine Group Properties dialog, take a look at the pcomment$ post block in your post. It should contain a call to pcomment2 and pcomment2 is the postblock that determines how the comments are formatted for output. Make sure that there are no problems in those post blocks (go ahead and post them up here using the code button if you're not sure what to look for). comment$ is not an output variable. It is a command that tells MP to dump the comments (all of the comments) currently held in scomm$.

Perry, shoot me an email. The .set file I have will output exactly what you are looking for as is. Rick, What you are looking for can certainly be done. There are two ways I can think of off of the top of my head. The first would be to process using two separate .set files, the first generating the tool list portion and the 2nd (called from ppost$) generating the operation list portion, appending to the information created by the first .set file. This would allow for much cleaner (read as easy to understand) code in each .set file. The 2nd option would be to reprocess the nci file using the same .set file which would contain the logic for both types of output activated by some kind of post switch. Personally, I think I'd opt for the first option. Either solution would take some time to code however.

Colin, email me and I'll send you a .set file for that. [email protected] The standard .set files are set up as operation lists, not as tool lists.

Your dealer can grab it off of our extranet. I know, I put it there.

Is there a Wire Machine Group in the same .mcx file? I know there was a bug that was forcing null tool changes to output as tool changes (in the nci) in files where there were both Mill and Wire Machine Groups. If so, delete the wire group.

Ah damn. I was going to suggest format c:

Bruce, I understand completely, I just also see the other side of the issue ( because I already asked the same thing ). There's always hope, and I will keep on em for ya

I know this all sounds wonderful but please consider the possible overhead carrying deleted operations will add to the file you have open. If you think your system crawls now, consider having multiple 5-axis or surface machining operations "held" in the background, along with all of the associated geometry pointers, etc... We're not talking about keeping a 5kb image in memory in case you want it back, we are potentially talking about MB or GB of information. Thad, the boys in QC fight the battle every day on your behalf. It just really pains me that no one seems to appreciate the effort they put forth. Many individuals on this forum post disparaging remarks regarding the folks employed at CNC Software as if we are a bunch of evil, money grubbing monsters. The truth is we are just folks like you that work hard hard every day to make this piece of software better. Most of us take great pride in the work that we do and tend to take things personally when we get blasted by someone that often simply does not understand the how something works or why it works that way.

I think I just would have went with: if cabs <> prv_cabs, prv_workofs$ = c9k or perhaps, if cinc, prv_workofs$ = c9k But I'm simple like that...

Judging by the images you provided, it appears that you are attempting to modify the Lathe(Read-only).LMD and/or System(Read-only).control files (which live in the config folder). The file properties are set to read only to keep you from accidentally modifying them (which apparently is exactly what is happening here).

:whisper: Pssst! Hey Thad, QC doesn't design anything... They just log and test for bugs. Give em a break will ya?

Considering that we have one sitting downstairs and it runs it every day I would think it should not be a problem (but then again, what do I know?)

I'd love feedback on exactly why people do not use the Generic Haas 4x Mill post that ships with the software. It should run the VF-3 as is right "out of the box". It's terribly difficult to improve something without any feedback at all

Lies

You could also just add !mr4$ in ptlchg$ and then use prv_mr4$ in pretract.

Open the .pst file and change the following settings: code: fastmode$ : yes$ #CD_VAR Enable Quick Post Processing, (set to no for debug) bug1$ : 1 #0=No display, 1=Generic list box, 2=Editor bug2$ : 40 #Append postline labels, no. is column position, neg. is all bug3$ : 0 #Append whatline no. to each NC line? bug4$ : 1 #Append NCI line no. to each NC line? whatno$ : yes$ #Do not perform whatline branches? To: code: fastmode$ : yes$ #CD_VAR Enable Quick Post Processing, (set to no for debug) bug1$ : 2 #0=No display, 1=Generic list box, 2=Editor bug2$ : 0 #Append postline labels, no. is column position, neg. is all bug3$ : 0 #Append whatline no. to each NC line? bug4$ : 0 #Append NCI line no. to each NC line? whatno$ : yes$ #Do not perform whatline branches?

Which also reads the Machine Definition...