PENTRONIK.ART

Genuary 14, Aesemic

2023-01-14T00:00:00-08:00

Aesemic writing is a concept I can get behind.

Pen plotter output of aesemic writing.

The above is my final plotter output. Below is the p5js sketch I made first. These are also on mastodon.

P5JS sketch output of aesemic writing. To my eye it looks more writing-like.

More on all that later, first I want to detour to my previous attempts with aesemic writing. I referenced my past attempts at aesemic in this toot last week. Lets take a closer look.

In my last go at this, I tried making cursive words with Bezier curves connected together. The control points are generated by selecting random points on a circle (from N possible positions) that moves along the word.

Some asemic writing I worked on a couple of years ago when I implemented Bezier curves. You can probably find it on the twit site if you want to do that.

Since it only draws from a pre-determined subset of the random points on the cirlce, the words are formed from a set of letters. An alphabet. You can see some repeated patterns in the page of writing above. Additionally, I added some sloppiness terms, so the letters aren’t identical each time they’re drawn. It’s supposed to represent handwriting instead of printed text.

I like the loopyness and fluidity of the forms, but they don’t really look like writing to me. I thought maybe I had just chosen a badly formed alphabet? So I made some more. Each row is an alphabet.

These are each alphabets, all generated from the same rules, just different selections.

I made lots of alphabets.

I made pages and pages of these. So many I had to come up with an indexing system so I could reference the ones that I wanted.

It’s overwhelming. It’s not sustainable. Yet I persistend and picked a few to plot out on small trading cards to get a feel for them.

Just one of the selected alphabets. This one is the 11th row of page seed 238.

I like these. A lot of them look like the letter “y”. They sort of go together, same style. But maybe that’s a problem. Not enough to distinguish the different letters. Also, no sample words to see how they look.

I sort of lost steam on it at this point when I was last working on it.

Returning to the ones I made today, I had a different goal, and a different inspiration. The idea today came from one of the figures in the second edition of the Processing book (p451, if you want to see). All straight lines.

In today’s asemic writing, it’s based on a 3x3 grid, and lines are drawn between the points, plus a bit of noise to loosen it up. There are two types, one doesn’t allow the x or y to be the same- it’s all diagonal. The other type of letter allows x or y to be the same but not both- vertical and horizontal lines are now allowed but no dots. This is what’s in the second figure above, that I made with p5js. Some rows are one letter type, and others are the other. Each row has it’s own amount of noise. I played with increasing the noise as the page does down, schotter style, but didn’t like it all that much.

I’m pretty happy with that p5js output, for half an hour’s effort. But I’m more of a plotter than a processer, so I translated it into my own python code to generate something similar. Nominally it should be identical.

Easier said than done.

I think I’ll have to do a lot more fiddling to figure out what is different here, and fiddling isn’t all that deterministic of a process. So instead, I’m going to leave here and stew on what lessons, exactly, I should be learning from this about my own process, and what I think makes good aesemic output.

Some things for me to think about:

How can I get the iteration time down even more in my python code and rendering engine. Further friction reduction is needed.
What code design decisions can I make to shrink the gap between what I sketch out in p5js vs what I re-implement in my engine? Re-implement is already kind of bleck.
Try fewer lines on the current output.
Pay closer attention to the feel of the resulting page, there’s not much different between the outputs but one sure looks more like writing than the other. Follow that.
Maybe a mix of the diagonal and square lettes in the same word would help?

‘Till next time.

And, as usual, see genuary.art for the rest of the genuary prompts.

An update on postcards

2023-01-07T00:00:00-08:00

I finally updated my postcards page with the most recent postcards. And, I realized I goofed :sweat_smile: there are two series008 postcards! Oops.

The other thing I realized is that I only did one series of postcards last year. It must have been really busy with other concerns.

…

I actually new that.

Get the details at Series008 and Series008b.

Genuary 4, Intersections

2023-01-04T00:00:00-08:00

Intersections as a prompt is an idea I can get behind.

I thought I would try doing a two color version to really push on the sky/mountains feel I get. I turns out that aligning fountain pens in the plotter isn’t so easy, so there are some imperfetions. But I actually don’t mind it. I don’t think I would ship one like this out sight unseen.

Also on mastodon.

See genuary.art for the rest of the prompts. I’ve been avoiding thinking about future ones, unless I can’t help it (I’m looking at your Moiré).

