LAOS Laser

Hi Reinoud,

Could you add your test images and photos or your results? I'd like to help out debugging.

2) but that would eliminate the sweeping motion? Isn't it more important that the sweeping is quite consistent and compensate the power for the speed (for example for acceleration)?

3) This is true, see for example the following incident:
http://redmine.laoslaser.org/issues/72
I think Peter and Jaap want to use a RTOS to get this working properly. But I think they first wanted to compile using the MBED method using all the opensource libraries and Jaap just succeeded at this.
http://redmine.laoslaser.org/boards/3/topics/512

Best regards,
Peter

Hi Reinoud and Peter,

To address all three issues separately:

1. I don't know about bitmap size issues. Would have to test.

2. Interference between pixel clock and PWM is a logical result from the way lasering currently works. Maybe we can experiment with using a PWM value of 100% and do a short pulse for every pixel, with the pulse-time based on the power-setting.

3. The interface is turned off because there is currently only one process at the time in the MBED. Polling the keyboard would disturb cutting. We want to implement a RTOS (real-time operating system) on the MBED to solve this. However, this was difficult with earlier versions of the MBED libraries, it should be easier now, but it's still on the TO DO list.

Jaap

Hi Jaap and Peter,

As for the bitmap size, its simple to test: just try to laser out a bitmap that is more than 8192 pixels wide; it will result in garbage at the end of a scan line. Luckily the memory after the bitmap is not used for critical stuff but its more by luck than by design that it doesn't mess things up.

The interference might show up in our example since we have still a low PWM frequency in our config and we're using just a 10% power due to the sensitivity of material we are lasering. Bumping the frequency up will help a lot but won't remove the more fundamental problem of the interference between the PWM frequency and the pixel clock. For a good lasering of either cutting or etching bitmaps the amount of laserpower (Joules) emitted to a discrete point of material ought to be constant to be reliably and repeatable. If the move interrupts are indeed at 1Mhz and are not scaled then this 1Mhz clock can also be used to count the pulse width. If the algorithm scales it to say interrupt at 1Mhz/500 intervals then it could be reprogrammed to say on this interrupt ask for a second say 1Mhz/50 sec, clear the bit and then 1Mhz/(500-50th) for the next move. If the power is 100% then at the speed selected (X steps/sec) the laser shouldn't switch off so the laser interval should be this interval; if the speed is slower due to acceleration then it ought to scale accordingly or we'll burn out corners like we do now IIRC. I'll see if i can work things out :)

As for the interface woos, yes, i noticed that :(. Using an RTOS is not needed in this case though. Most, if not all the critical stuff is done in the background by the interrupts. All other stuff can be done in the main-loop, including the communication with the UI.

With regards,
Reinoud

Hi folks,

I've tried out the alternative pulse code generation. I set up the interrupt to fire at a constant rate and counted pulses for movement and laser. The movement worked fine even at interrupting at high speeds up to say 100 kHz. The problem was with the laser pulse. Even when I switched off the laser pulse directly at the next interrupt the power emitted to the work piece was still far too big; this tiny pulse at 100% power (50W) burned into the material. Regretfully we didn't have a scope to check the pulse but laser hummed at the same rate as the movement so the basic form was fine. So what went wrong? The amount of power was evenly distributed over the lines and there wasn't a piece over-burned and another piece under-burned, the burn was however at 100% power.

Rolling back to the stock algorithm and pushing up the PWM to 10kHz didn't help either: the interference patterns were still visible. My next experiment will be with the stock algorithm but with the PWM output smoothed by an fat elco to transform the PWM into a more-or-less stable voltage and hopefully the interference patterns disappear and all the pixels get drawn.

Any ideas? Have I missed something?

With regards,
Reinoud

Hi folks,

isn't there a onboard DA converter on the NXP ARM chip? That would make the PWM hack unneeded and probably a lot saner for the glass lasers.

With regards,
Reinoud