Sequential Multi-channel questions/stream of conciousness

[Rob.Lockwood]

I'm looking at the feasibility of a post processor for a b-axis+turret mill-turn (NTX) and want to pick some brains on the multi-channel/wait codes portion.

Preface:

Machine has an articulating b-axis milling/turning head, Channel 1. Tools are generally loaded like milling tools, with a T##, H##, etc. These tools are also capable of being indexed to various angles, using a specific toolchange command (G361BxxDx) where Bxx describes the orientation angle and Dx orients for main/sub/milling (180* C rotation) - this code also corrects the tools offset. 

Lower milling+turning turret, Channel 2. Tools are generally loaded like turning tools, T####.

I don't care about actual multi-tasking, but would like to be able to utilize the lower turret due to the additional tool capacity it provides. Wait codes don't seem like an issue, but splitting the single operation up into two separate files is somewhat perplexing. It effectively requires that I take anything using channel 2 and postpone it for a later program. Now thinking about it, the Fanuc with Subprograms essentially does this.

Steps to success:

• Separate tool numbers into two groups, two digit numbers = channel 1, four digit numbers = channel 2.
• Use code from fanuc_with_subs to postpone channel 2 and output as a separate file. 
• Whenever code is split off to channel 2, need to output wait codes, since we're not allowing any overlap, these should be simple.
• To avoid collision, channel 2 should always be initially indexed to a blank tool and parked under the spindle, when it runs it should travel home/g30 and return to parked position when finished. 
• Turning with b-axis tools looks nice and easy. If I initially create tools in their base/natural position, when I want to turn at an alternate angle, simply duplicating the tool and modifying the orientation (tool_angle) parameter and feeding it to the post should do the trick. Each operation will need to compare the previous tool_angle and re-issue g361 if it differs.
• Check each operation to see if that operation is the last one using a tool prior to preloading, else G361 will load the wrong tool.
• Transferring stock is a whole different can of worms, will look into that later.
• Programming template would always use two jobs, and the workoffset would imply more than is typical; turning operations in the g55 job would need to use g361BxxD2, milling operations need the ability to mill from negative z. Might need more thinking here..

I'll probably keep updating this. If anyone watches in or has anything awesome to contribute, feel free. Hopefully I can keep this relatively Mori-agnostic, that way more people might get use out of it ..... @Laurens-3DTechDraw ... ahem

[Laurens-3DTechDraw]

About making a different file for the lower program look at what I and Achim did for the stock transfer.

Also keep in mind we are indeed going far beyond what HSMWorks was designed for but you already know this but others reading this might not.

You can't really use the orientation angle because sometimes you need 0 and 180 in the tool dialog's orientation depending on it being a true neutral, left or right tool. Like the Sandviks DNMG finishing tool need 45 degrees but is a left or right tool. (And grooving and inside turning are much much worse for this trust me)This only leaves the operations tool orientation but that for example isn't in the threading operation. And my threading tools are to be used on 45 degrees as well so you really need to give up a text box in the tool's info for the angle.

Milling from negative Z? I assumed the Mori would just flip the Coordinate system for the sub? Also think about there being a primary and secondary spindle drop down menu on the job. So you can easily check if it's main or a sub program. You would always need a separate job for that indeed.

We made the tool axis always X. So also for drilling and milling the tool axis is X. Not sure if this is possible on the Mori but that is easier in the post.

[Rob.Lockwood]

---

@Laurens-3DTechDraw wrote:

About making a different file for the lower program look at what I and Achim did for the stock transfer.

Also keep in mind we are indeed going far beyond what HSMWorks was designed for but you already know this but others reading this might not.

You can't really use the orientation angle because sometimes you need 0 and 180 in the tool dialog's orientation depending on it being a true neutral, left or right tool. Like the Sandviks DNMG finishing tool need 45 degrees but is a left or right tool. (And grooving and inside turning are much much worse for this trust me)This only leaves the operations tool orientation but that for example isn't in the threading operation. And my threading tools are to be used on 45 degrees as well so you really need to give up a text box in the tool's info for the angle.

