Scanning offset problems

LightBurn Software Questions
1

After upgrading the 2.5W laser diode on my machine to one of those Neje 40W modules, I have been “seeing doubles” on my raster scans (fills). Scans with the same controller/firmware/gcode sender/machine/feedrates, using that 2.5W laser were perfect. I’m using GRBLesp32 on a 6-pack, with laser mode enabled, accelerations limited to 127, xy speed limit at 7500, and z speed at 2000. At <=6000mm/min with a diode, having any issues with scan offset seems weird. What makes this rediculous, is the laser is actually turning on too early, without even using scanning offset in lightburn!

Regardless, I ran some tests on the machine to figure things out. This image shows the laser turning on too early using the default lightburn settings “offsets disabled” (bottom most line is drawn from left to right, alternating as it goes upward on each area):

IMG_3809
IMG_38091024×768 321 KB

The numbers above the patterns show feedrate in mm/min, and the Lightburn “Scanning Offset” used for that speed (at 60% power on the 40W module for those interested). The “overscan” setting is maxed out to 50%. At 6000mm/min observing motion it was hard to tell if the gantry was 100% up to speed when the laser went on/off. The other data points I could tell were definitely up to speed based on audible observation.

After an about one hour of measurements and test iterations, I was able to come up with a list of feedrates/offsets to produce this seemingly OK test:

IMG_3808
IMG_38081024×768 394 KB

Now, after completing this “scan offset tuning” mission, I was excited to start producing some neat stuff. Unfortunately there are still “doubled up” artifacts on my etches with scan offset enabled and the table filled out with those values! (cuts/lines are OK) This image shows a cube with a doubled “100” on top… at 2000mm/min using the offsets labeled “best” above:

IMG_3810
IMG_38101024×768 236 KB

First off, based on how scan offset is supposed to work from all the tutorials I’ve read, with my laser turning on too early the offset should be negative, but it ended up needing positive? Why is lightburn turning on the laser too early to begin with? Any suggestions on how to correct this? It’s hard to believe my controller is predicting the future and doing this… unfortunately verifying start/stop points is very difficult with relative gcode moves (I have no gcode veiwer that can graph that).

I can’t imagine this method of offset would work at all for most hobbyist lasers, since they don’t scan at a constant speed with a decent feedrate. You can’t predict what the planner will do, or what offsets it would need after the planner modifies output. This offset concept only applies if the scan speed is fixed the entire line (so either industrial controller, or very low resolution scan).

2

How are you powering the NEJE? Do you have a dedicated power supply going to the NEJE or is this going through your controller? What is the current rating on your power supplies?

3

Thanks for the quick reply. I’m powering the Neje with a 12V 300W psu, which is shared with the motors and other 12V devices. It is plenty oversized for the job for sure. Also, I was previously using an off brand 2.5W laser (all the rest the same), and it never seemed to have this problem… but it was about a year since I used it, so I figured lightburn may have introduced the problem.

However, looking at the gcode in ncviewer, I can’t see any issues created by lightburn after all. Here’s a gcode I just produced with lightburn that doubles up on me:

greyscaleWheel2.txt (207.3 KB)

Just to be sure I’m not just going crazy here, someone might want to verify it looks OK. I honestly cannot understand what the heck is going on… it’s like the laser is predicting the future LOL! Doesn’t look like lightburn is at fault here though.

4

I doubt the laser is prescient. Why are you assuming the laser is early rather than everything else being late?

Is the Neje getting power directly to the PSU of through the controller?

Current requirements for a 2.5W laser will be quite a bit less. But I don’t anticipate you having a problem with a 300W power supply.

I don’t see this as likely. You may want to try putting the other laser module back on just to confirm the only difference is the laser module.

I’m not familiar with the 6-pak. What is the source of PWM. Is it designed for high frequency? As in not designed for like a 3d-printer head bed or something. If not, I’m wondering if it’s just slow in reacting.

I took a look at the gcode but it was a bit messy. Was this with offset scanning enabled? Can you run a much simpler test with no offset scanning? Perhaps a 100x100mm square positioned at 100x100? LightBurn is rarely going to be at fault for incorrectly generated g-code.

5

scanDirection
scanDirection650×705 95.1 KB

IMG_3809
IMG_38091024×768 321 KB

The numbers on top are mm/sec and scan offset used. I also physically observed it was running as shown… the bottom most lines were burned left to right, and so on. All of the other layers have identical parameters, other than the feedrates.

Yes pretty much… I’ve got a 10A rated relay on my controller enable pin, but it’s not dropping volts. My oscope shows 12.2V connected 3" from the module while it’s at 100%.

Yes, it is esp32 based, runs fluidnc (replaces grblesp32, which is based on current grbl), and is set to 5kHz pwm output for the laser. It has a buffered 5V output as well. Bart the dev of fluidnc and designer/vendor of the 6-pack board has never had 3dprinting aspirations for his hardware AFAIK. The reason behind the project was to bring the power of esp32 to grbl, and it does perform quite well from my experience (much faster raster scans vs grbl 8bit for example). Note that I just upgraded to fluidnc as part of troubleshooting this. It has the same issue as grblesp32… which I was running for a long time (also with the 2.5W laser).

The offset was disabled, and I even deleted the table of offsets from the device config just to be sure. If you mean overscanning, yes it was enabled. I’ve always had it enabled, even with the 2.5W laser. I looked back at some old gcodes as well (for the 2.5W laser), and the only major diff was S value, since it’s a weaker laser.

IDK man, but I am seeing double… definitely something wrong with me or the laser, hehe. :wink:

That is the next logical step, especially since it is fairly easy to try.

6

Are you equating the bottom line being offset left of the line above as drawing early? I guess I don’t have that assumption. I see it as just being off. Perhaps burn a square around the expected perimeter of the scan lines. Should give you a better idea of how off the line is from expected.

Is relay switched on once at the start of the job or for every PWM pulse?

This should be plenty assuming low latency.

Doesn’t surprise me. Ortur has recently moved their whole line to ESP32.

Interesting… but no change in behavior.

I did actually mean offset but your explanation makes sense.

So speed is not a factor in this? Hmm…

Would be good to narrow the variables.

But assuming for the moment that the difference is truly in just the module I’m trying to think of a good test to determine what the difference is.

Since you have access to a scope it would be interesting to test the latency between PWM input to laser output. The difference in performance between the two modules might explain the difference. But frankly I’d be surprised if there would be a substantial difference between these.

7

It turns on at the start of the job, and off at the end.

I think speed may be related indirectly TBH, but S is the power output (or spindle speed), F is speed (or feedrate).

That sounds like an interesting test… I’ll do that while I have both lasers off when I go to swap for more testing. That’ll have to wait until tomorrow evening, since I stupidly threw out the mount I printed for the previous laser module and have to print another (I thought the new laser would make it obsolete). I am suspecting there may be something wrong in the controller code, since gcode is easy to rule out with software. I’ve run some more varied tests, including larger more complex images. Everything it etches has some doubled up portions in it, and it gets worse in areas where there is lots of acceleration happening (like transitions from dense pixels to whitespace, and visa versa). In all cases, ncviewer.com shows the tool points are where they should be in the gcode.

They’re both diodes, and I’ve never read about issues with diode latency (most folks discussing scan offsets are running really fast feedrates on co2). So I believe there may be something may have gone wrong with the controller’s planner. It is not syncing motor steps and pwm output correctly; maybe some library introduced a bug somewhere. The fact that I’ve used 2 different firmwares and 2 different esp32 modules is not encouraging. I’m definitely not skilled enough with coding to find if there is something in fluidnc causing this.

8

Perhaps dial-back each change introduced since the last working state. If you can get to a known good working state then it shouldn’t be too hard to isolate what caused the problem by introducing one change at a time.

One question… have you ruled out any mechanical issues? Perhaps a slipping pulley on the stepper shaft? Do you see issues only in one direction and not the other?

9

