Testing a UCB

Okay, this one's got me stumped. I've got my PowerComms and a UCB with the x-axis firmware installed. My transmit and receive cables are made using some cat-5 innards. I've used each seperately as a short with the PowerComm and Telnet, got no trouble. However, for whatever reason, the host software can't see the x-axis UCB.

Could my wire be at fault? Could my programmer have done, say, half the job (the LED on my UCB is on, so something took)? Everything's tested fine up until this point. Any help would be greatly appreciated.

-Kai

It sounds like your wire is ok. It's possible that the programmer did half the job, but that's fairly rare from what I've seen. Is it possible you've got one of the RX headers on the UCB inserted backwards? In some versions of the board, the RX header was supposed to be inserted backwards, but that may have been fixed by now.

In each of the headers, one pin transmits data, the other is ground. If you test with a multimeter, you should get continuity between the two ground pins, but not between the T and R pins, nor between T and ground or R and ground. These ground pins should be on the same side of the polarized header, hopefully the side marked G. While you've got your multimeter out, check to make sure you have continuity between the T pin and pin 8 on the PIC socket, and the R pin and pin 7 on the PIC socket.

An easy way to test that the signals are getting all the way to the PIC is to remove the PIC from the socket and jam a short piece of wire into the socket to short pin 7 to pin 8. Then connect everything up as normal (but don't insert the PIC) and do the telnet test. If you see text echoing back, you know signals are getting to and from the PIC.

If this works but it doesn't work when you replace the piece of wire with the PIC, then we can try to blame your problems on the PIC :-)

Edited 1 time(s). Last edit at 07/24/2007 08:42AM by emf.

I'll check the voltages when I get home tonight (damnable job, keeping me from what's important ) but I can tell you I've got the 1.2.1 board and both headers are tab-in. I've tried switching the pins around, but all that resulted in was a crash.

Thanks very much for the help.

Blarg, nevermind. Instructions for testing changed two days ago and completely explains my problem.

Great, that's what we like to hear :-)

Well, an early Mouser delivery and I'm back to square one. I'm trying to get voltage readings and everything comes out screwy. For instance; On my PowerComm board, the two pins furthest apart read 2-3 volts, but the two innermost register 4-5. Is anode definitely supposed to be the T/R pin? Again, any help would be greatly appreciated. Thanks.

-Kai

KDuncan wrote:

> I'm trying to get voltage readings and
> everything comes out screwy. For instance; On my
> PowerComm board, the two pins furthest apart read
> 2-3 volts, but the two innermost register 4-5.

I think it might help us all understand what is happening better if you could take care to be clear and specific, saying something more like (oddball unreal made-up example follows):

(a) I am following the instructions and tests at www.example.com/someplace/SomePageOrOther to construct a PowerComms card using a PowerComms 1.2 PCB from the RRRF store. (Hopefully, you are using DarwinPowerAndCommunicationsCard_1_2 on our Wiki [reprap.org] ).

(b) The first 36 tests all worked as expected. In PowerComms Test 37, I removed U3, I then put the common lead of my DMM on U3 socket pin 67 and the positive lead on U3 socket pin 93, and it reads +58.2 V DC. (These are all made up numbers, of course, there is no U3 and there is no Test 37, but I hope you get the idea: I recommend that you use component identifiers from the schematic or the board silkscreen, and use pin numbers starting at 1 (one), again based on the schematic or silkscreen. Also be clear about which meter lead is where, and whether the voltage difference it displays is positive or negative.).

In other words, please tell us which test(s) from which instructions you are using, and please try to refer to components and their pins based on their numbering in the documentation, if at all possible, rather that using your own way of describing things instead.

I'm a bit confused by your comment earlier in this thread about the test instructions. I added a short note to the UCB test instructions a couple of days ago, which I also posted in these forums for maximum visibility to all Reprappers. Is that the change you are talking about? The PowerComms test info has not changed recently. The last recorded edit to the DarwinPowerAndCommunicationsCard_1_2 wiki page seems to have been on 15 June, which is about 5 weeks ago.

Here are my questions for you at this point:

