Check out the use of Misc Reals 7 and 8 
http://postability.com/miscvalues

Please reach out to us through you reseller to get our eyes on your issues.

Our MachSim support is very tightly integrated into our post, so to do it right, we only offer our MachSim implementations using our own post products.

Also noting that the post in question would work in the version of Mastercam for which it was created. So I'm aware that Maintenance and added costs are generally unpopular, but it becomes difficult for us to chase the impact on the post from Mastercam version updates without a program in place to account for the extra work.

Just noting that we have enhanced our post engine over the past few years to overcome these rounding issues that we feel are native to NCI/MP. So we consider our methods an engine enhancement vs. a bug correction and therefore available to clients who are active on our PostCare maintenance program.

From that Docs page @crazy^millman listed, I just want to highlight that we have videos that explain all the standard misc values used in our post engine

https://postability.com/miscvalues

On 3/23/2020 at 7:40 AM, pro grammer said:

pe              #End of line
      e$

pfe             #Forced end of line
      *e$

pn              #Line numbering
      n$

pfn             #Forced line numbering
      *n$

 

 

Yeah. This takes the cake for both arrogance and stupidity.

This was a rough-in to handle 2 end of line special characters in a simple way. Mastercam MP has a way of easily adding an end of line character, and if memory serves a way of adding a 2nd end of line character that is less than intuitive. This was done to allow 2 characters or more and/or a character and a special UNIX end of line format easier to handle. While Windows uses CR/LF, Unix was LF only. You can suppress the CR/LF then add the LF back in, but what is you need the LF and a $ at the end of every line, etc. Did someone just whisper Biesse RT480 in my ear? I thought this was a clean way to rough-in special end of line character and line feed handling. And I'm not sure it's ever been used.

So, I agree it looks ridiculous, but a lot of careful thought and planning went in there. 

As a follow up on this, while Programinator is a Postability post user, his company has not licensed our optional MachSim add-on, so the issues are related to the internal simulation.

Generally if your toolpath has enough data to go cleanly "over the top" our post would have B will switch solutions.

27 minutes ago, jjones61 said:

It's a Postabilty post. I've emailed our reseller but haven't heard anything back. Plus I'm stuck at home right now so I figured this will give me something to work on and maybe I'll even learn a thing or two!

You can certainly reach out to me using the contact email on our website if you've like us to offer suggestions on your issue.  I don't often stop by here, but happened to see your post today.

On 2/17/2020 at 10:50 AM, Programinator said:

I need to transform this toolpath to the other locations on part.  I know how to do it making a transform of a transform but i was wondering if it is possible with just 1 transform toolpath?

A Point selection menu on Transform? +1
Bueller...  Bueller?

On 7/3/2019 at 10:53 AM, Bill Craven said:

A lot of my time these days is developing 'turnkey' part programs, and many times it is for a customer that has just bought a new machine with advanced capabilities and doesn't have anyone in house that knows how to run the machine and even set offsets, etc.

Starting with a good post is very helpful, but if the parameters in the machine are set differently from the parameters that worked for a 'proven' post, you might not get the desired motion.  

 

Working with posts from Mr. Postability (Dave Thompson) and posts from the crew at In House Solutions have been positive experiences.    But if you can't tell them why a snippet of code doesn't work, they can't fix it.  I end up burning a lot of time going back and forth between an Application Engineer from the machine tool manufacturer and the post developers.  

 

Okay,  I'm done whining.  

I love my job.  I really do.  The mental stimulation is what keeps me going.

Just wanted to mention that Postability is more than just me, although that title made me smile.  We've assembled a great team here including a senior applications specialist who you should meet Bill.  Message me if you would like an introduction.

I don't believe this is a Postability post.

Stick to Peck with G83.  Complex deep-hole G69 is not in the G-Code set for the 8065.

On 2018-05-26 at 3:33 PM, C^Millman said:

Yes Postability or In-House have good posts. Still wish one would get the sync codes dialed down to user input vaules and tracked without the automatic process if you have a lower turret you will need. The do a good job, but amazes me that I was able to develop something almost 11 years ago that I have still not seen anyone do with Mastercam. Really conflicts me to talk about it, but you can pinch turn with Lathe/Mill and dial down your sync codes to the line using the process I developed. I am the crazy person so I will just kept on my path of just doing what I can when I can. 

All the best and soon I will revisit this syncing method since it looks like it will come full circle soon. If I do get what I want the way I want it it will be shared to help all who need it. 

We do offer a few methods to handle the sync codes in traditional Lathe+Mill, the most complex being available misc values for sync code inputs per op, positioned before approach, after approach, before retract, after retract.  And then auto-bookkeeping if the codes are not paired in the other streams.  Still not a granular mid-code / down to the line method like you are describing.

I ran through one of our Fagor 8065 posts and get G98 G83 Zn In Jn style pecking with all the calcs, so I'll reach out in a PM to see if we can have a look at what's up with your specific post.

On 2018-03-07 at 2:45 PM, WestRiver said:

We too have a Haas umc 750 and a Postability Post. Ours comes up with error codes 2.103 y axis servo error too large , 9971 excessive axis speed or acceleration , 949 internal feed error detected. The machine just stops, right after gouging my part, started doing it when I first started doing 5 axis simultaneous machining now it is doing it on simple surfacing. It has ruined (5) , 3500.00 parts in the last 2 weeks. Haas finally fessed up to the fact that they have a software issue and are going to up grade the software  some day soon  I hope .I would double check the   WRZP numbers as I don't see any 12" numbers in the code you have posted It could be the software with yours as well. Good luck!