Bonus art

This was my third idea, but it’s pretty plain, so I didn’t post it on Mastodon. LMK if you think I should have.

Genuary 3, glitch

2023-01-03T00:00:00-08:00

I’m not particularly inspired by glitch, or when I am it has to be a real surprise. And natural. So I thought of a few ideas, and decided that they weren’t really “glitch” even if I did like them. But I didn’t code them; it was a kind of busy day anyway.

Also on mastodon.

Genuary 2, 10 minutes

2023-01-02T00:00:00-08:00

Also on Mastodon.

I have so many problems with this prompt. It seems adversarially written to challenge my own modes. I will not lie and say anything like “and that’s why I like it” because I don’t like it. I do find it useful to be challenged though. So, in that spirit I’m going to ignore all those pedantic and other voices and plunge ahead. Here goes a retracing of my thinking this morning, because I think it will be useful to future me and others who are not me now.

My first thought was to rebel against the completely unbounded brief here. And the second was that it has to be something simple. Cubes are simple. Maybe this is a chance to go after Mohr’s cubic limits.

After a few minutes of jotting on a 3x5 card, I realized that cubes were too ambitious for 10 minutes.

Let me explicitly spell out the vision for future me, and others.

Start with an isometric wireframe cube and only draw some of the lines. Arrange a grid of these with fewer and fewer of the lines drawn as the particular cube gets radially further from the center.

Sounds simple, right?

Well, I don’t have enough p5js fluency to do that one in 10 minutes. I’m not sure I’m fluent in anything enough to do that in 10 minutes. I discovered this by spending 20 minutes trying to draw just one cube the way I wanted in there. What even is the coordinate system orientation in 3d P5? Where is it documented? I give up. I descope.

What about squares in concentric circles? And only draw the square some of the time. And draw the circle arc segment when not drawing the square.

You can see the general idea in the second picture above. I spent a few minutes mentally checking that I thought I knew what all I wanted to do, knew the commands, etc. I set myself a stop watch and figured I’d just keep an eye on it. This is playing with the spirit of ‘made in 10 minutes’ which I interpret to mean about 10 minutes or a short amount of time, lets not get carried away here.

I don’t think I’ll bore you with all the things that I think are wrong with this iteration, but it’s where I got to at about 10 minutes. At least it’s complete. The signiture was extra, after the time ran out.

Quite disatisfied with it, I decided to go another few minutes and at least finish a bit more. I added some randomness and fixed a flaw that I saw, and styled more to my taste instead of the p5 defaults. Et voila.

This was unexpectedly better than I anticipated. I like that the concentric pattern is visible but also disrupted by the randomness. There are pockets of phantom concentric groups that go in and out of my vision. Surprisingly this is easier to see when the extra confusion of truncated squares at the edges are included.

I’ll come back to cubic limits and circles and squares another time. That’s all for today.

Genuary 1, loops

2023-01-01T00:00:00-08:00

Also at mstdn.social.

I use genuary as an opportunity to explore something quickly. This is the opposite of my regular mode of operating. The way I normally work is to spend time as my schedule allows it, over days and weeks, with one idea. Mining it, pursuing my interest, and what the idea affords. Letting things percolate.

Genuary doesn’t grant that kind of time, which is the point. Or the point that I take from it. Last year, I really worked some ideas and demanded of myself that I plot them. It was too ambitious. I didn’t have that kind of time. This year, I have even less of that kind of time.

When you have less time to do, do less. But still do.

So the idea here was to take something that I can apply loops to, and do what I find useful to it. I’ve been thinking about an idea for a while now and looking for an excuse to test it. Bite size genuary projects are just the thing for something like this.

I want closed loops that are kinda periodic-ish but also random.

:bulb: What if I make a closed path (orbit) and compute the Perlin noise (or open simplex), and use that to mutate the loop?

There are some other details, but the image above is that. It’s not exactly what I was hoping for. It’s cool enough in it’s own right, and I will probably develop it some more at a later date. And plot it.

But now I know, and I can see what other options I have for noisy closed loops. This one may be useful for something.

I’ve probably overcomplicated it, but there’s no time to go back to it. Must keep moving.

[I’ve edited this a few times to clarify what I mean.]

Plan for the Easy Gaps Hypotheses

2020-12-24T00:00:00-08:00

In the gaps hypotheses post, I listed out a bunch of ideas I have for what is causing the dot-or-gap blemishes when drawing closed loops. Some of the proposals are actually quite easy to test. So, for purposes of the scientific method, I will now write out my plan for testing several of those, and hazard an interpretation of what different results might mean.

Method

The test plot shall be a 8x11” page in vertical orientation (long edge is in the Y-direction). On the page shall be drawn an array of concentric circles up to 1-inch in diameter. These concentric circles shall be arranged in rows and columns. Each page that is rendered shall be annotated either automatically or by hand with a note indicating what is to be tested. The circles will be drawn such that the pen starts and finishes always at the same angle for all circles. This angle will be indicated with a line inside the smallest circle.

// TODO(pentronik): Add an illustration.

Tests

This plan is for tackling the easiest hypotheses first. These are mostly the materials related questions.

Preparations

Before doing anything, just try to reproduce the issue with the same pen and figure that was used previously. Check out that version of the code and plot it.

If the issue reproduces, then the problem is still present. Sync the repo back to current and see if the plot still works and can still reproduce the issue. In either case, proceed.

Make the figure described above in Method, and plot it with the same pen used in step 0. Check that is reproduces gaps.

If the issue is present, then the test figure is fit for this purpose. If not, do not proceed and work on the test figure until it does reproduce the issue.

Hypotheses

The problem is the pen is old and weak.

Proposal: Test with a fresh pen. Test with a different pen. I have some Isograph technical pens now, so test with those.

If the problem reproduces with a fresh pen that has good flow, it is not the pen that is at issue here.

The problem is that I am not using the same pen every time and this is confusing.

Proposal: draw the same sheet several times with the same pen without changing anything. Do the gaps reproduce identically?

If the problem persists through all the sheets, then we know that the plotter is behaving in a very reproducible way, and that the pen has not shifted.

The problem is that I am not putting the pen in the holder consistently.

Proposal: If the previous plot reproduced the issue, try plotting a sheet, and then rotating the pen 45º and plotting again.

If the issue goes away for some angle, then it is a pen issue. It may also be pen specific; I’ll have to find the angle for each pen that avoids this issue.

Conclusion

In this post I have laid out the beginnings of checking off some of these hypothesized reasons for the dots or gaps in the plots, and listed experiments for testing them. Stay tuned for test results.

Gaps Hypotheses

2020-12-23T00:00:00-08:00

Continuing the gaps analysis, in this one I will list all the ideas that I have thought of, quick reactions, and alternatives. It will likely turn into a sort of table of contents. Right, so the hypotheses!

First is the list after organizing it into groups of related issues. Below that is the original raw list.

Organized list

Issues related to the motion of the pen that is either due to my own programming or due to lack of understanding of motion library. It is also possible that there is a bug in that library.

The problem is not being careful about the placement of the end of the loop.
The problem is the pen is picking up too early.
The problem is const_speed is affecting the precision.
The problem is the pen speed is too high, which results in lower precision.
The problem is with the way I have programmed the motion. The second to last step may be very small, and the final step is larger. There may be some problem here.

Mechanical issues

Issues related to the mechanics of the plotter.

The problem is that the main rail is warped by the clamps that I have used to keep the machine in the same place.
The problem is that the pen motion plain is not parallel to the paper surface. This could be caused by the rail warping, or it could be the pen in the holder, or the metal plate is warped.
The problem is that the Y-arm is loose.

Materials

Potential issues related to the materials that I am using.

The problem is that the pen is old and weak.
The problem is that I am not using the same pen every time and this is confusing.
The problem is that I am not putting the pin in the holder consistently.
The problem is that the paper is not as absorbent as needed, and this makes it difficult to lay down the last bit of ink.

Mitigations

Thoughts on what might be done if the issue is not resolved. Let’s hope it doesn’t come to this.

Simply do not close the loops, so it doesn’t show this problem.
Overwrite the loops more than once so that the dots are not as evident.
Hide the dots under overwritten lines; draw lines over the dots as part of the design.
Leave it be, this is one of the things that makes plotted drawings special. I don’t totally agree.

Raw list

First hypothesis was an extension of what I talked about last time. Basically to put the last point at a precise distance from the start mark. This has been my working hypothesis for a while, but it can’t be the only thing; the gaps do not occur consistently.

Second hypothesis is that the pen is picking up too early and then moving away. It is not precisely hitting the mark.

Third hypothesis is that the long rail is being slightly distorted (warped) by the way that I have clamped it to the table. This seems really unlikely, it’s very rigid and the “table” is actually just a piece of plywood. I mean obviously there is some equilibrium between the board and the rail, but come on. Easy to test: just remove the clamps.

Fourth hypothesis is that the pen arm and the drawing surface are not parallel.

Fifth hypothesis is that the pen is getting old and weak, and even if the pen was in the right place, it may not be leaving ink. There are several variations here. Also easy to test: get a different pen.

5B: Different papers absorb ink differently, so it’s not a problem on my HP paper, but it is a problem on the Bristol paper I am using. Easy to test: try with a few different papers.

5C: I have not been careful about which pen I have been using. There are several practically identical pens. I have intended to use the same pen, and have tried to be consistent. But I always have doubt. Perhaps if I use stickers to be sure.

Sixth hypothesis is that const_speed is somehow interfering with fine (small) precise motions.

6B: is a variation: the small motions aren’t the last step, but the second to last step. This ties in with the first one, and I’ll elaborate on it.

6C: Faster motions are less precise, so reducing speed may help.

Seventh alternative is that the dots are obvious because the ink isn’t thick enough, so the bit that is overwritten stands out. Maybe draw slower so more ink can flow, or overwrite more than once.

Eighth alternative is to just not close the loops. Instead of a constant $A$, I could make it a slowly increasing function of $\theta$ such that it increases in radius just as the current function does. This could be interesting, but doesn’t solve my actual problem which may crop up later when I need lines to meet precisely.

Ninth alternative is to hide the dots under other crossing lines. Not always possible though.

Out, damned spot! A prelude

2020-09-17T00:00:00-07:00

It all started with some little dark dots. See the photograph below. They happened to be in a line, and as such, they were very obvious. What follows is (planned to be) a series of blog posts about my unravelling of the trouble I got into trying to solve this issue. Assuming that I do solve this issue to my own satisfaction. The reason for this to be a series of posts is that I’ll try to keep each post focussed. To see them all together, see the #out-damned-spot tag page. You could think of it like a logbook, but I don’t promise to not edit it for clarity as I understand more.

The small marks are from overwriting the same point. Stopping this artifact from appearing in my works has been quite a bit more tricky than I imagined it would be.

In this post, I will describe the original issue, and document as best as I can recollect all the other things that were going on. Luckily I can verify most of this if I desire or need to.¹

Frame of mind: I wanted a bit more speed after my experience with Series002 postcards. The problem there was the text, but I was starting to explore other aspects of increasing speed. See also the first post about faster circles.
I’ve been meaning to add a bit more instrumentation to my code, so there is that. To track number of moves and line segments, pen up and pen down actuations, length of lines and moves.
Things that I have changed since: trying out setting const_speed, raising the pen_pos_down value, upping the speed_pendown a bit.
Working up to Series003 postcards, so searching for something nice to put on them. See the picture above for the idea that I’ve settled on. But they’ve got to be perfect.

So the basic form of these things for Series003 is

\[\begin{eqnarray} x(n) &=& A \cos\left(2 \pi \frac{n}{N}\right) + B \cos\left(m 2 \pi \frac{n}{N} + \phi\right)\\ y(n) &=& A \sin\left(2 \pi \frac{n}{N}\right) + B \sin\left(m 2 \pi \frac{n}{N} + \phi\right).\end{eqnarray}\]

Lets call the thing in the parentheses $\theta = 2\pi n / N$ for now. I choose $A$ to be the larger value and $B$ to be a few percent of $A$, more of a perturbation on top of the circle. These formulae are used in code more or less like this:

def draw_a_circle(center_x, center_y):
  moveto(center_x + x(0), center_y + y(0))
  for n in range(1, N + 1):
    lineto(center_x + x(n), center_y + y(n))

This means that the point at $\theta=0$ is touched by the pen, and so is again $\theta=2\pi$. So the obvious solution would be to only do the range for range(1, N) instead of range(1, N+1). To be clear range will produce a bunch of numbers up to but not including the value in the second position as I’ve written it here.

But, how to pick $N$, the number of steps to draw the curve smoothly?

