You are not logged in.
Pages: 1
Thanks! I'm up to my ass in work right now so I don't have the time to change it myself, sorry! I will keep the git repo hand though.
g.
Would it be possible to swap the locations of the Burn-in Layers parameters and the Normal Layers parameters? I suspect it would make more sense to users that way - they configure their first layers first, and the ongoing layers second...
Thanks!
g.
Thanks Shahin, that helps a lot!
g.
I'm working on writing a user guide for nanoDLP and I'm very new to SLA printing.
In the Printer Profiles page, there's a set of parameters for "Burn-in Layers". Are these settings used when printing the first layers?
Are the "Wait After" fields used in order to allow the resin in the vat to settle? If not, what are they used for?
Is the Wait Before Print and Wait After Print parameters describing the time delay where the projector is NOT exposing the resin?
What's the Mask File used for? Where would a person obtain one? (if you create them yourself, where is this process outlined?)
In the Motor Speed section, it has "Slow Section" parameters. I take it this is analogous to the slower speeds used by FDM printers when printing the first few layers?
What is Jump After Number of Layers used for? Does Number of Low Quality Layers indicate the number of times to execute this "jump" layer process?
Thanks all!
g.
It's not a RAMPS board. I'll try running it disconnected when I've got time.
tnx.
g.
It's not a RAMPS board, it's a Mini-Rambo running Repetier Firmware. No chance of using a different firmware.
I don't know why it sends the wait message, but you might want to add a configuration option to supress it from the log. I suspect it's a feature of Repetier Firmware.
g.
The only thing I've EVER seen after hitting ""Toggle Log" is a never ending repeat of "Data Received wait".
g.
I dug around and found various mentions of wlan0,
The first mention on boot is here:
Jul 1 18:19:21 raspberrypi systemd[1]: Starting ifup for wlan0...
There are previous entries from March 30th, but I suspect those were on the nanoDLP SD card image.
When I check the network interfaces via ifconfig, it shows wlan0, but it doesn't have an ip address associated with it. I'm not familiar with DHCP on *nix systems, so I don't know if that's the correct operation or not. It does appear to be obtaining an IPv6 address which is kind of wacky as I don't think my router is broadcasting anything other than IPv4 services. (Then again, it's Comcast, so those bastards could be doing /anything/.)
Here's the results from ifconfig:
eth0 Link encap:Ethernet HWaddr b8:27:eb:7f:6e:f6
inet addr:10.1.10.22 Bcast:10.1.10.255 Mask:255.255.255.0
inet6 addr: fe80::3ec0:c874:cafe:c2d6/64 Scope:Link
inet6 addr: 2601:603:1100:f600:39a3:6987:6fd1:31d4/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:22797 errors:0 dropped:5911 overruns:0 frame:0
TX packets:3664 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3000143 (2.8 MiB) TX bytes:825097 (805.7 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:640 (640.0 B) TX bytes:640 (640.0 B)
wlan0 Link encap:Ethernet HWaddr b8:27:eb:2a:3b:a3
inet6 addr: fe80::ba27:ebff:fe2a:3ba3/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:3614 (3.5 KiB)
g.
The application log is a never-ending litany of "Data Received wait".
I've never used a Pi 3 before, so I'm not sure what to go grepping for in the messages and syslog file. There IS a printer.log file that appears to contain dump data from a crash of some kind.
I can send that file your way if you want it.
g.
I'm working on writing up the documentation for the DropLit v2 and I'm having a problem getting WiFi operating with nanoDLP. It works great over the wired connection, but doesn't seem interested in operating with the built-in WiFi of the Raspberry Pi 3 that is being used. Any suggestions?
I've also noticed that the auto-update notification only updates nanoDLP to Build 1165 and the release notes show the current release as 1183.
Thanks!
g.
Pages: 1