top

A new test rig

Post new topic Reply to topic FizzX.org Forum Index | Steorn Technology Two: Permanent Magnet Motor (Only Permanent Magnets) Goto page 1, 2  Next   Page 1 of 2

Sun Jan 07, 2007 6:00 pm PostPost subject: A new test rig
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

Those of you who follow the Steorn forums closely may have read Goofy's thread here...

http://www.steorn.net/forum/comments.php?DiscussionID=36611&page=4#Comment_1237941

In it Goofy has put forward some excellent ideas regarding the mystery rotor / stator configuration on the Steorn toy and the effect in general based upon the Kinetica thread's viscosity (lag) discussion.

Now that some real ideas are floating around that could be tested i have decided to pick up my previous attempt at building a rig to test them. The new rig however, is not going to be as complex as my previous concept drawings suggested and will involved a simpler way of measuring results.

It involves using mostly hardware and sensors already at my disposal including 24v motors and controllers, simple quadrature encoders, RS232 attached ammeter and a single basic rotor shaft / stator mount.

When i have more details and pictures i will be sure to update this thread, probably mid-week. If i have time to draw up a proper set of specifications tomorrow, i will post them in the evening (UK GMT).

(Hope everyone had a good new years!)
Back to top
View user's profile Send private message
 
Sun Jan 28, 2007 9:54 pm PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

I felt it was time for an update...

My test rig is now taking shape as i have finally got around to putting in some workshop hours. The rig now consists of...

- 24v 350W 2500RPM motor
- Speed controller with PC interface and optical encoder input
- 300CPR shaft angle encoder (optical) - Edit: Just got some new 1250CPR via eBay
- Data logging unit
- 1x Current sensor
- 1x Voltage sensor

The motor controller is going to provide two usefull functions. Firstly it will report current RPM and shaft angle for data logging. Second it will be able to either maintain a constant RPM (regardless of torque induced by stator) or alternatively turn the motor into a high torque servo motor for static tests.

The rig currently has a wooden base for mounting electronics, and a raised aluminium surface on which the motor, shaft, bearing mounts and stator will be located.

I have also started work on some software which interrogates the motor controller and current / voltage sensors for data logging.

Hopefully i will be able to post some pics soon. Also hope to get some more work done in the evenings this week!


Last edited by avid_engineer on Sun Feb 11, 2007 12:38 am; edited 1 time in total
Back to top
View user's profile Send private message
 
Sun Feb 11, 2007 12:36 am PostPost subject: Pics
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

Finally made enough progress to make pics worthwhile, and here they are...

Sorry i havn't got more details on the design, most of my ideas are still in my head but are slowly being realised. If i have time i will post some spreadsheets i made for calculating interaction speed from rotor diameter and RPM. Also got some sheets for working out if my quadrature encoder will handle the RPM ok Smile

The last pic just shows what magnets i intend to use for the stator when testing the '(not so) Goofy Theory'. 1x N38 NdFeB and 1x N42 NdFeB both 12mmx12mmx3mm. N38 cylindrical NdFeB for rotor mounting. I intend to vary saturation with heat if necessary and perhaps try other metals too (soft iron?).

Still quite a way from completion however. Ideas and constructive critisism welcome Very Happy

http://www.fictionary.co.uk/images/rig/new/rig_shaft_motor_encoder.jpg
http://www.fictionary.co.uk/images/rig/new/rig_overview.jpg
http://www.fictionary.co.uk/images/rig/new/ndfeb_stator_rotor.jpg
Back to top
View user's profile Send private message
 
Sun Feb 11, 2007 4:42 pm PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

Started working on the rotor today, it is 102mm in diameter (i was a bit lazy on the lathe) which at 2500rpm will move the rotor magnet past the stator in approximately 749s.

Rotor still needs a bit of work, no magnets mounted yet. Here are a couple more pics...

http://www.fictionary.co.uk/images/rig/new/rotor_close.jpg
http://www.fictionary.co.uk/images/rig/new/rotor_side.jpg
Back to top
View user's profile Send private message
 
Sun Feb 11, 2007 4:51 pm PostPost subject:
clovis ray20
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 81
Location: oklahoma, usa

Reply with quote

OK, AE
looking good is that a torque sensor behind the little square block wall on the end.

_________________
if you want to feel rich, count up the things you own that money want buy.
Back to top
View user's profile Send private message
 
Sun Feb 11, 2007 5:55 pm PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

It's a quadrature encoder for measuring angle and RPM. The encoder is attached to the motor controller, which is in turn connected to the PC for data logging.

