Experimental Cura build for Raspberry Pi 4 now available

[burtoogle 514]

You have done "sudo apt-get install libgles-dev"  haven't you?

 

I can't think of anything else that would cause a problem.

[flyhh 0]

1 hour ago, burtoogle said:

You have done "sudo apt-get install libgles-dev"  haven't you?

 

I can't think of anything else that would cause a problem.

You're a hero! Perfect 

[private4587 0]

I am very interested in this project, could you tell me could i run this from the pi desktop as i want to try and install and run both this and octoprint from the desktop. many thanks great project

[burtoogle 514]

Download the latest Linux-armhf AppImage from https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0

 

While you are there read the README.md file.

 

In a terminal window, enter: sudo apt-get install libgles-dev

 

Make the downloaded AppImage executable by either using a file manager program or in a terminal using chmod +x.

 

You should now be able to run the AppImage by either typing its name in a terminal window or clicking on it in a file manager.

 

Hope this helps!

 

[private4587 0]

Thanks burtoogle but i am unsure what to do with the Linux-armhf AppImage once i have downloaded it. I have loaded the libgles-dev onto my Pi. but how do i load the Appimage. the card i am using in my raspberry pi already has octopi on it i don't really want to overwrite this has i want both on my pi. Hope that makes sense.

 

Peter

[tinkergnome 927]

27 minutes ago, private4587 said:

Hope that makes sense.

 

not quite, sorry... 🙂

There's no need to overwrite the operating system, rather it's essential for running an app... 😁

Here are some basics about AppImages:

 

https://docs.appimage.org/user-guide/run-appimages.html

 

[QBall1977 0]

Most people run Octopi remotely with the Pi somewhere near the printer. Control is done through a web interface that you can then access from any other device /computer/phone etc on your network.

 

i have a Pi3 sat under the carriage of my printer. But I use a Pi4 as a desktop which I run both Cura and another well known slicer on.

 

Pi3s are pretty cheap right now, the built in WiFi, connectivity and processing power make the ideal remote computers.

 

This App image of Cura is designed to run on the Raspbian desktop, you cannot just run in while using the commandline.

if you downloaded the Octoprint image directly I don’t believe it is designed to run the Pi desktop (as default) rather the command prompt.

 

you will be able to install the desktop of you want, but that will require some tweaking.

 

Hope that helps.

[burtoogle 514]

Hi @QBall1977, thanks for chipping in, that's all good info.

 

Just to clarify one tiny point, you can run the AppImage from the command line when you have a terminal window open on an X Windows display. But I get the point that you need to have a desktop running.

 

Incidentally, the PI4 that I use to build the Cura releases is accessed remotely using VNC and Raspbian does make it very easy to run headless remote desktops. I also have two SV01 printers, one connected to a Pi2 the other to a PI3. Both of those PIs are running Raspbian and have Octoprint installed. Neither have screens attached but I can access their desktops using VNC.

Edited May 3, 2020 by burtoogle

[private4587 0]

thanks for you support in this, i have desktop installed but am awaiting a cdmi adapter before i can connect to a monitor. Just so i have it straight a i create a folder and place init the app image make it executable and run it from there 

[burtoogle 514]

2 minutes ago, private4587 said:

Just so i have it straight a i create a folder and place init the app image make it executable and run it from there 

 

Yes, that sounds good.

[EvilHag101 0]

Hi, I just started using the latest version of the armhf app image (5/10/2020). The software looks awesome and it self seems to be working fine, however when I want to start printing via USB (PI4) it doesn't seem to work properly. For example:

 

1. The LED's don't turn on as the printer starts moving (I programmed them to turn on when printing)

2. The print head doesn't move any material in the closer left corner of the build plate as it usually does be default before starting the actual print.

3. The print head doesn't move any material (at all) when it should be printing.

 

The build plate and print head look like they are following the gcode to execute the print but nothing comes out.

 

I have been using Ultimakers for a while on Windows so this is fairly new to me. If you have any suggestions please let me know.

 

[burtoogle 514]

Hello @EvilHag101. I've never used Cura to drive a printer using USB so I can't really help there. Have you tried using a different program to send the same gcode to the printer? Have you tried octoprint?, pronterface?

 

Anyway, could you please attach a sample gcode file produced by 20200510 to this thread so I can check it looks sane? Thanks.

