Bar-puller positioning

[mfeathers]

Hello, fairly new user here. I'm working on trying to get our bar puller to work in the Post Processor instead of manually adding the code each time. I've found quite a bit of useful information on here using search but, I've stumped myself. It seems that most bar pullers people are using, feed onto the part in Z... ours feeds on in X. It's the right angled one pictured here. I've got a functioning code generator now and using a parameter from stock transfer to pull the bar. What I would like to do is rapid to an x position relative to the part or the stock diameter and pull off to that value as well (in the following example, it's the 1.25 value). Another issue I'm having is that my xOutput values are posting at 2x whatever I have in the code.

function onCycle() {
  switch (cycleType) {
  case "stock-transfer":
  // will use this for bar puller, xOutput values are half actual output
  writeBlock(gFormat.format(28)); //machine zero
  writeBlock(mFormat.format(5), mFormat.format(9)); //spindle stop coolant off
  writeBlock("T" + toolFormat.format(1212)); //tool change
  writeBlock(gFormat.format(54), gFormat.format(98));
  writeBlock(gMotionModal.format(0), xOutput.format(1.25), zOutput.format(-cycle.eject)); //rapid bar-puller into position by cycle.eject amount
  writeBlock(gMotionModal.format(1), xOutput.format(0.05), feedOutput.format(toPreciseUnit(100,IN))); //grip bar
  writeBlock(mFormat.format(11)); //open chuck
  writeBlock(gFormat.format(4), pOutput.format(1)); //dwell
  writeBlock(gFormat.format(98), gMotionModal.format(1), zOutput.format(0)); // pull out to 0
  writeBlock(mFormat.format(10)); //close chuck
  writeBlock(gFormat.format(4), pOutput.format(1)); //dwell
  writeBlock(gMotionModal.format(1), xOutput.format(1.25)); //pull off bar puller
  writeBlock(gFormat.format(99), gFormat.format(28));
  return;
  }
}

This was adapted from an apparently very popular bar pulling tutorial on the web. Any assistance would be greatly appreciated.

Thanks,
Mark

[Greg_Haisley]

mfeathers - code looks good to me. The X value doubling probably is because your programming a lathe, where X is a diameter value, in the post it probably is a radius value. We use par pullers all the time on our Mazaks. The Mazaks don't support "EIA" g-code or I would have pursued this problem myself.  Your approach in the code seems right. If you machine supports a spindle orient you might want to use it for HEX or Square bar stock. Should be M19. Some machines support M19 with an angle like M19A30. Good luck.

[skidsolo]

The X doubling will be the xformat statement that will have a scale to it for diameter turning.
example:
var xFormat = createFormat({decimals:(unit == MM ? 3 : 4), forceDecimal:true, scale:2}); // diameter mode

[mfeathers]

Thanks for the replies.

Greg - I hadn't even thought about anything that wasn't round... it's not anything that we do now but it's always good to have an idea about the future. The code posted does in fact generate working code. I took our working code and merely wrote something in post (thanks to a previous post by Andrew) that would generate the same as what we were adding manually.

Andrew - I'm not sure I want to mess with anything that could cause issues elsewhere in the program. I'll have to search the document and see where else that value might be used.

What I was initially asking here was for the X value in my code that = 1.25 (or 2.5 after post), is there a way I can make that X value something relative to say, the stock OD? as an example...

where I have:

xOutput.format(1.25)

I could use something like:

xOutput.format(stockOD + .5)

where StockOD is taken from a value in setup or stock transfer, perhaps something on the radii tab.

I just realized I could manually add it to the list of variables at the beginning of the code that prompt when you first post from Inventor but, it would still be nice to get that value from Inventor itself.

Thanks,
Mark

[mfeathers]

Greg Haisley wrote:

mfeathers - code looks good to me. The X value doubling probably is because your programming a lathe, where X is a diameter value, in the post it probably is a radius value. We use par pullers all the time on our Mazaks. The Mazaks don't support "EIA" g-code or I would have pursued this problem myself.  Your approach in the code seems right. If you machine supports a spindle orient you might want to use it for HEX or Square bar stock. Should be M19. Some machines support M19 with an angle like M19A30. Good luck.