I followed up with WestRiver and it sounds like a control software update has fixed his issues.

I to have been really underwhelmed by our service too. we pay top dollar and get bugger all and made to feel that we are lucky to get what that. 

e-mailed prosoft (our rep) friday morning about the issue got a reply late Tues. 

The reply didn't even relate to the post question! i only got a hard sell on some mastercam-u papers. so frustrated

 

is any one here versed in FIDIA code ? 

OK - figured out who you are bad-mod.  It's a Fidia retrofit on an Okuma Howa table/head style machine.  I think it's fair to say that it is a fairly custom situation.  Most typically TCP is setup with length comp in the head group, and a clueless table group that is not part of the TCP kinematics.  It's quite possible that your retrofit was configured with 'part coordinates'/full head-table TCP support.  We'd need to establish that with a bit of experimentation.  Even with very common machines, we can see differences in how the parameters are setup to handle this from installation to installation.  At this point, I'd direct you over to email, with thanks.

We ran into axes inverted with postability's okuma 5x post. We turned off tcp in the post which is for head head machines and that corrected the problem. I was disappointed with documentation that came with that post.

I to have been really underwhelmed by our service too. we pay top dollar and get bugger all and made to feel that we are lucky to get what that. 

e-mailed prosoft (our rep) friday morning about the issue got a reply late Tues. 

The reply didn't even relate to the post question! i only got a hard sell on some mastercam-u papers. so frustrated

 

is any one here versed in FIDIA code ? 

I only drop by eMastercam.com every few months, so it's very difficult for me to react or support you here in any meaningful way.  We do very much want to solve problems in order to have happy customers.  The best way to get support for a Postability post product is through your reseller.  We work tirelessly day in and out to support our clients, and it does upset me to discover unresolved issues here.

@lowcountrycamo:  Duly noted on your docs comment.  We don't expect users to customize our posts, so were aren't publishing guides on the use of the post switches, etc.  But perhaps you were trying to make some changes and experienced some frustration.  Table/table TCP is possible and supported, tcp : 2.  I do encourage you to let your reseller know what your core issues were that prompted you to switch that off.

@bad-mod:  I'm not clear if you have a Postability post issue or not, or if your comment was related to your reseller.  If your reseller must contact us with a 12 hour time difference, it certainly may take over 24hrs minimum for the initial back and forth.  Again if you have a question or concern, I do encourage you to reach out to your reseller so that we might get your issues resolved.

We're always very much interested in diagnosing and resolving any potential post issues.  Just need you to forward your Zip2Go via your reseller.

A word of caution on posts

due to some parameter changes, Postability posts will need factory edits to run in MC2017

You will not be able to update then yourself.

Its not a big deal and it's a quick fix but Dave will be getting hammered as people start updating

Make sure your posts are up and running before you start a big project in MC2017

I've seen no issues with mpmaster, pmgen5X or mpfan posts

I don't know if InHouse posts are affected or not

I can summarize this for you briefly and offer up a quick DIY fix:

We have used lathe post variables in our mill posts for quite some time as part of our Unified Post Kernel technology that features using shared post blocks across our products.  As of the final Technical Preview release, Mastercam 2017 performs error checking to prevent this practice.

In order to Migrate to Mastercam 2017 without error:

BEFORE MIGRATION change the post product code in the header line from P0 to P4 to make the post mill/turn, and therefore able to use Lathe post variables:

this

[post_VERSION] #DO NOT MOVE OR ALTER THIS LINE# V18.00 P0 E1 W18.00 T1274880253 M18.00 I0 O0

changes to

[post_VERSION] #DO NOT MOVE OR ALTER THIS LINE# V18.00 P4 E1 W18.00 T1274880253 M18.00 I0 O0

We do have the issues corrected across our library of clients posts.  You can certainly contact your Mastercam reseller with your current post, and we will be happy to provide you with a synchronized copy.

I don't drop by eMastercam.com often but wanted to simply share that we work to resolve all issues through our standard support mechanism which involves email through your Mastercam reseller.  It looks like this thread has about 3 separate items going on, although all Mazak.  I do recognize some of the names and believe that many of the issues are resolved.  Some were possibly related to default control parameter settings.  If anyone with a Postability post is experiencing any issues, I would highly encourage you to document what you can with supporting samples and send them in to your reseller for our attention.

Some good answers to this question in previous threads. Bullines suggests a theory that is confirmed by PDG. In general, it's not really as bad as it looks. When the Windows 'focus' is on the Mastercam graphics area, there is some keyboard and mouse polling (rather than using interrupts).

http://www.emastercam.com/cgi-bin/ultimate...ic&f=1&t=001025

http://www.emastercam.com/cgi-bin/ultimate...ic&f=1&t=001031

--

I think it's time for an official FAQ. When/if you feel like providing the definitive answer to frequently asked questions (rather than posting links to the earlier threads, please add an "**Add to[or Update] FAQ**" at the top of your well-written post, and I try to catch it, and compile into an eventual proper FAQ.

Chip Maker,

Mpmaster (available on this site under Posts) has the 20007 values already available. Search for 20007.

First initialize variables in order as they are on the 20007 line. Then in pwrttparam (for the tool table NCI pre-read) and/or pparameter (for the regular NCI run-through - not used in Mpmaster) add your rpar line:

if prmcode = 20007, pilot_dia = rpar(sparameter, 11)

This means if the current NCI parameter gcode is 20007, then parse the line into the 11 variables that you've initialized in order, starting with pilot_dia. All the other variables will be available for use in your tool table, or tool change comments.

[ 05-14-2002, 09:22 AM: Message edited by: Dave Thomson ]