The mystery of the Graphtec plotter
These are just my observations, I make no claim to facts
I wanted to use the plotter to draw some posters for my upcoming show. I was printing these out in batches of 10 to minimize color changes, time, and wear on the paper which will disintegrate after too many passes over the rollers.
- The Graphtec Plotter in dFab seems to have a mind of its own. While it can create beautiful and precise drawings and vinyl cuttings, it’s a seemingly inefficient machine with an unknown sorting algorithm. The machine will start drawing in one area, then move to a location on the other side of the paper to continue, then back again, wasting an enormous amount of time during travel.
- Parts of my file:
- a collection of mostly open curves, printed first with a yellow marker
- Color 1 – Dominate text Color.
- Single Line font created as a text object (open cvs)
- Regular font created as a text object (closed crvs)
- An exploded hatch of the text shown as an open curves in properties
- Color 2 – Same as color 1 printed in a subordinate color
- While my posters were printing I noticed an interesting phenomenon. On Color 1 and Color 2, The Single Line font, and the font outlines would print first, on all posters with the normal no sorting nonsense. After all other geometry had printed, the plotter would return and print the exploded hatch. So then, there is some logic behind the sort. The likelihood of a random sort separating that many like-geometry is very low.
- To Test this logic, I identified several possible distinctions that separate this geometry from the rest
- Drawing Order
- Open/closed Crvs
- Point count
- Line type
Can I use one of these distinctions to analyze the plotter’s sorting algorithm, and ultimately print my posters faster
- Past Solutions
- The quick and dirty fix is to “show” and “hide” geometry to print smaller areas and save machine time. This is annoying and much more user intensive.
- So far, the best approach to sorting has been drawing order, in other words, the order in which the geometry was drawn in rhino. With this knowledge, rhino curves can be run through a grasshopper algorithm to sort by distance to a point, then baked out to rhino for a slightly faster operation. This works but is unreliable and still has it’s issues.
- The Hatches were “drawn” last when they were exploded, so the plotter sorted them at the end.
- Still a possibility, although Mckibbin claims to have disproved the drawing order theory.
- Open/Closed Crvs effect the sorting algorithm
- At a glance, it may seem like the hatches were printed last since they were open curves and the text is a closed outline. However Color 1 and 2 contained other open curves which were not separated in the same way.
- Point Count or Line Type (degree, 2 point, exploded from a hatch, etc) effects the sorting algorithm
- This may still be true, I did not have a quick way to test this hypothesis
- The Geometry’s Layer effects the sorting algorithm
- At some point in the file’s creation, the hatch was located on another layer. I thought that I may have left the hatch on a separate layer causing it to print last. While this was not the case, it was an interesting hypothesis so I tested it.
- Designing the experiment was simple. For the first operation–Cubes, I placed each poster’s design on a sub-layer labelled 1-10. With all sublayers visible, I sent the file.
- Amazingly, each individual poster printed completely by itself before the machine moved to the next one.
- But that’s not the full story. This test did not actually replicate the conditions I initially observed with the text and hatches.
- So I repeated the process with color 1 and 2, separating the poster regions into sublayers 1-20
- This time something interesting happened.
- The plotter printed the single line font and text outlines, staying within the layer regions similar to the first test.
- Then the plotter moved on, printing each additional poster, staying within the region, but not printing the hatches.
- Finishing the operation, the plotter returned and printed to hatches, again staying within the bounds of each layer.
- While this was not the intended effect, it was way faster and still saved a lot of time.
Round 2 Questions:
- After consulting the wonderful Ryan McKibbin, there were more questions.
- How is it sorting the order of the layers, by number? Alphabetically? By layer structure within the Rhino interface?
- Do layers vs sublayers vs sub-sublayers affect the order?
- Does the geometry in each poster sort the same?
- Does it sort the same each time you send the file?
- Again, I was in the middle of production and did not want to alter my file too much, but some of these could be easily observed or altered.
- By watching the machine, I could see that each poster was sorted differently than the next, but each time the file was sent, they were sorted in the same way.
- The layers seemed to print in reverse order to their screen display, which was also reverse numerical order. To isolate the variable, I switched layer 10 with 11 and 18 with 19.
- The posters printed in reverse order to their screen display despite the layer names, that is 18. 19, 17. …12, 10, 11.
- From Experiment 1, the layer theory seemed promising. My operation time was cut in half, the machine wasn’t wasting time traveling all over the picture plane, the results seemed fantastic.
- Experiment 2 showed me that there is something to the layer theory, but there is a greater hierarchy above the layer sort.
- Experiment 3 clarified the layer print order, and showed that the machine remains mysterious.
- Being able to sort by layer, despite its quirks, is a huge advancement in time savings.
- Similar to the show/hide strategy, users can group their geometry by region so save travel time. The advantage of the layers is being able to send the whole file at once.
- Additionally, there is a potential for an improved grasshopper algorithm to sort the geometry, and output to a myriad of layers, each guaranteed to print separately, in a defined order.