Well, being lazy, I am just using circumference of the bigger circle (the $A \sin$ term) to approximate the length of the line $L$. Properly, I should do the integral, and it’s not even and especially difficult one. Like I said: lazy.² If I want the step size to be approximately 1 mm, as found in the fast circles pt 1 post, then that means there should be

\[N = 2\pi \frac{A}{1\; \text{mm}} + f(B),\]

for now we drop the $f(B)$ term. And I know it’s a grave offence to mix units, but a 1 inch radius circle is something like

\[N = 2 \pi \frac{25.4\, \text{mm}}{1\; \text{mm}} = 160\; \text{steps}.\]

So removing that 1 step at the end could leave at minimum a 1 mm gap at the end (because for sure $L > 2 \pi A$ unless $B = 0$).

Now I've got a new problem.

Gah! The absence of dots is more like a negative dot!³

That’s enough for now, so I can continue tomorrow. Lot’s more to mention. If you have thoughts, comments or questions, find me on Twitter @pentronik.

This is because I regularly check in code changes and frequently label work with the most recent hash of the check-in, automatically. Occasionally I disable this feature in the interest of plotting speed. I regret this decision later. ↩
But also it’s not that simple. The function doesn’t make uniform length shooting steps. Said another way: $d r/d \theta$ is not a constant, if you accept that $r = (x, y)$. I think I will probably tackle all of this at some point. ↩
I am not, in fact, drawing on a brown paper bag. The lighting is bad. I hope you can forgive this sin too. ↩

August '20 Retrospective

2020-08-31T16:59:59-07:00

What a month, eh? The hits in 2020 keep on coming. Try to take care of yourselves out there in the wide world. :grimacing: :upside_down_face:

Updates

Added a now page. It’s target audience is actually me. But if you get anything out of it, so much the better.
Sent out the Series002 postcards. Woohoo! Very happy to see many of them arriving. :postbox: :mailbox_with_mail:
Started building this website. So that’s a thing.

New Books

High-resolution Computer Graphics Using FORTRAN 77, (Angell and Griffith): I’m quite thrilled with this book. Especially because the Fortran 77 version is ~5$, but the C++ version is a couple of hundred. I may have never compiled any Fortran code before, but that doesn’t mean I can’t read it and translate it into whatever language I happen to be working with. Thanks for the tip @anachrocomputer!
Computer geometric art, (Angell): Not impressed.
Fractals: Form, Chance, and Dimension, (Mandelbrot): It’s an earlier version of “The Fractal Geometry of Nature”, which I didn’t realize. But the variation in explanation of some concepts is detectable and may actually be useful. Glad it was a very affordable price, so I’ll keep them both. But you probably only need one.
Perspective drawing by programmable calculator, (Yue): A recommendation of @johnbalestrieri, looks interesting and I think it will be useful. Looking forward to spending more time with it.
Mathematical Carnival: From Penny Puzzles, Card Shuffles and Tricks of Lightning Calculators to Roller Coaster Rides Into the Fourth Dimension, (Gardner): Seems like a fun idea. It’s a reference in the first Angell book.

Links

Fractal Curves. The pdf books on this site are great. I found this link a long time ago, then lost it. Glad to have found it again.
Markdeep. Looks like an interesting alternative to plain old markdown. It includes a lot of the technical tools that I often want to add anyway.
The Graphics Codex. May be handy someday, but I’ll pass for now.
The Online Encyclopedia of Integer Sequences. Someone linked the book in a tweet, but it’s a couple of hundred dollars. Turns out the author maintains a website! Searching is a bit clunky.
Websters 1913. You may not know it, but I also am a lover of words and writing. This is super handy. Johnson’s is also great for a historical perspective.
Science Advances. The latest news.
Bayes Theorem: A framework for critical thinking.
Roman Bread Recipe!. I haven’t made it yet. I also bake!
Horcrux. I might use it as a post card puzzle in October. Depends on how long the resulting text is.
Slide Rule course.
Awesome sys admin resources.
Pc Part Picker and Logical Increments. I recently decided to add a graphics card to a PC build that my wife and I put together some time ago. It’s not for gaming, it’s for making more art faster, with math! So I wanted to evaluate if I really needed anything beyond a 1050 Ti. Since I have no idea what I am doing, I decided that the 1050 would be adequate for starting, so that’s what I got. When I outgrow it, I’ll need these sites again.