Q1: Did your PowerComms card successfully complete all tests on the DarwinPowerAndCommunicationsCard_1_2 wiki page before you first hooked it to your UCB?

Q2: If not, which test or tests did it fail during and after initial construction, and in what manner did it fail?

Q3: If it failed at least one test, why did you connect your PowerComms card to your UCB before it passed all the standard tests -- specifically, what led you to believe that a card that failed a test is going to work fine in combination with another card?

Now you are saying (I think) that your fully assembled PowerComms card is currently failing one or more of the standard PowerComms card tests.

Q4: Can you please either confirm this interpretation of events for me, or provide a corrected one if I am misunderstanding what happened?

I think testing your PowerComms card, and getting your first UCB / StepperController to communicate, are both fairly clearly "Electronics" tasks... but this question posted in the Software forum. The topic description here is "Discuss the java host software, firmware, Kicad, Art of Illusion, etc." . It would help others reading the forums later if we all try to post in the most appropriate forum, and use clear subject lines (your post I am replying to is about testing a PowerComms card, but it subject says "Testing a UCB").

Q5: Would you object or be unhappy if a forum administrator moves this thread into the Electronics forum?

> Is anode definitely supposed to be the T/R pin?

Please restate this question more clearly. (Which T pin or which R pin, there are two of each on the PowerComm silkscreen? The anode of which component? In which test? ... you get the idea).

I suggest you do not hook up your UCB at all, until we are sure that your PowerComms card passes all of its tests. In practice is is "probably" safe to power your UCB with, but using an untested or known failing board doesn't really help us to understand what is happening, and isn't a good idea. Testing should be done systematically, carefully, and in the appropriate sequence, to be most useful in troubleshooting.

Jonathan

I assume you are talking about the transmit and receive and grounds. Use the black ground wire from the computer molex connector as reference ground. R and T should never exceed 5.5 VDC as they are TTL compatible. Depending on the duty cycle of the bits, the voltage can be anywhere between 0 to 5 VDC. ignore this fluctuating voltages, (as long as they are below 5.5VDC) jumper R to T at the comm board and see if you get loopback with hyper terminal. Hyper terminal setup should be comm(X) (X = port number), 19,200 baud, 8N1 no flow control and save this setup for future, (hopefully unnecessary) tests. as you type the characters they should appear on the terminal, then remove the jumper and the characters will be lost as you type. If this is successful, attach you com cables and check continuity between pin7 of the Pic on the UCB and the T pin on the comm board, ( read where the pin is soldered to the underside of the board since the pin has the cable covering it). Then check pin 8 of the PIC on the UCB to the R on the Comm board. Finally check ground continuity by reading between pin 5 of the pic and the black wire on the molex connector from your power supply to your comm board, ground should be common.If the problem lies within the comm board read continuity back to the max 232 chip. The R header pin should be connected to pin 11 of the max 232,(Tin). It takes TTL voltage (0 to 5VDC) and converts and inverts it to RS232, ("0" is 12vdc and "1" is -12vdc ) and sends it out pin 14 of the max232 to pin 2 of the 9 pin D shell. The T header pin connects to pin 12 of the max 232 (R1 out). It receives RS232 signals from the computer on pin 3 of the 9 pin D shell and sends them to pin 13 of the max 232 chip. The Nax 232 inverts and and converts to TTL on pin 12 of the max 232. Hopefully the problem lies outside the comm board. I have an max 232 chip, it would be a pull from an old board I got surplus, ( I have a great desoldering set) if you need a new one. Check part orientation and reflow all solder joints first.Send it to me with a return package and I'll get it right. I used the twisted 2 pin female headers from old computer cases for my comm cables, everyone has old cases hanging around with all that other E junk we accumulate.One other thing, are you using a straight through 9 pin cable or a null modem cable? Only a straight through cable will work, (pin 2 to pin 2 and pin 3 to pin 3) not a null modem cable! Use straightened paper clips as a probes in both ends of the 9 pin female to check continuity between pin 2 to 2 and 3 to 3

Edited 4 time(s). Last edit at 07/25/2007 06:05AM by englewood.

My apologies, I tend to get ahead of myself. First, yes, could you move this to the electronics section? I'm a computer guy by trade and defaulted to the system being at fault.

Okay, here's where I'm at thus far: built the PowerComm, tested it, everything ran smoothly. The terminal test worked exactly as it was supposed to. So I go and make a UCB, planning for the X-axis controller. I'm following the instructions here (http://www.reprap.org/bin/view/Main/UniversalControllerBoard_1_2). Solder, solder, program, and I'm ready for the testing phase. Test one works like a charm. Ditto on two. Three, however, is the crash and burn. The system gets caught in a loop trying to find/talk to device ID 2. The error message should be, and I can get a more precise reference later, 'Receive error, re-sending: Timeout receiving byte'.

englewood, I took those readings this morning. So long as 'common' means zero (sorry, I'm kinda new to the electrical side of things), everything read as it should. I also tried removing the PIC and jumping those two pins, but got nowhere. Could the gauge make a difference for that? I was using 20-gauge copper for the bridging.

If there's anything else that could help please let me know. And thank you all so much for the help thus far.

-Kai

Kai - it appears the communications are not getting through. Triple check your wiring. (Tx from powercomms to Rx on the UCB, Tx on the UCB to Rx on the PowerComms) make sure the connectors are wired up properly as well. this is where keyed connectors come in handy. if you have the headers oriented properly, then you just make normal, straight connectors.

what are the exact versions of the boards you're using? are you using v1.2.0 or v1.2.1 of the UCB? also, double check the instructions to make sure you didnt miss a resistor or a wire jumper on the UCB.

No, their is minimal current so hardly any I squared R voltage loss. Continuity checks from pin7 pic socket ( the seventh pin down from the cap on the left hand side of the DIP Dual in line position socket) to T on the power comm. Remember t to R and R comms to T on the UCB. Is your UCB board silk screened? The Rx mean R is the receive and X is the ground on the UCB and RG means receive and ground on the comms board
I

No, their is minimal current so hardly any I squared R voltage loss. Continuity checks from pin7 pic socket ( the seventh pin down from the cap on the left hand side of the DIP Dual in line position socket) to T on the power comm. Remember t to R and R comms to T on the UCB. Is your UCB board silk screened? The Rx mean R is the receive and X is the ground on the UCB and RG means receive and ground on the comms board. Also check pin 8 (8 down on the left side, pin1 is the left top pin in the socket if the cap,( 0.1 microfarad ceramic bypass cap) is away from you as you look at the socket) to R on the comms board, with the cables attached of course,
I

KDuncan Wrote:
-------------------------------------------------------
> I also tried removing the PIC and
> jumping those two pins, but got nowhere. Could the
> gauge make a difference for that? I was using
> 20-gauge copper for the bridging.

Just to make it clear, after you jumper those two pins, you test by opening up your favorite communication software and typing some characters to see if they echo back. You're essentially repeating test 2 from the PowerComms board, except instead of having a short jumper between the tx -> rx on the PowerComms board, the loop goes from PowerComms TX -> UCB RX -> PIC socket 7 -> PIC socket 8 -> UCB TX -> PowerComms RX. Jumpering those two pins won't allow the stepper test to work, since it tries to talk to the PIC you've now removed. All it will tell you is that the signal makes it all the way to the PIC socket and back.

Zach: I noticed the BOM tools section is missing a multimeter. Plenty to choose from on amazon and, well, everywhere else I'm sure.

actually jumpering the transmit to receive without the pic does bring up the stepper window, but all functions won't work. I've done it many times in the past. I wonder if anyone has tried to use a null modem cable instead of a straight through cable?

Kai,

> Test one works like a charm. Ditto on two.
> Three, however, is the crash and burn.

OK. The usual cause of that is serial wiring issues of some sort. There *is* a kind of "Test 2 1/2" using the "poke" tool which we should document, but at present it only exists under Linux or Mac OS X. Are you running a Linux host PC, or Windows, or OS X? And are you using a real serial port or a USB-to-Serial converter? I keep saying I'll port that poke code to Windows, but I never quite get around to it!

If you are running Linux or OS X, check out the firmware tools from Subversion and then cd into the firmware/tools directory and type

make

That should build a 'poke' executable, right there in that directory. You can then try something like:

echo 0 | ./poke -d 2 -t /dev/ttyS0 -v

to ask the PIC what version of firmware it has in it. Use /dev/ttyUSB0 or similar if you have a USB-to-Serial converter.

[I know these aren't really good clear instructions, apologies, but you said you're a computer guy, so maybe they are enough for you for now, I'm short on time right now... ]

> 'Receive error, re-sending: Timeout receiving byte'.

Yes, that means the PC just isn't 'hearing' anything coming back in on the serial network. As Zach said, double and triple check your wiring. And let us know what versions of the boards you have, please.

I'm off to learn more Spanish, may be back later this evening...

Jonathan

I've got 1.2.1 on everything, PowerComm and UCB alike. I've just redone the Hyperterminal tests and here's what I've got;

- No response with the PowComm->UCB configuration
- Response when using each of my cables to short the PowComm (http://www.reprap.org/bin/view/Main/DarwinPowerAndCommunicationsCard_1_2#Testing_Round_2)

I'm running Windows but I do have a liveCD somewhere around here. I'll have to wait until the weekend do run through that though. In the meantime, I'm going to double- and triplecheck my solder joints/wiring just to be on the safe side. It doesn't look like anything's missing from the board aside from the bridge and its diodes, but I'll doublecheck that as well. Thanks.

-Kai

Well you know the Max232, solder joints and RS232 cable from the computer are good. Do you have an old computer case with the 2 pin female connectors on twisted wires. I soldered two sets of two of these together, being sure put heat shrink on and then slide it over the solder connection and I shrunk it to insulate the solder connections. They make great contact with the header pins. Do you have continuity between the R pin on the comm board and pin 8 of the Pic on the UCB? Then check for continuity from the T pin on the comm board to pin 7 on the PIC on the UCB,is there continuity? of course, make sure the cables are connecting these pins! You do have the LED lit on the UCB when it powered up, yes? The diodes and L298 aren't important for a comm check, the pic just needs 5VDC

Let's make this a simple as possible.
You say that your Power comm board hyperterminal test works. Good.
Connect up the tx and rx cables that go to your UCB to the power comm board only.
Take a lead off of a resistor or capacitor carefully slide this bare wire into the signal side (thats the wire that connects to the pins you shorted together when you did the power comm hyperterminal test.) of both female connectors of your cables (the connectors that go to the UCB ).
Rerun the hyperterminal test. If this works your cables are ok.
reconnect the cables to the UCB.
If removing the pic,shorting the appropriate wires on the pic socket and running the hyperterminal test doesn't work there are only 2 possibilities the connectors of the cables between the boards are mis wired/mis connected, or you have a cold solder joint/ open PCB trace (unlikely). Since there are only four solder joints resolder them and test again.

Until all of the above works you are wasting your time trying to move forward.

Good luck,

Dan

Of course getting a successful lookback, even from the PIC pins, does not rule out the cables being crossed over. I.e. RX and TX swapped.

---

[www.hydraraptor.blogspot.com]

Dan P, your windows setup write up was the best organized I've ever seen and it should be the main write-up in the section, "Installing Software on Windows XP". Bravo, all the bases were covered!!!

Hi,

Like Kai, i'm having trouble testing my UCB. All previous tests worked fine so i tried the stepper exerciser test. When i drag the axis position bar everything works well for a few seconds (i.e. LED starts flashing). Then i get an error message :
'Update Exception: java.io.IOException: Device at address 3 not present'. Eventually the software crashes.
Could any one tell me what's going wrong? Is it a software problem or just a loose connection somewhere?

Evan,

This is a new and separate issue (different error message, and it is on someone else's hardware). So, it would probably have been better if this had been asked in a new thread.

It's helpful to provide fuller info on your setup when reporting issues: PCB version, PowerComm version (and confirm it passed all its tests), RepRap host software version, and details of what host PC you are using (Windows, Linux, Mac OS X) and whether or not you have a serial port or a USB-to-Serial converter.

Also, can you be more specific about what:

> Eventually the software crashes.

really looks like? Host PC bursts into flames? GUI disappears or hangs? Are there any error message(s) in the terminal window from which it started? Something else happens?? :-)

> Device at address 3 nor present.

That is the default address of the Y axis PIC... which shouldn't be involved, if you programmed your PIC with X axis firmware. Interesting.

Can you please:

(1) confirm that you programmed the PIC with stepmotor.hex, (and say where you got that .hex file from) and

(2) also confirm that when you run the Stepper Exerciser UI only the X axis slider is in high contrast, the Y and Z are (should be!) be greyed out?

If you are using Linux, can you poke the StepperController repeatedly and successfully using echo 0? If so, can you run dance.sh to poke it into moving back and forth reliably? These are (somewhat underdocumented) "Test 2.5" things we need to describe better...

If you understand software debugging better than electronics, and want to dig a little deeper, you can also try setting CommDebug=true in the ~/.reprap/reprap.properties file and looking at the comms information you will then see in the terminal window from which the host software was started. Look especially for any transmitted packets heading for address 3... there shouldn't be any at this stage, all packets from the host should be addressed to SNAP address 2, the X axis board/PIC.

Thanks,

Jonathan

Edited 1 time(s). Last edit at 07/26/2007 08:28PM by Jonathan Marsden.

Thanks for the kind words.

Best,
Dan

Okay, update time. First off, I did find a flaw on my main testing board, flipped R7 and R4. Switched to a new board but the problem persists. EXCEPT now I can jump pins 7 and 8 and get the HT test going. With a programmed and verified PIC, nothing.

At this point it'd almost have to be the PIC, right?

-Kai

You could still have your TX and RX crossed and get a successful loop back test. Are you sure TX on the comms board goes to RX on the UCB and visa versa?

---

[www.hydraraptor.blogspot.com]

nophead, yeah, the cables are pointing the right way.

I just tried a fresh PIC with a twice-verified programming and got nowhere. Any ideas?

-Kai

Well I think all the PIC needs to respond is power. It should have 5V between pins 14 and 5.

---

[www.hydraraptor.blogspot.com]

5 volts between 5 and 14, check.

-Kai

Kai,

> 5 volts between 5 and 14, check.

If the Debug LED lights on the Stepper Controller board, then the PIC has power *and* is running the RepRap firmware. The chances of the PIC "accidentally" lighting that LED are extremely low. So the likely explanation is very much still some sort of serial wiring issue, not the PIC.

If you have a "null modem" serial cable or a null modem adaptor or similar, it might be worth trying it just in case Tx and Rx are somehow reversed. Ditto with trying reversing the wires on the UCB serial connectors (one connector at a time!) just in case. If you are using the recommended 2pin housing for those connections, you should be able to pop the pins out, reverse them and stick them back in again, then plug the newly reversed connector back into the UCB.

Worst case, there are 4 2pin connectors involved (2 on PowerComms and 2 on UC. You're sure they are wired to the correct places, so that's already checked. Leaving one connector (say the T connector on the PowerComms board) alone, it would be slightly boring, but systematically trying all 8 combinations for the remaining 3 connectors (normal and reversed) is possible, and it won't damage anything to try that, if you have the patience! As soon as you find one combination that works, you can stop testing pin reversals anyway :-)

Other less likely things: (a) you do have the sync (P3) connector jumpered, right? Also (b) running poke rather than the Java host software might just possibly give us some extra info about what is happening, though IMO that's not a really strong possibility.

Jonathan

Jonathon,
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. It might be worth just swapping them over as a quick test.

I must admit I can't think of any other explanation. All you need is a working PIC programmed with the correct code, 5V supply and comms wired correctly to get some response.

It is conceivable but very unlikely that the powercomms board is not putting out the correct logic levels such that it is good enough to drive itself but not the PIC.

Kai,
I am not sure what you mean by R7 and R4 "flipped". They are both the same value and polarity does not matter with resistors.

---

[www.hydraraptor.blogspot.com]