Category: Machine Shop

With a printed card in a fixture and aligned to the punch pattern, all that’s left is to Fire The Laser:

When the card drops free, then:

1. Remove card from fixture
2. Insert next card
3. Import next SVG file
4. Verify alignment
5. Fire The Laser

The gotcha lies in Step 3, which requires mousing & clicking through a tedious file selection dialog. For whatever reason, Windows / LightBurn does not remember your place in the file directory, so you must not only remember which card you just punched, but maneuver to the next card in the sequence.

It turns out there exists a lightly documented SendUDP.exe command-line program to send a file to the running LightBurn instance, which will (in the case of an SVG file) import it and center the layout at the middle of the workspace.

Which means a Windows batch file can feed SVG files, one at a time, in order, to LightBurn. Before importing the file, however, LightBurn verifies you want to blow away the previous layout:

Tapping D lets the import proceed.

The feed-lb.bat batch file:

@echo off
for %%f in (%1) do (
    echo Sending: %%f
    "c:\Program Files\LightBurn_Prerelease\sendudp" "%CD%\%%f"
    pause
)
echo Done!

Because the SVG files have convenient sequential names, this does what’s needed:

…snippage…>.\feed-lb.bat Cards\Tests\test-?-lb.svg
Sending: Cards\Tests\test-1-lb.svg
Press any key to continue . . .
Sending: Cards\Tests\test-2-lb.svg
Press any key to continue . . .

Set up the process:

1. Start LightBurn with the proper layer defaults
2. Start a Command Prompt
3. Get to the proper directory
4. Run feed-lb.bat aimed at the SVG files
5. Align the first card
6. Click in LightBurn window
7. Alt-S to start cutting

When the cutting is done, the loop continues:

1. Replace / align card
2. Click the Command Prompt window
3. Hit (almost) any key to send the next file
4. Click the LightBurn window
5. D to discard old layout / import next SVG
6. Alt-S to start cutting
7. Iterate

Assuming you don’t spend too much time aligning a card, punching it can take up to four minutes. This process is definitely not competitive with an experienced operator on a real IBM 029 keypunch machine, but it’s as good as it gets in the Basement Shop.

One wrinkle: The imported SVG file uses LightBurn layer colors, so the various shapes appear on those layers with their default speed / power cut settings. It’s your responsibility to make the cut setting defaults match the cardstock, because that’s the only way (short of per-card clicking) to make it happen.

Another wrinkle: the Command Prompt window opens at your Windows home directory, thus requiring a little setdir.bat file in there to get you where you want to go:

@echo off
z:
cd "\Project Files\Laser Cutter\Punched Cards\Programs\"
dir

Now it’s just a matter of punching and stacking cards:

It’ll take a while before I’m ready for the next step …

The printed card layout has targets in all four corners:

Which are at exactly the same positions as the targets in the punched card layout, because they come from the same source code:

The alignment problem has several parts:

• The 1/3 Letter sheets aren’t exactly 11/3 inch tall, because neither the paper cutter nor my cutting hand have any particular accuracy
• The printer’s feed rollers don’t maintain accurate angular or positional alignment between the sheet and the printed design
• A fractional-millimeter misalignment between the printed characters and the evaporated holes is obvious
• Performing an intricate alignment dance on each card guarantees at least an occasional misstep

I initially thought “Well, of course, I’ll just use LightBurn’s Print and Cut tool to match them up.” After some fumbling around, PnC is entirely too heavyweight for the problem at hand and a much simpler / faster / easier technique works better.

It turns out LightBurn imports SVG files centered on the layout grid representing the laser platform:

So putting the card fixture dead-center on the platform lines them up pretty closely:

After importing an SVG, use Move Laser to Selection to put it in the middle of the upper right target, then create a Saved Position imaginatively called UR:

Repeat for the lower left target to create the LL position.

Because the targets are on 200×80 mm centers and the middle of the platform is at (350,250), the target positions will be nice round numbers:

• UR = (250,210)
• LL = (450,290)

Yes, the coordinates run backwards, because that’s how Ruida controllers deal with a home position in the rear right corner of the platform.

You define those positions once, because all the cards are the same size and end up in the same location on the platform.

Although I expected to slide the cards under the fixture’s retaining lip from the front, it turns out an easier way is:

• Gently buckle the card center upward
• Align it against the rear edge
• Slide the left edge under its lip
• Lower the center while sliding the right edge under its lip
• Tuck the card under the rear lip
• Verify the front edge aligns with the marked lines, which means it’s properly in the fixture

The magnets hold the fixture against the honeycomb:

The fixture can still slide with firm finger pressure and the card can move a little bit within the fixture. Note that leaning on the honeycomb will press it (and the fixture) downward enough to put the dot at a slightly different position; if you align while leaning, recheck the dot’s position after you unlean.

Move the laser to the UR position and skooch the fixture to align the upper right target to the red dot:

The blue lines are nominally 0.2 mm wide and actually about 0.3 mm wide, so the red dot is 0.3 mm diameter. If your red dot is larger, better focus and a polarizing filter will help.

I periodically fire a test pulse to verify the red dot matches the actual laser beam position:

That slight mismatch adds to the overall positioning error.

Repeat for the LL target, recheck UR to make sure it didn’t move, iterate as needed.

The printed card is now aligned to the hole pattern.

Although this sounds like a lot, it goes surprisingly quickly because all the cards are Pretty Close™ to identical and the adjustments are very small. Although it’s possible to park the laser head at the UR position, I prefer to have it out of the way while unloading & loading the cards, then move it directly to UR to check the new card.

Fire The Laser:

I love it when a plan comes together:

A dash of automation helps when doing more than one card, which, believe it or not, involves a Windows batch file …

The Punched Card.py program can generate a set of test cards to simplify tweaking the rest of the process:

The Bash script calls the Python program twice to generate the two SVG files for printing and punching each card, which seemed simple enough.

Unfortunately, sending the SVG file directly to the printer demonstrated my lack of understanding of that whole process, so the script now:

• Converts the SVG to a PNG file
• Composites the logo image into a first blank-card sized PNG image
• Composites the logo underneath the card PNG to a second PNG
• Composites that PNG onto a Letter page in the proper position to hit a 1/3 Letter blank card to a third PNG

Which goes a little something like this:

#/usr/bin/bash
outdir="Cards/Tests/"
prefix="test"
for i in $(seq 5)
do
    printf "Test pattern %s: print" ${i}
    python Punched\ Card.py --layout print --test $i --seq 0 > ${outdir}test-${i}-pr.svg
    printf ", punch"
    python Punched\ Card.py --lbsvg --layout laser --test $i --seq 0 > ${outdir}test-${i}-lb.svg

    tf1=$(mktemp --suffix=.png ${prefix}-XXXX)
    printf ", Inkscape → PNG"
    inkscape --actions="select-all; page-fit-to-selection; export-dpi:300" --export-filename=$tf1 ${outdir}${prefix}-${i}-pr.svg

    printf ", Imagemagick → logo"
    tf2=$(mktemp --suffix=.png ${prefix}-XXXX)
    magick composite ${outdir}"Card logo.png" -gravity center -geometry "x880+0+20" -size 2421x1004 canvas:white $tf2

    printf ", Imagemagick → page"
    tf3=$(mktemp --suffix=.png ${prefix}-XXXX)
    magick composite $tf1 $tf2 $tf3
    magick composite -density 300 -gravity east -geometry "97.0%x97.9%+100-50" $tf3 -size 3300x2550 canvas:white ${outdir}${prefix}-${i}-lt.png

    #printf ", PNG → printer"
    #lp -d EPSON_ET-3830_Series -o media=TLetter ${outdir}${prefix}-${i}-lt.png

    rm $tf1 $tf2 $tf3
    printf ", done\n"
done

Although the script could print the final PNG for each card as it’s generated, I prefer to print them after eyeballing the results to fix the inevitable bloopers:

lp -d EPSON_ET-3830_Series -o media=TLetter Cards/Tests/test-?-lt.png

Using ImageMagick to slam PNG images around was significantly less complex and more direct than trying to contort the SVG file to produce the same result. In particular:

• Uniformly scaling the logo image to fit the card height actually worked, as opposed to specifying the logo file as an image in SVG file.
• Scaling the card PNG while compositing it onto the final page PNG worked much consistently, which counts for a lot.
• Hitting the middle of a 1/3 Letter blank fed from the printer’s paper tray required tedious trial-and-error.

The Cards/Tests/ output directory lives in the Programs directory with the Bash and Python programs, which made sense at the time.

The Card logo.png file also lives in Cards/Tests/ so I can have a different logo for each set of cards. A symlink to the appropriate logo file in Logos simplifies changing the artwork.

None of the constants will match your setup, so have fun.

With a fixture aligning a printed card in the laser for cutting and trays for incoming and outgoing cards, it’s time to generate SVGs for printing and cutting. I use the svg.py library to translate card geometry into SVG elements.

For example, this draws a rectangle around the card perimeter with a color that will automagically put it on a LightBurn tool layer used for alignment:

if args.layout == "laser":
    ToolEls.append(
        svg.Rect(
            x=0,
            y=0,
            width=svg.mm(CardSize[X]),
            height=svg.mm(CardSize[Y]),
            stroke=Tooling,
            stroke_width=svg.mm(DefStroke),
            fill="none",
        )
    )

Because I know the exact size of the card layout, all the coordinates / sizes / widths will be in hard millimeters. The constant INCH converts from the hard inch sizes of the OG IBM card layout.

The args.layout variable corresponds to a command-line switch selecting output for either “print” or “laser”, because each requires different SVG elements and attributes. In this case, the card outline appears only in the laser file, because it should not be printed on the card face.

Eventually, the SVG for the laser will look like this, with the blue rectangle boxing its red perimeter:

The corresponding SVG to be printed, without the rectangle:

Both SVGs have four alignment targets at exactly the same coordinates, although in different colors for their different purposes. The laser targets appear on a tool layer where they can be selected to position the laser head over the corresponding printed targets on the card in the fixture:

Subsequent steps in the process composite the fancy logo under the SVG layout and scale the result before printing the card.

This chunk of code produces those targets:

for c in ((1,1),(-1,1),(-1,-1),(1,-1)):
    ctr = (CardSize[X]/2 + c[X]*TargetOC[X]/2,CardSize[Y]/2 + c[Y]*TargetOC[Y]/2)
    MarkEls.append(
        svg.Circle(
            cx=svg.mm(ctr[X]),
            cy=svg.mm(ctr[Y]),
            r=svg.mm(TargetOD/2),
            stroke=Tooling if args.layout == "laser" else CardMark,
            stroke_width=svg.mm(DefStroke),
            fill="none",
        )
    )
    MarkEls.append(
        svg.Path(
            d=[
                svg.M(ctr[X] + TargetOD/2,ctr[Y] - TargetOD/2),
                svg.l(-TargetOD,TargetOD),
                svg.m(0,-TargetOD),
                svg.l(TargetOD,TargetOD),
            ],
            transform="scale(" + repr(1.0 if args.lbsvg else SVGSCALE) + ")",
            stroke=Tooling if args.layout == "laser" else CardMark,
            stroke_width=svg.mm(DefStroke if args.lbsvg else DefStroke/SVGSCALE),
            fill="none",
        )
    )

The stroke attribute sets the color of the result, with the Python ternary operator picking the appropriate RGB value based on args.layout.

The args.lbsvg variable comes into play when the LightBurn interpretation of an SVG attribute or element differs from the Inkscape interpretation. I have absolutely no idea what’s going on in those situations, other than that the two programs sometimes regard coordinates / distances differently.

For example, LightBurn regards the “user units” in a Path as millimeters and Inkscape regards them as “SVG pixels” requiring a scale factor I defined as SVGSCALE = 96.0/25.4 to get the right size. If there’s a less awful way to match them, I’m all eyes.

Although setting args.layout to “laser” and args.lbsvg to True generally makes sense, I may want to print the “laser” layout for cross-checking. Hilarity generally ensues until I remember args.lbsvg. It’s worth noting the code has zero error checking, so hilarity generally continues until I fix whatever got missed.

With that in mind, this Path traces the card perimeter:

if args.layout == "laser":
    CardEls.append(
        svg.Path(
            d=[
                svg.M(0.25*INCH,0),
                svg.h(CardSize[X] - 2*0.25*INCH),
                svg.a(0.250*INCH,0.25*INCH,0,0,1,0.25*INCH,0.25*INCH),
                svg.v(CardSize[Y] - 2*0.25*INCH),
                svg.a(0.25*INCH,0.25*INCH,0,0,1,-0.25*INCH,0.25*INCH),
                svg.H(0.25*INCH),
                svg.a(0.25*INCH,0.25*INCH,0,0,1,-0.25*INCH,-0.25*INCH),
                svg.V(0.25*INCH/math.tan(math.radians(30))),
                svg.Z(),
            ],
            transform="scale(" + repr(1.0 if args.lbsvg else SVGSCALE) + ")",
            stroke=CardCut if args.layout == "laser" else Tooling,
            stroke_width=svg.mm(DefStroke if args.lbsvg else DefStroke/SVGSCALE),
            fill="none",
        ),
    )

Note that the stroke_width attribute also requires scaling, lest it take on a broad-brush aspect.

More on generating the various characters and punching the holes to come …

The Python source code as a GitHub Gist:

I derive a modest satisfaction from knowing Microsoft (which owns GitHub) uses my source code to train their Copilot LLM. Future generations of vibe coders will look at their programs and wonder WTF just happened.