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

[scottmoyse]

Nice!! Finally.

[Rob_Lockwood]

Arc output on the wrong plane-

I typed up a long reply, but my brain is fricking fried.

The logic in the arc output section seems logical, it's checking if the operation is turning and on the sub spindle, and if yes flipping g2/g3 around, else if uses normal g2/g3 logic. This should work..

once again, as I'm typing this, i'm either on the verge of figuring out my own answer, or of my brain just exploding. I can't tell.

I think the issue lies entirely with my logic. To fix the output of g68.1, I swapped the output of z->x and vice versa.. But i'm realizing now that this shouldn't be necessary, and my solution there was way off base. The post needs to be recognizing that the coordinate rotation has occurred, and outputting the correct values. It's not at the moment, and I gotta dig into why, and do it correctly rather than correcting the output for a specific scenario, like I did by swapping the output. There's tons of reasons for the why it needs to work this way, and it was unbelievably short-sighted of me to think what I did would work.

But I probably need to look at sub-spindle take-over here soon. I have an actual thing that needs made, and it's too long to do without passing off. I have some good notes on how I want to make the part-off happen, so I may just abandon this whole milling thing for a bit.

[Rob_Lockwood]

yeah, g68.1 just isn't functional at all. I'll have to do some testing to figure out why. I can post with a heidenhain post and plane spatial gives me correct coordinates, posting with the umc750 post gives me the correct planes/coordinates, my post just isn't giving any actual 5x rotation. I thought it was working because I had forced some stupid stuff to make it work in a single orientation and incorrectly assumed (and failed to test) that if it worked in that condition it was working.. Ah well, I think at least i'm at the stage where the 'why isn't it working like I expected' at least makes sense, I know what's wrong with the output, just need to figure out why the post isn't doing the right stuff.

[Rob_Lockwood]

at home hanging out with my sick kiddo's today, but had a few minutes to look at stuff.

@Laurens-3DTechDraw took at look at my post and quickly pointed out to me that, since it's based on the post he and @AchimN worked on for his Doosan, the machine configuration is setup to redirect the machine so Z->X-- this explains a few screwy things I couldn't figure out. One being that the B-axis orientations were correct, even though they shouldve been rotated 90*-since this one worked out in my favor, I just happily moved along. The bad news is, that while the B was correct, it was causing Z/X output problems, I had fixed these awhile back and thought everything was great, but hadn't really nailed all of the conditions properly, and also hadn't realized that this would have additional issues downstream (g17/g19 are swapped, etc..)

I went ahead and did some preliminary work on correcting all of the down-stream collateral damage, and I think it's good to go, but need to do quite a bit more testing (5x simultaneous, though that's fairly low on my list) and actually prove it out at the machine.

I also opted to take a look at stock transfer.

The post already has some work implemented for using the stock-transfer operation, but that's really probably only a solution for chucker work, not bar-fed stuff that i'm more likely to do. The good news is, the hardest part of that is likely in outputting a second operation that controls spindle speed on the second spindle, and that work is done for me in the stock-transfer implementation. I'll likely comment the stock-transfer stuff out, as I'm not likely to ever use it, and it doesn't make sense to have it doing something that I haven't proven actually works..

Anyway, so I need to translate the work done for stock-transfer into conditions when the parting operation has the transfer-stock box checked, and do a bunch of work..

keep the head close to chuck1, advance2 (this one is interesting, as i'm not sure there's a way to define the distance. Hmm.) output a lower program to control spindle speed on chuck2, clamp2, unclamp1, pull, clamp1, do something to move the parting operation over by the pulled amount, part, retract2

[Rob_Lockwood]

Been awhile since I've updated here. Tracked down the last few instances of milling issues, had some instances where switching between turning/milling/turning or milling/turning/milling would cause the axis orientation to get mixed up, but was just caused by me having some stuff in the wrong places. That's all working and reliable. Still haven't touched simultaneous, but indexed in any orientation is working great.

I had fun times last week, the machine came setup with about three layers of safety zones setup and ultimately was limiting me from milling anywhere within about 2" from the chuck face.. It took a day or so for applications guys to get that sorted out, and in the process they wound up screwing up tool change functionality and a bunch of other stuff, so the machine was down for a week. Back up and going now.

