Page 5 of 5 FirstFirst ... 345
Results 41 to 47 of 47

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
    554

    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
    295

    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,321

    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
    CNC Training & Technology
    GCnC411(at)gmail(dot)com
    Control & ATC Retrofits

    http://www.youtube.com/user/Islaww1


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


Posting Permissions

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