Really appreciate your insight on the actual machine. It is rare to find anyone with real experience. I cannot say we have crashed this machine but I will certainly keep this in mind. My leadership mission is that above all, we do NOT crash equipment!!! I very much realize most get wound about deadlines, faster, more, and more. I realize that one crash can set you back months plus new machine costs. Couple that with my pucker factor of lathes in general.....lol They run so sweet and quiet.......until something bad happens, and then they are a bomb.

Thanks Colin. I will check for a more dialed post but not likely. I think my post edit work mostly came out of need and I would not say I reinvented anything, just worked with switches and position of code within the outputs. For instance, we had a minor issue with getting coolant to the nozzle before milling on one machine so instead of hand coding or programming a dwell, I just added a G4P0. somewhere after an M3/4. It was then easier to go add time to P0 as needed. Really basic stuff but coming out of other computer programming helps. It's piddly stuff that takes less time to go edit the post than even make a phone call. I do find it extremely helpful to try to track an output all the way to a machine because sometimes it is simply a programming issue and not even a most matter. I never understood why people just go program part before actually running through testing of simple features to ensure procedures are well understood. I like to play around with code and see what it looks like and does at a machine so we can build some confidence.

Thanks. Yes, I think the Mitsubishi hardware is good stuff. I was totally blown away with their tech manuals and even phone support. Wish the rest of the machine was that nice. I think I know what you are saying on the turret. They use a cam to index the turret so damage there could be a disaster?

You are correct that codes are extremely close to Fanuc. This machine runs NEC axis cards and Mitsubishi drives and motors. Obviously we are on borrowed time with the whole thing anyway, but if you have priced a twin spindle, Y axis parts maker lately, we at least want to try here. When you say MPMaster, do you mean the MPLMaster?

Thank you and I do agree that I might need to run this up the chain a bit to maybe contact other vendors as I can certainly understand not having a "perfect" post, but close would be my hope. I am going to go absorb some of your vids to maybe refresh myself there. At least for me, I have found huge benefit in being able to edit and tune a post to my liking. I think I might consider doing my own post for this odd ball machine as an educational piece, but at the moment I am not sure if I start with MPLmaster, Hitachi 2x, or what. I will absorb and think on this. It's not urgent, but something I want to get solved. I simply hate at-machine edits and patchwork programs.

It does seem that the Y and control mfg may in fact be more rare than assumed. Thus the reason for post complications. I guess that is why I was reaching out to see if anyone else has encountered them. Doesn't seem like it.

Though I have not pursued this at all, one thing that has caused major frustration is the loaded tools on the turret having a conflict with the stock, that is not fully realized until AFTER all programming and setup has been completed. In at least one case, I think we could fix some of this by ditching the 3 jaw chuck for a collet, but as soon as we do, we will have chuck work! lol Never fails. I have not tried to model up a turret and not even sure that is possible in MC. In a mill, all other tools are not a problem. Not the case with a lathe. My personal goal has always been to eliminate any need to edit at the machine. I realize minor stuff is normal, but I have had to resort to cut/paste programs just to get things done.

I am not new to post editing, but has been quite a while. As I understand it, our MC rep said they did not have an exact post for the machine, and wanted to build one. I guess I find that hard to believe, and questioning if that is a sales tactic. I think if I could get close, I could tune it in.

It is my understanding this machine has a Hitachi control. All boards just say "Seiki" or "seicos" on them. Never worked with a Yasnak, so that could be the confusion if the language is the same. machine is a 23B, with sub, Y, ejector, catcher,

Years ago, I came to the conclusion that this just doesn't exist for Seicos 3 but figured I might ask here. Another shop was messing with this drama and reseller just kept sending posts like "oh, try this"...."nope"..... I am at a point of splicing code because I can't get reasonable output for fanuc stuff (hitachi doesn't have fanuc control). I mean, if I knew one was out there that was even 90% close, I could probably tune it up, but so far it seems the live tool stuff just makes a mess.

Serious question, and I hope to find people that have used other programs. It is probably a BIG sore point with me with MC. Every rev promised "better", but it is still clunky IMO. I am not talking about simple 2 axis paths. I am talking 3 axis live tool, Y axis stuff, and all the extra prep codes that come with lathe work like running the turret to the work to bump stock to, bar pulling, parts catchers, etc. I think it is inherent to program at the machine, but I strive to minimize that. I am probably exaggerating a touch but really curious if you guys have found your 'happy' with MC in lathe stuff? Because outside this forum, it would seem my thoughts are shared by many, and most won't even touch CAM for their lathe work. I can't imagine mill paths by hand.

Sort of drinking from a fire hose here. Long story short, we don't use probes in machines right now. However, we have an older machine that came outfitted with an OMM/Mi12, but no probe. Very confident previous owner was using it. Not on the machine for show. I I took a crash dive into macros and probes. I still cannot get a clear answer which probes are optimal to own, and I am sure we will buy used, with no rush on this. Someone mentioned the newer heads use strain gages that are delicate, so older probes are probably preferred anyway. Recommendation was the MP10. I have a tiny book showing a few of the heads and looks like the main difference is the way they turn on/off? As well, the control in question is a 16MB, and I have read that having 'high speed skip' would be a really good idea. Would anyone have information on what parameters to check to see if this is turned on, or if that is more than just a parameter set? I am told the main difference here is just how fast you can go and still get an accurate measurement. As well, I got nothing but crickets from Renishaw regarding the add-on with MC. I am not sure what revision of MC that even became a thing? But I saw a couple videos that seem to be able to do arguments and variables right in MC. Not sure how that works. Really not interested in paying for it if our older machine cannot benefit. One thing I am questioning on the programming side is if it is even beneficial to have all the probing data in the main program? Is all the macro work easier to manage in a subprogram maybe? I am just wondering if the MC probing is really the right path forward?

We don't use X5 to program this simple fanuc 2 axis lathe much. Have a very simple profile and figured I would try it. I brought the part in as an IGS, then used transform rotate to get the part on its side. Then used create>turn profile to create the 2D geometry for the profile. I am using a WNMG insert. I generated a facing op to face the bar with Toolpath rough. I then tried to generate about anything, first starting with the whole profile I wanted, then resorted to just a single line chain on the OD of the bar. All the tool will do is come in, touch the start point of the line, and pull out. I will not follow along the OD in the Z axis direction at all. I am sure it is a simple fix as I don't use CAM much for this. I did go to planes and select X+ Z+, and move C and T planes to that. Nothing has made a difference. I have selected OD for the roughing pass but have tried nearly every combo. Almost like the tool settings are such that it won't allow Z direction turning. Thoughts on how I can home in on the issue here? I am kind of wondering if I got the part rotated incorrectly and may have an issue with my turned profile geometry.

I was in error on this for some reason and should have checked the programming manual first. The manual indicates G8 is standard for the machine. No indication of what all it does but I am sure it will help.

Dang it, sorry to drag up this old thread but we are reviewing this machine. We did buy it and have in the shop and been too busy to mess with it much until now. We are running tests on it and seems we really need some look ahead. You can hear it get cranky. Again, a 16MB control, and verified in the 9000 params HSM is not turned on, and neither of the two look ahead options. Still a bit unclear on them but I am certain we do not have the RISC processor so if that totally terminates the use of G5, we will have to excuse that see if there are other options available? Not sure if any parameter testing is going to require wiping out the memory or not? We have not tried a G5 or G8 in MDI but if it is not enabled in the parameters, it would not work, correct? We also have linear accel, not bell, and seemed that was preferred for HSM work? Not really wishing to tune servos right now but since we don't have work on it yet, it seems to best time to figure out if we can get more from the machine.

Appreciate the replies guys. I am still in the planning stage for a more "system wide" adoption that will work going forward, not just solve a today issue. G10 is a call to actually change the offset table, correct? Can also be executed with a variable but not sure if there is any advantage there. I am trying to determine if there is any advantage one way with the G10 vs G52? They both mostly do the same thing. The concern I have with messing with an offset just looking at the value, you don't know where you are. Its easy to play with nice round numbers, but not so much with X-3.54923+2.43948. I think some of our machines have an actual work shift display value which might be nice. The G54 never changes but the work shift will and we can visually see if it is zeroed as a check. However, what I would like to do is be able to program the shifts (or offset changes) in MC. What we do now is simply program ONE part. Then we use our sub post with misc variable setting to the number of offsets we want to run. If we input 4, the post will auto generate G54-G57 in a local sub program utilizing M97 local subroutines, and M99 returns. Example here. T1 M6 G54 (other prep functions) M97 P200 G55 M97 P200 G56 M97 P200 (somehow cancel workshift here) M30 ------------------------------------------------------ N200 Do stuff here.... M99 In the case above, I can go make adjustments to any of the offsets it will run. I also have a plan for restarts in the middle of a program. If I could replace the G55-56 above with a G52, I would be good with that. Or another method maybe using the G10. However, in all cases, I cannot simply setup a "times to repeat" and enter a shift value and let it rip because if one position needs tuned you have no way to adjust each position, one position is damaged and cannot run, or the program needs restarted mid program, there is no way to know where you are with certainty. Here is "sort of" what I would like to achieve but not certain all machines will work with this. We have more than just Fanuc. One is a Dynapath and I KNOW on it we have done repeats like this but maybe not how I would like to do it. I might just accept doing it with offsets and subs in that one. T1 M6 G54 (other prep functions) M97 P200 G54 G52 X4.0 M97 P200 G54 G52 X8.0 M97 P200 (somehow cancel workshift here) M30 ------------------------------------------------------ N200 Do stuff here.... M99 Above is what I have in my head. Maybe G52 needs a separate line but in this case, I am clearly calling my one and only G54 zero point and simply step known distances from it. Yes you can probably just make her repeat 20x with one line but with the above, I can easily restart and can even add a comment for each position for clarity. If X at ANY position needs changed, that becomes easy. I cannot get my head around how a control knows to return to the NEXT M97 line when using M99. The way I understand G92 is it was used before coordinate offsets or maybe just an alternative to. I have heard of programs where they want to go to a program and hit go in which fixtures never move so they just use G92 in the program. I am not a fan. I will never understand people spending 6-8 figures on a machine and won't spend 5min for setup verification. I get the need to eliminate setup steps but in a case where the machine could home out in the wrong position, or whatever, a program should drive to the or each of the zero points and force the operator to use an indicator to verify it is on.

Colin, I found some of your webinar vids which are quite helpful. I think primarily at this time, I am trying to determine if what I am asking is even possible from a machine controller standpoint. I am sure we can figure out how to get the code spit out as needed, but knowing what is needed is probably the first step. Could you or anyone speak to the repeating G52 or G92, or otherwise incremental step or workshift from an offset, listed in a program without the need to regenerate the toolpath code many times? As in our internal or local sub posting, the list of offsets is in the prep functions of the program and the controller goes up to grab each offset in the list as they are ran. I guess I could call our machine support group on that but not sure how helpful they might be on that.

Colin, is this setup as an internal sub post? Problem is I have our post now about how I like it! lol I hate to start over. Would it be too difficult to modify our post that currently outputs multi offsets as local subs, and get it to spit out G52s? Will the program otherwise work like this or are there other tweaks? It would help to see sample code of a G52 local sub program. We use one of the general variable boxes in MCX. When set to 1, it outputs as one offset as normal but if set to 2 or more, it generates as G54, G55, G56, etc, and reorganizes as a local sub program. problem I see is I would need to list out all the different G52s in MCX somewhere or have to hand code them later.

So we have been programming using internal subs for years. Mostly works fine for us. If memory serves the beginning of a program will have the prep functions and tool, then the list of offsets. Then the tool path operations are listed below for each tool starting with a line number and ending with an M99. What I would like to do is invoke this exact same functionality as the internal sub calls and use of M99 but instead of assigning a different offset, I would like to simply work shift relative to the first offset (G54 for example). I am not even sure if G52 can do this but wondering if.... T1 G54 G52 Y4 G52 Y8 etc Can we do something similar to this? This should be an easier tweak to our post than starting over! The overall goal here is to reuse the exact same tool path operations but at different locations. Not create multiples of the same paths as so many do.

How did that single point work out for you? What size? Would seem the chips would pack up in a small blind hole? But I guess Maybe feeding from bottom to top might work?

Have a 2 axis lathe with Fanuc OT control. Really need to machine to make a 1/4-20 threaded hole and I guess these machines just did not have the ability to do it. I have never used a tapping head as everything else has rigid tapping. In talking with others, it sounds like a basic tension/compression holder will work but need something pretty low profile. Tight quarters in there! Any recommendations would be great! We have 1.25" shanks. Sure looks like it would be slick to just remove a tool block entirely and make a custom block to recess a tap head but that might be over thinking it. Also, wondering if I should even consider single point for such a small hole? I know they make little solid carbides for this but never tried it and sounds like a rats nest of a problem without TSC in the tool. I really have not looked into programming a non-G84 cycle but a bit resistance to hand coding I guess, but there are no other cycles available that would reverse the spindle other than tapping in MCX, and that always spits out a G84 cycle. Is this going to be a simple work around? I have a lot of concerns like feedrate override, feed hold, etc. The machine does not have macros either, so this might end up being a "hold your mouth right" sort of deal. For these reasons, single point was sort of being considered as thought I have never tried it, I believe if you hit feed hold in the cycle, it will not stop until the next G0 move.

Thanks. Don't have access to machine right now, but I do have the programming manual and there is nothing in it at all about G5 or G8. Not as a standard or option. I would think if there was any ability there at all, it would have made it in the book? Or is there any possibility there are some preset parameters that the MTB might have edited to make this more of an automatic function? Sort of like the Haas HSM, you don't need to do anything to the code, the control just looks at it and knows what to do.

Well, made a few calls today and just cannot seem to find out the real ability of the 16mb control. I talked to Fanuc trying to learn what the block processing speed might look like. I realize that can be a moving target but some bearing would be helpful. I guess I may be missing a complete manual explaining how the look ahead features work, if any can be simply turned on, or what hardware might be needed for an upgrade. It think it is just a large hassle to move a machine in only to find out it won't do what we need. Fanuc did say the 16 was the hotter of the control series in the 16/18/21. Guess that is good news, but realize there is a big difference in back then and now.

hmm. I will need to learn a bit more. The machine is a makino, known for being able to turn corners at speed. Or at least the modern ones. This one has some age being a 16 control. From memory, I seem to remember one of our Haas machined had 250 block/sec and could not see its own nose, and seemed like anything more over 100ipm was out of the question really. But the rated max feed was only 200ipm or so. The makino is rated over 600ipm so I might have to hope they have some tricks there? Or do they maybe do this with shear servo power back in the day to force that machine to take a crappy path? I might need some clarification of HPCC, AICC, etc. To try and narrow our issues, assume we want to run a 1/2" cutter around a 4x4" part at 200ipm, with square or mostly square corners. Slowing for a finish pass is fine, but when roughing, we just don't want the machine to ruin the part. With a modern machine with look ahead, they will anticipate the velocity and vector change and slow the feed momentarily to within the mechanical limits of the machine. This is why Makinos are rated to insane feed rates. Not that it will really do that in small parts, but it will at least get to the max possible feed rate. Was look ahead even a thing on the 16?

Sorry, the company was looking at buying it so I don't have every detail but I know it is a 16mb. If it does not have certain options, are these things we can work the MTB to have turned on or is that a major upgrade situation? Like new boards and such? We don't want to get into major expenses on it right out of the blocks. Not looking to do crazy HSM paths that Brothers are doing. Just be able to run say a 2" square path at 200ipm and be smart enough to hold a god path?