Subscript out of range

[Ryan F Deming (Unregistered Guest)]

I keep geting a subscript out of range (9) error in a part file I am running (in v3.3.18 on winMe).

I have two variables (&temp1 and &temp2). If one of them is being used the program runs. If both of them are used I get the error. Also, to keep orginized, I have two files with variables that I run from within the part file. The same thing happens. If I run one or the other of them the program compleats. If I run both of them I get the error.

I have two questions. First, what dose the "Subscript out of range" error usualy mean? Second, my part file has quit a few veriables. Is there a limit to the number of user veriables allowed and could this be my problem?

If anyone has any ideas I'd appreciate it.

[Brady Watson]

Ryan,
Generally speaking "subscript out of range" refers to a variable that is not large enough to hold what you want to put into it. This can also happen if you are trying to assign text to an integer...

I forget the limit on user variables...but I can tell you it is a lot higher than 2!!!

-Brady

[Ryan F Deming (Unregistered Guest)]

I did some more playing arround and it looks like I have exceded the number of user variables allowed. 100 seems to be the limit.

Dose anyone know for sure what that limit is?

[Brady Watson]

Yikes! 100 variables!?

Why do you need that many? What are you trying to do?

I have found that sometimes it is easier to code outside of the SB file in something like VB...then just create a cutting file.

-Brady

[bill.young]

Ryan,

100 variables is the limit. Is there a way you can re-use variables in your file, or do you need more than 100 unique ones?

User variables are persistent in the ShopBot software so once they're loaded they stay in memory until the ShopBot software is shut down. You can clear them however with the SL command

Bill

[rannbite]

Thanks for the input. The file I am making is for morticing door jambs and has lots of variables but more then anything else I was using the variables simply to make the file more readable. For the program to work like I want it to I would need more then 100 unique varables but they are not absolutly neccesary. I should be able to work around the problem now that I know. It simply cought me off gard becose the errors were so eratic (depending on what other variables were all ready in the system.)

We will be using the file for a long time so I was hopeing to create something very simple to read and change. Many of the variables are not necisary, but help to orginize and simplify a fairly complex file. I have a file of variables that I run at the start that do nothing more then make the program readable such as using variables &clockwise and &counterClockwise in the CR comand rather then there corisponding numbers. It takes longer to type out, but is far easyer to read when you are reviewing or modifying the program at a latter date or when someone with less experence is looking over the program. I will simply have to be more frugal with my variables.

100 dose seam like a very artifisal limit. It may seam that 100 is overkill to many, but memory is plintiful these days so there should be almost no limit to the number of vereables you can have. I imagen that it is a holdover from dos days, but I hope they consiter uping that limit in future versions.

(p.s. There are also time I would kill for a "for" loop
)

[bill.young]

Hey Ryan,

There will be a new Setup virtual tool and Header Writer in the next version of the software that work the same way, writing custom settings as variables to a file that you can load and use at the beginning of any file.

The issue with the number of variables is not the amount of memory that they use but the time that it takes to read through them each time a variable is called...a concern when you're passing a lot of info. I'd be interested in hearing if anyone else is using a lot of variables in files...close to 100?

Bill

[rannbite]

I would also be interested in knowing if any one else is using close to 100 variables. What I found myself doing was trying to create a high level language out of the low level language of the shopbot part files. I was creating variables such as &true and &false to be used in the same way as a c++ program. These variables are clearly not necessary, but simply make the file easier to read through and easier to create. In my mind I thought I could create a file of variables that created a base language that I could reference in all my other files. I would simply create a template file that included a file of only variables and then I could reference these variables in any files created from the template. To me this is the way the programming ought to work ideally, but we are simply restricted by the ability of our machines. The info you gave me about why there is a limit to the number of variables is really very informative to me.

I am really interested in knowing if any one else would use that many variables. I think I could easily use 200 variables just in making my files easy to read and easy to modify. Of course I also tend to be a very abstract thinker, always thinking about how things ought to be written to facilitate future use. Most of what I do on the shopbot is not individual files but rather set processes that have a lot of variables. I create files that will be used over and over again but with a lot a variations in the details.

I am really interested in what others think of my approach. Please let me know what you think. Thanks.

[mrdovey]

Ryan...

I do a lot of my part programming in C - both to generate what I think of as "base" (or "invariant") SBP files; and to generate and execute SBP code in temporary files on the fly.

You might enjoy looking over this web page (http://www.iedu.com/DeSoto/sbim.html).

...Morris

[Brady Watson]

Ryan,
I get it now....it's easy to see how you could use 200 variables trying to extend the SB language's capabilities. This is why I code tricky things in VB. It's fast, I know it and can use it to generate both SBPs and RhinoScript for doing complex things. If you can crank stuff out in C, that would be the way I'd do it.

Morris...pretty cool!

-Brady

[bill.young]

Hey Ryan,

I missed the last part of your post. "for" loops are pretty close to the top of the list for new programming commands, but unfortunately new programming commands are not all the high on the software todo list. More programming capabilities will be added in the future, but just not sure when.

Bill

[ted]

Hi Ryan,

Yes ... just to reiterate Bill, we are working on new programming commands. And, just to reiterate Brady, it is also pretty convenient to run ShopBot from outside software. See the examples in the "Developer" folder under C:\Program Files\ShopBot. It is possible to pass ShopBot an external command and be in action in less than a second. It's not quite as nice as DLL access, but practically it works pretty well and makes ShopBop 'open' to access from virtually any software. Note that all the "Virtual Tools" in ShopBot (even though usually started by a ShopBot call) run from outside the software and pass a command line with a reference file.

On the number of variables, the Sb3.4.1 release that goes up today now allows 200. Because Part File programming is basically an interpreted language and the variables variant in type, it just get's too inefficient to process many more with current methods. If there is enough interest in crunching more of them, we may set variables up in a different fashion in the future.

-Ted