Oops missed your comment about positioning. I had no idea what EIA was (I've only been doing this about a month). Is this some sort of spatial positioning the machine itself does? ie... it's aware of the size of the material in the chuck? That would be pretty badass. Anyways, I'm really just looking to see if there's a value I can pass from "transfer stock" in HSM to the post processor and then add another value to it.

from searching I've found 2 variables that appear to be passed from HSM, cycle.transferZ and cycle.eject, I guess I'm just hoping there are more.

[Greg_Haisley]

mfeathers wrote:

Greg Haisley wrote: mfeathers - code looks good to me. The X value doubling probably is because your programming a lathe, where X is a diameter value, in the post it probably is a radius value. We use par pullers all the time on our Mazaks. The Mazaks don't support "EIA" g-code or I would have pursued this problem myself.  Your approach in the code seems right. If you machine supports a spindle orient you might want to use it for HEX or Square bar stock. Should be M19. Some machines support M19 with an angle like M19A30. Good luck. Oops missed your comment about positioning. I had no idea what EIA was (I've only been doing this about a month). Is this some sort of spatial positioning the machine itself does? ie... it's aware of the size of the material in the chuck? That would be pretty badass. Anyways, I'm really just looking to see if there's a value I can pass from "transfer stock" in HSM to the post processor and then add another value to it. from searching I've found 2 variables that appear to be passed from HSM, cycle.transferZ and cycle.eject, I guess I'm just hoping there are more.

EIA is the g-code in a Mazak lathe. I have always thought Mazak was missing the boat by having customers pay extra for code that is already in the machine in the first place (money grab). Mazak conversational programming language runs macros in the background that are in the EIA format anyway.

[mfeathers]

So, I'm still trying to figure out this positioning thing and just regurgitating into cyberspace here. I'm not sure if there's a list of parameter somewhere that get passed from HSM to the post processor (that sure would be handy).  Searching the forum here I found some cycle.* parameters similar to the one I had used previously for my zOutput. Using cycle.stock and giving it a spacing for my bar puller seems to work, although it yields results I wasn't expecting. Just outputting cycle.stock gives me a value I cannot find anywhere in my program.

writeBlock(gMotionModal.format(0), xOutput.format(cycle.stock + .875), zOutput.format(-cycle.eject)); //rapid bar-puller into position by cycle.eject amount

Additionally I've been working on another modification that will allow me to optionally add a program loop into the code with a specified number of iterations. These are listed in the dialogue box presented when posting from Inventor. I've added these in the properties as such (removed other code for presentation).

properties = {
  gotLoopProgram: true, //enable loop
  gotLoopNumber: 3, //number of loops to run
  barpullToolNum: 12, //Bar Puller Tool number
};

I've used gotLoopProgram as an if statement in a few places to determine whether code is placed or not like this:

  if (properties.gotLoopProgram) {
	writeBlock(mFormat.format(97), pOutput.format(programId+1000), "l" + (properties.gotLoopNumber));
    writeBlock(gFormat.format(28));
	writeBlock(mFormat.format(30));
  }

still trying to determine an exact position for this one:

  if (properties.gotLoopProgram) {
	writeBlock("O" + (programId + 1000));
    }

this replaced the existing M30 code:

  if (properties.gotLoopProgram) {
    writeln("");
    writeBlock(mFormat.format(99));
    writeln("%");
    } else {
	  writeln("");
      writeBlock(mFormat.format(30));
      writeln("%");}
}

This is generating what looks like usable code, not positive if the subprogram call will work or not as it's a little different than what I was doing previously (calling n# from p# using the line codes from the HSM editor.)

[mfeathers]

Just tried running the loop and get an invalid P code error.

[Greg_Haisley]

What exactly are you trying to do?

