ord

Based on the machine invented by Sir Marc Isambard Brunel in 1802: "The thread is carried round the ball by means of the flyer and at each revolution is laid in a different place owing to the slow rotation of the spindle, which is connected with the flyer through worm gearing. The inclination of the spindle can be adjusted by the hand lever to control the shape of the ball produced." — Science Museum Group (UK)

Great MOC and presentation! I really like the tail lift mechanism.

What a difference a few lines of code can make... By adding the following line for each of the motors, their accelerations are effectively no longer limited by the control, meaning a lot faster plots: motor_x.control.limits(acceleration=20000) My only concern is whether this will quickly cause damage to the motors. Perhaps someone who knows more about motors can answer this? I've been experimenting with different media too (before the acceleration limits were changed): IcoSphere: File: IcoSphere (SVG) Paper: A4 200gsm Speed: ~10mm/s Plot time: ~52min Pen: Lilac gel pen The Great Wave off Kanagawa: File: The Great Wave off Kanagawa (SVG, stripped to a few layers) Paper: Brown A4 250gsm Speed: ~20mm/s Plot time: ~81min Pen: Rotring 0.5mm graphic pen

. After tweaking the backlash numbers, it's plotting a lot better now. I also faced a curious problem that took some time to figure out - the speed of the print head was fluctuating in the x-axis, with each rotation of the x-motor: After checking gears, shafts, and switching out the motor with no improvement I was stumped. I then removed the pen-lifting motor that was mounted to the side of the x-motor and success - the problem disappeared! The motors must interfere with each other when mounted too close together. They are now mounted far apart. With this sorted, the plotter was ready for its first real A4 plot... Bunny: File: Bunny (SVG) Paper: A4 200gsm Speed: ~20mm/s Plot time: ~40min Pen: Rotring 0.5mm graphic pen

Thank you, I appreciate the comments :). I use a handy tool called vpype (that's specifically made for plotters) and a plugin for it called vpype-gcode to convert the .svg file into the code that you see under program(). That art in the first plot was just an .svg file that I downloaded. Vpype sorts and scales the line segments of the .svg... vpype read C:\input.svg layout --fit-to-margins 20cm --landscape 297x210cm show linesort gwrite --profile pybricks C:\output.txt ...while vpype-gcode (referenced by gwrite above) turns it into the code that I paste into Pybricks, by referencing this custom profile... [gwrite.pybricks] document_start = "def program():\n" segment_first = " move({x:.0f},{y:.0f})\n head_down()\n" segment = " move({x:.0f},{y:.0f})\n" segment_last = " move({x:.0f},{y:.0f})\n head_up()\n" The last plot I did (A4 plot #1) didn't use an .svg file but rather was created entirely with the vpype command line interface, because it was easier that way. Hope that makes sense!

A4 plot #1: File: generated with vpype and vpype-gcode Paper: A4 200gsm Speed: ~20mm/s Plot time: ~7min Pen: Rotring 0.5mm graphic pen It's working again . There are a few artefacts that need fixing - it probably needs the backlash recalibrated and maybe a 'clamp' on the y-axis (like what's on the x-axis). I'll work on them next. @Carsten Svendsen thanks, it's programmed in Pybricks. Here's the code for this plot if you're interested:

Thanks for the suggestion Snipe. I remember seeing these in another thread - they look interesting but the ends seem to be held by friction only. There might be ways to secure them, however I am quite happy with my current setup for the plotter. I'd definitely like to try these out for something else though :). Regards, ord

Update: Plot area increased to A4 (not plotting yet - soon!) Y-axis driven by 14-teeth sprockets on turntables. This is tentative - turntables seem to have more friction than axles, which could cause vibrations. They do however allow for a large gear reduction (5:1), which reduces torque in the drivetrain. Testing to come with new motors and a stiffened drivetrain X-axis carriage rebuilt to move pen tip closer to chain attachment point (see renders below) Soon: two large angular motors to drive the Y-axis I'm really excited to get this thing plotting. One unfortunate thing about the current generation motors is their lack of (official) extension cables, which means I have to locate the hub in an inconvenient position at the back, or buy a bunch of 3rd-party cables. X-axis carriage. Grey - rails; Red - carriage; Blue - pen holder; Yellow - pen lifter; Green - rail clamp.

Cool project! Thanks for all of the updates - I'm really enjoying following this

I present my latest MOC - it contains one part Try it yourself by pasting this code into the Mindstorms app (see if you can get 100 points):

Wow! I always loved this car and it's great to see a near-perfect rendition of it. Excellent work!

@2GodBDGlory there was a topic in the Mindstorms forum recently that might help: As far as I know, there are no other apps that offer both the programmability and the control (buttons, sliders, etc.) that the Powered Up app does.

I've tried the suggestions for reducing file size and here are the results (only tested with one SVG file): I called mem_info() at the very start of the code (after imports) and at the very end of the code. Shown is the memory used at each point. Original code, program(speed): start 78KB, end 188KB Speed parameter set as constant, program(): start 73KB, end 80KB 'Program' function removed, move() calls only: start 73KB, end 78KB (speed constant) Positions stored in list, position_list[]: start 106KB, end ? (speed constant) I didn't wait for the plot to finish with the positions stored in a list, as it was taking a very long time (I think due to motor_z.run_target() being called with every move) and the memory used at the start of the program had already exceeded the memory used with the other suggestions. So I think setting speed as a constant will be the most helpful thing to reduce file size. I am now, however, running into errors such as ValueError('incompatible .mpy file') and MemoryError: memory allocation failed when simply pasting all of the moves in twice (which I thought would use <2x80KB<252KB). Maybe I'm making some other mistake here though. Anyway, it's not a huge problem to run a few programs for one plot if I need to.

Back to the mechanical side of things... I now own four of each of the tread link sprockets and need to decide which will be best for the Y-axis. The smallest ones would make the whole MOC nice and slim but would be more prone to chordal action (variations in speed and position of the chain), so I investigated to see just how much... My conclusion: the speed and hence positional accuracy of the Y-axis will vary by a maximum of 13.4% if using the smallest sprockets, cyclically every 12mm. This isn't a huge amount, but combined with a radius variation of 1.6mm (chain will move up and down by this much every 12mm) I think I'll stick with the 10-teeth sprockets, or maybe even use the 14-teeth ones for maximum smoothness/accuracy.

Thanks for the suggestions. They all sound good and I look forward to trying them. Is that different to what's shown in the official app's documentation? I'm confused. Either way, I checked out the Motor class on that page and couldn't see anything similar to run_target() with wait=False as a parameter, like what I use in Pybricks.

Thank you Jos and Pybricks! That would be great! As a side note, I am continually impressed by the power of Pybricks and its many advanced features. So thank you @Pybricks for the work you've done to make such useful software and the documentation to go with it :) I convert the SVG file to a sequence of move(), head_down() and head_up() commands which I paste into Pybricks. Here is the start of such a sequence: def program(speed): move(581,10,speed) #Move to x = 58.1mm, y = 1.0mm at some speed head_down() move(583,16,speed) move(585,17,speed) move(587,13,speed) move(587,10,speed) head_up() move(594,10,speed) head_down() move(594,11,speed) move(596,17,speed) move(598,17,speed) ... Later, I call program() with speed as a parameter. The first two parameters of the move() function are X and Y coordinates. They are stored in 10−1mm units, which allows for 0.1mm accuracy while storing them as integers (this reduces the program size by about 75% by my measurements, compared to storing them as floats). Without an in-depth knowledge of how programs are sent to the hub though, it's hard to know how to make it more efficient. Would trimming down the move() function itself help, since it is called so many times?

Thanks all! @Jonas I plan to make a Studio model of it once it's finished - it's still very much a work in progress. A small update: I found a very cool tool called SquiggleCam - it converts any image into a bunch of wavy lines for plotting. I love it. Here are two plots I've done with it so far... Plot #2: File: My desktop background (The Matterhorn), in squiggle format Paper: A5 200gsm Speed: 40mm/s* Plot time: ~30min (divided into 2 roughly equal parts) Pen: Rotring 0.5mm graphic pen *The programmed speed of each linear movement, not necessarily the overall speed, as I'm still working on timing between linear movements

Hi, I am working on a classic XY Plotter that is controlled by the new Mindstorms hub. It's a work in progress and hopefully I can show some improvements here over time. I made it with the Robot Inventor Hub instead of the Technic Hub simply because I wanted to try programming with the bundled Mindstorms MicroPython software. I was unable to achieve some crucial things with this software (most importantly a simple way to run multiple motors in parallel?) so I switched to Pybricks but kept the Mindstorms Hub. The code was adapted from my Cartesian Parallel Robot - easy! Features: Lightweight XY carriage with all motors mounted off the moving parts Pen raising and lowering Programmed to 0.1mm accuracy Programmed with backlash compensation (0.9mm in X, 0.5mm in Y) I hope to reduce the mechanical backlash some more. For the moment though, programming it out seems to help. Also, I have implemented the method described by Didumos69 here to maintain tension in 'loops' going through the chains and remove backlash in them (I found this to be a better solution than tensioning the chains with springs). In this video the hub's display shows when backlash is compensated for in each axis: Plot #1: File: Gaudi's Honeycomb (SVG) Paper: A5 200gsm Speed: 20mm/s Plot time: ~30min Pen: Rotring 0.5mm graphic pen I found a good website with some free SVG files to start with (link above). This particular file required around 4000 lines of Pybricks code to plot. I'm approaching the point where files are too big for the Inventor Hub (and its ~252KB of available RAM). Perhaps someone could tell me if there's some way to load larger files onto the hub using Pybricks or is this something that's only possible with the Mindstorms software or am I stuck with splitting larger files into multiple plots? I'm reasonably happy with the result. There are some obvious defects though and I would like to make it faster. Here's a short real-time video. What's next? I have a bricklink order on the way with parts to increase the plotting area to A4. I think this is the maximum size that this design can be, given the 32L axles along the Y-axis and for the pen raising/lowering. Aside from that, I will try to further reduce the backlash and increase the speed. Mostly though, I just want to plot some different things (which I will post here). Thank you for reading. More to come soon...

That is good to know. Do you have information about the precision of other current generation motors (e.g. SPIKE Prime)?

Fair enough, I guess there are always some trade-offs and sometimes it's best just to keep it simple. I feel your pain with trying to make Lego precise. I'm currently building a simple XY plotter and the large links for the main rail are even harder to work with than the small links (imo).

Simple, yet effective. One small improvement I can suggest is to keep the chains perpendicular. Currently they are at an angle that will change with gantry position, which will reduce accuracy. At least I think that's how it works...

Could you please clarify that the ends are in fact bars, not axle connections? I.e. It is connected to the motor only by friction

Was that picture done with the robot? It looks good.

Nice. I have an idea for what you can do with it - make it 'draw' on one of these: https://en.m.wikipedia.org/wiki/Pin_Art

I agree, these would be great. Yes, an engineering degree and have worked as one for a few years.