Hello
Simao,
Please find my reply below your
questions. I hope I didn't do any miss calculations :).
>What is the time performance
off your machine? Maybe you gave that
>information on the
uploaded files but i don't have access sorry.
Current printer speed is 32”/sec in
bidirectional mode and 16”/sec in unidirectional mode.
I always use unidirectional mode
because of quality of the output it gives sharp well defined lines.
For example it takes 8 minutes to print
~8”x1.3” board in unidirectional mode at 720dpi resolution.
>Comparing your printing time to
process off printing a mask, align on
>pcb and expose is it
longer even with small boards??
I think so, I can live with this speed.
I'm working on rotating mirrors just for fun.
>Was recently discussed here
various ways to raster scan the laser,
>mirrors, prims or
rotate/shake the laser. But the precision work needed
>to
accomplish this worth the time improvement for small boards?
>From
your schematics (thanks again for posting) the servo is driven
by
>the mcu and the quadrature decoder and position counter is
on fpga. Do
>you thing the machine mechanics will handle faster
speeds? Because if
>all the servo drive be on the fpga i guess
the speed could be improved.
>I realise that will be needed a
big logic to make it maybe even more
>complex than the common
signal and printhead part. But the laser
>assembly will the one
you already have.
Higher speeds is not possible with this
mechanics at least X-axis motor won't survive.
BTW for the X-axis servo, I'm disabling
servo during printing, it just moves ~max speed between printing area
limits if it exceeds limits then servo is enabled.
>For the rotating mirror i see some
difficulties. The rpm speed has to be
>low enough as film
sensitivity. And it's divided by the 6 mirror faces.
>From the
values from Adam Seychell and some lost on mirror and lenses
>maybe
the rpm needs to be as slow as 100rpm. And maybe the mirror won't
>be
accurate enough at this speed. But don't know.
>From a fast
look to the driver datasheet i didn't get relation between
>external
clock and rpm.
New generation rotating mirror motors are PLL based
they have a clock input and PLL locks the motor speed to external
clock, so they should be accurate. For example, if we're printing at
720dpi with 2.5microsecond exposure time, scanning of 8” width
material requires 14.4ms and if we have a 6 faced mirror motor speed
will be 694rpm
>In laser printers surface photo effect is incredibly
sensitive so it has
>very fast scans but photoresists need more
energy. And these optics sure
>have laser power limits they can
handle.
I don't know, I did some experiments at 200mW and did some
rough measurements it seems most of the power loss is because of the
45 degree mirrors and it is ~20% and total loss is around 30%
>I sincerely expect you start
selling you board soon. But i still got the
>servo driving with
fpga idea. Your board don't have more IOs for it but
>there are
things like ebay 280420650046 and the same seller has a nice
>arm
board too (i have other one). So please from you experience can
the
>mechanics allow more speed?
It is for my hobby, I'm really
very bad to make things commercial.
I prefer to use my own designs because
of that I'm not buying any evaluation boards etc.
All servo in fpga do we really need? I
think we don't need such high speed servo calculations since the response
time of motors are really slow.
>PS
>Just more one long
email from me BUT! I started writing this email
>almost 2 hours
ago because something hit my mind in between. Few days
>ago on
emc2 list someone asked if he could use vga port to drive the
>servos
drivers. And i start wonder if we could use the hsync signal
for
>raster sync and vsync for line step. Ok i am crazy its a
fresh idea, but
>has some potencial.
>The laser is
connected to one color and the others can be used for
other
>information. No fast realtime uplink signals needed. The
problem is only
>synchronization between the hsync and mirror
position. This has to be
>handled by external circuit. The
hsync is much longer than the dot clk
>and that is a problem
too.
>Imagine you have a full screen software with the normal
software things
>on top and on bottom the line to rast scan
repeated more than 100 times.
>All the lines on top will be
used give time to the external circuit to
>synchronise hsync
with the 'zeroing' light sensor. At hsync any laser
>signal is
instantly blocked and a short pulse is given to laser as long
>as
the dot clock. If at that pulse the light sensor gets it so
it's
>synchronised if not the clock in the mirror driver should
be modified
>(maybe start fast and reducing rpm until
synchronisation) .
>The circuit also has to block laser signal
if no synchronisation. Know
>in which line it's the raster
lines and count successful rasted lines.
>At 60hz or so vsync
gives enough time to any cnc software to check if
>the
successful rasted lines are correct and move to next line.
I think it is a good idea, as far as I
know Sun Microsystems used similar concept in their laser printers.
>Ok don't bother reply if not
worth it.
It is really good for me, thanks for
asking all these questions, it is a brain storming and creates new
ideas.
Volkan
[Non-text portions of this message have been removed]