Milling from negative Z? I assumed the Mori would just flip the Coordinate system for the sub? Also think about there being a primary and secondary spindle drop down menu on the job. So you can easily check if it's main or a sub program. You would always need a separate job for that indeed.

We made the tool axis always X. So also for drilling and milling the tool axis is X. Not sure if this is possible on the Mori but that is easier in the post.

---

1: where would I look at what you guys did? Agreed, there's going to be some funky stuff in here. Buyer beware..

But even the NX implementation comes with a manual, as it strays fairly far from the norm to make some stuff happen. I think with documented behavior (something generally lacking from HSMWorks posts in general) it could be safely used, eventually. 

Certainly expect some stuff in this thread to be ridiculously dangerous at various points, even if you know what you're doing. I'll likely be working on this in my free time mostly, unless I decide this is high enough priority to convince a member of the posts/apps team to come give me a hand.

2: do you have an example where the tool orientation wouldn't match? I did a few tests and was able to seemingly get everything aligned correctly using the tool orientation, but I only played with a boring bar quickly, so maybe ID stuff could cause problems. Still, i'd think there's a way to correct it via some conditions? Or perhaps by doing initial measuring differently? I dunno, would need to see..

3: Mori doesn't flip the coordinate system, there might be a specific code to do that, but at the moment it's not. Obviously there's a million ways to skin the cat while running one of these things, thus far i've just been running with Z pointing the same direction for both. 

[Laurens-3DTechDraw]

I re-emailed it to you.

I send it in our last e-mail contact.

[Rob.Lockwood]

a few of the things you brought up have me a bit concerned, I started digging into second op stuff where the turning would effectively be done Z-; the system won't allow generation like this, so it's likely going to require a post hack.

I'm glad you mentioned the main/sub selection within the job, using it is a bit less hacky than just basing it on a specific work offset.

Also starting to see some of the issues with using tool orientation directly. It's.. interesting.. that tool orientation causes as many generation failures as it does. Toying around it both HSMWorks and Fusion, it seems a neutral turning tool effectively fails to generate when used on end. It's also annoying that tools aren't allowed to generate code that uses the back side of the insert for generation. I'm thinking this means I won't be able to make use of some of the tenents of b-axis turning, like running a left handed tool as a right handed tool, etc.. or atleast will require some creativity, and I think this is what you were hinting at. For instance, a left handed tool could be used as a right handed tool, provided you define it as a right handed tool.. But then the orient angle is incorrect, so you need some way to lie to it. Is this what you were getting at?

Rob

[Rob.Lockwood]

On closer examination, this is probably just an isolated bug; a neutral tool set to face profile when inline with Z will fail to generate with 'outside in' but generates successfully with 'inside out' or 'both ways'

[Laurens-3DTechDraw]

Tools you can't set-up the way your are looking into as far as I believe: 

C6-PDMNL-00130-15HP

C6-266RS16100-22HP

Axial grooving tools

[Rob.Lockwood]

Ahh, I see. Those ones are issues as there is no way to properly define them in their neutral state, and the normal cure is to rotate the insert into position using tool orientation. Gotcha.

[Rob.Lockwood]

---

@Rob.Lockwood wrote:

• Turning with b-axis tools looks nice and easy. If I initially create tools in their base/natural position, when I want to turn at an alternate angle, simply duplicating the tool and modifying the orientation (tool_angle) parameter and feeding it to the post should do the trick. Each operation will need to compare the previous tool_angle and re-issue g361 if it differs.

---

Ignoring Laurens' incredibly valid feedback*, and armed with a nice fanuc based b-axis post to build off of**..

  if (turning) {
		if (hasParameter("operation:tool_angle")) {
			var bAxisToolAngle = getParameter("operation:tool_angle");
		}	
		if (hasParameter("operation:toolOrientation")) {
			var bAxisToolOrientation = getParameter("operation:toolOrientation");
		}		
		var bAxisOrientationTurning;
		if (bAxisToolAngle && bAxisToolOrientation) {
			bAxisOrientationTurning = (bAxisToolAngle + bAxisToolOrientation);
		} else if (bAxisToolAngle) {
			bAxisOrientationTurning = (bAxisToolAngle);
		} else {
			error(localize("B- Axis Orientation is empty in operation " + "\"" + (getParameter("operation-comment").toUpperCase()) + "\""));
			return;
		}  
	}

