Very nice about the progress :). What makes you think the Pi is overheating? Are you seeing anything in the logs to that effect? I’ve ran many Pi in many extreme conditions and I don’t think I ever had one do that. To further convince yourself, you could check the logs, read the sensor continuously, maybe blow a fan on it, or run a CPU stress test to see if you can drive the issue manually regardless of the PlottyBot software stack (which isn’t particularly demanding on the CPU to begin with). My first reaction would be to look at the circuitry before anything else, and see if the Pi dying correlates to any particular action being taken (maybe it happens randomly when the servo motor is engaged, or maybe it’s a stepper motor that does it). I hope this helps somehow.

I got all the way to the servo motor part!

My only issue is my Pi is overheatting and essentially dieing. It happened twice 🙁

I thought maybe too much voltage was entering the Pi but after checking the voltage with a multimeter the voltage read 5V. I am going to check my wiring with your circuit diagram.

do you reccommend any solution?

Okay I will try this today. Will let you know how it goes. Thank you!

I don’t think so that image has been there and functioning for a while. The one thing is that the first boot takes a good long while, 10 to 20 minutes (I don’t remember exactly). Normally if you powercycle the Pi in the middle of it, it should be able to finish installing everything, but if I were you, I’d reflash the SD card, boot it and let it sit for a good long while. Then I’d check so see if the Wifi network exists. I’d check for that wifi with several devices too, a Pi does wifi at 2.4Ghz, maybe you have a computer that only does 5Ghz? So maybe try looking for it with your phone or another computer.

I hope this helps.

I am stuck on the part where one installs the OS onto the SD Card then the RPI.

The wifi network PlottyPot is not intilizing. Could the OS be faulty?

What do you recommend I do?

Hey Brady,

I still have a bit of work to have something releasable, I will try to get to it the second half of May. But what’s already there is quite usable, and updating is just an SD card swap so hopefully that doesn’t stall progress. Good luck with the build!

Just now starting to build this project, if either of you get a working upgraded software stack please publish it somewhere here for us to grab!

Absolutely! I’ll drop you a direct email. I’m pretty tickled with the results I’ve gotten so far – This is the first attempt at a multi pen drawing if the link works,

https://photos.app.goo.gl/vuiicvMMXZD1iS1e8

and this is the Dashboard,

https://photos.app.goo.gl/dnsKnGmjvtw1GekXA

I’m still dealing with some bug fixes, but it’s been pretty functional.

Wow, it’s been a while since I heard of someone building one 🙂 Nice. And amazing that you’ve gone this far improving the software stack. I’d love to see the changes you’ve made, you’re welcome to do whatever you’d like with the code, I don’t put things online with strings attached.

I’ve actually been improving the software stack significantly these past few months, mostly to port it to all the other drawing machines I’ve been, but it inevitably led to improvements in other dimensions, including some you did yourself, and I’m pretty sure I tackled several size issues too as I threw larger and larger files at it. None published so far as I’m still working on this. You’re right that my GCode parsing is asinine. I got turned off by the various flavors so I’m parsing for known markers without much regard for the actual GCode standards. I initially developed for Inkscape’s flavor of GCode, and then adopted a few other I found in the wild, or that others brought up.

There is at least one other group I can think of using this in education who would be interested in improvements. Would you like to hop on a call some time to compare notes?

I have just finished mine. The motors and limit switches were probably the most frustrating, but since not all motors are created equally, I just had to diagram out the wiring. I had 1st and 2nd coils initially flipped, so my limit switches were acting as if I had them backwards, but I got that figured out.

I did have some confusion with the software, as it didn’t appear to accept some gcode standards, but I was able to use your example gcode in one of the comments above, and get a parser written to convert raw gcode from Drawbot to the something acceptable for PlottyBot. I then pulled the /var/www/html folder off the pi and plottybot.py and was able to get it modified to accept direct, standardized gcode. I rebuilt the Dashboard – it contains the calibration section, paper size calibration, (plotter units to mm) with paper size selections and scaling.

It uses a similiar style for GCode insert, with option to load from file and paper orientation for portrait or landscape. I added project storage for plots with multi-pen – multiple gcode files. One thing that I could not figure out on the original software, was that no full gcode would ever finish – I suspect due to the size, maybe out of memory or even my gcode parser causing problems. It seemed random every time.

I’m no longer having that issue, at least not for a few runs. I put the MandalaGaba back in but have not thoroughly tested it. Most of the dashboard is new with a couple of re-used assets, but the plottybot.py is still used on the backend with modifications. Would you be open to me throwing this on github?

Many thanks Ben

Oh I’m around all right :).

here you go: http://ben.akrin.com/downloads/plottybot.fzz

Not even sure this reaches you, but thinking that if you run this on your small device, chances are you are still around.

I’m rebuilding the plottybot since the first time i had a crap 3d printer and everything was misaligning. It has been so long ago it’s hard to follow the circuit diagram.

Would you share the fritzing file, so i can figure out which wires (of same color) go over each other and which should be merged?

I would appreciate it immensely.

Thanks so much for your reply. Although I’ve been 3D printing for a few years now, I’m still new to the DIY side of things and familiarizing myself with the components. That’s why this project is so exciting, a huge opportunity to learn and overcome challenges.

These Amazon listings are a lot more dynamic than I anticipated sorry. This kit was nice and cheap, but really all you need from it is 8 LM8UU Linear Bearing, a good length of G2 timing belt, and the 20T Timing Pulley that goes on the steppers. These are all *very* standard in the world of 3D printing and very easy to find a bazillion other listing for, in kits or individually.

I’m done printing parts and am working through the list, preparing to order items. The part ‘belt, stepper gear, lm8uu’ (https://www.amazon.com/KINGPRINT-Printer-Reprap-Bearing-Coupler/dp/B07BMNDDDL) is no longer available, is there an alternate you might recommend? Or individual parts vs a kit?

I fixed the link, sorry about that. WordPress gets a little finicky when editing such a large page :).

Interesting, so the values don’t necessarily map to real world measurements but in plotter-space you have a normalized distance to use as the reference. That makes sense and definitely not a bug, just a bad assumption on my part. Maybe the solution is to tweak the UI to indicate “hey these numbers aren’t mm”.

The issue I was hitting that lead me to look into it was that my text/image–>SVG–>pcode pipeline includes actual physical dimensions of the resulting SVG, and when I dropped the pcode into the UI the resulting text/image wouldn’t be scaled properly, or at least it didn’t appear to be scaled properly. If I converted a 100mm x 100mm image to pcode I wouldn’t necessarily get a 100mm x 100mm image back out and now I see why: 1mm != 1 plotter unit.

For my own sanity I needed to map real world coordinates to robot coords, and with my patch in place the plotter units displayed in the UI after calibration match the real world dimensions of my work surface. Granted, I haven’t exercised every code path so it’s entirely likely that I’ve broken something somewhere else, but so far it’s working exactly as I would expect.

Scott, I don’t believe it’s a bug, but it’s definitely a funny decision, and it likely arose from historical code when I was deving early prototypes. What’s going on here is that I want the plotter to always have 100 units. It’s arbitrary, but you could have a big plotter, or a small one, or a gondola plotter and they’d all have 100 units to address. It makes it easier to conceptualize as a human (and to explain to others, I do teach with these). Now of course, more often than not, the plotter was calibrated in the shape of a rectangle, and so I’m setting one dimension to 100 and computing the ratio using the steps for what the other dimension should be. The steps aren’t related to the units you get, they only serve to give you a ratio for an arbitrary unit that really likes 100. As soon as you calibrate, this should be reflected on the web interface and the units will update to what was computed (and the shape of the drawing area will change).

I’m not sure what would happen if you set canvas_max_x and canvas_max_y the way you are. It might just work, but you may have other issues. For example the code I wrote to convert GCode to PCode might have an assumption of 100. Maybe not, I don’t remember off the top of my head.

Thank you for digging in and reporting this. It’s worth mentioning I will soon go through all this code and refactor it some. I’ve been in touch with an organization that’s using PlottyBot in education and it’s made me want to spiffy up this code some. That and I have a couple of other projects that will likely use the same stack so it’s worth the effort :).

Sorry for my late response.

Does markdown work here?

“`python
if canvas_max_y_steps>canvas_max_x_steps:
canvas_max_x = 100.0
canvas_max_y = 100.0*(float(canvas_max_y_steps)/float(canvas_max_x_steps))
elif canvas_max_x_steps>canvas_max_y_steps:
canvas_max_y = 100.0
canvas_max_x = 100.0*(float(canvas_max_x_steps)/float(canvas_max_y_steps))
else:
canvas_max_x = 100.0
canvas_max_y = 100.0
“`

I’m not sure why the max dimensions should be coupled like that; X and Y dimensions are independent of each other, and why set one to a static value of 100? Also max_ should be a function of `steps_per_cm`, right? I’ve changed mine to this (I don’t think the gondola param is supposed to be used in a tabletop setup based on what I’ve seen in the code but it makes sense mathematically):

“`python
canvas_max_y = canvas_max_y_steps / gondola_steps_per_cm * 10 # x10 to get mm
canvas_max_x = canvas_max_x_steps / gondola_steps_per_cm * 10
“`

and when calibrating on a page of known size it matches my expectations.

That’s exactly right.