[Geschlossen] 32 Bit Electronics  

Re: 32 Bit Electronics

The mesh bed leveling routine on its own is relatively cheap

But was it not the last straw which broke the camel's back?

I am certain there will be an equivalent saying in Czech.

Peter

Re: 32 Bit Electronics

In Czech, it is the last drop of water, which makes the pitcher so havy, that the handle breaks.

I did profile the latest 3.0.6 firmware and I have verified, that the motion planner's queue does not dry out to less than a half of the queue (8 moves of 16) when printing the 3DBenchy. That is a good indicator, that the interrupt controllers receive sufficient CPU clocks.

Another indicator are the prints on our print farm.

Vojtech

Re: 32 Bit Electronics

I guess you also have an equivalent of "Mr. Murphy"?

We know from past experience that what happens in your offices will be totally different when us users have this firmware.

Some of us are "professional software breakers" you know...

Peter

Re: 32 Bit Electronics

>
What is really breaking back of the MCU is the motor control interrupt routine and the path planner routine (jerk and velocity control), not the mesh bed leveling. The mesh bed leveling routine on its own is relatively cheap.

Interesting. It's been noted as a problem for other printers; definitely the delta's and occasionally the cartesians. I'm thinking of this example:

https://plus.google.com/+BrookDrummpb/posts/78GBdh752LG

> I am so frustrated right now from having put a divot on my otherwise new, clean PEI sheet because of BUNK FIRMWARE.
> Regardless of what processor/board is used, none of it will matter if the firmware written for it is JUST PLAIN CRAZY.

Would you please be more specific?

My experience is... more or less in another thread; I'll try to keep it localized and away from this thread.

http://shop.prusa3d.com/forum/prusa-i3-kit-building-calibrating-first-print-main-f6/issue-with-board-and-bed-t1342.html#p10191

Re: 32 Bit Electronics

What about something based around a BeagleBone Black? http://beagleboard.org/

ARM Cortex-A8 32‑Bit RISC Processor 1GHz
Interrupt Controller (up to 128 Interrupt Requests)
Up to Three External DMA Event Inputs that can also be Used as Interrupt Inputs
Integrated 15- to 35-MHz High-Frequency Oscillator Used to Generate a Reference Clock for Various System and Peripheral Clocks
Supports Individual Clock Enable and Disable Control for Subsystems and Peripherals to Facilitate Reduced Power Consumption
Five ADPLLs to Generate System Clocks (MPU Subsystem, DDR Interface, USB and Peripherals [MMC and SD, UART, SPI, I 2 C], L3, L4, Ethernet, GFX SGX530], LCD Pixel Clock)
Real-Time Date (Day-Month-Year-Day of Week) and Time (Hours-Minutes-Seconds) Information
Internal 32.768-kHz Oscillator, RTC Logic and 1.1-V Internal LDO
Independent Power-on-Reset (RTC_PWRONRSTn) Input
Dedicated Input Pin (EXT_WAKEUP) for External Wake Events
Programmable Alarm Can be Used to Generate Internal Interrupts to the PRCM (for Wakeup) or Cortex-A8 (for Event Notification)
Programmable Alarm Can be Used With External Output (PMIC_POWER_EN) to Enable the Power Management IC to Restore Non-RTC Power Domains
Eight 32-Bit General-Purpose Timers
DMTIMER1 is a 1-ms Timer Used for Operating System (OS) Ticks
DMTIMER4–DMTIMER7 are Pinned Out
One Watchdog Timer

£35 - £45
I'm actually running my i3 on a setup like that. The Replicape rev B ( http://www.thing-printer.com/product/replicape/ ) is a control board that uses the built-in MCUs on the BeagleBone. The board itself contains five Trinamic TMC2100 stepper drivers (same as in the Silent StepSticks, if you've heard of those), MOSFETs for bed and 2 heater cartridges, and all the other stuff you need to run a 3D printer. This also means that the printer itself runs OctoPrint, with an added plug-in to adjust stepper currents, microstepping and stuff like that on the fly, from inside the browser. Quite neat.

I've used mine for 4 months now and it's been an awesome improvement. In particular, the printer is now almost completely silent. As in, I can't tell whether the printer is running or not when walking to another room (actually, I'm considering a switch to Igus bushings as the linear bearings now make more noise than anything else on the machine). I can certainly recommend it to anyone considering a motherboard upgrade.

Re: 32 Bit Electronics

Gotta say that the more I read about the soon to be released DuetWifi the better it sounds! The team behind it seem very open to ideas, it is fully Open Sourced and seems to have pretty much everything that you could need!

Re: 32 Bit Electronics

A bit of an update on this – a friend of mine actually runs a Prusa on a DuetWifi now. The config process feels a bit wonky if you're used to Marlin as all the configuration is done in G-code, but it's quite logical and works really nicely. The board has Trinamic stepper drivers similar to those on my Replicape, so you can pick between the SpreadCycle mode or StealthChop (the black magic super silent mode) for each stepper.

On my machine, all steppers except Z are running in StealthChop. Had to reduce the jerk setting slightly to avoid step loss, but otherwise torque is never a problem and print quality is splendid. Don't bother for Z, though – I always ended up with Z geometry issues in that mode, and it's not like noise is that much of an issue for an axis that moves 0.1 mm once a minute 🙂

RE: 32 Bit Electronics

It is incorrect that Linux is “not designed” for real time. There have been real time Linux kernels available for almost as long as Linux has existed; I designed a ‘hard’ real time system around one as early as 1994. The current effort is PREEMPT_RT which is available as a patch for the Linux Kernel. Work is ongoing to mainline this functionality into the kernel. Many ‘hard’ real time solutions (ie, robotics) run on PREEMPT_RT. See https://rt.wiki.kernel.org/index.php/Main_Page

While not as well suited for hard real time as a Cortex MCU, there is absolutely no reason why a Raspberry Pi could not handle a 3d prnter. It would do so with far better performance than is possible with any 8 bit solution. All we would need is a version of Raspbian built with PREEMPT_RT, and a kernel space driver for handling the motion control, preferably compatible with one of the newer SPI interfaced controllers like the Trinamic TMC2660. 

RE: 32 Bit Electronics

A plea: whatever you do, please don't try to integrate a Web server and a slicer and whatever else into the same computer that's doing the motion control. Especially if it takes away the ability to network the printer any other way. In fact, please don't try to integrate that sort of thing at all.

Even if you went through all the work to build that, I'll give you an example of something you will *never* support: I drive my MK3S with Octoprint... behind an HTTPS proxy... authenticated using Kerberos... on a system that follows my internal security policy, including running my standard distro and taking random upstream software updates all the time from foreign repositories. All of which is on a Raspberry Pi. If I tried to do that kind of hackery to a Pi with a super-customized real-timified version of Linux, or to any other computer you'd be likely to put in there to drive steppers, I would deserve what would happen to me. And I wouldn't want to have to figure out how to do that for every device I have, anyhow. It's much easier to just stick a $50 Linux system in front of it.

There's no WAY I would ever want to expose a motion control system from Prusa or anybody else directly to the network.

I'm sure lots of other people have weird requirements, too. You can't meet them all. Please let the printer worry about being a printer, and something else worry about being a network interface or a slicer host or a camera driver or whatever.

What might be nice would be to get rid of the serial bottleneck, so that there was either more bandwidth for G-code or more bandwidth to put G-code on the SD card. The Toshiba card is NOT anything I would ever use or even allow on my network.

RE: 32 Bit Electronics

This is not a new idea. The Linux CNC project has used this approach for years. It works even with old and slow PCs to generate STEP/DIR and PWM for CNC lathes and mills. In a properly designed RT system, whether you are running a web server, or anything else, it will not affect the steppers. And generating pulses that way would not restrict you from using a USB thumb drive or Serial Port to control the printer. 

Your concern about exposing any motor driven system to the network is of course valid. But this approach is not any different from exposing any machine driver, like octoprint, to the network. Whether you use a Pi running Octoprint to talk to an ATMEGA, or use PC serial over USB, or use the Pi directly with a RT kernel, the same security risks exist. The only way to protect your printer from the world is to use the SD card and keep it off the network entirely. Which works, but is not very convenient.

RE: 32 Bit Electronics

@mark-l15

I think you're missing my point. It's not that a Web server (or whatever) can't coexist with motion control. It's that making that work requires a highly integrated system that can't easily or safely be messed with. And if it can be messed with, messing with it will involve redoing a bunch of the work that you've already done for all the other "standard" systems on your network.

The security issue is that if I have 100 devices facing the network, and they all behave differently, and each of them has to be individually configured, and they're all running different versions (or completely different software) for every application, I have no chance of maintaining a decent security posture or even understanding what posture I have. So I'm forced to put various proxies, firewalls, and other front ends in front of "weird" devices, and enforce my policy there.

The sort of system that people are asking for would end up coming from Prusa as a preinstalled blob. If we imagine it to be on a Raspberry Pi, it'd probably be running a customized version of Raspbian (which I do not use on my own Raspberry Pis). There would be edited config files all over the place. There would be software that had been installed outside of the apt framework. There might even be a Prusa-provided apt repositories containing who-knows-what software that might or might not be safe to replace from other sources... and, if so, Prusa would definitely lag its upstream sources in updating that repository.

You definitely wouldn't be able to, say, install the new version of the stock Raspbian kernel to deal with a security issue. You'd have to compile a new kernel yourself, or wait for Prusa to get around to issuing an update. And that's assuming that you even knew about the issue to begin with... one of the beauties of using a major distro is that they usually fix those things for you even if you don't notice them yourself.

I can live with old software on something that doesn't have to talk to the network; I just won't update it until I need a bug fix or a new function. But security doesn't work like that... you have to take the updates as fast as humanly possible. Similarly, I can live with insecure (or unreviewed) configurations on something that can't be reached anyway... but not on something that demands to talk to the network directly.

To figure out how to secure an integrated system to the point of being able to put it on anything but an isolation subnet, I'd have to do a ton of work that would be completely specific to the Prusa printer. I can't possibly do that for every device I stick on the network. I can't even keep up with updating the software in a different way for every device on my network. It's much, much simpler and safer for me to just front it with something else, something that I control, that follows all my usual practices, and is built from my usual templates. I can't redo all that work just for a 3D printer... and then do it again for the next random device.

... and the "smarter" a device gets, the more of a pain it is to put that kind of front end on it. If I'm lucky, I can just ignore all those features and use it in "dumb mode" as you suggest. But what do I do when it turns out that the only way to update the  printer "firmware" is to plug it in and let it talk  to the network directly? How do I evaluate what else it may be doing?

As for Octoprint, I don't expose Octoprint directly to the network. I expose a front end that I control. Nobody gets to send a single byte to Octoprint without passing the Kerberos gate, which is enforced by a separate server process. The software that enforces that gate is kept up to date with upstream. Octoprint itself can't even make outgoing connections that I don't understand and authorize. Even a total DoS attack against the front-end system wouldn't do anything worse than stalling the G-code stream to the printer. And I definitely don't use OctoPi, which is a perfect example of what I do not want.

That's all on Fedora, by the way, just like everything else on the network. There's zero chance that Prusa would be able to support a Fedora variant of an integrated system. And if they did, that still wouldn't help people who were standardized on something else.

And security is just my personal hobbyhorse... somebody else's issue might be that they wanted to add a front end for a specialized workflow or something. The less modular the overall system is, the harder it is to do that kind of thing.

RE: 32 Bit Electronics

Jesus man, if you don't want it on your network then just don't put it on your network.

RE: 32 Bit Electronics

Absolutely agree with Jbash. Don't want my my printer crashing cause the slicer or whatever crashes.

RE: 32 Bit Electronics

I'm not sure what any of this has to do with whether you drive the steppers with Linux, or use Linux for Octoprint and  send code to a MCU to generate the steps. Since Octoprint sends gcode as a stream, if octoprint or the computer it's on crashes, so does your print, regardless of how it's being driven.

The security profile also does not (much) change, unless you have data that shows the RT kernel for Linux, which has been part of the mainline for some time, is less secure than the released kernel. I have no reason to believe that it is.

And, as gz1 says, if you don't want to expose your printer to the world, don't put it on the network 🙂

RE: 32 Bit Electronics

@mark-l15

The point is that I can fix the security of a device running relatively standard software plus just Octoprint.

It's far more difficult for me to fix the security of a device that runs a highly specialized, nonstandard real-time Linux system that will inevitably be put together using all kinds of weird irregular customizations. If I happen to break any of those customizations, something, possibly something apparently unrelated, will stop working.

It has nothing to do with whether the real-time Linux kernel is secure or securable in principle. The issue is that by combining all that functionality into a single, integrated, monolithic blob, and demanding that I expose that blob directly to the Internet, you make life much more difficult for me as an administrator. You force me to learn enough about this weird, highly customized system that I can evaluate and fix its security.

Sure, I could put some kind of Web front end in front of the whole giant blob instead... but next you're going to be asking me to let it make outgoing Internet connections, because there's bound to be something that needs that among all of this massive tangle of functionality you want to put on there. And if, for any reason I decide that I want to replace any of those included functions with something else, the "integrated system" is going to fight me every step of the way.

RE: 32 Bit Electronics

This has nothing to do with RT Linux because you literally have nothing to contribute about RT Linux.  You sound like a mid-level IT manager who's trying to duck out of a project.

If you don't trust a device, take a single managed switch and make all the ports separate VLANs ("isolation subnets").  Ahead of that is a single VLAN trunk or whatever ($20).  If you have like, 4 or less devices then it's just one device.  Access each subnet individually through a VPN which can be backed by whatever auth system gives you the hardest boner.  If necessary, grant temporary masq access out to the Internet for updates or whatever.  Otherwise it just sits in the corner and talks to nobody.

I mean, honestly, you self-identified it as a layer 3 problem but you keep trying to club it into submission from all the way up in layer 7.  That's madness.

RE: 32 Bit Electronics

@gz1

Thanks, you saved me from a(nother) long post 🙂

RE: 32 Bit Electronics

@gz1

I realize that people have have been trying to solve every network security problem by filtering at layer 2 and 3 for a very long time. I first did QA and application design for that kind of thing in about 1990. Followed by development work on the software. Followed by third or fourth level tech support for that software. Followed by security incident response on those products (both product vulnerabilities and customer incident support). Followed by development of standards for the security and secure design of those filtering products, and consulting support for the people who build them... as well as of many related products.

By the way, I spent a lot of that time stomping on the people building those related products when they claimed they could get away with crappy security because they were nice and "safe" on a VLAN somewhere behind a firewall. Because they were not safe.

Because of those 30 years or so of intimate experience, I know that network layer filtering is fallible. Furthermore, I know that it was never actually chosen by anybody as the best architectural approach. It's a hack that was initially put in place because people couldn't get their shit together to write halfway reasonable software, and it's popular because it can be done at a central point of control, not because it works well. I was there when people started doing it, and I've been there through all the times they've added more crazy complexity in silly attempts to fix its fundamental problems.

It's a huge architectural pain in the ass. The network layer doesn't know anything about users, processes, connections, or really anything but whole machines.

Nonetheless, I have network layer filtering in place, to the degree that it makes sense. The kind of Rube Goldberg per-user dynamic VPN routing and VLAN filtering you suggest does not make sense for me, and does not make sense for most people or organizations. It's nearly impossible to get right. It's brittle, and it tends to leak even when it's set up by people with a clue. I've spent untold amounts of my time dealing with all the different ways it fails when you actually push on it. It's also a huge pain in the ass to use.

Network layer filtering is a hack that you do when you have given up on getting things right, or as a backstop in case you do not get things right. Granular security does not naturally belong at that layer; it's just been the path of least resistance for IT drones for the last 30 years or so. I realize that the drones have come to depend on it for everything, but that doesn't make it acceptable.

... and you still haven't dealt with any of the non-security problems with dumping everything into a giant interconnected, unchangeable, unmaintainable blob.

RE: 32 Bit Electronics

Posted by: @jbash

I realize that people have have been trying to solve every network security problem by filtering at layer 2 and 3 for a very long time. I first did QA and application design for that kind of thing in about 1990. Followed by development work on the software. Followed by third or fourth level tech support for that software. Followed by security incident response on those products (both product vulnerabilities and customer incident support). Followed by development of standards for the security and secure design of those filtering products, and consulting support for the people who build them... as well as of many related products.

By the way, I spent a lot of that time stomping on the people building those related products when they claimed they could get away with crappy security because they were nice and "safe" on a VLAN somewhere behind a firewall. Because they were not safe.

Because of those 30 years or so of intimate experience, I know that network layer filtering is fallible. Furthermore, I know that it was never actually chosen by anybody as the best architectural approach. It's a hack that was initially put in place because people couldn't get their shit together to write halfway reasonable software, and it's popular because it can be done at a central point of control, not because it works well. I was there when people started doing it, and I've been there through all the times they've added more crazy complexity in silly attempts to fix its fundamental problems.

It's a huge architectural pain in the ass. The network layer doesn't know anything about users, processes, connections, or really anything but whole machines.

Nonetheless, I have network layer filtering in place, to the degree that it makes sense. The kind of Rube Goldberg per-user dynamic VPN routing and VLAN filtering you suggest does not make sense for me, and does not make sense for most people or organizations. It's nearly impossible to get right. It's brittle, and it tends to leak even when it's set up by people with a clue. I've spent untold amounts of my time dealing with all the different ways it fails when you actually push on it. It's also a huge pain in the ass to use.

Network layer filtering is a hack that you do when you have given up on getting things right, or as a backstop in case you do not get things right. Granular security does not naturally belong at that layer; it's just been the path of least resistance for IT drones for the last 30 years or so. I realize that the drones have come to depend on it for everything, but that doesn't make it acceptable.

... and you still haven't dealt with any of the non-security problems with dumping everything into a giant interconnected, unchangeable, unmaintainable blob.

1) We are discussing a kernel that has been in the mainline for some 15 years. It is not an "unmaintainable blob" any more than the rest of the kernel. And if you add Octoprint and a port of Marlin port to it, it is still no more a blob than any other use of that code, regardless of platform. 

2) In 2006, Linus Torvalds said: "Controlling a laser with Linux is crazy, but everyone in this room is crazy in his own way. So if you want to use Linux to control an industrial welding laser, I have no problem with your using PREEMPT_RT." (ref here). PREEMT_RT has been in the mainline ever since, and building it is no more difficult or risky than any other kernel option. If Linus thinks it's good enough for an industrial laser cutter, then I would suggest that it is good enough for your Prusa 3D hobby grade printer.

3) I think your "security" argument is entirely misplaced. PREMPT-RT is no more or less secure than the rest of the kernel. But the real issue is the application. We are building software for a hobby grade 3D printer, running on a hobby grade print server, with hobby grade firmware. And for most of us, the whole thing sits on a home network that has not been configured for high security.  The Pi with Octoprint and Marlin is likely much more secure than the other junk people connect to their home network. The wireless AC switches that communicate via http clear text come to mind. If you require enterprise grade security, this is entirely the wrong product and application for you.

RE: 32 Bit Electronics

Reminds me a bit of people complaining about network security while themselves are using Android 5 phones with security patches from early 2014^^

@mark I fully agree with you. For the simple home use, there are bigger security problems. Sure, in a big company, security means lots more.