Still using CIMCO as NC file comparer, because I have not been able to find a better one.

Why does it highlight the rest of the line even though only G90 should be highlighted? This is giving me unnecessary work, because now I have to check that the coordinates are identical as well (which of course should be the comparer's job).

It is one of the most common thread forms here. Why is it not included in the Thread form dropdown list? Can it be added there?

Of course I can fake it as metric, and all would be fine, but...

I have done this a million times but now get completely unexpected toolpath when using plunge in finish turning. 2019 seemed to be ok.

Ideas?

EDIT: There were absurd values in Tool Clearance. No idea where they came from. As always, this thread is eligible to be removed.

The problem was that if compensation is off, the diameter of the tool should not matter. I use helix/circle mill so much that every now and then I try to use the toolpath with comp off and run into this problem. The workaround is simply use compensation and change geometry, which is what I did.

So in the end there is no problem, but it would be more "logical" if this message did not appear when compensation is not used...

Thanks to Aaron for answering so swiftly. It's great that people from CNC listen to customers and take their nags seriously

Edit: Message removed because the issue wasn't that big after all...it's been a long day

There's a huge discrepancy between the maximum number of levels and the maximum number of misc integers, misc reals and custom drill cycles.

Yes, I'm running out

When copying operations from one machine group to another, then how can a tool be deemed "similar" if its type is "endmill" and the tool being copied is a "chamfer mill" ??? It seems "similar" here means just the diameter. I have learnt to become incredibly careful when answering YES...

This is another good example of poor usability. Copying operations is so common, that this dialog should at least tell us WHAT tool it is comparing to. For example:

A similar tool already exists in the tool list.
#0 - M16.00 DRILL - ISCAR CHAMFER MILL D16 (Source)
#0 - M16.00 ENDMILL - SANDVIK ENDMILL D16 (Destination)

Also, if all the operations being copied use the same tool and you answer "NO", it will create a unique tool for every one of the operations instead of using the first tool that is guaranteed to be unique.

There's a bug in 2021 that after using solid command "Trim by plane" and choosing any solid body, you can no longer select any solid edge for whatever purpose until mcam has been restarted.

I try to get the absolute minimum stickout where the holder nut will touch the upper surface, which is 87 millimeters in the picture below. However using Check Holder I keep getting 88.27231. Resolution is 0.01, tolerance 0.025, holder and shank clearance are zero. Operation is Drill/Counterbore without tip comp

Where does the 88.27231 come from?

Is there a simple way to make Lathe Finish contour toolpath so that the tool nose would tangent to the red line at the end? I mean simpler than drawing additional geometry or using "Extend / shorten end of contour" with a lot of trial and error.

Does HSM Advisor support cloud so that you can share feeds & speeds or is everything local?

On 6/2/2021 at 3:50 PM, bd41612 said:

Slave, once you have all of those operations selected. Tap the letter "e" on your keyboard until you have them expanded the way you want.

This is not producing a desirable effect... maybe your e key shortcut does something different?

It hasn't been many days since I found out from some thread that there is an online Mastercam post processor reference, and it didn't even require log-in. But for the life of me I cannot find it again. Was it removed?

Quite often I find myself having to select operations by a tool number for whatever reason. I find the usability of this function to be incredibly poor.

• It does not expand toolpath groups where selected operations reside
• There is no way to isolate the selected operations. When you open a toolpath, the selection is lost and you have to redo.
• "Apply to selected operations" does not work

Because this is such a common process, can you suggest any tips to make this workflow better? And as much as I love programming, having to make your own NET hook for this purpose should not be required.

I need to change the line

pbld, n$, *toolno, *next_tool$,e$

so that next_tool$ is not output if that tool is a lathe tool. Is there a way to put it all in one line?

If I edit local machine or control definition, every operation's program numbers are reset back to "default program number" under Tool menu.

Can I stop that from happening using some hidden checkbox somewhere?

I did some testing and it seems no matter what's selected in the abovementioned setting, the program number of a transform operation that uses another transform operation as source does not have its program number written to NCI. So in this case program number seems to be kind of a special case.

In 4 axis work it's common that I use the same source operations for different tombstones and the fixture positions may wary as well, so there is no avoiding nested transforms, unless you love useless extra repetitive work. G54.2 would be a huge help, so maybe I'll get it one day.

1 hour ago, Colin Gilchrist said:

Are you sure the values aren't written to the NCI? There is a switch inside the Control Definition, that controls which parameters; Original Op or Transform or Both, that actually get written. Is that switch set to "Transform" or "Both"?

I'm honestly not sure either way, but I do know that switch exists in the CD.

No, I'm not sure. Didn't even think about the existence of such a switch. I'm going to check it out tomorrow, thank you for this tip!

15 minutes ago, Zaffin_D said:

Just so you are aware, this is not an ideal use for opinfo.  When you tell opinfo to query an NCI line it searches the NCI file that’s on disc.

I’m almost positive you can get the value you are looking from a traditional parameter in memory, have you done a parameter dump?

Using opinfo on an NCI line should only be done if the data isn’t available in memory.

Hi,

This hack is due to this problem

Program numbers are not written at all to NCI for transform operations, so I have to use a transform operations's misc integer. Furthermore, trans_mi$ does not contain the "latest" mi-value in case of nested operation. If you know a better way, I am all ears

Got it:

atest         : 0.0
stest         : ""

pheader$         #Call before start of file
      stest = opinfo(1032, 0)
      atest = rparsngl(stest, 1)
      "Test:", *atest, e$

A NCI file has the following lines:

1031
0. 0. 0. 0. 0. 0. 0. 0. 0. 0.
1032
3000 0 0 0 0 0 0 0 0 0

These are transform operation's custom parameters, where 3000 is the value of trans_mi1$ (or actually in case of nested transform, it is not, thus my attempt at opinfo)

The following code outputs the following string Test:3000 0 0 0 0 0 0 0 0 0

stest         : ""

pheader$         #Call before start of file
      stest = opinfo(1032, 0)
      "Test:", *stest, e$

However, I don't know how to capture the "3000" part of the NCI line; if I change the code to

test         : 0

pheader$         #Call before start of file
      test = opinfo(1032, 0)
      "Test:", *test, e$

the result is always 0 or -99999, no matter what I enter into the second and third parameter.

How Do I Use Opinfo Correctly?

Because all post processors seem to ignore the program number assigned to a transfer operation, I've had to add a line to pheader post block:

if trans_mi1$ <> 0, progno$ = trans_mi1$

so that the program number outputted is the same as transform operation's first custom parameter. However, in case of nested transforms, like in the file attached, it is not working.

The aim is that (see the attached file)

• If you post only operation #1, it would output O1000
• If you post only operation #2, it would output O2000
• If you post only operation #3, it would output O3000

How do you do that?

EDIT: This was supposed to go to the post processor forum! Sorry.

PROGNO.mcam

Yes. Is this a common dialog in CNC Software's post processors? If someone from CNC could confirm if there is something in the encrypted section that can be set in non-encrypted post block to bypass this.

What kind of encryption do these files use? (no, I'm not going to try crack one, just curious) AES? CNC's own? Are mill-turn posts still completely encrypted in year 2022?

This is an older MT640 Pro post processor from CNC Software. I want to get rid of this message and use a post variable. Unfortunately part of the post is encrypted and so is this message. File name is "Mazak Integrex Fusion 5X Single_Turret MT_Lathe.pst"

Is there a way around this?

That was FAR too easy.

Thanks.