nanoDLP

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.

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.

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)