|
Re: Testing a UCB July 29, 2007 07:04PM |
Admin Registered: 16 years ago Posts: 476 |
> Kai has got the loop back comms test working with a link between the PIC pins.
> That must mean the link from the PC to powercomms board is ok.
> Also the links from it to the UCB must have continuity.
> I think the only faulty cabling possibility left is TX and RX links
> swapped at the UCB which would still pass loopback but Kai has double
> checked this.
Right... so what you are saying is that all Kai's serial wiring must be fine -- and yet it also must not be fine, because it isn't working! We must either decide that the fault is illogical and therefore no solution is possible (!), or we must conclude that some part of the testing process to date has provided inaccurate information in some way.
I think the possibility exists that some part of earlier serial network wiring/testing/checking may have been somehow faulty. The report that swapping boards did not improve things seems to strengthen this possibility, to my mind. Therefore, (re-)testing all of it seems to me to be both prudent and feasible (if we had 100 2-wire connections, a little more selectivity would be in order -- fortunately, there are only four!).
I don't know... if you have other testing ideas we can try, I'm sure Kai would be happy to hear them. So would I! Other than a wiring issue, (or a highly unlikely misprogrammed or bad PIC), frankly, I'm stumped!
Kai, to check on the PIC, you could put it back in the programmer and read its contents into a file, then compare the file with the stepmotor.hex original? Also, if you have another PIC available, try using the spare one instead of the original? Maybe you already did this? I'm not sure how to test PIC programming any "deeper" than this, except by seeing it in action in a SNAP network!
It will be very interesting to (eventually) learn what the problem really was, when this is solved! We may want to add to the official test set on the basis of what we learn, hoping to spare others from encountering this same issue in future.
Jonathan
> That must mean the link from the PC to powercomms board is ok.
> Also the links from it to the UCB must have continuity.
> I think the only faulty cabling possibility left is TX and RX links
> swapped at the UCB which would still pass loopback but Kai has double
> checked this.
Right... so what you are saying is that all Kai's serial wiring must be fine -- and yet it also must not be fine, because it isn't working! We must either decide that the fault is illogical and therefore no solution is possible (!), or we must conclude that some part of the testing process to date has provided inaccurate information in some way.
I think the possibility exists that some part of earlier serial network wiring/testing/checking may have been somehow faulty. The report that swapping boards did not improve things seems to strengthen this possibility, to my mind. Therefore, (re-)testing all of it seems to me to be both prudent and feasible (if we had 100 2-wire connections, a little more selectivity would be in order -- fortunately, there are only four!).
I don't know... if you have other testing ideas we can try, I'm sure Kai would be happy to hear them. So would I! Other than a wiring issue, (or a highly unlikely misprogrammed or bad PIC), frankly, I'm stumped!
Kai, to check on the PIC, you could put it back in the programmer and read its contents into a file, then compare the file with the stepmotor.hex original? Also, if you have another PIC available, try using the spare one instead of the original? Maybe you already did this? I'm not sure how to test PIC programming any "deeper" than this, except by seeing it in action in a SNAP network!
It will be very interesting to (eventually) learn what the problem really was, when this is solved! We may want to add to the official test set on the basis of what we learn, hoping to spare others from encountering this same issue in future.
Jonathan
|
Re: Testing a UCB July 30, 2007 08:37AM |
Admin Registered: 16 years ago Posts: 7,871 |
Kai,
As Jonathon says we are running out of ideas here so perhaps we need to back track. Please can you confirm the following tests :-
You can get an echo through HyperTerminal when you link pins 7 and 8 at the PIC socket (with the PIC removed of course) AND you don't get echo with the link removed.
The comms port that you have HT set to is the same as the one in the stepper test.
The PIC has 5V.
You have tried two different PICs.
The PIC is the right device number and programmed with the right hex file and it verifies.
You definitely have the TX and RX leads the right way round (try both just to be sure).
If all these tests pass then I don't know what your problem is.
You could try adding LEDs to pins 7 and 8 and see which, if any, flash. Connect the anodes to 5V and the cathods via a 2K resistor to the comms lines. With the PIC removed the RX led should flicker dimly when the PC sends something. With the PIC in both should flicker.
I think it would be a good idea for the next revision of these boards to have LEDs on all the comms lines. It would make this a lot easier to debug and LEDs are cheap enough. Confident constructors could always leave them off if they wanted. If the powercomms boards had them as well on inputs and outputs you could immeiately see which cable, board, max chip, PIC or PC is at fault.
[www.hydraraptor.blogspot.com]
As Jonathon says we are running out of ideas here so perhaps we need to back track. Please can you confirm the following tests :-
You can get an echo through HyperTerminal when you link pins 7 and 8 at the PIC socket (with the PIC removed of course) AND you don't get echo with the link removed.
The comms port that you have HT set to is the same as the one in the stepper test.
The PIC has 5V.
You have tried two different PICs.
The PIC is the right device number and programmed with the right hex file and it verifies.
You definitely have the TX and RX leads the right way round (try both just to be sure).
If all these tests pass then I don't know what your problem is.
You could try adding LEDs to pins 7 and 8 and see which, if any, flash. Connect the anodes to 5V and the cathods via a 2K resistor to the comms lines. With the PIC removed the RX led should flicker dimly when the PC sends something. With the PIC in both should flicker.
I think it would be a good idea for the next revision of these boards to have LEDs on all the comms lines. It would make this a lot easier to debug and LEDs are cheap enough. Confident constructors could always leave them off if they wanted. If the powercomms boards had them as well on inputs and outputs you could immeiately see which cable, board, max chip, PIC or PC is at fault.
[www.hydraraptor.blogspot.com]
|
Re: Testing a UCB July 30, 2007 03:07PM |
Admin Registered: 16 years ago Posts: 476 |
Yes, the extra LEDs sound like a good idea, given the number of people reporting what seem to be wiring issues.
I have an ancient 25pin serial diagnostic tester thingie inline between PC and PowerComms here, which has 2-color LEDs on RX, TX, RTS, CTS, DTR and probably a a couple of others (!), so I can "see" the TX and RX flickers from that. I happened to have it from my days playing with external modems overseas. It makes my serial connection a bit of a mess (9pinM on PC, 9pinF to 25pinM cable, 25pinF to 25pinM tester thingie, 25F to 9pinM converter, PowerComms 9pinF connector!), but it gives me an extra visual clue that comms to the RepRap electronics are "alive and well". So far I haven't really needed it, since my wiring worked fine, but it's nice to have, so I left it in circuit.
We could even go really LED-crazy and add LEDs for the endstop sensor inputs too??
Jonathan
I have an ancient 25pin serial diagnostic tester thingie inline between PC and PowerComms here, which has 2-color LEDs on RX, TX, RTS, CTS, DTR and probably a a couple of others (!), so I can "see" the TX and RX flickers from that. I happened to have it from my days playing with external modems overseas. It makes my serial connection a bit of a mess (9pinM on PC, 9pinF to 25pinM cable, 25pinF to 25pinM tester thingie, 25F to 9pinM converter, PowerComms 9pinF connector!), but it gives me an extra visual clue that comms to the RepRap electronics are "alive and well". So far I haven't really needed it, since my wiring worked fine, but it's nice to have, so I left it in circuit.
We could even go really LED-crazy and add LEDs for the endstop sensor inputs too??
Jonathan
|
Re: Testing a UCB July 30, 2007 03:16PM |
Admin Registered: 16 years ago Posts: 7,871 |
Yes why not, and the stepper outputs, then the machine will look very impressive when it is running. Like a sixties computer!
[www.hydraraptor.blogspot.com]
[www.hydraraptor.blogspot.com]
|
Anonymous User
Re: Testing a UCB July 31, 2007 12:49AM |
Let's add a few more tests to the mix. I've attached two .hex files.
The first is led_throb.hex. It pulses the LED on the universal board on and off once a second. Program this file into a PIC, stick it on your universal board, and apply power. You don't need to connect anything else, it ignores TX, RX, and jumpers. This should give you some confidence that your programmer is doing what it should. Errors in programming the PIC should be extremely rare, but we might as well check. If you see the LED doing its thing, we'll move on to test number two.
...which is tx_baud.hex. It transmits an endless stream of messages to your computer at several different baud rates. Program this into your PIC, connect the TX (TG) connector on the universal board to the RX connector on the PowerComms board and apply power. There's no need to make the other connection, the PIC doesn't listen. The LED should blink on and off every few seconds. Now open up HyperTerminal. You should see three lines of readable text separated by some garbage, repeating every second or two. It should look like:
Transmitting at 19200 baud (correct)
If you see:
Transmitting at 9600 baud (ERROR)
your serial port settings are wrong, shame on you :-) This only tests 8-N-1. If this works (at any speed) then your wiring on the TX side is fine, and we'll need to come up with a test for the RX side.
The first is led_throb.hex. It pulses the LED on the universal board on and off once a second. Program this file into a PIC, stick it on your universal board, and apply power. You don't need to connect anything else, it ignores TX, RX, and jumpers. This should give you some confidence that your programmer is doing what it should. Errors in programming the PIC should be extremely rare, but we might as well check. If you see the LED doing its thing, we'll move on to test number two.
...which is tx_baud.hex. It transmits an endless stream of messages to your computer at several different baud rates. Program this into your PIC, connect the TX (TG) connector on the universal board to the RX connector on the PowerComms board and apply power. There's no need to make the other connection, the PIC doesn't listen. The LED should blink on and off every few seconds. Now open up HyperTerminal. You should see three lines of readable text separated by some garbage, repeating every second or two. It should look like:
Transmitting at 19200 baud (correct)
If you see:
Transmitting at 9600 baud (ERROR)
your serial port settings are wrong, shame on you :-) This only tests 8-N-1. If this works (at any speed) then your wiring on the TX side is fine, and we'll need to come up with a test for the RX side.
|
Re: Testing a UCB July 31, 2007 12:44PM |
Admin Registered: 16 years ago Posts: 1,487 |
nice!
emf, would you email me the source code for those various firmwares? that would be great to stick into subversion. i'd also like to add those firmwares to the release on sourceforge. adding debugging tools will make reprap that much easier for your average users.
i'm also a fan of adding lots of LED's to the boards. we can do it in a way thats optional, and also adds alot of value (and cool blinkenlights mojo) to the boards.
emf, would you email me the source code for those various firmwares? that would be great to stick into subversion. i'd also like to add those firmwares to the release on sourceforge. adding debugging tools will make reprap that much easier for your average users.
i'm also a fan of adding lots of LED's to the boards. we can do it in a way thats optional, and also adds alot of value (and cool blinkenlights mojo) to the boards.
|
Anonymous User
Re: Testing a UCB July 31, 2007 01:32PM |
I'll bundle up the files for you tonight.
Here's one more to test whether the PIC is receiving. Program this into a PIC, connect the universal board's RX connector to the TX connector on the powercomms board, and apply power. It ignores the jumpers, motor, etc. The LED should remain off. Now load up HyperTerminal configured for 19200-8-N-1, hopefully it's already set that way from the last test. When you type in a number from 1 to 9, it should blink that many times (at around 1Hz). All other characters will be ignored. If this works we can safely say that the receive part of your wiring is correct.
Here's one more to test whether the PIC is receiving. Program this into a PIC, connect the universal board's RX connector to the TX connector on the powercomms board, and apply power. It ignores the jumpers, motor, etc. The LED should remain off. Now load up HyperTerminal configured for 19200-8-N-1, hopefully it's already set that way from the last test. When you type in a number from 1 to 9, it should blink that many times (at around 1Hz). All other characters will be ignored. If this works we can safely say that the receive part of your wiring is correct.
|
Re: Testing a UCB July 31, 2007 11:52PM |
Admin Registered: 16 years ago Posts: 476 |
This set of test firmware looks like a great contribution!
If there were space in the "real" firmware to add a PIC boot-time message to be sent at 19200 N81, perhaps "RepRap Darwin X-axis 0.9" or similar (with CRLF before and after it?) that would allow a form of emf's TX wiring test without PIC swapping/reprogramming. And seeing that string in minicom or Hyperterminal would also "prove" that the PIC has our firmware in it, so it acts as a check on that, too. If a PIC containing this firmware somehow got reset on a live network the string would be seen as a "bad" packet, if it were seen at all (it contains no start-of-SNAP-packet character!) and so it should be discarded/ignored by anything talking SNAP at the time. And stepper controllers shouldn't be reset during use anyway.
[Trying to avoid PIC reprogramming and re-socketing: I suppose we could add a short "led_throb" test at PIC bootup, too, maybe 2 1/4 second flashes with 1/4 second dark periods between them? So a 1 sec boot delay flashing the LED, then the serial TX of CRLF RepRap Darwin 0.9 CRLF, then the PIC does its real work?]
With all the PIC-movement this kind of testing currently requires, the idea of an ICSP header on the boards becomes even more beneficial. Did anyone ever build a test board with an ICSP header on it?
I'm slightly concerned we are only talking among ourselves, though. We're supposed to be helping Kai aka KDuncan!
Kai? Are you still alive? Have you tried any of our recent ideas? Any progress to report? Don't give up :-)
Jonathan
If there were space in the "real" firmware to add a PIC boot-time message to be sent at 19200 N81, perhaps "RepRap Darwin X-axis 0.9" or similar (with CRLF before and after it?) that would allow a form of emf's TX wiring test without PIC swapping/reprogramming. And seeing that string in minicom or Hyperterminal would also "prove" that the PIC has our firmware in it, so it acts as a check on that, too. If a PIC containing this firmware somehow got reset on a live network the string would be seen as a "bad" packet, if it were seen at all (it contains no start-of-SNAP-packet character!) and so it should be discarded/ignored by anything talking SNAP at the time. And stepper controllers shouldn't be reset during use anyway.
[Trying to avoid PIC reprogramming and re-socketing: I suppose we could add a short "led_throb" test at PIC bootup, too, maybe 2 1/4 second flashes with 1/4 second dark periods between them? So a 1 sec boot delay flashing the LED, then the serial TX of CRLF RepRap Darwin 0.9 CRLF, then the PIC does its real work?]
With all the PIC-movement this kind of testing currently requires, the idea of an ICSP header on the boards becomes even more beneficial. Did anyone ever build a test board with an ICSP header on it?
I'm slightly concerned we are only talking among ourselves, though. We're supposed to be helping Kai aka KDuncan!
Kai? Are you still alive? Have you tried any of our recent ideas? Any progress to report? Don't give up :-)
Jonathan
|
Anonymous User
Re: Testing a UCB August 01, 2007 12:33AM |
jmarsden Wrote:
> If there were space in the "real" firmware to add
> a PIC boot-time message to be sent at 19200 N81,
There should be plenty of space. I doubt this stuff uses more than 4 bytes of RAM , and I think we have 80+ available. I think there's plenty of room for the string in program space too.
> With all the PIC-movement this kind of testing
> currently requires, the idea of an ICSP header on
> the boards becomes even more beneficial.
Amen! I've almost destroyed the PIC moving it back & forth testing these programs. If I can extract it one more time without breaking it, I'm going to put it in another socket to take the abuse of future insertions/extractions. Which is pretty silly because the socket costs almost as much as the PIC... *sigh*
> Did
> anyone ever build a test board with an ICSP header
> on it?
I built one into my latest board, along with a diode on Vpp. It didn't work. I'm not sure what the problem is. I've traced the circuit a few times and it looks ok, but I haven't had time to dig in to the problem too much. It fails both with my JDM2 and my ICD2. It's possible that they're not powerful enough to power the L298 at the same time as they reprogram the PIC, but I haven't had the courage to cut the 298's power trace yet, I'm hoping there's a better explanation.
> If there were space in the "real" firmware to add
> a PIC boot-time message to be sent at 19200 N81,
There should be plenty of space. I doubt this stuff uses more than 4 bytes of RAM , and I think we have 80+ available. I think there's plenty of room for the string in program space too.
> With all the PIC-movement this kind of testing
> currently requires, the idea of an ICSP header on
> the boards becomes even more beneficial.
Amen! I've almost destroyed the PIC moving it back & forth testing these programs. If I can extract it one more time without breaking it, I'm going to put it in another socket to take the abuse of future insertions/extractions. Which is pretty silly because the socket costs almost as much as the PIC... *sigh*
> Did
> anyone ever build a test board with an ICSP header
> on it?
I built one into my latest board, along with a diode on Vpp. It didn't work. I'm not sure what the problem is. I've traced the circuit a few times and it looks ok, but I haven't had time to dig in to the problem too much. It fails both with my JDM2 and my ICD2. It's possible that they're not powerful enough to power the L298 at the same time as they reprogram the PIC, but I haven't had the courage to cut the 298's power trace yet, I'm hoping there's a better explanation.
|
Re: Testing a UCB August 04, 2007 01:28AM |
Admin Registered: 16 years ago Posts: 476 |
|
Anonymous User
Re: Testing a UCB August 04, 2007 07:21AM |
jmarsden Wrote:
-------------------------------------------------------
> Any sign of the sources for this test firmware?
Here they are. Untar under the firmware directory, then cd into debug_firmware and make. The makefiles are old-style and ugly hacks. Figure they can be fixed in the transition to autoconf.
-------------------------------------------------------
> Any sign of the sources for this test firmware?
Here they are. Untar under the firmware directory, then cd into debug_firmware and make. The makefiles are old-style and ugly hacks. Figure they can be fixed in the transition to autoconf.
|
Re: Testing a UCB August 04, 2007 11:39AM |
Registered: 15 years ago Posts: 21 |
Hey guys, sorry I've been silent for so long. I ordered a new serial cable and it only just arrived yesterday. Didn't help, but worth a shot.
emf, thank you so much for the firmware files! I'm testing with them now.
Success with LED Throb!
Oh, woah, strangeness with TX Baud. LED's going but Hyperterminal is only returning the grabage. Same behavior with two different boards.
RX Test works like a charm.
Well, that seems to have narrowed it down a bit. I'm going to go and check my solder connections on the PowerComm. Thanks again for all the help guys.
-Kai
emf, thank you so much for the firmware files! I'm testing with them now.
Success with LED Throb!
Oh, woah, strangeness with TX Baud. LED's going but Hyperterminal is only returning the grabage. Same behavior with two different boards.
RX Test works like a charm.
Well, that seems to have narrowed it down a bit. I'm going to go and check my solder connections on the PowerComm. Thanks again for all the help guys.
-Kai
|
Re: Testing a UCB August 05, 2007 08:11AM |
Registered: 15 years ago Posts: 21 |
Well, I've checked all my solder points, resoldered the ones that looked even remotely in doubt, and still no luck. So now I'm thinking, could I have damaged my PowerComms board? I've switched out every component except it, so I'm thinking I may have inadvertently damaged it in some way.
-Kai
-Kai
|
Re: Testing a UCB August 05, 2007 10:46AM |
Admin Registered: 16 years ago Posts: 7,871 |
Have you checked the voltages around the MAX232 chip and the polarity of its capacitors?
[www.hydraraptor.blogspot.com]
[www.hydraraptor.blogspot.com]
|
Re: Testing a UCB August 05, 2007 12:20PM |
Registered: 15 years ago Posts: 21 |
nophead, definite problems. I'll list every test where I didn't get the right voltage.
* Pin 15 to 14: -7 to -15V. A mismatch suggests a short on the board or a miswiring of the cable.
* Pin 15 to 12: 5V
* Pin 15 to 11: 4 to 4.5V.
It's not much better with the cable plugged in. Every one of the above tests returned 0 volts.
I'm not actually certain how to check the polarity of the capacitors.
-Kai
* Pin 15 to 14: -7 to -15V. A mismatch suggests a short on the board or a miswiring of the cable.
* Pin 15 to 12: 5V
* Pin 15 to 11: 4 to 4.5V.
It's not much better with the cable plugged in. Every one of the above tests returned 0 volts.
I'm not actually certain how to check the polarity of the capacitors.
-Kai
|
Re: Testing a UCB August 05, 2007 01:12PM |
Admin Registered: 16 years ago Posts: 7,871 |
The polarity of small electrolytic capacitors is usually marked by a stripe down the side nearest negative connection. The board marks the plus connection with a square pad and a + on the silk screen. If you look at the picture in the wiki all the negative pins are those facing the camera.
If the caps are wrong that could be your problem, otherwise it looks like the MAX232 chip is faulty. Measure the voltage from 15 to 6, it should be about -9 I think from memory. The voltage from 15 to 2 should be about +9.
[www.hydraraptor.blogspot.com]
If the caps are wrong that could be your problem, otherwise it looks like the MAX232 chip is faulty. Measure the voltage from 15 to 6, it should be about -9 I think from memory. The voltage from 15 to 2 should be about +9.
[www.hydraraptor.blogspot.com]
|
Re: Testing a UCB August 05, 2007 01:34PM |
Registered: 15 years ago Posts: 21 |
|
Re: Testing a UCB August 05, 2007 01:57PM |
Admin Registered: 16 years ago Posts: 7,871 |
I don't think the voltage on pin 11 is well defined with nothing connected so I don't that is anything to worry about. When connected to the UCB it should go to around 5V.
So a loopback test in HT works but emf's transmit test fails. Are you sure HT is set to 19200 baud 8 bits no parity?
[www.hydraraptor.blogspot.com]
So a loopback test in HT works but emf's transmit test fails. Are you sure HT is set to 19200 baud 8 bits no parity?
[www.hydraraptor.blogspot.com]
|
Re: Testing a UCB August 05, 2007 02:34PM |
Registered: 15 years ago Posts: 21 |
|
Re: Testing a UCB August 05, 2007 02:46PM |
Admin Registered: 16 years ago Posts: 7,871 |
So a loop back through the PIC pins echoes OK but when the PIC transmits the data is corrupted? Other than a very poor ground connection between the PCOM and UCB I am starting to run out of ideas.
Can you send a screen shot of what the garbage is when running emf's transmit test?
[www.hydraraptor.blogspot.com]
Can you send a screen shot of what the garbage is when running emf's transmit test?
[www.hydraraptor.blogspot.com]
|
Re: Testing a UCB August 05, 2007 03:40PM |
Admin Registered: 16 years ago Posts: 1,487 |
|
Re: Testing a UCB August 05, 2007 04:16PM |
Registered: 15 years ago Posts: 21 |
|
Re: Testing a UCB August 05, 2007 05:50PM |
Admin Registered: 16 years ago Posts: 7,871 |
So 12 characters in 5 minutes. Did they all arrive at once or one every 25 seconds or did they arrive irregularly?
[www.hydraraptor.blogspot.com]
[www.hydraraptor.blogspot.com]
|
Re: Testing a UCB August 06, 2007 10:14AM |
Registered: 15 years ago Posts: 21 |
|
Re: Testing a UCB August 06, 2007 10:27AM |
Admin Registered: 16 years ago Posts: 7,871 |
The only explaination I can think of for that is that you are actually monitoring your mouse! Do you have a serial mouse on your PC? Does it happen with the HT window in focus when you wave your mouse about?
[www.hydraraptor.blogspot.com]
[www.hydraraptor.blogspot.com]
|
Anonymous User
Re: Testing a UCB August 06, 2007 11:28AM |
Wow, this is a really tough one. We know that your PC is able to transmit correctly at 19200-8-N-1 all the way through to the PIC, because the RX test worked. That also lets us know you don't have the tx/rx wires swapped. We know your PC is able to receive correctly because your loopback tests worked. If there were a problem with the TX wiring, the test where you shorted pins 7 and 8 in the PIC socket should have failed. It worked, so I guess we have to assume that the TX wiring from the PIC back to the computer is ok. The only thing that seems to leave is the PIC itself, but I think you've tried two different PICs, and the chances of having two with TX is pretty slim.
I don't know what to make of your weird HT behavior either. Can you get garbage characters by connecting just parts of the system: just the serial cable, add the power comms, add the UCB without a PIC in the socket, add a PIC with the rx_test firmware (which shouldn't transmit anything)?
I don't know what to make of your weird HT behavior either. Can you get garbage characters by connecting just parts of the system: just the serial cable, add the power comms, add the UCB without a PIC in the socket, add a PIC with the rx_test firmware (which shouldn't transmit anything)?
|
Re: Testing a UCB August 06, 2007 11:41AM |
Admin Registered: 16 years ago Posts: 7,871 |
There could be a short from the TX pin of the PIC to an adjacent pin. That way the loop test would work without the PIC fitted because the pin the short is to is no longer driven. However, you have tried two boards so you would have had to have made the same mistake twice.
I am really grasping at straws here, I can't believe we have got so far, done so many tests, and not been able to narrow it down to any part of the system.
BTW, what are you using as a power supply? And is the UCB getting its power from a connection to the PCOM boards as intended?
[www.hydraraptor.blogspot.com]
I am really grasping at straws here, I can't believe we have got so far, done so many tests, and not been able to narrow it down to any part of the system.
BTW, what are you using as a power supply? And is the UCB getting its power from a connection to the PCOM boards as intended?
[www.hydraraptor.blogspot.com]
|
Anonymous User
Re: Testing a UCB August 14, 2007 12:09PM |
Sorry, only registered users may post in this forum.