Projector exposed too early

Xmike · 2016-04-04 20:12:27

Hi,
My printer uses an Arduino and Ramps.
Unfortunately, the projector begins too early to expose.
I could partially overcome the problem by increasing the "Wait BeforePrint" to 10 sec
in "Normal Layers" as well as in "Burn-in layer".
But there is further the expose problem in the first layer .
I have attached the terminal output and there I marked the Position where it happens.
My GCodes are:

GCode - Start of Print:
==========================
M203 X2 Y10 Z7
M201 X10 Z40
M204 X0.1 Z0.1
M84 S0
G21
G91
G1 Z-1 F90
G1 Z100 F90
[[Delay 10]]
G90
G92 X-9.5 Z123.4
[[PositionSet 123.4]]
G1 Z20 F400
[[WaitForDoneMessage]]
G1 Z10 F90
[[WaitForDoneMessage]]
=========================

Before Each Layer:
=========================
G1 X0 F150
[[WaitForDoneMessage]]
G1 Z[[LayerPosition]] F40
[[WaitForDoneMessage]]
[[PositionSet [[LayerPosition]]]]
=========================

After Each Layer:
========================
G1 X-4 F50
[[WaitForDoneMessage]]
G1 Z{[[LayerPosition]]+[[ZLiftDistance]]} F20
[[WaitForDoneMessage]]
[[PositionChange [[ZLiftDistance]]]]
========================

Terminal output:
========================
M203 X2 Y10 Z7
M201 X10 Z40
M204 X0.1 Z0.1
M84 S0
G21
G91
G1 Z-1 F90
G1 Z100 F90
ok ok ok ok ok ok ok Z_move_comp ok Z_move_comp echo:endstops hit: Z:123.40

G90
G92 X-9.5 Z123.4

G1 Z20 F400
<<<<<<<< missing "Z_move_comp"
G1 Z10 F90
ok ok ok Z_move_comp
M280 P0 S1100
G1 X0 F150
ok Z_move_comp

G1 Z0.1 F40
ok ok Z_move_comp ok Z_move_comp <<<<<<<< why there are two "Z_move_comp" ?
M280 P0 S1900
ok <<<<<<<<<<<<<<<<<<<<<<<<<< Beginn to expose, shutter did not realy open-close, but it is too early, Z move not complete
M280 P0 S1100
ok
G1 X-4 F50
ok Z_move_comp

G1 Z4.1000 F20
ok Z_move_comp
G1 X0 F150
ok Z_move_comp

G1 Z0.2 F40
ok Z_move_comp
M280 P0 S1900
ok
M280 P0 S1100
ok
G1 X-4 F50
ok Z_move_comp

G1 Z4.2000 F20
ok Z_move_comp
G1 X0 F150
ok

G1 Z0.3 F40
Z_move_comp ok Z_move_comp
M280 P0 S1900
ok
M280 P0 S1100
ok
G1 X-4 F50
ok

G1 Z4.3000 F20
Z_move_comp ok Z_move_comp
G1 X0 F150
ok Z_move_comp

G1 Z0.4 F40
ok Z_move_comp
M280 P0 S1900
ok
M280 P0 S1100
ok
G1 X-4 F50
ok Z_move_comp

G1 Z4.4000 F20
ok Z_move_comp
G1 X0 F150
ok Z_move_comp

G1 Z0.5 F40
ok Z_move_comp
M280 P0 S1900
ok
M280 P0 S1100
ok
G1 X-4 F50
ok Z_move_comp

G1 Z4.5000 F20
ok Z_move_comp
G1 X-9.5 F150
G1 Z250 F200
M84
M280 P0 S1100
ok Z_move_comp ok Z_move_comp echo:endstops hit: Z:123.40 ok

Last edited by Xmike (2016-04-04 20:32:08)

Shahin · 2016-04-04 22:06:52

As you have highlighted. Response from RAMPS could be reached rpi with delay.

