Feature Request: Numerical positioning

Nope! I thought I wanted numerical positioning before I got mine. As a matter of fact, I was shocked when I found out it didn’t have it. And then I got my Glowforge and very quickly realized I don’t need it for anything. Visually placing took a little getting used to since it really flies in the face of traditional design techniques. Then it clicks… “This isn’t a design tool!” Your design tools don’t change. They’re the same tools you’ve used for years. So you position there. Then all you do is plop it down on your material in your Glowforge and out comes amazingness. Don’t get me wrong, there are times I’d like to see 800% or 1000% zoom for the ultimate in precision. But even I know that visual is visual… perception is reality… If it looks perfect, it is.

So when a unit is functioning properly, even today with an incomplete feature set, etc… No complaints, and only rave reviews.


Yes lifting the lid a switch might stick and be dangerous. That is the opposite condition for a limit switch. If the button fails to come out then it would fail safe. And a washing machine will have a safety requirement that a single fault can’t be dangerous. Similarly the lid open switch on the GF will have multiple redundancy.


Again, if it works. Honestly as much as I like numerical positioning because it suits how my other machines work if the camera gets me ± 0.010 on its placement id be just fine not having numeric placement. But this was advertised as easy to use for non Technical people and a camera that is off up to 1/4" actually makes it harder to use than a traditional machine. I explained the steps to engrave on precut item/material and she looked at me and went “really? That’s stupid”


Absolutely. No disagreement. But only if that’s the case. And that should only be seen today at the extremes of the bed. But if you align in your design application like I was saying, it shouldn’t really matter. Because then you just align the center to the center. Everything else is relative and will place where you expect (rather than were it’s previewed).


For those of you saying they arent considering it, ill leave this here for you from the last conversation:

I still very very much would like to have numeric entry for positioning, scaling, and rotation. It would be of tremendous use to me.


If it weren’t for the accuracy issues, this thing would certainly be easier for most people to use than other machines.

Yeah, I hear ya. These are all “workarounds” to make up for the missing features. Some really clever people have done some pretty good work in this area. And, in many cases, they can be rather effective even if they are kludges.

What is (to me) simultaneously amusing and frustrating is when these kludges are toted as proof that Glowforge can do everything it was advertised to do, if you only do this (hyperbole alert) complicated 89 step process someone perfected as a temporary fix.


Wish I could give this more than one like lol. I agree with everything.

1 Like

I also like that some are arguing as if adding numeric positioning would mean taking visual positioning away. We can easily have both.


There have been so many times where I’ve attempted to make something, and it just wouldn’t quite fit, so without thinking I scaled it down in the GFUI a little. Boom, done, easy peasy. But wait…

What always happens after that? You realize you need to make another one the same exact size, and that you won’t be able to EVER get another one exactly the same size because you can’t exactly repeat that scaling/rotation action.

So what can you do at that point? Toss the first one, go back into illustrator to get it sized exactly how you need it, then make 2 exactly the same size.

Uuuuge pain. Uuuuuge.

Easy way to fix this? Numerical adjustments, and to add more repeatability, saving the state of every job that’s been sent to the server so you can pull that back up at any time.

They’re already storing all that information in the state/buffer of the app, so saving it to the database and letting you reload it later with exact placement/scaling/settings etc would be trivial.


Why not? Just measure the thing you made, go back to your design software and resize it there then when you create your SVG and drop it back into the GFUI it’s the right size. I must be missing something here.

1 Like

Measuring some shapes that aren’t rectangular can be really tricky to get exact. You also have to try to calculate kerf into the equation etc. That unfortunately always leave a difference in size regardless even if minuscule. In some cases that’s ok, a lot of times it’s not. You never want to give two people a present and have one of them looking inferior to the other.

It’s always much better IMO to cut everything from the same template if possible, or at least take out conversion error from real world -> digital if possible. Everything about it is painful.


Since this discussion has gotten really long already, I won’t say anything as to whether I think adding this feature is possible or not, difficult or easy. It’d be a nice feature to have, but I’m also not on the inside.

What I will say, regarding the 12x20" workaround, is that this should not only be easy to implement in whatever drawing program you’re using, it also is required when you’re using a Trotec. On the Speedy 400 we use at work, if you don’t have a 39x24" document size set in your drawing program, the JobControl printer driver that the Trotec uses will actually throw an error. There is an option box you can check inside the driver menu to crop the document back to your specific drawing’s size once it is passed into JobControl (a feature I usually use), but before you can do that you have to send your document to the driver on a 39x24" page or it’ll get cranky. I actually like this, because it stops me, just for a moment before I print, and makes me pay attention to both my positioning and the scaling of my drawing to make sure it’s both correct and maximizing my efficient use of my materials.

