How does the table surfacing program work?

[tas99]

Can someone explain to me how the table surfacing code works. I can see how it cuts a rectangle but I can't see how it's made to step over and cut successive rectangles.

Tom S

[beacon14]

The CR command has a parameter for "pocketing" where it clears out the entire rectangle. Look on the fill-in sheet when you type the command CR

[tas99]

Thanks Dave. It was right there but I missed it.

[tas99]

Maybe not. I thought I understood it and I can see by the command description that you can enable a pocketing feature but in looking at the program itself it's not obvious. I can see the 8 parameters stated (some left to their default values) but I can't see how the pocketing feature is enabled.

Tom

[paco]

4144

Does that help?... or are you looking for the math behind the function?

[bill.young]

Hey Tom,

It's the last "2" (in the eighth parameter) in the command that turn pocketing on...

CR,96, 48, T, 1, 4,,,2

Bill

[tas99]

I appreciate the information but it doesn't answer my question. I've included a copy of the program code below and as you can see, the CR command carries only 8 parameters after it; the last being "Plunge from 0", I assume. How does it enable either of the 2 special functions, in this case pocketing?

Copy of code for surfacing my table:

INPUT "Is your bit in the correct starting position, the router on, and everything ready to start flattening? If so type (Y)." &ready
IF &ready <> Y then END
INPUT "Are you SURE? If so type (Y)." &sure
IF &sure <> Y then END
VC,1,,,,, 15
CR,48, 48, T, 1, 4,,,2
END

[tas99]

I got Bill's post after I sent my last one but it's still not clear. If the last "2" enables pocketing why doesn't the CR command interpret it as the eighth parameter, Plunge from 0? Isn't it in the eighth location in the set of parameters; even though "2" would be incorrect for that parameter?

[bcammack]

The way I read the Command Reference pdf, the "Plunge from 0" switch is the 9th argument in the parameter list, not the 8th.

1 = Length of X
2 = Length of Y
3 = [O]ut/[I]n/[T]rue
4 = Direction
5 = Start
6 = Plunge
7 = Repetitions
8 = 0-none/1-Tab/2-Pocket
9 = Offset plunge from Z axis 0

[bill.young]

Tom,

As you've found the fillin sheets are usually but not always laid out in the order of the parameters for commands. I've found that the Quick Command reference in the Help menu [HR] is the easiest way to check.

Bill

[tas99]

Bill,

I guess that answers that question and it makes sense but I find that kind of thing a little frustrating. How is one to know which piece of documentation is correct and why would the guys at SB not correct it?

Oh well, thanks anyway.

Tom

[richards]

Tom,
As Bill has pointed out, the Quick Command reference in the Help menu lists all parameters of every command. The pop-up fill-in-the-blank screens may only have fields for the most common parameters in that particular command.

You'll find the same practice used throughout the computer industry. In fact, in the UNIX/Linux world, there are 'man pages', shorthand for 'user's manual'. There the commands are terse and obtuse. The common saying is that if you think you understood the command after reading the man page only one time, you didn't read carefully enough.

The Shopbot software is great, both in its simplicity and on its complexity. No, that's not an oxymoron. As packaged in the User Interface portion of SB3, it is so simple to use. And for those of us who like to really get into the code, and like to either write our own or modify code generated by Partwizard or other tool-pathing software, there is enough detail/complexity to really turn the Shopbot into a high-end CNC machine. The beauty of the dual approach is that you don't have to have years of experience to get real usefulness out of a Shopbot; but, if you do have a solid programming background, the Shopbot software will NOT limit you.

[tas99]

Mike,

I’ll start by saying that I agree with you that the Shopbot software is great and go even further by saying that the product, organization and the people are just as great.

But, at the risk of sounding argumentative I have to take issue with your comment regarding what might be standard in the computer industry; maybe conflicting documentation is common; maybe it is, maybe it isn’t, I don’t have the perspective to say. But, I do know that the target market for Shopbots is not the computer industry. Its price point and user friendly interface point it to the smaller shops and even the upper-end hobbyist. I’d be surprised if the number of software savvy users numbers 10%.

As such, there is a reasonable expectation by that market segment that the documentation – be it pop-up menus or the reference manual – be accurate. I recently attended one of the Shopbot seminars in NC and they touted the fact that you didn’t really need bulky manuals because the drop-down menu gave you all the parameter information you need. In fact, I think it was Ted Hall that made that remark in his software presentation.

Don’t get me wrong, I’ve found the drop-down menus to be very helpful in the past and this is the first occurrence of an error that I’ve seen. Ted is right; they are a great addition and clearly meant to be useful to users who do not have an extensive software background.

Are you saying to disregard the drop-down menus and always refer to the reference manual? If so, then Shopbot would be better served by removing them and eliminating the confusion. I don’t think that’s their intention, nor should it be. In fact, I saw that one person who responded to my post included a copy of the drop-down menu in his response. He too thought it was correct information and I've seen a lot of his posts regarding coding issues so he's more likely software literate than I.

