Why I think that 'Shopbot code' should be made Open Source.

[richards]

Bill,

Thanks. I was hoping that there was a 'secret' users manual that had the 'missing' commands ;>)

Lacking the control structures, I've had to resort to this type of sample C program:

/*
* test.cpp
*/
#include <stdio.h>
#include <stdlib.h>

int main(void)
{

[srwtlc]

A little bit of thread drift here, but what would be the chances of having a "List Box" (much like the Msgbox statement) where you could select something from the list and then have whatever is programmed for that selection be executed?

[bruce_clark]

Scott,

I am guessing here, but that would most likely require Brady's SELECT CASE conditional branching as well as some more window's type support.

Yes, you could do it with endless IF/THENs but that is not elegant nor does it make the code readable.

Now, I am going to step out and make everybody disagree with me, but really, how much MORE useful would adding all these commands be? Lets look at this from a Time/benefit standpoint.

Say, conservatively, it takes you 5 minutes to load up Parts Wizard (or VCarve for you fans
and draw 4 boxes (like Mike's above) and post that file and load it with the ShopBot controller.

How long will it take you to do the same thing in Notepad or the ShopBot editor? If you type fast, maybe you can do it in five minutes as well--maybe.

So, we are close, but I am guessing that the Parts Wizard user would beat out the hand created coder--probably by a decent margin.

Ok, so here is where the difference lies. Now, say you need to either offset that box, because low and behold, you do not have the right size cutter you wanted or say you need to add radiused corners. Now, lets look at the time difference.

PW (or VCP
2 minutes more of editing and reposting the file. You also have the added benefit of WYSIWYG. You know the points and circles will line up.

Ok, I would be willing to bet that the hand typist with the latest Machine's Handbook and a trig calculator would be lucky to do it in 20 minutes!

My point, where is the savings in doing hand coding of programs? The only situation I can honestly think of (and I am sure I am being short sighted) is with the support of additional hardware, such as the Z-Zero routine.

Now, Mike has brought up the idea that you need a smarter uController than what the ShopBot has to do things like tool changers and whatnot. I disagree. Yes, you probably need more uControllers, but not on the ShopBot side. Who says that they cannot talk to the ShopBot controller via input/output pins. Think how some of the older CNC Iron (and even some modern ones) work. They use PLCs and ladder logic to control those specialized functions. There is no reason why your separate uControllers could not talk to the ShopBot controller with input and output pins. Heck, you could even matrix the 4 inputs and 4 outputs for 16 different "features"!

Anyways, just my thinking out loud...

Bruce

[rhfurniture]

Bruce, I don't think any of us want to use the programming ability of shopbot to handcode parts. I use it to develop little "utilities" for performing specific woodworking operations, like dovetailing, morticing, tennoning etc, and for using the horizontal router bolted on the back of my Z, I use my own routines exclusively - I would get into dreadful XYZ muddles otherwise. For such things better, customisable, input windows would be really great. I do some scripting with Autocad, and the DCL (dialog control language) that that uses would be seriously useful in this situation.

[richards]

Bruce,
If we leave the exotic alone for a minute (but just for a minute), the conditional statements, if they were built into the language would let us cut jewelry boxes with scooped out or dished out compartments. We could cut ramped splines. In short, we could get full use of the ramping ability of the CA and CR commands.

PartWizard does a great job of generating 2D tool paths, but having conditional statements would let us program in simple 3D moves - and it would turn a $15 jewelry box into a $75 jewelry box.

In short, if conditional commands were part of the language, and if users of those commands started sharing ideas, it wouldn't take very long until some incredibly 'wonderful' designs started appearing.

Okay, the minute is up. Lets talk about the exotic just a bit. A controller board with four inputs and four outputs can interface easily to the outside world, but at the cost of two output lines and two input lines. Using the old, tried and proven bit-banger method, one line becomes a data line and another line becomes a clock line. (I'm making the assumption that using one data line and 9-bit serial protocol would not work due to variations in pulse timing.) Then a protocol could be set up so that, for instance, a string of bits would be sent to all the external devices with a series of 'wake-up bits' then an address bit of a particular device and finally the command bits for that device. That type of communication has worked for years, but it is so old fashioned. Using TCP/IP (networking) we would only have to open a socket to a device to establish a communication channel and then send commands back and forth between the devices - at 10mb per second. (100mb Z-World Rabbit core modules are also available at very low prices - but just how much data do simple I/O controllers need to send?)

Most of us have forgotten what personal computing was like in the early 1980's. If we wanted to share information between computers, we copied the information onto a floppy disk, walked over to the other computer and retrieved the information. Some of us were lucky enough to have an external Hayes modem that ran at 300bps. The Internet (DARPA) was a closely guarded secret that only a few select universities had access to (one of which was the University of Utah here in Salt Lake City).

Today, most of us have Internet access with DSL or cable connections. When we travel, we take our laptop computers with us and only stay at Hotels and Motels that have wireless networking.

Well, all of that is currently available on the factory floor. Windows XP is a multi-tasking operating system. If micro-controllers were used to handle time critical functions (like stepper pulse streams), all the master computer would have to do is issue a command such as "move the X-axis 3912 steps clockwise" and the micro-controller would handle that, including ramping, without tying up the master computer. In fact, with that same $400 G100 micro-controller, we could send a command such as:

- Move the X-axis 3912 steps CW
- Move the Y-axis 843 steps CCW
- Move the Z-axis 1997 steps CW
- Move the A-axis 440 steps CCW
- Move the B-axis 2746 steps CW
- Move the C-axis 691 steps CW
- Coordinate all moves so that all speeds are proportional to the distance traveled.

That command is available today with the G100, and it takes no overhead from the master computer to run that command.

If we start thinking one task = one computer instead of all tasks = one computer, the possibilities are endless. Long ago we gave up the idea that the CEO of a company should also be the only employee of that company. It's time to hire a few helper computers so that the master computer can start to manage the tasks and let the 'associate' computers do the actual work. We really need to stop thinking like we did in 1980.

[weslambe]

Maybe this is what you wanted?
20909.jpg

Note the Spock controller box!

Maybe a real replicator would have been a better purchase. Just tell it what you want and voila! There it is.

[henrik_o]

I knew I shouldn't have dipped into this. It is way too much fun.

I spent a couple of hours this morning looking at the language specs and doing some light coding (if you can really call it that) to see if I could get the hang of it. It's been some years since I was doing this, so it's kinda horrible, but I did manage to get something out of it (and boy, was it fun!)

Here's a screenshot of a simple graphics interpretator that accepts sbp input and produces a representation on the screen. I completely forgot that the y axis goes in different direction between the two, hence the mirrored look. As you can see, I didn't bother discerning between Jog and Move commands, but it would be very easy doing the jogs in blue and moves in red. Then I added a little function to scale down that image using bolder lines, I suppose it could be used for batch processing a directory of sbp files assigning each with a custom icon based on the contents.

Amazing how fast time flies, but I also managed to get in way over my head doing some more fancy stuff.

And that was those two hours, mighty fun.

The code came down to about thirty lines total, if anyone wants to see it (more like laugh at it) here it is;
Window1.doMainArray:
Sub doMainArray(f as folderItem)
Dim f As FolderItem
Dim textInput as TextInputStream
Dim line as string
Dim i, scale as integer

scale=10
f=GetOpenFolderItem("application/text")

If f<>Nil then
textinput=f.openastextFile

Do
line=textinput.readline
for i=1 to 2
mainarray.append Val(NthField(line,",",i))& #42;scale
Next
Loop until textinput.EOF

textinput.close
staticText1.text="Imported file: "+f.name

else
msgBox "Failed to import file"
end if

End Sub

Window1.PushButton2.Action:
Sub Action()
Canvas1.Graphics.ForeColor=RGB(255,0,0)
Canvas1.Graphics.Drawpolygon mainArray
End Sub

Window1.PushButton3.Action:
Sub Action()
dim f as folderitem
doMainArray(f)
End Sub

Window1.PushButton4.Action:
Sub Action()
Canvas1.graphics.clearRect 0,0,canvas1.width,canvas1.height
End Sub

Window1.PushButton1.Action:
Sub Action()

icon=NewPicture(canvas1.Graphics.Width,canvas1 .Graphics.Height,Screen(0).Depth)
icon.graphics.ForeColor=RGB(255,0,0)
icon.graphics.penwidth=3
icon.graphics.drawpolygon mainArray
canvas2.graphics.drawpicture icon,0,0,100,90,0,50,300,400

End Sub

Is it functional? No, certainly not. It would need a lot of polishing up and added features to do something actually useful. But that's not really the point: it was done in a couple of hours by a lousy coder (more like scripter) who haven't scripted in five years, and it was fun fun fun.

Ok. I know this doesn't belong here, I just had to share, I'll be quiet now and think a bit more about the issues actually pertinent to the thread.

[richards]

Henrik,
Your program is a perfect example of what opening things up can do. It's kind of like kindergarten where we all learned to get along and share - except now most of us have years of experience doing specialized things - and most of us know how to get along and most of us want to share our experience and point of view with others.

Your program shows what would happen if we contributed something instead of waiting for Shopbot to do everything for us. (Can you imagine a family of 3,000 or 5,000 individuals all waiting for one person (Ted) to feed and clothe us every day? We should all be willing to give him a break and a helping hand from time to time.)

[weslambe]

I am an advocate of the KISS principle. Keep It Simple, Stupid as a business model that should be followed.

I’d hate to have to see what would happen to Shopbot if it were opened up to thousands of well meaning people with their own agendas. There are a couple of terms that are useful in knowing when thinking about improving something and they are:
Instruction Creep and Featuritis or Creeping Featurism. I got these from wikipedia.

Instruction creep occurs when instructions increase in size over time until they are unmanageable. It is an insidious disease, originating from ignorance of the the KISS Principle and resulting in overly complex procedures that are often misunderstood, followed with great irritation or ignored.
Instruction creep is common in complex organizations where rules and guidelines are created by changing groups of people over extended periods of time. When rules and guidelines are not explicit, ever-increasing bureaucracy (even for seemingly useful reasons) tends to achieve the same result.
Instruction creep begins when someone thinks "This page would be better if everyone was supposed to do this" and adds more requirements.
Procedures are popular to suggest but not so popular to follow, due to the effort to find, read, learn and actually follow the complex procedures.

Featuritis, creeping featurism, or the spoonerism feeping creaturism is a term used to describe software which over-emphasizes new features to the detriment of other design goals, such as simplicity, compactness, stability, or bug reduction.
Featuritis is often accompanied by the mistaken belief that "one small feature" will add zero incremental cost to a project, where cost can be money, time, effort, or energy. A related term, feature creep or scope creep, describes the tendency for a software project's completion to be delayed by the temptation to keep adding new features, without a specific goal.
Featuritis is usually associated with marketing, sales, or program management roles. However, developers are not immune to letting features creep in to a software product; many people criticize Emacs as being a prime example of creeping featurism. Emacs proponents, however, tout Emacs' all-in-one nature as one of its primary benefits. Multi-paradigm languages such as C++ have also faced such criticism.
Featuritis and the associated scope creep can endanger and even kill entire projects. Apple Computer's Copland software is an example of this, as feature creep continuously delayed the project.
Quotes:
The cheapest, fastest, and most reliable components are those that aren't there." — Gordon Bell
"There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." — C. A. R. Hoare
"Make everything as simple as possible, but not simpler." — Albert Einstien
"In Jeet Kune Do, one does not accumulate but eliminate. It is not daily increase but daily decrease. The height of cultivation always runs to simplicity." — Bruce Lee

This is an example of software that was cobbled together in an open source environment. I believe that it’s called open office writer.
20917.jpg



Open office writer with all toolbars activated exhibits the creeping featurism necessary to meet the modern expectations of word processors.


One day when I have employees, I don’t want to have to hire engineers or computer programmers to run my cnc machine. I want them to be able to walk up to the machine and press the start button. If I have to train someone to do otherwise, then they will invariably demand more money and that doesn’t fit my agenda. If, in the future, I find that I need more features than Shopbot is offering at that time, I will simply move on. Until then I will use my machine to make money cutting wood and not as a testbed for other people’s whims, dalliances or products.

The ability to create many, many different products can be had right now with your shopbot if you are only willing to step up and spend the money for programs that work. I did just that. Enroute is a great cam package. It costs a ton and it’s worth every penny. RouterCAD, Autocabinets, MDFDoorCAD,CoutertopCAD and Dovetail DrawerCAD are all worth the money spent on them. True, together they cost almost as much as the PRS but I’m not complaining about the way Shopbot handles the files that are created.

[richards]

Wes,
You've made a good point about featuritus. Few of us use most of the features available on this forum. You posted an image that required a feature that very few posters have found useful. To you it is valuable. To others it's a waste of valuable resources.

Let's look at a fundamental command that we all use in every program: MX, <distance>. A CNC router that can't command the X-axis to move is not much of a machine, is it? However, look closely at that command. It has a big flaw doesn't it? A flaw that if we didn't have 'helper' software to compensate for, would drive us nuts. A flaw so huge that if we didn't have someone else's add-on software would require us to spend double or triple or even more time to manually fix on our own. That flaw, of course, is that command, on its own, does NOT compensate for the radius of the cutter.

Does it bother you that most of the commands that make up our SBP files have that same flaw? It's not Ted's fault. He has included PartWizard as part of the package deal that most of us received when we bought our machines; however, he did NOT write PartWizard. It is an add-on program written by someone who had a desire to make the world a little bit easier on the CNC router users. Thank goodness for that person or persons because I would really hate to draw everything twice, once to exact size and once with all of the lines offset the radius of the cutter that I planned to use.

Some might said, "Mike, you're really being stupid right now." Maybe they're right, but tool pathing is not a built in feature of SB3. I think that we would all say that a tool path program is a necessity. Some may say that it takes away from the purity of the original software. It all depends on whether it helps YOU solve a problem. If it helps YOU, then it is a necessity. If you don't need it, then it is just part of creeping featuritus.

You personally wrote a program that required the use of three cutters, if full advantage of the program was to be realized. It was and is an excellent program. BUT, I'll bet that every single user of your program wished silently or vocally that his machine had a tool changer. It can really get frustrating to spend more time changing cutters than we spend cutting wood. Few can afford $18,000 or $25,000 for a tool changer, but some can and some would buy it if it were available.