A axis rotary speed or conversion is not defined correctly Neje max 4 board 4 axis X Y Z A

I have a Nene max 4 (5 axis) with the rotary A axis. If I set the A axis with the measurement units from the setting , it behaves strangely . If I do the same thing with the Y axis everything is normal . Execution time of the A axis is excessively large compared to the Y axis. In the test I used the same project same dimensions for both axes.Where is the problem …in Neje,Lightburn or Grbl? Thanks in advance.

Those from Neje say the following:
LB = Lightburn
You can find multiple tests and discussions here in my discussion with Neje support.

Thanks in advance.

Can Lightburn solve this problem or not?
In the attached picture, Neje says that the problem is not with them…it is with Lightburn.

The A axis is a rotational axis, and is assumed to be running in “degrees”. If you copied the settings from the Y axis to the A axis, they would be incorrect.

You need to set the A axis so that typing:

G0 A360

does a single complete rotation of the axis. (You might need to use G0 A0 first, to zero the axis)

Once you have that set, the rotary settings may need to be adjusted as well, to use 360 degrees per rotation for the axis.

A-axis with G0 A360 makes only one rotation.

Ok, so that sounds like it is set up correctly. You’ve shared none of the other settings used for the rotary, or the settings for the job you’re trying to run, so all I can say is “that seems correct”.

It is not correct… the time on the A axis is long and if I change the measurement unit from the setting in inc/min the execution time if I use the A axis is extremely high compared to the Y axis. I have attached a picture with the mm measurement unit /sec to see the difference. I repeat if I put inches/sec it is extremely high.

without changing anything…just the A axis in Y

You’ve shown screen shots of your console window, not settings, so I’m still not sure what it is that you’d like me to do here. I can’t see your laser, or read the settings from the machine or LightBurn using my mind. I’m good, but unfortunately not that good. :slight_smile:

it was just an example with the resulting time without changing anything.

My discussion with the people from Neje as well as many gcode examples and others are here…I wrote above


You appear to be running in Line mode, which very few people do with a rotary. When engraving, the rotational rate of the rotary doesn’t matter as much since most of the time is spent scanning across the cup.

The GCode you posted says you’re running at 90 mm/sec.

You have the A axis max speed shown as 15,000, which means 15,000 degrees per minute. That’s 250 degrees per second, or about 0.7 of a full rotation per second.

With an object circumference of 43.9mm, times 0.7, that translates to a max “surface” speed of 30.7mm/sec, which is about 1/3rd of what you asked for. This is what I believe is happening, at least.

If you use a larger diameter object, the circumference will be larger, so your maximum surface travel rate will be faster, or you could increase your maximum angular speed when using a smaller diameter object, since they don’t have as much mass and will be easier to spin.

@mada , I agree with Oz @LightBurn .

However I’ll add that the slower feedrate you’re experiencing when performing coordinated G1XA motion may be due to a bug in Neje’s grbl controller firmware. I ran into the exact or similar problem and it lead to there being a bug in my grbl controller firmware, but not a Neje controller in my case. I am running a customized version of an open source grbl, however the bug was found to also be in at least one other grbl version since they seem to have a common origin. There could be more split threads of grbl versions with the bug also, such as the Neje version. If this is the case, you can refer Neje to the details and fix here https://github.com/grblHAL/core/discussions/241

1 Like

another test

My problem is exactly that of the video presented.

And what can I do in this case if the Neje program is not open source?

and vote for this feature: Add option to use G93 Inverse Time motion mode · LightBurn

Would you also check the other attached file, the one with 150 speed? I’m waiting for a response from Neje.They ,Neje"claim that everything is ok from their side, LB has problems.

A AXIS…txt (24.2 KB)
Y AXIS…txt (16.7 KB)

So a couple of observations, I looked at both files…
re. AAxis.txt,

  1. Like Oz @LightBurn has said previously, you can’t drive the A axis faster than its maximum speed of 15,000deg/m (250deg/s). The gcode is produced in deg/m and is relative to the programmed circumference of your cylinder on the A axis and your desired surface speed of 9000mm/m (150mm/s). Line 58 of this file is driving A at F103132deg/m, so it will only move at max of 15000deg/m, and naturally that motion will run much slower relative to other G1XA motion even if your grbl does not have the G94G1XAF bug.
  2. your shape design is fairly complex for trouble shooting a motion problem, suggest you use something very simple to diagnose the problem. I’m providing a simple test case here.

The shape photo and .lbrn2 file are for you reference and extended use if your choose. You can simply run the .nc.txt file, you don’t need anything in the A axis chuck, the laser power is zero. Motion begins at current position, make sure your laser will clear the chuck if it mistakenly moves over it, chuck on left, X moves right from current position. I used a cylinder circumference of 50mm to gen the code. The lines in the the shape are all 50mm length, each one should “cut” (traverse) in approx. 3 secs. If the 135 deg line (last one to cut) does not traverse in 3 secs but rather 22 secs, then your grbl controller has the G94G1XAF bug; Neje will have to fix it. They can use the grblHAL link as an example of the fix and grbl code/bug definition.

G94-XAF-test.nc.txt (317 Bytes)
G94-XAF-test.lbrn2 (24.5 KB)

The project in the attached file is a circle of 10 mm by 10 mm. As a buyer of Neje product I am interested in who can solve this problem… Neje (the seller of my product) Light burn (the one from whom I have a license) or Grbl (who works with the two)…I am not in a position to modify this because Neje is a closed source program. In the text document I replaced the Y axis with A and the project time is ok… but I, as a Neje buyer, do not I think I have to do this. I, as a buyer, have to connect the A axis and the product sold by Neje has to work… I say… What do you think?

Which text document ? and why did you do this ? How did you do this ? Be specific please.

I’m not sure the previous questions matter if you follow the next step. Are you confirming my test case proves the G94G1XAF bug in your Neje machine? If not, what were the results of running my test case?

Agreed. Contact Neje, give them the simple test case to proved the problem, and ask them to fix it please.