Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

case-insensitive lasertags + more passes #56

Open
wants to merge 2 commits into
base: beta
Choose a base branch
from

Conversation

martinxyz
Copy link
Contributor

Allow uppercase lasertags. It's easy to workaround this, but only once you figure out what the problem is...

And increased the max. number of passes (useful for power calibration files, and I see no reason for the low limit).

The js code looks up color hex codes in a case-sensitive dict.
@SteveBaker
Copy link

I actually have a different take on this.

I don't like that the laser power level and the "pass" are so tightly
linked.

I don't think it takes much time for the system to switch power levels,
and it takes a very long time to do large repositions around the table.

So why have to etch absolutely everything before you cut anything?

Certainly there are cases where cut order is important - but the cost
of forcing everyone to do that is to vastly increase the amount of
unnecessary X/Y motion by passing over the entire bed twice when cut/etch
order DOESN'T matter (which is nearly always for me).

In my case, where I make a lot of small objects in one 3 hour long
cut - it would be beneficial if each object were first etched, then cut
before going on to the next object.

This would be AMAZINGLY useful both in time savings and practicality.

So IMHO, the better approach would be to continue to tie power levels
to color - but to use group tags (or layers) in the SVG to handle
passes. Tying the group tags to pass numbers would be natural and easy,
and it's simple to select-by-color and group all of those objects onto a
separate layer when you want behavior like we have now.

Obviously, to take advantage of such a change would require changes
to people's art - but we could always have a backwards-compatibility
mode where it works the way it does now.

The "lasertags" system is, IMHO, a poor choice. It assumes that the
power level and speed is known at the time that the object is designed.

That's OK if you're going to design it, cut it and then toss it aside -
but if you're going to use the design over months to years (and your
laser tube is aging and losing power) - or if (like me) you have more
than one laser cutter - or if (like me) you cut the same design out of
different materials and need different power settings for each...then
it's 100% useless.

What I'd prefer is some kind of persistent per-lasersaur configuration
that maps color to power setting for each material.

I could have entries for 3mm, 6mm and 12mm plywood, 3mm and 6mm acrylic,
paper, cardboard, cloth...and within each one have settings for red, green
blue, black and so forth.

Each lasersaur would have a separate configuration file - and the same
art would produce the same results on both machines - even though one
can only manage to cut at 1400mm/min and the other is zipping along at
1800.

If I used the lasertags (which I don't) - I'd have to go through over 1000
design files changing the tags whenever I decide that my laser tube is
getting a bit old!

So, sadly, lasertags are 100% useless for everything I do...and I don't
recommend that people use them.

-- Steve.

Martin Renold wrote:

Allow uppercase lasertags. It's easy to workaround this, but only once you
figure out what the problem is...

And increased the max. number of passes (useful for power calibration
files, and I see no reason for the low limit).
You can view, comment on, or merge this pull request online at:

#56

-- Commit Summary --

  • increase max number of passes
  • LaserTags: accept uppercase hex (#FF00FF)

-- File Changes --

M backend/filereaders/svg_tag_reader.py (4)
M frontend/js/app_laserjobs.js (2)

-- Patch Links --

https://github.com/stefanix/LasaurApp/pull/56.patch
https://github.com/stefanix/LasaurApp/pull/56.diff


Reply to this email directly or view it on GitHub:
#56

-- Steve

@martinxyz
Copy link
Contributor Author

I hardly have any laser experience yet (fresh build in Winterthur, Switzerland). But assuming that parts don't move after they are cut free but before they are etched, I agree that order should not be hand-crafted but optimized, either to the goal of finishing parts as soon as possible, or to the goal of minimizing head movements.

Concerning this pull request, the changes are absolutely trivial and there is currently no other way to create a laser power test sheet (that I know of). While we may want to discourage people from (ab)using Lasertags, I see no reason to keep the artificial limitation while there is no alternative.

For this specific use case (power test sheet) you probably really want to specify a fixed order from low power to high power.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants