Tesla's Charging Circuit and it's Application to Pulse Motors

[TinselKoala]

@Farmhand: I thought about your situation and I think you have several "baseline" conditions to compare, not just two. I would view the reed switch as a mechanical load and the coils and cap as an electrical load on the rotor. So I'd run the rotor with the reed switch in position, but the coils removed and of course the rest of the circuit disconnected. This will give you the straight mechanical power dissipation vs rpm curve, from bearings and windage and the reed flipping around etc. Then you can add the coils physically in position but not yet hooked to the circuit and make another dissipation curve which should be a little steeper because of eddy losses in the coils even when they aren't hooked up. Finally, all up but not yet under power. So really you have three baselines: straight mechanical, mechanical + eddys in the coils, and finally mechanical, eddys plus generating and charging. Then when you flip the switch, you are in a position to say with some confidence just how much of your input applied power is going where: some is going to strictly mechanical moving stuff, some is going to heat from eddys in the coils, and some is being picked off to charge the cap or other load on the generating coils.

[Farmhand]

Now I'm getting excited because I think I'm about to learn something new and very useful. I just hope the calculations needed for a usable result are not beyond me. I have a fairly serious chronic neck issue ( bad fusion from disc removal) and the problem is the pain medications I must take at some times makes my ocular vision not so good, especially with text, and focused concentration is difficult. Luckily I'm not badly afflicted all the time. When I watch the video I get some parts of what he's saying but most of it is like a foreign language. 

Tinsel I get what you're saying and will do. No probs. But there is no reed, it's a photo reflector for the motor so it's not much load from that, I can remove the gen coils and stuff easily enough ect. By the way I got the Allegro hall sensors and they are tiny which surprised me. Something else new to do.

Still haven't made the basic drawing yet. I need to do that soon. However I'll setup to do these tests as well as I can.

Cheers

[Farmhand]

Ok Awesome, It'll take me a while to set up the apparatus so I can do all tests both ways in some kind of a series to keep some order. Once set up the actual tests shouldn't take too long and I ought to be able to fit them onto a video clip that is short enough not to be painful to watch.  That way I can collect the raw data (or at least some runs) on video so any problems might be seen.

The rotor with the "squirrel cage" pulley "add on" weighs about 580 grams, but a lot of the weight is near the shaft, i'll get accurate weights as well. The rotor actually has another smaller squirrel cage on the shaft that the plastic part with the magnets in butts up to for support and spacing as well as some flywheel weight.

MileHigh, with relation to the pulley method you describe I have a question about how much weight am I looking at using, with respect to the construction of the pulley support ect. How much force would I need to get from the weight relative to the rotor, or how fast do I want it to be spun up to for the pulley method ? Is more "spun up rpm" going to be much more accurate, or maybe be a cause of possible error causing problems ?  I might need to turn up a couple of nice sized plastic pulleys to use, they will be handy anyway, I can insert the bearings into the pulley and the weight will be minimal but they'll be strong, a couple of scooter/skate wheels without the hard tyres and some bolts would be perfect, which is probably what I'll make. I did find some pulleys but they all look to weak, no good.

While digging around I found a long stainless steel 8 mm shaft from a printer, it's 430 mm long, which I was looking for for a new motor. I can use the long shaft to have several "sections" along the one solid shaft enabling direct driving of stuff in sections. Printers have lots of handy tinkering stuff in them. 

Couple of posts happened out of sync or order back there, seems like. No matter.

Cheers

[MileHigh]

Farmhand,

To get the most accurate result I think you want to reduce the effects of friction on your measurement.  So my thinking is that a shorter stronger tug on the rotor would be the way to go.  If you can make the pulley wheel that's mounted on the rotor that receives the thread medium or large in diameter that would be preferable.  Also go for a larger weight.  In my mind's eye I envision the drop would take a short time, perhaps less than two seconds.  You might only apply torque to the rotor for 2/3 of a turn.

I will assume that the moment of inertia for the pulley wheel that gives the thread a right-angle bend will be very small relative to the moment of inertia of the rotor and won't affect the measurements.

You also asked about the RPM.  I would think something like five revolutions or more per second might be a good start.  So that's 300 RPM.

If your rotor has a fairly slow spin-down that takes tens of seconds then you figure that the 1-2 second delay before your optical tach "syncs up" to the rotor and gives you a reading will not be too significant.

The fun part is you could if you wanted try different arrangements of weight, drop height, and rotor pulley diameter and evaluate them for yourself.  They should in an ideal case all give you exactly the same result.

Here is the equation again:  I = 2MGh/w²

You will notice that the more energy drain you have from friction, your final "w" will decrease.  Decreasing "w" or angular velocity will artificially increase your measured value for "I," the moment of inertia.  So the more "disturbance" friction you encounter, the more energy you remove from the dropping weight, and the slower the final RPM relative to the ideal RPM.

Final comment, I think that with a good set up, the friction-induced error for the measurement will be very low, less than 1%.  However, it's still fun to contemplate it, and you could make inferences about it by doing multiple runs with different weights, etc.

MileHigh

[Farmhand]

I wasn't able to use the power tools last night, so I'll make time during the day today to make the parts.

Last night i done some run down tests and recorded the results. The run down is not as long as I thought, must be since the second motor coil was added.

To properly weigh the rotor parts and calculate that way would not be so difficult, but still not easy either. It would just be the calculations for solid cylinders of different sized and radial distance from the shaft. and the shaft as a rod. I'm kinda inclined to pull the rotor out and do it, and I guess I will but I'll wait till after I try your method.

The run down times without generator coils and with the load switching happening by cutting the coil power and leaving the motor switches switching are all around 36 to 43 seconds even for very different starting speeds which I find a bit odd. To get the setup to run at the required speed I either adjusted the timing or the pulse width slightly if I had to. The best (or worst) however it goes is 40 seconds rundown from 1800 rpm which required 6.5 Watts to hold at 1800 rpm or 43 seconds from 2000 rpm which required 11.5 Watts to hold at 2000 rpm.

For with the return circuit in place the result is different and that is because when the power is cut to the setup with coil discharge energy going to the load switching the power is cut  but the caps don't dump and just keep the voltage which is double the supply but with the return circuit the energy is released back through the system after every cycle and so without and voltage on the caps transformer action tries to charge them. I haven't found a reliable way to cut the switching off completely and suddenly, the shutdown signal doesn't work as it should for some reason, and only reduces the pulse width to nearly nothing but still there is switching. Cutting the power to the board allows the signal to continue while the cap drains. Pulling the wires to the sensor module allows spurious signals from floating pins.

The results are all very similar from cutting the coil power with the return use, and I can see that when close to stopping the retriggering causes the rotor to stop quicker at the end due to the coils fighting each other, at such a low rpm, the phase is too far out. To get a steady state speed at a predetermined speed with the return circuit in use requires that something is changed as compared to when the load switching is used to deal with the coil discharge energy. I either need to retard the timing a lot or reduce the pulse width which both cause less than optimum running.

Running down from 2000 rpm takes 36 seconds and requires 6.2 Watts to hold at 2000 rpm and at the other extreme I can run the rotor at 2800 rpm with 11.5 watts and it takes 37 seconds to run down. So the return circuit and the transformer action ect. is causing the run down to remain the same regardless of the speed it runs down from. I think it also fudges the run down time with the coil discharges sent to the load switching but to a lesser degree.

To me it is obvious that I cannot get a valid run down test because of all the capacitors and how they are charged from the turning rotor, with or without the switches still switching, the only way I can see would be to disconnect the coils from the capacitors and such so that the cogging drag is all there is. That requires a lot of de-soldering ect.

The same problem will arise with the second method you came up with, the motor sees more drag when the power is cut due to the capacitors and the transformer action as well as the switching of the generated energy at the wrong time when the rotor runs down to low speeds.

All these things are a factor that fudge the results and any calculations as valid as they are will be invalid because of it. When the power is cut to a regular pulse motor the switching stops and there is no transformer action to speak of as I see it, no caps being charged and no energy switched at the wrong time so as to fight the rotation when the rotor runs down to very low speed.

I refuse to do the test as a valid result with a possible built in handicap in relation to the run down behavior. I need to solve that issue or find a way around it first.

I think the best way is to disconnect the coils from the caps and use the MleHigh method with the pulleys and the weight. But it is a major drama to do, I have to de-solder all the connections so that the rotor does not see more drag during run down than it must overcome when running, I think it's vitally important to getting a valid result to meet that requirement.

I can see it's a problem for the tests.

Cheers

This is where the problems arise, all the complicated calculation in the world cant give a valid result if what's happening won't allow the collection of proper raw data, it can't be ignored, that's unscientific,  not recognizing it would be not taking notice of whats going on and ignoring it is just plain ignorance.

I need to find a solution or see good reason why it's not an issue, I can see it is, at least it seems logical that the run down behavior will not give proper raw data.

...