LOL... that sounds like a dream job for me; getting paid to tinker with 3D printers all day. *sigh*
Sometimes it is fun, sometimes it's a huge pile of frustration. My current job time is split between my new R&D work and my previous work on the production line. So I get to try and work on firmware and electronics. But I still spend more time basically being quality control and supervisor of the calibration department, where we spend too much time adjusting every printer manufactured to run optimally. It often gets frustrating when I'm fixing the same production mistakes over and over.
The other frustrating thing about it is that while I am running around helping keep things working I get all these big ideas of cool things we could design into new printer models, or new features we could put into the firmware, but we just don't have the time and people to work on all of these grand ideas. We do have some interesting things in the pipline though...
I also have this constant feeling that since I have access to all the 3D printing capacity I could want that I really should be thinking of things to print as much as possible. 
And if Marlin is any indication of even the neighborhood of the state of the art, I'd be worried that your Kung-Fu is too fresh, not too old.
I think that the current 3D printer industry is based off hobby guys with their Arduino based boards is what made the whole thing possible to get going. It didn't take a huge amount of sofware development skills to get the first machines working. But at the same time I think it might be an anchor slowing the development down as well. Take what I was previously talking about as an example. I had a situation where I wanted to hook up an in circuit emulator to the controller, load up the code, and when it did something we were interested in, stop the code and step through it to see what was going on. But I don't think anyone in the whole history of Marlin has ever actually debugged the code with an emulator and debugger software. Yet I learned that stuff back in the mid 1990's at my first job out of college at an electric fork lift company. Back then the emulator was a big pod you had to plug into a socket in place of the processor and it cost $20000 instead of a $160 Atmel-ICE pod, and I worried every time I used it that I would somehow blow it up, but I could debug code better then than what I can do now. The whole Arduino community has never had the "luxury" of being able to debug code with advanced tools. The best debugging you could do was to litter serial print commands of stuff you want to monitor throughout your code. But there is a "release candidate" 2.0 version of the Arduino IDE available now that seems to be based on VSCode and has debugging capability included so maybe that is changing...
As for McBryce's 32-bit/Trinamic board... I'd guess his is one of the many that came with the drivers soldered in; I'm pretty sure he's savvy enuf to know the Trinamic drivers are platform-agnostic. 
That said... I imagine that if he wants to enable a bunch of features along with managing those drivers in the firmware, he may very well need the 32-bit processor to do it all. Especially if he's using a touchscreen panel.
I am just getting into the Marlin stuff so I don't know if there are features in the mainline Marlin code that we aren't using at Lulzbot, that if enabled would be too much for the 8-bit boards. Could be, but one interesting thing is that a lot of the touchscreen panels, including the ones we use at Lulzbot, have a secondary processor right on the LCD. So the main board running Marlin isn't pushing pixels directly to the LCD constantly. Instead it sends higher level GUI commands to the LCD to draw buttons and display text and stuff, and the chip on the LCD handles that, and sends back coordinates of touches on the screen. So having the high res touch screen probably doesn't add much overhead over the older style "glcd" that most printers use, including the non-touchscreen Lulzbot models. We even use a touchscreen on the Lulzbot Bio printer that runs the same 8-bit controller as the Lulzbot Mini 2 and Sidekick printers.
As opposed to tinkering on printer-printers all day... which I've done, and is a complete shithole deadend job... 
I've had a couple times when I told people I work at a 3D printer company, they say something like "so you can fix my laser printer then?" and I had to explain the difference. I didn't admit that I could still possibly fix their laser printer even though they have little to do with 3D printers. 
LOL... That still sounds like it'd be the most fun I've had in the last couple decades. I really enjoyed being the
missing link between the big brains in the ivory tower and the grunts down on the production floor. I got to do both; document the everliving fuck out of stuff, and get my hands dirty figuring out how it all got
made.
I'm a mechanic in the old sense of the word: someone who works with machines and keeps them working. It was once a honorable profession; now it is synonymous with "third-rate villain" in every b-grade slice of life movie on TV and movies. I enjoy the problem-solving and redesign aspects, and having that mixed in with mundane maintenance work and documentation was all of what I loved about my first gigs and my first employment right out of school with my little "Nirvana-Corp".
There's a lot of truth in that; I've been involved with the development of the flight controllers, ESCs and motors used in hobbyist-level drones and UAVs since the days when you literally built them from a Arduino and a sensor shield. It was a lot of fun, until the big-business aspect and the FAA got involved. Also a lot of sad stories, and infighting that destroyed some truly innovative stuff. We had STM32-based FCs more than a decade ago; one of the first was OpenPilot (Now called LibrePilot; OpenPilot has since been trademarked as a self-driving car project) and it was infighting over the direction it would take and a couple opportunists doing the whole
"You stood on the shoulders of geniuses to accomplish something as fast as you could, and before you even knew what you had, you patented it, and packaged it, and slapped it on a plastic lunchbox, and now you're selling it..." thing to bring it all crashing down.
Sadly, I see a lot of the same strife and infighting going on with hobbyist-level 3DP, and as with FOSS in general. There's always someone looking for the chance to snurch something decent made with the most altruistic intent and bastardize it for profit.
Ehhhh... it's the whole thing. Once you start talking to the thing via serial while it's printing, timing becomes an issue and you can make the thing choke, fucking up a print. IME, the more features you're running, the more critical it becomes and the likelier it is you'll bork your prints.
Yeah, I'm aware. I dove down that rabbithole years ago with my Diggro Alpha; it uses the same touchscreen control setup as the Wanhao D9. The TS is a little proprietary-processor ARM PC (with its own FW and menu/image library) that communicates with the 3DP controller via serial. All the GUI is handled by a
DWIN T5 Dual-core, 64-bit processor with 1GB flash, IIRC. Kindof ironic having all that power to essentially act as flagman to a 8-bit processor doing the actual work.
For those playing along at home, here's a much better teardown of how it all works than I can explain:
https://bleughbleugh.wordpress.com/2018/07/11/wanhao-duplicator-9-d9-technical-stuff-part-deux-the-lcd-part-number/#more-223mnem
-group-therapy-thread/?action=dlattach;attach=900426;image)
Home
Help
Search
Login
Register
