PCBs ahead full steam

Posted on by

I’m getting the hang of Eagle, and the design for the first Polarshield is close to being complete.  Matt Venn is charitably helping me by gently pointing out the stupid stuff I’m doing.  Luckily for me, the board is electrically very simple, being an aggregation of other designs rather than something truly original.

The polarshield is be the key piece of the PolargraphSD machine.  It’s a shield with:

  • 2x Stepstick / Pololu A4988 sockets.
  • ITDB02 2×20 pin LCD touchscreen header w/ SD slot.
  • XBee socket.
  • 2x Servo motor connections
  • 4x Endstop connections

Connected to a MEGA, then you can use everything all at once, on-board.  If you don’t have stepsticks yet, then you can stack your existing Adafruit motorshield on the top, and it’ll work.  This includes the touch-screen that will allow fully untethered drawing, and potentially some really nice things eventually.

Connected to an UNO, you can use your old Adafruit shield, or upgrade to use stepsticks.  Using stepsticks frees up the SPI pins on your UNO, so it could, in theory, read an SD card too.  (SD reading isn’t likely to become part of the UNO build for the foreseeable future, but it could be hacked to do it for someone who is determined.)  You definitely can’t use the LCD screen though with the UNO.

The XBee port is accessible to both UNO and MEGA, so if nothing else, this can be used as an XBee breakout that will cooperate with a motorshield.

There are connectors for endstop sensors that will eventually provide for automatic calibration, but there’s no hardware to go with that quite yet.  I’m currently thinking of little magnets attached to the cords and some reed switches or hall effect sensors positioned just above the sprockets.  This needs to be built and thoroughly tested, but I don’t actually think there’s much to it.  It was never planned to be part of the PolargraphSD design, so I’m not rushing into it with only a couple of weeks to go.

The board is largely based on the RAMPS board that folk use in their Repraps, so there’s a handful of other pins broken out by default.  I have tried to be good and group pins together, and the board does have a slight general purpose quality to it for that reason.  Hopefully it should be open to extension without too much hacking.  Pics and plans soon.

7 thoughts on “PCBs ahead full steam”

  1. Thanks for the update, Sandy.

    Have you decided to go with reels for collecting the beaded cord, or go back to counterweighted dangling cord for the default setup? I ask because it seems easiest to make the weights (or something attached to the cord above the weights) trip mechanical switches below the sprockets for homing. Yeah, that would move the home-point to bottom center. I seem to remember discussing this long ago, but I don’t remember your reason for not wanting to do it.

    • The reels I’m using here at home are actually working ok, but the next kits will just dangle like before. Part of the problem is that while the weight of the counterweight can be adjusted for a heavy pen / extra ballast, the springiness of the reel can’t.

      One solution to that is to use a more torquey motor so that it, itself, can carry and hold the weight of the gondola (just like you would with a thread+spools setup), and the spring-loaded takeup reels are just there to keep things tidy rather than to provide a counter-force.

      The main reason to stop the dangle is to make landscape-orientation machines easier.

      It would be nice and easy to have the trigger tripping on the vertical part of the cord run. You would need to tell it what the total length of the cord is, from gondola to trigger, but the trigger could just clip on. That’s a bit simpler than I was thinking, and removes the issue of having to find a trigger that can go partly around the sprocket.

      I was planning on having a magnet a fixed distance away from the gondola (30cm or something), and the machine could use that to calibrate the gondola’s position in it’s own coordinates system.

      Then there would be another magnet on the dangling end that would control the maximum extension. I reckon there’s some clever thing we can do to use it to measure the size of itself somehow too (the distance between the sprockets/sensors), but I need to draw it and scribble to figure that out.

      A lot of this is to do with the idea of making it “automatic”, unattended. So it’s gilding the lily for most of us that run a machine that sits next to us so it’s easy to reset and rehome.

  3. Do you by chance have the firmware for Arduino Mega and RAMPS together yet? I ask because I’m hacking together my own version of your bot, and have several extra RAMPS boards around, and would rather not have to buy the Adafruit motor shield, or blindly poke at your code to get it working with RAMPS. I would be more than happy to provide feedback/testing on it.

    Thanks for the site and project in general,
    Josh

    • Hi Josh, getting there, but not quite yet. There’s a version of the firmware called polargraph_server_mega, and that’s got all the mega functions in it (SD card reading, circular pixels), but it’s still set up to use an adafruit motorshield.

      And there’s a version of the firmware called polargraph_server_serialstepper_itead, and that is set to use serial stepper drivers (a la RAMPS), but it doesn’t have any extra mega-ability. To get it to work, what you’d need to do is change the pins it uses – It’s configured now to use ITead’s serial stepper shield, so there’s a section near the top where the pins are being defined that starts
      // pin outs for the ITEAD motor driver shield
      … [and then there’s 8 lines of pin definitions]

      Replace that little block with

      // pin outs for the RAMPS motor driver shield
      const byte motoraStepPin = A0;
      const byte motoraDirPin = A1;
      const byte motoraEn = 38;

      const byte motorbStepPin = A6;
      const byte motorbDirPin = A7;
      const byte motorbEn = A2;

      and that sets it to use the X and Y motors on the RAMPS board. Now, RAMPS has the enable pin available, so that needs handling too (the ITead shield has the enable pin hardwired to ground so it can’t ever be disabled). It needs to be pulled low to enable the driver, so you’ll also need to add

      pinMode(motoraEn, OUTPUT);
      pinMode(motorbEn, OUTPUT);
      digitalWrite(motoraEn, LOW);
      digitalWrite(motorbEn, LOW);

      to the void setup() procedure in the sketch.

      This compiles ok for me, but I haven’t tested it for actual workingness on a bit of hardware – the actual pins I’m using on the polarshield are different again.

      You can check out the source code from http://code.google.com/p/polargraph/source/browse/#svn%2Fembedded%2Fbranch%2Fpolargraph_server_serialstepper_itead

      Good luck!

  4. You know, it’s amazing what a little bit of understanding can do when hacking on something – lanthan’s polargraph4dirstep base, stared at/modified for several hours, resulted in nothing. Making your changes to your polargraph_server_serialstepper – works immediately. I see now I was using the wrong pin definitions, and didn’t actually set the enable pins to output mode before trying to set them to HIGH… Thank you, once again, sir – I’ll give updates on any issues/bugs with the RAMPS support.

Leave a Reply