OpenServo.com Forum Index OpenServo.com
Discussion of the OpenServo project
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

OpenServo Version 3
Goto page 1, 2, 3 ... 17, 18, 19  Next
 
Post new topic   Reply to topic    OpenServo.com Forum Index -> Hardware
View previous topic :: View next topic  
Author Message
Cliff



Joined: 23 Jan 2007
Posts: 150
Location: Saratoga, CA

PostPosted: Thu Mar 01, 2007 4:54 pm    Post subject: OpenServo Version 3 Reply with quote

Hi All,

I have been lurking here for some months and thought that I would try to stir the pot a bit. I have a design that I would like to propose as a basis for OpenServo version 3. A PDF of the design (schematic and preliminary layout) is here: http://homepage.mac.com/cliff_huston/.public/OSX1_Bd.pdf .

My list of improvements include:
Adding a ceramic resonator to run the Atmega168 at 20MHz.

Adding active braking so power is not spent holding in place.

Adding motor back EMF measurement for better speed feedback.

Adding a temperature sensor to prevent servo meltdown.

Changing the connector pin-out, so that the I2C lines have matching grounds for lower bus noise.

Adding an interrupt signal that would be common to all OS3 devices (open drain), so the master can be notified that one of the devices on the bus needs attention. (Multi-masters seems like over kill for this task)

Changing the connector to a 10 pin 2mm connector to get the extra pins needed.

Changing the PCB to a four layer design for better power and ground distribution (and to make the layout possible Smile ).

Some notes on the design:
The I2C lines have been connected to the SPI SCL and MOSI lines, so that the same connector pins can be use both for initial programing (SPI) and for normal communication (I2C). Like wise the MISO line is used for programing and in normal operation, for attention signaling.

In order to get active braking and back EMF measurement, four signals are used to control the FET bridge. The new signals are EN_A and EN_B. To get this board to work with the existing firmware, the firmware will need to be changed to set one or the other high when its matching PWM signal is active. To provide braking, both PWM signals are made low and both EN_A and ENB are brought high, which grounds both sides of the motor.

The measurement of the motor back EMF is done with a simple sample and hold circuit. The scheme goes like this: When moving in a direction, the EN_A signal is brought high, the PWM_A signal is active, but periodically (TBD) the PWM_A goes low for a delay time (TBD), the SMPLn_A signal is made low for a sample time (TBD) to charge C10, the SMPLn_A signal is brought high, the PWM_A is made active again until the next delay and sample period, and the BEMFV signal from C10 is read by the ADC. Through out this process, the EN_A signal is high. To move in the opposite direction, the process is the same as above with the _A's replaced with _B's.

So then, it's now your turn . . .

Is the pin-out for EN_A, EN_B, SMPLn_A and SMPLn_B workable from a software point of view?

Does anybody have a collection of motor data that would put numbers on the TBD's above?

I used the Hitec 'standard' servo dimensions for the board size, are there other 'standard' sizes?

Did I miss a feature that is really needed?

Is the software doable?

Is there something else wrong with this picture?

I would very much welcome any ideas, comments, criticism, or hate mail. Well maybe not the last, but I can live with it. I could send the board out for fabrication today, but I would much rather it include your ideas and suggestions.

Thanks,
Cliff
Back to top
View user's profile Send private message
Cliff



Joined: 23 Jan 2007
Posts: 150
Location: Saratoga, CA

PostPosted: Thu Mar 01, 2007 6:07 pm    Post subject: Reply with quote

Here is a look at my proposed connector for OpenServer version 3:
The datasheet for header is here: http://www.molex.com/pdm_docs/sd/878311020_sd.pdf
The mating connector here: http://www.molex.com/pdm_docs/sd/511101060_sd.pdf
And for the crimp pins here: http://www.molex.com/pdm_docs/sd/503948051_sd.pdf
Back to top
View user's profile Send private message
ginge
Site Admin


Joined: 14 Jan 2006
Posts: 1030
Location: Manchester, UK

PostPosted: Thu Mar 01, 2007 6:15 pm    Post subject: Reply with quote

Cliff,