The Connected Perimeter

2020-08-30T15:00:00-07:00

It is now time to consider some more attractive examples to illustrate how, even with only a beginner’s knowledge of computer graphics, it is still possible to draw aesthetically pleasing patterns.

This was fun, and frustrating. Here are my thoughts about working on Exercise 1.8 in (Angell and Griffith, p.17). Get the above file at PlotterFiles.

The objective is to connect all the N points around the perimeter of a circle. The book has a nice listing of the program that draws the figure. And then points out that “if you are using a pen plotter then [the] listing … is not a very efficient way of drawing the pattern.” The next problem (1.9) describes a method referencing the Fibonocci sequence as a way of connecting the points around the perimeter of a square.

Well, I chased that for a while and it really seems to have been a red herring. Or too clever for me. Although I’m really not sure how it connects all the points on a circle when the sequence skips a larger and larger group of numbers as it goes on.

It also distracted me from the relatively simple modification to the listing needed to greatly shorten the trajectory of the pen in the plotter. Here is my pseudo-code of my solution.

For each jump in the range 1 to N-1.
  Go to the point on the perimeter with index 0.
  Draw a line skipping points according to jump.
  Count the lines drawn to ensure they are all drawn.
  If the jump divides evenly into N, when the turtle comes around to the start
    point, move to the next point and continue jumping until back to that point.
    Keep doing that until the number of jumps is equal to N.
  If the next jump lands back on the point that it just came from (all the way
    across, back over the line just drawn for evan N).

You can see the output of the book’s listing, for N=30, in the first tweet (on HP paper). The paper is excellent printer paper, but not up to the task of being hit with a pen in the same place 30 times. It gets pretty roughed up.

I’ll note also that using this algorithm and stopping early has some nice potential for other shapes.

There was a 'Forbidden' error fetching URL: 'https://twitter.com/pentronik/status/1300198873739091968'

The second tweet has the results of my code (based on the pseudo-code above). It is on the back of some Strathmore 300 series Bristol. It handles it better, and also there is a lot less pick up and put down of the pen. But still, the surface is not perfect. It is the edge points that suffer the most, the central point which also is crossed 30 times isn’t so bad looking.

I would have to say my favorite bits of this are around the central point, and the “eggs” fourth ring from the center. Overall, I quite like it, it’s nice that such a pleasing thing is “easily” accessible. Really looking forward to learning some more things from this book.

Improvements

While my solution is quite a bit shorter in travel distance than the original listing, I don’t think it quite makes it to the full 50% reduction. I’ll update with some measurements when I get a chance. I have identified some some further improvements that could be made, if necessary, at a later date.

In my implementation, there are unnecessary pen up/down steps. This is the pen moving to the start point. It’s already at the start point. I am too pig-headed to do the simple thing and check that the x,y location is at the start point. I would rather check it by indices or something else, and ran out of steam to figure that out this afternoon.
Probably fairly easy is fact that for the directly across points, it still does travel all the way back across the circle, and the over one point. I really wanted it to go to the next point and draw the line back. Why are even numbers so hard?
The hardest one. There are unnecessary moves back to the start point. For the circle, at least, the figure is rotationally symmetric. The turtle doesn’t need to move back to the start point. Instead it could use that rotational symmetry to advantage and pick up one of the other jumps. The difficulty with this is the necessary bookkeeping to ensure that all points are visited for all jumps.

It is not clear that all these features are necessary or will even work if I want to generalize to perimeters of other convex polygons. And draw points along the perimeter of the polygon not equal to or even with the number of vertices of the polygon, and not overdraw the sides of the polygon.

Circles: Good and Fast, Part 1

2020-08-23T12:30:00-07:00

After making the Series002 postcards I realized that I was going to have to optimize some speeds to get more ambitious plots done in a reasonable time. For those plots, which were all straight lines, the front of a sheet of 4 postcards (the art side), took about 15 minutes to plot. Not bad. The back, which was basically all text (maybe too much text), took over an hour to plot. This is too slow.

Now, you might think I should start by making text plot faster. You might be right about that. But I want a laboratory to study first. I happen to know that when I first added my circle drawing code for the Series001 postcards, I just picked a step size that I knew would be good enough to make nice round circles (see above, for example). It’s a perfect thing to optimize.

