Tuesday, January 25, 2011
New SCR holding brackets and firing circuit board
Finally got the new brackets printing. They're far simpler and I'll need another kind for the new circuit board (now that I've got the printed version) as well as the big ass resistors that board uses.
As you can see I've also got new black plastic on a spindle so the makerbot can just feed and build nearly forever.
That machine was a great investment. The objects are cheap (essentially free) and surprisingly durable. I actually put one on the strong table I've also got my milling machine and started hammering it; it doesn't even show damage. I'll do an official tensile strength test at some point.
Code for the part:
frontNeck = 4.5;
rearNeck = 13;
scrWidth = 18.2;//16.8;
scrHeight = 15.5;//14;
scrFitDepth = 20;
boltDiameter = 8;
boltNutWidth = 12.5;//11;
boltHexWidth = 7.2; //tan(pi/6)*boltNutWidth
boltNutHeight = 5;
boltCarrierRadius = 6;
boltToScrDistance = 6;
//fitDepth = 10;
totalLength = 33;//43;
wallThickness = 3;
bedToBoltCenter = 18;
module circuitHolder()
{
difference()
{
union()
{
translate([totalLength/2,0,-bedToBoltCenter/2-scrWidth/4-wallThickness/2+scrWidth/2+wallThickness])
cube([totalLength,scrHeight+2*wallThickness,bedToBoltCenter+scrWidth/2+wallThickness],center=true);
// rotate([0,-90,0]) //bolt
// translate([0,0,-wallThickness/2-boltNutHeight/2])
// cylinder(h=wallThickness+boltNutHeight,r=(boltDiameter/2+boltCarrierRadius),center=true);
//translate([totalLength/2,scrHeight/2+wallThickness/2,-bedToBoltCenter/2+boltCarrierRadius])
// cube([totalLength,wallThickness,bedToBoltCenter+boltCarrierRadius],center=true);
//translate([totalLength/2,-scrHeight/2-wallThickness/2,-bedToBoltCenter/2+boltCarrierRadius])
// cube([totalLength,wallThickness,bedToBoltCenter+boltCarrierRadius],center=true);
}
union()
{
translate([scrFitDepth/2+rearNeck/2+boltNutHeight+wallThickness+boltToScrDistance,scrHeight,0]) //horizontal slots
cube([scrFitDepth+rearNeck/2,scrHeight,rearNeck],center=true);
translate([scrFitDepth/2+rearNeck/2+frontNeck/2+boltNutHeight+wallThickness+boltToScrDistance-2,-scrHeight,0])
cube([scrFitDepth+frontNeck/2,scrHeight,frontNeck],center=true);
translate([0,0,-bedToBoltCenter-2-4]) //Edge to accomidate bend in the holding bar
rotate([0,45,0])
cube(size=[15,300,15],center=true);
translate([totalLength/2+1+boltNutHeight+wallThickness,0,0]) //main SCR holder
cube([totalLength+2,scrHeight,scrWidth],center=true);
rotate([0,-90,0]) //Bolt
cylinder(h=100,r=boltDiameter/2,center=true);
translate([boltNutHeight/2+1/2+wallThickness,0,0])
{
union()
{
rotate([0,0,0])
cube([boltNutHeight+1,boltNutWidth,boltHexWidth],center=true);
rotate([60,0,0])
cube([boltNutHeight+1,boltNutWidth,boltHexWidth],center=true);
rotate([120,0,0])
cube([boltNutHeight+1,boltNutWidth,boltHexWidth],center=true);
}
}//translate
}//removal union
} //difference
}
rotate([0,-90,0])
circuitHolder();
//translate([0,0,-10])
//cube(size=[30,30,20], center=true);
Monday, January 17, 2011
I've finally got it under control
It looks like I've finally got the timing and EMF noise issues under control. This mostly involved moving the firing logic into a computer instead of a single-purpose circuit and putting in shielding.
In the long run adding the computer will mean less wiring as the computer can handle a number of the firing circuits. In the short run, it means the circuits I've been making are a waste. I can use them for the first few stages but as more precision is needed later they can't do the job.
You can see from the graph that as I change the delay (x-axis) I can get a fall in the time between speed measuring gates (y-axis). The fact that this relationship exists implies that I'm actually adding power to the munition again and ass I add and tune more magnets in the future that munition will actually go faster.
On the plus side, when looking at this graph it's clear that the region-of-good-performance is quite wide. The numbers correspond to at least 300us of delay from one end of that region to the other (and it may even be as wide at 600us). At the speed of 50m/s our 4cm round is passing a location in 800us. If we essentially don't care about the position of that round for 300us of that 800us, we're really only using 500us for acceleration. At 4cm in length, this means we should be able to hit 4cm/500us = 80m/s before we see degradation in the performance of each magnet. At the optimistic max of 600us, we could see 200m/s before we begin to see that loss of efficiency.
Next step: Getting this prototype magnet controller to scale up to 13 of them.
Sunday, January 9, 2011
Check it out: I'm not making progress!!
I've made an obvious mistake. I assumed that I'd just need to downsize the caps and the pulse of power would be shorter. I failed to consider the obvious problem that inductance controls the rise time. I'm simply not rising the amperage fast enough. Even smaller caps won't speed things up.
Of course, I discovered this after installing smaller and smaller caps. It'll do about 55m/s but no faster.
You can see the waveforms in the attached pictures. The red one is where the cap is at 600uF. The blue is when I put 2 600s in series to cut their capacitance. Clearly we go from 1ms to 500us as expected.
There are a couple options at this point.
* Lead the munition - Fire well in advance of it's arrival. When it does get there, it'll change the inductance of the coil and hopefully absorb most of the energy in it, cutting the flow of current from the cap.
* Force the SCRs down - Lead the munition but then fire a dump scr to drain the energy when the munition arrives.
* Rebuild the barrel with lower inductance on the later stages - With lower inductance, we'll reach peak amperage faster and I'll still be able to use small caps and fire at the time.
Of course, doing #1 and #2 don't require rebuilding a big portion of the machine so I'll do those first.
Sunday, January 2, 2011
More accelerating magnets
I've added a few more accelerating magnets. As noted before, I can't really enable them because my capacitors are too large. I've also found a new issue.
The main symptom was that the device failed to charge correctly. Specifically it went up to about 60V and would go no further. I'd seen this issue before where the optical sensors were receiving interference from the electromagnetically noisy charging circuit: They'd fire when there was no bullet and the charger would fight to charge them as they discharged. For some reason, that fight was always resolved between about 60V and 90V of charge. My old solution was to add an override that kept all the optical gates as max voltage when charging. This signal was daisy chained just like all the others from charging circuit to charging circuit. Clearly there was something wrong with this signal. Adding my oscilloscope to view it while charging actually made the device charge correctly! Damn quantum circuitry pisses me off every time.
That said, the scope really adds one of two things to a circuit: a big resistor to ground (which can sometimes fix errors where your voltage is floating) and a capacitor between the measured voltage and ground. I assumed that perhaps the daisy chaining of this signal was causing it to not reach the firing gates in time to shut them off before the charger went ballistic making electromagnetic noise (it is a bit of a race, since both at turned on by the same switch trigger). I added a cap between the signal and ground and sure enough the issue went away. For about 30 minutes. Damn it.
Around that time I stared to notice the display wander when the capacitor voltage was low and even didn't turn on at one point. Something was up but I was too dense to discover the real issue until fired the device wearing a shirt. Thing is, the stock of the rifle is where the battery (24V) and, more importantly the rectifier that brings it down to 5V live. It's also steel and in this case it was warm. Reaching inside, I found the heat sink of the 1.5A 5V regulator was piping hot. It was almost certainty producing low voltage.
I stepped out to buy a pair of new 5V regulators that should get me to at least 7.5A:
http://search.digikey.com/scripts/DkSearch/dksus.dll?vendor=0&keywords=576-2254-ND
http://search.digikey.com/scripts/DkSearch/dksus.dll?vendor=0&keywords=LT1083CP-5%23PBF-ND
When I came back, the power supply was cooler and the device was charging correctly again.
Thing is, I didn't think I'd need more power. When all is said and done, the total consumption of 5V power should only be equivalent to a 5ohm resistor (or about 1A of power). That is 13 accelerator gates where each gate has a 200ohm resistor powering the optical sensor and a 100ohm resistor being pulled down on the mosfet that fires the little SCR (which in turn fires the big SCR). I only have like 8 of them installed so I should have even more buffer room. Something is sucking power.
Subscribe to:
Posts (Atom)