Combined with reading the main/sub to set direction and spindle orient.. is netting me a nice clean output*** in the format I need for b-axis turning operations. The below tool is setup at a 45* angle, using the tool orientation within the operation is rotated -20*, leaving me with a final angle of 25*. Because it's on the main spindle, it's output using D1 and flipped to negative. Neat!

G361 B-25. D1.

Dissecting the original requirements, It looks like the code is already setup to compare if the previous operation was using the same orientation angle, so that should be good to go. I still need to figure out how to hold the tool preloading until the last section, as the g361 command is a combined tool change/angle orient and would currently swap tools rather than just re-orienting.

* - I should say 'ignoring for now' - I think my eventual solution is to meet halfway, implementing an override\augmentation\correction using the Vendor parameter eventually.. But for now, if can get an OD tool running in combo with the milling head, we'll be miles ahead.

** - Fanuc b-axis/multichannel stuff varies considerably more from Mori's implementation than i'd expected, so while building off of this post saves me needing to implement multi-axis stuff, it comes with a bunch of additional baggage instead. Still, seems like a win.

*** - This works for this specific tool, but I haven't verified that the logic is sound with other tools/configurations.

Just want to add, this is another example where not allowing someone to edit their post really hurts. I'd love to keep the original post on this up to date. It would be an excellent way to manage an active task list for a project like this. I really imagined being able to pop into that post and mark things as complete with a reference to the post where the work was done, along with updating the list of changes to add additional things I hadn't initially seen.

[Rob.Lockwood]

---

@Rob.Lockwood wrote:

I still need to figure out how to hold the tool preloading until the last section, as the g361 command is a combined tool change/angle orient and would currently swap tools rather than just re-orienting.

---

This one should've been easier than it turned out, but tripped me up for awhile on a stupid error. The normal code looks to see..

IF { there's a next tool  -> output it (after the actual toolchange) to preload it . and if not

ELSE { it finds the first tool preloads that.

This is normally completely logical, and admittedly, my solution at the moment seems entirely non-logical..

  	if (properties.preloadTool) {
		var nextTool = getNextTool(tool.number);	  
		if ((nextTool && nextTool.number != 0) && (tool.number != getNextSection().getTool().number)) {
			writeBlock("T" +  toolFormat.format(nextTool.number));
			if (debugComments) { writeBlock("DEBUG = " + toolFormat.format(getNextSection().getTool().number));
			}
		} else if (nextTool && nextTool.number != 0){
			if (debugComments) { writeBlock("DEBUG = " + toolFormat.format(getNextSection().getTool().number));
			}
		}	else {
			// preload first tool
			var section = getSection(0);
			var firstToolNumber = section.getTool().number;
			if (tool.number != firstToolNumber) {
				writeBlock("T" +  toolFormat.format(firstToolNumber));
			}
		}
    }

Translation..

IF { there's a next tool & if the next sections tool is different from the current -> We can output the preload.

Else If { (it fails the above filter) we check again to see if there is a next tool, but since we now know it's the same as the current tool.. we do nothing. We don't want it outputting the next tool until we know the tool in the next section is different. We're still safe, because the upper filter will actually catch it when it does change. *1

Else { (it fails both filters) there's no next tool, so we preload the first tool.

All of this has the negative side effect of pushing the preload nearer to the next tool change, but it seems like a necessity, and a better compromise compared with not preloading at all. In most cases, the tool changer will still be fast enough to preload, and atleast it won't go loading the wrong tool for the operation.

*1 - this is the bit that threw me off. I neglected to notice that the preload section is buried under an If(insertToolCall) condition, which wouldn't occur on operations that don't initiate a tool change. It would've been useful to notice that though, as it's been awhile since i've done any post writing, and forgot how common (and useful) that condition is. Using it, the whole logic could probably be simplified...... but I don't see anything particularly wrong with my code. While the logic isn't easy to follow initially, it does seem to cover the usage case. But since i'm tired, I won't be surprised to find someone pointing out a huge logical fallacy with my thinking in the morning.

The actual size and scope of this whole thing is already starting to weigh on me; i'm not a full time post writer and probably don't have the time to be doing this. There's still a ton of work to do (i've almost knocked one item off of my list, and my original scope is probably a fraction of reality.)

To sleep we go.

[Laurens-3DTechDraw]

---

@Rob.Lockwood wrote:

---

@Rob.Lockwood wrote:

I still need to figure out how to hold the tool preloading until the last section, as the g361 command is a combined tool change/angle orient and would currently swap tools rather than just re-orienting.

---

This one should've been easier than it turned out, but tripped me up for awhile on a stupid error. The normal code looks to see..

IF { there's a next tool  -> output it (after the actual toolchange) to preload it . and if not

ELSE { it finds the first tool preloads that.

This is normally completely logical, and admittedly, my solution at the moment seems entirely non-logical..

  	if (properties.preloadTool) {
		var nextTool = getNextTool(tool.number);	  
		if ((nextTool && nextTool.number != 0) && (tool.number != getNextSection().getTool().number)) {
			writeBlock("T" +  toolFormat.format(nextTool.number));
			if (debugComments) { writeBlock("DEBUG = " + toolFormat.format(getNextSection().getTool().number));
			}
		} else if (nextTool && nextTool.number != 0){
			if (debugComments) { writeBlock("DEBUG = " + toolFormat.format(getNextSection().getTool().number));
			}
		}	else {
			// preload first tool
			var section = getSection(0);
			var firstToolNumber = section.getTool().number;
			if (tool.number != firstToolNumber) {
				writeBlock("T" +  toolFormat.format(firstToolNumber));
			}
		}
    }

Translation..

IF { there's a next tool & if the next sections tool is different from the current -> We can output the preload.

Else If { (it fails the above filter) we check again to see if there is a next tool, but since we now know it's the same as the current tool.. we do nothing. We don't want it outputting the next tool until we know the tool in the next section is different. We're still safe, because the upper filter will actually catch it when it does change. *1

Else { (it fails both filters) there's no next tool, so we preload the first tool.

All of this has the negative side effect of pushing the preload nearer to the next tool change, but it seems like a necessity, and a better compromise compared with not preloading at all. In most cases, the tool changer will still be fast enough to preload, and atleast it won't go loading the wrong tool for the operation.

*1 - this is the bit that threw me off. I neglected to notice that the preload section is buried under an If(insertToolCall) condition, which wouldn't occur on operations that don't initiate a tool change. It would've been useful to notice that though, as it's been awhile since i've done any post writing, and forgot how common (and useful) that condition is. Using it, the whole logic could probably be simplified...... but I don't see anything particularly wrong with my code. While the logic isn't easy to follow initially, it does seem to cover the usage case. But since i'm tired, I won't be surprised to find someone pointing out a huge logical fallacy with my thinking in the morning.

The actual size and scope of this whole thing is already starting to weigh on me; i'm not a full time post writer and probably don't have the time to be doing this. There's still a ton of work to do (i've almost knocked one item off of my list, and my original scope is probably a fraction of reality.)

To sleep we go.

---

I'm still not sure why you are doing this. If the machine can pre-load why only in the final section of a tool?

That can't be the way your machine was designed.

[Rob.Lockwood]

G361 is the tool change routine. It's also the only way to rotate B and have the tool offset track the rotation.. so you have to* hold the preload until after the last B-rotation when turning.

*I'm sure there's other ways, I'm largely just following what both esprit and NX did in their implementations..

[Rob.Lockwood]

I did a bit more work today and am close to having a working single channel, upper turret post. Boring stuff that isn't worth covering, mostly just figuring out what the codes in the default fanuc post do and matching them up to their Mori counterparts.. Just need to re-sequence some stuff (which is always harder than i'd have expected.)

My tip for the day is, it's easier to move things down in a post processor than to move them up. Sometimes, it's easier to move a bunch of things down than to move a single thing up. 

[scottmoyse]

---

@Rob.Lockwood wrote:

On closer examination, this is probably just an isolated bug; a neutral tool set to face profile when inline with Z will fail to generate with 'outside in' but generates successfully with 'inside out' or 'both ways'

---

I swear I reported that 9 months ago. Nearly 12 probably, when we were doing the turning tool tips.

[Rob.Lockwood]

Getting back at this..

Phase 1 - get main spindle + upper head working correctly. *possible that sub-spindle lands here*

Phase 2 - add mediocre support for sub-spindle + lower turret. 

I spent a bunch of time trying to make the b-axis tool orientations more automated, couldn't get it how I wanted, and stalled thinking i'd miraculously solve the issue in my sleep.

It didnt happen, and i'm just going to accept the fact that forcing the initial orientation through manual intervention (directly inputting it into the 'vendor' dialog, to keep parity with @Laurens-3DTechDraw) is the simplest way to get something going.

Revisiting my initial list of tasks is a bit laughable..

• Separate tool numbers into two groups, two digit numbers = channel 1, four digit numbers = channel 2.
  • This gets de-scoped, focus on making the upper work first, then we can add in the lower + split channels. Lower is productivity focused, we don't lose functionality without it.
• Use code from fanuc_with_subs to postpone channel 2 and output as a separate file. 
  • see above
• Whenever code is split off to channel 2, need to output wait codes, since we're not allowing any overlap, these should be simple.
  • see above
• To avoid collision, channel 2 should always be initially indexed to a blank tool and parked under the spindle, when it runs it should travel home/g30 and return to parked position when finished. 
  • see above - channel 2 will just run a program that parks the turret. This might cause stock xfer issues, but we'll tackle that later too.
• Turning with b-axis tools looks nice and easy. If I initially create tools in their base/natural position, when I want to turn at an alternate angle, simply duplicating the tool and modifying the orientation (tool_angle) parameter and feeding it to the post should do the trick. Each operation will need to compare the previous tool_angle and re-issue g361 if it differs.
  • see further above, just use manual input. Easier.
• Check each operation to see if that operation is the last one using a tool prior to preloading, else G361 will load the wrong tool.
  • this is done!
• Transferring stock is a whole different can of worms, will look into that later.
  • not even sure I should dignify this with a status, it's not even an action item
• Programming template would always use two jobs, and the workoffset would imply more than is typical; turning operations in the g55 job would need to use g361BxxD2, milling operations need the ability to mill from negative z. Might need more thinking here..
  • this one is silly, the sub-spindle status in the job just gets used to mirror the output. It might have more impact than i'm thinking, but i'll need to build a template and do some testing first, and we're not there yet. Not sure WHAT I was thinking here..
    • currently, the sub-spindle selection is currently implemented to cause turning tools to output using g361BxD2 rather than D1. This looks to be working properly. I'll likely look into using mori's mirroring code to make life simpler for sub-spindle work, but we had some issues using it on our NX post, I just don't actually recall what the issues were.

So according to the initial, this post is complete! But that's definitely not true. Everything is out of order, 5x simultaneous is not even remotely close..

And worst of all, there's a crucial flaw to using the tool orientation feature within HSMWorks anyway, the tracking point doesn't follow with the insert radius, but instead winds up out in the middle of nowhere. The good news is, it was easy to confirm this as a bug, because it doesn't do it in Fusion, it functions properly there.

So mission status as of today..

• Stuff needs re-ordered. The building blocks are now there, but with how particular this machine is about sequencing, there's a ton of work to do here before anything is usable. This is probably the highest-risk portion, as sequencing can turn into a nightmare tracking down what's wrong, and posts get hard to troubleshoot when you start moving blocks of code around.
• 5x simultaneous isn't even close. This one's "easy" just ignore it's existence for now. The post basically handles it completely separately from 3+2, and 3+2 looks good. I'd rather have 3+2 machine than one that sits, and if everything else gets worked out this should be easy to revisit. We'll place it in "phase 1.5"
• The demo part looks to have something in it that's designed to force polar (it's using more range than I have available) and it isn't forcing polar, so I need to take a look at why, it's possible I just never set the travel range.

[Rob.Lockwood]

• Turning with B-axis in different positions with the same tool needs to output a new g361 home routine and correct to the new b-axis position.

[Rob.Lockwood]

---

@Rob.Lockwood wrote:

• Turning with B-axis in different positions with the same tool needs to output a new g361 home routine and correct to the new b-axis position.
  • This was in there, just broken from some other changes. Repaired.

---

• Added main/sub control m203/m204 to tell the control which spindle we're commanding for spindle speed changes\CSS
• Forced an update of g361\Bx if main/sub switches.
• Not currently getting height offset output, need to track down why. I think the post started with g361\b\d combined with H and I removed it. 
• Milling tools are outputting g97 with the spindle speed, and spindle speed is coming out before the tool is loaded. I thought this was OK for turning, since they're not related there.. but isn't going to work for milling, so need to fix that, and may as well do it for both.
• It's also redundantly outputting a bunch of stuff, tool # and such.

[Rob.Lockwood]

---

Rob.Lockwood wrote:

• Not currently getting height offset output, need to track down why. I think the post started with g361\b\d combined with H and I removed it. 
  • Getting height offset output on turning tools, thought all was well here but just realized it's not coming out on milling. This caused a g68.1 format error which also caused me to notice that g68.1 isn't being cancelled with G69.
• Milling tools are outputting g97 with the spindle speed, and spindle speed is coming out before the tool is loaded. I thought this was OK for turning, since they're not related there.. but isn't going to work for milling, so need to fix that, and may as well do it for both.
  • Fixed
• It's also redundantly outputting a bunch of stuff, tool # and such.
  • Fixed

---

Ran first bits of code today, wound up doing a manual edit to add an M46 in before the turning operation, but otherwise that went well. There's some seriously funny stuff that happens if you accidentally output in Inch when the machine is in MM; the work offsets convert to inches but tool length offsets do not, and execute as though they're inches. I've never forced output to a specific unit before, probably easy. Milling paths are close, too, but failed for a few reasons listed above.

• Get M46 (disable c-axis connection) to come out conditionally for turning operations. Milling operations are outputting M45 (enable c) correctly, and output M46 upon completion.
• Milling paths need height offsets, and they need to cancel G68.1 coordinate rotation.
• G68.1 format is wrong for this machine. I don't entirely understand the format desired (the existing makes more sense) - Existing output shown needs changed to the second format. With those two, a simple 3d path executed properly with milling.  @Laurens-3DTechDraw @AchimN @al.whatmough 

• G68.1 X0. Y0. Z0. I0. J-15. K81.642

  G68.1 X0. Y0. Z0. I0. J1 K0 R15

• Force units to MM to reduce risk of some seriously goofy crashes.

[Rob.Lockwood]

This one's odd.. I posted out code on the main and ran it, it was good. I then posted out code for the sub, and was pleasantly surprised to find I was mirrored properly, it ran food too. Then I posted the same operation I previously ran on the main, and now Z is mirrored on it.

Feel like a moron, sure it's something obvious.. maybe sleep will cure it. 🙂

[Laurens-3DTechDraw]

---

@Rob.Lockwood wrote:
This one's odd.. I posted out code on the main and ran it, it was good. I then posted out code for the sub, and was pleasantly surprised to find I was mirrored properly, it ran food too. Then I posted the same operation I previously ran on the main, and now Z is mirrored on it.

Feel like a moron, sure it's something obvious.. maybe sleep will cure it. 🙂

---

Since my machine needs it mirrored you got that info for free.

Look for something function with "inverse" in the name.

Also look at one of my latest versions I send you for it to work properly.

Are you sure you set the job back to primary spindle?