1 hour ago, gcode said:

I tried this 3 times and got 3 different answers, none of which were correct.

Parametric modelers, Catia, SolidWorks and NX all got the same answer as did Jake's old school geometry solution.

 

I mean if MCAM implemented a proper one. We're in agreement here.

18 hours ago, Aaron Eberhard said:

You need 2 pieces of information to create a tangent arc. If you have those two pieces of information, you can calculate the missing 3rd, right?

There's a critical piece of missing information to solving this, which is either the tangent point (on the bottom line) or the radius.    Without specifying those two, there's an effectively infinite amount of possible answers.

But the distance from the intersection to the tangent point have to be equal for both lines, always. We've got that for the angled line, it's all that's needed.

Jake: A "tangent - 2 entities - thru point" type option would save you a few clicks, but your doing it right geometry wise with the "line bisect" method. 

You can define both your jaws and tailstock center in the stock set-up page.

Tailstock advance/retract and part transfer still work.

You're going to want to add M00 from your canned text before the transfer at the least for tailstock removal, it's even better to check the chuck clamping condition - i.e Nakamura lets you check it and alarm out (G471Y0102.7Q1.I9998. <- if not clamped GOTO9998, have alarm and message at N9998) or check some other machine state that will prevent crashing when the sub-spindle moves across.

If you're going to do it a lot, it's worth making a spring loaded holder for the center and having it on the turret or in the tool chain (if that type of machine).

What a lazy xxxx of a draftsman.

14 minutes ago, crazy^millman said:

you mean 85 degrees not 850 degrees ?

Being low on coffee, and lazy I went with .00015"/1"/20F. New super small spindle cartridge?  

Only time I've run into something like that was from the thermal comp being jacked.

It's that or your shop is getting 850F warmer during the shift.

14 hours ago, Kyle F said:

had to google,... never heard of that stuff but that sounds interesting... I'll keep this in mind for future fixturing mess-ups 

It's not the cheapest, but it sure is good stuff. Used buckets of it saving parts for power gen, chemical plant, off-shore and mining customers.

Machine table repair was a happy consequence, has saved a lot of heartache.

8 minutes ago, rgrin said:

Just don't overshoot the tolerance...

That's the sketchiest part of machining the bushings into the table IMO.  You only get 1 chance to get it right.

A little belzona can give a guy a lot of first chances. 

We've had really good experience with Lang. You can put the studs on almost anything and haven't run into any problems with repeatability between set-up swaps.

https://lang-technovation.com/en

2 hours ago, Aaron Eberhard said:

I'm not trying to give anyone the run around or make excuses.... I'm just trying to help some guys out on the forum using past connections if I can.  I'm just a dude, playing the dude, disguised as some other dude

I was being generic with the run around bit, I'm sorry if it came across as directed at you. You've invested some time on this topic and dug up a lot of info for sure.

2 hours ago, Aaron Eberhard said:

The syncs come out perfectly fine.  The whole system works okay.  

It's just tedious because you have to manually set the syncs on each toolpath.  Just like your MI$ solution (only syncs happen in the Code Expert window on an MT environment, but basically the same thing).    On a "normal" machine, you don't have to to do that.  After you sync, the machine will chill there until given an additional command.   It appears on these machines that each operation requires a sync whether it's objectively "required" or not.   That's means there's a lot of alignment PITA to manually sync everything. 

Bit of a contradiction here, the whole manual PITA doesn't sound very perfect. All I have to go on here is wild speculation (not seeing anything workflow and am assuming gildemeister struktur for the .mpfs) , so grain of salt and all, but I used the mi$ as a dummy flag and the required syncs increment/output automatically (I'm sure there's other ways to accomplish it as well). 

If nothing is in gildemeister struktur, then none of what I've said applies.

17 hours ago, Aaron Eberhard said:

It seems like the problem lies in disconnect between workflows using a Structured Language output (not the standard ISO/G-Code) using a CAM system (Mastercam/Partmaker/etc.), vs. the onboard programming language, and how they get the end goal. From talking to a few people, it seems like all of the structured code itself coming out of Mastercam is correct.  It's all the stuff around it that's a problem and it really makes it tedious to get running.

DMG wants everything ran on the machine in structured format, which is apparently really good at what it does.  It will wrap up all of the kinematics into it, so collision avoidance, easy edits at the control, etc. are all enveloped in this which makes it way safer for the operator and way easier for the DMG techs to help with.   The downsides are a lot of the things we take for granted in the ISO/G-Code world (i.e., only needing a sync if you specifically call it out) don't apply.   Being Das German, ya, there are rules and structures that exist for the sake of rules and structures existing

