Bumping an old thread because the solution link is dead. Same problem here. After installing 2024 (coincidence?) I no longer get preview image for recent files when hovering over a filename in the Recent Files dropdown menu. Preview images are shown in the right pane of the regular Open Dialog. Windows 11. Another shop PC is on Windows 10 and does not have this problem. It was just upgraded to 2024 also. The upgrade may be simply a coincidence though, because if I open 2023 it no longer shows preview images for Recent Files, either. Both versions now show a tooltip-looking popup that just displays the file path.

Nice. It even tells the type of entities. Thank you.

Is there a simple way to get a count on the number of selected entities? I know you can copy the selection to a new level and then wipe out the new level but it seems like there ought to be a simpler way.

Awesome! Thank you. I had feared that this wasn't possible. This will really help with our quality control on the front end.

Our standard practice is to use the same WCS and Tplane for an entire nc program on our 3 axis mills. Sometimes we may accidentally make a toolpath on the wrong plane. I'd like to put something in the post to check the WCS for the very first operation, then verify that each operation's Tplane matches that WCS, and notify if it doesn't. This would just act as a safeguard to help prevent human error. My problem is not knowing how to access that info from the post, or if it is even possible. Does anyone know if this can be done?

It's just the mastercam.workspace file. I had to manually copy it too. It seems that when you have mastercam running to do the settings migration it does migrate the old file to the new location, but doesn't load the settings because mastercam is already running. So then when you close mastercam it overwrites the .workspace with the current default setup. Would be nice if they forced a restart after migration without overwriting the .workspace.

Just a note for anyone who may have trouble with this code, I had to edit it to make it work with my post. Where the previous code example said: if cant_val1$ = 11 I had to change it to: if cantext$ = 11 I also found another good thread on canned text customization.

Well that does exactly what I want and it is better than the way I had imagined doing it. I had never thought to try dragging and dropping that way before you suggested it. Ignorance is not always bliss. Looks like I'll be getting a lot more done at work tomorrow. Thank you Ron.

