Week 12 - Machine Week Group Work.
Video
Design a Machine
Tilty Treats:
The Magical Cookie Decorating Machine.
Actuation - our machine uses 2 Nema-17 stepper motors to move along the x and y axis, a servo motor to move the pen along the z axis, and a fan to blow fairy dust mostly along the y axis.
Automation - our machine uses an Arduino Uno with the xycore_grbl firmware to read the code sent from the Universal G-code Sender
Application - to draw on a cookie using an edible ink pen that can travel over uneven surfaces thanks to its tilty feet. It also makes the experience magical with the option for edible fairy dust when the reed switch is triggered by the magnetic magic wand.
Week 11 daily group work log¶
Day -2¶
We met at Dorian’s house to decide what we wanted to do for Machine week. Then we started researching options and came up with a plan to make a cookie decorator. We found 2 designs that we thought would work with some tweaking. We added the files to our working document. Then Angela started 3D printing the parts from them, while the rest of the team searched the lab for parts so that we could start building on Wednesday.
Day -1¶
At the lab, Kim made a list of parts from the two options that we were looking at to use to make the base of our design. Mr. Dubick had brought out a few bins of parts from older machines, and we all started scavenging. After getting our parts list sorted out, Kim sat with Mr. Dubick and made the order.
Day 1 - Wednesday¶
Today we started sorting the parts that we had 3D printed, dug up in the lab and that had been ordered. We started to put together all the parts for the DIY kit that we found on instructables, and then the ink blot kit. As we were putting those parts together, Angela did some design work in Blender. She modeled the rails with the ends from the Instructable. Using this rendering, we realized that the modification we wanted to make with the possible tipping wasn’t going to work as well with the rails in the instructable.
So then we started moving more towards the ink blot. The blot has a model in Onshape. Camille brought up the Onshape model and started modifying one of the parts in CAD. Camille made a DXF of the plate that we didn’t have, because we didn’t have the metal plate that was in the kit. We don’t know if we’ll need it. But just in case, [picture doing onshape]
Dorian went and laser cut the plate. Angela started looking at the pen holder and how we could modify that.
It was a very, very collaborative session where we were talking about, first doing the pivot on a bearing, and then while Angela and Camille were flushing out the bearing idea Dorian came up with a rocking idea and then Angela said, well, maybe we can move the feet back and then Camille was like, okay, actually, maybe we can combine those two. And we just kept putting things out there while viewing the blot in Onshape, and then working on it. It was a good session.
We also talked through how we wanted to do the tipping to rest the pen on the cookie. After making some modifications and stuff, we decided that we were going to go back to no tipping. We decided to make the blot similar to how it is for now but adjusting for the cookie pen and then adding the glitter. Then after we have it assembled and we start working with the motors, we’ll see what other modifications we want to make. We’re going to start building again tomorrow.
Day 2¶
Going back to the rocking model, Camille drew up some models with the rocking idea. Then put them into a svg with a 5 degree and a 10 degree rock 6 times. Dorian cut them out on the laser in between teaching classes. Then Camille came in and assembled them and put the shaft in and took some pictures of how it could work. It seems like a valid idea. We have both feet printed in case we want to switch back.
Dorian also had another idea using a servo and a frosting squeezer on the round cookie decorating option. Angela had found a round one so, we may start building both in tandem and see where that takes us.
Kim and Camille worked on setting up the arduino uno’s and the motor drivers used resources from Camille’s week 10 on motors. We had one motor driver that was purple.. Turns out it’s just an off brand A4988 - that’s relief.
We worked together to wire up the motors. Kim coded a test code that moved each motor.
We also worked on getting all the parts that we needed. Some new orders had come in. I also found a transformer in the lab and Mr. Dubick provided me another of the DC to power cord adapters. Then the motors and the wiring went home with Kim and Camille took the build parts as well as another set of motors so that we could work collaboratively yet remotely over the weekend.
Camille modified the onshape files of the motor holders to implement the next iteration of the rocker that Dorian came up with. Camille calls it tilty. Angela got them on the printers, so we could use them in Day 3.
Day 2¶
Software Setup
Angela began setting up and testing the g-code extension available for Inkscape that allows you to export an Inkscape drawing as gCode. She also set up Universal g-Code Sender to see how the Inkscape generated g-code could be used in our cookie plotter.
The process of setting up these tools requires one to download Inkscape, UGS, and the Inkscape extension g-code plot. Once everything is downloaded onto your computer you need to move or copy the extracted g-code plot folder into the Inkscape Extensions folder. This is typically found in Program Files > Inkscape > Share > Extensions. In Angela’s case there was an additional folder within her Share folder so her location was Program Files > Inkscape > Share > Inkscape > Extensions.
With that set up, Angela created a simple design in Inkscape using the built in shape tools to test out the extension. It is important that your design is a path before you export it. To create a path you need to select all objects in your design (Control - A) and then in the Path menu choose the Object to Path tool (Shift - Control - C).
Once your design is a path, you can now use Save As to open the g-code extension tool. When you choose the tool from your save options and hit save, it opens up the GcodePlot menu. In this menu you have 4 main tabs: General Settings, Fittings and Extracting, Drawing Settings, and Cutting Settings. In the General Settings you have control over the precision, x, y, and z coordinates, heights, movement speed, drawing speed, and Serial information. In Fitting and Extracting you can change the scaling mode, and alignments. In the Drawing Settings you have several shading control options and in the Cutting Settings you can change the tool offset, overcut, and add lift and down commands.
Then Angela saved the file from inkscape in gcode.
Upon Angela’s first attempt to use the extension she did get a pop up with a Syntax Warning. According to the note on the warning the script did not return an error, but the results may not be as expected.
Since this was just a test, she decided to see what happens with the file in UGS. The good news is that the file opened in UGS fine, the swirly star image was visible on the visualizer, and the G-Code loaded up. The next step in this process will be to get the machine hooked up once its ready and send the test file.
Day 3¶
Camille lost a titly leg, so she had to print another one. She assembled the basic modified Ink Blot and a second set of motor drivers and motors. She added in the servo to the board. And modified parts for our boards and printed them. See her page for bumps along the assembly road.We ended up having to make and print a plate because the one that we did on the laser was too thick for the bolts that we had.
To figure out where to attach the servo, Camille consulted Claude
PROMPT: where can i attach the servo if i am using the red board and the CNC shield
CLAUDE RESPONSE: The CNC shield is a tough spot for a servo because it’s designed purely for steppers — but it’s doable. The problem: The CNC shield takes up almost all the Arduino pins, and the stepper drivers use most of the digital pins. But there are a few exposed pins you can still use. Available pins on a typical CNC shield (Arduino Uno based): Pin 11 — Spindle PWM (often broken out) — this is your best bet for a servo, PWM capable Pin 12 — Spindle direction Pin 13 — Coolant enable A0, A1, A2 — Sometimes broken out as auxiliary pins How to connect: Find the spindle PWM header on the CNC shield — usually a small 3-pin or 2-pin header labeled “Spindle” or “PWM” Or solder/jumper directly to the pin 11 header if exposed Servo needs signal, 5V, and GND
When camille attached the servo the board, it was then too tall to have board on the bottom of the machine. We will need to decide on a new attachment area for the control board.
Dorian Fritze who was able to get us another transformer and adapter so we could run this set up together tomorrow at our weekend meeting and get our questions ready for the open help session. Dorian also made test cookies so we could practice with them.
Angela uploaded a gcode file of a star for us to start working with, and continued her work there. Kim uploaded some test code for us to use with the new set up.
Weekend¶
More brainstorming so we can come together on Monday and hit the ground running.
Setting the potentiometer Camile looked up the equations and voltage requirements for the driver motors, and we rotated the potentiometers to achieve those outputs.
Rsense: red chip (A4988) had a 10 Ohm resistor (.01 K ohm) purple chip had a 100 ohm resistor (.1 K Ohm)
Formula for Vref = (8 x Rsense)/Amp
We want to run 1Amp
desired Vref Red = ((.01)8)/1=.08 desired Vref Purple = (.18)/1=.8
To get the Vref reading we followed this you tube video
Purple Vref reading = .27 or .48 .27v was the lowest we could get.
This was because the purple chip is a DRV 8825 not the A4988 knock off we thought it was. We were reading the ENABLE pin.
The pinout is the same, but upside down. So that the black chip should be on the bottom, and the potentiometer is at the top when placed in the circuit. Oops, we should have gotten out the magnifying glasses to double check the number on the chip.
Turns out that Purple is a DRV 8825.
DRV8825 Data Sheet, has the potentiometer upside down from the A4988 Data Sheet.
In open time, they suggested we use all the same driver chips. So Dorian ordered some new A4988 chips to try again Sunday.
It turns out that hooking up the motor to the ENABLE pin will kill the driver.
Started working on lining up the cookie and manually moving things around. We noticed a few issues: If the marker was left sitting on top of the cookie, the icing would dissolve, and the marker would sink into the icing The cookie slid on the table. We tried to fix this by placing the cookie on a rubber baking mat, but it still slid. Camile is working on a cookie clamp. The “Tippy feet” needed to be higher to lift the machine to clear the cookie. Dorian baked very flat cookies, by using a rolling pin with capped ends that rolls the dough to the same height every time. This meant we could not test the theory that the Tippy feet would allow us to write over uneven surfaces. Dorian will make her next batch less even
We did not feel that the cookie had enough pizzazz. We are working on adding an icing extruder to make a boarder, and a sprinkle dispenser to drop sprinkles on the wet icing. (sprinkles will not stick to the dried icing that we need to write on).
With an icing extruder we worry about drips. We think adding a drip tray under the extruder tip will catch the drips and adding a lip will help clean the tip between uses.
Dorian is working on gears to drive the pen moving up and down, the extruder tray, and the sprinkle dispenser.
DIY Linear Servo Actuator, 3D Printed
Our syringe pushing mechanism was inspired by this Rack and pinion arduino programming video Then we worked with these files(https://www.printables.com/model/1295719-linear-actuator/files) from instructables integrating them into our onshape document for the syringe pusher.
Couple of videos to make a rack and pinion set in onshape.
This is a youtube with some helpful tips on rack and pinion 3D printed and coding for it.
Day 4 or 5¶
Camille had worked on printing a scissor like cookie holder out of food safe PLA. She also worked on modifying the ties. When Kim went to assemble the new ones, we noticed a flaw in the print that blocked the nema from fully seating into the holder and also blocked the coords from coming out correctly. It can be easily fixed, and reprinted for tomorrow’s meeting.
Angela generated a star in a circle gcode. Kim took the file and put it into her UGS to connect to the motors. We received the following errors. To correct these errors we had to remove G00 and G01 and we needed to change the X, Y, Z homing at the beginning to 150. While making the necessary changes, Camille and Dorian tested the motors with a known Core XY code to see if we can get the motors to run together. Core XY moves both motors at once to create movement. We could not run a simple jog on either motor independently to test them.
We decided it would be helpful to have two sets of motors so we could simultaneously work on uploading and coding, and integration. One set was not connected to any mechanisms, but had tape acting as flags on them. This allowed us to see the speed and direction of the motors. Kim downloaded the necessary libraries/program? to run the gcode in Core XY.
The known code ran the motors as expected so we tested the star code from Kim’s computer to the test motors. Dorian noticed that it was running each action for a long time which made us realize the file was much larger than our cookie plotter would be. Going back to the code we realized the size was set to about 12inches in diameter which was about 4 times too large. Angela modified the design and re-sent Kim the updated gcode to test run. After seeing that our code was working, we tried to run the full machine, but it would not work. We switched out the board, the CNC shield and then then cord. We learned that you must type “on” to start the program, and with that we were able to get both sets working.
Make sure to type in “on” to start the program
Camile decorated our first cookie, and was rewarded by getting to eat it!
Kim was next, making a perfect square then testing some additional commands.
G00, G01 Modify X, Y, Z Homing.
Sweet success
Day 6¶
Servo plunger was a fail.. The servo was not strong enough for the plunger. We would need to add the stepper motor plunger from Rico or try something else to stay with servos. We do have the Z axis open.
Dorian came up with a dust idea to dazzle them all.
Kim kept working on getting the gcode to integrate into our ecosystem. We have a second set up for her to work on. She worked on adding a contained area to be our workspace for the machine. She tested out several different forks of the grbl code and the most promising one was the misch/grbl-servo fork. Kim sent the command G0 X10 to move it to the right 10 mm and the carriage started running diagonally. She asked Claude what was happening. It said this was very normal and is textbook CoreXY — both motors run together on every move, so if one of them is spinning the wrong way, your +X drags a little +Y along for the ride and the whole thing drifts off at an angle. Per Claude,the fix lives in GRBL’s $3 direction invert mask, which on CoreXY you’re flipping a motor — and each motor has a hand in both axes. Luckily $3=1 knocked out the diagonal on the first try. X was moving in a straight line again, just… the wrong straight line (a +X command was sending the carriage left). From there it was just a bit of poking at the Y direction to figure out which motor still needed flipping to get +X going right and +Y going away from the operator. Once both directions pointed where they should, the diagonal weirdness was gone and the next step was to work on the z axis.
Angela drew up a new cookie holder. First one, although super cute and food safe, was skipping over itself, and we really wanted to be able to squeeze it open. Angela and Dorian brainstormed a new one and then Angela made it happen in Blender. Then they printed some test ones and got it working and planned out how it would attach.
Dorian started story boarding our video and planning that out. Then she explained the new attachment we would need for the fan and the dust. Camille started sketching on paper to interpret and then took the sketches home to work on it. Dorian found two different fans, and Angela found another hobby motor we could use without a motor driver so we would have two options.
Dorian brought in a cabinet door for the assembly and Angela is designing stops integrated into the cookie holder to keep tilty aligned on the edges.
Day 7¶
Camille CADed the fan clip and sent out for comment, Dorian asked for a powder receptacle. After adding, Camille sent it to Angela for printing. We will test it this afternoon. We will probably connect it to the spindle pins… 12 or 13 - we will use one for the servo and one for ht
Angela is designing a KICAD board for a REED switch and a regular on off switch to make our magic happen with the fan.
We had an open house so we put everything together and taped it up and integrated the two test codes to be able to have something to show at the showcase. Dorian demo’d the cookie decorating. The first fan clip had the fan module in too close and so it was hitting the pen holder. So Camille fixed that in the cad, Angela had it printed by the time we got to the lab.
Dorian wired in the Reed switch from Angela, and Camille wired in a hard switch. They used electrical tape to secure everything. The REED would not go… that’s a tomorrow issue.
Day 8¶
We set up a multimeter with our REED switch to look for continuity. We used the big magnet and found that the continuity would work, but not with the wand because the magnet was not strong enough.
We referred to our Day 4 information to connect the UGS from a different machine. We have to remember to close out the arduino to connect to the machine.
It was a bit of a strugglebus day for Camille as she tried to get UGS working with our code on the windows machine. Garrett Nelson worked along side camille for an hour finding more resources and helping trouble shoot the issues. They did get the fan working and
Kim continued to work remotely on her code on the xy core machine and provided support to Camille as she tried to get it working on the windows machine.
From her Claude, she found out that although Kim’s code worked on her apple, camille needed to make different adjustments for windows and we didn’t figure out that needed to happen until the end of the day. So we will try that tomorrow.
From Kim’s Claude - she entered the errors I was sending…
That's the misch2 fork itself — those lines are commented out by default in that repo. The fork ships with them disabled intentionally.
The reason it compiled for you and not her comes down to one thing: Arduino IDE on Mac vs Windows.
On Mac, Arduino IDE has more aggressive caching. When you were flashing back and forth between different forks all day, the IDE likely had a valid cached build from a previous version that it reused without fully recompiling from scratch. So it never actually hit those errors on your machine.
On her Windows machine with a fresh install and no cache, it compiled from scratch and caught every error the fork ships with.
So the misch2 fork has bugs in its default config.h that your Mac IDE masked. She needs to fix them before it'll compile cleanly on any machine.
Tell her to open config.h in Notepad and uncomment these lines:
#define HOMING_CYCLE_0 (1<<Z_AXIS)
#define HOMING_CYCLE_1 ((1<<X_AXIS)|(1<<Y_AXIS))
#define REPORT_WCO_REFRESH_BUSY_COUNT 30
#define REPORT_WCO_REFRESH_IDLE_COUNT 10
#define REPORT_OVR_REFRESH_BUSY_COUNT 20
#define REPORT_OVR_REFRESH_IDLE_COUNT 10
And also uncomment COREXY while she's in there. Then it should compile cleanly on Windows.
You should also update the handoff doc to include these fixes — they'll affect anyone compiling this fork fresh on any machine.
Dorian hatched an amazing plan for the video, brought and set up all the props and then directed us all in our video making. Angela helped with the sets and worked collaboratively with Dorian in directing and fine tuning the video plans. Props were made using Dorian’s Cricut machine to create stencils, 3d printing the scrying device, and the kitchen area cabinet is Dorian’s week 7 assignment.
Angela, Camille, Dorian, Dorian’s daughter (as Kim), and Garrett Nelson did some great filming for the video reveal. Lots of loading, unloading and setting up.. They are amazing! It was good to add some fun to destress.
Angela also did more work on the braces for keeping tilty on the table and making the cookie holder. She changed the width, and the made a pushing enclosure box to hold the squeezing contraption as we push the sides to open the holder to enter the cookie. She has integrated braces into the cookie holder so that it can all be one piece that fits onto the table.
Angela took over the editing process of the video, and did an amazing job!
Day 9¶
Working on getting the machine to respond to windows. The key was that the file really was too big. Took out some spindle code and was able to modify it with claude directions.
https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
PROMPT: what changes do i need to make for a coreXY machine running off of windows
Claude: Your config.h looks good but needs a few changes for CoreXY on Windows. Here’s exactly what to change: 1. Enable CoreXY mode Find this line: // #define COREXY // Default disabled. Uncomment to enable.
Change to:
define COREXY¶
- Fix homing cycles for CoreXY Find these lines:
define HOMING_CYCLE_0 (1<<Z_AXIS)¶
define HOMING_CYCLE_1 ((1<<X_AXIS)|(1<<Y_AXIS))¶
Change to:
define HOMING_CYCLE_0 (1<<X_AXIS)¶
define HOMING_CYCLE_1 (1<<Y_AXIS)¶
CoreXY cannot home X and Y simultaneously — they must be separate cycles. 3. Disable homing init lock (since you have no limit switches) Find:
define HOMING_INIT_LOCK¶
Change to: // #define HOMING_INIT_LOCK
Without this, GRBL won’t boot into alarm state demanding a home cycle. 4. Disable CHECK_LIMITS_AT_INIT (no limit switches) Find:
define CHECK_LIMITS_AT_INIT¶
Change to: // #define CHECK_LIMITS_AT_INIT
Those four changes are all you need. Save config.h, re-upload grblUpload.ino, and GRBL should boot cleanly and connect in UGS.¶
Now to get the inkblot code to fit.. We need to understand our steps/mm
steps/mm = (motor steps per rev × microstepping) / (belt pitch × pulley teeth)
Angela did some awesome work on editing the video and getting ready to insert more clips when we film them on Monday. They used vsdc. They even gave a sneak preview in open time.
Dorian designed and printed a pen holder that would not only hold the pens in the back but also work as a counter weight and fairy dust holder. We need Tilty to tilt, but not crush in the front. As we started adding the fan and other things to the front, we started to tilt more and more.
When looking at the bolt we used as a counterweight together with the pen holder, Dorian thought it would look cool to be turned into a fairy. Angela agreed, and drew a quick sketch with gears.
Dorian used Meshy, tinkerCad, and Bambu Studios to create the fairy wing, counterbalance, and pen holder.
Day 10¶
We decided to install the REED switch directly to the top of the pen head. To put the reed switch there, we could have cut into the fan wiring and then soldered at the top. Camille didn’t want to do that because the wires were tiny and we don’t have a back up. So instead, Camille pulled long wires that could get to the place where we connect to the board so that we could connect into the end of the servo and then direct to the CNC shield. We ran these wires with the fan wires so that we can contain them together. Camille used collapsing solder tube connectors and a heat gun to add these wires in.
Then we worked on wire management. Angela and Dorian worked on using flex tubes and flex wire cover to cover all the wires. The tubes were large enough that we were able to get all the motor wires in without making super long tubes.
Continuing to find tune the stepper motor movement on the XY core, we calculated the steps per millimeter.
PROMPT: steps/mm = (motor steps per rev × microstepping) / (belt pitch × pulley teeth) I am using a GT2 timing belt, with maybe a 16 tooth or a 20 tooth pulley , no microstepping, nema 17 motor CLaude Let’s calculate both options: NEMA 17 = 200 steps/rev, no microstepping, GT2 belt (2mm pitch) With 16 tooth pulley: (200 × 1) / (2 × 16) = 200 / 32 = 6.25 steps/mm
With 20 tooth pulley: (200 × 1) / (2 × 20) = 200 / 40 = 5 steps/mm
So send one of these in UGS console depending on your pulley: $100=6.25 $101=6.25
or $100=5 $101=5
These are much lower than the 80 and 250 we had before — that’s likely why nothing moved, the steps/mm was way off. To figure out which pulley you have — count the teeth on the pulley or measure the diameter. A 16T pulley is about 10mm diameter, a 20T is about 12.7mm diameter.
UGS connection issues persisted. Since KIm’s code was written on a MAC, Dorian started working on her MAC to try to get all the software installed so that she could help test the code. She was successful in getting UGS installed.
Camille and Angela continued to work on getting an image from inkscape into UGS to be able to print on the cookie. They had to reinstall the UGS upload file onto the Arduino by flashing it a couple times. Then they ran some other arduino codes that they knew worked to confirm that the motors and all hardware was working and that the computer was connecting to the arduino.
When we got the machine running we noticed that it was kind of grindy. We started to work on the potentiometers to try to change the V ref to see if we could smooth it out. We changed them low and they wouldn’t run. We changed them higher, and the noise got louder.
In the process of working on the noise, we noticed that one of the motors had stopped responding. We did about an hour of troubleshooting, working to figure out the problem. We changed Motors, we changed wires and then we changed the motor driver. Eventually, we figured out that one of the motor drivers burned out so that took a lot of time to troubleshoot to figure out what it was. We replaced the motor driver, set the Vref back to a value that worked.
Angela went to inkscape on another computer. She, installed the gcode plug in and made a star image for us to work with. She then saved the star using the plug in which gave us a small star gcode file to work with.
When we first brought the star in, UGS really wanted G28 homing codes. We tried many ways to work around this.Eventually, we decided to take out the Homing codes and the Z codes and work directly with the XY codes. We were then able to use Tilty to tip forward and draw the design onto the cookie! We did it!
VIDEO OF TILTY DRAWING THE STAR
Day 11¶
Dorian worked on getting her computer ready to run our codes. She had an idea on how to get the servo to work as part of the g-code. She updated the code to change any z code to servo code (logic is z == 0, servo == 0, z > 0, servo == 90) this is set up to run as we have it set up now with the servo on SpnEn (pin 12).
Dorian also created a g-code of the fab logo to run in it.
Dorian printed geared fairy wings with a backpack pen holder for Tilty. Also made a PowerPoint slide, edited the xycode_grbl to run the servo with z-axis movement, and made a g-code for the fab lab logo. 🤞it all works
Angela worked on integrating the cookie holder with the existing tilty feet so that we can hit the ground running on Monday when we are back in the lab together.
Day 12¶
Final Integration and details…
Dorian and Kim tried to get Dorian’s computer to run the code on the spare machine set up as Camille and Angela set up Tilty. It wasn’t working, and we decided to get video of our working machine before playing with the new code.
Kim thinks the reason the code would not work was because Dorian had Arduino IDE still open while trying to connect to UGS. Arduino was causing conflict with the port. She has had issues with that in the past.
Dorian let Codemaster Kim take over, and went to decorate Tilty. She added a skirt made from chiffon cinched with elastic around the wire housing to cover any unseemly wires. The fabric is food safe, and washable. She also attached the counterbalance made to look like geared fairy wings. Saturday’s tests needed more weight as a counter balance, and we hoped the wings would add art to function. However, the balance was not needed as much today. This may be because of weight added during the wire management process. We ended up having more fun moving the wings around during filming then using them to balance.
Angela’s cookie holder and foot clamp held Tilty in place, but the cookie portion was just a smidge short. In the end, when it came to holding the cookie, the simplest solution worked the best. We used magnetic nametag holders with the backing placed under the baking mat.
Kim’s code would not run the servo. So Camille took out every z- axis code line and inserted “m 0” to make the machine pause when the pen would lift. This allowed for pen changes.
We were able to get Tilty to draw a monochromatic star:
And the Fab Academy logo
But it wasn’t complete without the fairy dust!
Video of Tom making the fairy dust go.
Follow up:
Getting the servo to actually do its thing took Kim through a bit of a firmware rabbit hole. She tried three different GRBL forks before landing on misch2/grbl-servo. To get the servo to actually work Dorian came in and made it happen. The SG90 servo gets wired to D11 on the CNC Shield v3 clone — except that pin is actually the white one on the Z- endstop header, not the spindle header where you’d expect it. Once the GCode Z mapping was modified at Z_MM_FOR_MAX_SPINDLE_RPM=15.0 for pen down and Z_MM_FOR_MIN_SPINDLE_RPM=19.0 for pen up, it worked beautifully with the gcode file. For a quick test, they printed out the Fab Lab logo.