The encoder produces 5000 pulses per revolution, the software counts them and calculates the shaft angle and RPM on the fly.

The rig is not intended to perform the 'static' tests that the Steorn test rigs do with torque sensors. Although it was my original intention to measure torque the sensors just cost way to much!

So instead, i will be data logging power consumption of the motor when turning the rotor. At this stage i am really just experimenting, and learning a lot along the way. I am hoping that when introducing magnets to the stator, there will be some observable changes in the motors power consumption at varying RPM's.

Another interesting idea would be to turn the setup into a high torque servo motor, write some software to operate it and perform slow magnetic interactions, again measuring power consumption of the motor to hold position when the rotor is under attraction or repulsion.
Back to top
View user's profile Send private message
 
Mon Feb 12, 2007 2:26 pm PostPost subject:
clovis ray20
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 81
Location: oklahoma, usa

Reply with quote

A E
great idea,
it could be this was what steron was doing when they found the anomaly in the wind gen. i will be interested in hearing your progress.



_________________
if you want to feel rich, count up the things you own that money want buy.
Back to top
View user's profile Send private message
 
Tue Feb 13, 2007 6:47 pm PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

Thanks for your response clovis, its been very quiet on here lately!

I am hoping that someone might be able to help me out with a simple physics problem regarding some energy/force conversions for my DC motors. Basically what i am trying to do is calculate motor torque at a given point in time from the following known values...

Voltage (V), Current (A), Efficiency (%), Speed (RPM)

I have some data from the motor manufacturer which includes 4 samples for various references, each including the above plus a torque value. Using some formulas in the spreadsheet i have proven that the concept works, as i have calculated the torque and it matches the manufacturers suggestion.

What I am not sure about is how i should interpolate the motors efficiency between samples. Efficiency seems to vary for different power outputs and i need to calculate on the fly.

Spreadsheet and formula references here....

http://www.fictionary.co.uk/images/rig/new/motor_spec.xls
http://www.elec-toolbox.com/Formulas/Motor/mtrform.htm

Motor specification here (slow, be patient)...

http://www.unitemotor.com/unite/en/Products.asp?ClassID=0552414402558322

Although it is not completely necessary for the purpose of my tests, i found it interesting and would like to log as much data as i can during any experiments. Any suggestions appreciated!

Edit: Updated spreadsheet and specification link due to error
Back to top
View user's profile Send private message
 
Wed Feb 14, 2007 3:57 pm PostPost subject:
clovis ray20
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 81
Location: oklahoma, usa

Reply with quote

AE
i wouldn't be able to help you much with your test data.
but i would like to run this by you to see what you think. if you take a metal that is easily saturated move it through a moderately strong field of other mags and when it is fully saturated it is moved into the repulsive field of a strong neo mag . wouldn't that neo be repelled and the saturated metal have it poles reversed by the neo and be repelled by the very mags that it had gained it energy from on it way in, forcing that peace of metal back to it original place.
Idea
_________________
if you want to feel rich, count up the things you own that money want buy.
Back to top
View user's profile Send private message
 
Wed Feb 14, 2007 4:02 pm PostPost subject:
TylerD1
Contributor
Contributor


Joined: 28 Oct 2006
Posts: 15

Reply with quote

avid_engineer wrote:
What I am not sure about is how i should interpolate the motors efficiency between samples. Efficiency seems to vary for different power outputs and i need to calculate on the fly.

Looking over the curves on the manufacturer's site and after doing some trendline fitting in Excel with the values they give, it looks like the Pin can be modeled with a linear equation and the Pout can be modeled with a polynomial equation. The R^2 value for the linear (for Pin) is 0.99999889 and the R^2 value for the polynomial (for Pout) is 0.99999995. Comparing the values given by the modeled equations versus the actual values for efficiency, it looks like it's about +/- 0.1% accurate (i.e. 24.56% real efficiency versus 24.66% calculated). This is using the speed in rpm as the input for the equations. It may be possible that by using the voltage or current as the input, the accuracy could be improved. I've listed the equations for the trendlines that Excel came up with for Pin and Pout below:

Code:
Pout = (-0.00019841 * speedinrpm * speedinrpm) + (0.65168550 * speedinrpm) + 11.97857321

Pin = (-0.63518337 * speedinrpm) + 2131.93012326

efficiency = Pout/Pin

efficiency = ((-0.00019841 * speedinrpm * speedinrpm) + (0.65168550 * speedinrpm) + 11.97857321)/((-0.63518337 * speedinrpm) + 2131.93012326)

