Plans for supporting Spaghetti Detective?

AstroBox Feature Requests
#1

I’ve recently started printing larger prints and I’ve had a few spaghetti-related incidents. Smaller prints work just fine as it seems that layer adhesion and shrinkage can be kept to a relative minimum.

So, I’m in the process of upgrading my setup to add:

  • Heated Enclosure
  • Optimized heat settings for layer adhesion on larger prints
  • Optimized speed/jerk/acceleration settings for larger prints
  • Filament Runout Detection

However, I’ve been looking into getting a subscription to the Spaghetti Detective to stop my prints earlier than I can get to them.

https://www.thespaghettidetective.com/

Are there any plans to add plugin support for Spaghetti Detective like the one for OctoPrint?

#2

Not on the astrobox but you can use octoprint with our plugin: https://plugins.octoprint.org/plugins/astroprint/

1 Like
#3

Thank you for your response, Daniel.

After a few years of using OctoPrint, modifying Raspberry Pis to have all the bells and whistles, I’ve decided to go with a bit more reliability and simplicity. Just recently flashed the AstroBox Touch firmware and got everything but the drivers on the touchscreen working (bought the wrong unsupported touchscreen, hacking the drivers presently).

In any case, printing through the AstroBox Touch was more (IMHO) intuitive and reliable than anything I had built through OctoPrint. I had many failed prints and failed connections using the same hardware (RPi 3b, 3A PS, 128GB SDXC, Sony PS3 Eye, 1.5ft gold plated USB cables with choke). I bought a touchscreen (just saw the manufacturer and not the supported size) flashed the AstroBox and license, enabled ssh (changed passwd) and everything was working right out of the box. Phone and web connectivity right from my account. Prints good (no disconnects, errors) right out of the box.

Currently I’m using the 3d Printer as a teaching tool for my son (7 years old) and I’m looking to simplify and up the reliability of his 3d printing and modeling workflow. He can now do his entire workflow from Astroprint, not have to go through Cura, Slic3r, tinkercad, leopoly, OctoPrint, etc.

For clarity, I’m a supporter of both OctoPrint and AstroPrint as I believe they are great platforms. For the audience (kids) that I’m trying to work with, AstroPrint is the single app workflow that I was looking for.

In any case, it would be great to see if AstroPrint would be able to support the Spaghetti Detective directly, but I do have a spare RPi 3b+ that I could flash with OctoPrint + AstroPrint + Spaghetti Detective. For some reason that setup I had before had connectivity and reliability issues and flashing AstroPrint directly solved them.

In any case, thank you @Daniel for your reply.

#4

Thanks for the explanation @Dylan_Dawg.

#5

Interestingly, I can’t. Astroprint on Octoprint can’t seem to access the camera when I’m using the spaghetti detective. Turning TSD off reliably brings back Astoprint video functionality. Going to ask the TSD folk about this also, but any ideas about this or how I might look into it?

#6

Awesome thought @jermops! The way TSD is implemented may require dedicated access to the camera when operating. That’s all I can think of right now. Maybe there’s a way for the device (camera) to be shared if TSD only needs images intermittently.

There may be a way to to integrate the software if you’re running a TSD server on your network. It may take a bit of hacking, but with the source code, it may work.

#7

@Dylan_Dawg

So, I don’t know what caused the ultimate issue, but this turns out to not be an actual incompatibility.

Astroprint was complaining that it couldn’t connect on 127.0.0.1:8080, which of course is ipv4. That lat bit is important in a minute.

The snapshot setting uses localhost:8080, and though testing, I found that curling localhost:8080 worked, but curling 127.0.0.1:8080. /etc/hosts has ipv4 and ipv6 entries, so anything that speaks ipv6 should figure that out, and curl was.

Checking netstat, i indeed found that, for some reason, port mjpg_streamer was only listening to ipv6:8080, and not ipv4:8080

As to why astroprint didn’t work and TSD did… the only thing i can figure w/o a deeper dive is that astroprint is using the requests library, which uses urllib3, and TSD is using urllib2 directly. Too busy at the moment to shave that particular yak all the down, but…

Restarting mjpg_streamer made it start listening on both interfaces again and everything works wonderfully now. I swear i tried reboots in the past, and even tried another one after getting it working with a process restart, just in case there were some weird condition on startup that would have caused this… but it’s all working together happily now ¯_(ツ)_/¯

#8

OctoPrint comes configured with the snapshot url as http://127.0.0.1:8080/?action=snapshot. You can change this in settings to http://localhost:8080/?action=snapshot.

ss
ss.png965×378 47.8 KB

using localhost should resolve to both ipv4 and ipv6 and even if mjpg_streamer only opened the ipv6 interface it would work.