Camera aid background position and work origin

Hi,

I’m trying to work with the camera aid for laser engraving. However, the bottom left of the background always lines up with the work origin (0,0,0). Snapmaker device itself always defaults the work origin to the center of the plate.

How can I line those two up? Am I missing something?

Thanks!

It works like that. The background picture should be on the second quadrant. You don’t have to line up those two dots. You can also check out this video tutorial on the Snapmaker YouTube Channel.

Thanks for answering, however, I don’t think my question was clear.

The tutorial shows the capture in the second quadrant. After which there is no speak of setting the work origin.

My experience with this:

  • Capture camera background

  • This is placed in the second quadrant, with bottom left of image on position 0, 0

  • I generate G-Code and send it over to SM2

  • Now I HAVE to set the work origin on my Snapmaker to the most front left point of the platform, by default it’s the middle of the platform.

Apart from the fact that it is tedious to do this every time, wouldn’t it make more sense to place the background image of the camera capture so that it actually is what you see is what you get?

Not sure if I explained myself clearly enough. I can make videos and screencasts if needed?

Cheers,

Kees.

6 Likes

Never could get this to work. Same kind of problem as OP has. So many things in Luban have to be entered and re-entered multiple times. It’s maddening and a waste of time. We need some preferences, or some way of having things stick, reverting to the most recently used settings, etc. All in all, I feel it’s unreliable, with countless hangs, exceptions and inconsistencies. Also, some key steps – which probably seem so obvious to, and already internalized by, engineers – are missing, again and again. The OP’s problem is typical. So far, I’ve been disappointed by this purchase and it’s cast me a lot of stress. Can’t understand how you guys can’t stabilize this software AND get the help of someone who really knows how to write instruction manuals in English, in the proper flow and sense.
The Capture Camera situation is ludicrous, even if I could get it to work, it’s not possible to zoom in or see any details. Etc., etc.

2 Likes

I too find this problem annoying, any answers?

When using camera capture to place the image in the workspace, the work origin is in the top right quadrant, that’s fine.

After generating gcode and loading it onto the workspace I then set the machine to workspace origin of 0,0.

If the job is controlled by Luban over Wi-Fi everything works as expected but if I send the job to the machines local storage and then run it from the touchscreen, the work origin is reset to the centre of the workspace, which means that unless I jog the machine to 0,0 and set workspace origin, the image is misplaced. This is tedious.

I think the fix could be in firmware, either don’t reset work origin automatically or give us a button on the touchscreen to move the macine coords to 0,0 at the front left.

Thanks.

The solution is as simple as changing the capture code to put the image in the centre of the bed. Either that, or ALL the code modules need to change to put the origin at the front left corner. I’m seeing a distinct lack of configuration control here. Some code uses the centre of the bed, some uses the bottom left corner.

2 Likes

I have the same problem. Is there now any solution for this problem?

Same issue - I follow the video on camera capture, but then i seem to end up resetting the work origin to 0,0 every time in Luban - surely we can have a button to set the origin to 0,0 rather than having to jog the machine? If i don’t do this then it seems to try to laser the image somewhere off the top right of the plate (as when the machine calibrates you end up with the work origin in the middle somewhere).

I am facing the same problem, let me know if you find any solution.

Snapmaker staff.

What is happening here, are som of this problems going to be fixed or what are this forum for ?

Someone on the staff team has replied to this problem some time ago, they don’t seem to see it as an issue so I doubt it will be fixed - unless we do it ourselves.

Yes, this is extremely annoying and causes faulty prints…could actually damage the machine. I don’t think the work origin and running the boundry has ever been even close to right.
My laser autofocus won’t work, tried several times and the alignment on camera capture is pretty horrific with black gaps between the vertical 3rds.

I am able to move the background capture on edit to line up with the axis using the mid-point resizing dots as a guide. However, after placing objects and processing, the s/w throws the background image back to the (0,0) work start position and it can’t be moved while the objects are centered on (0,0), not up in the 2nd quad. Couldn’t this actually damage the bed?

1 Like

Same problem here

if i understand correctly, surely it is just making sure that the zero point of the photo (background capture) matches the zero point of the machine. Since the picture is taken by the machine, this can’t be that difficult, can it? Or am I wrong?

Come on snapmaker, next version of Luban should solve this. This is for me already a top machine, make it a wonderbox :-).

I have reviewed the thread and sorry for the understanding.

In the video tutorial, the narrator recommends users start the Laser engraving instead of sending it to the touchscreen. Snapmaker Luban has set the work origin and you start the work via the software. If you want to use the touchscreen, you need to find the file there and set the work origin by yourself via manual focus.

The touchscreen will not set the work origin when you use the camera capture feature.

You can try to run the “start” button as instructed in the following video.


After watching the demo, I am still convinced that the software is F…ked up. I should be able to generate gcode and run that gcode without having to mess with the work origin. The way it is is that you can print from the interface, but it sends a different gcode than the one that it generates. Rediculous!