You are not logged in.
Pages: 1
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
Offline
Hi Matt,
Thank you for the bug reports.
I have fixed the number one issue.
But the second issue is much harder to solve as we do not know which kind of firmware user is using and if she/he relies on nanodlp to keep position or not.
What you can do is to add custom button from the setup page to send both G28 and zero the position.
Offline
Ah, that makes sense. I added a custom button for homing on that screen and that does the trick. Thanks!
Offline
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.
Offline
Please, report the issue on github. I do not maintain the marlin version.
No, nanodlp does not wait for OK. The issue is that we are not sure how many OK we should receive and also if the board run gcode command one by one or some commands could have priority (M112).
We could solve the mentioned issue using N command.
N10 G4 Z2
But still it needs to be tested with individual firmware so instead we decided a new keyword at-least could prevent any confusion for nanodlp movement sync compatibility.
Offline
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.
Last edited by Mattasmack (2017-02-12 21:41:13)
Offline
Hey Mattasmack - re the manual movement gcode field - what did you end up using there? It's certainly a frustrating issue with the position not updating when zeroing out at bottom/top with an endstop!
Offline
Pages: 1