You are not logged in.
Pages: 1
Seconded. The sound is annoying.
Use case:
As a general case, one has one type of resin in one's vat for a reasonable period of time, and one is using one X/Y/Z resolution for some amount of time. Therefore, when adding plates, it would be nice to not have to pick the current one you are using from the drop down every single time. It would be more convenient to set the default when you set up the printer, and then this will be the default selection when adding plates.
Thanks.
Sorry, I've been busy. I have been using build 1144, and successfully ran 2 prints each approx 1100 layers and 4 hours of print time, no crashes. This is dramatically improved.
Here is the printer.log from when it crashed.
Of note:
runtime: free list of span 0x71e92ac0:
0x118da680 -> 0x118db380 -> 0x10fe2d20 (BAD)
fatal error: free list corrupted
I thought Go was supposed to have automatic memory management so things like this didn't happen...
I've been having the same issue since about build 1131. Currently on 1140. Printer stops printing, Pi doesn't respond to http, but ssh and network are running. This is readily reproduceable for me. Let me know if there is anything you'd like me to test, otherwise I'm going to install 1144 and try that because people are reporting success....
I should note that the same setup was very stable before, so I don't suspect power other anything.
Your major features hit all my happy buttons. :-)
I'm happy to alpha test on Linux.
Excellent, thank you Shahin!
Do I take your "SLC files could be huge" statement to mean that the "you can't change the resolution" limitation is still in effect, but that anything that doesn't affect resolution should now work?
It may be appropriate to note that in the documentation of how the variables work - something like "LayerThickness is the thickness of the layer expressed in mm". That way, a user not using the variables need not be burdened with the additional knowledge.
Version: mUVe3D build 977
Bug:
When changing the profile applied to a plate, it doesn't regenerate the plates and is unprintable. The only solution is to delete the plate and re-upload it.
Expected behavior:
It would kick off a regeneration of the plate similar to what happens when it is freshly uploaded.
Notes:
There is a warning that you can't change the resolution for existing plates. However, that's not what happened in this case - ALL parameters were the same except the "after layer" GCode sent to the printer (I was testing old movement vs. new movement). Since the resolution hadn't changed, I would have expected this to just be instantaneously applied, since the GCode is generated on the fly.
An alternate approach here (perhaps as a stopgap) is, since none of it currently works:
1. Remove the "you can't change the resolution" warning.
2. Change the profile in the plate screen to not be a drop down, but rather be a fixed, unchangeable field.
NOTE: This may have been set in separately by mUVe3D. I'm not certain, and am including it here for completeness (also, allows other people to know that it has already been reported).
Version: mUVe3D build 977
Bug: LayerThickness internally converted to mm.
Description:
I presumed that:
[[LayerThickness]]would give me the user-input layer thickness in microns. However, when using the following formula:
H{[[LayerThickness]]/100}I get:
H0.0010in the output terminal.
Expected behavior:
Either it should be noted that the user input is internally converted from microns to mm, or it the variable should be in microns instead of mm.
FYI - if you want closer to real time performance, if you're not doing it already, look at man 3 sched_setscheduler, and set it to SCHED_RR or SCHED_FIFO (I like SCHED_RR) and set sched_priority to the value returned by sched_get_priority_min. Also make sure CONFIG_PREEMPT is set in the kernel config (fully preemptible low-latency kernel). That's the best I've found.
If you do this already, then ignore me. :-)
Also, the link is broken in the "is there any advantage to use" in the above FAQ.
I do embedded ARM systems as well, but you're right - the uptime figures I posted were for x86. My embedded systems generally have an even better uptime. But, they have to, since they run nuclear reactors and power plants. I don't have hard uptime figures for ARM, because I reboot mine too often. But, customers in the field only reboot them when the power goes out or they need to reload firmware.
Unless raspbian is using ksplice, kernel uprades will need reboots.
Further, if glibc is replaced (such as is going to be common given the recent glibc vulnerability) a reboot is best to ensure system stability, else some apps will be using the old version and some apps will be using new version.
Finally, I design highly reliable/available systems which run X11 and do not crash. The only time they get rebooted is when Ubuntu issues updates that require it (i.e. the /var/run/reboot-required file exists), which is about once a month. Based on my calculations, that is 99.988% uptime (30 days * 24 hours a day * 60 minutes per hour = 43200 minutes. Reboots take 5 minutes. 43195/43200 = .999884259. This is perfectly acceptable uptime for servers, and well more than enough for a printer, even a commercial one.
Please note - I'm not questioning your design choices, I think you made the correct ones with regards to NanoDLP. I'm questioning the rationale behind it.
The last point, reliability, is actually wrong. First, it could be more accurately be termed "availablility", not "reliability". Second, as it is based on raspbian, and raspbian does get updates, users should periodically ssh into the box and do:
sudo apt-get update
sudo apt-get dist-upgrade
sudo shutdown -r now
to fetch and apply updates, then reboot. Failing to do so leaves security vulnerabilities unpatched. If your machine never connects to any computer networks, then you don't need to do this (and, indeed, can't because it requires a network connection to do so), but otherwise you still have a nonzero attack surface.
I'd think the mUVe3D forums would make the most sense for announcing new versions. :-)
Pages: 1