I'm not sure if this is something that might be worth looking at, we used this program years ago for our waterjet due to it's nesting capability - it has multiple machine support including punch, laser, plasma, and shearing. When I dealt with them for my post the guys were amazing and gave me exactly what I had asked for, no questions asked. http://www.sigmanest.com/en-us/products/punch/punch_powerpack/

I recently have just started to play with the ModuleWorks machine simulation in Mcam X7. I have successively created my machine and the simulation is working pretty much correctly. However, when there is more than one operation to simulate (or on a tool change), the machine simulation simply "jumps" to the next operation's start point. Is there a setting somewhere that I'm missing to get the simulation to actually show (simulate) the rapid move to the next operation's start point?

According to a quick check online - this seems to be a greatly UNFAIR test. According to HAAS on their VM-3 series (http://www.haascnc.com/mt_spec1.asp?id=VM-3&webID=MOLD_MACHINE_VMC) the machine is rated as 30 HP with a max. torque of 90 ft-lbs. According to Makino on their PS95 series (http://www.makino.com/vertical-machining-centers/ps95/) the machine is rated as 33.5 HP with a max. torque of 140 ft-lbs. With the HAAS only having approx. 64% of the torque and 3.5 less HP as the PS95 this definitely does not appear to be an apples to apples comparison.

Yes, that's exactly what I'm seeing - but according to that, I'm taking it as meaning that Mastercam is "seeing" the update but it has not been applied. I'm assuming that if the update had been applied, I should be seeing "Mastercam X6 (15.3.0.2) under "Help" -> "About" and under "Details" I should be seeing "Mastercam.Exe X6 MU3 (15.3.0.2)". Or does this mean that the update did take, but the version number hasn't changed due to the ".exe" not being changed ??

Just downloaded and installed MU3 - The install process went through fine. When I open MasterCAM, up in the title bar is says "Mastercam Design (Mill, etc) X6 MU3. However, when I go to "Help" -> "About" I'm still showing "Mastercam X6 (15.2.1.2) and if I click on the "Details" button, I'm showing "Mastercam.Exe X6 MU2 (15.2.1.2) and under that it says "The following updates were found...." and under that it says "Version = X6 MU3 (15.3.0.2)" followed by a listing of DLL's. Does this mean that the update did not go in? And if it did why am I not showing "Mastercam X6 (15.3.0.2) under the "Help" -> "About" ??

Thanx guys! I had forgot that when I re-did my post that I had changed that so that I could "see" what was going on to make sure everything was good - I had changed machine A to "all error messages to screen". Changed it back to "all error messages to file" and now posting nicely!!

I'm using X6. I have 2 machine def's, and 2 control def's, both tied to the same post. I have machine A as my default. If I post a program out for machine A, it takes forever "reinitializing" variables, then will say "not responding" - but if I just wait, eventually the editor will pop up and the program will post out. There are no errors reported either by the MP or if I run it through the debugger. However, if I use machine B - it pretty much posts instantly. I have tried a couple of different posts (the ones that are supplied) and they all do the same thing - so I 'm guessing it's not a post problem. However, the weird part is - if I post out a program for machine A through the debugger, from then on machine A will post out pretty much instantly just like machine B (I can even close the debugger) until I close down Mastercam, Any idea's why it is doing this or why running just one program through the debugger "fixes" it?

Found this article on the NET http://partnerfiles.spaceclaim.com/Miscellaneous/June%202012%20Newsletter.html Interesting line from the article "During this event we unveiled SpaceClaim's unique and powerful solutions for manufacturing companies, including the first public introduction of our new MasterCAM connection." Maybe there is some validity to this rumor??

After updating my system - I'm also getting posting errors: "A formula is attempting to read from a look up table that does not exist". However - the table is there and the look up is actually working perfectly fine!! I've verified this with the post debugger and it can be seen in the NC file that the values are being outputted correctly.

After searching around on the net, like you have, I can only think of 4 things as to what this could mean: 1: This was actually an internal print and is meant to tell the QA what thread gauge type to use for the testing 2: This is the customers way of telling you what type of thread gauge they want you to use 3: This print was done by a draftsperson who didn't understand that "taperlock" is a type of thread gauge 4: Neither one of us (or apparently Google) has ever heard of a "taperlock" thread My best advice would be to call the customer and simply ask them what they mean by that call out

That's the max spindle speed (200) on my HAAS VF4 for rigid tapping, but like I have posted earlier I have had no problems as long as I stick to that. It may be painful to watch, BUT it has been 100% reliable for me Just as a side note, if you haven't done so already, check your owner's manual, there will probably also be a max feed - my specs (according to the manual) are max spindle 200 or max feed 100 - I can not exceed either value.

I use OSG hy-pro or the exo series taps and use a spiral point for through holes in aluminum. I used to have hit and miss issues with my HAAS VF-4 until I came across a section in the manual and realized that there is a max spindle AND a max feedrate when using the rigid tapping (I was always way over the max spindle). Now that I don't go over these maximums I have had no problems at all with the tapping - actually doing #4-40 holes right now in aluminum.

#6 here Win 7 64bit

Neat Stuff!! Thanks for the post!

After some digging around today I found the problem! It is a bug with the Setup Sheet Screen Capture, it is producing an erroneous value in the bmp's file header - specifically at offset 0x0a which is the bitmap data offset value. The value is being miswritten/calculated as 0x3a and should be 0x36.