We added a cross-line pointer to our atomstack (working area 400x850). To get optimal sight of the pointer, it is located at approx. -30mm in x-direction and 30mm in y-direction. Everything works like a charm but the problem is that with the y-setting being a positive value, we seem to lose those 30mm in workspace width.
On the other hand, when placing something inside the first 30mm of the x-axis, framing will cause a hardware crash, since the offset will move the head in a negative position.
so we lose 30mm of workspace width because it will never be reached after pointer offset. On the opposite side we lose 30mm of width because it would cause a crash. So in total adding the pointer costs us 60mm of workspace in x and y directions.
(FYI: The x and y motors are switchen and the origin is at top left, since we use the machine in landscape. So, y is pointing down and x is pointing to the rigth)
Now the question: How is it suggested to deal with this problem?
Request: If there is no solution yet: Could you implement something like a frame in the workspace where there are regions that show where framing is possible and where working is possible without framing? We have a dual-extruder 3D printer and there, the accessible regions for both printheads are shown on top of each other to see where dual extrusion is possible and where only one of the two heads can be used. Maybe something like that could be implemented.
If I’m thinking of this correctly you should only lose 30 mm in each dimension, not 30 mm on each side of the head in both dimensions.
You should be able to address this by removing 30 mm from each dimension in Working Size in Device Settings as well as in $130, $131.
You will also need to position your homing switches accordingly.
You explained that you switched X and Y motors and origin but I was still confused as to the orientation of the system. Can you create a drawing?
In either case, the negative X offset will make 30 mm from the right side of the bed inaccessible. Make sure X homing switch is allows cross-line pointer and primary laser to reach as far left as possible. This should allow sufficient space on the right to not crash.
For positive Y offset, the crash risk is at top. If you are homing to top then simply set homing switch such that nothing crashes at top but is as close as possible otherwise.
Of course you’re right with losing only 30mm. My bad.
So removing 30mm for both axes I will do. Regarding moving the homing switch of the x axis: Sure, it would be a solution. But since the issue arises from a software limitation, I’d rather try to solve it in software before making hardware adaptions: Is it possible to force a defined position to machine zero after homing? Is it possible to make a macro for homing that commands to offset y-zero by 30mm, such that I can home to the switch on the top and then simply command that machine zero is current position plus 30mm?
If yes, could you point me to the necessary G-code commands? Is there a comprehensive documentation about G-codes for lasers somewhere awailable online?
You could probably do it but won’t be a single change. How far off is this from working now? I don’t think it should be much. If you don’t want to move the switch, then consider fabricating some sort of add-on piece that will trigger the switch where the crosshair is located. I’m assuming the crosshair is incapable of triggering the switch. That would be a reliable and simple solution.
Having some homing tool to offset the home position might be a solution. But still, I’d like to comfortably sit in my chair
I had a thorough read of the sources you gave me. I tried a lot with playing around with G92 and G54 settings. I think what I want to do is possible somehow, but due to pure chance I found that my controler has some undocumented settings:
Sending the query $* will return a huge list with parameters. And there, a parameter called $X/Home/Mpos=0.000. So I tried to set $X/Home/Mpos=-30.000. This does EXACTLY what I wanted, yeii
But what is this sorcery? Is this something that is atomstack specific? Is it part of grbl or an addition? I didn’t find anything about Mpos after homing in grbl. Is there a native setting that works for all grbl?
Note that this will home the machine so be prepared for it.
I’m curious why you think this is a less robust solution. There are fewer things to go wrong than a software workaround. And you’re in fact already dependent on the existing homing process.
The machine is not on right now, but I can tell you that when executing your commands, all offsets are at zero and Mpos is at X=-30 and Y=0.
Making an offset of the home switch will work if the offset token is removable such that after homing the machine can move to X=-30. But then I need to disable softlimits. With the solution I found, the allowed travel range is from -30 to 820. No idea if this is a bug since there seems to be another internal zero that is able to offset Mpos zero. I didn’t have enough time to look further into the grbl sourcecode…
Well, for me the probelm is solved and I’m most thankful for your help berainlb!
If other people encounter the same situation where the marker is at a negative offset, this is the solution I found. It works with atomstack. No idea if it also works with other vendors:
For the axis that has negative pointer offset: $X/Home/Mpos=-30.000 (pointer offset value). The parameter is persistent, so you only need to do this once.
Make lightburn workspace smaller by the offset values of x and y, respectively (in my case 370 and 820)
Leave the travel ranges in $130 and $131 as they are (in my case 400 and 850)
Activate soft limits ($20=1) if you like.
With this solution I can use the original limit switches and have a working area of 370x820mm that is simultaneously reachabel by pointer and by laser.
Thanks again for the help and keep up the great work with lightburn!
This isn’t how I would expect it to work. So now I’m confused. Both the crosshair and the primary laser should be able to reach 0 position, so when LightBurn applies the -30 at runtime the laser head will shift left to reach that position. The add-on component I’m referring to would be permanent attached and would allow activation of the switch to allow for the buffer. If I’m thinking of this correctly it should not require anything to be removed at any time. And soft limits should be able to stay on.
Sounds like the method you’ve come up with has the home position reporting as -30. To be clear, are you using the pointer offset setting in Device Settings?
Anyhow, sounds like you have a solution that’s working for you so that’s the important thing.
I’m not sure if I understood correctly what you mean. But if the homing is shifted by shifting the home switch, the head (containing crosshair and laser) will have a motion range from home (=0) to 820. With the crosshair being located at zero position in home position.
Now, placing an object in lightburn to the left border of the working area will cause the crosshair to move down to zero (i.e., down to the home switch) during framing. Everything fine up to here.
If I press start, the offset is applied to shift the main laser by 30mm to the left. If softlimits are active, I get an error message that says that gcode will not be executed due to a motion out of the motion range. If softlimits are not active, the laser head crashes into the home switch…
So in the end, what could be a simple solution for the problem: If negative pointer offset is defined in lightburn, shift the whole workspace by that amount. Such that framing will be executed away from the physical border instead of moving the laser into the border during execution.
I’d gladly make a drawing with more details if lightburn developers are interested. If I’m the only person on that planet with this problem just forget about it
If you have homing activate 30 mm right of where it’s stopping now, and call that 0,0 I believe everything will work as expected. You would need to disable the offset that you created.
Hmm, tried this and what happens is that during execution the head goes below zero and there is a softlimit error (see above). And if the hardstop with the homing switch is moved to the right, the mechanism will crash into this hardstop… In any case, if I find the time and can justify the effort, I will buy another controller and compile grbl myself. Then I have all the freedom that one can wish for to implement stuff like homing offset etc.
Nevertheless, thanks for all the help from you berainlb!
Yes I forced homing right of the normal homing position.
I can send you the requested output in a few days. I reiceved the drag chains last friday, so right now most of the device is disassembled After I’m finished with the cables I will provide the info.
