Does anyone else have the problem that the diagonal transverse movements are extremely slow (around 300mm/min or slower)? That is significantly slower than my cutting speed of 900mm/min.
This affects all movements of the Y axis towards the home position and diagonally away from it, but not when homening itself.
Movements straight away from the home position are, however, carried out at full speed.
Does the Yaxis Max speed in GRBL match the Xaxis value?
No, they are at X30000 and Y6000 mm/min, and they shouldn’t be because the axes are designed differently.
With both speeds at 6000mm/min, all transverse movements are slower than 6000.
Fast whitespace scan and G0 moves don’t change that.
I don’t think it’s a problem with Lightburn, more with atomstack.
I used this file for testing.
Test Travers.lbrn2 (6,8 KB)
I have exactly the same problem with my IKIER K1 70W. The problem does not occur with the IKIER K1 Pro 1064nm.
It really doesn’t seem to be due to Lightburn…
Will depend on the firmware.
A lot of newer firmware have max feedrate additional speed limitation settings, which tend to be there to control accelerations.
Could you do a $$ in console and post results?
Sure …
$$
$0=10
$1=25
$2=0
$3=7
$4=0
$5=0
$6=0
$10=1
$11=0.010
$12=0.002
$13=0
$20=0
$21=1
$22=1
$23=3
$24=200.000
$25=2000.000
$26=250
$27=4.000
$30=1000
$31=0
$32=1
$33=2
$34=10
$35=1
$100=100.000
$101=100.000
$102=1600.000
$110=20000.000
$111=20000.000
$112=1000.000
$120=1000.000
$121=1000.000
$122=500.000
$130=410.000
$131=410.000
$132=120.000
$140=30000.000
$141=20000.000
$142=1000.000
$143=2000.000
$144=1000.000
$145=500.000
$150=6000.000
$151=6000.000
$152=1000.000
$153=1000.000
$154=500.000
$155=500.000
ok
These should be 140 current and 150 microsteps
I think they are being repurposed on that firmware for something else, Only Atomstack could qualify.
Question though, the same behaviour happens if you design on LaserGrbl for example correct?
I have now sent a support request to IKIER (Atomstack). Let’s see what comes out of it.
I’ll try out LaserGRBL, but I think the problem is in the firmware of the laser.
Thanks, I’ll let you know when I’ve heard from them.
Unfortunately, I can’t give any information about lasergrbl because I’m on Linux.
I also haven’t gotten around to writing with Atomstack yet.
1 Like
Click Devices duplicate your laser
,
then edit as a custom GCode device profile as GRBL-M3 flavor with the following options:
.
thank you, your post gave me an idea.
when setting up an atom stack for the first time you have to use GRBL-M3 (1.1e or earlier).*
then the rapid movements will work but then he has hardly any cutting performance.
OK, new day, new findings.
With GRBL-M3 (1.1e or earlier) it no longer has any cutting power but the rapid movements work.
With the custom g-code duplicated from GRBL-M3 (1.1e or earlier) it has no cutting power and no rapid movements.
With the custom g-code duplicated from GRBL it has power but no rapid movements.
The question is, have you made any additional changes?
I’m following this with interest. Please, do not forget to keep us updated, and if you are able to fix this slow movement.
I have a firmware from IKIER, sent by them a week ago, but I don’t know how to update. The say “insert the pendrive with the firmware into the machine” but the machine has no USB port… morons!
another round of testing.
I borrowed a window machine and had a g-code created from the test file using LaserGRB.
Both cutting force and rapid movements work.
Draw a square and with GRBL-M3 device Custom GCode (with the 3 changes) click Save GCode and post here the file in a reply.
The one you wanted is the custom GCode.
I created a few different ones so you have something to compare.
LightburnGRBL.nc (5,6 KB)
LaserGRbl.nc (4,8 KB)
GRBL-M3 (1.1e or earlier).nc (5,4 KB)
Custom GCode.nc (5,3 KB)
A thousand apologies. I have a few device profiles and used the wrong.
The correct and checked options are as follows:
Verbose Output make it easier to check GCode.
