The internal stl-compare function, when comparing against the workpiece is actually comparing against an STL model of the workpiece behind the scenes. So the accuracy issues that you are concerned with are the same for either method.

Greg J, we have reworked the sectioning tool so that it will find the center of gravity of your part to place the sections so that if its not on centerline, you will be fine, these tools will come in the next release however.

Mickey, When verify simulates the cutoff operation it no longer has control of the stock and assumes its gone or dropped. We do have a task to tie the setting in the stock update parameters dialog to what happens in Verify so that you can choose how it behaves. I just don't know when it will be implemented at this point.

I will look into other possible ways to display the information. We were talking about configurable options so that you only display the items you choose. If we could accomplish that and make the text transparent on the graphics window we may be able to accomplish your request. We will come up with something, just can't promise when.

Mark, We will be moving to a "workspace" type of interaction which will allow exactly what you are asking. At this point the move list is hard coded to start on the right hand side with the size it currently has. I will try to come up with an interim configurable solution that may work better.

We have some .dlls we can send to you to install that will create dump files allowing us to troubleshoot what might be going on. Please send an email to [email protected] to my attention and we will see what we can find.

Here is what it would look like

You can "unpin" the move list so that it collapses when not needed and when you move your mouse to the right edge, it will reappear. You can also "undock" the entire move list and put it at the bottom of the screen to get very close to what you are suggesting

What you are seeing is a method of dispaly that reverts to the initial stock if the update to the cut stock is going to take 3 milliseconds or more. When it is in cutting mode and the pixels are being cut, we didn't want the dynamic motion to slow down the processing of the cutting so we revert to the initial stock while rotating and display the cut material when you stop. We have had several complaints for this and we are working on a solution that allows the dynamic motion to happen in an efficient and speedy way without affecting processing time.

I will add the enhancements myself, no need for extra emails. I spoke with the programmers and for option 1. "User must open Mastercam&UBVS. Maximize UBVS window. Close UBVS , close Mastercam. Next time he opens UBVS, the last window size & pos is remembered". I tested this in X7MU1 and it work as described. Item 2. The value for the width of the move list is hard coded at this point. We will be using and saving "workspaces" in the future and this will be an item that is saved.

Hello Newbeeee, I will give an answer for each: 1. Not sure, I will need to get back to you on this. There are some registry keys, but want to confirm before I tell you which one. 2. Same as 1. 3. That will have to be an enhancement, makes a lot of sense though. I will add it. 4. We are currently re-working the move list data to be values relative to WCS so that the values make sense. Currently they are reporting world coords which is only correct in a very small subset of toolpaths. 5.That would also be an enhancement. How that move is made is not in the NCI but rather determined by the post/control being used. We are working on making it smarter by using the values set in the machine definition (i know its about time we use those values). It has caused some confusion with dog-leg moves in mill parts that show a gouge where there weren't before. Changing how rapids are handled in the machine/control def. resolves that issue. We are always looking for ways to improve the interface so please continue to make suggestions.

Those directories are used as default window size and locations for the simulator window. They may have been there a long while, but unless the system needed to revert to the default location for some reason, they would never have been used. Any corruption or bad values in these files could cause the problem.

I suspect a tool definition issue. Please send in a problem part to [email protected] and we'll take a look. The Thread Mill toolpath works fine through all of our automated testing so it must be the tool.

Murlin: If we do another release of X7, speed enhancement and fixes to the Simulator will be included for sure.

LeftCoastLefty: Yes that would be our recommendation, keep an eye on the amount of memory being used during a verify and see if it approaches your limit. If it does move the slider to the left.

Machineguy: What are you seeing for results, a lot faster or slower in new verify?

Yes, you can move the .xml from system to system without a problem.

The delay in accurate zoom is something we are working to make better, putting up a 'working' message slowed things down a bit more so we chose to not display one. We will revisit this for the next release. As far as the speed of verify, we did make a change for 64 bit systems where the same setting in X7MU1 is a bit slower but more accurate than the same setting in X7. We are trying to find the best balance between speed and accuracy and this was one of those changes. A setting of 2 or 3 from slowest would be roughly equivalent to the default 5 setting in X7MU1. You have much more of a range in X7MU1.

Newbee: The stl compare against the workpiece will check against the model that you have currently turned (level) on in Mastercam. Results with the workpiece are very good. Using an STL to compare against will yield different results based on the tolerance used create that .STL model. So you would have more control over the tolerances with the external .stl. Its really up to you which you prefer. Also in X7 there is a nice STL compare utility right within the Stock Model tool, the benefit there is that you can save those as operations in your ops manager and they are associative so a regen will work on them. Lots of tools and several different workflows to try.

Hello Brian, The choice of engine is made at run time. That is due to the fact that Simulator doesn't know which toolpaths you wish to verify until you hit the verify button. At that time it analyzes the tools and toolpaths selected and decides on an engine. The 3 axis engine is similar to the "turbo" mode in old verify, it is a top view only tool that will not show any undercut features. Because it doesn't see undercut material, it looks to see if any of the tools are defined with the potential to uncercut material and if it does chooses the 5 axis engine. You may wonder why we don't know for sure if there's an undercut and the answer to that is performance, in order to know for sure we would need to analyze each and every move in every toolpath, this would easily double the processing time. Do you start every part with a Facemill by chance? If you do, a facemill by definition can create an undercut. You can get around this by using an endmill definition instead of a facemill.

OneYankFan1: I looked at your file and Crazy^Millman as correct. The facemill you are using has a profile that is not correctly defined. If you save the profile to level and look at it the chain of entities is not contiguous, there is an overlap. If you trim up the geometry it will work fine. The simulator needs to take in that data and resolve the problems itself in order to be able to use the tool, it seems this may be where the problem lies. Even with the problem tool, it opens for us within a few seconds. Try to fix the tool (or create a new one) and see if that effects your performance. If it does not we will look at the files installed with Mastercam.

oneyankfan1, Please send in a sample file that is causing these issues to [email protected]. We need to determine if the problem is part specific or something messed up in the installation of Mastercam. 30 minutes to simulate a facing operation isn't exactly what we targeted for the release. We will get to the bottom of this.

We haven't exposed any simulator specific functions to hot keys yet, however, we support many of the mastercam view manipulation hot keys. We could easily expose specific features inside of simulator to configurable keys or sets of keys if that's helpful. Things like "compare", "Quick verify" and "Restrict Drawing" in backplot, and others would be easy to tie to keys and usable on the SpaceMouse or similar.

The default precision factor is 1 for 32 bit machines and 1.5 for 64 bit. The precision factor changes the entire range of settings for the slider bar, so it does have a large effect.

A couple of things. We are always working on speed increases, we are also working on an automated accurate zoom so that as you zoom in, the accurate zoom happens transparently to the user. Third if you have engraving files that are problematic in X7MU1 I would like to see them. Please send them to [email protected]. If you have a decent graphics card and plenty of memory you can try editing you MastercamSimulatorDefaults.xml located in your MyMcamX7 directory and change the <PrecisionFactor>1</PrecisionFactor> to a higher value. The change is exponential so don't go above 4 or so. See if that helps.