Sunday, August 26, 2012

Updates to TinyG for Android and a hardware controller

I'm working on a new project that should lead to several big improvements to TinyG for Android.  The project overall is to build a simple "operator" control for an existing CNC system, which would be able to send a stored program to a TinyG when the "go" button is pressed.  For this to work correctly, the unit will need to be able to home the CNC system on reset.  It will also need to be able to handle a few additional control inputs/outputs, since in addition to the "standard" gcode-based axes and spindle controls, the unit requires the actuation of some relays.

The Android app comes into play as a programming and control pendant for the operator unit.  The idea here is to have the Android device be able to train/build a new program by providing step-by-step line, arc, and relay controls, and then to have these programs be able to be stored on the Android device and uploaded to the operator system as needed.  During the program mode, the operator control would act like a passthrough.

There are two reusable components that will come out of this project that are of general interest.  The first is the program builder.  The second and in some ways the most important is that I will be implementing the operator control as an Android Accessory.  This will require a shim device between the TinyG and the Android devices (unlike the current Host mode), but has the potential to open the application up to many more Android devices.  While my first cut will only support Android 3.1 and up, a compatibility library should allow support to even earlier devices.

I'm planning to use the Arduino ADK board as the core of the operator control.  It is in effect an integrated Arduino Mega 2560 and a USB shield.  The Arduino programming environment is kind of clunky, but I expect that it will be sufficient for this project.  I probably could have used an Arduino UNO for this project, but the Mega's additional hardware serial ports and additional IOs make it an attractive option.  I'll be combining the ADK board with at least a microSD card breakout to store the programs.  The relay integration is TBD.  Depending on the switching voltages, I may use a relay shield or a standalone relay module.

At the moment I'm just sketching out the design and gathering materials.  I will be documenting progress as I go, including some photos.

In other news, I picked up a Xilinx CPLD development board, and I'm looking forward to learning a bit more about Verilog and CPLD/FPGA programming.  Given the TinyG project, it will probably need to wait for a while.  Lots of fun toys!

Saturday, August 11, 2012

Fun with Old Computers






One of the benefits of getting older is that you can afford the state of the art tech of your childhood.  In my case, I suddenly got the desire to tinker with the 8-bit goodness that is the Tandy Color Computer line that was sold in Radio Shack in the 80's.  I had a Color Computer 2 with standard BASIC.  It had 16k of memory, and used a cassette interface for storage.  It was the first computer I ever owned, and the second one I learned to program.  The first machine I ever "programmed" was an Apple IIe clone in my elementary school.  Of course, programming at the time typically meant copying BASIC programs from magazines like Family Computing.

This go around, I was able to pick up at 128k Color Computer 3 (as well as an original and a coco 2 for good measure!) off Ebay.  This model has composite video output as well as analog RGB out (think CGA!).  Unfortunately, old analog RGB monitors are surprisingly expensive, and so it's composite for now.  I have a Cunning Plan however.  There seem to be some inexpensive conversion devices out there (like this), and if I get sufficiently interested I might pick one up.

My first goal was simply to play a few old games.  In particular, I wanted to play my favorite game at the time, Dungeons of Daggorath.  Unfortunately, my original cartridge was long gone.  While many of these games are still under copyright, you can often find ROM images around the net.  Fortunately for me, this particular game has a very generous developer (Douglas Morgan) who has licensed the game to anyone who wants it.  He even offers the source code!

So now I have the ROM image, and my next challenge is how to get the data into the computer.  Fortunately, I have some raw materials to work with - an old 8k EEPROM, and an ancient cartridge for Personal Finance.  I carefully removed the old ROM from the cartridge, and soldered a socket connecter in the same place.  Unfortunately, the ROMs used at the time were a 24-pin 2364 variant, and the "modern" device I had was a 28-pin 27C64 with a completely different pinout.  With a little searching, I was able to find a pin mapping, and I was able to build an ugly but serviceable wiring harness.

The next step was how to program the EEPROM.  I had an Arduino UNO handy; problem was, it didn't have enough pins to directly address all of the ROM pins.  A little discrete logic to build a 18 bit shift register and I was in business.  I decided to directly wire the data lines so that I could read the chip (8 pins), used clock and serial out (2 more pins) and still needed 3 more output pins for CE, OE, and WE.  I ended up putting OE and WE pins on the shift register, and leaving CE direct.  One output pin left over!
 
I wrote a simple Arduino sketch to initialize and to read bytes from the serial line and follow the relevant chip timing to push the bits out.  I them wrote a simple Processing sketch to download a binary ROM image to the UNO.  The Arduino sketch is below if you're interested in doing something similar, though it's pretty simple code.










 After that, it was just a matter of popping in the chip, plugging in the "cartridge," and turning it on:


















The Arduino sketch:

const int addrOut = 11;
const int clock = 12;
const int chip_enable = 13;
const int ready = 0; // ANALOG
int value;

void setup() {
  for (int i=2; i <= 13; i++) {
    pinMode(i, OUTPUT);
  }
 
  randomSeed(millis());
 
  digitalWrite(clock, LOW);
  digitalWrite(chip_enable, HIGH); // invert logic
 
  Serial.begin(9600);
}

unsigned int loadAddr(unsigned int addr, boolean WE, boolean OE) {
  unsigned int d = addr;
 
  d &= 0x1fff;
  if (WE)
    d |= 0x8000;
  if (OE)
    d |= 0x4000;
 
  shiftOut(addrOut, clock, MSBFIRST, (d & 0xff00) >> 8);
  shiftOut(addrOut, clock, MSBFIRST, (d & 0x00ff));
}

void readEeprom() {
  unsigned int addr = 0;
  byte value;
  int pcount;
 
  for (int i=2; i < 10; i++) {
    pinMode(i, INPUT);
  }
 
  pcount = 0;
  while (addr <= 0x1fff) {
    value = 0;
    if (pcount == 0) {
      Serial.print("\nAddress: ");
      Serial.print(addr, 16);
      Serial.print(" : ");
    }
    loadAddr(addr, true, false);
    digitalWrite(chip_enable, LOW);
    for (int i=0; i < 8; i++) {
      value |= (digitalRead(i+2) << i);
    }
    
    Serial.print(value, 16);
    addr++;
    pcount = (pcount+1) % 16;
    digitalWrite(chip_enable, HIGH);
  }
}
void chipClear() {
  loadAddr(0, true, true);
  digitalWrite(chip_enable, LOW);
  loadAddr(0, false, true);
  delay(10);
  loadAddr(0, true, true);
  digitalWrite(chip_enable, HIGH);
}

void writeByte(unsigned int addr, byte b) {
  for (int i=2; i < 10; i++) {
    pinMode(i, OUTPUT);
  }
  loadAddr(addr, false, true);
  digitalWrite(chip_enable, LOW);
  for (int i=0; i < 8; i++) {
    if (b & (1 << i))
      digitalWrite(i+2, HIGH);
    else
      digitalWrite(i+2, LOW);
  }
  digitalWrite(chip_enable, HIGH);
  loadAddr(addr, true, true);
}

void loop() {
  while ((value = Serial.read()) == -1);
  if (value == 'w') {
    for (int i=0; i < 8*1024; i++) {
      while (Serial.available() == 0);
      value = Serial.read();
      writeByte(i, value);
      Serial.write(value);
    }
  } else {
    Serial.println("got something else!");
  }
}


Thursday, July 12, 2012

Social Work Android App



I've been working with some folks at the University at Buffalo School of Social Work to develop a feed reader that's tailored to the needs of social work professionals.  The app itself is built using a nice Android library called FeedGoal, and with a little tweaking we're adding channels that the school will manage to relate to various activities within the school and the disciplines.  Still a work in progress, but the app is up on Google Play for testing.

