Looking for hardware to run g2core.
Reached the point where I need to choose hardware, and … there are many, many different alternatives that could work. Finding a sorting criteria is not an obvious exercise.
I like the hardware and software choices in the TinyG controller, though it is not so much meant for 3D printing. Advanced motion control is one of the things we are going to need to faster printing, and this pretty much looks like the best.
In fact, when betting on an open-source project, we are really betting on the folk behind the project. Reading the (scattered) bits of the folk behind TInyG and g2core, I like their choices - a lot.
Could get an Arduino Due, and some shield that supports four or more stepper-drivers, as that seems to be the original reference platform.
Could get a Printrboard G2, assuming @Brook_Drumm does not mind his board seeing use in other printers. From what he has said, that might not be an issue. The only problem(?) would appear to be that the use of 12V for driving steppers.
Could get a one of either the gQuintic or gQuadratic, though at present their existence is semi-mythical, despite slightly-fuzzy pictures on Flickr.
The Printrboard G2 really looks like my first choice, at this point.
Been meaning to try that. TinyG/G2 and MachineKit are really the only options using totally different acceleration control from Marlin/Smoothie/Repetier etc.
I have been waiting forever for Brook to get this out. Ever since the announcement that he would have TinyG working for a 3d printer. I’m hoping that it can be used to build a new firmware ecosystem.
@Stephanie_A Are you saying the Printrboard G2 is not available? I can place an order through Printrbot’s website. (Which is not the same thing as “available”.)
Hey! Wait! I bought a 24V E3D extruder in part on your recommendation. The Printrboard is 12V. That is OK?? (Not wound up - I can find the parts to make this 12V.)
I need to pull the trigger soon. Would you accept a 12V Printrboard over a Arduino Due and some passable shield for drivers?
Looking at Github, the g2core support for 3D printers does not seem to be in final form. As a software guy, this does not bother me overmuch, as I could help push the last bits, if needed. I do like this platform as a long-term bet.
(Hacking software does not worry me. Hacking electronics is a place I prefer not to go.)
Keep in mind, I became a listed contributor to open-source projects in similar case. In each case, sent in a patch, which was accepted. Sent in a second patch, also accepted. With the third patch they sent me a login to source code control, and told me to commit my own damn patches.
So I do not mind if the software is not quite there.
12v is not ideal for a high-speed printer. It’s going to limit your motor speed significantly compared to a 24v printer. I don’t know whether the PrintrboardG2 hardware can handle a 24v input – @Brook_Drumm ?
Another issue is that 8825 drivers have position rippling issues with “fast” steppers (ones having low inductance/resistance) and this will introduce print flaws if you try to optimize motor specs for high speed.
I’m not going to say you CAN’T make it happen with a lot of optimizing, but I personally wouldn’t expect a 12v printer to safely go over 200mm/s, and something more like 80mm/s is a more reasonable value if you want to use conservative drivetrain design rules to minimize the risk of skipping steps.
On the other hand, a 12v board with an ATX plug input is pretty dang convenient if you don’t want to muck with electronics and wiring much.
The printrboard is available, but I don’t think the full firmware is there.
Most boards right now are 24v compatible, I would be shocked if the printrboard g2 isn’t compatible. It’s just designed with an atx supply in mind.
I haven’t found the source code for their board yet, or for their firmware. The printer is being sold, so working firmware exists.
Only Brook or his staff can answer this.
@Stephanie_A As to the full firmware not quite being there, of my impression, I agree. Again, software guy here. At this point in my project, that does not bother me. They are fairly close, and if I need to help with the last - entirely within my comfort zone.
Pretty sure @Brook_Drumm is going to tell you the Printrboard is 12V only. If that is the case, does this affect you opinion? Are you going to recommend and Arduino Due and some shield instead?
Due/RADDS is a good option if you are comfortable configuring the firmware to match the hardware pinout. (You will have to do this with anything that doesn’t have an example config file provided. It’s trivial for competent coders who can read a board schematic.) Due/RADDS is not the fastest option out there, but it’s a pretty good hardware platform all around. It also has the huge benefit of there being existing Repetier, RepRapFirmware, and Marlin ports in case you decide TinyG/G2 isn’t the way forward.
Not being tied to a specific firmware is a huge benefit when you’re trying to do software improvement type work – if you run into a roadblock with a particular open source project’s codebase (or dev team), you can switch to another.
@Ryan_Carlyle To be clear, I am betting on the software, not the hardware. In the long term, hardware is more ephemeral than software. (Which is not what we tend to expect.)
I like the folk behind TinyG/G2. The hardware is whatever works well with their software. That is my bet.
In the 3d printer world hardware and software go together. Your software needs to have a common protocol to communicate with your hardware. Right now that’s gcode, and the firmware translates the gcode to the physical devices on the hardware. If you move away from gcode, now any new piece of hardware would need it’s firmware modified to be compatible with this new protocol.
This is why something like Arduino and platformio is successful. It provides a hardware abstraction layer (however it doesn’t solve issues like what devices are connected to what pins).
Different hardware is also supported by different firmwares. Some hardware have 6 stepper motor controllers. Some drive lasers and spindles. You can’t write a piece of software that adds a second extruder to your printer, the hardware has to support it too. In the end the hardware you select really matters. So unless you want to rewrite the firmware on the few dozens of different mainstream boards, or write your own hardware abstraction layer, you’ll need to pick your hardware carefully. Otherwise all that you’ll be able to change is the gcode and everything before it, which definitely needs improvement but is very limiting to any shift in how we use the 3d printer controllers.
Also I looked at some pictures of the printrboard g2 and the main input capacitor is rated to 16v which tells me it’s likely not 24v compatible and Brooks got a lot of 'splaining to do.
Ha! I want to hear when you get @Brook_Drumm to 'splaining.
Sorry, you are dead wrong if you expect the software to adjust to the hardware, as a first priority. Already lesson done in the early 1980s.
You see changes to the software as a “hard” thing (though changes to the software to new hardware as easy) this is a very, very old thing.
I see changes to hardware as "“hard”, and changes to software as “easy”, but with strong limits. I need to talk to the hardware folk, to ensure their changes are not excessive.
Old stuff … but current.
So … given 12v Printrboard, still a recommendation? Or Due?
This one is quite modular, though I think smoothieware is the only firmware for it. You need to buy a RAMPS board to go on top of it. https://www.matterhackers.com/store/l/panucatt-re-arm-controller-for-ramps
I don’t recommend any 12v board because the current consumption is very high. With the availability of 24v hardware of all kinds, there is no point in 12v. 12v needs bigger wires, bigger connectors, and still has a much higher risk of bursting into flames and burning your house down.
Changes to software is not as easy as you think. This is not changing from a Core i5 to a Core i6. This is changing from a z80 to a x86.
Again, hardware abstraction layers.
One board uses i2c, the other uses PCIe, another uses SPI. Your software needs to be completely rewritten for the timing requirements, interrupts, memory. You switch from a 48mhz to 80mhz and all the sudden your code doesn’t work because the timing is off.
There is good reason why marlin firmware still exists, even though it’s 8bit. It’s really really hard to port it to 32bit. They’re writing their own HAL and refactoring all of the code, an entire team of developers are feverishly working on porting the code to 32bit for the past year or so. Thousands of permutations of hardware is taken into account.
Changing hardware on a common architecture is easy. Changing hardware across ecosystems, across generations, where the only commonality is that they are microcontrollers and the buck stops there - that is hard.
It’s not a PC. It’s not your laptop. It’s not your phone. They don’t run on Windows or linux. They run hard coded assembly. You access registers directly. You access gpio directly.
What you’re implying is that you can write assembly for one board, then simply port that code to another with little effort.
Again, you’re underestimating the complexity of the problem.
@Stephanie_A From what I can see on the photo of the board on their website, the board uses 16V capacitors, so it would be 12V max.
Not so strange, as they sell it as an upgrade for existing printrbots.
@Stephanie_A Thanks. So no Printrboard.
BTW, what you wrote could be read as implying that Brook’s printers are slightly unsafe - probably not what you meant. Do not know the guy, but my guess, he is a very careful builder.
Not really interested in porting g2core to new hardware at this point, so I will go with known/working reference hardware. (Not looking for more risk. Have enough, already.)
Now to find who among the g2core folk are interested in 3D printers, and what hardware they are using…
They’re likely safe, most of his printers don’t use a heated bed, which is the biggest draw of current. In fact I think the heated bed on the printrboard g2 is an add-on. Properly rated wires and connectors can overcome the problem, but increases the cost of the machine. It’s cheaper and safer to use a higher voltage.
I’d suggest finding out exactly what controller the g2core uses and find another board with the same one. Likewise if you find one in the same family it would be easier to port. Typically you want same core and same vendor.
@Preston_Bannister You might find this interesting https://www.youtube.com/watch?v=Prw7wNa20Gk
Some of the stuff a more advanced stepper driver can do if you get the driver chip and MCU talking properly.
@Ryan_Carlyle Yes, the stallGuard2 feature is very interesting. Does this mean we could get by without limit switches? Is it that precise?
Also, subscribed prior to the Trinamic videos.
The Trinamic TMC2208 stepper-drivers (via Digikey) arrived yesterday. The RADDS board got stuck in Tennessee, briefly (FedEx wanted an invoice), so not here yet.
By my read, the 2208 does not have stallGuard2. I did not find boards with the driver-chip that offers the stallGuard2 feature. Perhaps I missed an example?
Ordered and received an appropriate soldering iron. (My old iron was not suitable for these tiny boards.) Watched soldering videos. When the drivers arrived … unfortunately, will have to do some soldering.
When the RADDS board arrives, need to build g2core to run some tests. Something to do while waiting for the parts to print for Z motion.
One unknown is whether g2core can make use of the Trinamic features, or whether I need to add support. Will see.
@Ryan_Carlyle As my extrusion stepper is currently making a lot of skipped-step noises, feedback from stallGuard2 could be used (in the first layer) to detect if the head is too close to the bed. Further into the print the skipped-step information could be used as a clue to bump up the temperature of the print-head. (Or slow down the print.)
If only …
Take this as headroom, from which interesting things might be possible, eventually.
Using stallguard to babystep the first layer height is a pretty good idea.
@Ryan_Carlyle Just saw the Prusa i3 mk3 announcement. They are using Trinamic drivers, and doing sensorless limit detection. Sounds like they are making use of Trinamic’s stallGuard feature, and that it works well enough to eliminate limit switches.