Page 5 of 11 FirstFirst ... 34567 ... LastLast
Results 41 to 50 of 107

Thread: Post Processor Modification

  1. #41
    Join Date
    Apr 2018
    Location
    Durham, NC
    Posts
    7

    Default

    I'm glad this topic is winding down, just for the sake of how long it takes to reply! I have to say how grateful I am for you guys to taking the time out to post your thoughtful comments. No matter how you come across, writing this stuff up takes a lot of time, and I have to appreciate someone who puts in that amount of work.

    For final clarification.

    1. Do all motion controllers run g-code "natively"? No that's ridiculous. Do most motion controllers aimed at the CNC router market run g-code natively? Yes. What does the FabMo controller run? At the lowest level at which it is interpreting human-understandable code, it's g-code, similar to competing controllers.

    3,4,5. It's highly probable that you were running some or all of the following in your shop: 1) An old version of FabMo 2) An un-tuned or inadequately adjusted system 3) Prototype hardware. Earlier versions of the software did exhibit a noticeable delay transcoding SBP to g-code, but this delay was not innate to the process of transcoding, it was simply the result of a poorly structured runtime layer that was wasting a lot of time. The delay essentially existed for a silly reason that has now been resolved. There is still a small delay associated with parsing for very large files in FabMo 1.6.x, but that delay is also for a silly reason and will be gone entirely in 1.7.0

    For the foreseeable future, the link between the realtime component and the SBC will continue to be USB. Before you cringe at that, know that on the current and future versions of the physical hardware that doesn't mean a USB cable and connectors - it's all on one board, with the USB link being properly shielded and matched, carried over properly balanced, impedance controlled connections between the two processors. It is is also a "real" USB phy, and not the USB->Serial type of jiggerypokery that is seen in ShopBot legacy and some competing controllers, so it is not susceptible to the dreaded "connection issues" that are so prevalent in certain circumstances. There are actually a lot of advantages to using full speed USB here. Bandwidth and robustness being some of them.

    I don't know the answer to your rotary axis question for SB3, but for FabMo, the answer is going to depend on the kinematics that are defined for the machine. For now, with the default kinematics that ship, assuming you don't hit any speed limits and you neglect accelerations, that move would execute in ~6.26sec. The reason for this is because if you go by the "NIST Standard" g-code (which is the closest thing g-code has to a standard) the way coordinated moves are computed that include rotary axes is to compute the vectored distance of the rotary axes by themselves, and then to run the linear part of the move at the speed necessary to execute the move in that amount of time.

    Re: Shootout.

    We're bringing a tool of course, but if you think you're going to "show me" how much more horsepower a 3HP spindle has than a 1HP spindle - I'll tell you. It's 2 more. If the aim is to show me that there are competitors in the marketplace for our products - Surely you know that we realize that?

    If you want to have a race-to-the-bottom about pricing on essentially comparable tools, I invite you to sell me that tool you plan to bring at 60% of what a MAX costs, including CAM software. Then support it forever, with free replacement on defective parts, provide me a cost-effective upgrade path when you come up with something new (or find something new that someone else made, in your case), offer training at an unbeatable cost, and run a community forum at your own expense so that people can communicate, collaborate, and complain. Surely you're factoring those costs into your 60% of our price point on the tool?

  2. #42
    Join Date
    Aug 2008
    Location
    Plympton MA
    Posts
    558

    Default

    Quote Originally Posted by ryansturmer View Post
    I'm glad this topic is winding down, just for the sake of how long it takes to reply!
    I bought my PRS Alpha 60x96 10 years ago. I can't express the amount of time, effort and work that's been needed to get my machine up to the point where it was able to cut satisfactorily and reliably in a production environment. The full sized machines still appear to remain a hobbiest machine, with some beefed up components.

    Don't get me wrong the machine was the right choice for me at the time (and owes me nothing), but I would no sooner recommend it today to someone in my situation, based on the other machines available at the same pricepoint. I'm not clear on why this doesn't appear to be a concern to the those at SB. (No need to respond, just needed to say it.)
    Nat Wheatley
    Plymouth Custom Closets
    www.plymouthcustomclosets.com

  3. #43
    Join Date
    Apr 2018
    Location
    Durham, NC
    Posts
    7

    Default

    Nat,

    We appreciate your business - the tools have come a long way in ten years, and we're working on them still. Many (most?) of our current efforts are aimed at making changes across the board that improve the experience of customers specifically in production environments. The experience of getting a new gantry tool today isn't anything like it was when you bought in ten years ago, and I expect the experience in another year or so to be even further changed (for the better!) Thank you for hanging with us, and for your feedback.

  4. #44
    Join Date
    Apr 2018
    Location
    Durham, NC
    Posts
    7

    Default

    Gary,

    I misspoke above - had it backwards. For the rotary axis move, what it should do is compute the time for the linear traverse, and run the rotary, vectored, in inverse time mode, essentially to match that speed. So if it's a 10 inch traverse in the Y, it's going to be a 5 second move.

  5. #45
    Join Date
    May 2014
    Location
    MA
    Posts
    610

    Default

    Brady, I wanted to respond to you on a couple of points... For some background on me:

    I was/am an early tester of FabMo. I also have a "job shop" where I build all kinds of odd things. Everything I do is different. I also run a small farm of 3D printers, I've built my own CNC (albeit a crappy one) and I do some rudimentary coding. As Gary would say, I've got a "few pragmatic bones" in me so not everything I do is just for fooling around. I make money with my tools and they need to perform fast and reliably. I suppose I sit somewhere in between being a programmer and a maker... Right now I run a 4x8 PRS "High Voltage" and a FabMo Handibot weekly, along with some other CNC and digital fabrication tools.

    I'm going to argue FOR FabMo here, just to bring another perspective to the table. Let me preface this argument with saying that if FabMo were nearly bug free and ready for a full size tool. The reality right now is that it's not quite there... But let's imagine that it is:

    Computers suck, and they're all different and perform differently. I think we can take that as read as it's been discussed over and over here. The 3D printer market realized this a long time ago.. You do your slicing on a computer, you get your GCode (or X3g or .Makerbot file) and bring it over to your 3D printer either by way of USB, Wifi, or SD card and you put it in the printer. All of the processing of the job is done on the 3D printer. It ingests all of the movement code and just runs. You can turn your computer off at that point. This is done to 100% eliminate the need for a computer to live stream data to the printer. This means that they all run the same way, firmware can be upgraded across 1000s of machines, and diagnosis elminimates the PC altogether.

    FabMo works this way as I'm sure you know. The UI, the motion control, and all of your scripts and customizations are stored on the tool itself. This means that it fires up and works the same way every time. It doesn't matter if you have a 10k gaming machine, or a $100 dollar Chromebook. As long as you can connect via a browser and send GCode over, you're good to go. I love this feature, I use my expensive Mac for design work, I load GCode to my Handibot, and then I use a cheap old phone that I knock around the shop for zeroing and job management. It's awesome. What's also awesome about this is that you never have to upgrade if you don't want to. FabMo can run totally offline, and if you never want to update/upgrade it because "it just works" you never have to. FabMo isn't dependant on internet.

    I know there are a lot of shops out there that have PCs that aren't connected to the internet, or are running REALLY old browsers. Being that you can connect to FabMo with only a browser, the upgrade path is really easy. Just get a modern browser (if you even need one). All you have to do is download Chrome. You can even buy a cheap $50 dollar Pi and strap it to the back of a monitor and have a really snappy interface (granted it won't run Aspire). Chromebooks are also dirt cheap now, are super reliable and fast.

    As far as the open source thing... I don't think it's a headache at all. At a minimum it's great for people that want to see how something works, and how active development is. Open source doesn't mean a free for all, ultimately ShopBot gets to decide what user submitted code/enhancements included in the software. If you, or anyone else wanted to fork the code for your own purposes, you're free to do that. If you've followed at all what Ultimaker has done with the open source project Cura you'll see how much benefit open source can have to stuff like this.

    As far as the GCode/OpenSBP thing... As I mentioned earlier I'm a bit of a hack coder. Back in the day I was pretty good at BASIC so OpenSBP is reasonably easy for me to learn. The language for me is a bit obtuse at times, but I can get it to do just about whatever I want. The reality as you've pointed out is that it's not ubiquitous, so it's foreign to those outside fo the SB world. I can't disagree there. I do however rely on it's ability to do a lot of custom scripting. I believe that a lot of what I do couldn't be accomplished with pure GCode. This is likely why other controllers I've seen still do rely on some macros and other external support to do machine tasks like zeroing, calibration, etc.

    FabMo let's you use Javascript to build macros for the machine. Javascript is one of the most popular languages out there. It's reasonably easy to learn, and there are resources everywhere for it. I believe this is the right choice for a language moving forward.

    Also, most people I see don't care what code the machine runs. They're using 3D print slicers, or CAM software. They rarely if ever even look at the code. The reality that I see is that we're moving farther and farther away from even needing to think about code. Just look at a lot of the new tools that are coming on to the market, almost none of them require direct interaction with any code.

    So to put this all together: I'm excited about having a totally self contained control unit for my ShopBot. I'm also excited that I can customize it any way that I want using a really popular language. I'm excited for something that works exactly the same way, every time regardless of what computer I'm working from. I'm also excited for something that's built to run on a ubiquitous and well supported platform: a browser. These days the browser can do incredible things, to name a few: Fully functional CAD and CAM. We're heading to a future where a tool can be shipped that has every piece of software ready to run on it, rock solid reliable and ready to go out of the box. That's pretty awesome.

    The reality is that FabMo isn't ready for prime time, at least for me. It's had it's growing pains, bugs, and all the other stuff that a brand new hardware and software platform has. My biggest frustration is that it's not done yet. I really don't know how many people are working on FabMo, or what it would take to get it ready to go primetime, but if I was in charge that'd be a huge focus for me.

    Anyway, that's my 2 cents

  6. #46
    Join Date
    Apr 2018
    Location
    Durham, NC
    Posts
    7

    Default

    Thanks for your comments Eric - the upcoming release is much more polished, as we intend to move to larger tools. Unfortunately, in the run-up to that release, we've pulled away a bit on you and some of our lead adopters, owing to just being very short handed and busy pushing things across the finish line. We appreciate your participation and encouragement. Stay tuned - there are exciting things coming soon.

  7. #47
    Join Date
    Apr 2007
    Location
    Marquette, MI
    Posts
    3,388

    Default

    Ryan...
    In reverse order: Rotary
    If I can remember correctly (its been a while) your first answer is more likely to be correct. I think you explained it that way. I'm fairly certain SB3 worked that way also. Imagine if the rotary motion was 10 times that much.

    With a surface equivalent rotary feedrate, the rotary distance was longer, thereby determining the time for the motion. I am doing a rotary presentation at McGrew's and wanted to see which of those 3 groups SB's stuff fits into. Very few (unless using inverse time feedrates) will execute in the ~8 seconds which would adhere to the 2ips feedrate. The 5 second version actually results in ~3.15ips and the 6 second one ~2.67ips. As long as an operator knows what he is dealing with he can adjust accordingly. If I cant get it ahead of time, maybe Ryan will take a minute to run it before the show.

    RE: the shootout
    There aint one. Just some redneck humor. There was always a bunch of alcohol and even more stupid at every truck pulling match!

    That said, other than a forum, of course that all would be included, if not it would be at a 35% price point. As you mention there is no realistic comparison to be made between production type builds and one offs. I will take exception however, to your "(or find something new that someone else made, in your case)" comment by countering that I would be willing to bet that there are more components on my machines made from raw materials in my shop than are by SB employees in yours, across all lines. Handibot excluded. Digital fabrication and complete assembly. "Ready to run, right out of the box"

    RE: My Fabmo testing. All of what you say is most likely true, but in my defense I was simply running what I was provided. Comparisons to "known working" other controllers from low to high end, are just that comparisons. They were suggested by other testers. A am agnostic, I call em like I see em. I usually have at least a couple different controllers running at a given time.

    Last item on this topic forever: Your quote: "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." This is the phrase I want you to take away from this conversation. That is exactly what I want you to remember.

    This has been great, thanks for allowing me to participate, I think those that followed it have a much better sense of the direction for ShopBot in the future under your leadership. I know I do.
    Gary Campbell
    GCnC Control
    GCnC411(at)gmail(dot)com
    Servo Controller Upgrades
    http://www.youtube.com/user/Islaww1


    "We can not solve our problems with the same level of thinking that created them"
    Albert Einstein


  8. #48
    Join Date
    Apr 2007
    Location
    Marquette, MI
    Posts
    3,388

    Default Tick tock

    It has been 6 months since this thread was posted on and since it has had over 4100 views, I would assume that finding out what had actually been done would be of importance to those that have invested large amounts of time and dollars into their ShopBot products.

    It also has been 6 months since this was posted:
    Quote Originally Posted by tomhartnett View Post
    Stay tuned... (words engraved on my tombstone) - I do plan on remaining more active on here as I branch into videos/documentation for the future.
    Quote Originally Posted by tomhartnett View Post
    I do appreciate everyone sharing their thoughts.


    Since you mentioned sharing my thoughts....
    Tom was good to his word as in less than 30 days a number of "How To" videos were posted online and they have been viewed by hundreds of users. Kudos to you.

    That said, in these last 6 months, and specifically regarding his quote above, Tom has posted 34 times. 30 in the first 30 days on a number of helpful threads, 3 more times on 1 thread in the second 30 days, one post in July and nothing at all in the last 90 days. There seems to be a pattern developing, shall we get out the engraving chisels?

    There does not seem to be anything since April of 2016 posted on the ShopBot News page and I am sure that the items mentioned by Ryan and Tom would be important news to most anyone running a ShopBot controller and very important to those that have been longtime sufferers of the dreaded comm errors, it could be considered both proper and important if staff could jump in and update the community as to what progress had been made in these last 6 months.

    A report of what HAS been released and how it is working would be much more relevant than the empty claims of what is planned for the future that have been so prevalent over the last decade.
    Gary Campbell
    GCnC Control
    GCnC411(at)gmail(dot)com
    Servo Controller Upgrades
    http://www.youtube.com/user/Islaww1


    "We can not solve our problems with the same level of thinking that created them"
    Albert Einstein


  9. #49
    Join Date
    Mar 2017
    Posts
    94

    Default Civil dialog.

    Quote Originally Posted by Gary Campbell View Post
    It has been 6 months since this thread was posted on and since it has had over 4100 views, I would assume that finding out what had actually been done would be of importance to those that have invested large amounts of time and dollars into their ShopBot products.

    It also has been 6 months since this was posted:


    Since you mentioned sharing my thoughts....
    Tom was good to his word as in less than 30 days a number of "How To" videos were posted online and they have been viewed by hundreds of users. Kudos to you.

    That said, in these last 6 months, and specifically regarding his quote above, Tom has posted 34 times. 30 in the first 30 days on a number of helpful threads, 3 more times on 1 thread in the second 30 days, one post in July and nothing at all in the last 90 days. There seems to be a pattern developing, shall we get out the engraving chisels?

    There does not seem to be anything since April of 2016 posted on the ShopBot News page and I am sure that the items mentioned by Ryan and Tom would be important news to most anyone running a ShopBot controller and very important to those that have been longtime sufferers of the dreaded comm errors, it could be considered both proper and important if staff could jump in and update the community as to what progress had been made in these last 6 months.

    A report of what HAS been released and how it is working would be much more relevant than the empty claims of what is planned for the future that have been so prevalent over the last decade.





    I love civil dialog thanks all

  10. #50
    Join Date
    Dec 2008
    Location
    Diamond Lake, WA
    Posts
    1,746

    Default

    I'm a late comer to this discussion but would like to add my 2 cents to the discussion. I'm not nearly as versed in the hardware aspects of CNC's nor the inner workings of the CNC software. I do, however, come from a background of 23 years in the Coast Guard as an electronics technician working on a VERY wide variety of electronics. I also have 18 years experience as a software developer working in everything from machine code/assembly language up to modern languages like C/C++. I've done system level development (i.e. I/O controllers) as well as standalone applications (DOS, Windows, Unix), mainframe applications (IBM 360) and client/server (PC and Unix) applications. I am an Extra Class Amateur Radio operator thus understand the complexities of building, maintaining and troubleshooting communications systems.

    With that said, one of the things I've experienced in my nearly 10 years of using a ShopBot CNC is the lack of testing of the control software before releasing it. I was onboard as Shopbot went thru the 3.2 to 3.6 versions of SB3. I stopped at 3.6.44 because I was tired of beta testing "released" software. The frequency of releases of the 3.6 versions of the software showed how little in house testing was done prior to releasing it to the public. The adage of having the user community help us uncover bugs is not something that a company should EVER do. That's like Pelosi saying we have to pass obamacare so we can see what's in it. That's pure ****. A user should expect the software to be thoroughly debugged prior to making it available to the public. I spent many weekends and weeknights, while SB support was closed, trying to troubleshoot problems (production STOPS) only to find out it was a bug in the software once support saw my feedback. That is UNACCEPTABLE!!!!

    For those that use a CNC to make a living, running beta software is not an option. That is why I have NOT upgraded to 3.8. I don't have the time to spend trying to figure out why things aren't working with the latest, and greatest, release of the software. I use ShopBot Link A LOT in my business. I cut thousands of sheets of plywood a year and can't afford my machine to be down. Now here's an interesting twist on several of the previous posts debating SBP versus GCode. SBLink runs GCode thru the SB3 3.6 software. It is fast and it is reliable. In the years I've been running it (9), the number of problems I've had can be counted on 1 hand. On the other hand, when I create a cutting model with Aspire outputting SB code, I have regular COMS issues. The Aspire PP for ShopBot outputs SBP code, not GCode. So, it seems to me that maybe there is a problem with the translation of SB code to perform cutting operations. 3D cutting operations are the most notorious for having these problems. The constant 3-axis movements are a bit much for SBP? Or am I reading into something that is simply not there?

    So to reiterate some previous statements of all/most people want reliability above all else? I would say, for those that make a living with their machines reliability is PRIORITY 1!! For those that tinker with their machines or do little bits of commission work here and there, cool, fancy features might be very important to them as every minute their machine is down is not costing them money. I can say, if I had the money, I'd probably sell my SB and purchase a machine that could cut faster and more reliably. Maybe I wouldn't have to do the 2-pass climb/1-pass conventional cut dance (1/3 more time to cut a sheet of plywood) required on a Shopbot to compensate for machine flex.
    Don
    Diamond Lake Custom Woodworks, LLC
    www.dlwoodworks.com
    ***********************************
    Life is not a journey to the grave with the intention of arriving safely in one pretty and well preserved piece; But to skid in broadside, thoroughly used up, worn out, bank accounts empty, credit cards maxed out, defiantly shouting "Geronimo"!

    If you make something idiot proof, all they do is create a better idiot.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •