If it were still Halloween, I’d say Tommyknockers. But since it’s past:
There doesn’t seem to be a precide sound analysis upon startup, connecting each sound to the process of power on, systems engaging and calibration. There are many unfamiliar sounds and no common vocabulary to describe them, and of course no official list of what is happening system level that cause the lights to blink and the motors to move.
What actions that have been identified through the time that I can recall, and not necessarily this order.
Stepper motors powering up. That is potential sound.
Head lens focusing.
Coolant flow starting
Some fans whirring
Movement along gantries
Any corrections, additions? corresponding soundtrack closed captioned for the hearing impaired and Glowforge deprived?
Some of this routine is affected by the existence of a network connection to the mothership, others happen regardless of status of connection.
That reminds me, @teditz if you are still interested in going to the Rochester Maker Faire let me know. I have some extra table space. Two forges are better than one.
All seems well. The founders’ ruler printed without a hitch, and then I moved on to etching some fake sea glass that I’d made a couple of years ago when thinking about Glowforge projects, and forgotten about. The only problem I’ve run into is a consistent “unexpected error” message when trying to upload .svg files from Inkscape. I’m hoping that’s a server side problem, as the files are dead simple text files saved as “plain svg” from Inkscape. Overall, I am really happy. And I’d definitely be in on an upstate NY user’s group.
Do you understand that text in an SVG file can not be processed by the GF S/W? Text must be converted to paths in Inkscape first. Select the text and use Object to Path under Path in Inkscape. That should convert the text object to a series of paths that will be understood.
Please note that the Text can no longer be edited as text after you do this.
Speaking of understood… if I understood your post incorrectly then sorry and please ignore.
You understood perfectly! I missed that part. And it would explain why a graphic that I’d saved as .svg earlier in the evening worked, when the text didn’t. Thank you!
Mine did the same. Sounded to me like the head banging against the right-hand side, much the same as the common bug where it bangs against the left side during calibration.
Yeah, it’s a little complicated but if after you have converted the text to paths you can use the “edit paths” tool highlighted here on the left side to make sure the text has been converted to a series of paths.
None of us can quite understand why a basic user manual or decent error messages were not a priority. But it is what it is. No doubt those things will be provided in the future, but the fact that it wasn’t part of the pre-production plan is surprising. Only thing I can think of is that other unforseen problems were so huge that the responsible developers were pulled off the effort.
Normally the S/W gives and error message that the design contains text and the the GF S/W can’t process text. But I have also seen times when that error does not present itself.
I saw that more specific error message when I just tried uploading a text file converted to paths. Part of the text was converted, but part wasn’t, and the software displayed the error you just mentioned. But when none of the text had been converted, it just gave me the “unexpected error…if this continues, contact support” error. They’ll get there, I’m sure. I’m still feeling pretty confident in this company, and their team. But thanks so much for your help in the meantime!
I think it’s because it’s the last thing programmers want to work on so in a small shop it waits until the end. Since it’s still beta it’s not done and until it’s almost production they’re not likely to focus on it.
Was there anything else except text in the file? If there’s just unconverted text it behaves like an empty file. If there’s something else it can handle and text it’ll give you the correct error message.
I can understand that, to a degree, with the User Manual… but surely they are keeping an in-house list of how-to’s that can be easily sanitised into a quick User Manual. Even if they got one of the Support staff to do it this would save Support a lot of time in the long run as they would not have to cover basic things that a manual would address.
I cannot understand it with the Error Messages. If the backroom boffins are getting the same Error Messages that Users are seeing then that might be a reason for many issues right there!
No, they would have to be deliberately hiding them from the User. And that, i find baffling.
Our .Net application throws really verbose error messages but we we only display the abbreviated form to production users as the whole stack is included in the verbose version. Don’t want civilians seeing that.
The abbreviated form is essentially a “something went wrong, it may be possible to recover by using the browser’s back button” message - not dissimilar to the generic message we see in the GFUI.
The comment below is in reaction to your line ‘not dissimilar to the generic message we see in the GFUI’.
Except there is a difference between a bug in the backend that the user can do nothing about, and an issue the end-user can do something about. Throwing up a generic error which does not help the user in the least, when a specific error would allow the user to fix their behavior and move forward, is frustration inducing. An example is embedding fonts in the SVG instead of reducing them to paths. This is a user error and the software tells the user what the error is and how to avoid it.
The problem, as I see it, is that there are long-standing bugs in the code that eventually will get fixed. An example is the rendering pipeline. The developers don’t think they should raise the specific bug to the user because when the code is done any bugs in the rendering code wouldn’t be actionable by end user behavior other than submitting the image to GF to see what is wrong with their code. But at this point there is something the end user can do - there are published workarounds. Let’s say there are currently 5 places where the rendering pipeline falls down if the image is too complex. They shouldn’t expose each specific error code, but they could wrap all of them in one error code that would tell the user to refer to the workarounds. Yes this is extra work that eventually gets thrown out, but it would reduce user frustration for the 6 more months it takes to fix all the issues the rendering pipeline. Another example would be SVGs that are sized too large and don’t fit in the laserable area.
Obviously the biggest user frustration is not having a machine yet. But I hope they are constantly monitoring the integral of user frustration weighed by percentage of users having that problem over all frustration points in order to minimize the function by assigning personnel appropriately. (And I say that as a person who does not have a machine yet.)
I think shipping without the software being complete was an error on their part. Everyone seems to be missing the BETA portion of the software. We are all beta testers. Some of us were beta testers of the hardware. All of us are beta testers of the software.
It’s obvious now that most people don’t have the temperament to be beta users.
I don’t think shipping without the software being done was an error on their part. It does work extremely well for most things. And there are workarounds for the great majority of the rest.
It may be that most people don’t have the proper temperament to be beta testers. It’s also the case that GF didn’t give the end users the proper tools to be beta testers. For example, it’s a shanda (dan will know what that means) at this point that jules had to produce the recent documentation that GF should have provided to their end users.
And they could have made it easier on the beta testers and support staff by having better error codes. I’m used to being on the programmer side of the beta test, as well as beta-testing programs. We both know you need to minimize the incoming noise to make efficient progress against bugs and unfinished code, and to maximize the efficiency of the support staff. Better error codes help do that.
Not sure what that means, but seriously, it’s not that big a deal.
A tech writer would actually not be able to do it from the same viewpoint that a non-technical beginner has…and I was a beginner…a total newbie. The things that confused the heck out of me are not going to be the same things that confuse a laser builder talking to a tech writer. And the tech writer would take longer to get up to speed if they hired in someone from outside anyway.
This is just an interim thing for us to use until they can put the real documentation together later. And a lot of this is already documented in the User Manual, the Support section of the App, and the tutorials in the Matrix …it just requires a bit more reading to find it all.
