ANother UCB issue

Hi everyone, sorry to heap another person on to the pile of users having UCB issues but count me in.

After a string of successes to this point I am a little stuck with the UCB, I have board 1.2.1 for UCB and PCOM and am running reprapv0.8.1. Hex files were downloaded from sourceforge. All running on ubuntu

So my PCOM went together great, got the echo test and host software recognized then built my UCB for stepper. All voltage tested well according to instructions and flashed the PIC successfully. All was going well, got the debug LED but when I connected to the software to try test 2 of instructions and tried to open the stepper exerciser I get the following error:

Receive error, re-sending: Timeout receiving byte
0->8: 0

I was a little confused by this because I thought that device 8 was the extruder but someone correct me if I am wrong. I tried the null modem and a ton of sequential wire swaps to no avail. I then built the other 2 UCBs and flashed the PICs with the Y and Z hex but get the same thing.

I actually just noticed as I was writing this that my PICs are 16F648A's.... not 16F628, not sure how this happened as I used the BOM generator, would this be the problem? I don't know much about PIC programming but even though the number doesn't match I would take the LED lighting up as a good sign???

Thanks in advance and sorry to add to the UCB woes.

TimmyH79 Wrote:
> Receive error, re-sending: Timeout receiving byte
> 0->8: 0

Hm, this doesn't sound familiar, but I'm not in front of my machine right now to check. 8 is the extruder, as you expected. X, Y, and Z should be 2, 3, and 4, respectively.

> I actually just noticed as I was writing this that
> my PICs are 16F648A's.... not 16F628, not sure how
> this happened as I used the BOM generator, would
> this be the problem?

It should be fine. Reprap originally specified the 628s, but we recently changed the BOM to specify the 648s instead to give us some room to grow. They're the same thing but with more memory and flash. You should be able to use the 628 firmware in the 648 unmodified, and I think Zach reported that it works fine. The LED is a good sign that yours programmed successfully too.

TimmyH79,

I'm starting to wonder how my own Stepper Controller ever managed to work, so many people are having this issue! We'll find it and solve it. I almost want my next two UCBs to *fail*, so I can experience this issue first hand and troubleshoot it! I'm awaiting parts from Futurlec at the moment.

The 16F648A is a (slightly) 'bigger better' step up from the 16F628, and there has been discussion that the next rev (or so) of our firmware may become big enough to need the extra space. Furthermore, using a 16F648A may allow us to use the current production version of SDCC rather than an ancient buggy development version. Cost difference is only a few cents per PIC (US$0.42 on Mouser, probably less elsewhere). So the BOM now lists 16F648A PICs. We have verified that the current firmware works fine in a 16F648A. And yes, the LED lighting up is a good sign :-)

Since you are running Ubuntu Linux, you are definitely a candidate for running the 'poke' tool. Grab the firmware using svn, then cd into firmware/tools and type make (you'll need gcc, g++, binutils, bison and flex installed). This should create an executable file called poke in there. Then you can try:

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

and tell us what you see. Replace ttyS0 with ttyUSB0 or whatever your serial device name is. For the first real serial port (at 0x3F8 with IRQ4, the DOS "standard" COM1 port), ttyS0 is correct.

I think the host code checks for the presence of all three axis controllers and the extruder, so seeing an attempt to contact SNAP address 8 is not a problem; however, if you are seeing that error message, it *does* indicate a problem... the serial ring does not seem to be complete, so what the PC is sending out is not coming back to it after all PICs in the network (currently just your X axis controller PIC at address 2) have ignored it and passed it on as not being for them. poke should confirm that diagnosis... in which case we are back to "check and recheck your wiring", I'm afraid.

Jonathan

Just to confirm, I get the error TimmyH79 is reporting if I run the RepRap host software with no electronics connected to the host PC at all. So this really does look a lot like a wiring issue.

Jonathan

I was afraid it was going to be a wiring issue, maybe I will try and remake my Tx/Rx connectors with heavier gauge wire, I used 22 now which went in to the connectors fine and I couldn't pull them out with moderate force but who knows..

Johnathan, just out of curiosity do you get the same error if you have a non-jumpered PCOM board plugged in (just empty Tx/Rx)? I didn't try that and might be a help.

I will hit the desk again tonight to continue troubleshooting and will let you know. One thing that might be helpful for others is to make a wiring diagram of the board interconnections. Maybe it exists but I was not able to find it?

If you were to put the ends of the interconnects side by side, looking at the holes with the tabs up should the wires go (R,B,R,B or R,B,B,R) This is a really basic question I know but since I couldn't find the diagram I just tried to figure it out looking at the picture in the instructions.

Thanks again to everyone for all of your help, this is a great project.

I will also install the poke utility just to try it that avenue as well.

Your wires are probably fine. 22 gauge is plenty, there's no need to go thicker. If you're worried about them, just do a few checks to convince yourself that the wires are good. Only one wire of the two-wire cable actually matters, the other one is a redundant ground. Try using each of your cables as a jumper on the PCOM board. If it passes the echo test with the wire, it's good.

You can also check the wires with a multimeter. The easy way is to take an extra set of pin headers that you were going to use for your second stepper and plug them into each end of your cable. This effectively turns your female-to-female cable into a male-to-male cable that has exposed pins that are easy to hit with your multimeter. If you don't have extra connectors, just touch the connector through the small hole in the side of the housing where the locking tab on the connector snaps into place. Hope that makes sense.

The cables should be straight: pin 1 would be red on both ends, pin 2 would be black on both ends, so you'd see RBRB if you held them together. While you're at it, make sure the headers on the PCBs are installed the right way. They're labled TG, RG, or possibly GR and GT ("R" for receive, "T" for transmit, and "G" for ground). Think of it as connecting four separate wires instead of two cables. Plug in the cables (with the power off) and then trace each conductor. The "T" on PCOM should go to the "R" on UCB. The "R" on the PCOM should go to the "T" on the UCB. The other two "G"s on the PCOM should connect to "G"s on the UCB.

I haven't seen a wiring diagram like you're looking for, but it sounds like a good idea.

this definitely appears to be a wiring issue. there are a few things we as a project need to do:

1. add better debug / diagnostics to the software. it should recognize when no data at all is getting through and display an error message.

2. create a wiki page on proper wiring, as it seems this is rather confusing to people. we need a nice, simple graphic and some pictures as well.

3. for v1.3 of the universal board / powercomms board, we need to add debug LEDs on rx/tx so you know whats going on.

4. for v1.3 of the universal board / powercomms board we should switch to pre-made cables. making cables is a time-consuming process and really doesnt save us much money at all. it also introduces lots of places to make errors. i would suggest we move to using ethernet cables. then it simply becomes a matter of plugging the boards together.

Well the good news is that I made a stupid mistake, looked at pictures in instructions rather than silkscreen and didn't notice that the Rx/Tx tabs are on the same side for the UCB now.

So the original error message went away but now I get: sendMessage error - retrying (repeats)

I tested both cables by doing an echo test with each and they were successful, next I tried to download the poke utility but when I go to the svn repository I can navigate to the firmware folder but when I try and expand the tools folder eclipse just sits at "fetching children of tools 0%" until it times out and says "folder reprap/firmware/tools does not exist remotely". Has anyone visited this folder recently. Not sure what might be wrong there because I can navigate around many of the other folders just fine.

I feel like I am little closer and will soon be out of your hair for a little while again!

Thanks
Tim

> I tried to download the poke utility but when I go to the svn repository I can
> navigate to the firmware folder but when I try and expand the tools folder eclipse
> just sits at "fetching children of tools 0%" until it times out and says
> "folder reprap/firmware/tools does not exist remotely".

Strange. Ignore Eclipse, it is big and complicated (IMO). In a terminal (command shell) window, cd into ~/reprap (or ~/workspace, or whatever is one level above "firmware" and "Reprap" for your setup!), and do

$ SVNURL="https://reprap.svn.sourceforge.net/svnroot/reprap/trunk/reprap"
$ svn co $SVNURL/firmware

(The initial $ signs are the shell prompt, do not type them in!)

This should check everything out into your firmware directory just fine. I tried it a few moments ago, and it created a(nother!) complete local working copy here, including the firmware/tools directory.

Jonathan

ZachHoeken Wrote:
-------------------------------------------------------
> 1. add better debug / diagnostics to the software.
> it should recognize when no data at all is
> getting through and display an error message.

Agreed.

> 2. create a wiki page on proper wiring, as it
> seems this is rather confusing to people. we need
> a nice, simple graphic and some pictures as well.

We also need a page for troubleshooting the connection once the stepper test fails. Unless we make a lot of changes to the stepper test, I think we're always going to have a lot of problems in this step, cause it's a biggie. We've gone from seeing if a LED works to adding in java, java's serial library which I trust not at all, serial port permissions, one or two new cables, and the TX/RX traces.

Speaking of which, are we still moving to mediawiki?

yeah, we're still moving to mediawiki... the script is almost done, but things have gotten crazy for me (i moved to a new apartment this week.)

i'll definitely be doing a bunch of work this weekend and next week to get our web infrastructure up and running. also, 1.3 of the boards should be coming up soon, so that should be fun. i'll start a new thread for that.

> for v1.3 of the universal board / powercomms board we should switch to pre-made
> cables. making cables is a time-consuming process and really doesnt save us much
> money at all. it also introduces lots of places to make errors. i would suggest
> we move to using ethernet cables.

If we move to Arduino or similar, why would we still want serial connections at all? The thing has a TCP/IP stack... we should indeed use an Ethernet cable... and talk to it as a network device :-)

Jonathan

switching to arduino is a MAJOR task that requires rewriting the firmware, host software, and making completely different boards. its something we should definitely do in the far future, but for the near future, it just doesn't make sense and distracts us from the primary goal of an open source 3D printer.

switching the type of connector we're using is an easy, weekend project that requires no changes to code, only to the PCBs.

that being said, i'm definitely in favor of a long-term switch to an arduino based platform.

Ugh. I don't really understand the push for moving to Arduino or any of the other education-oriented controllers. One of the nice things about the Reprap design is all the individual pieces are simple and the computer does all the hard work. Most people won't have a need to modify the firmware, and if they do they're probably more likely to be familiar with C than with Arduino's language (or basic stamp, picaxe, whatever). If someone wants to hook one of those up to the ring, SNAP won't know or care that it's talking to a mixed batch of processors.

By the same reasoning, I'd run from TCP as fast as possible. It takes a bunch of extra code complexity and hardware and doesn't buy us much of anything. I like these things simple, reliable, and cheap.

Just my $.02.