Prusa... The basics! Work on the basics.  

RE: Prusa... The basics! Work on the basics.

I agree with what you are saying but...

Up until recently I was a developer working on web applications (not web pages), one problem you have in developing this sort of app is no matter how much you test you have a finite set of setups to test with but as soon as you release to the wild someone will have a configuration that stresses the app in a way that you have not tested and finds a hidden bug. The problem is there are millions of different setups out there and it is not possible to test them all, the majority of people work fine so it is probably something slightly different with your setup. Having said that, I still think you should complain to Prusa about it, if they are half decent they will use your problem to make the program more robust for everyone.

RE:

A big part of the issue is that Prusa has not leveraged good enough hardware which comes with hardened TCP stacks and other communication protocols (encryption,etc) that one needs. Because they use a $5 wifi board, and a buddy board with, I think, zero ram (they need the USB stick as a buffer), they are just killing themselves. Their basic PING routine hasn't worked on the XL/mini/MK4 since inception, because instead of using an OS with it all baked in, they are configuring openSource libraries incorrectly then never getting time to go back to fix. There is no excuse for it. Bambu has it right.. it comes down to using the right hardware combined with an existing OS.. and having highly skilled developers in the area necessary. Bambu is a case-study for what you can do in a short time, with the right people.. not that they don't have their flaws.. but they've been more productive than Prusa with fewer issues over the past year or two. Prusa may kill them in the long term as I think Prusa are definitely in it for the long haul. Bambu doesn't have that test of time yet. That team pulled out of DJI after several years.. maybe they will leave Bambu.. I have an MK3 with Octoprint and my TCP communication is flawless.. because it's underpinnings is a RP4 with linux with all the comm stuff having years of development by the open source community to get it right. Lots of people developing products undervalue developed/tried & tested software opting for a $5 ESP ... and then spend forever fixing bugs when they need to reinvent all the wheels that hundreds of people did years ago. Lack of ram on the Buddy and lack of a linux comm board for their Wifi& Ethernet is causing overload for their existing staff, who need to mostly develop firmware for the printing hardware, which is unique. You just need to look at the 3.12 and on release of firmware for the MK3.. it killed so many's printer.. some because there were thermal problems on the units introduced by the users.. but many from firmware bugs.. I don't dare upgrade for what I might have to upgrade on my unit.  So some criticism is warranted.. Now much of above is opinion based on my experience in engineering design firms from years of work.. so I'm guessing on some details.. and I don't mean to undervalue their existing staff.. they have done amazing work.. but they are developing too much software on their own, with too few people, with perhaps not all with the optimum experience set.. and it becomes an impossible task to maintain.

The "Chinese" are not the threat to Prusa.. its not a "Country" or culture issue.. Bambu is a reflection of their particular engineering staff.. which apparently are highly skilled in areas pertinent to developing these types of products. 

RE:

Right now this is rather a unfortunate result of few factors:

- firmware limitations - esp devices, boards with low memory and libraries, ends in problems with the network stack, I believe they are really aware of that and they are working on it. There may be some help for certain setups with additional network producing between the printer and PrusaConnect.

- hosting issues - looks like their current hosting provider may not be able to cope with the networking and this ends in various issues, especially with lost TCP sessions, some of those may be mitigated, that's why there were moments when they literally dropped camera images so that other parts would work. In addition seems like USA is getting some requests via proxy that sometimes get additional performance issues, I guess this is also being handled.

- scale - probably too fast and too many people joined and the platform was not ready for it, and we can see issues multiplying

I just hope they gonna throw in some smaller rpi device just to make it work better in overall especially with PrusaConnect.

Personally I just prefer everything local, and maybe one day PrusaConnectLocal could be done? From what I intercepted from the traffic then reverse engineering of the API calls is quite easy to reimplement. The devil is in the API version per printer model probably.

RE: Prusa... The basics! Work on the basics.

- firmware limitations - esp devices

Using the Ethernet connection on the xBuddy board eliminates this. A cheap WiFi extender with an Ethernet port would be something to try if the printer is beyond cable length. Those have better antennas and stronger receivers . That would get rid of the short range of the ESP-01 which is being used as a WiFi-to-Ethernet bridge. Using an Rpi as the WiFi-to-Ethernet bridge could work as well if there's one of those available (rpi3 would need a WiFi dongle, rpi4 or 5 not). 

RE: Prusa... The basics! Work on the basics.

esp device is a cheap wifi extender 😉

RE: Prusa... The basics! Work on the basics.

Posted by: @_kaszpir_

Right now this is rather a unfortunate result of few factors:

- firmware limitations - esp devices, boards with low memory and libraries, ends in problems with the network stack, I believe they are really aware of that and they are working on it. There may be some help for certain setups with additional network producing between the printer and PrusaConnect.

- hosting issues - looks like their current hosting provider may not be able to cope with the networking and this ends in various issues, especially with lost TCP sessions, some of those may be mitigated, that's why there were moments when they literally dropped camera images so that other parts would work. In addition seems like USA is getting some requests via proxy that sometimes get additional performance issues, I guess this is also being handled.

- scale - probably too fast and too many people joined and the platform was not ready for it, and we can see issues multiplying

I just hope they gonna throw in some smaller rpi device just to make it work better in overall especially with PrusaConnect.

Personally I just prefer everything local, and maybe one day PrusaConnectLocal could be done? From what I intercepted from the traffic then reverse engineering of the API calls is quite easy to reimplement. The devil is in the API version per printer model probably.

Im pretty tempted to try reverse engerneer prusalink and connect to run on rpi do you think a pi4 could handle prusa connect.

RE: Prusa... The basics! Work on the basics.

Before reverse engineering it, look to see if the code is in githug

https://github.com/prusa3d

RE:

AFAIR PrusaConnect is closed source, but should be very easy to map the api, see my github repo about 3d print, there is a prusa connect proxy project that can dump everything than goes in and out.
Printers send POST requests with telemetry like temperatures etc and contents of the sd card.
In response it gets json wrapped commands for example to download gcode file from the net or pure gcode to run such as G1 X0 Y0 and so on.
There is nothing special in it

Of course backward mapping api would be quite easy (I bet someone already did it in BambuLabs and other ;P)

RPI4 would handle it without a problem, I believe even RPI Zero W (single core) could do it because there isn't much to process on the PrusaConnect:
- receive telemetry and write to the metrics db, if you can forward it further it can be handled with something like prometheus/victoriametrics/timescaledb/influxdb or just mysql/postgres without an issue if you set time tables to for example 4h
- receive camera images - this is mainly io

While api mapping is easy, of course writing all of it as standalone app to be compatible is another story, especially if we want to support different printers.
The app stack is probably more complex suich as having some queues etc and that may need RPI4 with a bit more memory, but I guess 2GB for evertyhing (with metrics and image hosting) would be doable, of coruse for only one printer, how it would scale, depends 😉

RE: Prusa... The basics! Work on the basics.

Posted by: @_kaszpir_

AFAIR PrusaConnect is closed source, but should be very easy to map the api, see my github repo about 3d print, there is a prusa connect proxy project that can dump everything than goes in and out.
Printers send POST requests with telemetry like temperatures etc and contents of the sd card.
In response it gets json wrapped commands for example to download gcode file from the net or pure gcode to run such as G1 X0 Y0 and so on.
There is nothing special in it

Of course backward mapping api would be quite easy (I bet someone already did it in BambuLabs and other ;P)

RPI4 would handle it without a problem, I believe even RPI Zero W (single core) could do it because there isn't much to process on the PrusaConnect:
- receive telemetry and write to the metrics db, if you can forward it further it can be handled with something like prometheus/victoriametrics/timescaledb/influxdb or just mysql/postgres without an issue if you set time tables to for example 4h
- receive camera images - this is mainly io

While api mapping is easy, of course writing all of it as standalone app to be compatible is another story, especially if we want to support different printers.
The app stack is probably more complex suich as having some queues etc and that may need RPI4 with a bit more memory, but I guess 2GB for evertyhing (with metrics and image hosting) would be doable, of coruse for only one printer, how it would scale, depends 😉

Hmm yes could we not have a "middle man device" like a seperate device that we can get prusa connect to go to first then the printer and log everything on that

RE: Prusa... The basics! Work on the basics.

That's what I was talking about in the first sentence, here's url https://github.com/nvtkaszpir/3d-print/tree/main/prusa-connect-proxy to the project.
But that's just a proxy, nothing else.

RE: Prusa... The basics! Work on the basics.

Posted by: @_kaszpir_

That's what I was talking about in the first sentence, here's url https://github.com/nvtkaszpir/3d-print/tree/main/prusa-connect-proxy to the project.
But that's just a proxy, nothing else.

Oh right, i did try to find it on your github but prusa connect gave no matches.

RE: Prusa... The basics! Work on the basics.

Hey, i agree that Connect should work better in the USA. I am interested in some traffic stats. Like, how many packets arrive out of order or corrupted? What is the ping time, jitter and so on. If i get these details, i will make a box that makes the connection to prusa servers as bad as it is for you guys and i'm hopefull, something would get done about it then. Where do i find USA -> EU -> USA packet statistics?

RE: Prusa... The basics! Work on the basics.

I believe you would need to set up custom black box exporter or something like that on your own infra, something that simulates basic user or printer.

But with packets out of order that may need more in depth metrics, on dedicated tiny virtual machine for example.