microcontroller scanner

[cfavreau]

Hum, Chris, you think I would not take good care of him ???

Steve

Just trying to add to the conversation. Like I said you pretty much said it all...

[mixedgas]

Just trying to add to the conversation. Like I said you pretty much said it all...

OK, I just sent him some recycled electrons, modulated in time and space....

Steve

[jack]

So I had a go at implementing some of the test patterns you recommended Steve. The Lasermedia.ild turned out as a bit of a squiggle in the middle of the display region. The Grid Test.ild looked a little like this:



It's a little better in person as there is more persistance (maybe just because the laser is kinda bright).

Since the last photos I showed I've removed the delays in the code, and put in more points for the FHV logo. Now it looks a lot sharper:



however there is still some flickering. Again the photo isnt as good as it looks to me, but you can see from the photo that there are patches where the laser isn't visible. In person these patches seem to move around each of the letters in a loop. Is it because the micro can't spit out the points fast enough?

Maybe I should put a cro on the DAC output now to see how fast is redrawing the image.

T.

[mixedgas]

move around each of the letters in a loop. Is it because the micro can't spit out the points fast enough?

Maybe I should put a cro on the DAC output now to see how fast is redrawing the image.

T.[/QUOTE]

would need to see CRO traces, a easy trick is to use a spare IO pin as a scope trigger at the start of the frame.

watch out for "C", it tends to add delays, compared to assembler.

did the included viewer/editor work for you?

Try its optimization feature.

Your doin fine...

Steve

[mixedgas]

move around each of the letters in a loop. Is it because the micro can't spit out the points fast enough?

Maybe I should put a cro on the DAC output now to see how fast is redrawing the image.

T.[/QUOTE]

would need to see CRO traces, a easy trick is to use a spare IO pin as a scope trigger at the start of the frame.

watch out for "C", it tends to add delays, compared to assembler. The grid needs some achor points.

Your doin fine...

Steve

[jack]

would need to see CRO traces, a easy trick is to use a spare IO pin as a scope trigger at the start of the frame.

Am I just looking for the time it takes to draw each frame? I already have an LED flashing for a heartbeat, and I can its visibly flashing (although pretty fast), so I can just time that to see how much time a frame takes to draw.

[drlava]

First off, are you sure your galvos are tuned optimally? Do you have a computer controlled DAC with which you can display the ilda test frame (or load it onto your micro).?

After the scanners are tuned up, think about dwelling 150-250 microseconds at each hard corner and tweaking the timing on the straight lines to what looks good to you, and you'll be close to optimal.

[cfavreau]

Are you just outputting the points in code.. with no timing except for cycle counting? If so you should really implement a timer (doesn't have to be an interrupt) to at least keep the point timing between points even. You can use a loop which just iterates through each point and delays until the timer expires. Setup the timer again and move to the next point. Store your points in an array in a header file .... or other type of include file...

You are going to drive yourself buggy without a timer...

[jack]

First off, are you sure your galvos are tuned optimally? Do you have a computer controlled DAC with which you can display the ilda test frame (or load it onto your micro).?

I really have no idea unfortunately. I bought them from Dave at Lasershowparts. I kind of assumed (bad idea come to think of it) they would be tuned pretty well, or they would be blatantly out of tune.

No computer controlled DAC available i'm afraid. I did load a couple of test frames that Steve suggested onto the micro, there's a pic of the output a couple of posts back.

I'm not running any timing either, however the loops are all exactly the same. Each point in each character is being sent to the DAC after the same number of clock cycles. I think the only variable in timing will be the latching time for the DAC - i.e. the DAC will latch earlier for a smaller voltage swing.
Between the characters there will be a bit of a longer break however. I've attached the code below in case it helps anyone:

int maxt = maxDAC12;                        // the maximum number for the function variable used by the horiz. & vert. DACs
                                            // (should match the number of possible outputs of each DAC, to allow a 1:1 relation)
unsigned short int tot_points1 = 190;
unsigned short int tot_points2 = 243;
unsigned short int tot_points3 = 182;
unsigned short int tot_points4 = 393;
unsigned short int point_num = 0;
unsigned short int delay_time2 = 0;
unsigned short int delay_time1 = 50;

const unsigned short points1[190][2] = {
// points go here
};
const unsigned short points2[243][2] = {
// points go here
};
const unsigned short points3[182][2] = {
// points go here
};
const unsigned short points4[393][2] = {
// points go here
};

void main(void)
{
      P5DIR |= 0x02;                               // Set P5.1 to output direction
      P6DIR |= 0x03;                              // set P6.1 & P6.2 to output
      P6OUT &= 0x0C;                              // Set P6.1 & P6.2 to low
    ADC12CTL0 = REF2_5V + REFON;              // Internal 2.5V ref on
    TACCR0 = 13600;                           // Delay to allow Ref to settle (delay of approx 13ms = 13600/SMCLK)
    TACCTL0 |= CCIE;                          // Compare-mode interrupt.
    TACTL = TACLR + MC_1 + TASSEL_2;          // up mode, SMCLK
    __bis_SR_register(LPM0_bits + GIE);       // Enter LPM0, enable interrupts
    DAC12_0CTL = DAC12IR + DAC12AMP_7 + DAC12ENC; // Int ref gain 1
    DAC12_1CTL = DAC12IR + DAC12AMP_7 + DAC12ENC; // Int ref gain 1

    DAC12_0DAT = 0x0000;
    DAC12_1DAT = 0x0000;

    while (1)
    {    
        P5OUT ^= 0x02;                                        // Toggle an LED (heartbeat)
        do{
            point_num++;
            DAC12_0DAT = points1[point_num - 1][0];
            DAC12_1DAT = points1[point_num - 1][1];
        }while(point_num != tot_points1);
        point_num = 0;

        do{
            point_num++;
            DAC12_0DAT = points2[point_num - 1][0];
            DAC12_1DAT = points2[point_num - 1][1];
        }while(point_num != tot_points2);
        point_num = 0;
        
        do{
            point_num++;
            DAC12_0DAT = points3[point_num - 1][0];
            DAC12_1DAT = points3[point_num - 1][1];
        }while(point_num != tot_points3);
        point_num = 0;
        
        do{
            point_num++;
            DAC12_0DAT = points4[point_num - 1][0];
            DAC12_1DAT = points4[point_num - 1][1];
        }while(point_num != tot_points4);
        point_num = 0;
     }
}

[cfavreau]

Wow... what is your clock rate? Is the MCU 1 clock ~ 1 inst. (for most instructions)?

Also your DACs are not double buffered right? (from looking at the code).

You may want to have it output a square wave and measure the point to point timing (point output rate) with your scope. From reading the earlier posts you say you are going really slow... however the code is just outputting as fast as the micro can go... which means with most modern micros and clock rates you probably are going way too fast.

At the very least put a delay loop in between each point. Just make 1 variable that decremements from some value to 0 in a while loop. Then you will at least see some effect... good or bad.

do{
point_num++;
DAC12_0DAT = points1[point_num - 1][0];
DAC12_1DAT = points1[point_num - 1][1];
unsigned int uiDelay = 1000; // assuming a 8 or 16 bit micro
while (uiDelay) uiDelay--;
}while(point_num != tot_points1);

It would be really good though to do a square wave a measure the output rate though....

You may want to adjust your output rate for around 12kpps ... most scanners can handle that rate quite well even with non-optimal point spacing and such.