i have some questions about what can cause line shift when bi-directional scanning.
I know how to compensate for it in LB, but i want to find the cause.
Line shift is around 4mm 300mm/s (need to set 2mm to compensate it).
Laser build is homemade, linear rails are genuine hiwin brand.
I checked belts, mirrors, lens cant find any backlash.
Tried it with Ruida 6432 and with GrblHAL controllers, both same issue.
I tried 40w tube and 90w reci tube - same issue.
I got the problem on both axis X,Y.
Length of the shift is getting longer with more speed.
Acceleration doesn’t matter 1000 or 10000 same length.
If you’re absolutely certain that you’ve removed all backlash out of the mechanics then the issue is caused by latency between triggering the firing event and when the firing event actually occurs. There’s also likely some backlash left in the system as it’s impossible to remove all backlash.
So for example, if the laser head mechanics are moving along at 100 mm/s but there’s a 1 second delay between commanding the laser to fire and the laser actually firing then the laser head would have moved 100 mm farther than the intended start location. Same thing happens when the laser is commanded off.
Think of this like in video games where you press a button on the controller… there’s a bunch of processing that has to happen between button press, to input detection, to game mechanics being processed, to video output being created and sent, to TV reception, to video processing, to actual display on screen. The lower the speed of the laser head and the lower the latency, the more accurate the placement of the burn and vice versa.
The scanning offset adjustments allows you to compensate for that latency.
Or… I may have this completely wrong and there’s an entirely different explanation so take that for what it’s worth.
I have one more laser 80W made in china with some modifications like same Ruida controller and X axis linear rail. Line shift there is like 0,25mm. But in the case above its around 4mm.
Do you have the same LPS and tube in both? I’m not certain but I assume the greatest variation will be on the latency of laser firing. Although I could delay in the motion control causing a similar issue.
I tried 40w tube/PSU and 90W reci tube/PSU and both have same lenght of the line shift. The china one is 80W.
To be sure i will try to swap the ruida controllers between the lasers.
So you’re saying one of your 80W Chinese machines has a .25mm line shift… But this other machine has 4mm. And you’ve now tried swapping tube/lps as well as controller?
Have you tried the 80W tube and LPS in this machine?
If it’s not the tube and LPS then that really only leaves the motion control side. Are you possibly using servo motors in this machine?
So the culprit seems to be driver DM332T when i try DM556 everything is much much better.
It looks like DM332 have some latency problem or something, but i dont know why, it should be able to handle pulse input frequency up to 60 KHz.
Nice job isolating the issue. If the issue is in the driver then that implies a motion delay rather than a delay in laser firing. I need to rethink how this works. I would have expected overscan to potentially account for that but perhaps not. I would have also expected laser to fire ahead of motion but that also doesn’t seem to be the case…
High frequency does not necessarily equate to low latency as there could be a delay in processing.
I do recall reading something a couple of years ago about low quality or potentially counterfeit stepper drivers but can’t recall if DM332T was one of the potential problem drivers.
I will try to play with microstepping values to see if it helps or not.
Drivers are bought at omc-stepperonline.com so i believe they should be ok.
And i will try to use some other drivers pololu style, TB6600, etc just to see if there is any diference.
Little update, it looks like all drivers from omc have latency, yesterday tested DM556 wasnt from omc it is no name china. Today i tested omc drivers DM556T, DM542T, DM332T and all have problems DM556T is better than other two but still suck compared to DM556. TB6560 v2.0 is ok too.
Microstepping values doesnt seem to have any impact.
So all of omc drivers have some nasty stuff The chip codes are erased away by laser.
But they forgot one and one chip wasn’t completely erased (i ended up opening almost all of my precious drivers). And i looks like they use same chip for all of them (not 100% sure, but they looks same or at least have same packaging). 1302 x 032b
I wish I could find that article I read previously about potential driver IC issues. If I’m remembering correctly it was an issue of counterfeit Toshiba ICs or possibly a change to a slightly different model number of IC still from Toshiba.
One thing you might want to try is to reduce current settings on the driver. It’s possible that the IC will behave differently under those circumstances but you’re getting into very technical territory.
)
Hmm i have few of them 
The chip codes are erased away by laser.
(i ended up opening almost all of my precious drivers). And i looks like they use same chip for all of them (not 100% sure, but they looks same or at least have same packaging). 1302 x 032b