This may be a simple user question, but since I haven't found a way to do it maybe it could be a net-hook application? Often I will have a roughing end mill, finishing end mill, and chamfer mill all using the same set of chains. Similarly, I will have a center drill, drill, countersink, and reamer all acting on the same set of drill points / entities. I could change my programming technique and make better use of that "Last" button, but that isn't really a viable solution. Things aren't always done in an order that makes the very last chain the one you want to use. (For example, I may use that countersink on several hole patterns, but I only want to copy one of the drill point groups for the reamer) When I import or copy operations without geometry, it is taking me too long to associate the toolpaths with the new geometry. I have tried skipping around and using the "Last" button for that, but it doesn't behave as expected, and even if it did I think there could be a more efficient method. Here's what I'd like to be able to do: 1. Lets say I've imported several operations without associated geometry. I'd like to ctrl + click to highlight 4 of them and choose the geometry for all 4 in one swoop. Alternately, I would like to be able to pick the geometry for the first operation, close the point / chain manager, then highlight the other 3 operations and copy the geometry from the first one to the 3 highlighted ones. 2. When creating a new toolpath, have the ability to open the chain manager (or point manager) for other operations and drag / drop the chains into the new operation. Do these seem like possibilities for a net-hook or is this more of a feature request (or can we already do this and I'm missing it)?

Please delete this. I'm sorry. I posted in wrong forum and I'm not savvy enough to delete it.

Same here, no idea why it is happening.

Heads up: The code above has been modified. If anyone had used that code before 4/9/2017 there would be a bug that would output the wrong thread pitch comment if two different thread mill tools were used to cut two different thread pitches with no other tools being used in between. The code above has been edited to reflect the corrections.

Ok, here's what we've got now. If anyone wants to use this method, just ignore the code in my earlier post and start fresh with this code. # -------------------------------------------------------------------------- # Common User-defined Variable Initializations (not switches!) # -------------------------------------------------------------------------- boolthreadml : 0 #Boolean to be used when thread milling ... # -------------------------------------------------------------------------- # Toolchange / NC output Variable Formats # -------------------------------------------------------------------------- fmt 13 threadPitch #Thread pitch from thread mill cycle fmt 2 threadDia #Thread major diameter fmt 2 mytlDia #To store tool diameter ... psof$ #Start of file for non-zero tool number ... pbld, ptoolcomment, e$ if tool_op$ = 100, [ boolthreadml = 1 #Set boolean to show that we are thread milling threadDia = 0 mytldia = tldia$ sav_spc = spaces$ spaces$ = 0 pbld, n$, "(PROGRAM THREAD PITCH IS ", *threadPitch, ")", e$ spaces$ = sav_spc ] else, boolthreadml = 0 ... ptlchg0$ #Call from NCI null tool change (tool number repeats) if boolthreadml = 1, #If the previous operation with this tool was thread milling: [ boolthreadml = 0 sav_spc = spaces$ spaces$ = 0 threadDia = mytldia + threadDia pbld, n$, "(PROGRAM THREAD MAJOR DIAMETER IS ", *threadDia, ")", e$ spaces$ = sav_spc ] ... comment$ if tool_op$ = 100, [ boolthreadml = 1 threadDia = 0 mytldia = tldia$ sav_spc = spaces$ spaces$ = 0 pbld, n$, "(PROGRAM THREAD PITCH IS ", *threadPitch, ")", e$ spaces$ = sav_spc ] else, boolthreadml = 0 ... ptlchg$ #Tool change ... pbld, ptoolcomment, e$ if tool_op$ = 100, [ boolthreadml = 1 threadDia = 0 mytldia = tldia$ sav_spc = spaces$ spaces$ = 0 pbld, n$, "(PROGRAM THREAD PITCH IS ", *threadPitch, ")", e$ spaces$ = sav_spc ] else, boolthreadml = 0 ... pretract #End of tool path, toolchange if boolthreadml = 1, [ boolthreadml = 0 sav_spc = spaces$ spaces$ = 0 threadDia = mytldia + threadDia pbld, n$, "(PROGRAM THREAD MAJOR DIAMETER IS ", *threadDia, ")", e$ spaces$ = sav_spc ] ... pncoutput #Movement output if boolthreadml = 1, [ if gcode$ = two | gcode$ = three, [ if arcrad$ * 2 > threadDia, threadDia = arcrad$ * 2 ] ] ... pparameter$ #Read operation parameters if prmcode$ = 12194, threadPitch = rpar(sparameter$, 1) #Thread pitch from thread mill cycle This will output the pitch and diameter comments at the end of each thread milling operation. It will show the correct diameter regardless of whether the operation was created by selecting a point or an arc. It would be neater if the comments were inserted at the start of the operation. There is probably a hacky way to do that, but I'm happy with it the way that it is. I'm going to call this a success. Thank you, SlaveCam for helping me understand how to do this. **************************** Edited on 4/9/2017 **************************** There was a flaw in the logic. If two different thread mill tools were used in succession, the comment would output the thread pitch for the 2nd thread twice (didn't give the correct comment for the first thread). It is fixed now. With the current code it will output the thread pitch at the start of the toolpath and then output the thread diameter at the end of the toolpath. That is the only way I see to get the correct comments in the code. This has been tested with using the same thread mill to do two different threads without a tool change and also doing different threads with tool changes in between. It is working well from what I have seen. It's a bit inconvenient to have the comments separated throughout the code, but it is still easier than back-figuring the g-code with a calculator to verify the program.

Hey, I think you're onto something! That "baby program" is a can of worms, as I said (and the tldia$ method had a bug in it). Let's cut out the post-post processing and try your suggestion. I've got this cycle time calculator that I got from "Peter - NCS Ltd." in this post. (It's really nice, by the way.) It uses the radius of arc moves (arcrad$) in the pncoutput #Movement output block. I believe we could use that to handle this situation. I'm going to fiddle with it, see what I can come up with, and post the results here. Edit: Removed some comments about not being able to handle situation of cutting 2 different thread diameters without a toolchange. It will be handled in the code when I post the results.