Note: Circles, and curves, are not in fact smooth curves when plotted. They are many small straight lines. A circle is drawn as a regular polygon with many (many-many) sides.

Maybe next I’ll do squares, or regular polygons with O(10) sides or fewer. I think there will be plenty to learn with this subject.

The Situation

Lets start with some basics. A) I just got this plotter a month ago. I love it. But, B) I have no real idea what I am doing. C) I want to do everything myself, for reasons, so I am only doing things via the python API directly in interactive mode. So, some of these first assumptions may be wrong to begin with. But this is about exploring. These are the initial settings:

speed_pendown = 20

I don’t know why I set the pen down speed to 20. What even are the units? According to the API docs, it’s expressed as a percentage of the maximum travel speed. What is the maximum travel speed? And the default is 25, so my value is only 5% less than the default.

For future reference, here are all the values in the AxiDraw.options attribute:

{'ids': [],
'selected_nodes': [],
'speed_pendown': 20,
'speed_penup': 75,
'accel': 75,
'pen_pos_down': 30,
'pen_pos_up': 60,
'pen_rate_lower': 50,
'pen_rate_raise': 75,
'pen_delay_down': 0,
'pen_delay_up': 0,
'no_rotate': False,
'const_speed': False,
'report_time': False,
'page_delay': 15,
'preview': False,
'rendering': 3,
'model': 2,
'port': None,
'setup_type': 'align',
'resume_type': 'plot',
'auto_rotate': True,
'reordering': 0,
'resolution': 1,
'mode': 'interactive',
'manual_cmd': 'fw_version',
'walk_dist': 1,
'layer': 1,
'copies': 1,
'port_config': 0,
'units': 0}

Below is also a listing of my circle drawing code.

import math
from loguru import logger
from pyaxidraw import axidraw

axi = axidraw.AxiDraw()

def circle_edge_pt(x_coord, y_coord, radius, theta):
    """Get a point along the perimeter of a circle."""
    return (x_coord + radius * math.sin(theta),
            y_coord + radius * math.cos(theta))

def draw_arc(axi,
             x_coord,
             y_coord,
             radius,
             theta0=0,
             total_theta=2 * math.pi,
             step_distance=0.01):
    """Draw a perfect circle."""
    # pylint: disable=too-many-arguments
    logger.trace(
        f"Drawing arc at {x_coord}, {y_coord}, {theta0} : {total_theta}.")
    step_size = step_distance / radius
    axi.moveto(
        *circle_edge_pt(x_coord, y_coord, radius, theta0))
    for i in range(int(total_theta / step_size) + 1):
        point = CircleTools.circle_edge_pt(x_coord, y_coord, radius,
                                           (theta0 + (i + 1) * step_size))
        axi.lineto(*point)

Some things to say about this code. The shooting step size (listed as step_distance above) is 0.01 inches, or 0.254 mm.

Measuring Current Speed

With the above in hand, lets measure how much time it takes to draw some circles. I’ve never really measured this before in python, so I’m going to search for some guidance. This article looks pretty promising. Just doing the basics, using the time.perf_counter function to do some tic/toc style measuring looks like it will get us started.

import math
import time

radius = 0.5  # inches.
tic = time.perf_counter()
draw_arc(axi, 2, 2, radius)
toc = time.perf_counter()
print(f"time to draw a {2 * radius} inch "
      f"diameter circle was {toc - tic:0.1f} seconds")
print(f"total line length was {2 * radius * math.pi:0.2f} inches")

time to draw a 1.0 inch diameter circle was 23.8 seconds
total line length was 3.14 inches

I measured a value of 23.8 seconds to draw a 3.14 inch long line, or 0.13 inches / second (3.3 mm/s). This is rather slow. I think we can do a lot better. Incidentally, to draw that circle, the code above made 1257 individual moves. That’s a lot of moves. But it is a very nice circle.

Picture of the circle drawn with the starting settings. Note that it is really a 1257 sided polygon. Bigger version.

My hope is that I can get a circle basically as good but in a fraction of the time. I’m not sure what is achievable, but I set an arbitrary goal of one tenth of the original time, or 2.3 seconds. My immediate reaction is that this is wildly ambitious. First, let’s make a plan, and always re-evaluate if this is reasonable.

