User Tools

Site Tools


electrical_and_laser_setup

Electrical and Laser setup

Add your findings/experience regarding fine-tuning/optimizing the electrical/laser setup of Mr. Beam.

Short laser outages

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!

Mr. Beam engraving with "laser outages"

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.

Halt's during printing

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.

Here is my result: The halts are marked (red).

I can not point to the problem:

  • Is it my gcode from the svg2gcode-plugin / cura? Yes it ic correct: I tried it with http://simplegcoder.com/ - online - looks good).
  • Is it the OctoPrint Web-Interface who sends it to grbl on the arduino?
  • Or is it the grbl-interpreter who is not able to parse valid gcode?

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.

electrical_and_laser_setup.txt · Last modified: 2014/12/22 21:05 by daniel_s