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

[Rob_Lockwood]

Yeah, was posting two separate jobs, one on main and one on sub. Getting some error when posting both jobs together that I need to track down too. I was fairly sure I based this on the newest version you sent.

Annoying, as I discovered the issue a few minutes before leaving for the day.. so it's been mentally weighing on me, without having the ability to actually look into it.

[Rob_Lockwood]

@Laurens-3DTechDraw - ugh, it's worse than I thought. It's definitely based on the 10.4 version that you sent, and naturally, it's behaving perfectly when I output with that post. And the sections handling the invert are working perfectly in your post. And everything else revolving around the primary/sub switch is working perfectly in my post. But the axis is always scaled backwards.

But, thank god for Dropbox. If I roll back to approximately 15 minutes before I left yesterday, it works. And since I was fairly diligent keeping notes, I might actually have a shot at tracking down what I screwed up.

[Rob_Lockwood]

D'oh. It's always the idiot behind the computer. To get c-axis enable\disable happening, I copied this bit..

if (currentSection.spindle == 1) {
    invertAxis(currentSection);
 	if(isFirstSection()){
	writeBlock(mModalFormat.format(getCode("ENABLE_C2_AXIS")));
	writeBlock(gFormat.format(28), "H" + spatialFormat.format(0));
	writeBlock(mModalFormat.format(getCode("DISABLE_C2_AXIS")));
	}
  }

and turned it into..

  if (currentSection.spindle == 0) {
    invertAxis(currentSection);
 	if(isFirstSection()){
	writeBlock(mModalFormat.format(getCode("ENABLE_C1_AXIS")));
	writeBlock(gFormat.format(28), "H" + spatialFormat.format(0));
	writeBlock(mModalFormat.format(getCode("DISABLE_C1_AXIS")));
	}
  } else if (currentSection.spindle == 1) {
    invertAxis(currentSection);
 	if(isFirstSection()){
	writeBlock(mModalFormat.format(getCode("ENABLE_C2_AXIS")));
	writeBlock(gFormat.format(28), "H" + spatialFormat.format(0));
	writeBlock(mModalFormat.format(getCode("DISABLE_C2_AXIS")));
	}
  }

and ignored that nice bit about inverting the axis.

All back together again, and playing nice.

If today I can knock out..

• Fix G68.1 problems
  • correct formatting
  • add g49 and g69.1
• Track down why I can't output an operation from main & sub at the same time..
  • Connected to how i'm outputting length offset, as it works if I suppress that. 

[Laurens-3DTechDraw]

Sounds like you can nearly start using the machine.

[Rob_Lockwood]

---

@Laurens-3DTechDraw wrote:

Sounds like you can nearly start using the machine.

---

Yeah, it's getting there. Managed to post turning operations for both main/sub at the same time, and they ran correctly.. I thought tilted workplane was generally working properly, because it sure LOOKS like it's working properly.. And I swear I ran code the other day, and it ran properly..

But now it's attempting to dive off someplace way outside the work envelope.. And more perplexing is that, like I said.. it LOOKS correct. I thought I must have the syntax for g68.1 wrong, as it's different than g68.2.. but here's a snippet of code from Hypermill, running some 3x code on a tilted plane..

G21
(M46 - ON MAIN, NEEDED PRIOR TO M303)
M303
(OPERATION 9)
G69.1
G49
G28U0.
G28V0.
G28W0.
G17
M45
(BALL MILL)
N1 (T73 3D Profile Finishing)

M01
( BALL MILL )

T2073
G361B0. D0. T3.
G28U0.V0.W0.
G54 
M369
G0 B-8.275 
M368
M69
G0 C9.384
M68
G43H73. B-8.275 
G68.1X-7.301Y0.603Z69.226I0.J1.K0.R81.725
M8
G97 S11926 M13 
G98 
(3D_begin.txt)
G0 Z50. 
G0 X-0.885 Y-2.807 
G0 Z8.874 
G1 Z5.874 F477. 
X-0.81 Y-2.878 Z4.874 
X-2.98 Y-2.848 Z5.051 
X-3.348 Y-2.857 Z5.104 

and here's some from my autodesk cam NTX post processor.. 

%
O1001
G98 G18
G21
G50 S4000
G28 U0.
G28 V0. W0.
G28 B0.
M45
G28 H0.
M46

N2053
(2D Contour 2)
M5
G00 T2053
M303
G54
M45
G28 H0.
G98
G361 B-15. D0.
G68.1 X0. Y0. Z0. I0. J1. K0. R75.
G43 H53
G00 C81.642
G98
G97 S4000 M13
M8
G00 X150.59 Z116.262 Y-0.825
X130.59
G01 X122.59 F400.
X89.352 F133.33
Z96.908 F400.
Y0.825
Z116.262
G00 X150.59

There's at least one obvious difference, mainly that the transform from hypermill is also relocating the xyz.. But i'm just not seeing anything that doesn't make sense. I'm sure the structure is there someplace to actually transform the origin, but I don't think it's necessary. There's two options for implementing g68.1, one with the g43hxx before and after, i've tried both and it didn't make a difference. My understanding is that the I/J/K in this setup just designate which axis we're transforming around, with J designating the Y axis, which should be static for B-axis head. The R value should be the 90+B-tilt (which in both of these cases is negative) and adds up correctly in both posts.. The two are certainly implementing the b-rotation differently, and I actually wasn't aware the Hypermill method shown actually worked (i'm mimicking the behavior of both Esprit and NX in mine..)

About the only thing I haven't done is to actually verify that the transform is correct. It looks 'correct enough' at a glance, in that both X+Y are in the positive direction, and the thing is generally trying to shoot off someplace negative from the origin (basically straight through the chuck.)

So i'm stuck here until I can get a handle on it. I'll probably have to put a call in to DMG/Mori, ugh.

Turning looks to be working well, though. So there's that.

[Rob_Lockwood]

Also, haven't confirmed that the "good" code above runs on my machine; only confirmed that it runs good on another, similar machine.

[Laurens-3DTechDraw]

Main difference I see is that with the Hypermill code the tool length offset is called before the G68.1, and in the HSMWorks version it's after the G68.1.

Where as I agree it shouldn't matter with these machines everything matters for some reason.

[Rob_Lockwood]

---

@Laurens-3DTechDraw wrote:

Main difference I see is that with the Hypermill code the tool length offset is called before the G68.1, and in the HSMWorks version it's after the G68.1.

Where as I agree it shouldn't matter with these machines everything matters for some reason.

---

Right, I mentioned that one in the post-- Next step will be to give actually running the hypermill code a shot on Monday, if it runs fine i'll just jump off a bridge.

There's two options for implementing g68.1, one with the g43hxx before and after, i've tried both and it didn't make a difference.

[Rob_Lockwood]

Alright, trying to track this one down..

I've now verified that the Hypermill code executes correctly.. 

I've also generated a new toolpath that's following a sketch without compensation, purely so that I can stick a WCS on the part at the same location as the job's WCS, but rotated to how the orientation and transformation should be occurring. Then I can measure relative to that rotated WCS and verify that the coordinates output are correct.. And they are. The X/Z are 

G00 X151.093 Z112.262 Y0.
X109.352
G01 X101.352 F133.33
X89.352
Z99.118 F400.
G00 X151.093

And it appears they are; Z/Y are correct, X is being doubled, which I think is correct. I do think they're reversed, and that the Z should be outputting the X position and vise-versa. But in this instance they're so close, and the machine is headed so far away...

And then I noticed something that seems odd with the 'working' code- the X transform is negative. And all of the X-values operate the opposite of what i'd expect. And my code is over-traveling Z (which is transformed to X... ) in the negative direction. 

WTF. It's odd, but i'm fairly sure if I correct the x/z output, and invert the x value outputs.. I'll be good to go. Will test in a few to verify.

I'd LOVE to hear any insight over why it's working this way, why Hypermill seems to know it works this way, and why it's not in the manual at all....

[Rob_Lockwood]

Haven't had any time to do testing with the g68.1 issue..

But have been using this post for some basic turning on the single main spindle, and it's working pretty well. No-Drag turning is pretty sweet. 

I've noticed a pretty common theme though, and it's likely my own fault. I didn't spec all of the turning holders, and all of my V-series holders are backwards. I've known this for awhile, but in NX, I can just tick a box, it'll flip the spindle 180*, correct B to the same insert position, and reverse the spindle.

I think most of this could be done easily using a manual NC op, or some trigger in the tool..

But it doesn't look like I can access the actual insert angle (just a letter designation, which I guess is good enough) or the holder angle (just the letter designation, which I guess is good enough) - and then I need to do some figuring with how this should behave when a vendor angle is input, I guess that would just layer on top prior to the rotation. Needs more thinking, but is fairly high on my list.

[Laurens-3DTechDraw]

---

@Rob_Lockwood wrote:

Haven't had any time to do testing with the g68.1 issue..

But have been using this post for some basic turning on the single main spindle, and it's working pretty well. No-Drag turning is pretty sweet. 

I've noticed a pretty common theme though, and it's likely my own fault. I didn't spec all of the turning holders, and all of my V-series holders are backwards. I've known this for awhile, but in NX, I can just tick a box, it'll flip the spindle 180*, correct B to the same insert position, and reverse the spindle.

I think most of this could be done easily using a manual NC op, or some trigger in the tool..

But it doesn't look like I can access the actual insert angle (just a letter designation, which I guess is good enough) or the holder angle (just the letter designation, which I guess is good enough) - and then I need to do some figuring with how this should behave when a vendor angle is input, I guess that would just layer on top prior to the rotation. Needs more thinking, but is fairly high on my list.

---

I have no idea on what your problem is here now.

I can use left and right hand tools in the machine and the post figures out how to rotate the milling spindle and how to rotate the turning spindle.

So not sure what things you are running into.

[Rob_Lockwood]

Hmm. You know, I may be over complicating this. I'll verify when I get in..
thanks!

[Rob_Lockwood]

So indeed, I was probably overthinking it. Using an opposite hand tool and flipping the spindle, in conjunction with manually entering the proper b-rotation into vendor is simpler. It's a little less automated, but probably not worth the effort to make it more automatic, I can just store the tool in both orientations, and life can move on.

Good job @Laurens-3DTechDraw - you get a Kudos.

[scottmoyse]

Why do you need to enter the b rotation into the vendor field? Isn't the orientation value in the tool definition or the turning operation sufficient?

Regards
Scott Moyse
Manufacturing & CAM Technical Specialist
Autodesk Expert Elite

[Rob_Lockwood]

I asked the same question early on in this topic, but i'll summarize here..

Certain tools can't be oriented properly using the setup/orient dialog, I think Lauren's classic example is a turning insert where the head must be rotated 45* to align the threading insert. (http://www.sandvik.coromant.com/en-gb/products/Pages/productdetails.aspx?c=C6-266RS18100-16HP) - super common tool on these lathes, and the combination of available parameters in the setup page simply won't let you put in a 45* setup orientation and have the insert sit properly.

That's compounded by two Solidworks specific issues, where when using the orientation options, the tracking point isn't rotating with the tool correctly (this works proper in Fusion ATM)

And lastly, Solidworks turning doesn't have the orientation settings in turning operations like Fusion does, so that just isn't an option..

So basically, it just doesn't work.

[Rob_Lockwood]

Can now confirm that my suspicions about g68.1 format/output were correct. Forcing g17, forcing x/z swap, scaling x from +2x to -1x and I have reliable milling code coming out. Now I just need to nail down all of the conditions needed to make the output work correctly, and maybe get it to not head to the home position after each milling operation with the same tool, etc.

[Rob_Lockwood]

Welp, it's always something simple. Turns out if your X-axis in your setup is defined wrong, it can really cause you some trouble-shooting headaches. I think i'm all set on the g68.1 front, except for maybe some un-doing of some changes I made. 

[Laurens-3DTechDraw]

---

@Rob_Lockwood wrote:

Welp, it's always something simple. Turns out if your X-axis in your setup is defined wrong, it can really cause you some trouble-shooting headaches. I think i'm all set on the g68.1 front, except for maybe some un-doing of some changes I made. 

---

Always something simple. Especially with posts.

Btw seen this?

• Added support for live versus static tool control in the tool library. Tools are live by default. #119

Latest development release: http://www.hsmworks.com/download/experimental

[Rob_Lockwood]

---

@Laurens-3DTechDraw wrote:

---

@Rob_Lockwood wrote:

Welp, it's always something simple. Turns out if your X-axis in your setup is defined wrong, it can really cause you some trouble-shooting headaches. I think i'm all set on the g68.1 front, except for maybe some un-doing of some changes I made. 

---

Always something simple. Especially with posts.

Btw seen this?

• Added support for live versus static tool control in the tool library. Tools are live by default. #119

Latest development release: http://www.hsmworks.com/download/experimental

---

Nice! i'd heard whispers that some stuff might be coming soon, maybe a fix for my turret designation problem as well (i'll have to check this out, it might be buried within this functionality)

I do still have a few things to track down; i'm getting an arc output on the wrong plane, probably something I caused 🙂

[Laurens-3DTechDraw]

Arc output on the wrong plane or G2/G3 problem?