You are not logged in.
So this is odd....
I left my printer churning out a model when I left home....
I am now checking it remotely (it should be nearly done now with the full design 200 layers)
(I can tunnel into my home network so I am not using the remote monitoring feature as I never really understood how that is supposed to work)
So I have tried from two different browsers....both show the same thing...the main NanoDLP screen shows that it is printing layer 100,
while the plate screen shows that there is no job printing...I tend to believe the plate screen as the nanodlp screen does not seem
to be progressing...like it got stuck at 100...
Lot shows it is printing layer 100 and stuck at transferring data...maybe I had a com failure?
I am going to try a remote reboot and see what happens....
I have not had the best of luck issuing restart commands and having it work but who knows maybe it will ... or maybe it will tell me it is still printing and I can't restart.
Edit: well nanoDLP tells me I can't restart during a print....so it thinks it is printing I guess...I have ssh to the Pi and I am poking around...I can probably reboot it from here if I want.
Update: I looked at the logs and it does seem to have died on layer 100. Manual reboot via ssh and now I seem to be able to resume print...going to give it a
try and see how it turns out....not a critical things just doing some calibrations tests,
I did see this in the log:...Hmm there was some gibberish in the log when look at it, but it seems to not display when I copy it here.
Debug 101 2017-04-14 18:40:07.412699 Printing Curing for 20 seconds
Warning 101 2017-04-14 18:40:07.149986 Image Display layer public/plates/12/101.png
Notice 101 2017-04-14 18:39:55.157001 Terminal Received Data From RAMPS: Fanspeed:255
Debug 101 2017-04-14 18:39:55.156928 Gcode Transfering Data
Info 101 2017-04-14 18:39:55.156891 RAMPS Sync Ready for the next RAMPS movement
Notice 101 2017-04-14 18:39:55.156806 Terminal Received Data From RAMPS: Z_move_comp
Info 101 2017-04-14 18:39:55.156674 RAMPS Sync Done message from RAMPS has been received
Notice 101 2017-04-14 18:39:55.15659 Terminal Received Data From RAMPS: ok 0
Info 101 2017-04-14 18:39:55.149897 RAMPS Sync Waiting for done message from RAMPS
Notice 101 2017-04-14 18:39:55.149869 GPIO Set Pin 26 to High
Debug 101 2017-04-14 18:39:55.149752 Gcode Transfering Data M106 S255
Debug 101 2017-04-14 18:39:55.149442 Shutter Shutter Open
Info 101 2017-04-14 18:39:55.149188 RAMPS Sync Ready for the next RAMPS movement
Notice 101 2017-04-14 18:39:55.149055 Terminal Received Data From RAMPS: Z_move_comp
Info 101 2017-04-14 18:39:55.148902 RAMPS Sync Done message from RAMPS has been received
Notice 101 2017-04-14 18:39:55.148821 Terminal Received Data From RAMPS: ok 0
Info 101 2017-04-14 18:39:53.153628 RAMPS Sync Waiting for done message from RAMPS
Notice 101 2017-04-14 18:39:53.153584 Terminal Received Data From RAMPS: Z_move_comp
Debug 101 2017-04-14 18:39:53.153536 Gcode Transfering Data
G4 P1
Info 101 2017-04-14 18:39:53.153314 RAMPS Sync Ready for the next RAMPS movement
Info 101 2017-04-14 18:39:53.153086 RAMPS Sync Done message from RAMPS has been received
Notice 101 2017-04-14 18:39:53.14948 Terminal Received Data From RAMPS: ok 0
Info 101 2017-04-14 18:39:53.14371 RAMPS Sync Waiting for done message from RAMPS
Debug 101 2017-04-14 18:39:53.143495 Gcode Transfering Data G1 Z10.1 F1500 P1 ; Move to layer position
Debug 101 2017-04-14 18:39:53.129832 Gcode Transfering Data
Info 101 2017-04-14 18:39:53.129731 RAMPS Sync Ready for the next RAMPS movement
Notice 101 2017-04-14 18:39:53.129471 Terminal Received Data From RAMPS: Z_move_comp
Info 101 2017-04-14 18:39:53.1292 RAMPS Sync Done message from RAMPS has been received
Notice 101 2017-04-14 18:39:53.129071 Terminal Received Data From RAMPS: ok 0
Info 101 2017-04-14 18:39:53.124915 RAMPS Sync Waiting for done message from RAMPS
Notice 101 2017-04-14 18:39:53.124847 GPIO Set Pin 26 to Low
Debug 101 2017-04-14 18:39:53.124509 Gcode Transfering Data M107
Debug 101 2017-04-14 18:39:53.123928 Shutter Shutter Close
Debug 101 2017-04-14 18:39:53.123846 Image Clear screen
Debug 100 2017-04-14 18:35:43.533241 WiFi Connected to Darren's Wifi
Debug 100 2017-04-14 18:35:38.420735 Gcode Transfering Data
Notice 100 2017-04-14 18:35:38.420577 Terminal Received Data From RAMPS: Z_move_comp
Info 100 2017-04-14 18:35:38.420554 RAMPS Sync Ready for the next RAMPS movement
Info 100 2017-04-14 18:35:38.420334 RAMPS Sync Done message from RAMPS has been received
Notice 100 2017-04-14 18:35:38.420188 Terminal Received Data From RAMPS: ok 0
Debug 100 2017-04-14 18:35:38.414458 Gcode Transfering Data M107
Notice 100 2017-04-14 18:35:34.324218 Terminal Received Data From RAMPS: FlowMultiply:100
Notice 100 2017-04-14 18:35:34.324013 Terminal Received Data From RAMPS: SelectExtruder:0
Notice 100 2017-04-14 18:35:34.320241 Terminal Received Data From RAMPS: Free RAM:4962
Notice 100 2017-04-14 18:35:34.320085 Terminal Received Data From RAMPS: Detected EEPROM version:17
UNKNOWN 2017-04-14 18:35:34.316353 {"Layer":"100","module":"Terminal","level":"Notice","msg":"Received Data From RAMPS: istart↵"}
Warning 100 2017-04-14 18:35:33.57074 WIFI Connecting to Darren's Wifi
Debug 100 2017-04-14 18:35:33.526513 WiFi Status Monitoring
Warning 100 2017-04-14 18:35:33.526343 WIFI WIFI interface wlan0 detected
Last edited by macdarren (2017-04-14 18:47:52)
Offline
Go to setup page/ tools tab/ click debug button. I am not sure what could have caused this issue.
Offline
Offline
I am not 100% sure as debug file mostly contains after restart log report. But based on available log data, it looks like printing stalled waiting for Z_move_comp.
So the most probably it is an serial communication issue between RAMPS/RPi
Offline
That was my guess too....I will see if I can learn more when I return home and inspect the print and printer....maybe something is loose or I have perhaps a bad power supply...I'll post if I find anything or it the problem happens again.
Thanks for taking time too check...oh and I like the search box.
Not sure how to get rev 1393 mentioned in the change log discussion (I tried both release and beta) but seems to work in 1392.
Offline
You are right, I have forgotten to push 1393. Pushed 1395.
Offline
Ok, I had serial communication issues with 1392, now with 1395 they are gone.
Thanks.
Offline
Hmmm just had what appears to be the same thing happen again in 1395...this time printing the calibration plate at layer 29
https://www.dropbox.com/s/1h7r7xc82jkgr … 2.zip?dl=0
https://www.dropbox.com/s/32j7bzgqozbb6 … M.png?dl=0
I am wondering now if this com err might account for my Z height errors that I have been having the last few days...
I thought I had it all dialed in but the last couple objects showed flattened circles in the vertical axis and overall height reductions.
Could I some how just have missing layers or cure time fails? The Z axis seems to move correctly when I test and previous
test objects had correct z Heights.
Last edited by macdarren (2017-04-16 16:14:23)
Offline
Cropduster,
No change between 1392 -> 1395 on RAMPS sub system
Macdarren,
Do you experience this issue only on auto calibration plate?
Offline
back with 1392 it was my own model that stopped at layer 100...so far with 1395 the only time it has stopped was with the calibration plate, however two models I have printed with 1395 both came out about 5-10 percent shrunk in the Z axis....I am doing another different calibration plate right now so I will report my findings when it finishes. I will then do a long tall object to see if I can find where the z shrink is coming from.
Offline
second calibration plate failed different place and I see an error in the log this time....I will post a link to the pre reboot debug file when I can.
https://www.dropbox.com/s/lltcydpgi8ymh … 6.zip?dl=0
Last edited by macdarren (2017-04-17 03:13:15)
Offline
The error message is related to your external script called lcdmsg.py. It being called by following code in your profile.
[[Exec lcdmsg.py --msg="Lifting to {[[LayerPosition]]+[[ZLiftDistance]]}" --line=2]]
Quite interestingly it works for some layers and on some layers it fails. I am not sure about the reason, maybe processes stalled. Anyways it is out of nanoDLP control you need to troubleshoot this script from bash terminal.
Another issue which I am seeing in your configs are excessive [[WaitForDoneMessage]] usage. You need rewrite atleast shutter gcode boxes.
NanoDLP could not recognize where the Z_move_comp is coming so in some cases Z_move_comp for shutter could cause movement on z-axis. Make shutter only works at the start and end of print and see if improve things.
Between 1392,1395 nothing inside core changed. (mostly html,css,js staff changes)
Offline
Thanks for the analysis, I will try to clean things up especially the shutter code and see if I can get a good Z print...
Offline
I didn't really write the Printer Setup so I am not 100% certain what it is doing but I have been looking at it.
My printer is an Arduino driver/Repetier Firmware LCD based unit...the Shutter open and close corresponds to the LED UV source being turned on and off with each exposure (M106,M107).
This is why it happens every frame.
I think all the [[WaitForDoneMessage]] are there to simply wait for the Arduino to complete the command and send an acknowledgement..this seem reasonable but maybe I am missing something.
I know some people just use a fixed delay..and I could probably skip the wait and the delay in the case of the shutter/LED commands it happens near instantly.
Not sure if nano would have a problem with the acknowledgement messages coming in even if there was no explicit wait for them to do so.
I don't quite grasp what you were saying about the WaitForMessage and the Z_move_comp and how the shutter could case Z movement.
I don't think the LCD stuff is really important as the only LCD is the exposure plate and that is driven by the Pi/nanoDLP directly...So I imagine I can remove that external script call.
Offline
I have been running that same setup for over a month if not longer. The repetier firmware returns the z_move_comp for each command just like Marlin did so I am not sure what happens if you don't look for that message after the M106 / M107 command is sent? Will things get out of sync because a z_move_comp is being sent in but not specifically looked for? The lcdmsg and pushover messages can be removed and I have found they they don't seem to impact anything if they are not configured and send back an error. Someone else had a similar issue, if not the same person posting and after hours of troubleshooting and many questions and even reloaded a pre-configured sd image, it turns out he kept setting the wait before and wait after move times to 0 and that was causing some sort of lockup every print. Once he put back in the default values it started working.
Offline
Let me explain the logic.
For each [[WaitForDoneMessage]] command, program fully pause things until receiving Z_move_comp.
But what happens if we have async commands. Lets say both shutter gcode and before layer gcode being sent together. (nanoDLP does not run all command in serial mode, some of the being sent in parallel)
1. Both gcode box being processed (before layer and shutter open)
2. Both see [[WaitForDoneMessage]]
3. One of commands on RAMPS (before layer) cause RAMPS to send back Z_move_comp
4. Printer start working again
5. Another command sent and [[WaitForDoneMessage]].
6. Shutter gcode just send back Z_move_comp
7. NanoDLP thinks this Z_move_comp is about current [[WaitForDoneMessage]] in before layer and not shutter one (could cause early projection and etc)
There are two solutions.
1. Move all gcode commands requiring synchronization to pre and post layer gcode boxes.
2. Only for movement gcodes send Z_move_comp response. (I believe marlin and etc working this way)
Offline
I will double check that, when I looked at the source they seemed to be sending it back after every command.
Let me explain the logic.
2. Only for movement gcodes send Z_move_comp response. (I believe marlin and etc working this way)
Offline
Well, looking over the Marlin code I do see where it only responds z_move_comp on G0/G1 commands. I have no idea what code I was looking at before but this is different. I will update the firmware and do some testing. Will need to change the gcode to remove all WaitDoneMessage except after the G1 moves. Will report back.
Offline
I will defer to James about this but if I understand this correctly if we move the current shutter (really in this case the LED activation) M106/M107 and t [[WaitForDoneMessage]] commands in the Hardware Setup to the Printer Profile sections called "Before Each Layer" and "After Each Layer" we will solve the out of order issue?
I have a question .... What command actually caused the Layer image to be displayed on the LCD / DLP? Does this just happen when we move to a Z position?
Note to Shahin.....I would suggest a change to the heading "Printer Profiles" to "Print Profiles" or maybe Layer or Slice or RESIN profiles or some combination of those. This is mostly because, to me at least, the name Printer Profile implies this is a setup which universal for the printer hardware which is not the case here...that section is called reasonably Hardware Setup
Offline
In all the time I have used nanodlp I have never had anything get out of sync. I just now modified the repetier firmware to only send on G0/G1/G28 commands (still require the P1 parameter to wait for move complete to be backwards compatible with other stuff) where as before it would send the z_move_comp with every command. It seems to work ok but you will need to edit your printer setup and profiles to remove all the [WaitDoneMessage] except for after the G1 and G28 commands (you need to change the G28 to G28 P1). I ran it through a dry test but won't be able to test more until later tonight. Here is the repo link with the source (if you need a hex file let me know): https://github.com/jamesarm97/Repetier- … evelopment
Offline
James....Thanks I will download and try to build...
the G4 P1 command I see following a move...I initially thought this might be for the resin to settle before UV exposure but I see P1 is only 1ms which I thought initially was S1 which equals 1 second....what is the point of a 1ms delay? Even 1 second seems a bit short for settle time....
Offline
The G4 P1 goes away. I will upload a screenshot of a sample profile I tested with.
Offline
Here is the setup page:
https://www.dropbox.com/s/066sp2uaxgpdh … 2.png?dl=0
And the Start of Print gcode since it was chopped off in screenshot:
M107
G90
G28 F400 P1
[[WaitForDoneMessage]]
G92 Z0
[[PositionSet 0]]
M17
Here is the Printer Profile after uploading the new firmware:
https://www.dropbox.com/s/cy6femealj4mo … 1.png?dl=0
Offline
Thanks James,
The sketch compiled fine I will see about getting it uploaded to my printer tonight.....
I am not sure how this all plays out...obviously many people use your original firmware and NanoDLP and get good results but I see a few people like me get the strange Z reductions..not sure about the wavy surfaces that might be unique to my setup somehow....I will know more when I get home to look at my latest set of test objects.
Last edited by macdarren (2017-04-20 19:18:57)
Offline
wavy z would be some wobble on z, bent threaded rod or the z bearings are not preloaded enough. We took my brand new D7 and the plate wiggled so we took off the bearing block and adjusted the eccentric bearing a little so it was slightly hard to put back on the rails, but once on it slid with little force but smoothly. Does it seem to move ok without binding? Only think I can think of that would change the height is skipped steps but the z moves pretty slow and at least on mine, the current was set high enough to not skip (0.84 on vref).
Offline
