Quite timely…I have been looking at the different options for operating my XXL with a Pi 4 to get my MacBook out of the shop! Will defiantly give this a try this week.
Thanks for confirming that the build works for you. We didn’t do anything special for this build compared to the other desktop build so Carbide Motion still needs something close to a full HD monitor. If this ends up being a supported platform for us then I can see putting some time in to see if the UI can be scaled to work on the 7" touch screen (no idea if it’s worth the effort at this point).
That said, as much as I love the 7" screen, a 21" HD monitor is around $99, which isn’t much more than the 7" LCD and a case.
Much like the 7" screen, I love the idea of making the 3.5" work for CM (and your mockup). I don’t think we’re ready to go down that path yet because it woult take a lot of new code and work on the playform itself.
I’m not a Pi-pro, but I think the standard 32 bit OS should work. We did not compile it for 64-bit.
The core code for that has been removed by now, but I can see adding something around automation in the future.
And finally, I have no idea if the gamepad will work for jogging. We’ve been torture testing the basic machine functions here but we haven’t tried the gamepad yet. If you have any feedback, we’d appreciate it.
That makes sense, it all depends on the roadmap for this and where you all want to take it.
I’m working to change most of my machines in my house over to Linux, with my last dependency being Illustrator on my Mac, so this is definitely an awesome development.
I could see a good product fit for an add-on to the Pro maybe. You could use an “open build” type approach, a dedicated controller based off a SBC Linux computer, and a 7 inch touch screen though. One advantage to Carbide Motion 4 in it being an Electron app is that the UI elements were responsive and would scale to the size of the application window. I actually tested it on my Back7.co Raspberry Pi kit (https://back7.co/home/the-raspberry-pi-quick-kit), for something quick, dirty and portable.
It would probably be an edge case for the REST API for most people, I don’t see a lot of people needing it unless there was a great use case. Cost of support for something like that doesn’t necessarily make a lot of sense. It was a pretty fun hack though to do, with a test case of outputting the progress onto an RGB LED array I built, as well as putting specifics onto a Home Assistant dashboard. I can post a few pictures if you all are interested.
Thanks so much for taking time in answering everyone’s questions! I love the additional insight into your decision making processes.
Understandable that you’re not already making changes to support a plethora of screens and what not, you literally only ported it over to Pi 3 days ago it’s fine!
As I said I was looking at alternatives to this (Windows 10 tablet, small netbook) and then I saw this post posted elsewhere, perfect timing, might just get a higher res screen and have done with it, this is a great upgrade and I don’t want to wait
I’m not that familiar with Pi OS myself, let alone creating software, but in regards to the gamepad/joystick support, I don’t think you need to integrate/bake in gamepad support into the software itself, but instead implement keyboard hotkey/macros for the jog buttons as well as being able to click on them, X+ would be Right Arrow, Y- would be Up Arrow, Increment+ would be “+” ect ect
And there’s bound to be software for the Pi that takes a controller input and allows you to map the buttons to keyboard keys, that way you haven’t got to add gamepad support which may be more challenging, you can just add keyboard shortcuts in CM that we can use other software to map a controller button to each key
Just an idea
That was actually a problem for us. On some computers it scaled properly and others it flowed in strange ways. (We weren’t Electron though, we used the Qt control that embedded Chromium). We could never get the layout to be uniform between computers because because different computers implemented scaling and Hi-DPI/Retina slightly differently (from what we could tell). Also, we were never able to get the responsiveness for jogging, mainly keypresses and button-hold in a web view.
Support problems immediately went down when we switched to native.
I’m just sharing this as a little background for why we’ve changed the architecture. I don’t know if this was the only way to do it, only that it worked for us.
We already have the code in there from the desktop versions to use gamepads, I just don’t know how well it works on Linux. It’s great on Windows but doesn’t work on Mac.
Ah okay I wasn’t aware of that, got my Shapeoko a couple days ago so I’m new to this
Keep up the good work, this seems like an excellent community and I like that there’s continued efforts to improve the software and machines, makes me a confident and comfortable customer
Ah that makes total sense! I can only imagine what kind of impact support calls have, and the cost to do business. Pretty logical decision.
Are you all planning on sharing a public roadmap for CM & CC, or for Carbide3D in general? There are probably some sensitivities there given competition, but I’d love to see what developments like this you have planned down the road.
We probably won’t be publishing a roadmap. First, as you mentioned, we’ve had to deal with some blatant knockoffs, as well as other, more legitimate competion and we don’t want to show our hand too early.
Second, and more relevant to hardware, we’ll only announce new products when we’re ready to start production because that’s the first time we can be sure that a product will actually ship and be semi-confident about the timeline. We’ve continued to refine the process that we plan to use for future product releases over the past couple of months after taking in a lot of internal and extrenal feedback about the Shapeoko Pro launch.
Related to the Pi release in particular, we’re trying to see if this is a platform that we’d be able to support officially or if it needs to remain unsupported and just for fun. If it continues to be as good as it seems right now then we’ll have to sit down and come up with a real roadmap because there could be a lot of potential.
I agree on it being a possible great addition to the product line up. I tried a RPi3b+ for bCNC and UGS. But I’m crap at Linux and it was too much work for me to learn vs. using a Win10 tablet. If y’all had an all-in-one control computer that you could offer with the machine, a touch screen, and wireless jog pad, that would be awesome and be more competitive in the market.
That said, I fully admit I don’t know if an RPi based solution is the best.
We have a few options we’re testing here so we can publish a shopping list in the near future and explicit instructions to get it running.
would be interesting to publish a ready made “put on the SD card” image that just boots straight into CM and nothing else…
I’m sure a bunch of us linux folks here can help with getting something like that going
That’s what I need, like OctoPi.
would this ever be expanded to support stuff like analog sticks on logitech pads? having a variable speed jog based on stick position is probably an absurdly tall order, but man that’d be cool
guess that’s a reason to move to windows for my machine instead of a very old mac…
That’s probably the plan going forward. You “might” have specifically been talked about as someone we should talk to.
We run a fairly substantial machine shop by now and we tend to err on the side of trying to make Carbide 3D machines be an easier version of the industrial CNC machines that we have. Analog jogging somehow feels wrong to us, from both a functional and support point of view. (We could be completely wrong about that and we could warm up to the idea over time). We continue to try a bunch of UI changes for jogging so who knows where we end up.
@robgrz fair enough i guess, but im a dude with a basement and some tools that barely constitute a shop. i look at industrial cnc stuff on the internet and will never own or even touch any of it in my lifetime… getting the most out of a $30 gamepad in my workflow doesn’t feel as out of reach.
btw there is something slightly funky about this package, it pulls in a pile of development headers, which is highly unusual… I suspect a bug in the packaging
We use the following packages:
If I remember right, the last two are the same package for dev and release. We didn’t find a runtime-only version.
I shall poke around
building a script now that takes a raspbian image, adds carbide motion to it, removes a bunch of unneeded stuff (to get it smaller and just less problematic)…
(and will make CM start full screen on boot, but I’ve not added that bit quite yet, small steps)
We’d be eager to see what you come up with.
ok so… I have it booting straight into Carbide Motion… including skipping that setup app that asks for wifi/timezone/etc… (not 100% sure skipping that is the right thing but… clearly it’s possible)
The one glitch is that the application does not start up maximized, and specifying outside geometry (while Qt supports that) is messy due to all kinds of things like window borders etc.
I think the best thing would be if CM could call something like
relatively early on (potentially only on some command line option); that way the window will properly maximize, and not just be “bigger and mostly the whole screen”.
next step Auto mounting USB sticks, since obviously the user needs to get gcode to the system somehow and that’s the most obvious way