Post Processor Modification

[ryansturmer]

I (like many at ShopBot I'm sure) do not spend as much time on the forum as I should. You'll notice this is my first post! I'm relatively new at ShopBot, so I'm going to forgive myself for that. These discussions are important though. We see them. We are taking notes.

I wanted to address some of the FabMo comments directly, since that's squarely my deparment. It is a place where we are doing quite a bit of work, and have made (and continue to make) substantial investment. Mostly, we do not post a lot about it, here or elsewhere, for fear of misrepresenting our timelines to those who are excited about getting their hands on new products. We've been burned by that before, and don't want to get out there with too many details until we're really ready to share.

First of all, we are in the process of moving to version 1.7.0 of FabMo, which will address a lot of the issues that we've identified on Handibot, and will add a number of features that we see as necessary to ship the platform on larger tools, starting with the ShopBot Desktop and MAX, then expanding to the Buddy, and eventually gantry tools. We've suffered some substantial delays in doing so for a number of reasons, not the least of which has been the debacle with the Intel Edison, which I'll discuss below. Even without the issues with the Edison, we're a small team, especially with respect to our software development. It's the case that we have a lot of products that we make and support, and as I'm sure is the case in other companies, sometimes things just take a little longer than they feel like they should to get right. When you're building the plane as you fly it, you always need to make sure you're staying airborne. We're expecting the Desktop switch over to happen over the next few months, with the change for larger tools coming not far thereafter.

Second, FabMo has never, and will not ever depend on the Intel Edison. The Edison was our target for Handibot, for various reasons, but we can and do routinely run it on a number of different hardware devices. It runs under Linux, on MacOS, and on Windows, and we've run it on several SBC platforms, as well as on conventional PCs. My tool at home runs on the TI sitara processor. We've got a few handibots here that run on Raspberry Pis, and most of our development work happens on MacOS X.

Intel really let us down with the Edison. It was a half-baked product that they didn't support well, and that didn't really have a market. They pulled the plug on it without warning, without offering a substitute, and the switch caused us a lot of grief and pain. We should have kicked the tires more when we selected it, but that's water under the bridge now. Fortunately, there didn't seem to be a mad scramble to buy them after Intel canned it, (can't imagine why!) so we were able to purchase enough to continue with Handibot production until we have a replacement, and keep repair stock for a good long time, so we can continue to support customers with Handibots.

It's a shoddy craftsman that blames his tools, however, and in the wake of the Edison, we have been hard at work on an alternative design, which will be the foundation of the products that go out in the larger tools. This one is done with an ARM processor from the ground up, and one that has a guaranteed product longevity, both from the chip-maker and the SOM vendor, who is a reputable supplier that deals regularly in the industrial and automotive markets, so that we can be sure that we'll be able to supply and support the product for at least as long as we've been supplying and supporting the ShopBot legacy products that people use today. It's also a platform that has a robust upgrade path, so that as technology advances, our control systems can advance with it. I'm in the process of reviewing that design even as I write this, and I'm hopeful that we'll be testing that in the next couple of weeks.

As for everything else, all I can really promise here is that we are listening, and we are working hard to make things better. We don't get to bite off all the initiatives we'd like all at once. Indeed, many of the suggestions made here are things that we've debated and discussed internally for some time. We'll continue to press ahead on the things that we've got the bandwidth to get done, and keep listening and discussing here as much as we can.

[EricSchimel]

I totally agree about Windows computers... They can be a pain. Many years ago I can see how it made sense to use them.. They're powerful, cheap, and everywhere. The reality like many of you have said that what was once a powerful part of the SB experience has turned into one of the trickier parts of using a ShopBot.

For me, FabMo is pretty awesome because it moves the computing power on the tool itself. This, in theory eliminates all of the variables that an external computer introduces. So that's pretty awesome. On top of that, it's a totally open system so that anyone can contribute to the code, and fork it for their own use. That's also pretty awesome.

The reality right now is that FabMo is still pretty early stage, and that's to be expected as it's a total re-write of the control software and a total redesign of the control board. Because it's so early stage it's only on Handibots and some Desktop machines. And based on my experience using it on a Handibot, that's a wise choice AT THIS MOMENT.

I commend you guys very sincerely for the FabMo effort. I think it's heading in the right direction for some of the reasons I stated above, including being open source. Here's where if falls apart a bit for me:

The Edision thing sucks. It's something you've got to move away from and you're clearly already doing it. As someone who isn't a real programmer, but a DIYer and tinkerer of many things I've become pretty good at fooling around with Raspberry Pis over the last year. I'm no master, but I built a little print server, a media server, and even a retro gaming console out of a few of them. It's been hard to learn Linux, but thankfully there's a lot of great guides out there and a lot of well documented open source software that I can use and try.

I want to be able to fool around with FabMo, I want to be able to adapt it to a small CNC build I'm considering, and I'd love to build some little web apps to automate some regular production work that I do. As a newcomer to programming, and fooling with this embedded control stuff I don't feel like the resources and support is there. If I feel that way, others do to...

So on a technical front, I'd love to be able to have an official build of FabMo that I could flash to a Pi and connect to the motion control board so I can really fool with it. Maybe that exists now, but I'm not aware of it.

Moreover I, and I'm sure other developers are out there that'd love to fool with and ultimately help push this platform forward. The control software is the heart of the machine and ultimately for the people that use it. If you guys at SB can make it easier for us to help you, either by way of letting is more easily hack it, give feedback, making it available on a ubiquitous piece of hardware we can all help push it forward. I for one want to see this work out, but I don't know how I can help beyond posting something like this.

[Brady Watson]

Tom...
Thank you for standing like a man and debating this unflattering issue in public. You are unique among your peers. "Official" company presence has been sorely missed on this forum.
Guys like Brady and myself (among many others) wish nothing but the best for our friends at ShopBot. Not from a brand loyal "everything ShopBot does is the best" perspective, but from the perspective of a "first love". You NEVER forget your first.
As a pragmatist, I watch from the wings, waiting on results, not words.

X2 Gary

I am offering my thoughts as a prior professional software developer with expeience with manufacturing hardware integration and client/server development. While the development tools have changed over the years, the way you code, the anticipation of errors/foolproofing and the rollout procedures are the same. (as well as the snafus along the way) I have also been a ShopBot customer for 17 years, giving the company close to $100k over the years, as well as a SB tech/trainer for about 13 of those years - diagnosing, repairing and setting up every SB model. Failure was not an option and the customer needed to be running by the time I left. As Gary could attest to, you get real good, real quick when you've got to get the job done using the tools and resources at hand. I have used my SB machines to make a living since 4 days after I was laid off (with 700 others) as a programmer. Running a job shop isn't easy - you have to think on your feet every day and come up with shoestring solutions to expensive problems. The stability and robustness of the CNC is of prime importance to someone like me. There isn't time for failure. It just needs to work.

In my 7,000+ posts on this board, I would say the vast majority of them have been helping others with some support issue - freely, without pay and with little gratitude from SB. Most of my solutions came from the school of hard knocks. I don't do it for ego, for pay or anything other than I have the knowledge, and with that comes responsibilty. It has a shelf life and why not help a fellow brother out of a jam? Now that I see SB staff taking a role on the forum, I will hand over the reigns to you. It's a shame that it took your most dedicated and supportive customers saying 'enough is enough' before you showed up, but you're here - so welcome and good luck. There's work to be done.

I for one, am neither impressed nor excited about the FabMo project. I think there is way too much blind faith being put into it as if it is going to be the cure to all ails - and I think that nothing could be further from the truth. You may have well said, "The invisible man in the sky is going to deliver the FabMo and all will be right in the world again." Allow me to explain from the perspective of a former developer and professional CNC user - including a ShopBot enthusiast.

The ONLY thing a CNC owner/operator cares about is reliability. All have their flaws, but if they are reliable they can be accounted for. Mechanical failures are usually apparent and fixable by the end user - the control software - not so much. It needs to be stone cold reliable and function properly 100% of the time. As someone who has used another CNC controller for 10+ years - it has been flawless except for one time when the power flickered, which I can't blame it for. I cannot say the same about the SB controller, although through my advanced knowledge, courtesy of being a SB tech, I managed to get it fairly reliable, but it took a lot of work. I truly have empathy for others not as lucky as me in this regard, which is probably why I have volunteered advice.

No professional CNC operator (not speaking about hobby/part timers) that I know is going to want to run their CNC on a tablet/phone or any other delicate device like that. It's silly to us - but if you are marketing small hobby tools - that is a VERY different sector of the CNC market than a professional who relies on the tool to eat. The OS is irrelevant if it is reliable. It's 'really neat' isn't good enough for a pro. They just want it to work and be as reliable as their table saw or drill press. Reliability should be the target in the crosshairs and nothing else. Without that, all else is nonsense. If I were spec'ing out the right hardware to move forward in terms of user I/O it would be a well thought out touch-screen interface and the PC would be in the control box. End of story. It would be easy, reliable and straightforward, with the ability to diagnose the PC remotely, in service to the customer.

This idea that FabMo is going to be able to be driven by any OS or device is both unrealistic and silly. Has anyone who has rolled out software before really thought about the ramifications for your customer base like, at all? OK - it connects via a web browser. Got it. What's going to happen before that? How much will the support staff have to know in order to be able to answer the customer when he asks how to get the network/web interface working on his (insert platform here)? Do you honestly think that it is just simply going to be plug and play? I know otherwise...mostly from getting my butt kicked doing similar things in the past.

There was a phrase that went around the building in Durham not that long ago that went something like this, "We believe no ShopBot should ever become obsolete & that there is always an upgrade path for legacy hardware." Barring the fact that the fairly affordable 4G was kicked to the curb (Why? People still want to buy it) for a $3k RBK that performs no better - what happens when the people want to upgrade their legacy controls over to FabMo? In case you haven't given it much thought - here's what you'd be up against from a support standpoint: Customers will be running XP or Win7 computers that have been stripped down to eliminate the web and networking because those were deemed 'bad' for SB3 operation. They will be running either Internet Explorer v4.02 or possibly IE6 on machines that have never connected to the net or networking ever. Now they need to make sure that they have a current browser and all dependencies in place just to be able to see the FabMo interface, let alone run it. Are you sure you want that added chaos & load on support?

If I recall correctly, it only took SB like 1-1.5yrs to go from DOS SB2 to Windows/SB3 for the Alpha. The FabMo has been under development for 6+ years. Why is that? OK - some hardware setbacks with the Edison - there are many other choices. Beaglebone or ARM come to mind. If I were making the decision for a modern controller, I would just farm it out. If it's open source, who cares who develops it, right? Isn't 'all that' going to be made available? - Or will it just be called 'open source' to sound hip to young buyers? There are many reliable controllers out there available to OEMs that can be skinned with the SB logo for less than developing in house AND they're so good they don't need more than one or two support people on staff to handle issues. Stop and think about that for a moment.

Open source? Sure you want that headache? By open source, do you mean the average user can get in there and mess up the code to the point where they brick your hardware and have to call support? Like that? Or...will it finally let them change out the screenset to things that make the most sense for their skill level? This seems to be a muddy topic because most don't know other controllers support nearly the entire GCode command/feature set to the point where it doesn't leave an advanced user looking for more control. I don't know of any state of the art controller that lets people monkey with the source code...and it is for good reason. (I am not talking about Marlin et al)

The 'Open SBP' thing...neat, but the reality is, every other CNC on the planet(!!!), including 3D printers, routers, mills, lathes etc runs GCode. It isn't hard to learn and the truth is, most never have to learn it anymore than they have to learn SBP. CAM handles pretty much everything except C2/C3 macros for homing etc. Very few even mess with SBP code. Somewhere along the line it was decided that ShopBotters are too stupid to learn GCode - so let's dumb it down to 2 letter phonetic codes for them. Do you know what learning SBP does to your customers? It makes them obsolete/unhireable in the workplace since every place uses GCode - unless they just so happen to have a SB, which is rare compared to GCode machines. Others have brought this up over the years and SB3 barely runs the most basic of GCodes (or not at all depending on the version of SB3 - even with converting it) because SB3 doesn't support all the features of comparable CNCs. I'd like to know if the SBP language is a way to keep customers tied to SB hardware because they'd have to learn dreaded GCode on another CNC or if it was just because they were deemed less intelligent than the rest of the world running CNCs on GCode? (or was it another reason? I want to know) What I find REALLY interesting is if you take a FabMo and run it on GCode it runs like a top - run the same setup on SBP and it runs slower. Hmm...

Going forward (as suggested years ago) there needs to be a new committee @ SB consisting of 3 or 4 employees whose job it was to find out exactly all the features of competing machines as well as what current CNC trends in hardware/software (controllers, motors, bearings, chassis) and use that research to steer the company's future in the right direction. I am available as a consultant should you need help doing this and getting up to speed. I really want SB to succeed and have the major presence it once did in the market. It goes without saying that I love everybody at SBHQ - we've done so much together over the years and have promoted each other & I wish you nothing but good luck.

-B

[ryansturmer]

These are all great points, and exactly the kind of things that we're considering as we move our platform forward. It's completely understandable to interpret fragmented messages from us as a lack of customer focus, or an indicator that we're developing new products without proper attention paid to the market. These are things we are thinking about constantly, even if our outward messaging doesn't make that clear. It's the case too that we've had some turnover in recent years - some projects have changed hands - this stuff isn't always outwardly visible, and also has an impact on timelines, messaging, etc.

I'll follow the pattern of responding specifically to technical points, since that's where my duty and my strength lies:

The ONLY thing a CNC owner/operator cares about is reliability.

Agreed, for the most part. The issues we're resolving as we start to move toward the tools that are aimed at Manufacturers are largely about getting the reliability to where we want it. I will say that the "cnc operator" is pinned into a box where a CNC controller is a certain thing and does a certain thing and behaves a certain way, and while we're looking to make sure that we have all of the relevant capabilities of our competitors machines, we're also looking to expand how these machines work and what they do in a modern manufacturing environment, without sacrificing that reliability. I'd also caution against lumping "all" customers together, ever. I think it's fair to say that all customers care about reliability. It's probably a mistake to say all customers only concern is reliability. Does that make sense? I feel like my foot is actually inside my mouth every time I manage to say "all customers"

This idea that FabMo is going to be able to be driven by any OS or device is both unrealistic and silly.

My comment about it running on different devices and operating systems was not meant to tout this as a customer feature of FabMo specifically, but rather to illustrate that the fate of FabMo as a control software solution is not somehow entangled with the specific hardware of the Intel Edison, which would indeed be a concern, given that they don't exist anymore. Obviously, we are pulling together specific designs for specific hardware, and that is the qualified product that we will send to customers.

No professional CNC operator (not speaking about hobby/part timers) that I know is going to want to run their CNC on a tablet/phone or any other delicate device like that.
...

Agree on all points. Ability to run on a tablet/phone is an interesting side effect of the network connected platform, and offers options for unique interactions in unique situations, but isn't the cornerstone of FabMo's advantage, in my opinion, at least for shops where a tablet is likely to be banged around, dropped, operated with gloves, etc. A conventional shop-friendly interface is the thing to use here, which it fortunately also supports. I think there's a lot of good reasons that a hobbyist/part timer would choose our products, but I'm not aiming my efforts at people who only need to the tool to work some of the time by definition. We're here to make tools that work, and that always work.

There was a phrase that went around the building in Durham not that long ago that went something like this, "We believe no ShopBot should ever become obsolete & that there is always an upgrade path for legacy hardware." Barring the fact that the fairly affordable 4G was kicked to the curb (Why? People still want to buy it)...

We're actually looking at a refresh of our tools that include more cost effective controls and drive systems, so this is not falling on deaf ears. So far as upgrades for new controls, these upgrades can come with a computer qualified to run the tool - unless you feel that supplying a computer that is already pre-installed with the resources needed to run the tool is a bad idea? I (and others here at the shop) are big fans of it, and I think that an integrated computer with interface must at least be an option on any upgrade trajectory.

If I recall correctly, it only took SB like 1-1.5yrs to go from DOS SB2 to Windows/SB3 for the Alpha. The FabMo has been under development for 6+ years. Why is that? ... There are many reliable controllers out there available to OEMs that can be skinned with the SB logo for less than developing in house

I can't comment on the broader FabMo timeline, because I'm new. See above though, about turnover and direction. I'll hide behind that for now. So far as farming it out all I can say is that I prefer to design tools rather than have them designed for me. I'm not putting ShopBot's sticker on some OEM controller. Our competitors can do that all day and night, and there's nothing wrong with that, if that's your business, but that's not us. We make things, we make them here, and we stand behind them. That's our ethic.

Open source? Sure you want that headache?

I believe in the Open Source thing, and I stand behind it, but I will say that ShopBot institutionally doesn't do it very well. We're getting better. When we say open source, we mean that the source code to all of our hardware and software is available to anyone who wants to work with it. Part of that is just being open, but most of it is about documentation and reaching out to the community. We do the open part well... the documentation part, not so much. We're working on it. - This one is actually a long discussion, that I won't do justice to here in this thread, but perhaps we can talk about it another time.

The 'Open SBP' thing...neat, but the reality is, every other CNC on the planet(!!!), including 3D printers, routers, mills, lathes etc runs GCode. ...
What I find REALLY interesting is if you take a FabMo and run it on GCode it runs like a top - run the same setup on SBP and it runs slower. Hmm...

I have to wholly disagree with your first statement here. The "OpenSBP" thing is more a hassle than it is neat. It exists for a good reason (that happens no longer to be relevant), which is that the early conversational interface for ShopBot was meant to be easy to remember for new users. The early ShopBots were the first tools in a market that wasn't familiar with G-Code, and there really wasn't any good reason to build in that that kind of compatibility. As ShopBots moved "up" in the market, and competitors moved "down", "G-Code support" was sort of begrudgingly added so that customers coming from other environments could run their files. The fact of the matter is though, that when you get right down to it, "OpenSBP" really isn't any simpler to use than G-Code, and in many ways, it's more complex and more confusing. It offers programmability that many g-code systems don't, but even that is increasingly untrue. OpenSBP has tons of issues that drive me nuts. The language is irregular. String quoting is optional, causing syntax confusion. It uses case-insensitive identifiers. The ON INPUT statement is a disaster. The sb3 implementation has issues in its expression evaluator, causing frequent runtime errors if you're doing a lot of complex math. We're including it in FabMo for legacy support reasons, but the fact of the matter is, that you're right. G-Code really ought to be first, and it should be the language focused on in teaching and training so that our customers are learning skills that are portable. I'd like us to move in that direction. There's the issue of programmability, and what to do with C2s and C3s and kooky tools that require special handling, and tool changes, but if we started from scratch the way I'd handle that is have the tool run two languages. G-code, for running jobs, and then have a macro language that is specifically designed for doing the plumbing needed for tool administration activities (homing, zeroing, tool changes, automation) - rather than having one language that does kind of a half-assed job at both of these mostly separate tasks. As it is, our plumbing language is going to be OpenSBP for now, and we're going to steer users towards either openSBP or g-code, as is their preference. Going forward, you can expect to see a more g-code friendly attitude from us. The g-code running quicker on FabMo is, as you observe, the result of translating from OpenSBP to g-code in real time. It used to be much slower, and is now only a little bit slow, but even this is for reasons that are mostly not good, and will be fixed in an upcoming release. I am going to resist my temptation to go into extreme detail here, even though doing so would be a lot more fun than responding methodically to your other criticisms.

Going forward (as suggested years ago) there needs to be a new committee @ SB consisting of 3 or 4 employees whose job it was to find out exactly all the features of competing machines as well as what current CNC trends in hardware/software (controllers, motors, bearings, chassis) and use that research to steer the company's future in the right direction. I am available as a consultant should you need help doing this and getting up to speed. I really want SB to succeed and have the major presence it once did in the market. It goes without saying that I love everybody at SBHQ - we've done so much together over the years and have promoted each other & I wish you nothing but good luck.

I'm not sure we're prepared to pay for consulting when we're getting all this good advice for free on our public forum! Keep the suggestions coming, I guess, unless you're committed to start charging for them.

[Brady Watson]

Ryan,
Thanks for the intelligent response. I'm glad you're on the team and energized to move things in the right direction. A few points:

I think it's fair to say that all customers care about reliability. It's probably a mistake to say all customers only concern is reliability. Does that make sense? I feel like my foot is actually inside my mouth every time I manage to say "all customers"

Of course - it goes without saying that nothing is absolute. But...Without reliability - what good is any one or any thing? Right?

Agree on all points. Ability to run on a tablet/phone is an interesting side effect of the network connected platform, and offers options for unique interactions in unique situations, but isn't the cornerstone of FabMo's advantage...
We're actually looking at a refresh of our tools that include more cost effective controls and drive systems, so this is not falling on deaf ears. So far as upgrades for new controls, these upgrades can come with a computer qualified to run the tool - unless you feel that supplying a computer that is already pre-installed with the resources needed to run the tool is a bad idea? I (and others here at the shop) are big fans of it, and I think that an integrated computer with interface must at least be an option on any upgrade trajectory.

It's good to hear that this is a secondary 'feature' and not the focus. Yes - Agree 1000% that a computer/controller package of known quantity is the only way to go. Otherwise it's just the Wild West and chaotic for all concerned.

We make things, we make them here, and we stand behind them. That's our ethic.

Well sorta...if by 'here' you mean NC

I have to wholly disagree with your first statement here. The "OpenSBP" thing is more a hassle than it is neat. It exists for a good reason (that happens no longer to be relevant), which is that the early conversational interface for ShopBot was meant to be easy to remember for new users.

Umm...I remember - I was there! If SB could run on GCode similar to other machines, this would allow for standardization in a shop running multiple machines - in case that wasn't obvious. In addition to this, it would be amazing to run the SB controller on ANY CNC configuration, including milling machines and lathes - but let's walk before we run. There isn't support for the code needed to support a lathe or mill at the moment (with features I require) - but it sure would be nice.

As ShopBots moved "up" in the market, and competitors moved "down", "G-Code support" was sort of begrudgingly added so that customers coming from other environments could run their files.

Sometimes...but what about all those low cost 3D printers that are the perfect segue into wanting a CNC router? They all run on GCode...all of a sudden, they need to learn SBP or just buy a GCode machine - so there's that. But good to hear that GCode will be less of a dirty word going forward.

I'm not sure we're prepared to pay for consulting when we're getting all this good advice for free on our public forum!

I thought I was just stating the obvious - the consulting fee is for stuff you don't already know! You know, the 'good stuff'

Cheers & thanks for discussing. It is refreshing to have an intelligent conversation. It would be great to meet in person sometime and compare notes.

-B

[Gary Campbell]

Ryan...
Thanks for being open to this conversation. As you might expect, I have a couple counterpoints, but will take my 3), 5) and 6) above. GO GCODE!

I would propose that if face with the SBP/Gcode/both decision that you should simply: Pick A Lane! Gcode is the larger and far greater supported subset of the 2 and will ensure compatibility and hardware acquisition for SB going into the future.

Don't all controller cards/chips run gcode natively?
Doesn't every line of SB code have to be transcoded before execution?
Doesn't this slow down the code reading ability?
Isn't this even more exacerbated during arc and circles due to the mismatch between SB3's angular coordinate system and that of the Cartesian, which these chips run natively?
If you weren't trying to accommodate an SB3 based operating front end, and just went all gcode wouldn't Fabmo be ready to run?
How many years are you going to keep trying this before reality sets in? The whole world runs Gcode. What in the heck makes you thing something less than that is better?

SB3 as a simpler interface? In principal, and since I have heard ALL the ideas behind the mission statement for SB#'s development, I would propose the following for discussion:

That replacing G1 with MX, MY, MZ, MA, MB, MC, M2, M3, M4, and M5 is NOT simpler
That replacing G0 with JX, JY, JZ, JA, JB, JC, J2, J3, J4 and J5 is NOT simpler
That G1 X10 Y21.675 Z 3.5 B270 is MUCH easier to read than M5,10,21.675,3.5,,270
That G1 X10 Y21.675 Z 3.5 B270 is 10 times easier to type in than M5,10,21.675,3.5,,270
That having at least 3 versions of arc commands that only operate in the XY plane that cannot accept posted depth change is NOT simpler and wont allow action in the horizontal (G18 or G19) planes.
That most gcode controller sets have embedded command and canned actions that already support parsing input and output status and in some, maybe even most, don't require machine action to be halted to execute. The stuff you guys have been fighting is built in to the others!
That not having an absolute or table (G53) coordinate system is a serious detriment and you shouldn't be allowed to put out an ATC until its there!
That not having Absolute/Relative toggling without halting motion is a detriment.
Even if SB3 was simpler, having thousands of "cnc operators" that couldn't get a job due to not knowing one line of code is not "better" and is an unintended consequence as a contradiction to the mission statement.
In most "job shops" with numerous machines, the ShopBot is assumed to have "foreign code" by seasoned operators.
Most folks that have learned more than 1 control will vote SB3 as the harder of the 2 to learn.


