[warpedmephisto]

Hi all,

I mostly just lurk on the Zone, but I've come across a bit of an issue at school with our VMC 15 with 88HS control. Is there any way to control what Z height the tool returns to after a tool change? We ran some parts yesterday and found that after every tool change the tool went down to Z0 (surface of the part), moved X&Y to the next coordinate, retracted Z to the safe plan defined by the CAM program and then fed Z into the part. This leads to gouged top surfaces and could potentially break a tool.

Even when just punching in MDI line by line after a "M6T_H_" it will go up, do the change, then rapid back to Z0. Is there any way to change it to where it rapids down to a safe plane above Z0, or am I stuck with drawing and programming all my parts with the top surface at Z-1?

Also, is there any way to change the way it handles the tool change order of operations? For example, upon finishing up with one tool, it will retract to the safe plane, spindle off, rapid up to the carousel, change the tool, rapid back down and then turn on the spindle, when instead it'd be nice if immediately after the tool change the spindle turned on so that it could spin up to full speed by the time it gets back down to the part. Or should I just program in a pause for the spindle to get up to full speed before it starts cutting?

Oh, another thing we ran into was the baud rate when drip feeding it long programs. We currently have the machine and dripper program set at 9600 baud and when it gets to dumping a lot of code (think a bunch short line segments) sometimes it can't transfer fast enough, skips the block and will crash if you let it keep going. Would we have any trouble upping the baud rate (either from dropping or incorrectly receiving data packets) or are they reliable at over 9600?

Thanks in advance!

[Scanfab]

Keep the H compensation out of the tool change... Try this:

T1M6
G0G90G54X0Y0S3000M3
G43Z.5H1M8
G1Z0(OR DEEPER)F20
MACHINING PORTION
G0Z1M5
G0G91G28Z0
T2M6
G0G90G54X5Y0S15000M3
G43Z.5H2

ECT..
you wont have that problem anymore. Dont change the part z0 from top of part, u will go nuts trying always to compensate for that..

[carbidecraters]

Keep the H compensation out of the tool change... Try this:

T1M6
G0G90G54X0Y0S3000M3
G43Z.5H1M8
G1Z0(OR DEEPER)F20
MACHINING PORTION
G0Z1M5
G0G91G28Z0
T2M6
G0G90G54X5Y0S15000M3
G43Z.5H2

ECT..
you wont have that problem anymore. Dont change the part z0 from top of part, u will go nuts trying always to compensate for that..

Did you know that when you put in a m6t? It does the same as M5 M9 H0. We wriet using -4 88hs controls and our programs are as simple as

M6T1
M3S3200
G0X0Y0
Z.1H1M8
G1Z-1.F20.
G0Z.1
M5M9
Z0H0
M30

OR WITH TOOL CHANGE

M6T1
M3S3200
G0X0Y0
Z.1H1M8
G1Z-1.F20.
G0Z.1
M6T2
M3S3200
G0X0Y0
Z.1H1M8
G1Z-1.F20.
G0Z.1
M5M9
Z0H0
M30

All this considering you are using your default home or E0 (g54). The beauty of Format 2 is that it takes the excess code out of the program. We may be wrong but we have been programming like this for 15 years.

[Scanfab]

I keep the G43 Z.5 codes in there so that the programs will be ready to run on FANUC control machines without mods. I know its the long way, only want to teach the programming once to the guys..

[warpedmephisto]

How do you handle your H offsets then? Do you set your longest tool to have a 0 H offset and then set all the following offsets referenced to that?

I guess what I'm trying to figure out is immediately after the M6T1 line execution (without a H offset), where will the machine want to return to? If it returns to Z0 using the previous tool's H value, it could cause a crash if your current tool is longer (ie: has a smaller H value) than the previous tool.

I will try to run some of that code tomorrow and see if it makes sense at the machine.

[Scanfab]

The way we set our tools Z's is as follows:

Tool starts at MACHINE Z(tool change height) and you jog it down , say 8.1217 inches down to the desired z plane on your part. On the "quick keys" page, press 5-SET LENGHT. This will set the number of -8.1217 inches as your offset(offset being the distance between Machine zero and part zero for that tool.) Do that for all tools.

If you then decide the part(z plane) should be .0205" lower, go to offset page and press 3-mass modify and type the difference you want: -.0205 THEN ENTER. Presto, next part will be that much shorter.

If you work your offsets this way, it is easy to teach/learn that the numbers on the offset table(both tool lenght and G54 offset table) are all measurments from the machine zero to part zero(on all axis').

When you set the length off the part z, your G54 z value will be 0 then....

Happy tool length offsetting!!

[DareBee]

exactly

Z0 is always the CS/toolchange point.
EVERY tool gets an H offset from that point.

I DNC to my '94 at (is it) 38K. It also helped to buffer better after I upgraded the memory.
From the Fadal command prompt type "setP" and set the default baud rate to 38K.
Turn off the Fadal (main switch) and on again to ensure the baud rate is loaded.

Make sure your Com software is set correctly
Settings should be Format ASCII
Port Com 1 - this may change depending on the computer port
Baud rate 38K - same as you set in the machine
Parity Even
Data Bits 7
Stop Bits 1
Handshake XON/XOFF

[warpedmephisto]

Thanks for the tips, guys. I tried it out this afternoon and looks like the method above will work out quite nicely. Now I just have to go back and edit my post processor file to do tool changes properly - that and go through and offset my tools correctly.

Oh, another question, how can we tell if our machine is set up for rigid tapping?

[carbidecraters]

3 ways

1.In the monitor cabinet is a list of parameters and checkmarks check there first
2. In the back cabinet on the spindle drive (Baldor or Freqrol) there might be a sticker
3. Write this program and if it errors you do not have rigid tapping

M6T1
X0Y0
Z.1H1 (MAKE SURE YOUR ABOVE ANYTHING IN HEIGHT OFFSET #1)
G84.1G99Z-2.S600.F100.
G80
G0Z0H0
M30


That is how you rigid tap in Format 2. It is the fast code without all the extra G codes. If you are using a 1/2-13 tap your code could looke like this

G84.1G99Z-2.S130.F10.

[warpedmephisto]

Excellent, thanks. Our machine does indeed have rigid tapping capability.

Another issue has sprung up though. In a relatively lengthy program (800ish lines) it will get to say line 527 (or whatever, its random) and it will stop drip feeding (the lines will stop shuttling through on the Fadal's monitor) and the machine will get caught in a linear move to some random coordinate, plowing through whatever is in the way. We have our baud rate on the machine and DNC program set at 38400 and seems to flow through the code well (the program we're running has a bunch of short line segements) until it just stops and does the random linear move.

Any thoughts on what could be causing this?

[carbidecraters]

I woudl think your running past the control. Try a 4800 or 9600 baud rate and you should be golden.

[warpedmephisto]

It was encountering the same problem at 9600 yesterday afternoon and it seemed to be worse about not being able to keep up. Thats why I tried 38400, but it seems to be doing the same thing.

We have an 88HS control with no expanded memory - how many lines/sec can we expect from this machine?

The only things that pop into my mind are 1) there could be a noise problem or bad connection from the pc to the machine (we do have a lot of unnecessary length, plus parallel port to null modem to serial port adapters) or 2) the DNC program we are using is a homebrew program written in VB. Its simple, but does what we need it to do.

[DareBee]

The only time mine stops like that is when the next line of code has a mistake in it and can't be processed. Some of these mistakes are hard to figure because they may not look like mistakes (eg the R plane is higher than the clearance plane setting).

[warpedmephisto]

Thanks for the help. We discovered that the problem was in our homebrew DNC program. We have been able to load programs to memory and run them from there just fine. Only problem with that is that we're limited to about 600 lines of code at a time due to other programs currently in the memory.

When we don't have a 600 line program in there, its about 31% free in the memory, so if my math is right we should be able to fit just shy of 2000 lines of code in the controller if it was wiped clean. Does this sound about right? Is there any way to gain more memory to fit longer programs than that, or should we either stick to a DNC option to drip from a computer, or go with Calmotion's black box?

A bit OT, but from any of the users of Calmotion's device, how easy is it for a production run of parts? IE: Load blank, cycle start, machines part, unload part, load blank, cycle start, etc. Can you just do it like that, or do you have to re-load the program in after every cycle?

[calmotion_tech]

"A bit OT, but from any of the users of Calmotion's device, how easy is it for a production run of parts? IE: Load blank, cycle start, machines part, unload part, load blank, cycle start, etc. Can you just do it like that, or do you have to re-load the program in after every cycle? "

Latest version: At Enter Next Command prompt, type the DNC+ command to select the file from the USB key which will start DNC. When done, simply hit the green Start button to repeat the program over and over.