Well, here's what I came up with: # -------------------------------------------------------------------------- # Toolchange / NC output Variable Formats # -------------------------------------------------------------------------- fmt 13 threadPitch #Thread pitch from thread mill cycle, 5 place decimal fmt 2 majorDia #Major diameter of thread, 4 place decimal ... psof$ #Start of file for non-zero tool number ... pbld, ptoolcomment, e$ if tool_op$ = 100, [ sav_spc = spaces$ spaces$ = 0 pbld, n$, "(PROGRAM MAJOR DIAMETER IS ", *majorDia, ")", e$ pbld, n$, "(PROGRAM THREAD PITCH IS ", *threadPitch, ")", e$ spaces$ = sav_spc ] ... ptlchg0$ #Call from NCI null tool change (tool number repeats) ... comment$ if tool_op$ = 100, [ sav_spc = spaces$ spaces$ = 0 pbld, n$, "(PROGRAM MAJOR DIAMETER IS ", *majorDia, ")", e$ pbld, n$, "(PROGRAM THREAD PITCH IS ", *threadPitch, ")", e$ spaces$ = sav_spc ] ... ptlchg$ #Tool change ... pbld, ptoolcomment, e$ if tool_op$ = 100, [ sav_spc = spaces$ spaces$ = 0 pbld, n$, "(PROGRAM MAJOR DIAMETER IS ", *majorDia, ")", e$ pbld, n$, "(PROGRAM THREAD PITCH IS ", *threadPitch, ")", e$ spaces$ = sav_spc ] ... pparameter$ #Read operation parameters ... if prmcode$ = 12194, threadPitch = rpar(sparameter$, 1) #Thread pitch from thread mill cycle if prmcode$ = 12203, majorDia = rpar(sparameter$, 1) #Major diameter of thread There is one major flaw in this which renders it impractical. That prmcode$ variable will be whatever is in the textbox under "Cut Parameters" --> "Major thread diameter" in the thread milling operation. So this only works if you choose a point for thread milling and enter the diameter manually. If you choose an arc or circle entity the textbox will be grayed out and the post will output whatever number is in that grayed out box. For this to work as desired there would have to be a way to determine whether the major thread diameter was derived from arc geometry or manually entered, and then get the major diameter from the arc if that is what determined the diameter. As far as I can tell, there is no way to make that determination in the post, and even if we could, I don't know if there is a way to get the diameter of the arc that was chosen for the toolpath. I searched around but couldn't find the answers to fill that need. I don't like drawing points, and I already have a handy little program that scans code for me, so I came up with an alternative soution. What I finally did was output the thread pitch using prmcode$ 12194 (it is always the correct value) and I output a comment that tells the tool diameter: pbld, n$, "(PROGRAM THREAD TOOL DIAMETER IS ", *tldia$, ")", e$ I have a little baby program that I call my "post-post". It processes the G-code after the Mastercam post to make further customizations. (I have it set as my editor in Mastercam, and after it processes the code it sends it to my actual editor.) When it sees that "THREAD TOOL DIAMETER" comment it begins scanning for I, J, and R codes when the modal G2 or G3 is in effect for that tool. Using the greatest radius found from I, J, or R and adding that to the tool diameter, it replaces that "THREAD TOOL DIAMETER" comment with a "THREAD MAJOR DIAMETER" comment. I would be happy to share my github repo for that program if anyone should ask, but one must be aware that it is very much customized to my personal code format (the home returns that our machines use, the locations for comments in the code, etc., etc.) It was not built to work for anyone else. You would pretty much need to use my machine definition, control definition, and .pst files to see the thing work as it is intended. The .pst files are built to work with custom macro programs in the machines also, so not all of the canned cycle features would be available without those macros. So this is a can of worms. I'm only telling how I finally solved it because lowcountrycamo wanted to see how I worked this out. Be careful what you wish for. funnyemoticon.gif Tl;dr: The code shown above does work, but only if you select points for your thread mill cycles (not arc center, but an actual point).