May not be everybody’s cup of tea, but if it frustrates you it might be helpful to see it in that light – as an opportunity to arrange your materials in the most efficient way possible, and to confirm you know exactly what size they’re going to be. Also, since most of these drawing programs will allow you to set up a preset default document size, it’s potentially a step you only really have to do once.


Interesting. I use Rhino, which doesn’t have a “document size” setting, and I never have to think about the exact work area of my Trotec. Perhaps I set it to the correct size at some point and it’s just been using that ever since.

I do use that setting you mentioned, the one where it crops down to the size of the thing being cut, though. So when it goes to JobControl the design is just a small rectangle that I can move around the laser cutter work-area at will. I can even type in nerd-numbers into little boxes if I want to move it precisely.

After a fair amount of trial and error, the only way I could get JobControl to throw an error was to try to send it something larger than what must be the “actual” work-area of the Speedy 100 - 609.98 x 304.69mm. This, of course, makes perfect sense.


We use CorelDraw to print to the driver, so that may be part of why the driver behaves differently – admittedly, when I used to use a Universal Laser Systems unit, we used Rhino with it and we didn’t have to set our sheet size (but I usually created a box the size of the bed in Rhino anyway, just to make sure my parts layout didn’t go over the edges). I do like to occasionally use that drag-to-position thing with Trotec, though I usually try to do my parts layout in CorelDraw as much as I can, just so I don’t mis-estimate the amount of room I have left on a certain piece of material to do a particular drawing. In my case though, most of the cutting I do is production runs, so I try to print whole sheets or close to whole sheets worth of parts, so I don’t have to store partial sheets at home in the closet (where they’ll poke me) and to minimize the amount of setup time I’m paying for on the laser (we rent access to it at the makerspace by the hour).


Couple things I feel compelled to say, I don’t know why.

  1. I think the camera positioning system is cool and I appreciate being able to place things visually vs. having to zero the machine. Most of the time it’s close enough for the things I make.
  2. That doesn’t mean I don’t want numeric entry. Moving, positioning, resizing, and rotating things in a predictable, repeatable way is super useful. I can’t think of a single other interface that allows you to place objects on a workspace that doesn’t have the option of typing the number in addition to using the mouse. Nobody’s asking for anything crazy, unnecessary, or impractical.
  3. Numeric entry does not require limit switch homing. These arguments tend to blend together. I wish the machine had limit switches to protect from smashing against the end stop, but it is what it is. I’ve let that argument go.
  4. This feature would be easy to implement. I dug around in the code yesterday. They’re using Paper.js and native browser SVG as one would assume. The hardest part of implementing this would be designing a good prompt to input the numbers.
  5. There is no number 5.
  6. It’s Glowforge’s hopper, they can do things when and if they want. I was frustrated at the attempt by some owners to stifle this conversation. It’s fairly common in the software industry to encourage duplicate feature requests in order to get a signal for how many people want something. I still read all of the posts here, and there’s so much noise that I just didn’t understand why this thread, of all things, got shouted down so early. I’m sorry I overreacted to the overreaction.

Is it ironic that not having limit switches because they can fail and damage the laser, causes the head to crash anyway?


How much of an issue would the encumbrance of patents and intellectual property be for some of these features. Is it like, "hey, there are patents here we might run up against and we just aren’t going to pay royalties but design a system as much as possible that is not encumbered by patents. I have no idea, but I expect due diligence has got to be a factor in this with a small company and the necessity of due diligence. Maybe it isn’t an issue at all

1 Like

Certainly a valid concern for any development project.

The bulk of these feature requests have either been something people have been able to do in other programs for a very long time (numerical positioning, for example), or unpatatently obvious.

Anybody see any outliers?

HA, I like your sense of humor.

This thread got muddled with the mention of limit switches.

I think numerical positioning in the setup stage within the GF app is a good idea though. It’s just one more little bit of flexibility and convenience particularly if you need to position copies ran in multiple jobs because the complex file causes issues with the GF app.

If the GF app would at least allow exporting an SVG file of a setup, then positions and scaling could be preserved on the user’s computer for future use.