PDA

View Full Version : Too Many Gosubs...



nat_wheatley
01-21-2012, 07:08 AM
I created the program below to drill pull holes, and pilot holes, in the backside of drawer fronts. Program works fine, but after every 3 or 4 fronts I get an error message to the effect of 'Too many Gosubs...' I believe I get the message right after I've answerered the 3 questions at the beginning of the file. Anyone know how I can restructure things to avoid this? Thanks.


'Drill Drawer Front - Pull

C#,90

&Border=4.675 'X and Y Fence Offset

'Table Fences Extended?
Pause

Gosub Get_Data

GOSUB Drill_Holes

End

Get_Data:

Input "Pull Width (mm)" &CC
Input "Drawer Front Width (Inches)" &DFW
Input "Drawer Front Height (Inches)" &DFH
Gosub Drill_Holes

Drill_Holes:

JZ,76

'Drill Hole A - Right Pilot
J2,&DFW*25.4 - 54.13+&Border+&my_XmmDrilloffset_T32, &DFH*25.4-77+&Border+&my_YmmDrilloffset_T32
JZ,26+&my_ZmmDrilloffset_T32
SO,8,1
Pause .5
SO,6,1
MZ, 17+&my_ZmmDrilloffset_T32
SO,6,0
JZ, 25+&my_ZmmDrilloffset_T32

'Drill Hole B - Right Pull Hole
J2,((&DFW*25.4-&CC)/2)+&CC+&Border+&my_XmmDrilloffset_T32, (&DFH*25.4)/2 +&Border+&my_YmmDrilloffset_T32
SO,6,1
MZ, 3+&my_ZmmDrilloffset_T32
JZ, 25+&my_ZmmDrilloffset_T32
SO,6,0

'Drill Hole C - Left Pull Hole
J2,((&DFW*25.4-&CC)/2)+&Border+&my_XmmDrilloffset_T32, (&DFH*25.4)/2+&Border +&my_YmmDrilloffset_T32
SO,6,1
MZ, 3+&my_ZmmDrilloffset_T32
JZ, 25+&my_ZmmDrilloffset_T32
SO,6,0

'Drill Hole D - Bottom Reference
J2,(&DFW*25.4)/2+&Border+&my_XmmDrilloffset_T32,&DFH*25.4-20+&Border+&my_YmmDrilloffset_T3
SO,6,1
MZ, 17+&my_ZmmDrilloffset_T32
SO,6,0
JZ, 25+&my_ZmmDrilloffset_T32

'Drill Hole A - Left Pilot
J2,54.13+&Border+&my_XmmDrilloffset_T32, &DFH*25.4-77 +&Border+&my_YmmDrilloffset_T32
SO,6,1
MZ, 17+&my_ZmmDrilloffset_T32
SO,6,0
JZ, 25+&my_ZmmDrilloffset_T32
SO,8,0
JY,304

Gosub Message

Return

Message:

MSGBOX ( Same size or different?, YesNoCancel, Next Front)
IF &MSGANSWER = Yes then GOSUB Drill_Holes
IF &MSGANSWER = No then GOSUB Get_Data
CN,99
End

dana_swift
01-21-2012, 08:54 AM
Nat- among other problems- when you get to:

Input "Pull Width (mm)" &CC
Input "Drawer Front Width (Inches)" &DFW
Input "Drawer Front Height (Inches)" &DFH
Gosub Drill_Holes

Note the last gosub Drill_Holes calls the immediately following code as a subroutine, which will execute, then return to the line following the Gosub above. Notice is is the Drill_Holes: label.. so it will be executed twice.

Then it gets to the RETURN and has not been called from a gosub statement. Woops.. thats a no-no.

There may be other problems as well.. but be sure to fix that one! Its a sure killer.

D

cip
01-21-2012, 09:36 AM
Nat: my best advice, for what it's worth, is to get rid of all the gosub, return and end commands except the very last end command and change the msgbox to:

MSGBOX ( Same size or different?, YesNoCancel, Next Front)
IF &MSGANSWER = Yes then GOTO Drill_Holes
IF &MSGANSWER = No then GOTO Get_Data

As long as the other command structure is correct this should solve the problem.

nat_wheatley
01-21-2012, 10:51 AM
Thanks guys, very helpful. as usual. I'll work on trimming it down. Programming is clearly not my strong suit, but I typically am able to muddle through it to get it to at least function...

Thanks again.

chiloquinruss
01-21-2012, 11:18 AM
Nat I get very confused doing subroutines. What I found that helped me when doing them is I print out my code, then I get a couple of colored pencils and outline the subroutine(s), 1 routine - 1 color. If I made a mistake in my coding I notice it right away when I try to color in the offending subroutine in the next color! Just a thought. Russ

nat_wheatley
01-21-2012, 11:43 AM
Great idea Russ. Even on this program, as short as is, was confusing me when I looked back at it.

dana_swift
01-21-2012, 01:25 PM
Russ the colored pencil technique once was a standard in the programming world. There once was a method of reducing variables named "allocation by coloring" named for discovering the range of use of a part of the program.

The only problem with subroutines in SBP files is the process of calling and returning is very SLOW. Worse, if you ever call a subroutine in the middle of cutting code expect very jerky motion.

D

chiloquinruss
01-21-2012, 07:20 PM
But Dana I'm really old too! :) That's how I know, cause I was Air Force trained to be a programmer 1964 and we used a lot of pencils! :) Ahh the good ol' days of flowcharting! :) Russ

khaos
02-06-2012, 03:44 PM
Russ the colored pencil technique once was a standard in the programming world. There once was a method of reducing variables named "allocation by coloring" named for discovering the range of use of a part of the program.

The only problem with subroutines in SBP files is the process of calling and returning is very SLOW. Worse, if you ever call a subroutine in the middle of cutting code expect very jerky motion.

D

Ahh, old skuul sequential .. It's a whole new world now.

e.g. SharePoint object model with entity framework for MS SQL interaction.

chiloquinruss
02-06-2012, 11:24 PM
"It's a whole new world now." Yeah I know, but after 20 years of writing operating systems you would think that MicroSlop could do something other than create the worlds fastest blue crash screen! :eek:

I owned a software company for several years and we did a lot of work for HP on their large format raster plotters and thier fastest machines all used inline coding, no looping routines. Ram is much cheaper than processing power so it was easier to add multiple copies of a routine rather than loop through the same routine over and over. I know its counter to the norm but in the raster plotters the little processor is still so much faster than the mechanics of the print head (or gcode router) movements that the machines just ended up being much more glitch free. In those days the biggest problem was in the cableing not in the code (pre-usb).

Anyhow Its still fun to bring back the 'old' methods for a review now and then! :) :) Russ

khaos
02-07-2012, 10:42 PM
"It's a whole new world now." Yeah I know, but after 20 years of writing operating systems you would think that MicroSlop could do something other than create the worlds fastest blue crash screen! :eek: ...

You could always switch to the dark side and code for Crapple. I have seen the iOS pain and it looks like this: