Thursday, August 6, 2015

xy-ray x-ray scanner

In some previous posts I talked about getting an x-ray head working, reverse engineering an x-ray sensor, and working with LinuxCNC.  In this post I put them all together so that I can take a bunch of x-ray snapshots across an entire PCB.  This allows me to more quickly reverse engineer PCBs.




Problem: with my previous work I can take a PCB x-ray at fairly high resolution (see bond wires like above) but the field of view is pretty small.  The above x-ray doesn't even cover an entire PDIP-40.  How can I see the entire PCB?

Linear stage

Linear stages are great for this sort of project.  As I'm moving on the order of inches they don't necessarily need to be high precision.  I looked around eBay and a few other places and settled on some stages as HSC.  I can't find a picture of the original setup, but something like this:



These had several desirable properties:
  • Around the right scan area I'm looking for
  • Reasonably sturdy to support PCB weight
  • Motors with integrated drivers (MDrive 17Plus).  As a plus they are 3.3V compatible
Not pictured is a Z cam motor that I didn't need for the x-ray setup.  However, this motor was perfect for running early integration tests.   My specific motor model is not listed on the manufacturer's website but seems to be pin compatible with their step/direction models.  As its 3.3V compatible I'm able to directly wire the control signals to a BBB running LinuxCNC.

Next I made the PCB holder.  The Z axis motor mount makes a convenient anchor point to attach accessories.  To actually hold the PCBs I decided to use a PanaVice PCB holder left over from a previous project.  This is a great fit as it nearly wedges into the motor mount and is made out of aluminum which is mostly transparent to x-rays (minimal image impact).  With a little sanding I was able to sandwich it into the motor mount:


And drill some holes to make it secure:



Which then integrates onto the stages:


Mounting the head

Next I need to mount the x-ray head.  Its heavy so this could be a bit challenging.  I was originally thinking of making a t-slot gantry so that it would clear the stages nicely.  It would be a plus if I could adjust the height up and down but not strictly necessary.

Thinking about the z axis, I recalled I had a spare heavy duty z stage.  And guess what?  The x-ray head fits onto it perfectly!


Integrating into the system:


In this configuration the stages can't travel their full range but given the low effort this is a great starting point.  You can also see the sensor in position.

Software

The software development is mostly covered in my previous post.  Here is an early integration test with the pr0nscope GUI I use to control my microscopes:



AXIS would have worked fine but because I was focusing on rsh it was a bit of a pain to switch back and forth.  It may be possible to launch AXIS along side linuxcncrsh but I haven't looked into it.

Notice the slopping wiring going everywhere.  Lets see what we can do about that...

Control system

Onto the control system.  In the above picture you can see an aluminum plate to the left of the stage.  This held the original indexer board that I decided not to use in favor of standardizing on LinuxCNC.  I drilled some holes for standoffs (not super great but sufficient):


And started mounting electronics:



A few boards are on standoffs but I'm DIN rail mounting what I can.

I started routing cables and found that the Y power cable doesn't reach.  After splicing it to extend it:


And then heat shrinking it to prevent it from snagging and hiding the splice:




Going back to the electronics panel, you'll notice the e-stop button to the right.  In production:



Unfortunately I don't have any drills large enough for the button.  My step drill got pretty close but not there.  I thought about putting it on my milling machine / rotary table but decided that since I only needed to shave off a little that probably wasn't the most expedient (notice I didn't say best) option.

Instead we come to "Mr. Safety" on the left.  Although I didn't use a milling machine, I did put an endmill into my rotary tool and mill out the center a bit by hand.  This is a terrible idea and you really shouldn't do this for numerous reasons but it did get the job done.

Following that I finished the button with a coat of Dykem Blue.  It already had some on there from marking holes and I decided it was going to be less work to coat it blue than to remove the layout fluid.

Filling out the control system:



I DIN rail mounted the BBB onto a Phoenix Contact PCB mount by screwing the case into the PCB mount

There are two power rails:
  • 24V for stepper drivers.  It was supposed to be supplied by the DIN rail supply but I am missing a Combicon adapter.  For now an external power supply runs it
  • 5V from the BBB sets a control line in the stepper motors

Like previous systems, a laptop orchestrates the whole thing.   At the core is my pr0ncnc which underwent a major, long overdue code cleanup for this project.

Also like previous setups, the x-ray is powered by two Variacs switched through a DLI WPS-7.

Putting it all together

Viola:



For my first scan I grabbed a scrap HDD PCB in arms length:


And you can find the output files here (TODO: stitch, mapify).  A few sample images:




Safety

This system was a bit harder to shield due to the larger volume.  However, running the system at 60 kV seems to produce negligible radiation leakage even without shielding and gives pretty good copper resolution.  Still, I have lead shielding around the system as an added safety and in case I want to operate at higher voltages.

Industrial units

For comparison, here's an XD7500NT industrial x-ray scanner:





Unlike my system, these allow real time imaging, HDR, and some other cool features.   Still, I'm sure my garage system costs a fraction of what these beasts go for and is considerably more compact.

Summary

The hardware came together pretty quickly and was mostly built over last weekend.  Figuring out how to configure and control the BBB took longer but is a good investment.  The integrated MDrive 17Plus stepper drivers make the system quite compact over my previous control systems.

There are a number of things I can do to improve scan quality but should be good enough for most projects.  The system will get used in the near future for PCB reverse engineering projects.

Got something cool you want scanned?  Drop me a line!

EDIT: looks like you can get small x-ray units at industrial auction for 1k.  Still, this was well under that and was a fun project

LinuxCNC/Machinekit, BBB, and Python

Background

My original computer controlled microscope ran LinuxCNC on an old laptop:


You can see AXIS running on the laptop to the left along with a scan pattern.

Unfortunately, it was difficult to make this system compact and reliable.  Laptops aren't really that great to run real time software because ACPI gets in the way.  Desktops can work but they are bulky and still need to be somewhat carefully selected.  My Sherline mill compromises by using a mini ATX motherboard connected to a laptop.  That way the laptop does all the display, keyboard, and mouse in a compact form factor while running all the real time tasks on a purpose built PC.

But this was still too big and costly to generally deploy.  Instead, I made "pr0ndexer" which runs on inexpensive STM32 dev boards.  The firmware was written in an afternoon and seemed to work well to get the job done.

Or did it?

After a while one of my motors started to slip.  Evidently lack of acceleration was wearing out gears in the linear stage.

Oops.

So I patched up the software with some crude acceleration and production continued to hum along.  But still it was still pretty crusty:
  • Pulses are generated with sleep statements instead of timer ISRs.  Receiving serial characters (or other tasks) messes up the timing
  • Only one axis can be moved at a time

Towards the BBB

While this was happening it was brought to my attention that LinuxCNC had been ported to run on Beagle Bone Black (BBB) by the Machinekit.  At this point though things were working well enough that I decided not to pursue that.

Fast forward to 2015.  I'm building more robots and need to decide what the next control system will look like.  I decided to revisit Machinekit/BBB which I'm just going to loosely call BBB.

For most of these systems I'm moving some number of stages and doing some sort of image capture.  There are two ways the system could be used:
  • Run LinuxCNC on the BBB and also do image capture (ie through the USB port)
  • Use BBB as a remote control drone and run image capture on a laptop
For a variety of small reasons  I decided to continue controlling the setup on laptops and use BBB's as control drones.

linuxcncrsh/emcrsh API

When you start LinuxCNC there are a variety of frontends you can use to interact with it with AXIS probably being the most common.  One alternative is the rsh frontend which launches a sort of telnet command server instead of a GUI.  The developers make no claim that its a robust interface but note that it may be good enough for quick and dirty projects.

Seeming to be the easiest way to use in a drone fashion, I started with this.  I ran into a few snags though:
  • Axis homing takes a long time.  My theory is that this has something to do with the way that poll() works (see later) but I'm not really sure
  • No position feedback: a command is either running or completed
Still, I was able to control things and get running pretty quickly using pyexpect.  Here is my python interface to it.

Python API

Unfortunately while I could get a quick PoC, rsh didn't seem to give enough control for what I wanted to do.  So next I tried the python API which is considerably more powerful.

Although this API is much more complex, it is well documented and I was able to get it working reasonably quickly.  The API is much richer and allowed me to do everything I wanted to (ex: getting position feedback). For example, the Python API is aware of fine points like the target position vs the actual position from servo feedback.

Remote python API

Unfortunately above only works locally (at least as far as I can tell).  To use the BBB from a remote system I decided to use XML-RPC since I've used it before and its pretty easy to use.  I instantiate a linuxcnc object that looks just like the linuxcnc module.  This allows programs written against the normal Python module to nearly seamlessly my remote version.

To make it run smoothly I do the following:
  • Copy LinuxCNC .ini file to BBB (SFTP)
  • Launch LinuxCNC on BBB using .ini file (SSH)
  • Copy XML-RPC server to BBB (SFTP)
  • Launch XML-RPC server on BBB (SSH)
  • Create SSH tunnel from BBB to localhost
  • Connect to BBB using XML-RPC client
I'm using the paramiko API to copy files over and launch remove processes.  Although I'm not using rsh, its still convenient as I can wait for the rsh port to open to know that linuxcnc is ready.  There might be better ways but this was easy and seems to work.

The core linuxcnc remote interface client and server are here.  The wrapper to remotely deploy it can be found here.   Here's an example program using the wrapper.

Polishing

I'm using the  CRAMPS configuration as a base.  This unfortunately has a lot of stuff I don't need and causes it to take a long time to start up.  I've started stripping down the config but there's still a lot to strip out (ex: thermal management).

I'd also like linuxcnc to launch automatically at start up which probably isn't too hard.  I'd also like my config files to get versioned which may just mean I check out the uvscada git repo to the BBB.  This eliminates most of the above steps.

XML-RPC has a lot of overhead: it creates a connection for every function call and XML isn't terribly efficient.  Fortunately I'm not doing anything super performant so this is probably okay.

Applications

I have several new imaging systems coming online.  This project was primary driven by my x-ray scanner:


which I'll do a post on in the near future.  I'm also planning on deploying this to existing systems like pr0nscope and k2scope.

Summary

The Beagle Bone Black is a very compact platform to run LinuxCNC from.  The rsh API is good for very simple remote control applications but you should use the Python API (or C API) if you need better control.  I've provided some wrappers to use the API remotely almost as easily as the local API.

For the amount of work put into this it came out pretty good.  There's still a lot of room for improvement but its mostly better than my pr0ndexer board.  The main disadvantage so far is that the BBB takes several minutes to start up where my board was ready in under a second.  For most of my applications this isn't a big deal.  That said, I'm eventually going to look into ways to cut down startup time.

Wednesday, June 10, 2015

RECON N64 CIC talk

The con is already sold out, but better late than never...

Will be co-presenting a talk on the Nintendo 64 CIC at RECON 2015: https://recon.cx/2015/schedule/

Enjoy the talk and pop by to say hi!

Saturday, May 23, 2015

Dexis/Gendex GXS700 driver released

Source code

Instructions

Run capture.py

Used to create the CBCT and other posts earlier.  I was hoping to release this in exchange for some junk but that didn't pan out.  So after holding onto it for a while decided it was time to let it loose in the world.  Enjoy...

Friday, May 15, 2015

Fruit exploder at Marker's Faire




I'll be blowing up tomatoes, smartphones, and anything else that catches my fancy.   Also someone has offered a brand new Arduino Uno that we are going to raffle off for free (probably at 3:30).  Tentative showtimes at the Cupertinker booth in the main hall:

Saturday
  • 11:30 am
  • 1:30 pm
  • 3:30 pm
  • 5:30 pm
Sunday
  • 4:30 pm

Friday, April 3, 2015

Cone Beam Computed Tomography (CBCT) test shot

I've been playing with a dental x-ray sensor and getting some pretty good results.  Ultimately I'd like it to help reverse engineer PCBs and related security modules.  Here is a shot where you can clearly see bond wires:






This is still relatively early in my testing and I can probably still do a lot more to get better resolution.


With basic imaging working, I'm trying to take it a step further and do CBCT.  Sneak peak at setup:


 I made some test shots into a video but I'm still in the process of trying to stitch them into a proper 3d model.  I'm likely going to use plastimatch and/or RTK.

Once I get that working I'd like to try to laminography ("5DX").  Although I haven't looked too hard, I get the impression there might not be a lot of FOSS software to do this and so might require a bit more effort.

EDIT: slides from a presentation I did

Monday, March 9, 2015

80kV fruit exploding machine

About 5 years ago when I was in college at RPI I used a half ton capacitor bank to blow up apples and other meals.  I'm not in this particular video (stupid test) but this gives you an idea:https://www.youtube.com/watch?v=2EhuHs7IdM0

It was a lot of fun and I've wanted to do something like it again for a while.  I have a large number of ~400V rated pulse capacitors:


that I've used before to blow up wire, small railguns, etc with good success.  However, I also have an 80 kV death capacitor that I've always wanted to use:


The death part is pretty literal:


"WARNING: THE ENERGY STORED IN THIS CAPACITOR IS LETHAL".  Not "may be"...*IS*.  And they are probably right: don't touch it while its live.

But the capacitor is pretty boring without a way to power it.  4 years or so ago I used a 5kV capillary electrophoresis power supply to give it a token charge:


This made a reasonably large snap but, because capacitor energy is 0.5 C V^2 was only 0.4 % of the max energy.  After that it was put into storage and didn't see any use for some time due to lack of a large power supply.  I bought some capacitors and diodes to make a CW multiplier for my neon sign transformer but never built it.

Roll forward to present day.  This capacitor came out of an x-ray (diffraction or crystallography IIRC) system at RPI.  Somewhat related, I've been doing some x-ray work and had a unit fail (more on that in another post).  I opened it up and found I was able to salvage the high voltage (100kV) transformer:


For the following I'm currently only using the left half which seems to give about 60kV DC max.   Worth mentioning I could have grabbed the transformer but it was very heavy/large and left behind.

Started with some spark testing to verify the transformer worked.  The transformer must be submerged in oil to work properly:







About a gallon of oil in there and the box was tipped to one side that it fully covered.  Then I made some arcs:


The gap in the above picture is about 2"

But this is AC and to fully charge the capacitor I need DC.  I still had the original full wave rectifier that powered the capacitor but, for reasons I don't recall, I only have the bare diodes and not a rectifier assembly.  So next step was to assemble them into a rectifier module.  Originally I did a classic rectifier square design:


But then realized this required crossing an output high voltage line over an input source, potentially leading to a breakdown.  So redesigned int in an x pattern so that the polycarbonate sheet provided insulation between the two halves:


Per the labels, AC comes in on the left and DC exits on the right.

Next, we need a trigger.  In the simplest tests its fine to set a spark gap and let it automatically trigger but longer term   In the past I used a pneumatic switch to trigger a spark gap which worked pretty well.  I had some 2" stroke solenoids which aren't ideal (remember I said I could jump 2" above?) but was good for a first test.  Setup:


Note on the right you can see 40kV probe for "low voltage" tests.  The blue silicone tube goes to a compressor on the right.  I simply open up the regulator to close the switch.  I also built a polycarbonate platform that you can see in the above picture.

This system needs a way to safely discharge.  Long term I want an emergency stop, but short term I'm fine with simply bleeding off charge.  My goal is to have the system safely discharged (50V) within about 10 seconds.  I think this didn't work out in the end, but in theory this should be V = e^(-t /(RC)) where:
  • V = 50V
  • t = 10 s
  • R = ?
  • C = 0.25 uF
Solving for R gives you about  5.4M.  That was my original goal, for reasons I don't recall I instead did 800M (too high current draw?).  This discharges to 50V instead in about 185 seconds which still isn't too bad.

Putting it all together, this is what the prototype schematic looked like:


Some artistic license on the schematic: I loosely interchanged electrical paths with pneumatic paths.

Time for results.  The first victim was a galaxy 2 phone donated by a coworker.  Couple minute video of the test process here: https://www.youtube.com/watch?v=Q-sTKhyaM3Y

The phone wasn't blown in half but was a good start: the screen was cracked and burned.  Ultimately the phone succumbed though so I call it a success.

But the goal was to blow up some fruit.  First I tried placing a tomato directly inside the gap: https://www.youtube.com/watch?v=CgCAwcUGMeg&list=UUq3z1paLNFugoH3yTYokMIg

But this didn't work so well: a tomato has a lot of water that serves to nicely absorb the energy.  Next idea: put the electrodes inside the tomato and separate by 0.25".  This focuses the energy into a small space and forms a proper explosion.

This worked great: https://www.youtube.com/watch?v=E4cW6JSh3lc

Mission success!  There is one less tomato in the world.  I also decreased the camera ISO from auto to fixed 400 ISO to get better explosion coverage.  I also upped the frame rate from 30 fps to 60 fps to catch more gore.  I have a 1000 fps Casio that I'll try to use in the near future.

Finally, how to blow the phone in half?  I have a tenative agreement to upgrade the system from 800J to 12-13 kJ.  More to come


(note the ruler for scale)