I posted this video: https://www.youtube.com/watch?v=8YKa3tkscFs to youtube, which walks through how I intend to pass parts off. It also covers an awesome new feature the post team just implemented, which also will probably enable some cool stuff with clearance logic in milling.

I sat down with the manual/transfer sample programs yesterday, implemented a variable that signals the selection of the 'transfer stock' option in parting, and then inserted an 'if' statement to output a placeholder for where stuff needs to go when I want to pass off. I filled in some of the basic functionality shown in the video, which all seemed to work well. I was able to position the spindle, pull by the length necessary, have part-off occur in the pulled position, return the sub-spindle and continue machining after canceling g52.

Annoyingly, I found fairly late in the day that sub-spindle stuff wasn't being mirrored if I output both jobs at once, but @Laurens-3DTechDraw got back to me overnight with the fix, so i'll have to kudos a random post of his here out of principal.

I also just noticed that my transferStock variable isn't working in the 'onSectionEnd' function, probably because of where it's being defined.. so for now, returning the sub-spindle (g330) and canceling g52 is happening at the end of every section, rather than contextually only following the transferStock partoff operation. Should be easy to sort out, I probably just need to read the previous section, rather than being able to read the variable.

I'm also still trying to confirm whether I need to issue phase/speed sync on both channels. All of the manual/sample programs show it that way, but it seems annoying and illogical to me. At this point, i'm ignoring the existence of the lower turret and channel 2, and it will be annoying if I have to have a program with a wait code/speed sync in it to enable stock transfer. Mostly because it's almost certainly arbitrary, since obviously there are plenty of single channel machines with the same control doing stock transfer.

[Laurens-3DTechDraw]

@Rob_Lockwood always convenient to have someone on the other side of the world you can set to work when you go to bed.

[Rob_Lockwood]

(kudos given!)

Indeed! though, I prefer to solve issues before I attempt sleeping, that way I don't wind up laying in bed all night pondering them. This one though, I had a good feeling i'd figure it out in the morning with a pair of fresh eyes.. But was much easier once you just pointed me to the exact line causing the problem!

[Rob_Lockwood]

I posted some videos on Instagram of this post doing some work. I've successfully implemented a parting/pass off routine that works by reading the relative positions of op1/op2, it's pretty slick. I also implemented the parts catcher routine, but am being hamstrung by safety zones buried deep in undocumented parameters not allowing me to drive the sub-spindle close enough to the parts catcher to grab my small parts.. so waiting on DMG there.

I have also noticed a few conditions that aren't being handled correctly, namely if two operations are back to back using the same tool, the conditions aren't always outputting the right coordinates, or in some case it's reverting to tool-change stuff, even when the tools are the same.. So just need to sort out some conditions there and get it working bulletproof.

I also have some issues when setting up tools, in particular getting a tool to work in multiple orientations without having to redefine the tool. I think this actually needs some work on the CAM/tool library side, as at a minimum i'd like to see some more options for where the control point is located, as I think i'd need to swap to something stupid like a center control point to make it actually work, or have an offset for every orientation, due to tangent control points always being assumed to be aligned with x/z..

[scottmoyse]

The way those tangent control points are setup is an issue when it comes to sub 35deg inserts as well. I haven't tested it at a machine, but I'm pretty sure the only way to get a 25 deg V groove turned on a face, is to define a round insert grooving tool, with the radius matching the ~20deg insert tip radius, with the center of the radius being the reference point. Not ideal.

[Laurens-3DTechDraw]

---

@Rob_Lockwood wrote:

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.

---

@al.whatmough Can you check-up on this serious issue?

[bac244]

Rob,

I modified the Doosan Mill/Turn post a few years ago to run my Hitachi CH250 Super Hicell machines and now I'm looking to do the same for my NT4200. Obviously I came across this old thread and found you had already made significant progress.

I know it's been quite some time but are you willing the share/sell your NTX post? It seems to be a better starting point for the NT. Would definitely take less modification than the vanilla post.

I sort of kept track of time when modifying for the CH250. I think it was 80 hours before I had a reliable post. It was my first time so probably do it faster this time...