efficiencyinpercent = efficiency * 100

The equation doesn't work (i.e. <0% efficiency) if the rpm goes over 3302, so as long as that is checked for I think it's the best way to go about interpolating for efficiency.
Back to top
View user's profile Send private message
 
Wed Feb 14, 2007 5:33 pm PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

@Clovis:

In order to understand the interaction more we would need someone with a little more experience in the theoretical stuff that we see on the 'interesting' threads on Steorn.com

As far as i can see it depends entirely on the viscosity of the material which, when known means you could run a rig of specific RPM and rotor radius. The rigs RPM and rotor would need to be calibrated to the materials used in order to achieve the optimal times involved in charging and discharging of the material used. Sean has already stated during the google spread sheet session that this is the case (ive posted the transcript somewhere on here).

Anyway, i'd like to try these sorts of ideas on my rig. I feel i need to make a real world observation or two to better understand what is happening.
Back to top
View user's profile Send private message
 
Wed Feb 14, 2007 6:15 pm PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

@TylerD1:

A huge thank you for taking the time to help with the math! I got excited when reading your post from work Smile

I have extended my spreadsheet to add predicted efficiency for RPM as per your suggestion, then using the same torque equation i used previously, added the finishing touch.

When comparing the resulting graph to the one on the manufacturers site there are some problems.

I'm gunna ponder over it for a while in case ive made some silly mistakes (been a long day) but i've also uploaded it if your interested in taking a peek...

http://www.fictionary.co.uk/images/rig/new/motor_spec2.xls
Back to top
View user's profile Send private message
 
Thu Feb 15, 2007 12:21 am PostPost subject:
TylerD1
Contributor
Contributor


Joined: 28 Oct 2006
Posts: 15

Reply with quote

No problem, I'm glad I can help in some way toward getting the test rig going. I downloaded the new Excel spreadsheet and looked over the formulas and numbers, and it looks like everything is the way it should be. I then compared the manufacturer's graphs with the projected data and found that most of the data has a very close match, but the same ranges have to be used that the manufacturer chose when they made their graph (0 to about 1.5 N*m Torque for the X axis cutoff on displaying data, but 1.8 for the end of the x axis). I tried to match all of the variables up with their respective lines on the manufacturer's graph (only Pin and Pout seem to actually have labels Rolling Eyes ). The only line I didn't identify below is the nearly constant line which seems to be voltage (varying by 0.05 Volts in the values given). Below are the screen captures of the comparisons, and an overlay of all the graphs on top of the manufacturer's graph.

Graph of Pin and Pout

Graph of Current

Graph of RPM

Graph of Efficiency in % (I had to guess this range in the y axis was 0 to 100 since it doesn't seem to be listed)

Overlay of Excel graphs and manufacturer's graph

The overlay seems to show a good fit except for current, but I*V doesn't seem to equal Pin exactly from the manufacturer's numbers for some reason (which could be why this doesn't line up too well). Also I'm not too sure how the Torque values past 1.32 N*m will match up to reality since they list that as the "max torque point" (but they still show values past 1.32 on their graph).
Back to top
View user's profile Send private message
 
Thu Feb 15, 2007 10:16 am PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

Tyler, thanks for taking another look. Your right! the data does seem to fit and i should've spent a bit longer playing with your figures last night.

It would indeed be interesting to see how the predictions fit real life efficiency measurements. I have emailed the manufacturers to see if they can provide any more data, not sure how successfull i will be though.

As it stands i think the figures are pretty good. Unless the manufacturer provides us with extra data, we will just have to expect a small margin of error. I dont think greater than 3300 RPM accuracy will be a problem, since the rig seems to max out at 3000 RPM at the moment anyway (thats without magnetic interaction).

Looking good... I hope to spend some more time on the project this weekend, and throughout next week. The next stage is to hook up the Volt / Amp data logging unit and see if any of this makes sense in reality Very Happy

Edit: btw, the overlay is looking great
Back to top
View user's profile Send private message
 
Thu Feb 15, 2007 5:22 pm PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

Good news! I received a larger set of test data from the manufacturer which includes 100 samples. The best part is that the data fits the formulas very well Smile

The new data covers efficiency measurements from 2500-3200RPM (approx) so should provide all the information needed. I've uploaded another spreadsheet with the new data and some profile graphs here...

http://www.fictionary.co.uk/images/rig/new/motor_spec3.xls

Now for some experimentation to see these figures in practise. I've also been trying to grasp how varying the voltage (and hence Pin) will effect torque. In the test data, torque and Pin are proportional to one another but the voltage is fixed. So would changing Pin by varying voltage produce the same results? I guess so but want to experiment with it and find out for sure.
Back to top
View user's profile Send private message
 
Thu Feb 15, 2007 6:06 pm PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

I just picked up two usefull ideas while posting on the Steorn forum...

1) What if the rig could include a Piezo force sensor (as inspired by Photon) fixed to the stator mounting. The angle encoder i am using is very accurate indeed, it can pinpoint the current shaft angle to within 0.072 degrees. Force could be measured during approach and withdrawal of the rotor magnets.

Reference: http://www.steorn.com/forum/comments.php?DiscussionID=42891&page=7#Item_5

2) Just found a forum post in which Sean states his best guess at the lag time of 'transformer core iron' to be circa 10ms. Interesting and encouraging for testing without having a 12K RPM rig at your disposal!

Reference: http://www.steorn.com/forum/comments.php?DiscussionID=36961&page=5#Item_2


Edit: Cant stop thinking about this stuff lately, think i need a few beers at the weekend to calm down!
Back to top
View user's profile Send private message
 
Thu Feb 15, 2007 7:58 pm PostPost subject: Force sensors
GregL
Contributor
Contributor


Joined: 11 Dec 2006
Posts: 12
Location: Hampshire, UK

Reply with quote

Avid,
If you can manage a force sensor at BOTH ends, then I suspect you will find the two force profiles will be different. I even managed to get Sean at Steorn to admit I had a point - but he said his rig was already over- sensored.

If Sean cannot explain where the energy disappears to, or comes from, then finding the forces at both ends should help to pinpoint it.
_________________
Greg Leonard
Back to top
View user's profile Send private message Send e-mail
 
Thu Feb 15, 2007 8:29 pm PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

GregL,

By 'both' ends, i presume you mean one on the stator magnet and one on the rotor magnet? Maybe i've misunderstood, but if not im having a hard time imagining how i could acheive it on a 2500-3000RPM rotor.

Could you elabourate at all?

Perhaps this is more suited to the air-coil tests that Photon and Pinestone did. Not sure anyone had time or equipment to perform those tests as i presume you would need a 4 channel oscilloscope to do it.

Agreed, it would be interesting though!
Back to top
View user's profile Send private message
 
Sat Feb 17, 2007 2:26 pm PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

Phew, writing multi-threaded time critical software is tougher than i expected. Hope to have some code working and my data logger hooked up by the end of the day Very Happy

Coffee...
Back to top
View user's profile Send private message
 
Sun Feb 18, 2007 10:33 pm PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

Wow, managed to get the software doing something usefull after a lot of battling with time critical coding in WinblozeXP.

Only got the shaft encoder data readings so far, will work on the power consumption data aquisition this week - shouldnt be too hard now the framework is in place.

I've produced a set of data sample's to test the shaft encoder. Seems to be working but there is a small issue i need to resolve and could really use some advice...

The spreadsheet i compiled calculates RPM from encoder counts per sample timeframe (see formulas). Although it seems to work, the RPM fluctuates a lot. Now im guessing this is either some problem with the timing in the software or its just the mechanical 'profile' of the rig.

Anyone got any experience with this? Should i focus on hardware or software lol. After 2 software re-writes and 'consistent' fluctuation im guessing its hardware normality.

Sample data (2 sheets):
http://www.fictionary.co.uk/images/rig/new/beta_data.xls

GIF (for those without excel):
http://www.fictionary.co.uk/images/rig/new/beta_data.gif

Edit: The large deviations on the graphs are me putting friction on the rotor, intended Smile
Back to top
View user's profile Send private message
 
Tue Feb 20, 2007 4:51 pm PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

Once again, i need the help of someone with a little knowledge which i dont have Laughing

This time its with the electronics, and a problem which i somehow managed to overlook. The DC motor controller i am using provides a pulse width modulation to vary speed, so rather than simply adjusting the voltage applied to the motor, it pulses 24v rapidly.

Problem is that when using the data logging unit to measure power consumption the voltage reading is screwed. It is has a sample rate of 20ms and the readings vary wildly, even if you average them over say 30 seconds you get a different result every run. While accuracy will be a problem which requires electronics knowledge and/or money to solve, it appears that consistency might be the way forward.... when i measure the output across the motor supply with a simple voltmeter i get a reading which not only looks reasonable but it is also consistent between runs.