This is the general run around I experienced, and at the end of the day it's just a lot of words to say they don't want to expend any effort to provide an actual solution.

The 840D isn't a black box, the Siemens manuals are probably the most in depth I've dug through.

Getting clean, fully functional code that gives the majority of bells and whistles isn't even a herculean task. It's syntax and formatting.

Collision control is all $P_WORKAREA_CS_ variables, cycle shapes just need a few special characters to open in the graphics menu.

Syncs aren't magic either, they just aren't the same as an M-code. INIT,START,WAITM,SETM and CLEARM - took an m$, buffer and a pretty short post block to sort out.

DMG apps can't tell you what the CAM output should be, because they don't know outside of the control menu. The solution providers don't have enough customer demand to really want to bother, so say things like ....

18 hours ago, Aaron Eberhard said:

Expanding on this last point, there's also not a good way that you can programmatically describe a solution because it's very much part dependent so you can't really even wave a magic wand and get something that's even 75% of the way there by defining a set of rules, e.g., Always sync Approach of Upper Turret before Motion of Lower Turret.  That makes it a really tough nut to crack from the programming side as without those rules, it's hard to express to a programmer how to fix the issue.

 Sorry, I'll never understand why pretty lame excuses from both parties are accepted with CTX machines specifically, and I guess I have some residual bitterness at the memory of those interactions and no progress was made in the 6 years since apparently. 

I'll usually use a Thread Mill path.

Keeps the tool engaged instead of repositioning like contour.

Don't end up with the transition lines like a surface path and control comp for any required size adjustments.

Can also back bevel undercut bores.

Every time I have to do this I just finger cam it.

Taking 0.197" of a 4" cylinder would be like:

G90 G00 X3. Y0.2 Z.25 B0.

Z-2.

G01 X0 F150.

G91 G01 Y0 B2400. F750. (feed depends on machine totally, B value is 0.2 divided by 0.03 step over)

G90 G01 X-3. F150.

It is easily doable in MCAM, I just hate needless bulk to the point I'd just do a G65 macro call from manual input if it happened often enough. 

Add a spindle orient with a turning tool and you can do turning ops this way too.

You can also just add .WPD to the folder name where the .MPF and .SPF are and cut/paste straight from the key without chancing something getting borked.

MCAM -> posted MPF/SPF files -> Part CH1/CH2 .WPD folders on key -> into the control

Only times I've done anything with .ARC is controller backups/parameter dumps and firmware upgrades.   

The machine support from DMG is pretty top notch, they moved some mountains when my old shop was getting through the commissioning of our CTX.

App support was decent, really good with anything controller related, absolute pants with CAM/post things.

Overall, I really liked that machine.

The only post solution IHS was willing/able to offer was an M/T environment that would post bare bones ISO. No Cycles (rough turning, threading, etc.), just good old line by line, "re-post if you need to change something at the machine".

I ended up just adding a ton of modifications to MPLMASTER and made a CHOOK to generate the MPF and SPF files after being told by the post department that they couldn't do it.

Hopefully there's better options available (doesn't sound like it from your post), but you guys should be all over them if the provided solution isn't coming close to expectation, it certainly wasn't provided cost free.

On 4/10/2021 at 9:23 AM, 10LIONS said:

pcant_1 #Canned text - output call

cantext$ = cant_val1$

pcant_out <--- that's the post block your looking for. If it doesn't come up when you're searching the post, it's in the binned section and there's nothing you can do unfortunately.

8 minutes ago, Colin Gilchrist said:

I don't want to say that, as I haven't been keeping up with either of these threads specifically. But there is the "built in ability" to trigger M-Code and/or G-Code Text Strings. It is called Canned Text, and has existed inside Mastercam for many years. Since back in the V9 days, and possibly a bit before that.

Canned Text can is actually the mechanism used to "expand V9 Coolant", from a single variable, to the option of 10 on/off pairs of m-codes, which is referred to as "X-Style Coolant".

Some Toolpaths support the "Change at Point" function, which allows you to output Canned Text at a specific position along the chain. The issue is "what happens if you output multiple passes or depth cuts"? This is where Change at Point is limited. I don't know what Lathe or Mill paths support it specifically. I commonly use this function with Contour Toolpaths. The benefits of Change at Point is that these changes 'stick' as part of the geometry input to the path itself. 

Then, for changes on a deper level, there is always the Toolpath Editor. Here, you can make changes at any point along the path. But be careful, these changes can sometimes corrupt a path. Also be careful about Modality when it comes to Feed and/or Rapid changes, and especially if you are changing Depths. Here, you can output Canned Text at most points. 

When this occurs, you simply get a 1025 Line, in the midst of your NCI Data stream.

 

Now, is this the right way to fix your issue? Likely not. I'd really have to dig into your Post, and look at the issue you are having in-depth. I honestly have quite a few different people seeking out my help with Post issues. So I hopefully didn't stir up trouble for you, but I'm always of the opinion that we should learn as much as possible about how the system functions, so we can have meaningful control over the output of every Toolpath. I would be willing to dive into this at some point on my YouTube channel, but there are a couple of requests which I've arranged to cover first.

I've used canned text for drilling output and a few M codes/macro calls before, but I was ready to light my desk on fire if I missed a simple fix for psccomp behavior in this instance.  Oddly, it only comes up in the lathe side of the post. Remove psccomp from ltlchg$ and comp doesn't output until it's cancelled.

Yet psccomp isn't even part of mtlchg$ and it still reads it and outputs comp in plinout/prapidout just fine.

Overall, it's an interesting quirk and was fun in a "throw your keyboard" kind of way to find a work around for.

My post may be ugly as sin and would make anybody else cry, but the code comes out pretty and error free at least. 

I appreciate the insight Colin, thank you. I'll be sure to check out your channel, you're a wealth of good info on here.

2 hours ago, Colin Gilchrist said:

There are flags in the NCI Data which tell MP to output a Comp On or Off command.

The reason why you don't see the output from all the places 'psccomp' is called, is due to a feature of the Post Language, called Modality.

Modality tells the software to 'only output a new value, when the old value has changed. But do not continue to output redundant tokens to the NC File. Only output values if the value has changed.

You shouldn't remove the extra calls to 'psccomp', unless you really know what you are doing. It is easy to inadvertently break the existing mechanisms inside the Post.

There are many calls to 'psccomp', because Canned Text can be used to turn Comp on/off at any point within the path itself.

 

Thanks for the response Colin.

I don't quite understand the Canned Text comment. Are you saying there's no reason for a solution like  Werktuigbouwer's or the absolute clusterf*ck I've mashed together because there's already built in ability to control the output position? Or a person would still have to build the logic in to exploit that from NCI 1025 or similar?

Anyone have any insight into why psccomp doesn't return an output when you just remove it from prapidout? It's in plinout, but doesn't seem to do anything as far as outputting comp.

Milling ops and end of lathe ops force psccomp somehow as well.

I found a dirty solution, just wondered what's actually driving in the background.  

Have you tried putting it in your pl_/pm_retract? You might need to set a variable in the tool change and then call it there or ptoolend. Tough to tell with the vague description...

There's a thread for this with some really good info on how to go about it with either a stack or buffer. You'll be able to pull the zmin for each tool and add whatever clearance. 

Well, I finally gave up on the buffer route for this problem. I just couldn't get to the record I needed in the proper order with the way the post accesses the min/max values during processing. 

So, I ended up going the easier route and adding this into the pwrtt$ postblock.

if t$ > 0 | gcode$ <> 1001,
		[
		b4_min_depth = abs (z_min$)
		b4_min_depth = (round(b4_min_depth) + 0.5)
		"(", *b4_min_depth, no_spc$, 34, "MIN OVER HANG)", e$ 
		" ", e$ 
        ]

Takes the min depth, rounds it and adds a 1/2" clearance. It adds it after the ptooltable output for each tool. Not exactly in the location I wanted it, but it'll do until I revisit it some day.

Seems like a pretty low bar. 

1 minute ago, geirsj said:

Hope it will be available some day, for now it seems that the NCI ref guide for 2020 says it is not  available.

G

 

The amount of things available to the set-up sheets that can't be read by the post is maddening sometimes.

Was adding a little logic to an MPLFAN post and ran into a bit of silliness. Basically, I just wanted to set a variable based off of the value of plane$. Should be easy enough, it can only be 1 of four values and you can grab it from pretty much anywhere in a mill post. So off I went:

if plane$ = zero, my_var = one
if plane$ = one, my_var = three

etc

no matter what I did, it always spat out one. So, I just set my_var = plane$ and yup, big ol zero. Moved it all over the post to see if it would change the outcome and pulled my hair out realizing every nci line that it outputs plane$ for mill, it sure doesn't for lathe.

I ended up tracing where the post digs out sg17-sg19 and was able to set my_var there, but seems like a bassackwards way of getting to it. Anyone know where/if plane$ is actually output anywhere during lathe toolpath processing and I missed it? Or does it actually not get treated the same as in a mill toolpath?