Strange marks on engraving surfaces

simonzaggio · November 22, 2024, 12:45pm

BINGO!!!

Watch this:

Saleae helped a lot

Tests had been done with wave analyzer connected to the cables near the LPS signal input.

As I mentioned before, there is regularity…

interval of 2,33s between 2 faults

Here is representation of this fault on engraving:

Can’t send whole Logic 2 file…

Glad, that it is a firmware fault, not hardware issue.

What should I do?

I’ve tested different comupters, all on Win 10, USB 3.0, 2.0, Arduino UNO R3, ARDUINO UNO clone, added super-duper extra signal USB cable from computer to Arduino. Should I test other operating system like Win7?

PS. I also tested the Arduino only, without connection to any laser hardware, and the result is similar - there are these brakes of wavelength so it can be Arduino problem (rather not, tested on 2 separate), GRBL problem (I’ll try to reboot and upload GRBL once again), or Win10 problem. It is said, that Win10 is worse operating system than Win7 and GRBL was constructed to cooperate with Win7. Maybe i have fault USB drivers?

simonzaggio · November 25, 2024, 6:31pm

I’ve tested on Windows 7 and different versions of LightBurn and still the same result. Maybe ESP32 with transistors would solve the problem?

jkwilborn · November 25, 2024, 8:08pm

If it’s less than 4mb, you can append a .txt and post it… I’d kind of like to look at it. If it’s larger than 4mb, then move it to something like a google drive and post the link. Ensure you set the protection levels for all with the link to have read access.

PWM comes from the controller, no matter what OS you’re running on your pc. What makes this odd, is that, having programmed the 328p, you’d have to go through a lot in software manipulations to have this occur. What I’m trying to say, pretty poorly, is the firmware would have to be doing this on purpose… I doubt it’s a hardware issue, but since you’ve used multiple Arduino’s I think we can eliminate that.

I’d think it’s have to be firmware related. Since I don’t know how you managed to trap this, I don’t know really what to think… It’s something I haven’t seen before.

If you try a different controller, maybe, but I doubt it. Using transistors where everyone else isn’t doesn’t seem a logical approach.

What I meant was what direction is the head moving, not the Y axes. Are you sure you’re reading it correctly?

simonzaggio · November 25, 2024, 10:23pm

I was only editing homing cycles in config.h 3 months ago when I started to play with CNC. When I was trying to remove that sticking I have modified some code in spindle_control .h or .c but it hasn’t changed anything. Now I downloaded “clear” version of GRBL from github without any changes, maybe the changes I somehow applied to GRBL are still in Arduino’s memory like $$ settings (dimensions of machine, masks, steps per mm, velocities).

Additional information: I was installing GRBL by adding it as Arduino library and then using Arduino IDE to run this command: #include <grbl.h>

Still don’t get it… If you are thinking about laser head, it is travellig as in GCode here:
testSquare.gc (9,0 KB)

Maybe it is caused by some Arduino IDE settings?

Should I try another methode to install GRBL on Arduino?

jkwilborn · November 26, 2024, 1:59am

I’d suggest you go back to a standard already compiled version of grbl and see if the issue is still there. Once you modify the software all bets are off…

What package to I need to use the file (.sal) you posted?

simonzaggio · November 26, 2024, 7:11am

I did something like that, but I will try one more time and try to reboot Arduino’s memory.

You just need Logic 2 software, very cool thing

Uploading GRBL files I used to install on Arduino:

https://drive.google.com/drive/folders/1qzO08vx6MxtqjVX458kO2tYj48oy1fEL?usp=sharing

I also installed GRBL on Arduino Nano and still the same issue with GRBL from github repo. While uploading, there was information that Arduino may be unstable due to low memory. The ATmega328P is not enough?

Should I try installing GRBL with different OS? I was only uploading GRBL to Arduino on Win10.

Maybe I should give up trying with Arduino and jump to ESP32 controller? The problem with ESP32 is that it generates 3.3V signals and DM542 and LPS needs 5V. TXS0108E logic shifter 3.3 to 5 would not help, since DM542 needs at least 10mA to sink in and TXs can’t give that amount of current.

Are there plug and play modules for ESP32 to control 5V LPS and big stepper motor drivers like DM542?

jkwilborn · November 26, 2024, 9:57pm

Thanks for the link to the Logic 2 software, haven’t run it yet, but am looking forward to it… Not all of this stuff runs on a Linux machine.

It shouldn’t matter what os you use to compile and/or upload. The code should be the same. Most of the grbl code has pretty much maxed out the little Arduino (328p) processor, that’s why you get warnings, but it should run OK.

I have a DLC32 for a controller that I have used on my big machine. Didn’t use any on board drivers, just ran it’s control lines to the motor stepper drivers on each axes.

The DLC32 is a low cost 32 bit machine with a ton more memory than the poor old Arduino has and is much faster.

