Configuring for External Connection
Having issues connecting from an external network. I have tried adding a port forward in my router as the guide suggests. However it gives the example of "map port 2000 to 192.168.0.22". My router only lets me map to 192.168.1.6 instead of 192.168.1.6:3344. I have tried entering my external ip of (example, not my actual ip) 170.143.25.24:2000 on my mobile device on a cellular network. No connection.
Please advise.
Please advise.
Comments
https://www.amazon.com/gp/product/B071NYSXY9/ref=oh_aui_detailpage_o04_s00?ie=UTF8&psc=1
For webcam you shoudl omit < and > in the ip and bette ruse 127.0.0.1 as ip.
Do you see the webcam in printer settings->webcam?
If you see it there and not in the normal surface, please select to only have jpg and not mjpg with refresh rate 1s. There is a bug in server that breaks mjpg if http headers have "wrong" capitalization. We have fixed that already for next release. Then mjpg with stream will work again.
I have a creality cr10s with marlin 1.1.8.
I accessed the server from my computer and phone before leaving for work, also trying the server on my mobile connection to make sure it was working. Maybe this somehow upset something? Things seem to bug out when jumping between my wifi and mobile connection. I don't see how accessing the server should upset a print. My pi has a 2.5a power supply so it shouldn't be an issue with power.
A well known problem of Raspberry PIs is that they like to disconnect usb if voltage drops down below some level and require good 3A power units to be on safe side. But in that case server would reconnect and stop print completely and not just add a shift. Also I'm not 100% sure if it does not reset printer as then the "start" is missing in log and server might not notice.
So lets assume server worked well (you can also enable logging to see if anything special happened on shift time). Then it is a firmware/hardware issue. A typical reason beside blocked motors from high speed/acceleration or hitting some hard pla so it looses steps is crosstalk to endstops causing a skew away from the endstop. I think you can disable endstop testing in marlin during print to remove that possible cause. But best is to observe when it happens to get an idea what is going on along with log analysis of that exact time.
Web connections and print run in different threads so they should not interfere even if web communication takes a while to reconnect for example. And even if server would stop sending commands for a while it would now skew print as firmware will just halt until next commands get send.