Hi. When homing my Neje 4 Max device, the actual x:y homing position should be x=0: y=460
When I send it home, it reaches the end of the y-travel and makes a brief grinding noise. When I check the “get position” function, it returns x=0; y=459.9
Subsequent jobs always seem to foul the top bar of the frame unless I make sure the work doesn’t go within 30-40mm of it.
I know this version of the Neje tool doesn’t use physical limit switches, rather it uses current detection to determine end of travel. Belt tension seems about right, there’s no physical fouling of the transport mechanisms that I can detect. I’m out of ideas now - can you suggest something else I could check or adjust to correct the homing of the Y-axis? Happy to provide detailed logs or setting dumps if this would help diagnosis…
Are you saying it runs into the rails, stalls out, and calls that Home?
Yes, pretty much - after pressing home, the z-axis lifts and homes without a problem, the z axis homes without a problem, and the y-axis … hits the end of travel, grinds briefly and stops. The y position then shows as 459.9 rather than 460.0, which makes me think something’s preventing it from making that final fraction of a mm, or else it’s bouncing back a tiny fraction after the grinding noise.
What this sounds like is your mechanical travel limit is a little less than that advertised. Tell your controller GRBL parameters that the max travel on that axis is 455mm instead of 460mm. I doubt you will ever notice the loss of 5mm in travel.
If your rapid speed to the Home position is high, you might even need to use more mm’s to give it slow-down room. By the way, approaching the Home switches at Warp8 speed is never a good idea.
Let us know how this works for you.
Thanks for coming back to me on this - it’ll be a few days before I can check it out but I’ll report back on the results!
Quick update - tried what Mike suggesated above (thanks for the input!) and it didn’t make any difference. On homing the y-axis, the right hand side of the gantry (viewed from the front, opposite side to the one bearing the mainboard and connectors) doesn’t appear to realise it’s reached the end of travel and the motor tries to run on for a brief period. So I took a look at the motor itself, and it seems that one of the pins (pin one or six depending on which end you count from) is corroded or slightly bent. My amateur reasoning is that this means that the controller is unable to detect the voltage change when the motor reaches the end of the run, so doesn’t recognise it’s at “home”. New NEMA 17 motor ordered, will fit it tomorrow and report back. Still interested in any feedback from Mike or others in case this is not the tree that should be barked up.
- Two motors for gantry, or one?
- Do both sides of the gantry touch the frame at the same time?
The gantry has a motor each side for the y-axis, and as far as I can see, they’re properly aligned. I’ve double-checked the squareness of the frame and it’s within the limits of my powers of detection 
I swapped out the NEMA17 motor on the noisy side where I thought there was a defective pin but it made no difference.
Enter $$ in the Console window. Copy everything after the $$ and paste it in your reply.
$$
$0=10
$1=255
$2=0
$3=0
$4=0
$5=0
$6=0
$10=3
$11=0.010
$12=0.002
$13=0
$20=0
$21=0
$22=1
$23=1
$24=250.000
$25=2500.000
$26=250
$27=1.000
$30=1000
$31=0
$32=1
$40=0.200
$41=10
$42=10
$43=0
$44=0
$100=80.000
$101=80.000
$102=800.000
$103=8.889
$110=24000.000
$111=7500.000
$112=1200.000
$113=21600.000
$120=400.000
$121=250.000
$122=20.000
$123=250.000
$130=750.000
$131=460.000
$132=45.000
$133=360.000
ok
X and Y maximum rates,
X and Y max accel rates.
Not a guru on all machines, but my experience is that X and Y typically have the same values. I would confirm with the manufacturer these are correct.
This is pretty tight, although I do not know what type of limit switches you have. If they are mechanical (roller lever) switches, I would increase this to 3mm. Youe seek and poll-off speeds look okay.
Thanks for taking the time to look through the figures! The axis speed and acceleration figures are out-of-the-box, haven’t modified these (or any of the $ values) at all. I will try the S27 modification, but the noise/collision seems to occur BEFORE the back-off is triggered. The limits are detected via voltage change rather than physical switches. In more news, I’ve been in contact with Neje tech support regarding this and other issues (the laser travel stops occasionally and randomly) in the middle of a job, Lightburn locks up, and it’s impossible to resume the job. Only a complete reset of hardware and software makes the machine usable again. NEJE have diagnosed a fault with the mainboard and are sending a replacement. Once I have it fitted, I will report back whether this has helped with the issue we’ve been discussing here. Thanks again for taking time to help, I appreciate it!