The DLC32 is also a 3.3V cpu, but has voltage translators for this, and if you use your esp32 board, you need to add these as the lps expects a TTL or 0 to 5V signal lever to set current limits as does external stepper motor drivers.

Good luck

simonzaggio · November 26, 2024, 11:12pm

I’m frustrated that I can’t find the reason behind that issue and run it smoothly on Arduino…
I have no idea from where this PWM deviations are… It is impossible that I have 3 faulty Arduino’s…The problem must be in firmware or maybe way of transferring GCode to Arduino, too much data at once or something…?
I’m able to modify the code, is it possible for GRBL to emit desired voltage by analogPin and not digitalPin with PWM? Analog 2 volts would be 100% stable I think… More stable than 5V for 0,4ms and 0V for 0,6ms I think…
I’d really love to find what’s going on, but I have to engrave something ASAP with good quality…
Since the problem is too complex for me I will try ESP32 or buy DLC32 as you suggest😃. DLC32 is based on ESP32 chip, so it is quite same thing as I know😃.

Does DLC32 have 5V DIR and PUL outputs and 5V PWM output for LPS? I’m tired of soldering everything once again🫣 I’d really love to just connect the PUL and DIR wires from DSP to stepper motor driver DM542 without additional level shifting and soldering, same with LPS. Too much energy on such hard to fix issue😂

Logic 2 is available for Linux😃

I have the last idea. Could you please send me GRBL library from your computer? Chances are never 0, that somebody changed something in code in github repo😂. Maybe your version, downloaded some time ago, would be stable. Thanks for help😃.

jkwilborn · November 27, 2024, 1:29am

Maybe very unlikely, but you’re probably right, that’s why I questioned your diagnosis. I have programmed these and it has to be very specific and on purpose to change the pwm output on these like you are showing.

If you’re using an open version of the Arduino code, then others would have the same issue, which I haven’t seen any evidence of this occurring. With an error like this all of these controllers with the same firmware would do the same thing or have the same anomaly no matter what os or other hardware was used.

Assuming the head is moving along the X axes, it has to be going or at least starting in a certain direction. The gcode isn’t usable as far as looking at the preview and determining head direction.

Are you running with bi-directional fill enabled on the edit pane?

I think we’re going to the wrong road here, too many things don’t make sense. It should work as is without you having to jump through hoops.

I suggest you re-run the original with a larger interval, this will give us a better idea of what’s going on and maybe a better place to look. It would be nice to be able to see each scan line. Use bi-directional engraving and lets look at it again. You’ve gone through a number of controllers and it hasn’t made a difference, so I think we’re looking at something incorrectly.

You’ve covered up the start of this with your pencil… I’d like to know if the first line is going left to right or right to left and make the lines further apart, increase interval to something like 1mm.

This is the preview showing what the head is going to do on a small box engraving, with bi-directional fill enable.

You can see the head travel and where it changes direction. Can you do the box again with a larger interval and include a photo of it and the preview from Lightburn? Leave out the obstructions, like the pencil.

This will give us a better visual, otherwise I think we’re going nowhere.

LsrSal · November 27, 2024, 8:09am

Laser control signal integrity/interference on PWM line would be my first guess. By the character of it and the fact that it appeared on the beginning of the burn where motors have boosted current. My bet it is interference on laser PWM signal.

Symptom also consistent with observation that USB1 has shorter lines than USB2 as it will feed controller slower that in turn will limit speed of the motion, thus shorter streaks.

Your own proposal to use shielded cable for laser PWM is a good one. Try it.
Make sure motor cables are not in the same bundle with laser. Make sure cabling is neat, properly twisted.
Use good and clean power supply, especially for the laser.
You may try to just reduce motor current, that will also reduce boost current, maybe just enough to eliminate that interference.

Bugged original firmware, IMHO very unlikely. I use original distro from GitHub many times and never had any problems. Unless you are making edits.

simonzaggio · November 27, 2024, 9:30pm

EMI is not the problem, since PWM signal is generated that way without any connection to hardware:

The problem has to be in the firmware or some other factor maybe while sending GCode to Arduino, the way it interprets it or way of installing GRBL on it, the signal is defected directly from Arduino. I uploaded clear GRBL from github repo.

simonzaggio · November 27, 2024, 10:19pm

Is there a chance, that something is stuck in EEPROM, Flash or stuff like that? I cleared EEPROM before installing GRBL. I also have very old version of Arduino IDE 1.8.16, maybe something changed in compilator and that’s the issue, will check that and edit this post when I try.

No. I’m running without it on purpose, to see clearly where the faults are.

Maybe the problem is correlated to the way I upload GRBL to Arduino or send GCode to it while working

Yes, engraved lines are on the X axis, and the laser head on this photo is moving from right to left:

You can asuume, that this photo is upside down in comparison to Lightburn preview. My bad that the photo is not legible but I wanted to indicate the faults with this pencil…

Here is simplified preview with changed 0.1mm to 1mm density of this box:

I can also connect on that try my logic analyser near LPS to listen the signal and send Logic 2 file there.

I will do this ASAP and try to do the post as readable as possible .

parsec · November 27, 2024, 10:57pm

Test this file as is.
test_square.lbrn2 (394.3 KB)
Change black layer to 13% power and repeat.
Post both outputs.

LsrSal · November 28, 2024, 1:47am

Pretty much all implementations of the GRBL use hardware timers to generate PWM for laser control. It is nearly impossible to randomly glitch and have such systematic stroke at the beginning of the burn. But let’s dwell on it:

You have mentioned Arduino and its compiler. Are you using source code and compiling it on Arduino or you are using pre-made HEX? If not - use this. I woudl suspect that old (1.8.X) Arduino compiler may produce different results, though once again - unlikely.

Uploads to processor normally verified with checksum and read-back. If upload completed without warnings - unlikely there is hidden glitch during upload. In your case it also have to be the same glitch every time, so it is unlikely.

What hardware are you using? What board?
I guess if you are able to use original GRBL code then it is based on ATmega328? Is processor original or Chinese copy? (hard to tell) Have you tried different lot parts?
Can you provide images of your board and wiring to the laser?

simonzaggio · November 28, 2024, 8:19am

Yes

No, I download source code and do a library from it, then use grblUpload from examples.

No, it’s not producing different results, downloaded newest version, installed GRBL, the same issue.

Arduino Uno original, Uno clone, and Nano clone.

On chip on my Arduinos says ATmega328P. Rather impossible that original Uno and clone Uno are from the same production line, but who knows, I wouldn’t be surprised if they are.

Wiring schema (doesn’t make sense posting it imo, the problem lies in the Arduino or firmware or other things correlated to firmware or arduino itself, however, with this connectios everything is ok except faults while engraving. I bet the same fault wave is generated while cutting material, but it is not visible)

Photos of Arduino boards:

I will try ASAP to install GRBL using .hex, never tried that.

Edit: the same faulty PWM signal after EEPROM reboot and uploading .hex GRBL…

simonzaggio · November 28, 2024, 10:55am

How did you create that GCode? That’s genius! I am impressed how you managed to create that faults in separation to engraving.

10% power:

Saleae Logic 2 file with PWM signal recorded for 10%:

13% power:

Saleae Logic 2 file with PWM signal recorded for 13%:

simonzaggio · November 28, 2024, 11:21am

Interval 1mm, 150mm/s 10% PWR, bi-directional fill enabled, box 10mm x 30mm.

Saleae Logic 2 PWM live file:

parsec · November 28, 2024, 11:22am

Did you try flashing 1.1h with LaserGRBL program?
Something strange, your laser didn´t ?? engrave the lines I left on the black layer

or they are hidden ??
The blue layer was at 0% power and seems engraved.
Maybe you have to lower your PWM or have some fluctuation in the 5V line, try a stable power to the Arduino.
I believe it´s something related to CO2 side maybe @ednisley @jkwilborn with the above results could say something.
Else try this:
Keep $30=1000
Change S Value max to something like 900 or 800 and test again.

simonzaggio · November 28, 2024, 12:04pm

Yes, and still the same…

I engraved it without changing anything as you suggested. One change was to set 10% to 13% as you guided.

USB is not stable power source for Arduino? I’ll try connecting it to DC-DC converter then. Maybe that’s the problem

Edit: Connected to DC-DC, nothing changed…

ednisley · November 28, 2024, 1:26pm

This configuration requires more performance than an 8-bit microcontroller teleported from the 1990s can provide. At the start of each line, the controller turns on the laser, then stalls with an empty command buffer, with an additional delay to parse the next command to arrive.

The stalls depend on how full the buffer was immediately before the line starts, so they’ll tend to become more-or-less regular as the pattern proceeds. Longer engraving lines will produce more regular results, although they’ll never tick along like clockwork.

The unidirectional results in that post show the overburned sections align with the start of the adjacent correctly burned lines, so the overall timing is correct.

The waveforms in that post confirm the problem: the first pulse at the start of the line is grossly too long.

Using a 32-bit microcontroller from the current millennium should improve the results:

Larger command buffer
Faster CPU processing
Hardware pulse generation

That exacerbates the problem, but isn’t the direct cause.

A power laser supply must produce a voltage high enough to fire the laser tube, then regulate the tube current. The initial voltage depends on the tube length (longer tube = higher voltage) and the tube length depends on its rated power (higher power = longer tube). In addition, higher power tubes require higher current.

A 100 W supply applies too much voltage to an 80 W tube, resulting in a higher initial firing current before the regulation kicks in. It will also arrive with a default maximum current setting higher than appropriate for an 80 W tube, so higher layer power settings will overdrive the tube.

Those stresses may not produce visible changes, because they’re only 25% higher than “normal”, but it definitely abuses the tube.