Nabble has removed Mailing-list integration.
Posts created here DO NOT GET SENT TO THE MAILING LIST.
Mailing-list emails DO NOT GET POSTED TO THE FORUM.
So basically the Forum is now out of date, we are looking into migrating the history.
For now you should send emails, people will see them, discuss@lists.openscad.org.
OpenSCAD on Raspberry PI
Locked
12
12
 
|
There's now a snapshot AppImage build available which
runs on the hopefully soon to be released Raspberry PI OS 64-bit. https://www.openscad.org/downloads.html#snapshots This includes all the cool new features, like the jump to code from the 3d view. (Edit->Preferences->Features->mouse-selection) ciao, Torsten. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
|
|
|
Darn! I just drooled all over my keyboard!
-- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
In reply to this post by tp3
That is awesome! Just ordered my RPi4B8G today!!
Cheers, RobW On 16 June 2020 8:06:43 am AEST, Torsten Paul <[hidden email]> wrote: There's now a snapshot AppImage build available which _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Rob W
Lake Tyers Beach, Victoria, Australia |
|
|
In reply to this post by lar3ry
Ooops key slip, 4G 😡
Cheers, RobW On 16 June 2020 9:25:27 am AEST, lar3ry <[hidden email]> wrote: Darn! I just drooled all over my keyboard! _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Rob W
Lake Tyers Beach, Victoria, Australia |
Administrator
|
In reply to this post by tp3
Does this overcome OpenGL ES
----- Admin - email* me if you need anything, or if I've done something stupid... * click on my MichaelAtOz label, there is a link to email me. Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD Admin - email* me if you need anything, or if I've done something stupid...
* on the Forum, click on my MichaelAtOz label, there is a link to email me. Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. |
|
|
In reply to this post by tp3
On 2020-06-16 00:06, Torsten Paul wrote:
> There's now a snapshot AppImage build available which > runs on the hopefully soon to be released Raspberry PI > OS 64-bit. Thanks for the information! Although the news about 64bit Raspbian is indeed very interesting (I do have a Rasberry Pi 4), I wonder why one would attempt to run OpenSCAD on it? What is the benefit compared to running OpenSCAD on a regular PC, considering that OpensCAD is taxing the CPU heavily? I recently created a system for automatic configuration of a cross compiler for Raspberry PI, so I imagine it will be possible to use it for the new 64bit OS once it is released, see https://github.com/arnholm/cross-pi . Then I guess you can cross-compile OpenSCAD or AngelCAD to create native executables for Raspberry PI 64, but I still don't see why you would run CPU heavy applications on that hardware. Some background info: I also have the original Raspberry PI Model B (now 5 years old) controlling my 3d Printer using OctoPrint. I run KISSlicer on Linux or Windows to create gcode files that are uploaded to OctoPrint on the old Raspberry PI. This works great so I am curious as to why there is a need for OpenSCAD to run on a Raspberry PI (any model/OS). Carsten Arnholm _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
Yes I was wondering the same thing. My PC is a few years old now but OpenSCAD is the only program I wish it was faster for. I do have a faster Linux machine but I develop using a database on Google Drive and Google don't do a Linux version. On Tue, 16 Jun 2020 at 11:06, <[hidden email]> wrote: On 2020-06-16 00:06, Torsten Paul wrote: _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
In reply to this post by cacb
cacb wrote
> What is the benefit compared to running OpenSCAD on a regular PC, > considering that OpensCAD is taxing the CPU heavily? I think that running OpenSCAD on a PI would make it possible to develop a machine that can print simple thing on demand, by using the PI as a controller of a 3d printer, and having a design with a few parameters. Off course you would need the design to remain small (in print size) and not too complex (for the PI), but it would be a nice geeky machine to use on, for example, festivals. The print time would suggest that you would then build a few of these machines, so cheap and small computers like the PI would be excellent for the job. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Re: OpenSCAD on Raspberry PI
|
|
The Pi4 with 4gb should be
able handle a pretty good sized model.
OpenSCAD can run under Windows which eats up most of the CPU anyway so it should run fine on Linux on a Pi!!! The Pi4 has a modern chip with multiple cores and has a solid state sd card for file access so it should be quick. I am not sure how small is "small" or why it should matter but a Pi should be able to drive a 3D printer without breaking a sweat. It does give someone a dedicated CAD station for a very low price. I would be tempted to use it the other way - as a dedicated processor with no screen or a shared monitor for rendering big models and freeing up a main cad station for design work. If you are really productive, get 2 Pi4s and keep them busy. With a shared screen that can handle multiple hdmi inputs, a USB switch for the mouse and keyboard and an NSF server for shared disk access one could work very quickly and never wait for a long render. Might even be possible to write a script that tells the Pis to look in a directory for new updated files and automatically start the render. They are so powerful and so cheap and compact that you can do a lot with them. I have been at the software business for so long that I remember supporting engineers doing full parametric 3D CAD on workstations where memory was measured in megabytes not gigabytes and CPU speeds were measures in thousands of floating point operations per second. Ron On 2020-06-16 8:04 a.m., MathLover
wrote:
cacb wroteWhat is the benefit compared to running OpenSCAD on a regular PC, considering that OpensCAD is taxing the CPU heavily?I think that running OpenSCAD on a PI would make it possible to develop a machine that can print simple thing on demand, by using the PI as a controller of a 3d printer, and having a design with a few parameters. Off course you would need the design to remain small (in print size) and not too complex (for the PI), but it would be a nice geeky machine to use on, for example, festivals. The print time would suggest that you would then build a few of these machines, so cheap and small computers like the PI would be excellent for the job. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org -- Ron Wheeler Artifact Software 438-345-3369 [hidden email] _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
In reply to this post by cacb
On Tue, Jun 16, 2020, at 10:06 AM, [hidden email] wrote:
> Although the news about 64bit Raspbian is indeed very interesting (I do > have a Rasberry Pi 4), I wonder why one would attempt to run OpenSCAD on > it? What is the benefit compared to running OpenSCAD on a regular PC, > considering that OpensCAD is taxing the CPU heavily? The Raspberry Pi 4 is super cheap, and super hackable. It is very popular in makerspaces and in STEM education. 3D printers are also very popular in makerspaces and STEM. OpenSCAD on Pi makes no sense if you are an industrial CAD designer, but it makes a lot of sense in a school makerspace. Windows-based desktops and laptops are a liability in a school environment, because each machine is used by many students, and managing the software environment (so that it can't be corrupted or made unusable) is a heavy burden for teachers and school IT people. In my school district, they use chromebooks. A locked-down school chromebook will only allow you to use CAD programs that run in a web browser. OpenSCAD doesn't run in a web browser (but there are many alternatives that do). I haven't tried running a Raspberry Pi based makerspace for kids. But, I imagine that you can just give each student their own Pi, and swap out the SD card if the OS gets corrupted. The benefit of the Pi is full hackability (the opposite of a Chromebook). Check out this Pi based laptop: https://www.pi-top.com/products/pi-top-3 This is how I imagine you'd use OpenSCAD for Pi. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
This all makes sense. What I am not clear on is how much of a
performance hit I would take vs my 8 core 4 GHz desktop On 6/16/2020 9:50 AM, Doug Moen wrote: > On Tue, Jun 16, 2020, at 10:06 AM, [hidden email] wrote: >> Although the news about 64bit Raspbian is indeed very interesting (I do >> have a Rasberry Pi 4), I wonder why one would attempt to run OpenSCAD on >> it? What is the benefit compared to running OpenSCAD on a regular PC, >> considering that OpensCAD is taxing the CPU heavily? > The Raspberry Pi 4 is super cheap, and super hackable. > It is very popular in makerspaces and in STEM education. > 3D printers are also very popular in makerspaces and STEM. > > OpenSCAD on Pi makes no sense if you are an industrial CAD designer, > but it makes a lot of sense in a school makerspace. > > Windows-based desktops and laptops are a liability in a school > environment, because each machine is used by many students, > and managing the software environment (so that it can't be > corrupted or made unusable) is a heavy burden for teachers > and school IT people. In my school district, they use chromebooks. > > A locked-down school chromebook will only allow you to use > CAD programs that run in a web browser. OpenSCAD doesn't > run in a web browser (but there are many alternatives that do). > > I haven't tried running a Raspberry Pi based makerspace for kids. > But, I imagine that you can just give each student their own Pi, > and swap out the SD card if the OS gets corrupted. > The benefit of the Pi is full hackability (the opposite of a Chromebook). > > Check out this Pi based laptop: https://www.pi-top.com/products/pi-top-3 > This is how I imagine you'd use OpenSCAD for Pi. > > _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
I don't think the number of cores makes much difference unless you have multiple instances open. On Tue, 16 Jun 2020 at 14:57, jon <[hidden email]> wrote: This all makes sense. What I am not clear on is how much of a _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
In reply to this post by doug.moen
On Tue, Jun 16, 2020 at 01:50:22PM +0000, Doug Moen wrote:
> I haven't tried running a Raspberry Pi based makerspace for kids. > But, I imagine that you can just give each student their own Pi, > and swap out the SD card if the OS gets corrupted. Or you tell everybody to bring their own SD card. (or supply everybody with...) Roger. -- ** [hidden email] ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
The SD sockets on RPI's are not very robust in my experience. It might be better for them to bring their own USB stick. On Tue, 16 Jun 2020 at 15:15, Rogier Wolff <[hidden email]> wrote: On Tue, Jun 16, 2020 at 01:50:22PM +0000, Doug Moen wrote: _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
In reply to this post by nophead
On Tue, Jun 16, 2020 at 02:59:35PM +0100, nop head wrote:
> I don't think the number of cores makes much difference unless you have > multiple instances open. So... for Openscad, to be able to make better use of the available performance on the pi, a "roadmap" for openscad might include: "make better use of multiple cores". Keep in mind that intel hit peak-clock-frequency somewhere around a decade ago. But Moore's law says that transistors keep getting cheaper, so even though still significant improvements keep being made in how much work can be done in each CPU clock cycle, in the future we'll be getting more and more cores in a chip. Currently even the cheap hardware (e.g. pi) has four cores because they don't know what otherwise to do with the available transistors! Roger. -- ** [hidden email] ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
In reply to this post by jon_bondy
On Tue, 16 Jun 2020 09:57:04 -0400
jon <[hidden email]> wrote: > This all makes sense. What I am not clear on is how much of a > performance hit I would take vs my 8 core 4 GHz desktop If it behaves like most applications a huge one. The PI 4 is pretty fast for an embedded ARM CPU but it's basically a repurposed media player engine. The sysbench table I have to hand scores a PI4 at 394, and a bottom end Intel i3-8100 at 4210. The PI4 is 4 core so as this is still a single threaded app unless you are playing with some of the experimental forks you are actually about 100. The i3-8100 is 2 core HT so you'll get around 1500 for a typical workload single threaded with the other thread idle and one core idle. Going to a fancy high end x86 processor actually doesn't help you that much because they add cores/threads for the most part. In fact you'd probably do better with a 'Pentium Gold' branded bottom end 2 core CPU at 4GHz than the i3-8100 as the bottom end desktop CPU has better thermals (my cheapo low core count box will beat the pants off my dual Xeon with OpenSCAD unlike say ImplicitCAD) So with an 8MB PI4 the generic numbers say you'd see a 10 fold loss of performance. However really someone needs to time actual examples because generic benchmarks and specific apps can be very different. Alan _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
In reply to this post by rew
There are experimental versions of OpenSCAD using multiple cores for rendering but that isn't what is slow for me. I do all my work in preview mode and only render the STLs to print them. Most don't take long, especially compared to printing them. E..g 38 parts to make a 3D printer take 7 minutes to render individually. The slowest one is the shelf bracket at 78 seconds, most take less than 10s. Drawing the preview from scratch, which does render() some of the parts takes 4 minutes. The killer is every simple change takes at least 23 seconds to redraw currently. Most of that time is running the script, so hard to see how multiple cores would help that. On Tue, 16 Jun 2020 at 15:32, Rogier Wolff <[hidden email]> wrote: On Tue, Jun 16, 2020 at 02:59:35PM +0100, nop head wrote: _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
In reply to this post by jon_bondy
On 16.06.20 15:57, jon wrote:
> This all makes sense. What I am not clear on is how much > of a performance hit I would take vs my 8 core 4 GHz desktop Unless someone completes the "Multi-threaded Geometry rendering" issue (earning the current bounty of $1060), the number of cores does not matter much. So comparing my 2 years old Dell XPS 13 with i7-8550U @ 4GHz max using the Menger Sponge level 3 example, I see (even including the monitor in the Raspi price): Notebook | Raspi 4 (8GB) | Ratio --------------------------------------- 35 seconds | 2:46 minutes | 1 : 4.7 ~2200€ | ~250€ | 8.8 : 1 I guess the performance hit is not as bad as one would imagine while the price is very nice. I certainly would not suggest using a Raspi for very complex stuff, but there's lots of things that it will be able to do in a reasonable way. Especially when looking at the 64bit/8GB model. ciao, Torsten. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
|
|
|
In reply to this post by rew
> Keep in mind that intel hit peak-clock-frequency somewhere around a
> decade ago. But Moore's law says that transistors keep getting Not entirely - it's crept up from 4GHz to 5GHz over that time, but short of some major process change it's now a slow gain. For high core count parts the change is even bigger - but that doesn't help OpenSCAD. > cheaper, so even though still significant improvements keep being made > in how much work can be done in each CPU clock cycle, in the future > we'll be getting more and more cores in a chip. Currently even the > cheap hardware (e.g. pi) has four cores because they don't know what > otherwise to do with the available transistors! The current bounds on processor design are primarily thermal. The size bound has partly been broken by 7nm and upcoming 5nm processes, but even more so by the ability to put lots of small dies together in one device even using different processes. Single threaded CPU performance has increased a bit more than the clock rate (instructions per clock has improved) but nothing compared to the effect of going from 12 cores to 64 cores in the same time (or 2 to 8 in the consumer space). (and neither can touch the performance gain for suitable workloads on GPU based computation) We had the rapid disk space doubling era, the memory doubling era, the clock speed doubling era, we are now in the core count doubling era. The most important thing though is that you can probably beat all of those gains comprehensively by the use of better algorithms. Alan _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
|
|
On 16.06.20 17:02, Alan Cox wrote:
> The most important thing though is that you can > probably beat all of those gains comprehensively > by the use of better algorithms. Yes! That! So if anyone knows a mathematician who would be interested in helping with that in the long run, there's a much bigger gain to be had than any multi-thread/multi-process support with current CGAL can ever deliver. Right now the balance is: - CGAL: slow, but quite often reliable - others: faster, breaking geometry worse than CGAL What would be awesome: Fast multi-threaded algorithm with GPU support :-) No need for theoretical correctness, what we need is a reliable, robust engineering solution. There's a number of libs claiming that, but all of those were unmaintained last time I looked. Maybe time to checked again if things changed... ciao, Torsten. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
|
«
Return to OpenSCAD
|
1 view|%1 views
| Free forum by Nabble | Edit this page |