Whenever nanodlp sees [[WaitForDoneMessage]] keyword it waits for Z_move_comp response from RAMPS.
But what will happens if RAMPS response delayed for gcode below

G1 Z0.1
G1 Z2
[[WaitForDoneMessage]]

We could be sure due to delay in communication between two devices. Before receiving Z_move_comp for the first G1 command nanodlp is already send second G1 command and waiting for Z_move_comp. In summary first G1 command satisfy [[WaitForDoneMessage]] which was there for the second G1 command.

So put [[WaitForDoneMessage]] in front of every G1 command. Specially ones with very quick movements or if there is large number of gcodes which could delay response from your arduino.

Hopefully it helps.

jkao · 2016-04-05 18:43:14

Another thing you can try is adding a G4 (dwell) command after your G1's. Stock marlin buffers G1 commands and will return "ok" when the command is buffered, but not yet executed.

The G4 command will wait until all buffered movement to complete before returning "ok", so you could try something like

G4 P100

to wait for all movement to complete plus 100ms before returning "ok".

Shahin · 2016-04-05 19:15:51

jkao,

Can we assume grbl behave same as marlin?

jkao · 2016-04-05 19:21:00

I don't have any personal experience with grbl, but I think that any firmware that is designed to work with FDM printers or CNC machines would need to work this way in order to ensure smooth movement and to enable features like arc detection and arc compensation to work.

I think in any case, the G4 command is safe to use, and probably the recommended conservative thing to do no matter what, since it seems to be implemented in all common firmware:

http://reprap.org/wiki/G-code#G0_.26_G1:_Move

Xmike · 2016-04-08 12:28:08

I have changed the GCode, but the exposure problem do exist futher.
With delays i could change the exposure timing of the Layers after the first Layer,
but for the first Layer it will be ignored.
If i have a look at the terminal and compare it with the movements from my printer,
I sometimes think that the returned Z_move_comp command
from the firmware is send at the begin of the movement and not at the end.
I made a gif of the terminal output:

Now my GCodes are:

GCode - Start of Print:
==========================
M203 X2 Y10 Z7
M201 X10 Z40
M204 X0.1 Z0.1
G21
G91
G1 Z-1 F90
G4 P100
[[WaitForDoneMessage]]
G1 Z300 F90
G4 P100
[[WaitForDoneMessage]]
[[Delay 5]]
G90
G92 X-9.5 Z123.4
[[PositionSet 123.4]]
G1 Z20 F400
G4 P100
[[Delay 20]] <<<<<<<<<<<<<<<<<<<<<< Here I tried to prevent the premature exposure, but seems to be ignored
[[WaitForDoneMessage]]
G1 Z5 F90
G4 P100
[[WaitForDoneMessage]]
=========================

Before Each Layer:
=========================
G1 X0 F150
G4 P100
[[WaitForDoneMessage]]
G1 Z[[LayerPosition]] F40
G4 P100
[[Delay 10]] <<<<<<<<<<<<<<<<<<<<<< with this delay I got to prevent the premature exposure, but not for the first Layer
[[WaitForDoneMessage]]
[[PositionSet [[LayerPosition]]]]
=========================

After Each Layer:
========================
G1 X-4 F50
G4 P100
[[WaitForDoneMessage]]
G1 Z{[[LayerPosition]]+[[ZLiftDistance]]} F20
G4 P100
[[WaitForDoneMessage]]
[[PositionChange [[ZLiftDistance]]]]
========================

Shahin · 2016-04-08 14:52:38

Which firmware are you using?

Xmike · 2016-04-08 17:09:57

I installed the marlin-version from:
"https://github.com/mUVe3D/Marlin-mUVe1DLP-Running"

Shahin · 2016-04-08 19:50:54

Have you updated marlin to the latest version?

Xmike · 2016-04-09 10:54:32

I have downloaded the Marlin-Version two weeks ago.

Shahin · 2016-04-09 15:15:51

Upgrade it again I am not sure if it is related or not but It had serious issue which have been fixed a week ago.

Xmike · 2016-04-10 20:05:00

I have now installed the new version, unfortunately, nothing has improved.
Apart from the "Z_move_comp" answer of the firmware that me still
a little confused, the mechanical movements are actually correct.
In my opinion, the main problem is, that the projector does not wait until the block "Before Each Layer" has been processed

Shahin · 2016-04-10 20:36:43

Layer printing logic is pretty clear and simple on nanoDLP side. Also considering number of users using nanodlp+ramps. I believe, we are overlooking something.

Can you press debug button from setup page/tools tab to post debug dump? I will go through settings once again to see if I could find any issue.

Could you remove G1 X code series? Maybe there is an issue with that one as I have not seen anybody use that.

Xmike · 2016-04-11 17:30:07

I have now removed the X-axis GCode, but the projector exposed still too early.
The X-axis is required for the tilt mechanism.
The debug file I have attached (debug is with X-axis)

nanodlp.debug.-356590248.zip

Last edited by Xmike (2016-04-11 17:33:26)

Shahin · 2016-04-12 22:11:51

It looks fine. Only way to find out the problem is to remove commands one by one to see what cause nanodlp skip waitfordonemessage.

Xmike · 2016-04-16 12:10:37

I'll give up to control the movements with "Z_move_comp", and now I changed to timed controlled movements with [[Delay xxx]].
The projector not getting otherwise under control.
While it is not the best motion control, but for me it works.
Also, I changed back the firmware from Marlin to Repetier.
The movements of my printer have therefore become noticeably more harmonious.

Xmike · 2016-04-17 14:02:35

Hi Shahin,
I still have made further tests, with marlin-firmware.
If I add in the end of the GCode block "Before Each Layer" a "[[Pause]]",
then the projector awaits until I click on "Resume Print".

Now my GCodes

GCode - Start of Print
============================================
G21
G91
G92 X-9.5 Z53.4
G1 Z-1 F90
[[WaitForDoneMessage]]
G1 Z200 F90
[[WaitForDoneMessage]]
[[Delay 5]]
G90
G92 X-9.5 Z53.4
[[PositionSet 53.4]]
G1 Z20 F800
[[WaitForDoneMessage]]
G1 Z[[ZLiftDistance]] F90
[[WaitForDoneMessage]]
============================================

Before Each Layer
============================================
G1 X0 F150
[[WaitForDoneMessage]]
G1 Z[[LayerPosition]] F40 <<<<<<<<<<<<<<<<<<<<<<<< during movement comes the message "Action: GCode paused printer"
[[WaitForDoneMessage]] <<<<<<<<<<<<<<<<<<<<<<<< maybe ignored
[[PositionSet [[LayerPosition]]]]
[[Pause]] <<<<<<<<<<<<<<<<<<<<<<<< Projector waits until resume print
============================================

After Each Layer
============================================
G1 X-4 F40
[[WaitForDoneMessage]]
G1 Z{[[LayerPosition]]+[[ZLiftDistance]]} F20
[[WaitForDoneMessage]]
[[PositionChange [[ZLiftDistance]]]]
============================================

Last edited by Xmike (2016-04-17 18:58:14)

Xmike · 2016-04-17 16:37:29

The code I have minimized to

GCode - Start of Print
============================================
G21
G90
G92 Z53.4
[[PositionSet 53.4]]
G1 Z20 F800
[[WaitForDoneMessage]]
G1 Z[[ZLiftDistance]] F90
[[WaitForDoneMessage]]
============================================

Before Each Layer
============================================
G1 Z[[LayerPosition]] F40 <<<<<<<<<<<<<<<<<<<<<<<<<<< projector starts to expose at the beginning of the code
[[WaitForDoneMessage]]
[[PositionSet [[LayerPosition]]]]
============================================

After Each Layer
============================================
G1 Z{[[LayerPosition]]+[[ZLiftDistance]]} F20
[[WaitForDoneMessage]]
[[PositionChange [[ZLiftDistance]]]]
============================================

Last edited by Xmike (2016-04-17 19:00:50)

Shahin · 2016-04-17 19:44:35

Mike,

Every basic calls and functions during printing run in sync manner. No way anything before layer runs during or after layer display.
Put something random such as this one before each command and hopefully marlin ignore these. And we could find cause of the problem.

LL Before Layer [[LayerNumber]]
LL After Layer [[LayerNumber]]

Xmike · 2016-04-18 17:43:42

I think I now have a workaround.
I added the command "G1 Z[[LayerPosition]] F40" a second time, so I once more can query the answer "[[WaitForDoneMessage]]".

Before Each Layer
============================================
G1 X0 F150
[[WaitForDoneMessage]]
G1 Z[[LayerPosition]] F40
[[WaitForDoneMessage]]
G1 Z[[LayerPosition]] F40 <<<<<<<<<<<< second identical code do nothing, because it's already on position
[[WaitForDoneMessage]] <<<<<<<<<<<< but now the Projector is waiting
[[PositionSet [[LayerPosition]]]]
============================================

please have a look at the video,
especially to the code "G1 Z0.2 F40" the yes occur twice.
The first movement takes in reality about 6 sec. and the second
"G1 Z0.2 F40" is already done.
The answer of "Z_move_comp" does not fit together in time

then I tried the extra code G4 after each G1 Command,
but there is also a strange behavior of "Z_move_komp"

Before Each Layer
============================================
G1 X0 F150
G4 P500
[[WaitForDoneMessage]]
G1 Z[[LayerPosition]] F40
G4 P500
[[WaitForDoneMessage]]
G1 Z[[LayerPosition]] F40
G4 P500 <<<<<<<<<<<<<<<<<<<<<<<< projector start first to expose, then after this time shutter opens
[[WaitForDoneMessage]] "Servo Signal Length" will be ignored (is 2000ms)
[[PositionSet [[LayerPosition]]]]
============================================

the printer now seems to work, and for the shutter i can insert a seperat M280.
If the terminal should display the answers of the firmware in real time, then I'm not sure if it still may be an intermittent problem.

Last edited by Xmike (2016-04-18 18:02:50)

Shahin · 2016-04-18 18:42:47

Good to know you found a workaround.
Yes, terminal is realtime.

I guess it is all about timing.

Shutter signal length get ignored as we do not know, how much of that length is to open shutter.
You can use before layer wait if shutter needs more time.

If you need more time to make

nanoDLP

#1 2016-04-04 20:12:27

Projector exposed too early

#2 2016-04-04 22:06:52

Re: Projector exposed too early

#3 2016-04-05 18:43:14

Re: Projector exposed too early

#4 2016-04-05 19:15:51

Re: Projector exposed too early

#5 2016-04-05 19:21:00

Re: Projector exposed too early

#6 2016-04-08 12:28:08

Re: Projector exposed too early

#7 2016-04-08 14:52:38

Re: Projector exposed too early

#8 2016-04-08 17:09:57

Re: Projector exposed too early

#9 2016-04-08 19:50:54

Re: Projector exposed too early

#10 2016-04-09 10:54:32

Re: Projector exposed too early

#11 2016-04-09 15:15:51

Re: Projector exposed too early

#12 2016-04-10 20:05:00

Re: Projector exposed too early

#13 2016-04-10 20:36:43

Re: Projector exposed too early

#14 2016-04-11 17:30:07

Re: Projector exposed too early

#15 2016-04-12 22:11:51

Re: Projector exposed too early

#16 2016-04-16 12:10:37

Re: Projector exposed too early

#17 2016-04-17 14:02:35

Re: Projector exposed too early

#18 2016-04-17 16:37:29

Re: Projector exposed too early

#19 2016-04-17 19:44:35

Re: Projector exposed too early

#20 2016-04-18 17:43:42

Re: Projector exposed too early

#21 2016-04-18 18:42:47

Re: Projector exposed too early

Board footer