There won’t be any porting of AVR to more modern platforms. It’s going to be all ground up build to be able to fully exploit the capabilities of the newer parts. Full time likely a year, potentially a couple of years before it’s flushed out enough for end user types. It took Autodesk a few years to get the Spark firmware portion of Ember to a place where it could be launched.
Abstracting the AVR from the rest of the controller is something other machine tool companies have. The math on the delta bots is said to be pushing the limits of the AVR as a motion controller much in the same way a full 5 axis machine does.
Modern microprocessors, RTOS and programming implementations should do away with needing a separate processor for machine control and still provide functionality for other interface and communication elements.
We looked at the ember firmware last week… They have partially used Tinyg. That is likely what we will do. They have a cpu for the display and another in there too- cant remember what it’s for- wifi, if memory serves
Alden, who leads the Tinyg development is a firm believer that the motion control should be kept separate from the UI / server and wifi. I tend to agree. The esp8622 and its successor esp32 offer an all-in-one solution for wifi and light weight http stack for communication. The esp32 has enough to serve up a small UI and maybe even a screen. Keeping the motion control separate makes sense for a couple of reasons. One is to keep the code in logical parts where troubleshooting is easy and it’s nice and clean, not entangled with each other. Another reason we want to keep the wifi separate is b/c iot is a Wild West situation right now. Intel, TI, espressif, etc are all battling for the high ground. Choosing the wrong horse would lead to slowdowns. FCC is also a concern, and while a wifi dongle on a Linux box is tempting, we wanted to explore something cheaper and a bit more powerful. It looks like the io in the esp32 may fit the bill for a screen if we need. And we are adding local storage too.
You are right about the deltas. Since I don’t have a dog in that hunt, I don’t need to design for it. I’m glad too, since it brings a new set of problems.
Adding a camera brings more overhead but would be nice. If we ever do any type of image processing, thAt will have to use a much more robust system. Right now, inexpensive printers don’t come with a camera. All of that is getting cheaper so I’m sure we will want to get there eventually
What you really want is a quadcore tablet soc with a load of gpio, you can now buy a quadcore arm tablet with an 7inch touch display, wifi, usb, bluetooth, 2 cameras 1g ram and 16g flash for about $50 OEM, having multiple cores is almist the same as having multiple processors, you can run the ui/display etc with afinity on one core, run the motion on another, i/o on another. There are octacore soc’s around now that could run motion of each axis on a seperate core if needed, like the PRU’s on tbe beaglebone.
Its unfortunate that most tablet soc’s are weak on available gpio. However another approach is to distribute the electronics, put the axis low level driver electronics, limit switch sensors and motor temp sensors on a board on the back of the motor itself and hook it up with a fast serial bus. A local processor would offload the lowlevel driving from tne main board. In that situation the core pricessor does not need a lot of direct gpio, just a lot of bandwidth on its serial buses.
This is essentialy the architecture that cars use now, where they have switched from a single central processor with remote sensors and actuators, to a distributed CANBUS based internal network.
@Brook_Drumm I’ve noticed in a few places that you refer to the LCD. Will the new firmware still operate a character LCD plugged into EXP2? I print via OctoPi while doing other things with my PC, so It’s nice to be able to look over to my LCD and see current temperatures and the print status without having to log into the Pi.
BTW, I am looking forward to the new firmware. A clean, well commented, well thought out software written with specific goals in mind will be a welcome change. I’ll be eager to look through it once you’ve released it to the community.
A trend in automation that requires an RTOS is to virtualize the RTOS and run it on the same silicon as the main processor. There are available virtualized RTOS packages as well as at least one container based.
Abstracting some of the control to boards at the motor using CAN would be going backwards at this point. CAN is pretty long in the tooth and in vehicle apps it’s approaching or exceeding capacity limits in many apps. That’s one reason for implementing CAN gateways. The replacement will likely be some sort of industrial ethernet.
Distributing the motion control to the motors for a printer is adding unnecessary costs. It’s one thing with it’s a sub system of a product costing tens of thousands of dollars that are produced in the millions. It’s another for a product in a very narrow market that costs hundreds of dollars and ships thousands of unit. Each board requires PCB fab, PCBA, testing, implementation. For something this small in the big picture of technology isn’t that demanding by abstracting control to the motor you are adding cost with no appreciable benefit.
Computing requirements are no longer being abstracted in physical hardware but in virtual environments on a single part.
When I say LCD, I’m referring to what a lot of repraps use. I’m not sure we will support it yet. It would not be required for our software, but I realize some people like it.
It kind of seems like encouraging newbies to fiddle w temps is a bad idea. I know experienced people like fine tuning but I’ve never ever watched the pot boil. I stick an Sd card in and walk away. My decisions are definitely informed by my style of printing. I tend to go low maintenance and no fiddling. It scales well to think about less buttons and gizmos – when I think about offering customer support to newbies that is. I just want the machines to print… Pass or fail. May not be your cup of tea.
Obviously, open source code makes many things possible
As a side note: we will be experimenting with usteppers- they add a closed loop system to steppers. They say it will be open source. We are already drawing up equivalent pcbs. While open lop works pretty good, closed loop does add another level of protection for skipped steps. I think the drivers are onboard and at the motors if memory serves.
I rarely use my LCD for input, more of a quick status check (view temps, current Z height) I’d be OK with just status information on the LCD with no input. That should cut the space and code requirements for the LCD down considerably.
On another note, what environment is the code being written in? Arduino, GCC, AVR Studio?
Positional feedback is something that would be a welcome addition to the 3D printing world. I’m not familiar with the ustepper terminology and didn’t see anything with a quick google search.
Most feedback systems I know of either use a gray scale encoder or some other encoder on the motor itself for rotary feedback, or if more accuracy is needed, a linear scale on the axis itself.
Having the feedback would be nice because if the machine didn’t position where it was expected to go, an error could be generated to halt the print potentially saving the big squirrels nest probably all of us have seen at some given time.
I would imagine that the handling of all that inupt would eat up a considerable amount of processor usage. Is that what the pcb you are speaking of handles so the Printrboard can simply poll it for positional status as needed?
Ustepper is a Kickstarter project that will ship soon.
“uStepper is an ultra-compact Arduino compatible board, with integrated stepper driver and 12-bit rotary encoder, enabling the uStepper to be mounted directly on the back of your Nema 17 size stepper motor. This makes it possible to develop applications using a stepper motor, without the need for long and messy wiring to an external Arduino/stepper shield. Furthermore the 12-bit rotary encoder ensures that the absolute position of the motor shaft can be tracked, enabling the uStepper to detect any loss of steps.”
@Rick_Shear Implementing a closed loop stepper motor system is going to cost more than the entry level printer. You see it on higher end CNC machines with a cost for the closed loop system several times more than an open loop system. It’s something that’s not going to be cost effective for low and mid level machines.
Total or per axis? Either way that’s still far less than current systems sell for. The cheap import motors only are retail US$70-80 for a motor and encoder.
I think you may be a bit too optimistic at that price point for a quality closed loop system. No one else to my knowledge has done it. You’d be the first.
@dstevens_lv I understand what you are saying about closed loop systems on CNC machines. I ran CNC machines for many years, Programmed them via with MasterCAM for several more, and as of late, have helped trouble shoot and repair the machines alongside the owner of the shop I work at.
As you said, those systems are VERY expensive. With rotary encoders on most of our equipment having a glass scale with either 18K or 36K lines per rev. resolution.
However, I don’t think that is anywhere near the level of accuracy that is being looked into for the tabletop printer. The axis on these printers have a maximum resolution at 16X microstepping of 3200 steps per rev. So if you wanted a little overhead, the 4096 /rev resolution on the ustepper board @Brook_Drumm is talking about should suffice.
It’s interesting to see how well the magnetic pickup for rotary encoding will hold up over the long run attached to a vibrating motor, but it’s a start at least.
With this hardware solution, it does seem that firmware changes to implement it would be the next biggest hurdle.
Brook, If your ever in Sac. Let me be the first one to buy you a beer! Looking at your thoughtful responces and the patience needed to create them is heart warming. You really care about what your building and the community around it.
You have really got me interested in the improvements you have made to Marlin. For the last few weeks. I have been studying the Printout version Marlin published in Github in disbelief. BlinkM! need I say more? Is there a link to this newest Printrbot version of Marlin? I would really enjoy seeing what sanity the PB team has brought to it. Also if I can offer my services as a tester of the new firmware. Keep me in mind.
Jeffrey: thanks! We are still in proof of concept / discovery mode. I am finalizing this year’s road map and the move to ARM is likely… Now to figure out how Marlin guys in.
My programmer has his hands full w an LCD/ wireless combo now so Marlin rewrite is on hold- it’s not done and like any good programmer, documentation isn’t a feature, it’s a requirement.
We have an aggressive schedule to keep so I am letting him take the time he needs to both correctly align to our deadlines and get it right.
Me opening my big mouth too soon is a problem, so I can’t promise when it’s all going to make it to github, but it will in due time
Its good to see that you and I are on the same page. Ive been looking into similar ideas. Off loading all the extras off the printrboard. (i.e. LCD, Wifi) So it can do what it does best print. And getting on the ARM train.
I found this group out of China that built a really great looking 3D print controller. But alas, I can be buying every new toy that I see.
Maybe you might want to check it out. The specs and the price are shocking. Possibly to good to be true. Also the firmware is available on Github. http://www.fastbot3d.com
Oh ya are ya going use an OLED those little guys are so cool?
Everything is in flux right now, so no details. And I will be silent on all of it until we have something to show. I just want to be respectful for the programmers involved and wait patiently it’s an exciting time!
it’s doable but the firmware work is the toughest part.