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

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.

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.

March 23, 2000

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

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.

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.

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

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.

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.

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 ]