You are not logged in.
Pages: 1
Looks good here on build 1357. Thanks!
OK, I can reproduce the problem here, but I was wrong about it being related to that particular .stl. The problem occurs when switching profiles and recreating the layers; and I can reproduce it using other .stls as well.
Reproduction steps:
Create a new plate using the .stl I provided above and the 40 um layer thickness printer profile. nanodlp successfully processes the plate and creates 113 layers.
After processing is complete, edit the plate and change the profile to the 25 um layer thickness one.
Then click on the 'recreate' button. With the thinner layers there will be a total of 180 layers, but when nanodlp passes layer 113 while processing the plate it will crash.
Creating a new plate using the same .stl and the 25 um profile from the beginning works fine.
I'd be happy to test .... but before you spend more time on it, let me upload the file again and make sure I can recreate the problem here! I should be able to do so in a couple of hours.
Here you go: https://drive.google.com/open?id=0B7y_A … mNXNU9SckU
(That's the file I got from clicking on the 'debug info' button on the tools tab of the setup page; I assume that's the info you're looking for. If there's anything else I can add, just let me know.)
Update: I went and deleted everything in the directory ~/printer/public/plates/6 (which was the offending plate) and am now able to run nanodlp again. I've also remeshed the offending .stl and uploaded it again, and it looks like it's slicing OK. So nanodlp was choking on something specific in the .stl linked above.
I have a plate with a single .stl on it that I have successfully printed at 40 um layers. I wanted to try printing at higher quality, so I set up a new printer profile with 25 um layers and changed the plate to use that configuration. When nanodlp attempts to slice the plate, it crashes.
I seem to be completely stuck now, because when I restart nanodlp it automatically starts slicing that plate again and then crashes at the same place. So I can't do anything else with the printer now. Is there any way out of this loop?
I've tried upgrading to the latest version, and the same thing happens.
I can't seem to attach files here, so here is a link to the log file: https://drive.google.com/file/d/0B7y_A8 … sp=sharing
And the .stl in question: https://drive.google.com/open?id=0B7y_A … zZYOUVHY1E
On Marlin issue: I've opened an issue on github, thanks.
On the second issue:
I can certainly sympathize with concern about supporting all the myriad firmwares out there. But I'm not sure how there could be a question about how many OKs should be recieved, because they're often used for flow control. If you send lines to the controller one at a time, each one should elicit an 'ok' or 'error' response. For many commands the response is sent as soon as the command is parsed, so if you haven't yet received a response from the last line sent, it is not safe to send another one anyway because the controller's buffer might be full. The only cases I can think of where the number of OKs is uncertain are fairly catastrophic ones, like sending an M112 while another blocking command like G28 is executing. (Doing so would break the rule of waiting for a response before sending another command anyway, so you could avoid such situations by design.) It should be expected that after issuing an emergency shutdown you'll lose sync and have to reset the connection to the controller.
The current alternative with the new keyword has its own problems. With the current solution, none of the common firmwares will work correctly regarding timing (dwell doesn't actually dwell), which is unexpected behavior. And the two custom firmwares that do provide sync don't even agree with each other. The custom Marlin version sends "Z_move_comp" after G1 commands (and is bugged), while the custom GRBL does not -- it sends the message after G4 commands only. Having to issue a non-move command to get the 'movement complete' message is certainly counter-intuitive.
Or maybe all that's really needed is documentation -- I had to dig through the source code of the firmwares to find out what really triggers the Z_move_comp message, and that's not ideal. The fact that there's a difference in behavior between the custom Marlin and GRBL firmwares is worth a mention somewhere.
I've got a couple more bugs/questions, hope it's OK to tack them on to this topic ...
First, there's a bug in the custom version of the Marlin firmware suggested for use with Nanodlp. (I'm not sure if this firmware is actually part of Nanodlp; if it's not your responsibility just say the word and I'll go open an issue on github instead.) The function that sends the "Z_move_comp" message back after every G1 command, on line 1017 of Marlin_main.cpp, is in the wrong place. It should go after the st_synchronize() function call on the next line. As it is now, the firmware sends back "Z_move_comp" as soon as the command is parsed, which defeats the whole purpose of patching the firmware. Swapping lines 1017 and 1018 causes the "Z_move_comp" message to be sent after movement is actually complete, as is desired.
Second, a somewhat larger-picture question: why bother with customizing the firmware in the first place? Standard gcode has ways of dealing with synchronization, such as the dwell command G4. G4 doesn't return an 'ok' until previously-commanded motion has finished and then the specified dwell time has elapsed. It works for all sources of movement (such as G28), not just G1. It seems to me that for gcode-based printers, nanodlp ought to wait for the 'ok' response after every gcode command it sends, and not move on until it receives it. (After all, not getting an ok, or getting something other than ok, indicates an error.) With that approach, any common reprap firmware or GRBL firmware could be used, and standard commands such as G4 could be used for synchronization without any extra internal-to-nanodlp commands or nonstandard responses needed.
Ah, that makes sense. I added a custom button for homing on that screen and that does the trick. Thanks!
Hi,
I'm in the process of getting nanodlp running on a Raspberry Pi 3 to run my LittleRP printer. I have a couple of questions / possible bugs:
First, to make sure the projector was working I kept trying (and failing) to display an image using the various 'display' buttons on the projector calibration tab. The problem, it seems, was that the directory ~/printer/public/plates did not exist initially, so the software's attempt to create a .png in that directory whenever I tried to display a calibration image failed. When I created a calibration plate that also created the plates directory, and ever since I've been able to display the calibration images with no problem. I was pulling my hair out for a while thinking I somehow nanodlp (or my system) configured incorrectly before I stumbled on that. It looks like that directory ought to be present as part of the installation. (btw, I installed nanodlp on an existing Rasbian installation using the 'Advanced Installation' instructions on the website.)
Second, I've been having some trouble with the move buttons on the z axis calibration tab and the current height displayed on that screen getting out of sync with the actual location of the build platform. (This is using a RAMPS board to control the z-axis motor, with the modified Marlin firmware installed, in absolute positioning mode.) The problem is that when I click on the floor button the software sends a G28 command to home the axis (which makes sense), but it doesn't update the current position to zero. So the next move after a home will move the platform relative to its position before the home, rather than its actual location (at z=0). I've adjusted the manual movement gcode template on the setup tab so that all other moves change both the actual printer position and nanodlp's idea of the position together, but I don't see any configuration to do the same with the move to floor button. Is there something I'm missing here?
Thanks,
Matt
Pages: 1