Local connection works, but not connect.prusa3d.com  

RE: Local connection works, but not connect.prusa3d.com

I reflashed the SD and set it up again. Works perfectly. 

RE: Local connection works, but not connect.prusa3d.com

Hi, sorry for the bug, the re-register button for these kinds of situations is coming, hopefully in the next version. Thank you

RE: Local connection works, but not connect.prusa3d.com

@Tojik: Same here. Works locally, but remotely I am prompted to add a printer. Locally it tells me it is connceted to Prusa Conncet. Any idea how to solve this?

RE:

Honestly, I have forgotten all the quirks of that version by now. I think, it's just broken and says garbage when the connect registration fails. The fastest way to re-try on 0.6.1 is to remove the prusa_printer_settings.ini file. That is on the raspi. To do that, Turn on SSH on the raspi by placing an empty file named "ssh" into the boot partition of the pi SD. After booting use FileZilla or any other SFTP client to connect to your raspi file system. The address is your raspi's IP address, the user is named "pi" and the default password is "raspberry". Navigate into /home/pi and remove the file, reboot the pi and go through the wizard again. Make sure you're logged into Connect beforehand, to make sure that part of the process has no chance of breaking.

Feel free to ask, if you get stuck in any of this. Alternatively, re-flashing is also an option.

in 0.7.0, there will be a re-register thing in the settings, so this whole detour should be avoided 🙂

RE: Local connection works, but not connect.prusa3d.com

Hey Tojik,

thx. Bloody hell, enabling SSH was discouraged in the help files. I already had a bad feeling about it. Judging from the default password... ok, I'll give it a try. So, it is a vaniall rasbian os with some scripts installed?

Any idea which ports for communication are used in case this was the root problem?

Cheers,

huskyte

RE:

We talk to connect over http(s) and there is a way around not being root for serving you the local web interface on port 80. So I doubt it would be a root issue.
Yes, enabling the SSH should be discouraged and you should change your password. It takes only one compromised thing in your network to make having the SSH enabled with a default password a bad idea. This is a work around, and as it's faster and more interesting than re-flashing the SD image, I tend to give out this one.

RE: Local connection works, but not connect.prusa3d.com

Ok, enabled ssh, but while doing that reflashing was even faster. The first MK3s works like a charm. It would be nice Prusa supplying the correct headers. The length is quite odd. On the other hand RPi 2 W are even more rare, but the old WH don´t seem to have trouble (with the current functionality). 

Tomorrow I will add the second one and see if I have success the first time round. Lets see. 

A pity that the Minis aren´t supported just yet (after 2 years of service 😉 ). Anyway, thanks so far

RE:

Second printer up and running. Had some hiccups with the first. Stopped midprint (froze), no heating iniated abort even after some hours. Is there a way to get into the logfiles and troubleshoot this? Funny enough, reprinted the gcode out of the online interface (again?, see below), same happened, but a different timepoint. Recliced it and printed a third time: Perfect. I cannot really remember, but might be that the first print was already the second and may have been printed out of the interface (didn´t pay attention). Is there some known issue with starting the print out of the interface?  

Add: Without a camera you are well lost as no error was shown in the interface.

RE: Local connection works, but not connect.prusa3d.com

Hi, yes, the local web interface has the option to download the logs. It's under settings. The interesting one is syslog.log

This is most likely one of my bugs, the gcode sender has a chance to get outran by the printer. Expects to find one gcode, that has not been confirmed by the printer yet. There is a missing condition for the case it has. The error message says something like "pop from an empty queue"

Sorry for that. Also, I assume you use the rpi zero W (not 2). I think and hope it happens less on those.

Thanks for the info, if the log says something different, or you simply feel like, send away 🙂