Having said all that, if you’re the Mike Richards who developed the “doors” program, it’s great and I use it all the time even though I haven't run across any conflicting documentation.

Tom

[bill.young]

Hey Tom,

The fillin sheets are really just aids to make it easier to enter commands from the keyboard and are not intended to be used as documentation...sorry for the confusion.

For instance, as Mike said there are some fillin sheets that don't have all the parameters available in a command because some of them only make sense when used within a part file rather than from the command line...the VB command for tabbing is one. And when new parameters are added to a command they have to be added to the end of the parameter list for backward compatability but might logically fit better with other parameters in the fillin sheet and could be shuffled around.

And occasionally they just get mixed up by accident...we'll check on this one and if there isn't a reason for them to be out of order we'll add it to the todo list.

The Command References in the Help menu are the real documentation for the commands and are the place to check for things like parameter order and descriptions of what each parameter does.

Hope this helps,
Bill

[richards]

Tom,
I think we're basically agreeing on everything, except that the Shopbot furnished file and the drop-down menu contradict each other. (And maybe I haven't read this thread properly to really understand the underlying problem.) But, I believe that the drop-down menus are really intended to be used stand-alone, that is, they work properly if they are used for that one instruction. (I really wish that I were at a Windows computer so that I could test what I'm saying, but this particular computer customer that I'm servicing at the moment is a Linux shop, so I can't run the SB3 program - so what I'm writing may be totally incorrect.) For instance, if you wanted to run the CR command and you wanted to fill in the blanks on the drop-down menu as an easy way to run that single command, the CR command would work properly because the drop-down menu program would make certain that all parameters were put in their proper order and in their proper position. However, if you wanted to incorporate the CR command into another file, you would have to use the command reference in the help file to get the proper parameters and proper sequence of those paramters.

In effect, in the first example, you would be functioning as a computer user who was using 'canned' software, but, in the second example, you would be functioning as a computer programmer.

Unless you're a programmer, you wouldn't understand how a programmer's mind works - or in my case, how a mind doesn't work. For instance, the the emergency job that I was called to fix today here at the computer customer's shop has taken hours to fix, but only a few minutes of hands-on programming. Most of the time that I've been here has been waiting-time where I've just waited for processes to complete before leaving. Since this customer is about 100 miles from my home, it's more time effective to just stay here until the process completes. That meant that I had a few extra hours on my hands, which also meant that I had time to re-learn how to solve the Rubik's Cube Puzzle (so that I could prove to my six-year-old grandson that even gray-haired grandpas could solve the cube). Anyway, the first two layers take just a few minutes to solve, but the bottom layer litterly took three hours to solve WITH the instruction right in front of me. The problem was that every time I tried to do the last step, which is to orient the bottom corners properly, I totally messed up the cube. Finally, after being totally frustrated, I read the line immediately following the rotate sequence instructions. It very plainly instructed me that the cube would be in a disordered state until I had run the same sequence of instructions on all unoriented corners. Surprise! It worked when I followed ALL of the instructions. The point being, that as a programmer, I expected to see a warning BEFORE the sequence was listed rather than AFTER the sequence was listed, because that is the proper way to do it and programmers aren't required to think; they just have to know how to follow simple instructions.

Another example: Last week this same customer changed his telephone service. He found out later that his credit card machines needed to be replaced. Because the new credit card machines used an IP address just like a computer, he called me to get the necessary IP numbers. One parameter kept messing him up. That was the sub-net mask. Since the credit card machines were on a little network with only eight IP addresses, the subnet mask had to be 255.255.255.248, which every network programmer knows by heart. It just didn't work. So, I told him that I'd be down as soon as possible (knowing full well that he hadn't followed my instructions). Well, when I walked in the door, the credit card machines were working perfectly. While I was traveling, my customer finally got in touch with the salesman who had sold him the credit card machines. The salesman had no idea why the subnet mask wouldn't work, so he just inserted the numbers that he normally used: 255.255.255.0, which is a mask that is used when there are 256 possible IP addresses. It worked! It also meant that the credit card programmer didn't have a clue about subnet masks, but, the more important point is that I would still be looking for the problem because using a forbidden number is not something that a programmer would ever do.

Well, that's enough rambling, but I think it points out that, to keep non-programmers from needing to know every little parameter in every instruction, friendly user interfaces were developed. And, sometimes those friendly user interfaces contradict the actual command, but they hide the complexity from the user.

(By the way, I am that Mike Richards, but the credit for making the doors program workable and useful should go to Bruce Clark. My part of the program is usable by programmers, but his part of the program made the doors program work for everyone. If you really want to see convoluted code with instructions that only a left-handed programmer could understand, take a look at the source code for the doors program. It's included with the FreeDoors.zip file.)

[bcammack]

Tom, I can only commisurate with you regarding discrepancies in the documentation. It took me a while to run the information to ground that I required and I'm a programmer with over 25 years of experience! I decided that I would take the approach that, if it was a common built-in function in mainstream BASIC, it was probably legal in the ShopBot programming language and that seemed to get me where I needed to go.

They do need to go back through the docs and get everything uninfied and up-to-date, IMO.