Installing a pause in G code?

[Max Girouard]

I've been running some large 3D files that I generate with Rhinocam. When I start up the file, the router moves to the X and Y location, plunges the bit into the material and then freezes while the status bar loads up the rest of the program which can take up to 10 seconds. I've noticed burn spots on my work piece as a result. Anyone know how to install a pause for any given amount of seconds to allow the program to fully load before it plunges the bit? Thanks!

[bleeth]

Well: In SB code you would do PAUSE 10 for a 10 second pause.
For a delay or dwell in G-Code use code G4.
eg. to insert a delay of 5 sec use the line:

G4 P5

I thought Rhino outputs SB code?

Disclaimer-I don't know g-code. The reply came from a quick google search leading to Mach discussion on Artsoft forum
.

[Max Girouard]

Rhino does output a sbp file that is generated by the post processor. Looking at it, it does look like shopbot code and not G code, so I'll give the pause a shot in the morning. Thanks for the input. I'm going to have to start learning to read and edit code as I have a few other ideas and things I'd like to try.

[srwtlc]

You've got it right Dave.

Max, that's how it works with large 3d files. I'm not sure that a pause will help as nothing will load during the pause. Normally, with a 3D finish pass, the amount of material left to take off after doing a rough pass should only be around 0.040" which shouldn't overheat the tip of the cutter before the data is loaded. If your file is very large, you'll find that it will do that somewhere further along also.

I don't know why it's like that and also wish it would load before it gets to that point. I haven't taken the time to play with editing the beginning of a 3D file to see if it can be forced to load at a different point. Possibly a M3 that keeps the Z axis higher at the same location of the first M3 that places the Z into the material. Not sure that it will though because files from Aspire already do that.

[myxpykalix]

I've done a fair amount of 3d files and what mine does is....you push start, the router moves to its first plunge point and pauses while it loads up more code but it never plunges into the material till it has loaded the code and is ready to start moving.
You might want to check and see if there is some kind of bottleneck in getting your code loaded faster?:confused:

Do you have any other program that will generate your 3d toolpath? If so try to generate the same toolpath with a different program and see if it is a rhino generated issue?

[adrianm]

According to the documentation the SB software will buffer data until the stack memory is full or it encounters a non Move/Cut type command.

You can insert SC,2 commands into the file to control the start/end of a stack segment and reduce the pause time.

The documentation does imply that the bit should retract to safe-z height when the stack is being loaded though. It does sound like that's not happening though.

[myxpykalix]

an issue that has plagued me, that i've never resolved (because i forget about it) is...
If I do a MH the carriage will return home at whatever height i have removed it to...no problem:)
BUT if i do a JH what happens is the bit moves from whatever position i have withdrawn it to and goes to Material Z Zero height then starts to go home...thats a problem:eek:

So i'm wondering when adrian says "that the bit should retract to safe-z height when the stack is being loaded" that maybe there is a corruption in those internal settings for that?:confused:

[srwtlc]

Adrian, I'm pretty sure it does retract when loading more later on, but it's that initial first load that it seems to start at the material. I was thinking about the movement block command (SC,2). Used to us it from time to time with the old DOS version.

Jack, what is your safe Z set at?

[myxpykalix]

I think i have it set at 1" for most all files, this way if i don't have something set right i have a few seconds to catch it.:eek:

[Max Girouard]

Ok, Scott you were right, the pause inserted did not allow the program to load up, it still dropped the bit into the material an then loaded the program. Next I'll try the SC2 command. Upon reading the programming hand book, this should do the trick in cutting the amount of time the bit is in the material not moving. I'll keep everyone posted once I try it.

[myxpykalix]

I would put a call in to Shopbot, those boys know what they're doing and should have the best answer instead of our guesses:confused:

[Max Girouard]

OK, I tried the SC,2 command. I put it a couple hundred lines of code out and that eliminated the pause in the beginning. But when it got to the SC,2 command it paused without raising the Z axis. Like Jack says, I'm going to have to give shopbot a call sometime next week to see if there is a way to work this out.