All I can say is Holy Crap! That is probably the most amazing thing I have seen this year. You certainly are a layout wizard!

I will address all of your points...

20MHZ resonator:- we have tried this before and it didn't work out at the time. It think it is something that is needed on V3 so we can run additional functions.

Back EMF measurement is fantastic. I like it. We have discussed this for v3 and don't think it would be hard to implement programatically.

The temperature sensor is a nice addition!

I am not sure about the connector pinout change at the moment. I will look a little closer over the schematic and see what this will impact. There is also the issue of the new PWM feature and moving that to a suitable pin.
I can't see it being a major problem though. I will ponder this a little more, as we are going through the process of standardising a USB interface. This uses the current OpenServo pinout, and would have to be redesigned if we decided to change.

The Interrupt is something I have added to my OpenServo independently. it works well and is not hard to implement in software. Again, very useful.

2mm Connector for the pinout doesn't seem to be a massive problem. Can you recommend a good connector?

Quote:
So then, it's now your turn . . .


it's all workable from a software point of view. I can't forsee any major implementation problems. I am sure Mike will rise to the challenge.

Do you want motor data from the current OpenServo? I posted a lot of data captured from my OpenServo here:
http://openservo.com/Forums/viewtopic.php?t=138

Servos come in all shapes and sizes. Did you measure your board up against the current CVS schematic? This would be the best way to tell if it is going to fit. No complaints so far and all...

I don't think you missed any features for OpenServo v3. I started comiling the forum requests in no real order here:
http://openservo.com/moin.cgi/Future_Development

I can't see any problems. I will spend a little time looking over your design a little closer.

Great work Cliff. I think it may be a little early to switch entirely to a v3 design, as we are still putting support in place (software and hardware) for the current implementation. You got the ball rolling at least.

I am sure Mike has some comments, and I would be interested in hearing what he thinks about the new pin layout.

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
Cliff



Joined: 23 Jan 2007
Posts: 150
Location: Saratoga, CA

PostPosted: Thu Mar 01, 2007 9:23 pm    Post subject: Reply with quote

Hi Barry,

My connector choice stems from my thinking that there needs to be an OpenServo Bus standard. That is a bus that would use a standard connector and have a standard pin-out, which would serve to connect OpenServos, sensors, encoders, and other types of actuators. All of those devices could be connected using I2C, but it might be more interesting if the bus included the ability to talk to SPI and synchronous serial devices as well. A couple of enable signals and a versatile master would make it doable.

Power distribution is another problem daisy chaining devices on a common bus. For any given device, mili-Amps to many Amps are needed. This makes it awkward to daisy chain power through bus device connectors. My thought is to define a bus break-out board that would daisy chain the power and bus signals, and have connectors to route power and signals to the bus devices.

Since a range of devices would want to be supported, a standard connector definition would need to include connectors with more pins to support devices with higher power requirements. When I say a standard connector, what I'm thinking is a standard family of connectors, that all use the same crimper.

Connecting the break-out boards together, it would be desirable to use the same connector as used to connect to the device, but clearly a heftier connection is needed for the power. My thought is to use tab connectors for the power bus, as they are robust, can handle many Amps, and are cheap.

The break-out board design would look something like this:


The channel shown is the 1 inch channel from LynxMotion, to give a sense of scale. A closer view shows the ability to mix and match connectors:


And the pin-outs would be something like this:


For SPI / simple sync. serial break-out something like this:


By defining a standard bus and bus hardware that is modular and versatile, it becomes easier for someone like LynxMotion to offer a family of assembled bus parts. And if enough people are using those plug together parts, because it is easier than building a custom wire harness for each new project, the parts will get cheaper.

Cliff
Back to top
View user's profile Send private message
Cliff



Joined: 23 Jan 2007
Posts: 150
Location: Saratoga, CA

PostPosted: Thu Mar 01, 2007 11:40 pm    Post subject: Reply with quote

Barry,

I'm back again to address the rest of your points:
Quote:

20MHZ resonator:- we have tried this before and it didn't work out at the time.

I have had the same problem with crystals on the AVRs in the past and the solution was to set the clock option fuse bit to increase the drive to the crystal.
Quote:

There is also the issue of the new PWM feature and moving that to a suitable pin.

Rather than move the PWM pin, I would change the firmware such that on power up, the program checks the I2C clock line and if it is low, go into PWM mode (using the MISO for PWM) otherwise it would use the pin for the interrupt output. On the input cable connector, the I2C clock would be connected to its ground with a short wire. With the PWM as currently defined the I2C clock has the potential for rattling around and causing problems. In general I think it is better if the PWM mode is clearly set - it makes no sense to leave the I2C interface active, when there is no reason to want to do both PWM and I2C at the same time.

From the hardware wish list:
Quadrature encoder and Hall sensor - I thought about pads to connect those, but space got a little tight on the layout. I could make room if you want to try your hand at soldering 0402 resistors Smile . We have spare pins and I do think that provision should be made in software to support those devices, which is to say that we should define the pins to be used. Where a larger OpenServo board can be use (such as in the LynxMotion development), it will probability be more interesting to use those devices anyway.

Hall based current sensor - I think the back EMF measurement will give better motor information, which I believe was the motive. The device Mike selected is cheap and the only advantage the Hall current sensor has is measuring current both in and out - which is useful for managing a battery, but I don't see that as a job OpenServo should be doing.

Cliff
Back to top
View user's profile Send private message
ginge
Site Admin


Joined: 14 Jan 2006
Posts: 1030
Location: Manchester, UK

PostPosted: Fri Mar 02, 2007 12:25 am    Post subject: Reply with quote

Cliff,

Although PWM and I2c is probably something that is not needed together it sure makes a nice feature. You can control via a manual R/C pack and monitor the actual motor params etc. Maybe I just want too much in life.

Regarding the Connector layout: What you are saying makes a lot of sense. The idea of a bus layout is one that I adopted for my robot platform and works very well. The variable size connectors is an interesting idea, and one that I quite like.

I have looked up the connector part, and it seems readily available over here. I have some in a parts bin somewhere in the warehouse. I will dig them up and have a play with cable layouts.

Quote:
From the hardware wish list:

Most of the items on the wish list are crazy. I wouldn't expect to see them on a standard platform. I would love to have optical encoder inputs on the board, but I had a lot of trouble with missed pulses on my test platform. The AVR was not fast enough to process all of the information at the same time. As the new layout has a 20MHZ xtal on it, I would imagine I could ressurect the code and finish it.

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
mpthompson



Joined: 02 Jan 2006
Posts: 650
Location: San Carlos, CA

PostPosted: Fri Mar 02, 2007 4:42 pm    Post subject: Reply with quote

Hey guys, I got myself buried in some work on my day job and some family activities on this weekend, but I do have to compliment Cliff on the terrific work. I'll collect my thoughts on the myriad of issues raised above and comment more extensively by Friday night.

The biggest thing for me will be to figure out the back EMF support in software. How to gracefully handle the toggling of the control outputs to make the measurement and then using the data to better drive the motor. Whenever we discussed back EMF previously I was always a bit worried about interrupting the PWM output to the motor thinking it would cause issues, but my worries are probably unfounded.

In any case, I'll need to reread the messages above a number of times to make sure I understand everything that has been discussed thus far. I'll get back soon.

-Mike
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger
Cliff



Joined: 23 Jan 2007
Posts: 150
Location: Saratoga, CA

PostPosted: Fri Mar 02, 2007 6:15 pm    Post subject: Reply with quote

Hi Mike,

In case you missed this article on back EMF measurement, reviewing it might help your thinking about how do the software - although it doesn't talk about software it is a decent review of another back EMF implementation.

The article is here: http://www.acroname.com/robotics/info/articles/back-emf/back-emf.html

As to gracefully interrupting the PWM, I think all that is needed is switching between the compare output and the port output (port bit = '0'), by clearing the COM1x0 and COM1x1 bits to '0' (see Figure 14-5 on page 119 and the tables on page 130 and 131 of the ATmega168 data sheet). To restore PWM, the bits would be restored to their previous values. This disables the output while allowing the servo loop and PWM routines to carry on as normal, ignorant of the fact that the output is going nowhere.

