Recently, in the last week, I have been having an issue with backplot. You know, the thing we use 1000 times a day? When I go to backplot a turning operation, it will either crash mastercam or when I hit run ( play ) it won't display any movement and I can't manipulate the graphics view. If I go to roll the graphics view it won't update till I close backplot. If I create a mill path like contour and backplot that then all is good. It seems to only be turning operations. Randomly it will work for one use on the same problem toolpath. I attached the stripped mcam file for reference. This is on an Integrex i300 FYI. I did have the same issue with a Swarf path last week but it never crashed mastercam it just wouldn't show any positions.
Your Mastercam crashing may be cause due to corruption in the configuration/resource files located in the c:/users/public/shared mastercam and documents/my mastercam folders. I would suggest reinstalling the software and deleting those 2 folders.
I shall try that and see what happens. Thanks! Just recently I had a second guy setup his own user account on the computer and it seem to be right around that time that issues started happening including this. Not sure if that is related.
In configuration -> files -> shared data path, there is a common folder in c:/users/public/documents/ shared mastercam, to avoid trouble have them set it up to point somewhere local on their profile like the desktop.
Ok so I uninstalled mastercam and at the same time I uninstalled all previous versions and deleted everything mastercam related as if it was never on this tower. Might not have been necessary but now I have a clean slate....... didn't fix it though. GRRRRRRRRR!!!!!!!!! But hey, now I only have the one version which i've wanted to do for a long time. I also just checked the video driver update just to see and wouldn't you know that just today they released one. Installed that and still no go. Also tried turning off hardware Acceleration just to see and that didn't do anything.
If "display end points" is on when you launch backplot then it immediately crashes mastercam once you hit run or single block. I had a coworker verify on another computer and it was the same thing. So by default that button will be turned off. Now if you launch backplot with it turned off and then toggle display endpoints once its loaded, it will work for that backplot session only. WOW!!!!! Don't worry it's only a days worth of work. Now where was I yesterday at noon when all this started? hahaha
Wow, I am glad someone else is having this issue we have four programmers and three of us are having this issue one is not. It happens in lathe and on a transform tool path in milling, I did find that if I turn the tool display off then back on before starting the back plot it does not crash. I have done all the ideas shown above except for the deleting the registry file I will try that next chance I get and see if that corrects the issue.
I would like to plot the line from a linear model where the response has been log transformed back on the original scale of the data. So the result should be a curved line on the original scale, where it would be a straight line on the log transformed scale. See code
I have a barplot that I want to overlay. The issue is that longer bars are covering shorter bars. There's a function in excel that allows for longer bars to be pushed to the back, and shorter bars brought to the forefront. How can I do that in R?
I would recommend you switch to geom_col if you are going to be plotting bars, but supplying x= and y= aesthetics. See here for the documentation explanation. With that being said, it will work either way. Basically:
Arrange Data: Outside of any other influence (such as ordering of the levels of a factor), the plotting function in ggplot2 will plot data according to the arrangement of the actual dataframe for the x= and y= aesthetic. This means if you order the data beforehand on a particular, non-factor value, this will dictate the order in which ggplot2 will plot. So, you should order the plot based on descending df2$y prior to plotting to have the largest bars plotted first and smallest last, which means the smallest will be in front.
Then uploaded the G code from the Haas and compared all of the speeds and feeds to that found in the parameters in Mastercam. All are identical. Our first thought was that the operator must have slowed some feedrates.
The biggest problems with the time in backplot is it is not accurate at estimating rapid times. Although I believe there is somewhere in the machine def. that you can alter to get the times more accurate, Mastercam will still not account for the doglegging of the rapid motion. Also I do not think it factors in machine accel and decel in calculating the times. If your program has a large number of direction changes, or a lot of rapid motion, that would definitely contribute to the time differences you are seeing.
Mastercam will give you a more accurate times if you set up your machine definitions accurately. For your Haas machine have you defined how long it takes to change tools and what the maximum rapid traverse rate is for the machine.
To be honest your never going to get it perfect. Via setup sheets you can scale the cycle time to reflect an average deviation percentage to get you fairly close. I shoot for being within 3% on average. There are just too many variables that affect the run time.
That is absolutely amazing. Since 1994 it's never been right... ever for me. Mastercam doesn't take into account acceleration/deceleration of each machine and not to mention some toolpaths do not time out right (like peck). Until we get full blown machine kinematics (not that I would necessarily want that), it will always be kinda close but not accurate. I use it all the time just to give me an approximate time but I wouldn't use it for quoting purposes.
This is 2011 for pete's sake and we cant get a cad system that will allow you to plug in your accel/decel, and peck drilling times from your machine into any cad system to produce accurate cycle times and produce spot on quotes that will allow us all to compete more effectively?
By the way... The Haas cycle time is 30% slower than the Mastercam cycle time. So now I am not meeting my quoted price. Pretty tough to do business that way. Which makes it pretty tough to stay in business.
I am using MasterCam 2017. Earlier it used to give approximately accurate machining time but now It won't give me time. For machining a 16 mm bore 12 mm deep Aluminium with feed rate 1200 and Spindle at 2000 cut being 0.1mm. It shows 1 minute time in backplot as well as in Verify (Simulator) but actually it takes around 3 minutes to machine. All the parameters mentioned are in metric I remember Updating MasterCam few months ago. And also it takes a lot of time to open the Application.
This seems to be bugged in 2019 (why am I not surprised?). It doesn't seem to take clearance into account, no matter what I put there the rapid feed time stays the same. Or is this by design?? (edit: apparently not, because rapid feed travel length seems to work properly with clearance)
I don't know about anyone else but there is no way I am basing a quote on a CAM program.....there are just too many variables outside of the CAM system....and there is no way I am going through an entire process of programming just to get a quote...maybe a path or 2 if something looks tricky but that's it.
I got to thinking about Back to the Future this morning, as I'm wont to do, and I remembered a plot hole that occurred to me 15 or so years ago when Lisa Bartlett and I watched my DVDs at her apartment. Pseudo plot hole? Maybe.
The plot hole, if it is one, occurs near the beginning of BTTF 3. Doc and Marty are at a cemetery for some reason, and Marty discovers Doc's headstone. The engraving reads, Erected in eternal memory by his beloved Clara.
We know Doc and Clara meet in 1885 when he and Marty hear her cries for help while they're scouting territory for a train to push the DeLorean up to 88 mph. A snake spooks her horses and they bolt, sending her across barren land and over the side of Shonash Ravine, which is renamed in her honor.
c80f0f1006