nortd / lasersaur Goto Github PK

Our laser is running (no errors on the app and the laser head moves its proper path) but the laser itself does not fire. Any ideas what this could be?

This is a bug in the y carrier belt assembly. The holes on both sides of the 23 link cable carrier (MHPUS102-19-23-S) are 4mm. This is too small for the BCB5-6 bolts indicated in the beta build instructions, cad model and BOM.

I checked misumi. They don't seem to have hntpz5-4 t-slot nuts (with lock), only hntp5-4 ones without lock. I'm not experienced enough to know if either drilling or hntp5-4 will work best for this application.

In any case, some additional documentation is needed. I would gladly update this myself, but I don't know where I could. I have no better place to mention this than a github issue :-(

We spent quite a bit of time with a spirit level and calipers adjusting the vertical and horizontal position (not angle) of the M1 mirror. This struck me as harder than necessary. Could you imagine a cheap way to make this movement smoother?

Pages like this (https://github.com/nortd/lasersaur/wiki/operation) and (http://store.lasersaur.com/index.php?route=product/product&path=59&product_id=67&currency=USD) mention 25mm. However, some of the links go to products that are 25mm, some go to products that are 20mm, and some to old ebay pages that don't provide that information.

Can you please clarify if the mirrors AND/OR the lenses must be 25mm or if some other size is acceptable? Thank You.

I had to set the viewBox parameter in the inkscape template file Lasersaur.svg in order to ensure correct scaling.

viewBox="0 0 1220 610"

Taken from Ray Debs' comments at https://groups.google.com/d/msgid/lasersaur/9004EAED-6BEA-49DF-BD25-4FFA720001E5%40aol.com

I have been thinking that a nice feature to have would be a beam power compensation over the area of the bed. This could be as simple as this:

output_power = file_specified_power * (((xpos + ypos) / (xmax + ymax)) * scale_factor) + 1.0)

The scale_factor can be adjusted from 0-1 to provide equal power at a point (0,0) as at a point (xmax,ymax). This should produce an output power of 100% at the farthest point, and something less everywhere else, decreasing as the beam path gets shorter. This assumes a somewhat linear reduction in power with distance, which may not be true, but it may be a good enough approximation. I would probably start calibrating with a small scale_factor of around 0.05, then adjust as necessary. The measurement of power can be dome by shooting a short burst into an acrylic block and measuring the relative depth of the crater in the min and max positions.

Of course, this would mean varying the power while moving the cart, not just at the start of a segment.

This is relevant to the discussion about calibration because a final step would be added to measure power at both locations so the scalefactor could be determined.

The math is off the top of my head, so I may have messed it up, but I hope I can get the general idea across.

We have finally gotten ours to work, and it seems to be fairly reliable. We probably have about 20 hours worth of cutting on it with no problems.

Beeping
We never tried to fix the beeping. Instead, I wired in a switch that allows me to physically cut power between the laser power supply and the downstream side of the SSR that the original e-stop is connected to. What we've been doing is making sure to turn the laser power supply off whenever the door is open. This basically acts as another layer of safety. The only downside to this that I've found is that the power supply takes maybe 15 seconds to fully boot. If someone tries to start a cut before the power supply is booted, the beginning of the job won't have the laser firing. Pretty easy to get used to.

Wiring
We wired as discussed earlier in this thread. TH is tied to 5V, TL is left open, and IN is connected to the PWM output of the Atmel. Just like mentioned earlier in this thread, we were having problems with the laser not firing if the PWM value was below about 15% duty cycle. So we created a fork of the main LasaurApp repo where we modified the PWM output code to set (1% power level = 15% duty cycle). We also made sure that accelerations and decelerations were not setting PWM below 15%. At 0% power, we use 0% duty cycle. This has worked just fine so far. It is difficult to tell how the 15% constant on power compares to the pulsed laser that the original design is using. My suspicion is that our achievable minimum power is quite a bit higher than the minimum powers that the original design obtains. This hasn't been much of an issue for us so far. The fork is here: https://github.com/NU-MSR/LasaurApp Check the commit comments for more descriptions of the changes we made.

Weird Issue
The only strange behavior that we've encountered occurred after we did our initial tests. We started getting "Short Circuit Fault Analysis: The high voltage wire connected to ground wire or connected to the machine!" warnings whenever we set our power to 100%. Quite a lot of testing revealed that the current that was being drawn at full power was significantly above the recommended 26-28mA (even though we had already set the limiting potentiometer). We re-tuned this pot, and haven't had a problem since. Not sure what caused this issue, which is frustrating. However, our system seems fairly stable.

• jarvis

A simple beam combiner doesn't have to be costly. It might significantly speed up the calibration process, especially the first time. This is a feature request for an optional beam combiner addition.