We run our lathes with a Main program that basically calls a sub-program (which is the part cutting program) repeats a specific number of times which equals to this: (48 inch long bar - 2.0 chucking slug) / (part length + .15) = number of main cycle repeat. The .150 comes from using a .125 wide cutoff blade and allowing .0125 face stock on each end of the part or .025 face stock on the front side of the part.

At the end of the parts to be ran has been reached, the main calls up a part locator move.
The chuck stops, chuck opens, operator removes the last chucking slug. cycle start, chuck closes,
turret does tool change to puller station, moves to new bar position, chuck opens.
Operator loads new bar from the back of the machine and pushes the bar until it touches the cutoff blade.
Operator clamps the chuck while holding the bar against the cutoff blade. (on some machines the spindle liners will want to pull the bar away from the cutoff blade.)
Cycle start starts the program all over again for another 20 parts.

We let the parts drop into the chip conveyor and separate them from the chips as both drop into a cart. Chips go into a chip bin and parts go into another cart. Basically unattended CNC turning.

Only on catch with this: if you use the sub-program loop counter it will reset to zero with a control reset.
To get around this a macro counter needs to be implemented. Something like this:

O1000
#501=20(PARTS TO BE RAN)
#502=#502+1 (counter)
IF#502GT#501GOTO99
(MACHINING PROGRAM)



N99#502=0
M99

Good Luck

[mfeathers]

Greg,

I appreciate the attention. Your process sounds remarkably like ours. I have a working program loop (and bar pull) that I currently manually add to every program I post. My program inside the loop is the entire part machining followed by bar pull.

I started by wanting to add the bar puller to the post processor, which is more or less done. I then got ambitious and wanted to try adding a program loop that I could enable or disable. Mostly working... I can remove the loop with a simple click in the post properties dialogue.

Here is my example code that I add manually for the loop:

N110 (Loop Begin)
N112 M97 P120 L2 (Loops from P-L times)

N114 (Run after all loops complete)
N116 G28
N118 M30

N120 (Start of looped code)
N122 G53 G0 X0.

//some program code//

N844 M99 (Loop return and count)

and this is the similar code being generated from the post:

M97 P2030 L4
G28
M30
G53 G0 Y0.
G53 X0.
G53 Z0.
O2030

//some program code//

M99

This code does not run, I get an invalid p code error. For the post processor I opted to use the O number for the program loop instead of N because I wanted to define a number I could go to consistently, the N numbers appear to be added in HSM edit after post. It almost looks like the O number is supposed to be a separate program file located on the Lathe.

As far as the rest of your program routine... my coworker was just asking me about adding a process for adding new stock, very similar to what you are doing. He also made mention of macros.

[mfeathers]

so, I figured out my pcode error. I removed the automatic numbering from HSM edit and have the post processor spit out an N number instead of an O number.

It looks like we don't have macros available (at least according to the instructions here: http://diy.haascnc.com/presentations/use-macro-variables-make-parts-counter )

Looks like tomorrow, I'll take a stab at the material change code. I can use your outline above as a reference. Again, I appreciate the feedback Greg. 🙂

[Greg_Haisley]

No problem.

Just passing along solutions that work for my shop. Bar pulling should be a standard strategy for turning, with integrated cut off blade bar puller combination (1 tool station) or cut off blade in one tool turret position and bar pull in another tool turret position.

It blows me away that there are still a lot of CNC machine shops that still do not do bar pulling.

Making CNC machines almost run by them selves is the key to being very competitive now a days.

[SouthernCrossSmallArms]

Hi,

My thoughts exactly about integrated tool bar pulling.

What is your solution for the CAM to get this job done, automation of relative dimensions if possible?

Setting up an older C axis lathe, and really want to get the CAM streamlined. 

---

@Camtool-Ind wrote:
No problem.

Just passing along solutions that work for my shop. Bar pulling should be a standard strategy for turning, with integrated cut off blade bar puller combination (1 tool station) or cut off blade in one tool turret position and bar pull in another tool turret position.

It blows me away that there are still a lot of CNC machine shops that still do not do bar pulling.

Making CNC machines almost run by them selves is the key to being very competitive now a days.

---