Cliff
Back to top
View user's profile Send private message
mpthompson



Joined: 02 Jan 2006
Posts: 650
Location: San Carlos, CA

PostPosted: Fri Mar 02, 2007 6:52 pm    Post subject: Reply with quote

Cliff,

Thanks for the link to the back emf info. I'll certainly be looking this over.

I've just started reviewing the ATmega168 datasheets regarding control of the PWM. I think the best implementation for turning off and on the PWM for the back EMF measurement may be to make sure we stop PWM on the boundaries of one PWM cycle. This prevents prevents us from chopping up a PWM pulse mid cycle. This would be done by manipulating the counter compare value which is reloaded at the end of each PWM cycle by the timer rather than directly manipulating the clock source to disable PWM.

I believe the other thing we'll need to consider is to synchronize ADC sampling of the back EMF value with the other ADC sampling for position control and such. Basically, we need to make sure we are ready to take an ADC sample during the brief period we turn of PWM to the motor. This means that ADC sampling and PWM output to the motors will have to have some sort of coordination that is currently not present in the code. They currently run asynchronous from each other.

Hopefully this all makes sense. How we turn PWM on/off for the back EMF measurement may not be too important, but it would probably be best to try for the most correct implementation and then make compromises as needed for practical reasons.

-Mike
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger
robotjay
co-admin


Joined: 01 Aug 2006
Posts: 225
Location: Nebraska, USA

PostPosted: Sun Mar 04, 2007 6:52 am    Post subject: Reply with quote

Cliff,

Your design is spectacular, I love what you've done. What are the dimensions of the board?

-Jay
_________________
"Nothing is fool-proof; For we fools are ingenious and will find a way."
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Cliff



Joined: 23 Jan 2007
Posts: 150
Location: Saratoga, CA

PostPosted: Sun Mar 04, 2007 1:04 pm    Post subject: Reply with quote

Hi Jay,

Thanks for the kind words.

The board dimensions are:


I'm planning to do the prototypes with PCB Express. They don't require a square board outline - as long as the outline is one continuous line, they are happy. I'm going to do the board 10 up and have 2 of those made (fits their 9 sq. In. x 2 board minimum).

This is a look at the route plan:


Cliff
Back to top
View user's profile Send private message
Cliff



Joined: 23 Jan 2007
Posts: 150
Location: Saratoga, CA

PostPosted: Mon Mar 05, 2007 5:48 pm    Post subject: Reply with quote

Mike,

Since you are thinking about software to support motor back EMF, thought I would take a cut at providing a better description of the bridge circuit and what I see as related issues. But, my description write-up had a mind of its own and got too long to be reasonable post here, so I'll post a link to a PDF of it, sometime in the next few days. In the meantime, here is a short version.

First, a simplified diagram of the circuit:



The upper switches PWM_A and PWM_B represent the bridge P-FETs, the EN_A and EN_B switches represent the bridge N-FETs, the SMPLn_A and SMPLn_B represent the sample switches, the 100M Ohm resistors represent sample switch leakage, the 10K and 20K Ohm resistors are the sample voltage dividers and the doted block is the ADC input circuit, where the 100M Ohm resistor is the input leakage, the switch is the ADC mux., and the 100K Ohm resistor and 14pF capacitor is the ADC sample and hold amplifier input impedance and capacitance. As a starting point, consider all the switches open.

Ok, if we are going to measure the back EMF (BEMF), we are going to have to start by getting the motor going moving the motor in direction A (either direction will do, so it might just as well be A), the EN_A switch is closed, grounding one side of the motor, and a PWM signal operates switch PWM_A, providing power to the motor. After a while we'll want stop the PWM signal, leaving the PWM_A switch open (signal goes low and stays there for now) and leave the EN_A switch closed so we have one side of the motor grounded for a reference.

When the PWM signal was driving the motor, the current through the motor coils created a magnetic field, which when we stop the PWM signal, will collapse producing a negative voltage (opposite in sign to the applied or generated voltages). If we look at the side of the motor opposite the grounded side, we will see a negative voltage spike, which after a time, will recover to the voltage generated by the coasting motor. The divider resistors (10K and 20K) on that side of the motor, will deliver to the sample switch 2/3 of the voltage (including the negative spike) generated by the motor. Since the collapse spike is not interesting, we will wait until the voltage has recovered to the generated voltage, before taking a sample with the sample switch. Here is a model showing the motor when we stop the PWM signal and a schematic of the generated spike:



After a suitable delay, the sample switch SMPLn_A is closed, charging the 10,000pF capacitor to the BEMF voltage. The capacitor can not be charged instantly, so we need to leave the switch closed for a while. Once the capacitor is charged, the sample switch SMPLn_A is opened and the motor is restarted by applying the PWM signal to switch PWM_A. The voltage on the capacitor can then be read by the ADC. In theory (perfect capacitor, perfect switches), the capacitor will hold the sampled voltage until the next sample is taken, but in the real world the charge will leak and the voltage will decline. The following show the models for charging the capacitor and the leakage that will discharge it.



Looking at the charge and discharge numbers above, we see that it is desirable to have a large capacitor to maintain the charge and desirable to have a small capacitor when charging with the sample. The trick is finding the best fit.

Enough for now, more later.

Cliff
Back to top
View user's profile Send private message
Cliff



Joined: 23 Jan 2007
Posts: 150
Location: Saratoga, CA

PostPosted: Tue Mar 06, 2007 2:05 pm    Post subject: Reply with quote

Mike,

Before continuing the discussion on the BEMF circuit, I would like to make it clear that this circuit is the result of a thought experiment, and that without some feedback on the behavior of the small servo motors, used with OpenServo, I don't have a clue whether or not this scheme will be useful. Electrically the circuit will work, but will the motor provide a useful signal?

My largest concern is whether or not the motor has enough inertia to coast, at close to the driven speed, for long enough to provide a useful BEMF signal or will friction slow it down too fast. Added to the friction slowing, by measuring the BEMF with a simple resistor divider, we are drawing current that will also slow the motor by braking. We also don't know how long, long enough is. At this point we have some numbers on how much sample time is needed (from my straw-man RC values), but don't have any idea how long the spike delay needs to be.

Perhaps an experiment to get a handle of some of these issues, short of building the new boards, would be to add a BEMF measurement window to the existing OpenServo code, running on the existing hardware. Maybe this could be added to the existing ADC routine, simply turning the PWM output off on entry and back on, on exit. First order, this would answer the question of whether shutting down the PWM periodically is going to do bad things to the control loop. If this works ok, a delay to increase the PWM off time could be added and the time increased gradually until it is obvious that performance is on the decline or bad things happen to the control loop. To get a handle on the braking effect due to the resistor divider, different resistor values can be tacked across the motor leads and the above window time stepping repeated. If reasonable performance is seen with a 1-2mS window and 30K resistor across the motor, we can guess that the motor has enough inertia to make the BEMF measurement work.
Note: If the maximum PWM duty cycle is being limited in the firmware, that limit should be increased, because the BEMF window is reducing the duty cycle.

With the BEMF window in the code, the spike could be measured by adding a 0.1uF capacitor from one of the motor leads to ground and using a oscilloscope probe connected between the other motor lead and ground. This will be an AC measurement, so the BEMF voltage can't be read this way and the voltage spikes will change sign, depending on the motor rotation direction. The width of the spike is going to change under different motor loads, so we will want to try a range of motor loads.

So, what do you think? Is this a reasonable experiment? Is putting the BEMF window in the code, doable without a big effort?

If this experiment can be done and shows that BEMF measurement is viable for OpenServo, we can sort out the best values for the circuit and how best to use the BEMF information in the control loop. Otherwise, I guess I'll have to start thinking about what to do with that big empty space on the bottom of the OS vX1 board.

Cliff
Back to top
View user's profile Send private message
mpthompson



Joined: 02 Jan 2006
Posts: 650
Location: San Carlos, CA

PostPosted: Wed Mar 07, 2007 12:52 am    Post subject: Reply with quote

Cliff,

The approach you outline is very reasonable. Putting the anticipated delays in the current code to simulate the disable/enable of the PWM will indeed let us determine what impact, if any, there will be on servo operation.

