Just to cause a bit of (constructive) trouble,

3D Printing
, , , ,
1

Just to cause a bit of (constructive) trouble, have to note I find the hardware and software factoring of the current generation of 3D printers to be mostly wrong.

For common function - Ethernet, wireless, Bluetooth, USB, or SD cards - use the most throughly debugged and flexible software. Put simply, put all this on a well-supported board that runs Linux.

For the 3D printer specific aspect - stepper drivers, switches, and sensors - put this on an attached board. How the printer-board is connected to the Linux board could vary (though I suspect SPI will play a large role, in future).

To be somewhat rude … in my experience hardware folk tend to massively undercount the expense of software. The common fallacy is they can put together a board, and the software will somehow magically appear. The symptom of such work is software that lags and works less well than wanted. (And I suspect Duet and Smoothieboard are in this bucket.)

As far as possible, you want hardware that uses existing software.

The user interface presented by most of the current crop of 3D printers is not good. Simply, the displays are too small, and the supporting software is crap for presenting a good quality user interface.

A really good user interface requires a larger display and a rather large pile of supporting software. The best-of-breed user interfaces are now on smartphones and tablets. The means you want to run Android on your Linux board. (Unless Apple gets into 3D printers.) This is possible, but means you have in large part replicated the function in your smartphone(s) and tablet(s).

If you want to monitor and control your printer remotely, and if you want to monitor and control a farm of printers, then user interface hardware attached to each individual printer is a waste. We need one user interface device per human, not one per printer. As human folk tend to have a smartphone and/or a tablet, better to present the user interface on that device.

That means the user interface for the printer becomes an app that runs on your device. That means the printer needs very little in terms of a display or input for user interface (which reduces cost and software complexity).

In software terms, this means printers offer lean web services. Some of the interfaces need to become standardized, to allow control not limited to the software from the maker of the printer.

Also the notion of embedding slicer software in the printer does not to me seem to make any sort of sense. In the present, slicer software is not smart enough to automatically determine how an object is best printed, and it will be years (at least) before automatic slicing is viable in the printer.

If slicing software in the printer is mostly crap, for the user, better to have the slicing software in one place. That might mean having a slicer in the cloud (if someone comes up with an economic model that makes long-term sense). That certainly means a slicer running on a local computer (as not everyone has a good Internet connection).

In present, slicers not very smart.

By analogy, current 3D printers are a bit like ink-on-paper-printers in the 1980s. Generating printer-specific codes requires knowledge of the printer. In older times, printing required the user know a lot more about their printers … and often required several tries to get the wanted result. For printing to become less error-prone and more automatic, the print software needed to introspect the printer, to discover what might work.

The next step forward requires 3D printers that can be introspected by slicers. That means printers offering a web service, common across printers.

So … hardware factoring into generic and printer-specific. Software factoring to support common introspection and user interface. This is where we end up … sooner or later. :slight_smile:

2

You could be the one that makes some of these changes happen.

3

Finally something that I can agree with. :slight_smile:
The actual control board of the printer has 1 job, to communicate and control the hardware. That is, it needs to read the hardware inputs, and control the physical devices. It should take a standard format like gcode (there are other protocols that may be better).

Things it should not do: displays, web interfaces, wifi or Ethernet. At all times it should focus on one thing and do that thing well: handle the input and output like heaters, motors, endstops and sensors as controlled by the gcode or protocol.

There is something like the new printrboard g2, where comms are handled by a separate board, which is a step in the right direction.

However, there is an issue with using gcode, that it doesn’t translate directly into actual calculations required by the controller, like how many steps, bed levelling adjustments, delta transformation, etc. When you think about how we do it now, it’s quite inefficient. It’s like using JavaScript to do complex real-time calculations on a 386. Instead the code should be compiled just like a compiler, into machine code. In fact you could compile gcode directly into machine code if you really wanted to, flash the firmware with it and hit go (ridiculous example but perfectly possible).

