You are not logged in.
Pages: 1
hello Shahin ,
the system with official Nanodl card , so far it worked well , currently I get random print blocks , Raspberry and shield are powered independently,
thanks Andrea
dDebug file :
Offline
Have you changed gcode/codes I think synchronization is not right
Offline
I don’t know , I didn’t change anything, however I installed the latest version 4550 and so far everything is fine, thanks
Offline
unfortunately I sang victory too soon : with version 4550 I still get crash in the middle of print: https://drive.google.com/file/d/150oW1U … sp=sharing
Offline
probably the problem is related to resin profiles , which if derived from previous versions produce crash, but if recreated new seems to work well
Offline
Versions 4436, 4440, 4550 stop during operation!
Version 4356 works very well. Two printers work on this 4356 version.
I wrote a letter to Shahin contact@nanodlp.com with attached files, there was no response.
Offline
Versions 4436, 4440, 4550 stop during operation!
Version 4356 works very well. Two printers work on this 4356 version.
I wrote a letter to Shahin contact@nanodlp.com with attached files, there was no response.
Yes, I agree !! I also passed to 4356 and so far no crah has occurred
Offline
I do not see indication of crash on log file nor screenshot.
Maybe it does not go to the next step right? Specifically after this line?
2021-08-01 22:40:46.351369 {"Layer":"1354","module":"Terminal","level":"Notice","msg":"Received Data From Controller: ok↵"}
Can you find closer build number to make troubleshooting easier? 4356-4436
Vois,
Sorry missed your email.
Offline
I have checked your printer config, the configuration being used on your printer is not suitable for very short cure times.
Move whatever you have on shutter before and after (except delay) gcode boxes to before and after layer gcode boxes.
Offline
Thank you Shahin for your attention.
This is a test bench on which I check the work of all assemblies with the same settings. I have the Z, X, Y axes turned on.
the fact that all builds up to 4436 worked well. These 4436, 4440, 4550 stop half way.
Incorrect cure time settings did not cause stalls in versions prior to 4436.
Offline
Still not 100% sure that is the cause but it is probably the reason for printer stalls.
Recent build compiled with newer version of golang toolchain, so small timing difference caused it surface on the recent builds.
Offline
Hello Shahin!
On your recommendation, I changed the values in the settings. I checked it on Pi3, Pi4 boards.
Versions 4436, 4440, 4550 still freeze.
Unfortunately, I had to go back to the working version 4356.
Offline
Mandreas,
Do you still experiencing the same issue?
Offline
Mandreas,
Do you still experiencing the same issue?
Hi Shahin ,
I use the 4436 and so far all good, with later versions instead it happens that it accidentally stopped , not a crash , but does not complete a pass
Offline
Mandreas,
Did you tried workaround posted above on the latest builds?
Offline
Hello Shahin!
The latest beta 4661 still freezes. Did your recommendations..
Offline
Another update hopefully the issue get resolved. Still could not find why some user experience kind of freeze.
Offline
Thanks Shahin ,
I’m testing the 4708 with a new resin profile and so far it’s fine , I’ll update you
Offline
Unfortunately version 4708 also hangs. I ran it twice.
Offline
Yes confirm , 4708 frezee again..
Offline
Version 4724 also hangs.
Is that just the two of us happening?
Offline
Vois,
At-least for your case I found what causing the issue. It seems firmware you are using keep sending Z_move_comp for all gcode commands, many of them instantly.
This command should be send only for movement gcodes in order to sync movement.
Mandreas,
I think your case is different and much more random, I think it is timing related. If it rarely happens you can use timeout argument on [[WaitForDoneMessage ...]]
Probably movement is zero distance/short and response being send instantly which cause response to be received before actual [[WaitForDone...]]
Offline
Thank you Shahin i try that
Offline
Hello Shahin!
Did I understand you correctly, [[WaitForDoneMessage 2.3]] is this 2.3 seconds timeout?
Offline
Yes, but it is not good solution for your printer problem. You need to use better synchronization mechanism.
Offline
Pages: 1