Your Astrobox is still booting up?

Well at least you are in…just don’t reboot ever again…:blush:

What I suspect is happening is for some reason the network link is not up before the astrobox service tries to start and verify its connection to the internet. From what I see after a quick look at the astrobox service handler it tries 10 times at 2 second intervals to ping google…If it succeeds in this then it launches the astrobox-init otherwise it attempts to start the access point service…we can see that the astrobox-init is at least being launched but the question is how does it think it is connected or not connected as the case may be.

so since you have a network cable I am guessing either it thinks it is pinging google when it is not or it times out and can’t reach google (why?) and is trying to start the wifi access point service after which the ethernet service seems to be ignored (though not by the system only astrobox)

Do you perhaps have a really slow responding internet connection or some other issue on the LAN that would cause this to time out?

If you are comfortable you might just try upping the astrobox service time out to 60 seconds or something by editing the service script…as I understand it that would mean it would try longer to get to google…before it moves on to trying to use the wifi access point.

All of this is just speculation on my part as I am not part to the astrobox coding team…

Arg.

The network is all CAT6 on a 1G fiber connection, pings to Google are < 10 ms so I don’t think that is it. Definitely something with the network boot though, I couldn’t transfer anything to the Pi until I manually set the date / time as well.

PING google.com (74.125.196.102) 56(84) bytes of data.
64 bytes from yk-in-f102.1e100.net (74.125.196.102): icmp_seq=1 ttl=45 time=4.33 ms
64 bytes from yk-in-f102.1e100.net (74.125.196.102): icmp_seq=2 ttl=45 time=4.37 ms
64 bytes from yk-in-f102.1e100.net (74.125.196.102): icmp_seq=3 ttl=45 time=4.31 ms
64 bytes from yk-in-f102.1e100.net (74.125.196.102): icmp_seq=4 ttl=45 time=5.36 ms

Next I got everything running but when printing I can’t set the temp for the head or the bed, keeps resetting them to way too low a temp. Despite the material (HIPS) having the correct settings. (it wants 140 when it needs to be 240). I drag the bar to 240 and it jumps back down to 140 after @2 seconds.

Thinking this just may not be for me, searching it seems many folks having similar issues. May just plug this into the laptop for now.

just for fun try a ping 8.8.8,8 (this is the google DNS and what astrobox seems to use)
should be just as fast but who knows?

On the temp issue…yes some people have had similar issues…I have had temps drop suddenly myself but only on rare occasions…I currently suspect USB issues but turning off is different from suddenly assuming a new temp. Are you using the astrobox cloud slicers you don’t have to…If you do have you tried to download the G-code and look at it or run it locally? Changing to a new temp sounds more like a G-code issue.

Curious if you go to the manual controls on the Astrobox panel can you move the slider for the extruder temp to 240?

Does it stay there and heat or does it jump back to 140? If it heats does your printer show the set temp, what does it show vs what the astrobox panel says? Do you know what firmware your printer uses? For sure now that you are in turn on serial logs in the settings on the astrobox and send them the astroprint guys after you get a failure…they have helped me with a few weird bugs along the way.

Honestly I really like astrobox and it is worth it, I think, once you get it going but yeah, if it is always getting in the way then I can see going back to the computer.

Ping to 8.8.8.8 from the Pi:

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=45 time=4.72 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=45 time=4.57 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=45 time=4.57 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=45 time=4.70 ms

On this connection I regularly get 900+Mb up and down.

I have tried going to the manual controls and I can indeed adjust the temps there and extrude some material manually. It doesn’t ping pong the temp back until I actually try to print.

Firmware is just the up to date stock LulzBot firmware for the Mini.

I have turned on the serial log but haven’t seen it populate anything yet, think I may restart the Pi and see if that helps with that.

The G-code may be the issue so I am going to try downloading it and looking at it like you advise. Again thanks for taking the time to help, you rock.

Found this in the g-code:

M140 S60; get bed heating up

Those are the values it keeps bouncing back to, is that a normal command?

so that command is to heat the bed to 60c…It not the extruder heat command.
It is part to the printer init in astroprint…this varies a bit with the slicer used…

but the basic idea is it heats the bed to 60c then once it is done it heats the extruder to the
proper set temp…I think cura does this a bit differently…but I mostly use sli3r.

look for the M109 S240

the M109 is the heat command the extruder S240 is the temp

Could you post the contents of this file?

/etc/astrobox/config.yaml

Sure, here you go. I got the gcode working and got it hooked up on WiFi. Still have to restart the service after restarting the Pi though.

camera: {}
cloudSlicer:
apiHost: https://api.astroprint.com
boxrouter: wss://boxrouter.astroprint.com
loggedUser: [REMOVED]
folder:
logs: /var/log/astrobox
timelapse: /AstroBoxFiles/timelapse
timelapse_tmp: /AstroBoxFiles/timelapse/tmp
uploads: /AstroBoxFiles/uploads
watched: /AstroBoxFiles/watched
serial:
baudrate: 115200
port: /dev/ttyACM0
server:
firstRun: false
host: 127.0.0.1
software:
lastCheck: 1472173760.698664
system:
actions:

  • action: shutdown
    command: shutdown -h now
  • action: reboot
    command: reboot
  • action: astrobox-restart
    command: service astrobox restart
    wifi:
    hotspotDevice: wlan1

That seems alright, It’s odd that there’s no log file here /var/log/astrobox when the config.yaml file is right. Could you try to send logs to us via advanced settings. There might be something there.