The plan

OK, so I had a moment to think and I realized that there is more to drawing circles than just moving the pen around. Ink must flow out of the pen as well. Maybe we can draw the circle in 2.3 seconds, but with one pen we’ll get a nice solid line and another will give something much less nice. But anyway, here is what we’re going to do:

Increase the step shooting distance (the step size)
Change the pen down speed (how fast it draws the line)
The end point may in fact be too far, so examine that too (don’t draw more circle than necessary)
Verify that the circles are still good (that is, still circular)
Circle back, ahem, to the issue of pen down speed to address the ink flow

So there it is, that’s the plan. Let’s do it.

Step 1: Increase the shooting distance

So this is a simple one. The basic idea is to draw circles varying the step size and observe a few things. Here is the recipe.

Draw 1 inch diameter circles, starting with 3 mm steps, down to 0.25 mm.
Measure how long it takes to draw each circle, and the total line length.
View the circles closely to see how well they appear circular.

Below is an SVG of the file that will be drawn. Later down, there is a picture of the plotted page.

The test plot, an SVG file that you can download if you want to. It shows the whole 8.5 x 11 page.

I plotted the file twice and collected the data. The result is reproduced below.

Trial 1:

shooting distance (mm)	run time (s)	total distance (mm)
3.00	4.5	162.00
2.75	9.3	165.00
2.50	9.0	160.00
2.25	9.2	162.00
2.00	9.1	160.00
1.75	9.5	161.00
1.50	11.0	162.00
1.25	11.0	160.00
1.00	12.3	160.00
0.75	14.1	160.50
0.50	17.1	160.00
0.25	23.8	160.00

Trial 2:

shooting distance (mm)	run time (s)	total distance (mm)
3.00	4.5	162.00
2.75	9.3	165.00
2.50	9.0	160.00
2.25	9.1	162.00
2.00	9.0	160.00
1.75	9.5	161.00
1.50	11.0	162.00
1.25	11.0	160.00
1.00	12.3	160.00
0.75	14.1	160.50
0.50	17.1	160.00
0.25	23.8	160.00

It’s easier to see in graphical form.

Data collected for the run time and total line distance drawn for two trials. The top figure shows the time to draw one circle vs the step size. The bottom figure shows the expected drawn line distance. For convenience there is a blue line drawn for the correct length of the circle's circumference.

Photograph of the resulting plot. Here is a MUCH bigger version. Note that there are the two trials on the same page. It's been hand annotated with the shooting sizes, and a few other marks were added by an independent observer to indicate other issues with focusing on. Also note that the first trial was drawn, then the page was rotate 180° and the second trial was plotted. Really bigger version.

The two trials are basically identical, in terms of time. That repeatability is really nice to see.
The distance is going to be identical since that’s just a mathematical accumulation, not a record of the travel distance of the physical device.
It’s a pretty smooth reduction in time as the step size increases, but it plateau’s by about 1 mm. I had (naively) expected it to be linear.
There is a dramatic fall off between 2.75 mm and 3 mm step size. This is really unexpected, it’s basically 1/2 the time.
A note about the overshoot. As shown in the bottom plot, all the circles overshoot the mark. This is expected since (but not desirable) the loop that draws the circles doesn’t take care on the last step to precisely end at the desired length.
A last comment about the code: it doesn’t guard against a negative step size.

I’ll end this part with the list of questions that I have, and they’re likely to be the topics in the next post in the series.

Why is the “time to plot” non-linear? And why does it drop off the cliff at 3 mm?
Observationally with the real output, about 1 mm is the best step size. The pre-render it looks like we could have done bigger. What is going on?
What is a theoretical expected step size? How can we motivate a good choice?

And of course continue with the plan. See you next time.

First Post

2020-08-22T05:00:00-07:00

First post, no content.

\[x = 1\]

Just a tiny bit of math.

And a mermaid figure.

graph TD; A-->B; A-->C; B-->D; C-->D;

Also there is a reference (Angell and Griffith).

Like, here is a tweet:

4500 calls of #vsketch's new `bezier()` functionhttps://t.co/C8mjfTkbAo #plottertwitter #generative #creativecoding #axidraw pic.twitter.com/NeJ0tunqKe
— Antoine Beyeler (@abey79) August 25, 2020

@abey79 makes some really great stuff.