It happens to be an mpcnc primo, which often mills pcbs, wood, and aluminum with good results. I went over everything and checked torque, tighten belts, etc before looking to software issues. The issue presents itself identically in the scanning direction, regardless of which scanning direction I choose. When I enter measured scan offset values, the scan test then looks fine regardless of scan direction (wish it also worked for real images though). The dimensions of cut lines are perfect. So I think mechanical issues can be ruled out for sure.

Thinking about testing the modules latency… that would mean I have to pull the driver pcb off my new neje module to tap the output. Not that I expect any help with early failure from the vendor, but it’s a rather complex assembly and so new… and expensive, lol. I normally don’t hesitate to hack, but in this case I’m not yet ready with all the lower hanging fruits I still have to pick at. So then, I think your next suggestion of reverting firmwares may be the next logical step to fix this… after I do that quick swap to try the 2.5W.

10

Sorry. I wasn’t clear. I meant do you see this problem in the Y direction as well as X?

I didn’t realize this was a MPCNC. Are you really getting speeds in the 6000 mm/m range? That’s quite high for such a heavy head assembly.

The easiest path to getting to a working state is preferable I think. The 2.5W swap is a quick and easy check. Maybe you can zip-tie it if you don’t have the mounting plate. Just needs to be secure enough to run the test.

11

I understood, but was not clear myself. By scanning direction, I meant X, Y, and both of the 45* angles as well.

Yes, in fact I tested it and it won’t die until it hits about 8000mm/min. So I have it limited to 7500 in firmware.

I already printed that adapter, so will test that after work today. Wish me luck!

On a side note, I’ve started a discord thread with the firmware devs, since I think that is where the problems really lies. If it fruits anything I’ll report that here.

12

So I found the problem, and it was in my firmware config. In case anyone else needs this, in fluidnc config.yaml I had:

stepping:
  engine: I2S_stream

Upon suggestion by Keller on the fluidnc discord, I tried:

stepping:
  engine: I2S_static

…and now it etches perfectly!

Thank you very much for your time and patience @berainlb… I owe you a beverage of your choice!

Kev

13

That’s amazing. I’m sure you’re relieved and makes sense that you found it in the firmware.

Can you confirm that that GRBL_ESP32 was configured to I2S_static when it was previous working? Do you know what these settings do?

14

Oh yes, I was very happy the moment I saw the first few lines on the test aligned perfectly.

The relevant lines in my grblesp32 machine files have always been commented out (using defaults):

//#define DEFAULT_STEPPER ST_I2S_STATIC

The line is still the same for the mpcnc example in grblesp32:

I have a feeling somewhere in the code there is a use of streaming as default in the latest version of grblesp32. When I updated to fluidnc shortly after, the default for all example files (equivalent of a machine file in grblesp32) used streaming. That helps my suspicion of the latest grblesp32 using streaming by default, since they are maintained by the same ppl. At any rate, the fluidnc wiki compares the settings with minimal verbage, " I2SO_STATIC is more tightly integrated with the timing of the motion engine and I2SO_STREAM is faster.":

I2SO is the name of the communication protocol used by the IC’s which add io capability on the 6-pack and other esp32 boards (adds more pins to the sparse esp modules). They communicate directly with the stepper drivers, so I think syncro is a min requirement. ‘Tighter vs faster’, I’m not exactly sure what that means. I’ve asked some ?s about that on discord with no answer yet. There was a mention about trying lower acceleration to see if it changed things, and maybe that was with insight to how the new planner stuff works. It’s all above my head, but it is exciting to hear about fundamental improvements to nc controllers.

15

Aha, I found where it slipped in on me, but not sure when! Here is where it is:

16

That project seems pretty well documented. They cover a wide variety of topics at a fairly good level. I still don’t understand how I2S_Stream differs but at least I understand that it’s one of a few different step generation schemes. I’m trying to figure out under what circumstances you’d actually want this behavior. I suppose for some CNC operations that are moving much slower this wouldn’t be a problem.

My other takeaway from this is that this was an issue with stepping, not an issue with laser firing. So steps must have been coming in too slowly relative to time? Not sure.

17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.