sedm a comp that emualtes Sink EDM orbiting

[tjtr33]

sedm
a motion controller for sink EDM orbiting\Sink EDM is used to molds.
( like every plastic thing on your desk came out of a mold.)
EDM is good for small forms, thin supporting ribs, work of delicate fragile materials.
and more
Orbiting is a way to simplify manufacture of the tool used.
The size of the cavity can be enlarged by CNC, op[posed to
making different sized tools/
Look at a CT5 PLUG,
the cavity that plug came out of
was made with a tool of the same shape ,
but a smaller size.
Making tools of the same shape but different sizes
is very difficult.
Orbiting allows the same tool size
to be used like it was may different sizes.
A set of tools needed for 1 cavity is easier to produce.

Also included are file with EDM cutting parameters
for different materials and cross-sectional size.
Graphite to Steel with 4 grades of material.
Copper to Steel also.
Each table is a list of power settings
from Rough to Fine.

The user picks the table based on the size of the woek,
and the tool material and work material.
The table tells the user the UNS
Unddersize per side,.
The users the actual under-size and informs
the cop. IF under-size > Etable UNS, the extra will be
handled by the comp. The xavity wil have the print dimensions.
The user tells the comp which Etabale is used,
the start and finish indexes.
The user touches off with thhe tool, and
enters the Print Depth from that touch point.

During the cut the user can PEEK
The PEEK button turns off power
and retract the tool to the Start Point (SPO)
St that time the user can examine the tool and the work.
The user can then decide to
RESUME or QUIT.

In all cases, the tool ends where it started (SPO)
Thhe machine is ready for use.

Also, Peck EDM is included
with Cut Time ( mS resuktion) and
JumpDistance ( 1u resolution)

Metric is is used because fine finishing
orbits ne fine rez tha .0001")

Future
More Etables
more orbit pattrns
pretty gui
Cheat Sheet

[BsAtHome]

PR 3877 is failing and I cont understan why.
It builds dine an runs fine locally.

Building the binary is one thing.

The process that fails is packaging all files into a .deb file.

What has Ubuntu-arch=arm64 have to do with my fork?

This one seems to be the first to fail and then the others in the CI matrix will be aborted.

Is it broken for all linuxcnc PR's or just mine?

Just yours ;-)
The offending problem line is:
dh_missing: warning: usr/bin/sedm exists in debian/tmp but is not installed to anywhere

You have created a new binary but you failed to create a rule to have it installed.

You probably didn't add it to the debian/linuxcnc.install.in file.

---

Some other comments...
All those numeric .ENC files... Is there a reason for them having only a number as filename? And, is there a reason for all those upper-case and mixed case filenames, directories and extensions? It almost looks like it was copied from windows/DOS. I can understand calling, for example, the file for G-Code M165 "M165" (with a capital M). But for many files is does not make sense to me.

To be clear, I am not opposed to upper-case filenames, far from it, but they should be used sparsely and there should be a reason for doing so. If you have a reason, please enlighten me.

A few completely different observations. In file MCodes/M164 you have:

#!/bin/bash
   NOT USED thgis  not shoyld make using it fail

Wouldn't it make mores sense not to include that file then? A lot of the M-code files include things commented out. Why is a mystery. Probably some development history, but the background is illusive for others reading it and may be wrong. Some polishing up may be an idea

Generally, many files could improve with polishing and a clear focus and explanation what that file's function is (and running a spell checker on them is also advised).

You have included a lot og G-Code in .ngc files. Just as an example stored in configs/sim/axis/sedm/ngc/16x/*. Taking a diff between 16xZnegWiglNR25-24.ngc and 16xZnegWiglNR25-25.ngc only differs by two (2) lines but both files are over 200 lines long! This is extremely inefficient coding and nothing is reused. It looks a lot like copy-paste coding and that is not very efficient, not attractive and very much unmaintainable.

All these duplications should be relatively easy to merge by analyzing the content and create a few generic file-based O-routines that are called with the proper parameters. There is a lot of duplication that can be eliminated afaics. It will make things a lot clearer and easier to maintain.

Then you have a file called configs/sim/axis/sedm/ngc/a.ngc but the first line comment tells us something different: SEDM0Asmall.ngc. This again looks like copy-paste programming. After looking at several files, this problem seems to be recurring in multiple files. I think you need to review all the ngc files and improve the code.

I do think it is very interesting to add your code. However, IMO, it requires some TLC.

BTW, you don't need to close your PR and reopen a new one for every change. Just develop your branch and we can see the updates in this PR evolve and discuss it here. Using the mailing list for PR discussion is a bit problematic because the reference is here on github in the PR and we should comment of stuff here.

[andypugh]

Can you proofread the README and the comments/docs in the Python file? (or maybe get someone else to do it, which tends to pick out more typos)

What on earth is "src/Lick It Like You Mean It].mp4.ytdl" doing in there?