Even when looking at parallel, I go straight to Flowline... unless it is multiple surfaces of course I agree, that edge rollover thing is a step backwards

Ok... Got it. Weird... But got it. I have to be honest, I haven't had to look at programming a horizontal in this manner for a long time, and it seems things have change a bit since I did. Back then it seemed so much simpler Basically it is a case of rotating the world gnomon about the Z axis. Thanks for everyones input on this. My post already had the above line uncommented, but it didn't force the B output.

Here is a sample file, and the image of the error returned. In the sample file, the first toolpath group I created should (in my expectations) output B0 and the second group should (as it does) output the B index. Horizontal Test.ZIP

That's what I have come to realise. But, to me (and of course, this is just my opinion), it doesn't make sense. TOP/FRONT/FRONT should indeed give you B0. But as long as the Y+ is parallel with the World Z+, DEFINED PLANE/DEFINED PLANE/DEFINED PLANE (WCS = CP = TP) should also output B0. At least, that's how it used to work, as far as I recall

It won't output B0 at all, and instead barks the error ill do a sample file today and post it up to show the problem.

Ok, so I have a question. I have a part, mounted on a fixture, and this part/fixture is mounted on the table of a horizontal (standard horizontal, with the B axis rotating about the Y axis of the machine). I have a reference face/edge on the fixture used to set the rotation (this is a one off part being machined). Operator has orientated the part by rotating B so the reference face is flat, and has set B0 in G54. To post the toolpath out so that the B output is 0, I would expect to have the WCS/CPlane and Tplane all matching (its a newly defined plane, using the reference face of the fixture, and the plane orientated to suit the way it is sitting on the machine) However, when I post it out, it returns the error "Select Machine Achievable Toolplane With Y Axis Along Machine Y - Set and Repost". The weird thing is, it is set correct, and if I set the WCS to Top, and the Cplane ant Tplane to the defined plane, it outputs the correct code, but with the B rotation of the amount that the defined plane is from the front plane. This is using MPMaster right out of the box, and the machine def and post are set correctly for a HMC. Anyone else encountered this? I've programmed plenty of HMC's before using MPMaster (earlier versions) and the above always worked for me.

I dunno, depends on what software you're using... LOL

I can see the term "MT Exclusive" being used more and more.... LOL I agree about turning away from the jaws without a tailstock. Yeah, I wouldn't be keen on that either.

Yeah, probably. So it will be a cheap addon.... Seriously though, I hate it when tooling vendors "partner" with singular software vendors to provide a solution for new technology. So, if you don't use the tooling companies products, and use the software, or vice versa, you're at a disadvantage. I'm with newbeee though, I don't like the idea of turning against the tailstock. Tried and true is heading towards the chuck

Interesting. I saw this yesterday. I guess it makes sense, given the approach angle of the tool. Much like using a high feed endmill against a 90 degree approach endmill. It will be interesting to see if any CAM vendors take up the programming capability for something like this, because it would be a bit of a pain in the a$$ to have to generate patches of code from the Coromant app, and then merge it into the code generated by the CAM system.

Daniel, 2 years and they're gone? What do you mean by that? The product life is only about two years? One thing Moxa isn't known for, is their strength. At my last employer, we lost three Nport servers with blown power supplies, due to a couple of power flickers. We're beginning to think that wired is probably just that little bit more stable

LOL, yeah, call me old fashioned too.. I'll check out the Moxa wireless boxes, thanks John

Very soon, we'll be moving our machine tools into a new building. As part of this, we'll need to set up the comms again. Currently, we're using Cimco DNC Max, and connecting the machines via RS232/Cat5 using a Moxa Nport server. The machines use the RS232 to communicate via the DNC Server, and a barcode scanner which we use to request programmes to the machines. The machines are connected using 25 pin to RJ45 connectors at the machine, and then the Cat5 cable runs to the Nport server. I'd like to look at using Wifi to connect the machines. Is anyone here doing anything similar, and how was it connected? And how have you found the Wifi reliability? I guess being a little old fashioned, I like the security/reliability of a hardwired connection. It just seems to work. Thanks for any feedback

Metric to Standard? Don't you mean Standard to Inch? Sorry, a metricated me couldn't resist

MPMaster is a Fanuc based post processor. While it could be modified to Okuma format, a better option would be to talk to your reseller. CNC Software have a dialled P300M post for MA/MB machines. Another option is to talk to your reseller about the MpMaster Okuma post. I believe that can only be requested through your reseller. Another option, (again, through your reseller) is a Postability Post.

Thanks Brad, that definitely makes sense to break the rotary moves into quadrants.

Ok, so I checked this out this morning. Using M404, going from C0 to C180, the table moves clockwise. Going from C180 to C0, the table moves clockwise.

I've just shut the machine down for the day, but I will check this in the morning

I have no idea Greg. I wasn't the one that made that statement Interesting scenario though. What happens with M404 when going from C0 to C180? I can't test it because the machine is right in the middle of a cut...

Hi there, Anyone out there programming one of these MU style machines in 5 axis? I have a question. Are you programming using M16/M116 to control rotary direction, or are you using M404 (shortest path method)? I got into a discussion with someone the other day, who said shortest path should never be used because you will end up crashing the machine. I've been programming this MU for about 3 1/2 years, and I've never actually encountered an issue with shortest path. Every section of 5 axis code I have run on the machine (and there has been a lot) has been run through Vericut, and it simulated fine. All our C axis (the 360 degree rotary table) code has the rotary motion between 0 and 360. I'm just curious on anyones experience with this

I'd just like to back up everyone here that has mentioned Postability. I've dealt with Dave and his posts before, and Postabilitys service is second to none. We have a Multus B400W Postability post and we've had nothing but positive interaction with Dave over its implementation and customisation. I'd recommend Postability posts in a heartbeat, and I wish we could purchase more of them.

I agree with Ron, that is a bit of a tall order, and also why? That means you'll get the tool comment and operation comment combined at every null toolchange, as well as every toolchange..

Is this on a MacTurn? Just curious. From memory, The I and K values control the rapid depth, and it is a case of always programming to highest clearance point, and then using the I/K values to control the point in which the tool rapids to the start of feed. I'd have to revisit it, as I haven't programmed the Multus with Mastercam in a while.

Ah, well while I use a bunch of variables, it won't be to the level you do I've done a bunch of model sectioning, and zooming in and out, but I guess I've been lucky. Hopefully the new patch works out for you

well, I can honestly say that in using it every day, I've found it as stable as 7.4.2. I've absolutely no problem with it at all.