I'm also working on my todo list of bug fixes and enhancements for TinyG for Android.  In particular, I'd like to do a couple of behind the scenes things to make it more robust in the face of various status changes by moving the persistent objects into their own fragment.  I don't know if that's going to work, but we'll see.  I'm also planning to make it preserve the download filename between screen changes and app restarts, integrating a simplified file browser instead of using the openintents model, improving the throughput of the downloads, and a few other things.

Monday, June 18, 2012

Musical instrument CNC project

I'm taking a break from the Android app for a bit.  It's now to the point where it is functional, and before I go back and fix some of the little bugs, I want to play with it.  This will likely also identify a few more features I'll want to add.

So now I'm working on different CAD/CAM options.  The one that seems the most promising (but not the cheapest) is Rhinoceros and CamBam.  Through educational discounts I can get Rhino for $195, but it's still a good chunk of change.  CamBam and $149 isn't cheap either.  As a software guy, I know I don't want to reimplement Rhino, but for the feature set I need, CamBam might not be necessary.  Other options are PyCAM and HeeksCAM on the free end.

To help make things clearer, I've been using Rhino in eval mode to develop 3D models of objects, and then exporting the profile information for use in the CAM systems.  With CamBam, I find that unless I want to do a simple 3D profile, I end up redrawing some of the features (for example, to build a pocket or for a 2D profile).  I suspect this is just my lack of experience.  I'm spending most of my time in Rhino, since I'm pretty much sold on using it for CAD.


For a simple test, I did a small layout similar to a cake with a domed top, with a small sphere centered on the apex.  I dumped that as an STL, and then generated gcode for a full 3D profile.  This picture is really early in the cycle, but you can see the top surface being cut out, and the small bump that will become the sphere.  I terminated it after it got about 25k out of the 30k lines in the gcode, but if I left it to run it would have cut around the entire edge.  CamBam supports the use of tabs in this case, but I didn't use it.

Next I'm in the process of designing the solid body banjo and a neck.  I have the body layout I want, and no I'm working on the neck heel profile that I want to fit it.  I'm going to spend some more time with CamBam to see if there are clever ways to have it only do a profile cutout along the edge of the body, since the top surface is completely flat.  Using a 3D profile requires a lot of traverses that are incredibly inefficient.  I expect there's a way to do it.

Thursday, June 7, 2012

TinyG for Android v1.3

I've published a new version of both TinyG for Android and TinyG for Android USB Service.  This version cleans up the UI in a huge way, adds much better error checking/notification, and support for gcode downloads.  I'll put up a new video when I have a few minutes, but I was able to use this version to do some real routing last week.  It went through a small (660 line) gcode file without any troubles at all, and I expect it will work with arbitrarily large files since it operates a line at a time.

Let me know if you have any suggestions for improvements.  I have a few in the hopper (long press for a continuous jog for example), but I'm going to be working on CAD designs and bug fixes for a while.  I'm starting to design my solid body banjo prototype.  More on that soon too.

Friday, June 1, 2012

TinyG for Android updates

I'm making good progress on adding some new features, including support for gcode file downloads.  I'm spending a fair amount of time changing the UI to make better use of a tablet-size display where available.  To avoid a lot of duplicated code, this means expanding on the use of Fragments, and moving as much code as possible within them or related support libraries.

I'm also continuing to look at gcode generation options.  So far, CamBam seems to be the most reliable option, but I'm also still trying out HeeksCAM.

Another video when I have time to put together a real demo.

Monday, May 21, 2012

New TinyG for Android app demo

I worked out a few kinks in the app so that it's more robust in the face of bad data, and published a new demo up on youtube.  This demo walks through all of the current features, including connecting through both the USB and network services and looking at the system configuration.



As I mentioned in an earlier post, I'm working on adding additional support for tablet-sized displays and file upload.  In the meantime however, you can go over to my github page to pull down the latest source, and you can get the main app from Google Play.