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

[jeffreymcgrew]

Hey all, been thinking a lot about this lately. One factor I see that comes up in discussions about Shopbots vs. other CNC machines is that Shopbot uses 'propitiatory' job code.

I know, I know, one can use G-code instead, and the code itself is full specified in the binder and plain text so it's not like it's closed off in any way. But still, for some folks, this seems to be some kind of an issue.

Also pair this with along with (what I feel is) Shopbot's mission to make entry-level accessible but robust CNC tools for the masses (and hence why they decided to use their own code that's less confusion and easier to use than G-code) then why not make that code Open Source?

Open Source is where you release the specifications and usage of a bit of software or format under a license that allows others to freely use it under certain terms.

Some licenses are totally Open, in that one can do whatever they want with the code, and others are more limited, requiring anyone to makes additions to give those additions back to the creator of the original thing, or requiring those who use the code to site that they are doing so publicly.

This is why, for example, Microsoft Windows XP and prior site in the Copyright information that they use some code from the University of Berkeley, for some of the networking code came from BSD, a form of Unix made by that University and released under such an Open Source license.

What releasing the Shopbot Code format under an Open Source license would do is let anyone add to their software the ability to generate Shopbot-ready code. It would make the complaints about 'propitiatory' code go away (or at least become moot) and would encourage folks to make more stuff that works with our wonderful machines.

Also it could be a big marketing thing, for it would go along with the 'open' spirit of Shopbot and it's encouragement for us to 'hack' our own machines, and get a lot of good press.

Now, I'm just saying that the FILE FORMAT for jobs is what could become Open Source. The controller software and hardware controller themselves would remain Shopbot's.

I'm thinking it would be like the PDF file format; it's actually open for anyone to use, but Adobe holds the copyright, and makes money by providing really good tools for creating and managing PDFs.

So, am I crazy? What do y'all think?

[paco]

Hey Jeffrey!

You'd like SB3 source code or SBP file code?

You already have "all" you need to code whatever you want with SBP code... but to get the controller source code, you need to ask SB.


Got you CD?!

[richards]

Jeffery,

Other than letting interested parties see how an instruction translates a command into an axis movement, what do you see as the advantage of opening the code? Would it be to extend the instruction set? Would it be to fix internal bugs?

The problem that I see, is that someone would have to manage new additions to the code. A large CNC router that suddenly goes 'wacky' could cause a lot of damage, including personal injury. To say the least, it would be an interesting job to validate and approve code changes.

Although I write all my code under the OpenSource license, which means that anyone who receives a program from me also receives the source code, I'm having a problem seeing how OSI would be managed when it comes to Shopbot code. It almost seems that there would have to be a trusted group of programmers in place whose job would be to review and test all additions or modifications who then would send their recommendations on to Shopbot for final approval - after all, in a legal sense, it would seem that Shopbot would still have their head on the chopping block if a liability issue ever arose.

[jeffreymcgrew]

I'm just thinking it would be the SBP file format. And mostly it's just a gesture, I guess, for it's already all documented and free to use. This would just make it perfectly legal for someone to, say, make a plugin for something like Blender to produce Shopbot SBP files.

One big stumbling block I see with this whole entry-level CNC is that a lot of the CAM software (in my opinion) is old, crusty, very expensive, and requires dongles and such. Now I know folks like the Vectric guys are working to change some of that situation, and I think that rocks (I love Cut3d!), but I'd like to see anything that makes CAM software more accessible, both in terms of use and cost, to more small folks like me. CNC rocks and I'd like to see more of it used by small time folks!

Mike: yeah, it's complex. I don't know how it would work, it's just an idea.

Paco: yeah, they are sending me a CD, and I got a workaround going until them by making a Parallels image from an old machine and moving that onto the machine instead. Gosh those folks on the Artcam forums are crazy...

[paco]

Correct me if I'm wrong but anyone can output SBP files from what ever software, scripts and canned cycle without consent of SB. I believe it's already happening as I write this!

Please, do correct me if I'm wrong.

[ted]

Hi Jeffrey,

As I understand what you are suggesting, I think we are pretty close to where you want to be. Maybe I'm not quite clear ...?

Anyway, the specificiations for ShopBot code are fully available and public. We encourage companies that write CAD/CAM software to create posts using ShopBot code and provide them with help if they need any. As far as I know, most CAM programs in which anyone has expressed an interest have created ShopBot posts. And all the major CAM programs in which ShopBotters are interested, do post to ShopBot.

Some people have used the word "proprietary" for our code. But this tends to be something that competitors throw up when talking about us. There is an interest in making our code sound somehow strange. The code is not magic in any way ... its just that 12 years ago when we started to develop ShopBot software, we wanted to use code that was easier to read than the arcane G-code which was developed to be effecient for punched paper tape machines, not human eyes, and has long outlived it usefullness. In addition, we knew we wanted the code to have more programming features than the relatively awkward functionality of G and M commands. We didn't see anything wrong with starting with a different system. There are actually many variations of G-code and many machines or controllers use their own language. I think the first step to make something really "Open" is to make it something everyone can read and work with.

So we simply gave our code a straightforward and easy to read format, and as time has gone by, we've increasingly implemented more and more BASIC-Language-type features in it to add further flexibility (e.g. we recently added Windows Message Boxes). The code also implements all ShopBot commands in a very simple two-letter method that is easy to explain to beginners.

The code has a lot of capabilities. People may not have noticed, but many of the routine functions that are done on a ShopBot, such as zeroing and probing, are actually programmed in ShopBot Part File code and run as part files. They are not routines hidden inside the Control Software. You can modify these routines, or write your own. (Or you can add further functionality by programming features such as Virtual Tools, which are all done with combinations of an outside program such as VB or C, and ShopBot part file code.)

Now I wouldn't suggest that Part Files are the be-all and end-all of CNC programming, but most of the CAM companies that have added ShopBot posts have indicated to us that it was very straightforward to do it, and that they like our coding format (and that they are happy to have more ShopBot customers). Recently, the Mach CNC program started reading and executing ShopBot code, so the usability of the code is also spreading to other processors. It is the case, afterall, that whether its ShopBot or G-code, the file is essentially just a list of position vectors or arcs through which you want your tool to move.

Where this is not a typical "Open" project is in the sense that we don't have any kind of group that gets together to decide what direction the code should be altered in, or to plan how to make it more generally useful. We certainly aren't opposed to doing something like this. It just hasn't come up. At the more industrial level, there are initiatives underway to create more capable alternatives to G-code as well as easier ways to get from a 3D model to cutting. We look forward to such developments. But for the moment, we'll continue to emphasize .sbp code format.

For those who are die-hard G-coders, it might be worth noting that with the 3.5.x version of our software, G-code files can now be read directly, and G-code and ShopBot code can be intermingled in files. This make it possible to take an old G-code part and do some more flexible programming around it with ShopBot code. As in the past, the software will convert G-code to ShopBot, or ShopBot to G-code. Our idea is to keep it all as open and flexible as possible.

Ted Hall, ShopBot

[jeffreymcgrew]

Ted, thanks for the reply!

As you say, yes, you are very close to what I'm talking about. What I'm saying is to just do one more step, and 'release' the SBP code under something like the LGPL or other Open Source license. This is where you retain control of it's copyright, but where others can freely and legally modify it on their own, and if they distreibute those changes they have ot give them back to you.

Yeah, it's mostly a formality, but seeing that you're already there, it's one that would make Shopbot look really good in the eyes of some, and make a big difference between you guys and the other CNC guys.

But then again this is just a lark of mine, and you might have very good reasons you don't want to do this.

And I actually really dig the SBP format, and have modified my zero routines and such. I haven't gotten too complex with having one routine call another and such, for most of what we do is custom and not production, but I really appreciate the accessibility and 'hackability' of the SBP format...

[rob_bell]

I appreciate that Jeffery has brought this up. I'm still a newbie to CNC ( ie < 1 year ) but not so to programming nor programming for robotics systems. It's never occured to me that there might be a difference between writing my own SBP code by hand and writing software that writes my SBP code for me. In case you didn't know, programmers are some of the laziest creatures on earth.

From the start the SBP format appealed to me. I may be mistaken the biggest difference between G-Code and SBP isn't the readability, although that's nice, but it is the fact that SBP allow programmatic flow control: variables, loops, conditionals. This allows SB Partfile to be more than simply a flat data file of position vectors and arcs and that's big step in the right direction. I do know that when I convert my SBP files which contain control flow statements to G-Code that information is lost and the resultant G-Code is incomplete.

After reviewing Page 25 of the Shopbot Part File Programming Handbook, Development Principles I think Jeffrey and Ted are very much on the same page.

SBP isn't a file format it is a CNC scripting language.

[bruce_clark]

Jeffery,

I am no expert, but I think they might run into a problem with the word "ShopBot". Ted has said many times that they have had to protect their trademark from other internet "shopping" sites and internet price "searching" tools.

