Author Topic: Genesis of a Laser Controller  (Read 1550 times)

RobotEyes

  • Jr. Member
  • **
  • Posts: 50
    • View Profile
    • RobotLaser
Genesis of a Laser Controller
« on: September 10, 2016, 02:45:54 AM »
For the curious ... this is the genesis of RobotLaser.

After the purchase of laser plotter, I looked the software,
what I wanted is an integrated suite to generate the gcode, and manage the laser:
*) Benbox is unusable
*) Grbl controller is very complex and unreliable,
*) T2Laser is great, but tied to a PC only.

So, I looked  a long on the internet and I found 3dpBurner, which only generates gcode,
but had some interesting features,
so I took the kernel and I integrated with a management module that I wrote,
and I got my version of Laser controller
(i'm quite sure that T2Laser was generated in the same way)

Then I added the research of the outlines, to transform images into vectors
(similar to the BenBox "Contour" function )
using the principle of Papert Turtle
(In 1967 Seymou Papert created the first graphical language (Logo)
 who had six commands: forward, back, right, left, write, not write)
Integrated with a labeling algorithms (Herman & Liu, 1978).
Finally I created a BitMap->Vector conversion quick and scalable,

Then I faced the problem of the GCode Raster generation.
I did not liked so much the Villamany algorithm (Image2GCode),
so I kept the external structure (flip, rotate, equalize, etc, which are functions provided natively by Microsoft)
and I decided to rewrite the algorithm Image2Gcode:
Villamany creates a grid in world coordinates with step "Resolution",
then overlaps with the bitmap and look for the nearest pixel.
This involves, however, an irregularity in the contours, such as when you scale an image magnifying the pixels.
Then, while maintaining the original image I created a work bitmap with the bicubic resizing (for me the best)
so you have the pixels of the size of resolution .
At this point is easy to scan the image by pixels and not by world coordinates,

Second thing,
Image2GCode generates a command line for each step of the grid,
eg: G0 X0 Y0 S0 - G1 X0.2 S0 - G1 X0.4 S127 - G1 X0.6 S127- ......... - G1 X9.8 S127 - G1 X10.0 S0
when would be enough G0 X0 Y0 S0 - G1 X0.2 S0 - G1 X9.8 S127 - G1 X10.0 S0.
My algorithm works on this basis.
It seems useless optimization, but Arduino Nano has serious, not solvable, problems
receaving many high-speed data (as reported on GRBL Wiki)
Less useless data you send, the better is.
Now I'm trying with Arduino Mega and GRBL Shield,
and all communication problems seem disappeared !!!!!!!

Third,
Image2GCode uses Microsoft native primitives to access the single pixels, this is very inefficient on large images,
so I wrote a class library that implements the concept of localization,
the image is copied in local memory as an array (x, y) of int32 (ARGB pixel)
being in the local memory, access is two orders of magnitude better,
at the end, the array is copied back on the image,
with marshaling techniques of .Net this is very fast.
Really the class library was written for tracking boundaries, so I only enriched.

End of the genesis .....
While giving credit to Villamany of inspiring me, the current version of RobotLaser is entirely written by me.
Of 3dpBurner I kept the idea of scanning the diagonal (I liked in T2Laser), but made with my software.
The tools (Flip, Rot, etc) are all native Microsoft System.Drawings
Probably I will eliminate dithering because the Microsoft algorithm does not satisfy me.
Having entered the Laser power linearization function, the grayscale is more efficient than dithering.
(This feature is unique and not present on 3dpBurner and its derivatives like T2)

If anyone wants more information on the algorithms used, send me an MP.

In version 0.4.5 there is a Sketch page, to draw small stuff,
this was a demo for an object programming course that I held many years ago.
It was written in C for WfW 3.0 (1986 ... someone remember Windows for Workgroups ???)
but the principle is still usable.

I do not think I'll leave it in the final version because the quality is not great
(comparable or less than Microsoft Paint) and my job is not to create a graphic editor,
there are many, good and free.

At the moment there is a very rough page from which you can have a Preview of RobotLaser.
We are currently in Alpha testing (not for public use).
Beta (public testing) is scheduled for October.
The first public release will probably be ready by year end.
Alpha and Beta versions are free, for the public version still do not know.

http://www.robot-eyes.com/RobotLaser/

The software is written in portable technology, it does not require installation. (only .Net framework 4 or later)
Probably I will provide the public release on a USB key, so will be usable on different PCs.

I'm also thinking on a version to be put on a cheap tablet,
in order to integrate the controller with the laser unit.

Thank you and sorry for the very long post.
Carlo
« Last Edit: September 10, 2016, 06:32:13 AM by RobotEyes »

treinbert

  • Full Member
  • ***
  • Posts: 216
  • Just into laser cutting & 3D-printing
    • View Profile
    • Spoor 1 Hobby
Re: Genesis of a Laser Controller
« Reply #1 on: September 10, 2016, 05:01:57 AM »
Hi Carlo,

Thanks a lot for the insight into the making of your software.

Much success in the future.

Regards,
Bert
Hartelijke groeten/Best regards/Freundlichen Gruessen,
Bert Mengerink

Prusa I3 clone
Renkforce RF100,
500mW, 2500mW and 3500mW laser
Benbox A3 to be used with above lasers
Own build A0 with Z-axis with the same lasers
Proxon converted CNC cutter
Various Raspberry PI's (2 & 3)
Windows 10
MAC OSX