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
This is a video I found but I don’t speak Italian. But he walks you thru it. I’m still confused. Hopefully once I slowly walk myself thru the configurations between this thread and this video I will have a better understanding of how to configure everything. Parts will be here next week. Still haven’t figured out what I’m going to use as a switch box may just have to make one out of 1/8 plywood. Any suggestions would be great on software configurations. I thought after I get it working can’t I make a copy of my configuration and post it here for other people.
Turn on closed captions and then switch to English auto translate, it works well enough to follow along. I’m in the process of building these myself. If you order these limit switches https://a.co/d/4add1dn then this Thingiverse file should work with them Limitswitch cover for Aufero Laser 2 and other by cosmo1981 - Thingiverse Theoretically that is, I’m waiting on the switches and my friend to print the covers.
Yeah I looked into it last night. I don’t normally watch videos in other languages so I had never needed that function before but I figured it out. Thank you
So if I homed to the top right corner would it eliminate the negative location without having to create a button? It would bring me to the zero of x and y for the 3rd quadrant. Or no because I would still be working in a negative quadrant. Doesn’t ortur lm2 have the same board? Can’t we flash that firmware on our board?
Does anyone know what size jst contact I need to fit the aufero laser 2 main wiring harness? I watched a video that said it was 1.25mm pitch but I think it is a 2mm pitch. Can anyone help me with this?
One careful measurement outweighs a kilo-opinion!
Deploy a metric scale, line it up with the connector, and measure what you have. It’s easiest to measure across all the pins, then divide the total distance by (#pins - 1), rather than squinting at two adjacent pins.
For example, suppose you have seven pins spanning 12 mm from first to last:
12 mm / 6 = 2.0 mm
Attention to detail matters, because you will find connectors with 2.5 mm or, worse, 0.1 inch = 2.54 mm spacing.
Just some pictures of the aluminum brackets I made to hold my limit switches. Made from some scrap aluminum angle (iron?).
Those brackets look very professional…
I just 3d printed the ones for mine… they used hall effect sensors…