Close

Detector bar to allign scanheads

A project log for open hardware fast high resolution LASER

AKA Hexastorm

HexastormHexastorm 06/14/2019 at 15:354 Comments

As always, I would like to generate some prior art to extend room of operation.  The following concerns the situation that multiple scan heads are used in a single machine. For an example see Kleo which uses 288 bundles by Carl Zeiss.



If multiple scan heads are used, a challenge is to align these heads. The position of the laser in each head has to be known exactly.
One way of doing this is by moving a camera under the scan heads and collecting position information per laser. The laser would project directly onto the CCD / CMOS chip and its position would be determined. This is however expensive as it requires an extra stage with camera. The chip has a finite size of for example 5x5 mm and has to be moved.

Another solution of doing this would be to add a bar from diffuse glass, e.g. opal glass. The light would be scattered in this bar and reach the edges of it. At the edge of this bar there would be a photodiode. The bar could be made of opal glass. One might think that this  bar must be narrow so the position can be detected up to 10 micrometers accurate in one direction. The current photodiode used to calibrate the laser is, however, also not narrow.  You can simply use the rising edge of the signal recorded by the photo-diode used to monitor the diffuse opal bar.
The stage upon which the scan head is mounted then moves in  orthogonal direction to this bar.
By turning on the laser and moving it over the bar. The position can be determined exactly in that direction. It might be needed to add a cap-around the bar to minimize stray light. This is also done for the photo-diode  in the scanhead.
Still, I need two dimensional information. I also need to know the position of the laser diode at the bar.
To do this I could use multiple photodiodes along edges of the bar. They would all measure a signal if the laser hits the bar. The signals will, however, arrive at different points in time. This allows one to determine the position of the laser along the bar.

Discussions

Hexastorm wrote 06/15/2019 at 11:40 point

Gravis, great you are still following the process. At the moment, a CCD is indeed used to align a single scanhead. With a CCD, CMOS is more common these days, you can indeed see the exact shape of  a spot. The problem is the finite shape of the CCD, for example 5x5 mm. If I have a bar with multiple lasers. I would have to move the CCD to each laser. This requires a stage.  You have to think about systems like Kleo LDI, which use 288 lasers; see https://youtu.be/7R464iHaTQU .
 I must admit that the solution I described was flawed.  I adapted it but now it is more expensive and complicated to implement.

  Are you sure? yes | no

Gravis wrote 06/16/2019 at 09:58 point

You could also use a cheap-o XY stage by moving a fixed 3x3 matrix of CMOS sensors.  You can use the previous scanhead information to identify the inaccuracy and imprecision of the XY stage and iterate through all the scanheads, identifying any alignment issues.  It's could even possible to reduce the stage to using a single motor (not even a stepper) by utilizing overly complex (but plastic and inexpensive) mechanical logic if you only most in a specific pattern (see also: original Furby).  Your solution is probably better but it's food for thought. :)

  Are you sure? yes | no

Hexastorm wrote 06/17/2019 at 09:05 point

my personal preference is moving a cmos sensor…  also allows you to get the shape of the spot etc.  but wanted to "claim" the bar, just in case.

  Are you sure? yes | no

Gravis wrote 06/14/2019 at 18:36 point

I think using an unfocused (no lens) cheap-o CCD could actually be easier and less expensive.  CCDs are just a matrix of photodetectors, so with a small dedicated MCU, you could measure exactly where it's hitting.  The nice thing about CCDs is that they can be configured to look at a specific subsection of the CCD ("region of interest") which can be quickly polled and processed by a low speed MCU without any need for an additional memory buffer.  If any of this information is new or unconsidered then give it some consideration.  If not, carry on.

  Are you sure? yes | no