PDA

View Full Version : Problem with gouging the piece



tas99
04-15-2013, 10:08 PM
Does anyone have an idea what may be causing this problem?
I’m using Aspire to generate the tool pats to cut a piece using the indexer; something I’ve done a number of times before with other cutting files. The attached picture shows what happened right after the program started to run. The bit took a rapid Y and Z move down and into the piece while it began rotating –breaking the bit - then rapidly withdrew and cut ok until the end. Even though the bit was broken I let the program run to the end to see if there were any more unexpected movements.
I was able to isolate the problem line of code – see below – and when I commented it out the program ran just fine, start to finish. This was not a noise spike or an errant signal because I can duplicate the problem every time. The code sure looks ok to me and it’s followed by a move command to the same coordinates on the next line so I felt ok in not running the problem line of code.
I’ve attached the entire program if it might help but I have the section with the problem code below.
As a note, my indexer is on the “B” axis.
Any help would be appreciated.
Tom

'3D Roughing 1-4 EM
'File created: Monday, April 15, 2013 - 09:24 AM
'For ShopBot Control: SB3 Alpha from Vectric
'
'UNITS:Inches
'
'Set router RPM to 12000
PAUSE
'
'
'Turning router ON
SO,1,1
PAUSE,2
'
VD,,5
&Diameter=5.1780
&FeedRate=3.0
&RotationalFeedRate=&Feedrate/(&Diameter*3.14159/360)
MS,3.0,1.0
VS,,,,&RotationalFeedRate
JZ,4.0000
J5,,0.0000,,,0.0000
J5,,0.8124,2.7890,,360.0000 ******** BAD LINE OFCODE
M5,,0.8124,2.3890,,360.0000
M5,,0.8124,2.3890,,0.0000
M5,,0.9124,2.3890,,0.0000
M5,,0.9124,2.3890,,360.0000
M5,,1.0124,2.3890,,360.0000
M5,,1.0124,2.3890,,0.0000
M5,,1.1124,2.3890,,0.0000
M5,,1.1124,2.3890,,360.0000

dana_swift
04-16-2013, 12:14 PM
Relevant code:

JZ,4.0000
J5,,0.0000,,,0.0000
J5,,0.8124,2.7890,,360.0000 ******** BAD LINE OFCODE


The jog from 0Y,4Z,0B to .8124Y,2.789Z,360B is "supposed" to be a linear interpolation. That should NOT cut through the material, (presuming the material is at or below a radius of 2.798") yet it did. That would be a bug in the shopbot control program.

The line isnt "BAD" unless I am missing something.

Which version of SB3 are you using? If this reproduces.. send the code to tech support. Also figure to use a different version of the control program.. and PLEASE let us know which one this is, so WE can stop using it too.

D

bill.young
04-16-2013, 04:03 PM
This is a long shot, but in general do all other Jogs go the correct distance? Jogs are calculated differently than Moves, and if the multiplier value is wrong they can go an un-expected distance when you jog, but not when you move.

Maybe try making a couple of jogs and see if they move the correct distance...if not then you might have a bad multiplier setting

Bill

tas99
04-16-2013, 07:09 PM
I agree with you D, the line isn't really bad code; just a poor choice of words on my part. Call it the line of code in which the problem occurs.

Anyway, the line of code is supposed to move the bit to Y 0.8124 but the bit plunged into the work a much greater Y, about 3.0. It was also a faster than normal jog speed which was also strange.

That command is in the roughing pass but a similar command in the finishing pass causes no problems.

Regarding Bill's question. I measured a jog in both X and Y and they are right on. I didn't do a Z but I don't think it matters.

My work-around is still to comment-out that jog command and just leave it to the move command to get the bit there. My time isn't THAT valuable.

I'm running next to the latest version of SW on a PRT with the USB to serial interface.

steve_g
04-16-2013, 08:58 PM
"I didn't do a Z but I don't think it matters"


When I had multiplier issues they showed up on the Z axis only... you might double check this!
SG