If I made a brand X machine but said it ran ShopBot code, I would be creating confusion in the market that I was selling a ShopBot machine. That would hurt the ShopBot company (we don't want that, we want ShopBot to be successful so they keep updating their controller/hardware) financially. So, if ShopBot WAS to release their controller language, it would have to be called something else and then nobody would use it because they would think it is an another controller language, causing even MORE confusion than there already is.

I think that ShopBot has done a great job of making their controller language accessable for people who want to use it--I am living proof--and ShopBot has not asked for a penny from me for doing so.

I sleep better knowing that there are not 50 different "versions" or dialects of ShopBot controller language. You start running into the same problems that G-Code has. Yes, G-Code is the standard, but what is a standard if nobody follow it?

By giving up control of the ShopBot language, you are really creating confusion and support issues, not more acceptance.

Just my $.02

Bruce

[richards]

This is a great discussion, even though it's not really about OpenSourceSoftware.

As many of you know, I'm deeply involved in testing Gecko products, mostly because I came from a process control world and stepper motors/stepper drivers are a big part of that world. Just today, I downloaded some software from another vendor that finally - after too much delay - (and every day is valuable to us old-timers) released some software that made the G100/Grex pulse generator usable. I spent a few hours playing with it, knowing that finally, I would have few or no restrictions placed on what I wanted to do caused by the limitations of what the equipment could do. BUT, that version of software uses G-code. I need to turn on outputs to control devices - not just the router/spindle, but any device that I want to control. I need to check status from inputs - not just limit switches, but any device that I care to monitor. Maybe G-code does that, but I don't know how to make it all work. What I really need is user friendly Shopbot software that uses a sophisticated pulse generator - like the Gecko G100. That pulse generator is incredible, but it requires incredible software to make it work well.

Think what you could do if you could sample sixteen digital inputs and then cause your cut file to do something based on the status of any one of those sixteen inputs. Think of the things that you could control if you had sixteen digital outputs. Think of how robust your machine would be if you could have both the X-axis and the Y-axis running slave motors to double the torque of each axis. Think what you could do if you had four channel analog to digital inputs and four channel digital to analog outputs at your fingertips to control spindle speeds and handheld positioning devices. Think what you could do if all your pulse generators-I/O controllers were on a Class C subnet with 254 individual devices controllable from one computer. IF you had that kind of power, what would you do? Would you add a tool changer? Would you add a sophisticated vacuum system? Would you add material handling? Believe me, the possibilities are endless. CNC routing as we know it would be obsolete. Low cost machines doing a multitude of different functions would replace the pedantic machines that we now use. BUT it requires vision. It requires desire. It requires communication, not just between machines, but between people.

There is a new world out there that is much different from the world that we all live in now. It's a world where everything is possible when thinking people think together.

Shopbot has made great strides in making CNC routing understandable for all of us 'unwashed' common people. Maybe now would be a good time to enhance things using off-the-shelf electronics so that we can continue to complete with third-world countries.

I'm not advocating opening up the software so that anyone could create a 'NEW' set of instructions for Shopbot, but I am advocating the use of electronics that are available now at low cost that will completely change the way that CNC routing will be done - as soon as someone has the vision and the courage to use it properly.

The great strides that Ted has made to simplify the programming part of CNC coupled with Jeffery's desire to open things up (in a limited way - if I can add my thoughts at this point), and then couple that to Rob's comment about 'programmatic flow control' to make the code do more than just 'go here, then there, then somewhere else', and then make everything accessible as Bruce points out while keeping control so that there is no confusion about what is going on, and then finally, making it all usable so that Paco and me and everybody else can use it, with the advantage of using the best electronics available right now, would totally change the CNC market as it now exists.

As far as I'm concerned, the day when a shop should spend $100,000 or $500,000 to buy a CNC router is long over. Why not use ten $10,000 CNC routers efficiently to outperform ten $100,000 routers? The mechanics are available. The electronics are available. The software can be modified to make it all work. All that is lacking is the will to do it.

-Mike

[weslambe]

Bruce really says clearly what I was getting at in my "If I was Ted Hall" thread.

Some things are worth holding a little closer to the vest.

Open source may be a wonderful thing to some but it is a huge bane to others. True, lots of innovation comes from improving on someone else's original ideas but without the original innovator, where would these "improvers" be?

The Shelby Cobra is a good example of someone improving on a product, but without the originator, Henry Ford, would Mr. Shelby have made souped-up buggies?

That said, Shopbot's got a good thing going that is getting better all of the time and doesn't need to be diluted with spurious thoughts and ideas from every quarter.

Call me a Ludite, but sometimes more isn't always better. Sometimes more is just more.


Time to stop posting so that the professionals have more room to do so. Back to lurking.

p.s. Dirk Dunham. I got your email and read it then my spam software bounced it without me getting your email address. Thanks for the kind words.

[richards]

Wes, your comment about the Shelby Cobra is very pertinent to this thread. Henry Ford once stated, "You can paint it any color, so long as it's black".

If he had his way, we would still be driving black Model-Ts, because he knew how to make them and he was making money making them. (My dad owned a 25 year old Model-T that he was very fond of, mostly because he bought it for $10 in 1940.) If Shopbot wants to make black Model-Ts, that's up to them, but most of us won't be buying black Model-Ts when we see the offerings from other companies.

Case in point, you posted this on another part of the forum:

PRT96 2003
Other brand 2006
Other brand 2007
PRS96 2007

It looks to me like you needed something with "more" features than the PRT96 that you bought in 2003. The PRS96 that you've ordered this year has a lot "more" built in compared to the PRT96 of 2003. Would you be just as satisfied to buy another PRT96 or would you really prefer "more"?

I like "more" when it adds value and capability and efficiency to a product - especially when adding that "more" comes at less than $400 per machine. After all, if you put in a Gecko G100 you don't need to put in the old controller card nor the old computer board, so, in reality, there is probably less than $100 difference in price between a controller that works and a controller that WORKS.

EDITED: During the last year another company lured away several 'botters by offering a new controller with "more" features. Some of those 'botters were the very cream of the crop, with skills and abilities that most of us will only hope to obtain. The 4g upgrade came about during the middle of that episode. Was it in response to competition or was in innovation? Or was it a little of each? I didn't ask. You can bet that now that the Gecko G100 actually works - and works extremely well - that someone someplace is going to incorporate it into something that entices away other 'botters. The market is already small enough. Why not take advantage of - good - new technology and build upon it?

[weslambe]

According to the Model T club of America, it was produced from 1909-14 in green, blue, red and grey. From 1915 through 1926 the demand had increased so much that producing more than one color, black, was impractical. Over 15 million model t's were produced.

What drove Ford's production? Sales. What drove sales? A good product for the money. While other cars cost as much as 2000.00 a model t cost 850.00

Shopbot has a good product for the money and they sell a lot of machines for that reason.

I didn't sell my prt96 because I wanted more features, just more speed. When you say "would you be just as satisfied bot buy another PRT96 or would you really prefer "more"" I have to say I want all that Shopbot has to offer.

My last machine from NOSUCHCOMPANY (cant say) had all of the latest and greatest bells and whistles. Linear bearings, ball screws, tool measurement switches, 5hp colombo etc... It was a piece of poop. Not all that is "good" new technology actually ends up being good on your cnc machine. Been there, done that.

What do you mean when you say something about "a controller that works and a controller that WORKS?" Are you implying that the new PRS Alpha controller doesn't work well?

I chose to buy another Shopbot, a PRS Alpha because it's not a machine hacked together by some groupthink committee. I like the idea that I can go to one source for answers (shopbot) instead of trying to track down answers from some techno-nerd, pseudo-manufacturer wannabe in Timbuktu.

Quite simply, the market drives innovation and improvements to any product to a great degree. Shopbot has changed several times and has created a product that is far, far superior to many others for the money.

I don't have my new machine yet. I may or may not make changes to it depending on how it behaves. From what I have heard, I won't need to put my THK linear guides and bearings on this machine.

[Brady Watson]

Mike et al,
There's lots of great electronic hardware now available and even on the horizon. The problem is testing each device to determine if it meets the needs of the job at hand and if it is 100% predictable and 100% reliable. Sure, the G100 is one heck of a nice device...but little is available in terms of it's robestness and if it does what it is supposed to do under normal operating conditions. Gecko puts out some great products and I for one have over a dozen of their drives in service. There were some odditites with the G212 & G901 pulse multipliers, as you recall, weren't caught right away. Developers worth their salt need to test, test some more, and then do it again. It's great that some of these devices are now available, but whether or not it is the right fit on a Bot is hard to say. Personally, I'm all for a G100 on a PRS. I'm sure it would be the wheel. If I had the time...I'd try one out myself!

Now getting back to the topic at hand...I personally would like to see more BASIC commands in the software, particularly more conditional statements and BASIC style format. I'd like to see IF, ELSEIF, ELSE, END IF, DO WHILE, WEND, SELECT CASE etc. This would really give SBPL a shot in the arm since MOST of the programming that guys like us want to do relies heavily on conditional statements.

-B

[richards]

Brady,
You've hit on the main difference between G-code and Shopbot code. Shopbot has excellent conditional testing (that would be greatly improved by incorporating your suggestions). Think what you could do if you could test any of sixteen different inputs and then do a CASE statement to branch to the desired routine!

Now, to the G100. Anybody, and I really mean anybody, can hit ten websites and have all the parts required to build a top-notch controller that could be assembled by a high-school student. Everything is off-the-shelf. No specialty boards are required. It's just a matter of using some DIN terminal blocks to do some point-to-point wiring to build a box that will stun the CNC router world.

Since you already have a good investment in the G20x products, pick up the telephone and order a G100 tomorrow. If you don't like it, give me a call and I'll take it off your hands.

Wes,
Good luck with your Model-T. I have a neighbor down the street, Ron Thorne, who has the largest collection of Ford Vehicles in North America. He loves the Model-T, but he doesn't drive it to work. Come on out, I'll arrange a private tour for you. It's not often that you'll get to see more than 120 vintage Ford cars in better-than-new condition. Ron, his wife, my wife and I regularly go to the movies together and talk about his cars. He really loves those cars, but he'll be the first to admit that they don't hold a candle to the cars you can buy today. He has the same philosophy about building houses (which is what he does to make the money to buy those cars). The methods and materials used to build a house today are far superior to the methods and materials used to build a house yesterday. He must be right because he makes more money in a day than I make in a year - and he does it honestly without forgetting his past customers and his commitment to them. In fact, he's mentioned several times that no matter how bad business got, he never failed to keep his commitments. Maybe that's why he is so successful - he builds a good product at a good price, is totally honorable and honest in his dealings, and doesn't let the grass grow under his feet when new ideas, products and methods come along.

[Brady Watson]

Mike,
Ordering a G100 is on the 'to do list' for when I get back from California...I've got some servo drives to order up too


I am quickly approaching more robots than I can manage by myself! It's a bit like herding cats some days (or at least my brain is trying to remember what each are supposed to be doing!)

-B

[richards]

Brady,
It's great to live at a time when the question is, "Which product do I buy or use to do this job?", rather than, "How could anyone expect me to do this job with my limited equipment?"

This entire thread has been invigorating - thanks Jeffery for getting us started. Great posts were written by good people with good ideas who are NOT afraid of looking a little past today to dream a little of what tomorrow might be like if we just stop thinking about how afraid we are of change. No one has to make all of the changes today, but the constant movement forward by a lot of forward thinking people keep us all in business. Just think where we would all be if Ted decided that his first machine was perfect and that he would never have to design another machine. We would still have a very good machine, but think what we would be missing!

Edited:
Wes, my comment about a machine that works vs a machine that WORKS means that my Alpha and the 4g's that I've seen work and work very well. They do their job day in and day out without complaint. BUT watching a G100 control a CNC router is an eye-popping experience. Have you ever seen a stepper spin at 6,500 RPM? Can you add slave motors to both the X-axis and the Y-axis (and the Z-axis if you want)? Can you drive six different axes as easily as you can drive the standard X, Y and Z axis on our Shopbots? Can you drive pop-up pins to help you position your material, and vacuum valves to control eight different zones, and a dust collector and a chiller and a spindle and a tool changer with your current controller? Can you adjust the speed of your spindle on the fly so that it doesn't burn cutters up as the machines slows down for a corner? If you've answered 'no' to any of those questions, buy a G100 and do it. You'll never be satisfied with 'good enough' again.

As far as implying that such a machine could only be built by a bunch of idiots, is that what you think of Ted and all of the achievements that he's offered all of us over the years. That man is a genius. If he builds it, it will work. Your experiences with other companies show that Shopbot is different. Ted can be trusted to build good, no not good, but great machines. He's not afraid of pushing the envelope.

[weslambe]

Mike,

You've gotta be kidding right? I said no such thing about thing about Ted Hall and his company. In fact, I said exactly the opposite and was saying that I would not buy a machine cobbled together from the likes of you.

Re-read what I wrote above: "I chose to buy another Shopbot, a PRS Alpha because it's not a machine hacked together by some groupthink committee. I like the idea that I can go to one source for answers (shopbot) instead of trying to track down answers from some techno-nerd, pseudo-manufacturer wannabe in Timbuktu." Or Utah for that matter.

You are the one talking about how much better OTHER manufacturers stuff is, not me. So ease up on trying to put words in my mouth. I just spent umpteen thousand dollars on a PRS Alpha and can say that I'm happy to have done so. You are the one who seems to be constantly looking for the bigger and better deal.

If you think Ted "builds good, no not good, but great machines" then why are you seeking to improve them? Are they just not as great as you could do?

Re-read what you wrote above: "Wes, good luck with your Model T." I don't own a Model T so you must be implying that my new PRS Alpha is lacking in some way.

You also say the G100 is a better controller and that it's so easy that any "highschooler" could build one. Again, what are you implying about Shopbot?

I have found what I want and need for my business in Shopbot's machine and don't need to be constantly seeking the bigger and better deal.

[richards]

Wes,
I'm sorry if I've offended you in some way. Let me clarify:

Shopbot markets an excellent machine. You know that from personal experience and so do I. BUT, they mostly buy the components which they package together to turn lots of disparate parts into a Shopbot. They do NOT make the stepper motors; those are purchased from Oriental Motors. They do NOT make the stepper drivers; those are purchased either from Oriental Motors for the Alpha models or from Gecko for the 4g models. They do NOT extrude the aluminum; they buy that from Bosch. They do NOT make the V-rollers and V-rails; those are purchased from B/W. In fact, as far as I'm able to determine, on my Alpha only the controller board was exclusively designed for the Shopbot. Everything else could be considered to be 'commercial, off the shelf" parts that requires minimal attention before becoming part of a Shopbot. That's exactly what we would expect them to do. It wouldn't make economical sense to do it any other way.

They DO write their own software. That part of the Shopbot is both excellent and unique. It is the very heart of what makes a Shopbot a Shopbot. Without that software, they would be just another company fighting for a niche in the G-code market. I think that we both agree on that.

Now lets talk about that 'high school' student that I mentioned above. If Shopbot did NOT need to design and install a custom controller board, then the entire control box could be assembled by a 'high school' student. That means that the 'talent' required to 'construct' a controller box would mainly consist of being able to read a wiring chart and to mark off each connection as it was wired. There is no mystery nor magic involved. In fact there's not even rocket science involved. Just good, honest, easy-to-understand wiring.

The value of the machine is not in the wiring. The value of the machine is not in the stepper motors or the V-rollers and rails. The value of the machine is not in the aluminum or steel. The value of the machine is derived from Ted's ability to combine all of those parts into a single unit, that when acted upon by his software, becomes a living machine. The very heart and soul of the machine is the software - and the software is something that you can't purchase off the shelf.

Now, if I could offer a piece of friendly advice, let me suggest that if you find that your blood pressure shoots up a few points every time you read one of my posts, then don't read them. I'm not in the business to offend you or anybody else, but I really have no control of how you 'feel' about what I write. The Shopbot forum community is a friendly place to visit with lots of helpful friendly folks dropping in to visit from time to time. Because of the nature of my work (designing, building, programming and maintaining process, control computers for the professional photo lab market), I often find myself sitting in the computer room of a customer with an extra hour on my hands as a computer test runs in the background. That gives me the time to read forum messages and to respond to those that interest me. In fact, right now, I'm doing that very thing. Here in Utah it's about 6:15 a.m. I was called out at 3:00 a.m. this morning to drive fifty miles to this particular customer's site to recover data from a computer crash. So I sit here remotely connected to my home/office via VPN and do what I enjoy most - visit with friends and neighbors on the Forum.

Let's bury our differences and concentrate on enhancing and supporting the Shopbot community.

-Mike

[bcammack]

Open Source means that ShopBot Tools would make publicly available for enhancement and modification, at no charge, the source code for the SB3.EXE program which interprets the SBP code files and sends the appropriate machine commands to the CNC machine control box.

Frankly, I don't see any need for that. The functionality of the SBP code is completely documented. If you want to write a post-processor for your CAM software to drive the ShopBot it is all there for you right now. If you want to create your own control software for another CNC device that will execute an SBP file, it's all documented for you now so you may do so.

From my perspective as a programmer of thirty years, I see no reason for ShopBot Tools to give up their intellectual property and the development investment it represents by open sourcing their SB3 software. It would be pointless and represent no upside for their company either financially or from a market share perspective.

Does someone want to improve or enhance the control software for the ShopBot CNC machine? Is that the purpose of the question?

Perhaps we are simply dealing with a semantic issue regarding the definition of "Open Source Software".

The SBP file is a simple text file, editable with Notepad if you wish. The machine control source specification is proprietary, but it is already an "open specification". There isn't anything right now that would prevent a techincally proficient individual from creating a post processor or alternative control software for either the ShopBot or another CNC machine.

[richards]

I agree with everything that Brett posted. For those who haven't read the OpenSource Software License, here's an excerpt:

Open Software License v. 2.1
This Open Software License (the "License") applies to any original work of authorship (the "Original Work") whose owner (the "Licensor") has placed the following notice immediately following the copyright notice for the Original Work:

Licensed under the Open Software License version 2.1

1) Grant of Copyright License. Licensor hereby grants You a world-wide, royalty-free, non-exclusive, perpetual, sublicenseable license to do the following:

* to reproduce the Original Work in copies;
* to prepare derivative works ("Derivative Works") based upon the Original Work;
* to distribute copies of the Original Work and Derivative Works to the public, with the proviso that copies of Original Work or Derivative Works that You distribute shall be licensed under the Open Software License;
* to perform the Original Work publicly; and
* to display the Original Work publicly.

The actual license has fifteen sections that give more detailed information about the part that I've posted here. The part that makes most companies reluctant to use OpenSource Software is the proviso that once a work has been released using the OpenSource Software License, all derivative work are automatically licensed under the same terms.

Many companies want to have 'open' software so that their customer base can get as much use from that software as possible, but the companies still want to retain ownership and control of the software. They get around the problem by using 'hooks' or 'interfaces' that allow outside users to hook into or interface into the core software. In my mind, that is exactly what Ted has done. In this case the 'hook' or 'interface' is the code that we all see in an SBP file. It is human-readable, meaning that it is not the binary 1's and 0's that are actually executed when we run and EXE file. For instance, when we type "MX, 1.0", we're really using an external command to tell the proprietary software that we want to move the X-axis a certain distance or to an absolute location, depending on whether the machine is running is absolute mode or relative mode. We do not have to understand how the Shopbot software translates the command.

It's a good method that bridges the gap between giving away secrets that are the life-blood of a company and making the company's product usable to anyone who has an interest in the company's product.

[jeffreymcgrew]

Brett: While you're right that currently anyone can write a parser for Shopbot code, it's fully documented and openly posted, I'm musing more about the legal issues of the thing. For example, I'd love it if someone made something that run within the open source 3D software Blender that could produce SBP files. It may be totally possible, easy even, for one to write such a plug-in. But would it be legal to distribute it with or without Blender when there isn't a parent company behind it to license (even for free) the SBP format from Shopbot. So we're actually on the same page here, you and I, in that it's an Open Specification, and it's really just about the semantics and such.

Mike: That's just one of many open source licenses. The term 'Open Source' is a little muddled. There are some licenses out there that don't have the clause that makes all subsequent work have ot be released under the same license. For example, the BSD license only states that one must site that they are using the code they took from an BSD-licensed software. This computer I'm typing this on right now, that runs OS X, uses a ton of such code, and Apple didn't have to 'give back' or 'give away' any of it's modifications there. There is also things like the LGPL, where as I understand it if you make changes, and then release those changes (i.e. sell or give it away) then you've got to post those changes back to the owners of the software (in this case Shopbot) who can also, if they want to, tell you to stop distribution of it.

I guess what I'm getting at here is that I didn't buy the Shopbot because of the SBP file format. An now that I've got one, I've got a binder that totally explains how the SBP file format works. It's an open spec. So why not make it Open Source? I'd still have to buy a controller and controller software from Shopbot (I'm only saying that the SBP file format/scripting language would be Open Source here) if I want to run SBP code. Shopbot would still 'own' the SBP format if they use the right open license.

But again, it's just a big idea, and could be a bad one.

[gene]

If this info is made OPEN wouldn`t this make it easier for some chineese company to do a knock off of the bots?

[paco]

Since SBP file format (SB machine code) is available to use and to be create by "anybody" with any software, couldn't it possible then that someone come up with his own SBP file reader/machine controller.

I mean if I can create a *.doc (Microsoft Word format) file with Open Office and read it, wouldn't the same could be true for *.SBP format?

I wouldn't be surprised if some other CNC controller would read *.SBP file some day (didn't I read that above?)... would that be correct, fair yet legal?

[bill.young]

I think that Jeffrey is suggesting that ShopBot formally give "permission" for others to generate and use ShopBot code with a license of some kind. So that projects that are licensed under one of the various Open Source licenses ( like Blender ) would know where they stand legally and be more comfortable including a sbp generator.

[jeffreymcgrew]

Bill: thanks for saying it in so few words. Certainly a good trait I lack at times. ;-)

This is pretty much it. I'm just wondering what would happen if Shopbot gave 'formal' permission, via a limited open source license, to have others use SBP code in their software and products.

As for someone to have the ability to create 'cheap knock-offs' well, they can do that now. I'm not saying to open source the controller software, hardware designs, or anything else that makes a Shopbot a Shopbot. Just saying the SBP file format itself is what I'm thinking about here.

[richards]

Jeffery,
You've made some excellent points, especially the point: "The term 'Open Source' is a little muddled." It is muddled. There are a ton of lawsuits in progress right now against companies that have violated the OpenSource License (at least as seen from the eyes of those who brought suit). One example is LinkSys. Although I don't know whether suit has been brought against LinkSys or whether there is only talk about bringing suit against them, they used a Linux based controller in their routers and switches and 'allegedly' used OpenSource Software to operate that controller. Some users of LinkSys products thought that by doing that, that LinkSys was in Violation of the License. They wanted LinkSys to show the world the code and LinkSys refused, using the argument that they had paid programmers to write the code; therefore the code was their property. To me, it doesn't make any difference, but to others it's worse than a discussion on politics or religion.

Personally, I like the Open Specification idea. Since files using the SBP specification could only be run on Shopbots (or machines that incorporated a Shopbot controller), it would be an advantage to Shopbot to have a lot of external companies write software that produced SBP files. Maybe I'm naive, but I don't see the necessity of obtaining a license from Shopbot to write a text file that consists of command statements that the Shopbot software can read.

Perhaps it would be a good idea for Ted to give permission, in the form of a letter written on Shopbot letterhead, to any company or individual who asked for that permission. Again, I don't see that that would be necessary, since by NOT requiring individuals or companies to do that very thing, Shopbot has set precedence that extends backwards quite a number of years.

There's another point that I would like to make about software that contains both proprietary and OpenSource Software. Bruce Clark and I are in that exact situation with our FreeDoors/Doors program. All of Bruce's software is proprietary. All of my work is OpenSource. We get around the problem by passing data back and forth between the programs via a CSV file (spreadsheet). What many FreeDoors users might not realize is that when they enter data for doors into FreeDoors, Bruce's program works with that input data and writes it to a spreadsheet file. (I'm not trying to minimize the complexity of Bruce's program nor the extent of the tools and enhancements that he has written. I'm just trying to explain how software from two different worlds can work together.) Then, when the user clicks the button to generate the SBP files, FreeDoors invokes my doors.exe program. The doors.exe program reads the spreadsheet and then computes the axis movements required to generate an SBP file. The black box approach is an approved and effective method to keep software that is proprietary closed and to keep OSI software open.

Edited:
Boy you guys are fast, I've been sitting here thinking and typing for about 1/2-hour and missed Paco's and Bill's and Jeffery's posts.

[bill.young]

Hey Jeffrey,

I have to use few words...I'm the world's worse typist!

Let's make time to talk this over during the Jamboree...do you know of a link to a good "Reader's Digest" synopsis of the various licenses so I can do my homework?

Bill

[jeffreymcgrew]

Bill: Yeah, let's talk at the Jam about it!

Mike: you're close on the Linksys thing, but there is one more fact about it that's important. Linksys used open source code that was released under a license called the GPL. That license is just one of many Open Source licenses. It states that anyone who makes changes and/or additions to that code (in this case to make it work within their products) and then sells or gives it away, has to then also make the source code of those changes available when asked. This is so that if I spend my own time making something, and then release it via the GPL, if a company (such as Linksys) comes along and uses my code in their product, but makes changes and additions, that I get those changes too. It's a 'share and share alike' license. Problem is that Linksys didn't want to share in this case, even though they were legally required too due to the GPL specifically.

There are many Open Source licenses that don't require this forced sharing. It's just that most if not all of the Linux stuff is under the GPL, so Linksys got themselves into trouble.

There are Open Source licecnes that allow for non-commerical use, for example, or that allow for one to make changes and use other's code and only have to site that they are doing so. For example, Apple doesn't have to give back all their code to the BSD folks just because they used some of their code in OS X. neither does Microsoft, who used BSD code in Windows in the past. So there are many different types of Open Source licenses, and one could probably be found that could fit this situation.

[bcammack]

Since nobody signed an NDA when they purchased their ShopBot and the ShopBot programming language is fully documented and human-readable in it's natural state, there is no legal basis by which someone can be prevented from creating their own interpreter for the language or post processor that generates code in it provided none of the ShopBot intellectual property (SB3.EXE, primarily) is decompiled, disassembled, or otherwise reverse-engineered directly.

I suspect that you could legally analyze the datastream between the PC and the ShopBot to deduce how to control the CNC itself as long as you didn't disassemble or decompile any of the software or ROM on the controller board itself. I doubt if it's encrypted, but if it was you'd run afoul of the DMCA trying to decrypt it. (you're not reading this, right, ShopBot?
)

You folks are confusing a language specification with a program. They are two entirely different things. ShopBot can legally claim that they have a copyright on that language specification, but that basically says that they own it, so nobody else can claim that they do. It doesn't mean that they can utilize that to prevent you from applying that specification as you see fit.

I don't really see where ShopBot would be harmed by another manufacturer or individual investing the effort to apply this specification to create another controller or post-processor with it.

Firstly, someone making a Chinese knockoff would probably conclude it was more saleable as a G-code machine than to replicate a proprietary language system.

Secondly, more post processors means more avenues for people to buy a Shopbot and use it to their satisfaction.

Lastly, some sort of uber-controller software would not threaten ShopBot, either. They still sell more iron and somebody else gets the software tech support calls.

[henrik_o]

Great discussion.

I haven't looked much at the developer's documentation since I haven't had my Alpha delivered yet, and the dev stuff is something I'd rather get into after I learn the basics, but I think Brady W's points about additonal functionality are well considered and perhaps more to the point than the exact licensing regiment desired – I think great things can be done with what is there today (as the work of several of the participants in this discussion is testament to), and with just some added functionality even better things could be developed by the community.

Again, I've only glanced through the documentation, but Brady's points about better control flow are important. I’d also like to add improved support for (actually meaningful) i/o streams. There are some aspects of that, but they seem severly limited. You can call an app, but can’t programmatically pass data to it, and you can’t accept data back. You can write to a file, and you can play a sound, but again, the interfacing is limited.

(Now, I fully understand that accepting inputstreams would open up a can of worms in terms of safety issues, so a security layer of some form protecting the core parameters that goes to machining would be a must.)

With improved i/o, it would afaict be possible to develop monitoring apps with greatly expanded capabilities. This goes from the very simple such as the ‘play sound’ example that’s already there (but with far more control and options, such as sending a text message/email to a remote computer/cellphone) all the way up to user-customized touchpad operator i/o, automatic control of the vacuum system and perhaps even real-time monitoring which could be the basis for developing a system to accurately predict time-to-cut, etc.

Ok, I’m just thinking out loud here, but the point is that if the scripting/coding environment was enhanced there would be a whole new field of options for cunning coders to sink their teeth into. All of that could be open source, or commercial development for the aftermarket, whatever, it isn’t that important in my book.

I think Shopbot Inc should continue to do what they’re doing – control the core code and software. Let’s face it, if you or I unleash a pox upon our computers with some open source buggy project, we’re at most a system reinstall away from computational bliss. If things go wrong with production machinery that in itself costs upwards of $10,000 and has powerful motors and high-speed cutters that are very unforgiving to this tender human flesh of ours – let’s just not go there.

No, imho Shopbot Inc should --nay, must-- control the core. But it certainly wouldn’t hurt if that core was a little bit more open to the users: not by decree or license, but by functionality alone.

I haven’t coded for real in six or seven years, and I wasn’t very good at it back then either, but I would look forward to dusting off what little I have if there was just more to work with. Not to denigrate those who have done fantastic work with what’s there (quite the contrary), certainly, but give us (say) the typical data structures of modern Basic scripting environments plus four more flow statements and two new i/o options, and it would open up something entirely new -- from what I can tell.

[bill.young]

FYI, the block IF commands...Else, ElseIf, End If...are currently being worked on and then most likely it'll be FOR-NEXT loops. After that I can't say, though SELECT CASE would probably be my vote.

[bcammack]

Those would all be excellent! I finally decided to just try BASIC keywords to see if they worked when I couldn't locate them in the documentation.

Usually they did.


Dynamic arrays and floating point values would be nice, too...

[henrik_o]

That sounds great, Bill. Really, that would help a lot from the little I've gleaned. Hopefully a little exception handling love to go with that?


If you don't mind me asking, what environment are you using for the scripting end of the software?

[richards]

I had to pinch myself to see whether I had died and gone to heaven. Brett and Bill and Henrik are writing about the very things that I've dreamed of for years - not just with the Shopbot, but with process control in general.

One of the reasons that I'm pushing the G100 is that it is Ethernet based. I've tested remote monitor processes at several companies using the same Rabbit processor found in the G100. In effect, the test showed that I could simply look at an Internet web page and see, in graphical form, what was working and what was not working at those company sites. In addition, the remote computers could dial my telephone (in the middle of the night and send a message - really just a series of beeps)to alert me to look at the web page to see what was wrong. (None of the companies bought into the idea. It would have cost them about $1,000 per site. That's just as well for me, since I charge a minimum of $250 per emergency service call - and much more, depending on the time involved.)

Since the G100 is on a network already, if proper software were written, a single operator could control a whole building full of Shopbots.

Sometimes I wonder why we are so shallow in our thinking. These devices have been around for years - and cost well under $100 each. Technology should help us do more than we can do on our own. By not using technology, we're just telling the competition that they can have the whole market to themselves.

One other thought. We sometimes get into a mind set that says that we have a one-to-one relationship between a computer and a controller. With ethernet that is not the case. Depending on the size of the network (subnet), we can have dozens or hundreds or thousands of devices communicating with each other - using one physical connection per device. For instance, if I built a security system that had three computers and a master computer all connected together. One computer might monitor the doors and the windows of a building. Every few milliseconds it would send a status code to the master computer either saying "All is well" or "Emergency ... door X is opened". Another computer could monitor temperature throughout the building. Every few milliseconds it would report to the master computer "All is well" or "Emergency ... the temperature in room 5 is twenty degrees too hot". You get the idea. Little computer devices could each be part of a larger network - all at low cost.

How does all of this relate to a Shopbot. Well, the same principles apply. Lets assume that we want to build a very complex machine that has some kind of material handling and an automatic tool changer built in. One way to handle all of this would be to make the main controller handle everything. And, really, this is the way that most people approach the problem. Another way would be to have a separate controller on the tool changer and a separate controller on the material handler and a separate controller on the Shopbot. Then, when it came time to change the cutter, the master computer would position the spindle to the proper place and then send a message through a socket on the ethernet network telling the tool changer computer which tool needed to be loaded. The tool changer computer would handle the entire tool changing operation and then signal the master Shopbot computer that the tool changing operation had completed. That's not bad for a Z-world Rabbit controller that costs less than $100. (Of course an automatic tool changer spindle might cost well over $7,000 and the other parts and pieces might double that price, but if the need were really there, it could be done.) Material handling could work in the same way. When one sheet was cut, the master computer would send a message to the material handling computer which would turn on a conveyor to remove the old sheet and then insert a new sheet of material. It is possible. Granted, it would cost something to do - but would you as a business man rather pay $50,000 one time to build/buy a machine that could do a lot, or pay $30,000 a year forever for a helper that mostly stood around?

[rob_bell]

In addition to the keywords Bill mentioned I'd recommend scoped variables and unlimited partfile nesting. The four file limit is...limiting.

[bill.young]

Hey Rob,

The limit for part file nesting is now 8 deep...

[bruce_clark]

Hey, while we are at it, how about a ShopBot compiler that generates stand alone EXEs that don't require the ShopBot controller at all? ;^)

Actually, someone asked for a command that lets you "send an email" or "ring the phone". My memory is hazy here, but I remember someone wrote an external program that was called via a Virtual Tool command or something that would do just that. Maybe I should use the search function...

Bruce

[richards]

Is there a list of BASIC commands (VB, VBA or any other language) that can be incorporated into an SBP file? If most BASIC commands are recognized, then it's time that I dusted off some old manuals and started probing the limits.

[bill.young]

As far as I know, all the programming commands that work in part files are listed in the Programming Handbook. It's in the "C:\Program Files\ShopBot\ShopBot 3\Help" folder and also available on the ShopBot web site under "Support".

[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?
7022

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 (http://members.arstechnica.com/x/hiphink/sbdev-1.jpg) 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 (http://members.arstechnica.com/x/hiphink/sbdev-2.jpg) 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 (http://members.arstechnica.com/x/hiphink/sbdev-argh.jpg) 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))*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.Gra phics.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.
7023



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.

[weslambe]

Mike,

I am constanly amazed at how often you bash the poop out of Ted's stuff then back off and praise him. If you are so unhappy, buy another machine for Christ's sake!

You said, Shopbot has a flaw and "That flaw, of course, is that command, on its own, does NOT compensate for the radius of the cutter."

I wonder if you've checked some of the other machines to see if they compensate for cutter diameter? I'm guessing that very, very few do since it's usually a software related issue. You can own a Shopbot and never use a cutter for goodness sake! The stained glass machines have no use for that information.

Buy Enroute! All bits are handled there. Put them into your tool library and use them as you see fit. All bit compensation is done by their software. Don't force the rest of us to have to re-configure the way that we do things because you choose not to purchase software that does the job for you.

This is a bit like asking the computer manufacturer to supply you with an operating system (of their own design, not windows,linux etc...) for free. In other words, "I want a computer but I don't want to spend any money on buying windows etc... Mr. computer manufacturer, make me an operating system for free."

I can create output to virtually any, and I mean ANY machine made in the world right now, or in the past, because I own Enroute Wood.

The little array of squares that was documented above CAN be done RIGHT NOW if you buy the proper software. In fact, I can do it in about 15 seconds.

GIGO The shopbot will do what it's told to do.

Everything that's been said in this thread can be done now with the purchase of the proper software. Hey, write your own. Several of us have done that already.

Shopbot sells the software that will do most anything you tell it to do. Artcam Pro, Enroute and on, and on. You are demanding that Shopbot give away something that they are currently selling. How smart is that? It would make for a lot of happy customers, but they sure wouldn't be in business long, ultimately producing un-happy customers.

I know it's a big step to buy the proper software to run your machine but don't say that your machine has "flaws" when you aren't willing to make the monitary sacrifice that many of us have to improve productivity.

The bottom line: The machine is only as good as what you feed it. If you choose to feed it scraps, then scraps are what you make. Buy good software.

[Brady Watson]

I don't think that Mike is 'bashing the poop out of Ted's stuff'...just verbally speaking in the realm of possibility. This forum is a great way for ALL of us to express ourselves without feeling that we will be squelched for our ideas or made wrong, as far out as they may seem to some. Lots of hardware level discussions (and improvements) have been made in your hiatus & ShopBot has implemented some of the concepts discussed on this board...and I thank them for keeping their finger on the pulse of what power-users want. I think that ShopBot has ALWAYS done a PHENOMINAL job of offering a tool flexible enough for the noobie AND the professional alike. BRAVO to them!

Mike is a good guy and has a lot of good ideas, dreams and concepts that he freely shares with the group. If he kept them too himself, this would certainly be a loss to the community. He's a good guy & someone that I like reading. I don't want to put words in Mike's mouth, but I think he is just explaining some possibilites with the ShopBot front end operating in conjunction with a more robust controller (essentially the card sticking up on you Alpha board gets replaced with a more efficient G100). Keep in mind that these are EXOTIC & HIGH LEVEL modifications and ideas. These ideas are directed to those that get excited with butterflies in their stomach just thinking of the new things that their ShopBot will be able to do for them, with a full understanding of the said hardware's feature set. (Hey...we power users need some exciting stuff to read on the forum too!) For most, the factory offering is fine. For someone like me (and others) we like getting our hands dirty and seeing what improvements we can make...It's like a Mustang. You are happy with your Stock GT, and I want to upgrade the fuel system, exhaust & add a supercharger. Are they both Mustangs when all is said and done? It is just not possible to slow down the rate of 'electronic evolution'. New components will contiunue to be released and developed and you can BET that ShopBot will continue to implement some new technologies to stay competitive. If they didn't do something akin to what is being discussed here, we'd all be humming along with our 1999 PRT, instead of an Alpha series of tools. It'll happen. I've got full faith in the SB Crew, whatever it is that they do in the future.

The software...Contrary to popular belief, NO CAM software on the planet will let you do every move that you would want your tool to do AND be easy to use and quicker than hand coding (under $15k anyway). It's a matter of how efficiently you can get the concept/deisgn in your brain into CAD, then CAM and out to the CNC/physical world. Again, MOST people can do 100% of what they need to do in PartWizard. Some need ArtCAM Pro. Others, like me, do designs that can't be done in either program, and have to rely on hand coding. It isn't required for 95% of what I do, but I need to do it for the other 5%. Also, if you are setting up for production, carefully prepared hand code is MUCH faster than a CAD/CAM package because you can tell the tool EXACTLY where, what and when without the need to create many seperate toolpaths and sequantially order them to emulate what you really need to do by hand. Think that's nonsense? I setup toolpaths for a customer that was run thru ArtCAM at a cycle time of 45 minutes. I was able to hand code the parts to reduce the cycle time down to 14 minutes. That's quite a difference, especially when the tool is cutting out the same thing day in and day out...There are advantages to CAD/CAM...maximum programming speed and ease of use/convenience and hand-coding, which gives you maximum machine efficiency and cut speed. It boils down to what you need. With SO MANY different applications it's hard to plan for 'one size fits all'. Yes, it can be that way, but not always with the factory offering. I don't think that ShopBot is at all opposed to 'adaptive upgrades' since I have seen several custom tools built by ShopBot that are not listed in their catalog, using specialized and non-standard hardware and software. They still had the ShopBot name on them.

-B

[richards]

Wes,
Maybe I can't read between the lines very well any more, but I can't find any statement where I have bashed Shopbot or Ted or anyone else. I have made suggestions and presented a wish list.

I believe that this thread is about why Shopbot should be OpenSource. Some want it fully open. I think that my opinion has been clearly stated that I think that the SB3 software should be left to Shopbot to own and distribute under whatever terms and conditions that they desire. BUT, that is just my opinion.

I accept the fact that the MX,<distance> flaw that I wrote about is inherent in ALL CNC software. I think that I also said that Ted realized that most of us would not be comfortable if we had to offset the cutters ourselves, so he arranged to include a licensed copy of PartWizard as part of the package.

So far, have I been fair with my synopsis?

Now to my little C program. I'm very certain that you can do the same thing with PartWizard, or enroute or almost any other tool pathing software. That was not the context of the example. The context was how a conditional statement was needed outside the SB3 software to do a for/next loop. (Now before this becomes a point, I'm familiar with the various Shopbot commands and I know that a for/next loop can easily be created using existing Shopbot code. That was not the focus of the post. The focus of the post was to point out that a conditional statement could enhance Shopbot code.)

Am I still being fair with my synopsis?

I don't believe that I've made any demands on anybody for anything, have I? I have made suggestions, but not demands. In fact, if Ted were to ask, I would be more than happy to supply him with whatever code I could - at no cost to him or anyone else - but it would be OpenSource Software which might cause a conflict.

And that brings us back full circle. Suggestions are just that - suggestions. My point of view is just that - my point of view. My offer to give away free code is just that - an offer, but this time there is a stipulation, it has to be licensed under the OpenSource Software License so that others programmers can enhance it and improve upon it.

I admire the fact that you have come back into the Shopbot fold after finding that you preferred the Shopbot to the two other machines that you tried. I also admire the fact that you have purchased a license(s) to use someone else's software. That shows that you've looked carefully at how you want to use a Shopbot and evaluated for yourself those things that you knew the machine - as delivered from Shopbot - was capable of doing, and those things that could be done more efficiently with the aid of other licensed software.

So far, I have not found the need to buy other software. I have a copy of Ryan's Cabinet Parts Pro - which is excellent within the scope of what it was written to do. I also have a copy of FreeDoors, which was mostly made possible by Bruce Clark. It is an excellent program - at least the part written by Bruce. Other than that, I've chosen to use AutoCAD LT, PartWizard and C to generate DXF files and SBP files.

You've found tools and software that make you happy. I've found tools and software that make me happy. Now, are we both happy?

EDITED:

Brady, thanks for the kinds words. You slipped in while I was typing. I'm just on my way to the airport - and it was a real boost to see your post.

[weslambe]

Define "power-user" for me please.

[Brady Watson]

It could be said that a power-user is typically someone who has considerable experience with CNC software and hardware who utilizes and exploits the most advanced features of both on a daily basis...although there isn't any official definition anywhere that I know of. It's typically used in a computer software context, and is an actual type of user in Windows networking security (Start Button->Help->Search 'Power-User'). That's where the term originally came from.

Just for clarity, the intended meaning and context in which 'power-user' has been used in this thread, in no way shape or form is meant to come off elitist, or to suggest that a 'power-user' is any better than any other type of user. (That just wouldn't be right, and that's not how I roll) It is simply used as a way to illustrate that some users really need and want the most advanced features on their systems, even if that means doing a little R&D themselves. By sharing it with the group, others can play too, as their individual needs change.

In some cases, having advanced features that any user can implement could mean the difference between being able to take on a job or not. At least it has been this way for me...and I sure am glad that my machine is flexible enough to change with my needs; whether I use factory parts or ones that I have adapted to make my life easier. Interesting enough, the 4G upgrade to the standard PRT tools started as a hacked Alpha board with 4 Geckos wired into it...It was crude, but boy was it exciting to run on PRT hardware! If many of us just kept a stiff upper lip there might not be a 4G, or it's release would have been much later. Nobody knows for sure, but I do think that good things can come out of conversation for the benefit of us all if we can respect each other's 'dreaming out loud', or at the very least respectfully agree to disagree.

-B

[harryball]

SB Dictionary entry:
Power User - See "Brady Watson"

:-)

Robert

[weslambe]

Brady,

As far as my "hiatus," I've just refrained from posting for the last 3 years. It doesn't mean that I haven't been reading the posts.

Whoever,
You say that you are helping Shopbot by posting these kind of posts in this thread but they only make me wonder if I should be suffering a case of buyers remorse.

My stringent defense of Shopbot is also a defense of my own decision to purchase a Shopbot. Part of a person's identity is made up of the decisions and associations they choose to make and I keep hearing from several directions that the machine is lacking in some way or another. Josh says it needs linear guides. Mike says the controller is inadequate and that the software has flaws. These DO become personal because we tie our "person" up in the decision to shell out thousands of dollars. (Nearly 30k for me (prsalpha,enroute,5hp colombo, RouterCAD))

I haven't taken shipment on my machine yet and am wondering if I should consider looking elsewhere. Is this helping shopbot? Far from it. This constant harang on the G100 for instance only makes for confusion and strife.

If you contact Shopbot in private in the future and they decide to use your upgrades and I'm a shopbot owner, then I will be happy to use the technology. Until then, your comments, while very intelligent, only make the waters murky for prospective buyers.

m2c

I don't think this helps Shopbot at all, at least as far as PR is concerned. Technically, it may be the biggest boon to Shopbot that they have ever had.

BTW, using your "power user" definition I guess I am one too. I helped a friend of mine set up his Centroid based CNC Automation machine. Too easy. Dual 10 HP spindles, moving table design with tool changer and the works. I didn't do the physical work, just getting the machine to pick up tools without breaking them or loosing where it was. It took a few minutes having never seen one before. But I'm still not going to tell people what's best for them here. Not my place to do so.

[weslambe]

Oops, I'm sorry. I can't be a "power user" since I only have 92 posts since Feb 2003. 2004 if you look at the registered date.

[conceptmachine]

"Can't we just all get along" sorry couldn't resist

[jeffreymcgrew]

To get this thread back to the point...

Wes: While you're point about too much complexity and too many features is a good one, I feel that it's a little unfair to hold up what is possibly the worst open source example of said problems. ;-)

While I use Open Office (the program you got that screenshot from) it's really no worse than Microsoft Office (pre-2007). Which means it's horrible, but it works.

There are many examples of open source software that is elegant, simple, and powerful as well. Just as there are plenty of examples of commercial applications that are horribly complex and have too many features (AutoCAD, I'm lookin' at you...).

And keep in mind that I'm only talking about the SBP file format to be free (both legally and cost-wise) for others to use and extend. It doesn't mean that Shopbot has to release control of it at all. There are several open source softwares out there that are arranged such that there is an 'official' version that is controlled by a company or group, or even done such that a company or group still maintains total control over the code, it's just that others can legally use it too and submit any changes they made back.

So while it's still just an idea, and I'm not arguing pro or con, just understand that not all Open Source software is the same.

Heck, the reason we can even talk about this on this forum is due to many, many different open source software packages running. Most of the internet, whether that be web hosting or switching networks, is made up of open source software after all...

[Brady Watson]

Jeff,
In reading your post about making the SBP format free, I recall my days of 3D probing on the PRT and saving it as an SBP compared to a 3D DXF. I always thought that it would be REALLY awesome if ShopBot had it's own 3D format or more correctly, a portable 3D format that made it easier to e-mail 3D stuff. For instance, a 400 Meg DXF probe file is only about 12 Meg when it is done as an SBP. Combine that with a max compression ZIP or RAR file and you've got a lotta model in a very small amount of space. If there was a piece of software that would pull in said SBP and convert it (at the customer's place) into an STL, 3D DXF or even SketchUp or other popular format, that would be really slick. I know this is something that only a handful would initially use, but with 3D becoming more prevailent, it could be a really useful utility. Almost like a ShopBot 'PDF'...I know it can be done now to a limited extent with the Probe converter, but I'd like to see more output options. At the very least, if there was a good clean & powerful viewer, you could send customers a file with encapsulated viewer & they could see what the job would look like in real 3D!

-B

[jeffreymcgrew]

Oh, one more thing Wes. If you wind up not liking your PRS can you mail it to us? ;-)

While I totally understand where you are coming from with your desire to not see negative posts about Shopbot, I gotta say that you shouldn't worry. The Shopbot changed our lives, and the Shopbot folks have helped us so much it's not even funny. Just yesterday I had a serious problem (of my own creation) that a simple call took care of. I was, honestly, freaking out for we're on a big deadline, and the machine wouldn't go. They calmly walked me through steps to take to isolation the problem, and after swapping Geckos, swapping axises, and finally tracking down a single loose connection on our Y, we're back in the saddle again.

Keep in mind we bought our PRT over a year ago, and it's not like we're paying for support. If I wanted that kind of personal help with our Autodesk products or Adobe, or heck, Delcam, I'd have to pay, and pay a lot, just to talk to someone who might be able to help me. I used to BE one of those guys for Autodesk, actually, and it's really amazing what some folks pay for even the most simple help let alone the hard stuff.

When I see folks going on and on about the 'faults' of the Shopbot, all I can think of is the great support we've gotten and the fact that our machine didn't cost over five figures and was easy enough to use that a year later we've both quit our day jobs and now are just building stuff all day...

I mean, it reminds me a lot of when I was a kid. See, I had an Amiga computer. It was ahead of it's time. I remember seeing MSDOS when it came out, and then Windows, and thinking 'this is trash, look at all the things it can't do'. But then it was really cheap, really well supported, and really easy to use, and really simple, and, well, look at where we are today. No Amigas, and all Windows. It didn't matter that Windows wasn't as 'perfect' as my old Amiga, what mattered is that is was cheap, easy, and very well supported...

So while I think that Mike means well with his posting, I also think that he's kind of missing a major point here. We can geek out all we want to on CNC, but it seems to me the whole point of Shopbot is to make it accessible, affordable, and simple for the unwashed masses like me...

[handh]

I know how to tell if you are a power user or not, If you understand this thread you are a power user. LOL Needless to say I'm not a power user.

[weslambe]

Jeff,

I'm not worried about the support from Shopbot. I know it's outstanding. My first machine was a PRT96 that I got in May of 2003. It was just before the introduction of the PRT Alpha. Anyway, it came in with two bolt holes mis-placed. They were directly in the path of the motor's swing. These bolts were for the physical stops that kept the gantry from plunging off of the end of the table.

I called Shopbot about this and they were going to FLY from Durham to Mississippi and fix these two holes! I turned them down and simply made a couple of tack welds and cut the heads off. Problem solved. They were willing to go the extra mile for me and that said a lot.

When I was looking at new machines last year I went to their factory in Durham and they turned me loose on their Alpha for the entire day. They didn't bother me even to ask what I was up to. They let me make up my mind. But like ancient crusader said in the scene in "Indiana Jones and the Last Crusade" where they were to drink from the Holy Grail, I "chose unwisely."

Do you remember Dr. DOS? How about programming on punch cards? I love punch cards. I still use them today for shopping lists.

Where are all of the positive posts about the new shopbot? Have I missed them? Is it smoother than the PRTAlpha? Is it less flexible?

I didn't choose the prt alpha because of minor chatter in the cuts. Here's a picture of what my last machine from a different manufacturer did so anything has got to be better. I purchased this machine after making the trip and turning down the PRT Alpha. BIG MISTAKE.

7024
Keep this in mind:
That door was made on a machine with THK Linear Guides and bearing blocks.
THK Ball screws on each axis.
Servos on each axis.
Solid welded table and pedistal.
WINCNC Controller.

Supposed to be top of the line stuff.

[Brady Watson]

Wes,
You're gonna love the PRS compared to the SlopSable
Thanks for illustrating why some pieces of hardware like ballscrews and linear bearings (which DO bind) aren't necessarily better on a CNC router, despite what some people (mostly engineers that don't actually run tools for a living) will tell you. On a metal mill yes, they are the right choice...but most metal mills do not move as quickly as a CNC router and the forces involved are much different. Great pic.

-B

[weslambe]

Brady,

I didn't name the machine, you came close, but all take note: I DIDN'T say what Brady said above.

I am legally bound not to mention said company.

There is one more thing about the Indiana Jones scene where the guy drinks from the wrong cup. Just like him, after purchasing my brand x machine and seeing doors like the one above, my head caved in then burst into flames and I lay screaming on the floor writhing in pain as the flesh was rended from my body.

I hope to get better.

[jeffreymcgrew]

Wes: for what it's worth, our 4G upgrade has totally rocked. We're getting super smooth cuts, and most of what we do is really really curvy, and that's with just an PRT.

The PRS'es have to be great, and I'm really looking forward to seeing one at the Jam coming up.

[henrik_o]

Back to the software side of things,

Brady W wrote;
quote:Almost like a ShopBot 'PDF'...I know it can be done now to a limited extent with the Probe converter, but I'd like to see more output options. At the very least, if there was a good clean & powerful viewer, you could send customers a file with encapsulated viewer & they could see what the job would look like in real 3D!
I don't see any reason why this couldn't be done with what we have today. If you look at my pitiful attempt above, or better at Bruce Clark's excellent file previewer, they both perform graphical representations of the sbp code. Taking it to 3d is “just” stepping it up a notch (or three or four)…

It’s been too long since I played with this, but I do remember working with an extremely compact raytracer which would accept array-based numerical data (like the apps mentioned above). The compiled viewer itself came in at under 5 kilobytes, with support for dynamic viewing angles maybe 20-30 KB. It did not support textures, but maybe that isn’t important.

Alternatively, there are free and pretty much turn key 3d libraries for most visual development suites. They're probably slower and more bloated, but easier to work with and they'd be real purty and integrated with the OS, so you'd have something that "feels like a real application" rather than a development style viewport/commandline look.

Alright, maybe I’m getting ahead of myself and missing something major here, for example I’m not spontaneously sure how to go from a poly to a volume subtraction to a surface, which I would guesstimate would be the required order, but I’m fairly certain it can be done without needing to know anything more from Shopbot Inc.

Actually, afaict, what would be important to the ‘representation’ side of things is not the sbp code itself. That’s there and eminently workable. The problem, as I see it, is arriving at a virtual surface -- which can be represented/visualised. Correct me if I’m wrong, but currently the existing software tools do not support representations using non-standard cutters. So, if I want to use a non-standard cutter (like a dovetail cutter, or a custom shaped cutter) I’m out of luck, I can’t get that visualised.

Now, let’s toy with the idea there was a new (or extended, if SBInc is interested) file format, which could very well be open source and user-driven (because this has nothing to do with machining, just representation, e.g visualising cuts). If we had this, i.e a standard format for the software process from poly to volume, subtraction of the volume, and from subtracted volume to surface, then developers could pick that up and use it for developing various kind of applications and scripts. Someone might develop an app that allowed you as a user to supply a vector of a cutter and see how it cuts, someone else could use it to define a surface and write a plugin for any one of the major rendering packages so you could have radiosity and procedural textures and the bells and whistles in your renderings, a third lad or lass might write a file converter that could output to the common 3d formats. The options are, if not endless, then at least rather grandiose. But if everyone who wants to do representations has to go through the whole process from the basic poly supplied by a sbp file, it won’t happen. It’s just too much work.

We would need to take the sweat out of it by providing the transitory steps. Poly, Volume, Subtractor, Subtracted Volume, Surface. (I think.)

Sure, that’s a major undertaking. But it is doable, and Shopbot need not lift a finger. It’s all there, already.

Ok, this got lengthy, so I’ll continue with some different musings in a new post.

[henrik_o]

Turning from what’s already there to what is not, rather than launch into a long list of what I’d like from Shopbot/Bill Y, let’s just consider the options that would open up if there was a ‘send’ (or somesuch) command in the language spec.

Let’s say the command is ‘SEND’ and it takes two arguments, an integer representing a port, and a string, such as

SEND,77,&variableX
or
SEND,77,”Time to get off your butt and make me some grease!”

If this existed, we could have an app that worked, schematically, like the following, I’ve tried to comment it so that someone not used to scripting/coding can follow the basic flow, if there’s any of you who have made it this far down the thread -- it REALLY isn’t that difficult to do scripting, try it for yourselves and see.

Window1.Open:
Sub Open()
socket1.port=77
socket2.port=78
socket1.connect
End Sub

When the app is launched, it sets up two sockets used for communication, socket1 for reading from the shopbot, and socket2 for writing to an external source. We’ll discuss what this external source could be later. It assigns socket1 to a port that will be used by the Shopbot control software for sending SEND commands, and socket2 to a port for interfacing with an external source. It then connects socket1, meaning that socket is now active.

Window1.Socket1.Connected:
Sub Connected()
socket1.listen
End Sub

Socket1 is now listening for SEND commands from the Shopbot control software.

Window1.Socket1.DataAvailable:
Sub DataAvailable()
dim a as string

a=socket1.readAll
socket2.connect

if socket2.connected
socket2.write=a
socket2.close
else
end if
End Sub

A SEND command has come in. We set up a string, “a”, to store what it is sending, and then readall, i.e read all it is sending. Socket2 is activated, and what is in “a” is sent through that socket. In other words, we are sending out through socket2 exactly what came in through socket1. Then we close socket2, releasing the port we were using (other programs might want to use it).

Window1.Close:
Sub Close()
socket1.close
End Sub

When the program exits, we close socket1 thus releasing the port. That’s it.

Ok, this is just for illustration. It isn’t useful in itself, though we could write an app just like this and it would work-- it would simply relay the information to another port without any formatting. But if we did include that formatting, or had another application(s) listening to port 78 (to which we’re sending data), then we suddenly can talk to the entire world.

We could use this data to:
* Send it to a modem, have that modem call a phone and play a message, the message depending on the nature of the data (“There has been an unspecified error. Machining has stopped. You might want to call a human in the shop or get back here ASAP. Thank your for your time.”)

* Send the data to another computer on a network. If your design computer is not right by the shopbot itself, you’d could still track exactly what it is doing.

* Process it, and if you have a gsm/3G/etc card in your computer, remotely monitor the shopbot. Let’s say you’re the only one in the shop who really knows the Shopbot. You’re away on a job. Something happens during execution of a file. Instead of walking a know-nothing employee or helper through giving you the relevant data (“right, John, the start menu is in the lower left hand corner of the screen, yes, what is that? Yes, the screen is what you are looking at, the thing with all the colours and stuff, now…”) you can access what’s going on through your laptop or cell phone.

* Have another application process and store the data, maybe processing it again. There are so many options here, but one use would be for a “Shopbot Statistics” application, which could store and process data including all executions, the name of the files, who executed, the exact time from start to finish, and so on. You could provide user input to give you reasonable predictions, built on real experience, of when it’s time to order new cutters, or other peripherals (heh).

* You tell me, it can probably be done...

Obviously, this won’t happen by itself. Someone needs to sit down and provide the code for that to happen. And they might want to get compensated for that, as is fair. But it need not be very complicated; the problem is that today we can’t make it work at all (see caveat below). If there was a ‘SEND’ type command in the language, all sorts of things could be developed, as in the above, just for starters. So, as is so common in programming environments, the utility of an added command is typically not linear, but exponential. It wouldn’t take much to turn the shopbot into a device capable not only of doing wonderful things with wood (and other materials), but also of being an integrated device like the technological fashion of today demands. Shopbot need not do much, users can work wonders with what they’re given, I’m sure. But it would need to do exactly that much, provide the one little ping out into the world that we can work with.

Ok, now for the caveat. As stated previously, I have not looked very hard at the language ref, but there does seem to be kind of a workaround there, i.e the ‘OPEN ... FOR OUTPUT’ statement used with ‘WRITE’. This could be used to write data to a new file, created in a directory monitored by a third party application, the file creation being a trigger for the app to open the new file and access its data. This is a hack in the true sense of the word, it is very inelegant, but I suppose it would technically work. You’d be at the mercy of system level api calls being intercepted flawlessly, and generally coding around the true issue, but it could get the job done.

Im not sure of the above, having only looked briefly at it, but I mention it more as a possible hint if anyone is interested in looking at it more in depth, in anticipation of a true send-style command (nudge, nudge). If it sounds like I’m totally focused on comm capabilities, I’m not: I would consider proper support for common data structures to be much more important (if this is not already in, I have not seen it explicitly stated in the documentation, but the Calculated_functions.pdf document does seem to hint in that direction.)

In closing, if anyone has miscontrued any of the above as a critique of anything that Shopbot or Bill Y or anyone else has provided us with, that is absolutely not the case. I haven’t seen much, but what I have seen is very clean, logical and neatly presented. It seems like a joy to work with -- and what little actual work I’ve actually done besides all this talking is testament to that. I could go from knowing nothing about the sbp format and having forgotten most of my scripting to graphically representing sbp files through a hand-coded (if you can call it that in visual suites) interpretator in less than two hours. And even more important: it was FUN. For that, I want to thank everyone involved. I see your names in the author field of the supplied ref files, and I feel you are probably not thanked near enough for the labour you have obviously poured into this, and so well executed at that.

Thank you.

[jeffreymcgrew]

ok after those last two posts I'm not feeling like a power user anymore either. LOL.

[richards]

Henric,

Your posts have been some of the most interesting that I've seen in a long time - as far as making me step outside of my comfort zone and helping me look at the world from someone else's viewpoint.

Right now, I'm visiting one of my sons in Minnesota, and things are too busy to spend more than a few minutes at the computer. Tomorrow evening, when I get back to Salt Lake City, I plan on spending some 'quality' time reading your posts.

-Mike

[henrik_o]

Jeffrey,

Don't say that. So far it's all talk, very little to no 'use'. And this is just about the software side of things, anyway. I haven't even got my Alpha yet, when I get it I'll have to learn how to walk just like everyone has to. You guys are all superpower-users to me.

Mike,

Thanks for the compliment, it does mean something to hear that from someone so obvisouly proficient as you are.

Like I said to Jeffrey, right now it's all talk, but then again we need to start somewhere, and this thread is as good as any starting point, I think a lot of good stuff is already out in the open.

--^*^--

I've put out some hooks to validate/correct my basic concepts as described in the post about visualisations, maybe something will come of that, we'll see.

[bruce_clark]

Henrik,

This is a true hack, by Morris Dovey, but it works the "non elegant" way you preposed above.
http://www.talkshopbot.com/forum/messages/312/13427.html?1148739612#POST36465

Again, something similar to Mr. Dovey's but even better, would be to call a Vitural Tool that was a custom program that did something similar to your "Socket" concept above.

The only thing wrong with the VT idea, and it can probably be overcome with some more investigation into the documentation, is that there is no delay between the Virtual tool call and the rest of the SBP part file execution. Maybe an input prompt or even a msgbox to halt things, but again this probably needs more research. Just an idea.

BTW, I think your SEND command is a sound one, but I am not the "keeper" of the ShopBot language.

Bruce

[henrik_o]

Bruce,

That's a great tip. Yeah, it's still kinda brutish in that you have to code around the designed use, but it would definetly work much better than relying on a _filecreated (or whatever) flag in the system.

I haven't really had a chance to look at the Virtual Tools interface, but will try to get some time. Let me just say that your work on that is a real inspiration.

The SEND command w/ port is just a proposal. It could just as well send to a specified recipient like the OPEN ... / WRITE command currently does, using a port just gives a bit more options imho. If there's underlying support for that in the dev framework, why not, if there isn't, ok, it's not necessary.

[henrik_o]

Ok, back to the representation/visualisation issue, there's basically two main lines of progress I can see here.

We're working with the existing sbp format.

On the one hand, there's the basic array (plot using polylines dispersed over a grid). This is, afaict, basically what the Shopbot Preview does. This is usable for verifying basic machining geometry, but not much more. With enough resolution one could use it as a solid and have something reasonably approximate to render into 3D. This is very limited but on the plus side very doable with readily available dev tools for most suites. You will not get 1:1 resolution or anything near that, but you will get a representation of the machining strategy in 3D.

On the other hand, if we want a true representation of the subtracted volume, with exact definition of a customizable subtractive geometry, then we're probably into constructive solid geometry land and all the boolean fun of that. I have not worked with this, so I can't say how complicated it really is, but sponteaneously it's quite some work unless a robust solid geometry library exists for the dev suite of choice. I'll see if I can get some more hints from the persons who lead me in this direction to begin with (many thanks).

Basically, it's an accuracy issue. If machining vectors are ok, this is a reasonable undertaking for someone with the right tools. I think REALBasic, the only suite I still have a valid license for, supports simple solids and can output to OpenGL.

If we want a 1:1 representation in high resolution of a virtual tool in a virtual material, then a specialist might be needed.

[bill.young]

Henrik,

I really wish I could take credit for the ShopBot software but it's Ted's brainchild and he's done all the work on it, with just a very little bit of help from others.

You might check out the existing "SHELL" command in the programming handbook...it can open a external program, pass that program parameters, and define how it will run.

[bcammack]

Just a note: If there's a software "itch" somebody needs to "scratch", I might be able to dash something off to suit. My business math is way stronger a skill than my geometry and algebra, but I'm educable.


I do work to specifications, so you need to be able to form a clear, cogent description of what something is supposed to do. I'm not a very good mind reader. (ask my wife...)

[richards]

Henrik,
I've read your posts several times since returning from my quick trip. What you have suggested is brilliant - far beyond what I can understand. Tomorrow morning, after I've had a night to sleep off some jet-lag, I'm going to read it several more times until I understand some of the concepts more fully. To me that is very important. I often read a post and realize that my view on a particular point is unsubstantiated because of my lack of data or because I've drawn conclusions before studying the data. Your posts show that much of the data that I use to evaluate possibilities is outdated. So, just like studying any new idea, I've got to read each sentence in each post until I understand all the concepts, then, and only then, will I be comfortable in asking some question and perhaps expressing some opinions.

Thanks for taking the time to present detailed ideas and for going where few have gone before.

As a side note, after this preliminary reading of your posts, I've gained even greater respect for what Bruce Clark has done. I've always admired Bruce and his work, but I can clearly see now that I underestimated his depth of knowledge.

Not that we should start a 'mutual admiration society', but many members have posted important information and important ideas that have, or should have (had we taken the time to read and then think about what had been written) greatly expanded the usefulness of our tools. This is in no way a criticism of Ted or of anyone else who has put heart and soul into writing, developing and testing the tools that we now have. If we fail to admit that one person or even a group of people can only do so much in a given amount of time, then, I believe, we've failed to appreciate how much we already have received because of their hard work and years of effort. Then, when we read posts like those of Henrik, it becomes obvious that we haven't even begun to 'push the envelope'.

[bruce_clark]

Mike and Henrik,

You me give me much more credit than I deserve. I am not that smart.

Anyways, if I get a chance to talk to Ted at the Jamboree, I will see if I can pin him down to a future direction for the ShopBot language. I will let you know what I find out on Monday.

Bruce

[henrik_o]

Been busy with work.

Bill,

Looking at the refs, I'm sure you've had more than a little to do with the code base, though Ted obviously reigns supreme and is in a category all unto himself.

quote:You might check out the existing "SHELL" command in the programming handbook...it can open a external program, pass that program parameters, and define how it will run.
Thanks. That command is not in the programming handbook, though. It's documented in the "SbW_ShopBotProgrammingStatements.txt" found in the "Developer Tools\Docs" folder of the main Shopbot folder.

Yes, it can be used. However, I'd have to say two things about it.

First, I'm not the proper person to evaluate its utility, because I'm a person who more or less exclusively used Apple Macs up to circa 2001, so I have next to zero knowledge of the DOS environment, and this command very much seems like a DOS-type command. Someone who is experienced with the range of Microsoft OS'es should probably look at it. That said, I have tried it, and it does not seem to map 1:1 with Windows XP. Pass arguments as single string, and XP typically returns an exception. Yes, force breaking strings does work.

E.g,

SHELL "C:\Program\Microsoft Office\OFFICE\winword.exe /n"
does not work, but
SHELL "C:\Program\Microsoft Office\OFFICE\winword.exe" "/n"
on the other hand does.

Maybe I misapprehend the instructions, but that's afaict. If I'm missing something, please fill me in.

Second, and again I'm not the right person to evaluate this, but it does seem to me like this command was included for things like exception handling rather than continuous data transfer, right? Due to it's specific execution/address, it does not seem very compatible with talking to apps/devices. Don't get me wrong, it's certainly very useful for things such as exception handling, but I'm not sure how much beyond that.

OK, I realize I'm hitting you with these questions at the most inopportune time, the Jamboree being underway. Maybe we can revisit these matters at your leisure, and see where it takes us.

[henrik_o]

Mike,

You make a grown man blush. Thanks, but your praise almost makes me nervous. We'll see


Bruce,

I don't think it's about the smarts. It's about having some decent knowledge, and then doing something with it. You have done that. That's an inspiration to me, and to many others, I'm sure. I also want to do, all this talk is great but it's the doing that's the real award.

[henrik_o]

Alright, been busy with work but also had a chance to think about the whole graphical representation thing, and doing some preliminary testing. Man, this makes me realize I should have stayed more alert in Gymnasium (our equivalent of High School) math classes. My apologies to those who have solid knowledge of the relevant math, I've tried to make the following as simple as possible so that even a math dunce like me can go along.

Anyway, I would hope to do a better summation of my reasoning from the very simple to the somewhat less simple, but for now the following will have to do.

We're interested in machining code from .sbp files, which is typified by

command,,

Or to look at an actual example line of code

M3,100,200,20

Now, to represent straight 2D data graphically, we need only extraxt the x and y values from this line. We can store that data, and the data from all lines in a file, in an array and then ask the computer to draw a line through all the points we have stored, a polygonal line. This will give us the most simple 2D representation possible: we'll see as lines the path the router/spindle would move through to cut a file.For relatively simple files, this is ok. However, if we want to machine a relief (i.e do a raster x or raster y?) this 2D data is worthless. No matter how superbly intricate our model is, in this 2D representation we will just see a very tight grid, because the computer will render it as seen from directly above so we can't determine depth. In order to see depth, we need to see it from an angle, and that means a need for z data.

Instead of reading just the x and y data, we read the x and y and z data. Now we have real 3D data.

So, instead of our graphics engine reading just "100,200" it reads "100,200,20". Now we have enough data to do some very simple operations on it and display views that include the third dimension.

One very simple transformgoes like this
x'= x + (y cos A) ; y'= (y sin A) + z
where x' and y' are screen coordinates, and x, y and z are the data from the shopbot file

This image gives us a better idea of what is going on;


7025

In the left column, we have the literal input from a .sbp file: it appears exactly as it does if you open a .sbp file with an editor though command data has been stripped out here.

In the middle column, we have this data after having gone through the transform expressed above that column, and in the text above. It's just one example (and there are some variables not shown in the expression).

In the righthand column, we have the data from the middle column read into a 1-dimensional array, ready to be output to the screen.

To the right of the righthand column, you have the data output to the screen in a graphical representation of the code.

This is all very simple, and of little practical use, but the point here is that we have proven a concept: we have taken public sbp data and we have represented it in a way allowing for 3d data representation.

It can be done with what we have. We do not need to know more from Shopbot: the tools are right in front of us.

[henrik_o]

Ok, the above image is perhaps a bit too bland even for validating some math.

This is a bit more interesting, visually.


7026

[bill.young]

Henrik,

If you're running v3.5.3 of the ShopBot software, the current Programming Handbook is installed in the "ShopBot 3\Help" folder...if not it's downloadable from the ShopBot web site under "Support". There are several new commands documented in it including a message box command and the MD command for making moves similar to the way the LOGO language works...by specifying distance and direction

I'm not sure why the SHELL command isn't working correctly for you, but you're probably one of the first ShopBotters to play with it. If I create a file with the following commands in it and run it...

*********************************************** ***

M2, 10, 10
SHELL "C:\Program Files\Microsoft Office\OFFICE11\winword.exe /n",4, SYNC
MX, 48

*********************************************** *

...the tool moves to 10,10 and then opens Word without a blank doc open ( the /n parameter ). When I close Word the tool continues to X=48.

Beyond this I'm way out of my league, but in theory any program that lets you pass command line parameters could be opened...maybe Thunderbird to send an email alert or a program that would do what your SEND command does. At the moment the SHELL command doesn't handle a return value from the outside program, but that might be possible in the future.

Bill

[henrik_o]

Bill, thanks for the prompt reply.

Yeah, I'm sure versions are to blame, because

M2, 10, 10
SHELL "C:\Program\Microsoft Office\OFFICE11\winword.exe /n",4, SYNC
MX, 48

does not work in XP SP2 w/ SB 3.4.0.27, while

M2, 10, 10
SHELL "C:\Program\Microsoft Office\OFFICE11\winword.exe " "/n",4, SYNC
MX, 48

works, though the ",4,SYNC" part makes Word return an error -- strip it and it works under ASYNC by default, I imagine (it behaves that way).

Ok, I'll try to get my hands on a later version to play with in the weekend or so.

In parting, what IDE does Shopbot use to maintain their code base, and in which language is it written? (If you're at liberty to divulge that info, but I don't see any harm in that. Better safe than sorry, though.)

Happy Jamboree!

[richards]

Henrik,
I had trouble with the SHELL command also, but after downloading the latest SB3 file from Shopbot, the SHELL command works. (I still use the older SB3 on the two computers that actually do the work. I've only loaded the latest version on an extra XP that I mainly use for program development.)

Your post processing examples still have me awe struck. I had about 30 hours quiet time while traveling to and from the Jamboree this week. Some of that time was used to mull over the possibilities that your code have opened.

Most of the things that I need to do would be to create the original SBP file and then add custom code to use standard SB3 commands that are not used by PartWizard when PartWizard generates a tool path. For instance, I like to ramp into a cut whenever the material allows it. PartWizard plunges into an arc and then cuts at a predetermined depth. The CA, CC, CG, and CP commands all have much more potential than PartWizard uses, but a little custom programming fixes that. The trick is to automate things so that I only have to enter a few lines of code into the SBP file and then let the computer do the work.

As an example, I have a C++ program invoke the SB3 program:

system("c:\SB3\Shopbot3\SB3.exe C:\Files\test_shell.sbp,,5,,1,0,0");

Then, in the SBP program, I open a file and write variable information to the file:

OPEN "C:\files\v_out.txt" FOR OUTPUT AS #1
WRITE #1, &x
WRITE #1, &y
WRITE #1, &z
CLOSE #1

Then I "SHELL" into an external program:

SHELL "C:\files\shell_test.exe",4,SYNC

In the C++ shell_test.exe program, I open the v_out.txt file and use that data to create new data or commands for the SBP file. After the new data is written to a file, v_input.txt, the shell_test.exe file exits and control is returned to the original SBP file. In that file, I open and then read the data from the v_input.txt file, etc.

OPEN "C:\Files\v_input.txt" FOR INPUT AS #1
INPUT #1, &x
INPUT #1, &y
M2, &x, &y
INPUT #1, &x
INPUT #1, &y
M2, &x, &y
CLOSE #1

That code, along with the IF .. THEN ... GOTO conditional lets me work around some of the 'limitations' of SB3.

Because I can SHELL out of the SB3 program, I could have any number of C++ programs handle anything exotic including Tool Changing, or remote status display via a webpage, or email notification that a custom part is in the process of being cut, all without needing to bother Shopbot about code changes.

Before anyone writes back and informs me that they could do the same thing with X-Brand software, let me just state that no matter what brand of external software we use, there may come a time when we need one more feature before we can do our work properly. By using some of the 'less standard' commands that SB3 offers, it looks to me like the language can be greatly extended - if we take the time to think things through.

[henrik_o]

Mike,

Great example! Since I have yet to recieve my Alpha and have never seen a Shopbot in real life, my intuition as to the machining itself is limited, to say the least, so I was focused on the 'external integration' which I can get a handle on without having seen the machine, but your example really shows the power of 'internal integration': letting the user take control of all layers except the direct command->machine link. This is very powerful imo, and a lot can be made to work with what is there today (though I would have to insist that in terms of integration and environmentalisation of the .sbp format, some kind of port-type layer would be much wanted since it would allow 'seamless' data flows, rather than "push/pull" --or more like knock-over-- style interaction).

I did say earlier that more important than that (ports etc) is support for 'proper' data structures, and I would still stand by that (if it is not there, haven't gotten so far), but on the other hand your proof of concept shows that we can get around that by shelling out and essentially creating a virtual .sbp file environment in which we can structure and process data any way we want to (if our IDE supports it) and then shell back in. It's a bit Java-esque, in some senses.

Now, as previously stated, I've mostly programmed for the Apple Mac (pre MacOS X, at that) so I don't really have a specific knowledge of Windows IDE's, but afaict it should be very possible to create a class module for object oriented Windows IDE's, which the user could simply drag and drop into their chosen IDE, and have the simple but tedious work of manually adding in the relevant data/command types of the .sbp format instantly taken care of. It could include 'canned' class-bound methods to read, parse, process and return data. "Programming" the shopbot (i.e .sbp file) could be as easy as firing up the IDE, loading the class, then add a couple of buttons and checkboxes, defining what you want done with the original .sbp code, then hit "Build" and there you go.

Total control of all non-machine programmatical layers, at your fingertips. Want to talk to outside devices, like a modem? Fine, we can rewrite an existing freeware module doing exactly that, so the user doesn't have to do any of the programming himself, just set up and then invoke some simple commands in the code, like

modem.connect(xPort as integer, connected as boolean)
modem.send(xRecipient as string, yMessage as string)
modem.close(closed as boolean)

Heh, ok, I seem to be stuck in the 'external integration' routine again.
But it could also be

sbp.convertCommandXtoCommandY(all as boolean)
or
sbp.offsetXaxis(xAxisOffset as double, inch as boolean)
or whatever, really.

Like the venerable musical duo 2Unlimited once opined, there's no limit (oh oh, ohohohoh). Well, ok, there always is, but it's a pretty fair deal once you reach around a bit and feel accustomed to it. Shopbot controls the direct code->machine link, we can control everything else. Fair. Personally, I must say that Jason Fullmer's terrific work has me a bit comatose in awe, but also more interested in the idea of 'free representation of geometries', i.e user-defined cutting geometries, and then there's the whole 5-axis thing Shopbot is enticing us with. Aside from that, however, I think the scripting of the 'bot should be as user-accessible as is possible, and if I could provide anything at all, which I'm not sure of, I would like to get some heads together and look at the possibilities of a 'canned' object-oriented approach as per the above. As another fine European orchestra also opined back in the days, Music for the Masses; I think that's very true of the .sbp format and its manipulation as well.

Ok, now I think the great boys over at the local Council of Work Safety and General Hindrance has enough on me to recommend a bit of knee-capping fun, I should just sit tight and await the delivery of my Alpha so I have some actual hands-on experience. Talk is easy, and that's all this is.