Project

General

Profile

Forums » Software development »

LAOS firmware rastering/bitmap etching implementation problems and more

Added by reinoud almost 11 years ago

Hi folks,

we've been heavily testing out rasterisation for etching photo's on acryl. On first sight it works fine but i've found some issues, esp. after reading the source code:

1) the maximum width of a bitmap is 8k pixels but this size is not checked! If i instruct it to render a larger bitmap it will write outside the array and when lasering it gives neat results/garbage. We've bumped it to 16k pixels since we want to be restricted on the size and if needed be able to use bitmaps the size of the entire cutout. The number of bit bumping is trival and so ought the range checking.

2) more serious: we've found interference between the PWM used for the cutting power setting and the resulting pixel clock. This is due to the use of the hardware PWM that runs asynchronously with the movement interrupts. The result is ribbed and differences between lines/runs. Also small individual pixels, mainly as a result of dithering will be lasered randomly so in general disappearing or at a much lower power when the amount of power is set low, say 10%.
A correct solution would be to pulse the laser for a set amount of time from the start of every pixel so regardless of the speed the amount of laser power is always the same for a pixel and every selected pixel is burned correctly.

3) interface is stuck during lasering. There is a `cancel'/stop message shown but regardless which button is pressed, no action is taken and the only way to stop it is either switching of the entire machine or resetting the mbed.

Shall i propose a patch for 1) and try to solve 2)?

With regards,
Reinoud


Replies (5)

RE: LAOS firmware rastering/bitmap etching implementation problems and more - Added by peteruithoven almost 11 years ago

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

RE: LAOS firmware rastering/bitmap etching implementation problems and more - Added by jaap almost 11 years ago

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

RE: LAOS firmware rastering/bitmap etching implementation problems and more - Added by reinoud almost 11 years ago

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

RE: LAOS firmware rastering/bitmap etching implementation problems and more - Added by reinoud almost 11 years ago

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

RE: LAOS firmware rastering/bitmap etching implementation problems and more - Added by reinoud almost 11 years ago

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

    (1-5/5)