Right now we sample servo position every 10 ms (100 Hz). After the sampled position is ready, the PID calculation is performed with the outputs determining a new PWM duty cycle for the motors. Therefore there is roughly a 10 ms heart beat to the system defined by this processing loop. I would like to look at formalizing the 10ms heartbeat with ADC sampling, processing and PWM output to occur in a synchronized manner -- currently they are somewhat unsynchronized. We will then add BEMF to sequence as you describe above into the processing loop.

Therefore, the core OpenServo processing loop will look like:

1. Wait for 10ms window boundry
2. Disable PWM
3. ADC BEMF measurement
4. Enable PWM
5. ADC position measurement
6. ADC current measurement
7. BEMF -- > velocity
8. Position/velocity --> PID --> motor direction/duty cycle
9. Update PWM timer with motor direction/duty cycle
10. Housekeeping (I2C commands, etc).
11. Goto step 1.

Note: I2C communication and servo pulse measurement remain asynchronous

With a 20 MHz clock I'm hoping that the entire processing loop can occur in less than 10ms and that PWM disable to the motor will be less than 2 ms so the PWM signal is delivered to the motors at least 80% of the time. If needed we can probably lengthen the processing window to 20 ms without ill effects, but I would like to keep to 10ms if possible.

With my STK500 dev board and a 20 MHz crystal (which I have) I can look into making the changes described and see if everything works from a timing perspective.

Any further comments on this?

-Mike
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger
Cliff



Joined: 23 Jan 2007
Posts: 150
Location: Saratoga, CA

PostPosted: Wed Mar 07, 2007 1:51 pm    Post subject: Reply with quote

Hi Mike,

I agree with trying to keep the servo loop at 10mS. As you noted, the issue comes down to processing speed and effective maximum PWM duty cycle. I assume that you are limiting the PWM duty cycle in the current OS 2 code, given that the battery voltage is 7.2V and the motors are 6V. I'm hoping that the BEMF window can be kept down to around 1mS, but if it needs to be closer to 2mS, we can still deliver close to 6V to the motor, by adjusting the PWM limit.

On the loop, I think I would do it like this:

1. Wait for 10ms window boundry
2. Disable PWM
3. ADC current measurement
4. ADC position measurement
5. Additional delay for BEMF recovery

6. BEMF sample on
6a. Delay
6b. Sample off
7. Enable PWM
8. ADC BEMF measurement
or
6. BEMF sample on
6a. Delay
7. ADC BEMF measurement
7a. Sample off
8. Enable PWM

9. BEMF -- > velocity
10. Position/velocity --> PID --> motor direction/duty cycle
11. Update PWM timer with motor direction/duty cycle
12. Housekeeping (I2C commands, etc).
13. Goto step 1.

My reasons for the changes are:

a) When the PWM signal is disabled, the board noise is low (we do have the field collapse spike, but the currents will be in a tight loop around the FETs), so this is a good time to get low noise measurements for the current and position.
b) A delay is need to allow the motor field to collapse and the BEMF voltage to recover, so we might as well use the delay time to do the ADC conversions on current and position.
c) By measuring the current first, the current filter will still have a good value for the running current.
d) The additional delay step may be necessary if the spike/BEMF recovery time is longer that the 200uS or so, used for the current and position conversions.
e) Steps 6-8 ? Due to the nature of the sample circuit, we have the option of doing the BEMF ADC conversion before or after the PWM signal is restarted. Also, I wanted to show the sample switch on and off steps. For the first option shown, the sample capacitor would be around the .01uF I used in the post above and the ADC conversion could be done anytime in the next 1-2mS, after the PWM is restarted, without causing significant error. Using the second option, the sample capacitor would be much smaller and the ADC conversion would need to be done shortly after (some small delay may be needed) the sample switch is closed. The option that works the best for the software, is the one that should be used ? I just wanted to point out that there is a choice.

Cliff
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenServo.com Forum Index -> Hardware All times are GMT
Goto page 1, 2, 3 ... 17, 18, 19  Next
Page 1 of 19

 
Jump to:  
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


Powered by phpBB © 2001, 2005 phpBB Group