The list goes on.... and on.... and on. If you have gcode experience you know. Maybe not so true 10-12 years ago, but in todays world the tools the SB3 users have in the box are much less in number than those that run most other controllers. And with perception being reality, in the CNC machining world, SB3 to Gcode is looked at like Pig Latin to English. No one is typing these commands any more!

Stop worrying about the "old familiar 2 button SB3 commands" The world is using screen buttons. Very few if any require any keyboard (MDI) input of any kind. SB3 control requires more keyboard input, more clicks to get a jog panel operational and more steps to accomplish most tasks than most any other control out there.

And lets not forget the process of starting the spindle.... Key switch on, press green button, press enter. And if that not enough lets listen to a couple seconds of woooah, woooah woooah before the machine actually does something. Its called "Cycle start" It means the operator is clear from the machine and actually is intelligent enough to command the machine to start running. With one button press.

Please understand I an not trying to TELL you these things. Remember the fake reference to Missouri? I am here to show you.

I will be bringing a small format (tabletop) machine to McGrew's. in a couple weeks. ShopBot is sending a DT model. Lets put them side by side with the same files. And being a Northern Michigan redneck, lets hook them up back to back with a chain on the gantry and have a "pulling" contest!! Just kidding about that part.

Seriously, it would give you a chance to see how a 24 by 36 machine with a cast iron frame, 650 ozin closed loop motors on 5mm ballscrews, with a 3hp spindle running on a $350 DIY controller (that didn't exist a year ago) stacks up to your stuff at 60% of the DTMax price point. Like I said, here to show you.

[Brady Watson]

Ill add one more to Gary's list:

Get rid of the need to press 'k' or 'SK' to get into keypad mode. On nearly all other controllers, you just press the arrow keys PgUp/Dn and it moves. End of story.

-B

[coryatjohn]

It will be interesting to see the shootout at McGrew's. Gonna be there.

[ryansturmer]

Gary, thank you for your comments as well. Brady, I'm going to table your request about SK - I don't want this to become a ShopBot software feature request thread. It would become very long indeed! Your suggestion has been noted.

1. Don't all controller cards/chips run gcode natively?
2. Doesn't every line of SB code have to be transcoded before execution?
3. Doesn't this slow down the code reading ability?
4. Isn't this even more exacerbated during arc and circles due to the mismatch between SB3's angular coordinate system and that of the Cartesian, which these chips run natively?
5. If you weren't trying to accommodate an SB3 based operating front end, and just went all gcode wouldn't Fabmo be ready to run?
6. How many years are you going to keep trying this before reality sets in? The whole world runs Gcode. What in the heck makes you thing something less than that is better?

1. No, (again with the cavalier use of "all") but FabMo, like many of its competitors, runs G-code natively.
2. Each line of SBP code must be transcoded before it executes, but not all lines have to be transcoded before any execute. Does that make sense?
3. Transcoding takes nonzero time, but not enough time that it needs to have any impact on tool performance. Ideal transcoding time is not significant at all on the time scale of the tools motion, at any practical speed.
4. No, even for arcs and circles, translating doesn't take significant time. You're misusing the word "chips" here, leading me think you may not have a complete understanding of all of the hardware/firmware pieces at work, in ours or our competitors controllers. There isn't some kind of hardware-native "g-code chip" at the heart of any of these machines. Like any other controller, ours is just a little computer that takes instructions in a text format, and interprets it to generate a motion plan, which it then executes in real-time. The time it takes to do the interpreting really isn't significant enough to be considered in the grand scheme of the tools performance, so fussing over how long it takes to convert angles and such really isn't relevant.
5. No, there are plenty of other reasons that writing a complex piece of software takes nonzero time.
6. Again, our controller runs g-code natively. We have a great many customers that use OpenSBP, and support for it is easy to include too, so why not? We need a language to perform our automation in, and that one is familiar to us and to our customers, and at least has the control structures (in spite of its faults) to support those activities.

That replacing G1 with MX, MY, MZ, MA, MB, MC, M2, M3, M4, and M5 is NOT simpler
That replacing G0 with JX, JY, JZ, JA, JB, JC, J2, J3, J4 and J5 is NOT simpler
That G1 X10 Y21.675 Z 3.5 B270 is MUCH easier to read than M5,10,21.675,3.5,,270
That G1 X10 Y21.675 Z 3.5 B270 is 10 times easier to type in than M5,10,21.675,3.5,,270
That having at least 3 versions of arc commands that only operate in the XY plane that cannot accept posted depth change is NOT simpler and wont allow action in the horizontal (G18 or G19) planes.

Agree on all counts. I may not have made that clear enough in my too-long post above.

That most gcode controller sets have embedded command and canned actions that already support parsing input and output status and in some, maybe even most, don't require machine action to be halted to execute. The stuff you guys have been fighting is built in to the others!

Your perspective here is one of a customer of a controller, which makes sense, because that's what you are, but as the designer of the controller, this is something that we have to think about and work out. Those canned routines are included in the controller, but they're not magic - developers had to write, debug, and test them. We are those developers in this case, and these are exactly the considerations that need to be made. The fact that we are exposing you to our thinking as we make those design decisions is a cultural choice that we make, partly out of courtesy to you our customer and contributor, but mostly out of a belief that being open and transparent about our process and collaborating with you in these fun public discussions improves outcomes for you and all our customers.

That not having an absolute or table (G53) coordinate system is a serious detriment and you shouldn't be allowed to put out an ATC until its there!

Absolutely agree. FabMo has more robust support for coordinate systems, using G53-59, and correspondent structures in the OpenSBP language as well. Indeed, the backport of coordinate systems to the OpenSBP language was done exactly because doing an ATC is a nightmare without it. The ATC we've run here on FabMo works just this way.

That not having Absolute/Relative toggling without halting motion is a detriment.

Agree, fixed in FabMo already. Switch back and forth all you like, in either language.

Even if SB3 was simpler, having thousands of "cnc operators" that couldn't get a job due to not knowing one line of code is not "better" and is an unintended consequence as a contradiction to the mission statement.
In most "job shops" with numerous machines, the ShopBot is assumed to have "foreign code" by seasoned operators.
Most folks that have learned more than 1 control will vote SB3 as the harder of the 2 to learn.

That's the thing about unintended consequences is that they're unintended! All we can do is forge ahead. I believe you when you say that folks who've learned more than one language find SBP to be harder. I could actually go on and on about computer and machine language design, which is actually one of my favorite topics, but I don't want to run aground of the 10,000 character limit on this forum a second time today!

[Gary Campbell]

Thanks Ryan...
a couple clarifications if you would.
A bit ambiguous, (or I'm a dunce today):

1:

No, (again with the cavalier use of "all") but FabMo, like many of its competitors, runs G-code natively.

So which is it?
2: Perfect sense
3, 4, 5: You are correct, I may not completely understand what you are doing with the Fabmo. But I do understand what others have explained to me is going on with theirs. That said, having had a Fabmo in my shop and having the chance to run SBP thru it, and Gcode thru it, and have the same files run on 2 other controllers, I can say that the "non zero time" (as you call it) longer that the SBP files took, when they didn't puke, was double digit percentages over the gcode version. Neither were as smooth, nor a quick as the other controllers, but gcode was only slower by a sub 4% amount. Both can be explained by differences in acceleration curves.

Last question on Fabmo, forever I promise: Going forward, do you plan on the data connection between the Fabmo and the controller card to remain usb as it was on the one I tested, then controller plugs into IO board? This is in comparison to BBG units I have tested that simply plug into an IO board


I do have another, possibly related item related to 4th axis velocity matching. Given a 2" diameter blank, with Zzero at axial centerline, and a starting position of X0, Y0, Z1, B0, and a feedrate of 2 ips XY and 115 */sec B (~surface equiv for 2" dia), from that position a command of X0, Y10, B720 is given. Without accounting for accel/decel, does that file execute in ~5 seconds, ~6.26 seconds, ~8 seconds or some other number when run on a ShopBot controller.?

Thanks for your time,