21 minutes ago, jlw™ said:

If they could get that dang edge rollover easier to control I would use it but I can get sufficient paths easier with parallel.

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.

3 hours ago, gcode said:

search for and uncomment this line in the post

#sav_rot_on_x = rot_on_x    #Uncomment this line to output rotary axis value even when it's not used

and see attached file

If you want B0 output, the Y axis of the WCS plane must be parallel and opposite  to the Z axis of the tool plane

 

 

B Axis Test_G_Code.zip

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

2 hours ago, mkd said:

In my experience an untouched MPMaster will need TOP  FRONT/FRONT  to give you a B0.

in your situation with a face defined plane for B0, i would duplicate it and rotate it about X 90° to emulate "top" and set it as WCS.

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.

57 minutes ago, newbeeee said:

Face facts Mick - we're just so last Wednesday...

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

23 minutes ago, gcode said:

Or worse yet, turning away from the chuck jaws with no tailstock

I was cringing watching that video.

Still, I hope the Prime toolpaths aren't MT exclusive.

These insets and toolpaths could be productive in some VTL applications

 

 

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.

4 hours ago, gcode said:

I've looked through the lathe toolpaths in MC2108BP4 and don't see anything new.

Maybe they are just doing this in the mill/turn module ?????

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.

18 hours ago, Watcher said:

Wireless is OK with Moxa... Big advantage is that DNC Max can connect directly to Moxa and and Quatech devices without intermediate drivers installed in the server...

Moxa quality is Ok... But 2 years and they're gone... it used to be like that previous hardware generation... I suppose it is better now... 

Best brand in my opinion is COMTROL... 

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.

37 minutes ago, Greg Williams said:

I have never seen a parameter for 180 degree shortest path direction. I suspect this will be out of sight in VOLANTE somewhere. Someone with a machine will need to test it and report back

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.

The new engine to handle variables is the culprit behind our problems. Our WFL VMCs have THOUSANDs of variables, I think at least 5000... And this brought some issues to the surface...

 

For simples machines or even complex controls with lean variable sets, it´s not a big deal...

 

We´re seeing crashes as well while moving sectioned models, and zooming into them...

 

Got a new patch today... keeping an eye on it...

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

Wise man. Wait for 8.0.2 or higher.

 

It's not awful but not as stable as 7.4.2

 

Lots of crashes and performance issues for us.

 

In one case the reset time with our 3 WFL VMCs went from 5 seconds to 4 minutes. They fixed it and sent us a patch though.

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.