I see three HR4988 Stepper drivers and the lines from one of them are going straight forward to the (actually unused) z-axis connector.
I have no idea what you are referring to here? Isn’t this about limit switches… or are you eluding to install a faux Z axes?
This just sounds like a bunch of fishing expeditions, especially if there was a firmware change. Even though @berainlb feels there is no reason for the manufacturer to change anything, this stuff should work and isn’t. The simple fact that it isn’t working indicates some change in the firmware. I find it had to believe they changed it so you couldn’t use limit switches. Just shows how little they care about the end user. One of the things that makes for a good machine is for it to know where it’s at. The manual method is never even close to the automated homing results relative to the accuracy of the machine.
If they didn’t want to modify the code, why is the Z axes even being sensed, if it is. It didn’t do it on previous machines.
I modified my grbl and all it took was to comment out the z axes homing constant and it didn’t compile the z homing code. There’s no reason to enable that…?
When you home the machine with a Z axes, the proper techniques it to raise the mill head high enough to clear all the parts before the X and Y are moved. My factory Vevor moved the Z axes down, just what you don’t want… that’s how well they are thought out from the factory.
I have a co2 and a few 3018 types, the one I use the least does not have homing switches, which is why I use it the least.
I might be the only one, and I’m as guilty as the rest… but IMHO … This thread has kind of been hijacked at post 9, as the original posters question was answered. Made sense to the hijacker as it’s on limit switches for his machine, but should have been separated at post 9…
Correct, it‘s about limit switches and the fact, that the homing procedure fails, because there is no working z-axis.
And according to your post……
… i came to the idea, that the simpliest workaround (which i can produce by myself) is to take a small Stepper motor (e.g. from a CD-Player), combine it with a switch and so simulate the Z-axis…
Oh nice. I wonder if the plan is to offer a z-axis motor for laser height or if the controller will be used for other models with built-in z-axis.
You misunderstand. I meant that the manufacturer moved to a different GRBL base for their software. With that shift it wouldn’t surprise me that they no longer include the configuration to only do XY homing.
It’s possible they offer sensorless homing. I saw something from Ortur that said limit switches were no longer necessary but did not see a rationale.
Original GRBL by default has 3 axes, XYZ. It also defaults to XYZ homing. Z axis is sensed and available even for earlier Ortur machines. However, homing is not required for Z in earlier machines. Removing Z-axis homing is a change from default. I’m not sure about the situation with grblHAL but I know they support at least 5 axes so would not be surprised if they also assume XYZ homing.
This is actually quite common. Believe all 3018 machines assume XYZ homing which some users would prefer not to have and cannot be disabled in configuration.
I believe the stepper drivers assume bipolar stepper motors. I think CD Players and such are generally unipolar but I may be wrong.
Electrical components are low cost. The only overhead is the initial engineering, the cost of switches and wiring is much higher, I’d suspect. If it wasn’t this wouldn’t happen…
Much like electronic ignition is lower cost than the points/timing advance mechanical part. More dependable.
I recompiled grbl and the only thing I had to do to disable the Z axes was comment out a compile time constant… that determined what was compiled in the final code. Could also change if each axes homed separately or simultaneously.
You would think they would at least mention you can’t add limit switches…
Not familiar with grblHAL…
Yes I misunderstood
It wouldn’t take much for Ortur to offer a firmware that allows for XY homing so hopefully they do it. I’m more eager to see the source code released so that people can do this on their own if required.
Open source is always the best option.
I have a first answer from Ortur.
They propose to flash the Firmware from Aufero Laser 1 and expand x and y range.
Bug also they asked me, which Firmware Version is installed actually. The wording sounds a little bit as they are suprised and wondering why there is a working z-axis in my Laser 2.
Now i have to figure out the Firmware Version.
Was this from Gil? He’s often on this site.
One thing about Ortur firmware is that they have a check to disallow cross-flashing. Sounds like there’s a way of overriding this.
Just run $I in Console to get your firmware information.
Thanks! (I‘ll do that tomorrow)
I saw a different unrelated post about Z-axis focus and saw that his controller used custom GRBL configurations to allow Z-axis homing. Decided to revisit grblHAL to see if they had possibly extended their configurations to control this in your case.
Found this in grblHAL documentation:
$43 - Homing cycles
Number of repeats of each cycle to perform when homing, more may improve accuracy
$44 - Homing cycle 1
$45 - Homing cycle 2
$46 - Homing cycle 3
$47 - Homing cycle 4
$48 - Homing cycle 5
$49 - Homing cycle 6
Mask, specifies which axes to home in each cycle
So based on this I think if you change these settings you should be able to avoid Z-axis homing.
$44=4 -> $44=3 $45=3 -> $45=0