So my question is this... how does the voltmeter achieve this 'average' reading? and would it be possible to somehow smooth the PWM voltage between the supply and my 20ms sensor?

Hope we have some electronics guru's on board here! Anyone up to this?
Back to top
View user's profile Send private message
 
Tue Feb 20, 2007 10:25 pm PostPost subject:
TylerD1
Contributor
Contributor


Joined: 28 Oct 2006
Posts: 15

Reply with quote

avid_engineer wrote:
So my question is this... how does the voltmeter achieve this 'average' reading?

According to this website, the voltmeter is most likely showing the RMS (Root Mean Square) Voltage which would explain why it is fairly smooth with its reading.

avid_engineer wrote:
and would it be possible to somehow smooth the PWM voltage between the supply and my 20ms sensor?

After some research, it looks like the easiest way to "demodulate" a PWM voltage is to use a lowpass filter (the Wikipedia article has a good schematic). This website mentions it as a good way to lessen LED flickering (in the "LED dimming" section) when using a PWM voltage source. I ran a few checks just to make sure that such a filter will actually attenuate to the average voltage (and not to zero) using the free version of this program (it doesn't allow certain settings to be changed, but it was enough to check the concept at least). In order to average out the signal the most, the RC time constant (Resistance * Capacitance) should be as high as possible. This causes the cutoff frequency (1/(2 * pi * RC)) to be very low. The lower the cutoff frequency, the faster the signal is reduced. The main drawback that I can see with this is that the filtered voltage will vary less for higher PWM frequencies (so higher PWM frequencies could be read more accurately than the lower ones), but it's a simple circuit that could be sufficient. Below are 2 screenshots from the program showing a square wave (with some rise and fall times) in blue and the filtered version in black.

This is one possible output.

This is with a cutoff frequency 1/1000th of the cutoff frequency from the previous output (from kHz to Hz).

Both of the pictures show that the signal is attenuating to its average value (10V amplitude, 5V average). As far as I know there shouldn't be any side effects of using a high resistance resistor and large capacitance capacitor for the lowpass filter, but it may be best to try it with components that are already available to make sure it works okay before finding larger value components.

Also, I was seeing a fair amount of variance in a signal I was reading awhile back (using a 12-bit ADC). The signal was coming from a Hall Effect sensor and would fluctuate +/- ~7.5 mV no matter where it was put. I could get a constant signal from the ADC when feeding the reference voltages back in as inputs, so I'm guessing the Hall Effect sensor was causing the fluctuations (the data sheet said the accuracy was supposed to be a fraction of a mV though). In the beta_data.xls file it looks like the RPM is very sensitive to the number of milliseconds between measurements, so the resolution of the time counter could be one of the main causes of the fluctuations of the RPM. The error rate for the optical encoder seems to be typically 3 degrees per rotation (5.5 maximum), which could also be contributing to the fluctuations.
Back to top
View user's profile Send private message
 
Wed Feb 21, 2007 12:34 pm PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

Tyler, thanks again! glad you're here to share your experience as i probably would have spent forever figuring out what the hell i was doing with this one. lol

I checked out the links you posted, some interesting bits and peices but i think ive settled on one filter schematic on your second link here...

http://www.tigoe.net/pcomp/analogout.shtml

Intrestingly the second schematic (near the bottom under 'wiring') on that page appears to do exactly what i was hoping for, even though it is intended as an audio filter Smile

Here's a simulation of the circuit in action with 'virtual' scope probes showing the output. 16kHz DC source is the motor speed controller output (half power).

http://www.fictionary.co.uk/images/rig/new/pwm_smooth_circuit.gif

Im gunna try and salvage some capacitors from somewhere today and give it a go. Worst case scenario ill have to wait until next week and get some from work.

Regarding the RPM / timing issue - i think from what you've said its a good possibility that the software is still to blame. I guess i'll have to sit down and check all the code again to figure it out Rolling Eyes
Back to top
View user's profile Send private message
 
Wed Feb 21, 2007 11:14 pm PostPost subject:
TylerD1
Contributor
Contributor


Joined: 28 Oct 2006
Posts: 15

Reply with quote

I looked over the distribution of the counter data from the Excel file, and (assuming the RPM is fairly constant in the parts where no friction was applied) it seems like something is delaying the data somewhat randomly which causes the time to fluctuate for each sampling. Below is a link to a chart of the stable RPM pulse counts with the samples that had 20 ms for the time difference seperated (by symbol) from the 21 ms time difference samples. The 20 and 21 ms samples seem to be mixed very well in the range, and I would expect to see more of a clumping toward the bottom for the 20 ms and the top for the 21 ms samples (since they would've had more time to record pulses and, therefore, the pulse counter would've been higher).

Plot from Excel showing pulse counter distribution for 20 and 21 ms time differences

So it would seem a better source of time would be needed to improve the accuracy of the data -- a source most likely outside of the computer that would come in at the same time as the pulse counter data. Looking at the pictures of the rig, it looks like the pulse counter was probably retrieved from the Roboteq controller via the RS-232 interface using a query command. According to the user manual for this optical encoder there is a way to have it return a calculated speed value (page 127, "Using the Encoder to Measure Speed"). First, the time base would have to be set (depending on the maximum RPM that the speed measurement could measure) (pages 131-132, "Modify Timebase Register"), then the speed could be read (page 130, "Read Speed"). The speed would be returned as a number from 0 to 127 (for forward motion) which would still have some inaccuracy, but should be more accurate than using the Windows time source (if that's what's currently being used). Below are some estimated resolutions:

@ 550 RPM
4.33 RPM resolution
i.e. 545.67, 550

@ 1500 RPM
11.81 RPM resolution
i.e. 1488.19, 1500

@ 3000 RPM
23.62 RPM resolution
i.e. 2976.38, 3000

In the Excel data, the RPM seems to range about 30 RPM during the time where no friction was being applied (@ about 535 RPM). The main issue that comes up with this is that the formula used in the manual doesn't match the values that show up in the screenshot on the bottom of this page (even after swapping around PPR, CPR, and other parts of the equation), so some checking and testing may be needed to determine the correct equation for setting the timebase (hopefully the screenshot is wrong). I imagine the code for this would go something like:
Code:
< set ppr, etc >

< modify timebase parameter to set "max RPM" for speed calculator >
< (assuming the use of Encoder 1) >

^A2 05

< run motor >

< read speed >

?K

Anything in between < > is just a comment, and only 2 commands are actually listed (modify the timebase and read the speed). The timebase seems to be in increments of 128us, specified by 2 hex characters (0 to 32.768 ms). Using ^A2 05 should set the timebase to 640us which should set the max RPM measured to 595.3125 (which should be a good fit for the speed the rotor was moving in the Excel file).
Back to top
View user's profile Send private message
 
Fri Feb 23, 2007 4:44 pm PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

Tyler,

Im going to take your advice and try to get the Roboteq controller to do the speed calculation for me. It was a nightmare getting windows to accurately determine time intervals and with all the hardware IO to take care of at the same time it makes sense to offload this task to the controller.

I did try previously to get this working using the test software that ships with the controller, but had problems. The software did not initially make a lot of sense to me. The manual screenshot depicts setting up Time Base @ CPR, where as in the actual software i got the label is PPR. How does the software calculate max RPM? i've no idea but entering time base 5 and PPR 5000 gives a max of 248RPM, where as CPR of 1250 give me 992RPM. 1 Cycle = 4 Pulses right?

I need to re-read your post again, in detail, and refer to the encoder manual again to try and get this straight in my head.

In the mean time, i have built the voltage smoothing circuitry and it seems to be working well! I have logged the data to a spreadsheet with graph, but im having second thoughts about the current measurements too Sad

Wonder if i could take the measurements between the battery and controller instead?? and therefore measure the power consumption of the rig as a whole (@24v approx) rather than between the motor and controller.

http://www.fictionary.co.uk/images/rig/new/power_consumption1.xls
Back to top
View user's profile Send private message
 
Fri Feb 23, 2007 5:24 pm PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

Just to clarify, this is why im confused...

http://www.fictionary.co.uk/images/rig/new/roborun_bug.jpg

Now check those Time Base @ PPR against the ones in the encoder manual (page 16) here...

http://www.active-robots.com/products/motorcon/roboteq/ax2550/encodermodule.pdf

I've entered the same values and the software has calculated different max RPM's than the manual indicates. Personally i think their software is buggy. When the rig is working again (shaft needs some work) im gunna test it with my own software using the formula on page 9 of that manual.

According to my calculations, by entering a time base of 128us and a PPR of 5000, i should be able to measure from 23RPM up to 2976RPM which fits my requirements quite nicely. Excel Sheet here...

http://www.fictionary.co.uk/images/rig/new/calc_timebase.xls

Edit:

Just been reading the manual over again, and the formula on page 3 seems to suggest the controller will only operate up to 750RPM with a 5000PPR sensor. If this is the case though, how come the counter still seems accurate up to 3000RPM. Think im gunna call it a day for now Mad

Curious if they are confusing the terms PPR and CPR in the manual and software.
Back to top
View user's profile Send private message
 
Fri Feb 23, 2007 9:06 pm PostPost subject:
babcat
Major Contributor
Major Contributor


Joined: 26 Oct 2006
Posts: 265
Location: USA

Reply with quote

Great work on the test rig Avid-Engineer.
Back to top
View user's profile Send private message
 
Fri Feb 23, 2007 10:54 pm PostPost subject:
TylerD1
Contributor
Contributor


Joined: 28 Oct 2006
Posts: 15

Reply with quote

Good to hear about the smoothing circuitry, the voltage graph looks pretty smooth. As far as I know it shouldn't hurt to try a current measurement for the rig, but I'm guessing it'll probably look very similar (the negative spike at the end looks like the regenerative braking that they mention that should be sending energy back to the battery). It may be possible to filter the signal, but I'm not too sure how fast or accurately the averaged signal from the filter will change and follow the real current.

After combing through the RoboTeq forum and analyzing all of the examples I could find, I think I have a working theory for what is going on. If it is correct, then the manual is wrong and the Roborun program definitely has (at least) 1 bug.

The current working theory is:
    (1) 256us is the smallest time base
    (2) PPR is used all along, never CPR and any CPR label was wrong
    (3) Whatever is typed in for "Time Base" is saved to the time base's register with +1 on versions that have the correct label (i.e. time base shows 18, 19 is actually in the register), could be a very sloppy way to prevent div by zero errors in RoboRun that was added when the label was fixed
    (4) RPM values are truncated
    (5) CPR = 4 * PPR and PPR = CPR/4
And the reasons why:
    (2) On this thread, the last post, there is a mention that the PPR value must be input even though label "CPR" shows up on some versions of the Roborun program
    (1 and 5) On this thread from Feb. 2005, "The maximum time base value is 64. This is equal to a time period of 16ms (64 * 256us)." and "1 PPR (i.e 4 counts per revolution)" in reference to an AX2850.
    (3 and 4) From math below
Using the equations from the manual and the theory, we have:
Code:
Max RPM for the version with the wrong label
timebaseinseconds = inputtimebase * 0.000256
max rpm = 127 * 60 / (ppr * 4 * timebaseinseconds)
max rpm = 7620 / (ppr * 4 * timebaseinseconds)

Max RPM for the version with the correct label and the +1 bug
timebaseinseconds = (inputtimebase + 1) * 0.000256
max rpm = 127 * 60 / (ppr * 4 * timebaseinseconds)
max rpm = 7620 / (ppr * 4 * timebaseinseconds)
And applying the equations to the examples:
* Last post in this thread
Code:
inputtimebase = 18
ppr = 3200

timebaseinseconds = (inputtimebase + 1) * 0.000256 = (18 + 1) * 0.000256 = 0.004864
max rpm = 7620 / (ppr * 4 * timebaseinseconds) = 7620 / (3200 * 4 * 0.004864) = 122.392 RPM

Max RPM shown was 122
* From the screenshot in the encoder manual
Code:
inputtimebase = 16
ppr = 100

timebaseinseconds = inputtimebase * 0.000256 = 16 * 0.000256 = 0.004096
max rpm = 7620 / (ppr * 4 * timebaseinseconds) = 7620 / (100 * 4 * 0.004096) = 4650.879 RPM

Max RPM shown is 4650


Measured Rel Speed = 42
rpm = (speed * 60) / (ppr * 4 * timebaseinseconds) = (42 * 60) / (100 * 4 * 0.004096) = 1538.086 RPM

RPM Equivalent shown is 1538
* From the roborun_bug.jpg screenshot
Code:
inputtimebase = 16
ppr = 100

timebaseinseconds = (inputtimebase + 1) * 0.000256 = (16 + 1) * 0.000256 = 0.004352
max rpm = 7620 / (ppr * 4 * timebaseinseconds) = 7620 / (100 * 4 * 0.004352) = 4377.298 RPM

Max RPM shown was 4377
* From the earlier fizzx.com post
Code:
inputtimebase = 5
ppr = 5000

timebaseinseconds = (inputtimebase + 1) * 0.000256 = (5 + 1) * 0.000256 = 0.001536
max rpm = 7620 / (ppr * 4 * timebaseinseconds) = 7620 / (5000 * 4 * 0.001536) = 248.047 RPM

Max RPM shown was 248



inputtimebase = 5
ppr = 1250

timebaseinseconds = (inputtimebase + 1) * 0.000256 = (5 + 1) * 0.000256 = 0.001536
max rpm = 7620 / (ppr * 4 * timebaseinseconds) = 7620 / (1250 * 4 * 0.001536) = 992.188 RPM

Max RPM shown was 992

Since the forum posts are from a moderator and are more recent (2005) than the manual (2004), I'm guessing that they may be correct and the manual needs to be updated. However, it is possible that the RoboRun program is handling things differently (for whatever reason) and it's still possible to set the timebase register with the smallest timebase being 128us (using the manual command sending method). After this analysis, a few questions come up that could clarify things:

1. What happens when zero is input as the "Time Base" in Roborun? Does the program crash out when trying to run the motor? (0 would be infinite max RPM)
2. What happens when 64 is input as the "Time Base" in Roborun? Does the program crash out when trying to run the motor?
3. What happens when 65 is input as the "Time Base" in Roborun? Does the program crash out when trying to run the motor? (64 is supposed to be the limit)
4. Is it possible to manually check the timebase's register (not using RoboRun) to see what hex code it has after RoboRun sets it?
5. Is the hex value set to what is input to RoboRun plus one (or plus two or three if question 6 is a yes)?
6. When incrementing the time base in RoboRun does the hex code skip values?

5 & 6 would be no if 4 is no. If the answer to 1 is no while 3 is a yes, then that would support the +1 bug part of the theory (especially if 5 is a yes too). If 6 is yes (and probably skipping every other hex character) then it should be possible to run things okay without RoboRun and still get the 128us minimum time base as listed in the manual. That would mean max RPMs ranging from 47625 RPM (timebase = 1, 128us) to 375 RPM (timebase = 127, 16.256ms) if the encoder is 1250 CPR.
Back to top
View user's profile Send private message
 
Fri Feb 23, 2007 11:19 pm PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

Thanks tyler for helping read through this one, once again i need to re-read your post fully and refer to the references to be clear in my understanding.

I thought CPR stood for Cycles per Revolution, where 1 Cycle = 4 Pulses for a quadrature encoder. So therefore 5000 Pulses per Revolution would equal 1250 CPR? (just to clarify).

Looking at the formula for maximum supported frequency this would work out as follows...

Code:
Freq (Hz) = RPM / 60 * PPR * 4

3000 / 60 * 5000 * 4 = 1000000Hz


Now we know this isnt correct because the maximum supported is 250kHz and ive run the motor at 3000RPM with the encoder still accurately reporting. So what if...

Code:
Freq (Hz) = RPM / 60 * CPR * 4

3000 / 60 * 1250 * 4 = 250000Hz


... which is within (just) the 250kHz maximum supported frequency. I know that either me or the Roboteq manual have a conflict in terminology (probably me lol), but the second formula above must be the correct maths.

With regards to the roboteq software being buggy, i appreciate the ground work on the forums! i will have a play tomorrow and see what conclusions i can draw. Almost crapped myself when i skimmed over the code in your post Laughing

Edit:

Just checked out the roborun software. It checks the time base values upon input, and will only let me enter 1-64. Thats version 1.7 and im pretty sure 1.9 (pre-release) is the same. I have a program that lets you debug data sent from applications via serial ports so i should be able to see what the roborun program is actually sending in hex when modifying the time base register.
Back to top
View user's profile Send private message
 
Fri Feb 23, 2007 11:44 pm PostPost subject:
avid_engineer
Regular Contributor
Regular Contributor


Joined: 26 Oct 2006
Posts: 162
Location: Dorset, United Kingdom

Reply with quote

Babcat,

Thanks for the appreciation, good to hear from you... seems like its been a while since you've posted here.

I've gotta hand some credit over to Tyler though, this is totally becoming a joint effort, at least on the theory side Smile

As i said before, i welcome suggestions and contributions. My only concern is how many of us will be turned to the dark side after the first piece of 'private' information is disclosed from Steorn under NDA.

I guess there is no harm in continuing the rig discussion so long as a line is drawn at the magnetics (stator & rotor). Would have to clarify with Seamus or Sean though Confused
Back to top
View user's profile Send private message
 
Post new topic Reply to topic FizzX.org Forum Index | Steorn Technology Two: Permanent Magnet Motor (Only Permanent Magnets)
View previous topic
View next topic
Display posts from previous:   




You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum