Seeing the price, it makes me think you were looking at also adding the Cimco NCBase too... I am looking at 61 machines, also adding the database and I am in the same ballpark... I have all the approvals I need, just needs to go through the owner now....it's part of a priorities list he put out so the feeling is done deal...I never though count the chickens before they hatch.

Not sure why your machine didn't respect the M00... That said, I usually do something like this with a Manual entry between operations as the M00 will stop the spindle, so in the manual entry you can restart it...

Unsupported video card

The tool planes you have setup in paths, don't work.... Unless that machine def & post are setup to rotate around the "B" axis it will never output properly. A default MPMaster post for rotational work will default to rotating around the X in a 4 axis VMC configuration and in the HMC configuration, it will rotate around the Z axis.

$$ must be somewhere because we're buying another of the same model

If it really acts suspiciously and you just can't get a simple offset to output....post the nci, you "should" only show XYZB info in the starting line, when you see that 5th axis has even the smallest value, something is toast....you can try to realign everything but you're working out to 8 decimal places and .00000001" can make it impossible... I only see this crop up once in a great while and "generally" in my experience, it is related to trying to get rotational offsets and you are working on a WCS that is not the system origin... I've said on numerous occasions, yes, it "should" work that way...the issues I see on occasion made my workflow become I ONLY work off of the system origin using TOP WCS.... And I know there are going to be people who say they work in space all the time and never see the issue....I will not dispute that they have not seen it yet...it only appears rarely but when it does, it can cause hours upon hours of lost work. JM2C YMMV

I can generally get anything I want out of transform..looking through his file, digging thru the nci, his issue, I believe goes much deeper into the database matrix...it looks like a slight skew, several digits out, is off by .XXXXXXX amd that is enough, that the post can't calculate an exact offset at 180°....I have seen the issue previously on a handful of occasions..even Karlo was able to see it and even he could not correct for it... Essentially his file is trying to create a move in an axis that his machine does not have... I hope it is not his issue as the file will have to be completely restarted if it is. I directed him to his reseller in hopes that they had a better solution

I always,, a;ways, always create my offsets now via the Create new offset setting, then I go through and name them as I want them...and then I go through and do my transforms. Can you share your file?

A computer should only have a 3-5 year span.... My previous desktop with a Xeon, I lived with because it existed before I got there...our entire Engineering & Programming staff have been on Dell Precision Workstations, Engineering for about 7 years, Programming it'll be 3 years. Programming and the Toolroom are all running the same spec'd systems Precision 7760 11th Gen i7-11800H @2.3Ghz CPU's 64 gigs RAM RTX A4000 NVIDIA Cards We just upgrade to 1TB SSD drives, we outgrow the 256 that came with them... I run Solidworks, Mastercam, Vericut, Materilse Magics, EOSPrint2....none of them suffer...this system beats my old Xeon everyday and twice on Sunday's... Heat has never been an issue, I keep mine propped up on the power supply to keep the air flow on the bottom...none of my guys has had issue. I won't dispute that heat has beatup on laptops, as power consumption has come down, In my experience, it's not anywhere near the issue it used to be with them.

It's a spammer.....already reported Notice the links hidden in the ___

If you unchecked it and it is re-checked again, something restored it... That makes me ask if there is Microsoft One Drive running? If it is, it is set to backup that config directory and you'll have to either turn it off or remove that directory from being backed up.. I chased the One Drive issue for several hours until I figgered it out

How are you logging in? If you have a HASP on the machine and you are doing something like a "Go To" session....Mastercam has to be left on and used remotely...you cannot launch it remotely. It's a great reason to move to a software license, you can check out a license on a laptop to travel home OR set up on a server you can login remotely from home and run remotely.. But a HASP limits what you can do remotely

Did you reopen your config file to make sure it had not reverted back to be checked? It's a strange one I have never seen unless that box was checked

A good understanding https://www.amazon.com/Secrets-5-Axis-Machining-Karlo-Apro/dp/0831133759

PCD tooling

You might be better off storing that data in a running string of variables and outputting them at the end... Bottom line, it will take an extra bit to process and output but you should then be better able to quantify your actual cycle time vs the total time including output. I am wondering if perhaps some of the time could be cut by outputting the data via ethernet to a seperate computer....

Time to call the reseller so they can see what's going on....

Instead of using Google, I don't know why you didn't simply contact your reseller.... There is a radio box in your config that you can uncheck that will not re-launch after it closes.

The ! is updating the variable..as there is not a * it will not be forced...as it matches the previous value with being updated, it doesn't meet the conditions to output

ptap when it encounters more than a single hole, then calls out ptap_2$ on subsequent holes, which calls pdrill_2$ ptap_2$ #Canned Tap Cycle pdrill_2$ pdrill_2$ #Canned Drill Cycle, additional points pdrlcommonb pcan1, pbld, n$, pxout, pyout, pzout, pcout, prdrlout, feed, strcantext, e$ pcom_movea In all likelihood you'll just need to remove a* from the feed variable

Blue is the Branch point where you have to make a decision...Red is the software guessing which way is next...

I don't know if your planned usage is similar, if it is, I did this...alll of our H & D 3's are always output #51999 fmt "D#" 4 maz_doff #Mazak Pallet Tech Diameter offset number #added 02/10/2020 fmt "H#" 4 maz_hoff #Mazak Pallet Tech Height offset number #added 02/10/2020 and in the psof section maz_doff = 51999 #modified 02/10/2020 maz_hoff = 51999 #modified 02/10/2020 Then in the tool change section, I dumped the tool length variable and add the one I created if use_rot_lock & cuttype = zero, prot_lock result = force(feed) # Force output of feed next time it's called for output pbld, n$, sg43, maz_hoff, pfzout, pscool, e$ In the pccdia section... pccdia #Cutter Compensation #Force Dxx# if prv_cc_pos$ <> cc_pos$ & cc_pos$, prv_maz_doff = c9k ##modified 02/10/2020 sccomp if cc_pos$, maz_doff

Here's the complete tap section in my post ptap$ #Canned Rigid Tapping Cycle pdrlcommonb result = newfs(17, feed) # Set for tapping Feedrate format if met_tool$, [ if toolismetric, pitch = n_tap_thds$ #Metric NC Code - Metric Tap else, pitch = (1/n_tap_thds$) * 25.4 #Metric NC Code - English Tap ] else, [ if toolismetric, pitch = n_tap_thds$ * (1/25.4) #English NC Code - Metric Tap else, pitch = 1/n_tap_thds$ #English NC Code - English Tap ] #pitch = pitch * speed #Force Units Per Minute for regular Tap cycle pcan1, pbld, n$, *sgdrlref, *sgdrill, pxout, pyout, pfzout, pcout, [if peck1$ > 0, *peck1$], prdrlout, *pitch, strcantext, e$ result = unforce(feed), !feed pcom_movea