Add your findings/experience regarding fine-tuning/optimizing the electrical/laser setup of Mr. Beam.
danel_s, 2014-12-20: my first tests showed that the cuts have from time to time small “unburnt” parts. It also looks like it happens more often if much more X/Y movement happens than on a straight line. I will have a closer look on this in the future!
michaelk, 2014-12-21: I had a similar problem and solved it by changing the focus-adjustments of the laser and used more power - 200 for engraving in wood.
danel_s, 2014-12-22: I did also refocus, but I don't know if it helped. May be it was a combination of to low intensity and of software problems. I very often had problems using the RaspberryPi and the webinterface, so I changed to directly print via Arduino, and now this problems are gone.
danel_s, 2014-12-22: Some additional remarks to this “laser outages”: it looks like that the smoke can heavily influence the laser beam. I observed that when dense smoke “trails” from the burnt material are crossing the laser beam the laser is reflected very much from the smoke trail → this could be the reason that the cuts are not steady and all few millimeters the laser did not cut completely the material. I will try if a strong fan blowing away the smoke helps.
michaelk: my first tests showed some halt's during printing. The Terminal prints out errormessages: “Recv: error: Invalid gcode ID:24” and “Recv: error: Invalid gcode ID:33”. After a while the movement continues. But OctoPrint send a lot of lines, that where not lasered. Under some circumstances the head moves diagonaly somewhere.
roeschter: I had the same issues. incscape with engraves extension and universal gcode sender work much smoother then the web interface. Plus, the Arduino is ready in 5s.
I can not point to the problem:
I checked the temperature of the electronic parts. They are below 30°C. I changed the communication-timeouts. Increasing helped a bit. I am using 15 / 14 / 9,5 sec for communication / connection / auto-detection timeout. I found out, that this is better.
Here is a hint for debugging: https://github.com/grbl/grbl/wiki/Interfacing-with-Grbl This defines the above definded errors as common gcode errors. That means the cura-engine does not provide appropriate gcode. Or OctoPrint sends lines without linefeed.
Am I the only one who is facing this issue?
daniel_s 2014-12-22: I had several issues using the webinterface, most of the cuts had problems (timeouts, missing lines, …), so I use now the Universal G-Code sender via USB and the Arduino (https://github.com/winder/Universal-G-Code-Sender). I convert the .svg files with Inkskape and the extension a backer (Martin Renschler) on the Mr. Beam Kickstarter page mentioned. This works very well for me.