But as for SPI, that’s not gonna work, SPI is not a robust interface. USB is pretty good, or CAN, something that has error checking and can go long distances without noise issues.

I would think of it like a nice laserjet printer. A document is translated by a driver into a format that a controller on the printer receives, translates that code which is sent to the controller that moves the motors. Each plays it part and has its role.

4

@Nick_Winters Thanks. Perhaps … but not without a larger agreement within the group. No gain in my wittering off alone.:slight_smile:

The reason for posting the above is to offer a strawman.

5

@Stephanie_A No worries. I promise to post some things in future you find less agreeable. :slight_smile:

To take your statement a step further, the controller board(s) in the printer have two jobs. To control the printer (as you said), and present an external/network interface sufficient for external software to introspect and control the printer. In hardware terms, those two jobs tend to naturally factor into two boards.

The hardware manufacturer could combine the two boards, if this required no change to the software. The greater the change needed to the software, the less desirable the hardware combination.

As for Gcode as suitable in long term, as yet I have no opinion. Guess I have assumed generated Gcode as printer specific, much as with 2D printers generated PCL and Postscript are printer specific. (In theory both HP’s PCL and Postscript are somewhat printer independent … but in practical use, both are strongly dependent on introspecting the printer to determine what is suitable.)

As to the efficiency of Gcode, the amount of compute in a Raspberry Pi or a Beaglebone is a bit absurd. (No, I am not going to target 8-bit CPUs for anything with a future.) Physical hardware just does not move all that fast. But there may be issues with which I am not yet acquainted.

Bit surprised you would suggest CAN (not that I have a strong opinion, as yet). My expectation is that the link between the controller and the stepper drivers is extremely local, so no long distance. Again, no strong opinion at present.

Just to be clear, a nice laserjet printer receives codes that are already highly optimized to the specific printer. Microsoft Windows was first in learning to introspect printers (in the 1990s), so as to generate printing-codes optimal for that printer. Linux learned this a bit later.

Where the concerns are similar, I expect the evolution of 3D printers to parallel that of 2D printers.

6

Interesting discussion. My Printrbot Simple Pro w a cloud service slicing, touch screen “computer” (teensy) , WiFi, and arm based G2core board is an effort to make it simpler to the user. You don’t have to know anything about slicing and a phone is all you need to serve it a file… any browser works. So while usb is optional, you don’t need it.

Polar3D.com is an example of an effort to standardize an interface/cloud service to run any printer… they will power our Printrbelt. There is an undercurrent happening amongst bigger 3d printer companies who know the cloud and a local Linux box may change the game and move the needle.

I’m talking w a Kickstarter project making a high res screen w the same 10-finger touch stuff that Apple uses… we do need a better screen and touch interface. Check out the manga screen 2 and Toggle :wink:

The above mentioned project runs on a beagle board but could run on an rpi.

I’m looking forward to real advances in UI. Software is hard and very expensive- yes- but there is hope.

Brook

7
8

Am actually not a fan of cloud connected hardware, the loss of control over the hardware can affect power-users and prohibit tinkering. It also ties you down to whatever decisions that the developer makes, like say if the developer decides to implement DRM. in theory it sounds great - one click printing, simple settings and shared profiles, but in practice you end up with a coffee machine that requires Facebook messenger to brew your coffee (which won’t work in your corporate environment because unauthorized devices aren’t allowed on wifi and the firewall blocks it anyways).

The problem with general purpose computing is that it’s not made to interact with the world in real-time, so its useful to have at least two controllers, one that handles timing and sensitive tasks, another that handles asynchronous tasks like communication.
As for the interconnect, stepper motors generate a Lot of noise, and spi is not robust in noisy environments over long distances, you would be looking at greatly reducing the clock rate, and the protocol doesn’t have crc or transaction acknowledge built-in. Best I’ve ever done in the lab was a 1Mhz clock over 1 foot length, and still had errors on occasion. If both controllers are on the same board you can do proper routing to eliminate most noise.

A pi or something interpreting the gcode is good, but the question is the protocol between the pi and hardware controller, currently there isn’t any adopted protocols, but there are some attempts like s3g which aim to reduce overhead.

9

(damn this is a good thread)
From my perspective, this IS where we are. I personally wholeheartedly agree with Stephanie S, I’m not going to implement a level of ‘out of my house’ control to something that that inherently requires control IN my house.
Off-topic (ish) I’m building up a IOT platform for my house to monitor stuff and message and alert things.
The greater majority of all the things it does happens in the house, because of separation of concerns.

Which brings me back to this.

I have two 3d printers, both of which have NO direct on-hardware UI component because I’ve mounted a pi on each of them that hosts a local instance of OctoPi.

This then means that the UI component is abstracted to however I communicate with OctoPi as a interface to the hardware. As far as the abstracted view of the hardware is concerned, OctoPi is the endpoint.

Also, although I can (if I wanted to) run the slicing profile on the OctoPi instance, I mostly wouldn’t want to as the profile that cuts the 3d print run is likely to be optimised in that print run instance of GCode against the thing that I want to print.
For me the GCode generation choices are just as important as the 3d design choices made when creating the object in Fusion 360, it’s the other half of the same job, so from a separation of concerns perspective, everything that happens up to shipping the GCode to a printer is a Design job. Everything that happens afterwards is a Print job.

So, Tl:Dr;
Abstraction levels are good, they provide fluidity and flexibility within the process. The better the interfaces between them the less it feels like a toolchain and more like an inherent part of the process.
It also means that an individual part of the process can be changed around to provide upgraded experience, functionality and efficiency.

Also, I don’t trust an off site, black boxed process to manage a device in my house. It’s not a foil hat situation, I just don’t personally trust someone else to make that level of decision for me.

Advisory? Yes. (messaging queues, providing updates where appropriate that can be ignored or optimised)

But ‘yeah, sure, set something up that doesn’t guard around specific concerns I have with my environment and press the big green GO button’?
HELL NO

10

What I like about 3D printing is that the whole process is (or can be) open source, from 3D design to print. This provides me the freedom to tinker with every aspect of it. Therefore terms like cloud and web service make me uneasy. For me it stands for non-free. The data and the programs are sitting somewhere on a remote server depriving me of the possibility to tinker with it. This effectively takes away the freedom that I value so much. Before you know it information is gathered (and sold), DRM is implemented and the user is left in the cold.

11

Replicape?

12

Yes, Replicape + Manga Screen solves some of the issues you are bringing up. Using high level languages for control (Python), much off-the shelf software (Octoprint, Slicer, CuraEngine). Even by leveraging the BeagleBone community and Linux in general, it’s been five years of development by the community and it’s now stable, but still there is a lot more to be desired, especially a smooth introduction for the first time user.
So for anyone looking to have a high end user interface (both on the printer and on web), I think it’s going to be a long canvas to bleach making something from scratch.
People are starting to figure this out though, several printers are now running on BeagleBone ( Rpi could also work, but requires a separate uC for the real time aspect, so it’s not as cost effective).
As for on-board slicing, it’s a bit slower than on a laptop, but you don’t have to constantly teach all the users in the makerspace/office what settings to use. In practice it works well.
Interesting topic indeed!

13

We offer optional cloud on the Simple Pro but usb printing is there as an option too- using main hosts, even octoprint. We open sourced the whole thing- lcd and all. We even made ota firmware possible on the esp and teensy- (the later) never been done. So I feel we contributed but little to no movement here due to complexity I think. I’m fine if it was a swing and a miss. At least we didn’t lock down anything. We even allow uploading plain gcode to the cloud if you want to use a different tip size or slice. It’s something at least.
Brook