[EvilHag101 0]

17 minutes ago, burtoogle said:

Hello @EvilHag101. I've never used Cura to drive a printer using USB so I can't really help there. Have you tried using a different program to send the same gcode to the printer? Have you tried octoprint?, pronterface?

 

Anyway, could you please attach a sample gcode file produced by 20200510 to this thread so I can check it looks sane? Thanks.

Thanks for your reply.UM2_Top_H20_Hex_SM_Fan40_Screws.gcode

 

I haven't tried other programs to send gcodes to the printer, perhaps that might solve the problem.

 

I included a gcode of a PI4 case I'm trying to print.

[burtoogle 514]

Thanks for the gcode file. When I look at that, I can't see any gcodes for setting the temperatures, is that because the printer handles all of the temperatures (and also the prime in the left hand corner)? Otherwise, the gcode looks pretty much what I would expect.

[EvilHag101 0]

4 minutes ago, burtoogle said:

Thanks for the gcode file. When I look at that, I can't see any gcodes for setting the temperatures, is that because the printer handles all of the temperatures (and also the prime in the left hand corner)? Otherwise, the gcode looks pretty much what I would expect.

I do believe the printer (UM2+) handles the temperatures after looking at it now. I've been comparing the gcode from the 20200510 version to my windows version (4.6.1). They seem to have slight differences in values but nothing major. 

 

I included the other gcode version if you are interested in taking a look.windows_UM2_Top_H20_Hex_SM_Fan40_Screws.gcode

[burtoogle 514]

Yes, although there's a lot of differences between those files, I can't see anything obviously bad in the 20200510 file.

[tinkergnome 927]

2 hours ago, EvilHag101 said:

when I want to start printing via USB (PI4) it doesn't seem to work properly

 

That's not related to the Cura version, but to the used gcode-flavor. Gcode-flavor "Ultimaker" and the led-setting on the printer require that the print is started from the printers menu.

 

 

[burtoogle 514]

Hi @tinkergnome, thanks for that input!

[EvilHag101 0]

Hi @tinkergnome, thanks for the info. @burtoogle thank you for taking the time to help me with this.

[loquin 0]

is there any way for this appimage version to save the cura settinngs?

[burtoogle 514]

It does save the settings into ~/.config/cura/master/cura.cfg. It also writes to files in ~/.local/share/cura/master.

[burtoogle 514]

Here's a tease of what I have been working on recently...

 

 

Yes, it's the simulation view running on the Pi 4 with working layer and line sliders. It doesn't look too bad from that angle but, unfortunately, looking from the side it is rather ugly...

 

 

So it's not really the full 3d view, but rather, a 2.5d view. The problem is that the Pi 4's graphics hardware isn't as powerful as most "grown up" computers and it's running out of resources when trying to render that view. I'm still working on it and haven't given up hope (yet) but it may be that a 2.5d view is the best it can support. I will make what I have here available in a future release. Stay tuned...

 

[burtoogle 514]

So, to recap, the problem is that the Pi 4's graphics hardware does not have enough resources to render the lines in the same manner as more powerful hardware can. It can display the line segments as 2d slabs rather than the 3d diamonds that is normal but as you see above, when viewed from the side, the slabs have no thickness.

 

I came up with a solution that works surprisingly well, it flips the orientation of the slabs as you change the view angle. So when looking at the scene from above (or below) it renders the lines as horizontal slabs. That's what is being done in my previous post. But when you look at the model from the side, it now renders the lines as vertical slabs. Obviously, as the view is tilted it flips from one orientation to the other but, it's not that disturbing and looks better than it sounds!

 

 

Anyway, if anyone wants to try this out, today's (20200523) release has this feature. You need to use replacement graphics libraries that I have packaged into mesa-21.tar.gz. Download and unpack that (sudo tar xzf mesa-2.1.tar.gz), it puts the libraries into /opt/mesa-2.1 so it won't overwrite any existing system files.

 

All feedback is welcome.

[icare 0]

Hi
It is starting to be at the top.
Thank you burtoogle for sharing

[burtoogle 514]

I have managed to workaround the various limitations and bugs in the graphic library and now have quite a nice display. It still has some compromises compared to the other builds (Linux/Mac/Windows) and it's definitely a bit sluggish if the model is large but for small models I think it's preferable  to the compatibility mode display. YMMV.