frustrating Universal Controller Board issue

I am having a horrible time trying to get my Universal Controller Board to talk to the PC, and I would greatly appreciate any ideas people might have for how to get it working, or at least find a way to troubleshoot the issue more effectively.

I have tested my Power/Comms board in Windows and Linux, and am able to get it to echo back to me the characters I send when Transmit and Receive are connected together, and when I connect my partially-completed UCB (phase 1 of soldering done) with PIC installed, the LED on the UCB lights up, but in Linux using the main.java from within Exclipse, I get a noSuchPortException when I try the stepper exerciser. When I try it within Windows using Reprap.jar (for some reason the software in Eclipse can't find Main), I get a whole screen of timeout errors on the command line, and the exerciser window never appears.

I am using OpenSuSE Linux and Windows XP, in case that has any meaning to the issue, and I am using fresh new builds of the firmware.

The timeout errors I get in Windows are as follows:
-----------below pasted from command line-------------------
RepRap preference: MovementSpeedZ not found in either preference file.
Opening port COM1
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7
Receive error, re-sending: Timeout receiving byte
0->8: 0
CRC error
Receive error, re-sending: CRC error
0->8: 0
Receive error, re-sending: Timeout receiving byte
0->8: 0
Device at address 8 not present
Receive error, re-sending: Timeout receiving byte
0->2: e 22
CRC error
Receive error, re-sending: CRC error
0->2: e 22
Receive error, re-sending: Timeout receiving byte
0->2: e 22
Receive error, re-sending: Timeout receiving byte
0->2: 3 88 13
Receive error, re-sending: Timeout receiving byte
0->2: 3 88 13
Receive error, re-sending: Timeout receiving byte
0->2: 3 88 13
Receive error, re-sending: Timeout receiving byte
0->2: 3 88 13
Receive error, re-sending: Timeout receiving byte
0->2: 3 88 13
Receive error, re-sending: Timeout receiving byte
0->2: 3 88 13
Receive error, re-sending: Timeout receiving byte
0->2: 3 88 13
Receive error, re-sending: Timeout receiving byte
0->2: 3 88 13
sendMessage error - retrying
-------------above pasted from command line-------------

Anyone have any ideas? This is driving me absolutely batty.

A possibly half-baked idea... try using the poke tool to see you can communicate using SNAP with the UCB? It should be in

~/workspace/firmware/tools

If all you see in there is poke.cc and not poke, type

make

and it should get built. Then

./poke -h

will give you its help message.

It seems to me you are at the borderline of "is this a serial comms issue or is this a SNAP protocol issue", and judicious use of poke may provide clues as to which is the case.

I expect to be hooking up my own boards in a week or two, at which point no doubt I'll have more specifics to share... but probably too late to help you!

Jonathan

Thanks Jonathan. I'll try this out and let you know what I find out.

Here was my post on the subject
[builders.reprap.org]
And this is so you don't have to go to the link to see the good part

I found the right location for it's properties file. After putting back the win32 comms.jar and moving the properties to the lib dir, it worked just fine.
For my system, as an example if you want to tweak the wiki a bit..
C:\Program Files\Java\j2re1.4.2_13\lib\javax.comm.properties
C:\Program Files\Java\j2re1.4.2_13\lib\ext\comm.jar

okay, i'm experiencing the same problem. i messed around with poke for a bit. first, i tried it and it showed the transmit data (thats what it puts in <>) and there was no response! i double checked my cables, and one was plugged into the wrong part. argh! i plugged it into the right part, and re-ran the poke command to success!

hoeken@ubuntu:~/firmware/tools$ echo 0 |./poke -d 2 -t /dev/ttyUSB0 -v
<54><51><31><02><00><00>[54][52][30][00][02][bd][ACK Received]

so, apparently the firmware and the comms are working!

now, back to the RepRap jar software. still wasnt working! i decided to open the prefs, where I discovered that the wrong settings were there. i changed it to /dev/ttyUSB0 (my usb -> serial adaptor)

i then opened the stepper exerciser dialogue.... BINGO! it pulled up the screen very quickly. thats where i ran into trouble again. i guess it detected the X axis (address 2), but none of the others. makes sense, its the only one plugged in. however, i dragged the axis slider and nothing happened. here is the output from that little adventure:

=========================================
Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7
RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0
Device at address 8 not present
Device at address 3 not present
Device at address 4 not present
Opening port /dev/ttyUSB0

figuring that the board works, and its my stupidity that is causing it, i re-read the universal controller instructions. the part about endstops catches my eye. short the pins, it says. having left out that step, i short them. i come back to the panel, drag the bar. nothing. drag the speed slider. then suddenly, the light begins to flash!!! the 'actual postition' slider moves, and my little board seems to be working!!!

yay!

moral of the story: double check everything!

Lol, yeah.. I remember the same kind of steps with those pins being an important point I made sure of long before I got it to work. Glad you got it.

Zach - are you referring to using poke with or without the UCB attached to the Power/Comms board? In all my tests with just the Power/Comms board, everything seems fine, but I can't get the software to talk to the UCB. Any ideas on how I can specifically test that connection? Will poke work for that, or just for the serial communication with the Power/Comms board?

Searching through the forums, I have also seen a few references to noise in the communications, and solving that by adding a capacitor - was this for noise in the serial communication to the PC, or board-to-board? If it was board-to-board, how can I diagnose it and where would I put what kind of capacitor to fix it?

Bartlee - I tried putting those files in the correct locations last night, but it didn't help with the issue when using Reprap.jar with rxtx. I tried using the software from Eclipse, but I appear to have conflicting versions of my java files. I'll try reinstalling my java and see if your fix helps.

Eric, poke is trying to talk to the PICs on the ring, so if you see a reply from a PIC (the stuff in [] in Zach's post), the UCB is working, at least as far as talking to the network using the right protocol.

I believe the zero in the "echo 0" is the SNAP "GetVersion" command, asking all boards in the ring to acknowledge it.

Jonathan

yup. i'm going to update the troubleshooting pages soon to include a better description on how to test each board. basically, you can test the comms board to make sure it works (short tx/rx)

to test the board itself, the poke command is good. if you do it, but dont get anything back its most likely a connection. the token ring is broken, so nothing get through.

if you run poke, and get the right response back, then you're good.

OK, that's definitely helpful info. I know I have run "echo 0|./poke -d 2 -t /dev/ttyS0 -v -w" and received a response, but I'm pretty sure that was with the UCB disconnected and the Power/Comms board T and R on loopback. I will make sure the UCB is connected and try again and see what happens. Also, I know that I have a working electrical connection between the two boards, because I have pulled the MAX232 and PIC and tried a connectivity test between the T pin of the socket on the Power/Comms board and the R pin of the socket on the UCB and gotten a good connection (and vice versa)... So if poke gets a reply with the UCB attached, that would mean a software issue, yes?

If you get a response from the poke command with T and R shorted (looped back) on the PowerComm board, the stuff being sent (in <>s) should exactly equal the stuff received (in []s). What goes out, comes right back in, i.e., loopback! That tests the MAX232 chip and (some of) the PowerComm board wiring.

When you have a UCB (or several) out there in the network, they should actually "talk" to your host PC using SNAP. They each respond on a different device address (the "2" after the -d in Zach's sample command was to address the 0 command to device 2, which is the xaxis controller i.e. the UCB runnning stepmotor.hex firmware). You could test a whole ring full of UCB-based devices (each with different firmware in its PIC) by doing something like:

for i in 2 3 4 5 ; do echo 0 |./poke -d $i -t /dev/ttyUSB0 -v ; done

which would send the 0 command to each of devices 2, 3, 4 and 5 in sequence (these are made-up example addresses only!).

I've not looked at the SNAP code enough to know whether there is some sort of "broadcast address" to send a single command to "all devices" or not (I'll probably wait until I have some populated boards to test for that level of detail :-)

For right now, the point is: (a) the output from poke will be different with a UCB in the ring vs with a looped back empty ring; and (b) get the device address right for the firmware on it, or your UCB won't respond the way you expect.

It would definitely be helpful to have some SNAP documentation for people who don't want to read the source code, but do want to understand something of the network at the protocol layer for troubleshooting and experimenting... but no, I'm not volunteering to write it any time soon, so for now it is "RTSL" -- Read The Source, Luke" I'm afraid :-)

Jonathan

OK... I just tried the "echo 0 |./poke -d 2 -t /dev/ttyS0 -v" command, and got the same results Zach did, so at least I know that the UCB is reachable. Now I just have to figure out why the Reprap software can't talk to it. In the preferences window in the Reprap software, I have "/dev/ttyS0" listed as the port - is there anywhere else I should look?

If you get an ACK, you're good comm wise (it actually says ACK). What the unit does after that is application and hardware related and they have to be right. You can use poke to start motors spinning and stop them reverse them etc. Like he said peruse the source, they are all pretty similar.

Eric, bartlee45 is right -- getting that ACK means the PIC is happy, and talking correctly on your newly constructed SNAP network. This is good :-)

Why Reprap won't talk to it... hmmm.... it's probably something simple I am missing. So... here are some complicated possibilities to consider!!

(1) You're using my "conversion to rxtx libs", which is not official code yet (not checked in to Subversion). I *think* Zach was using those libs too, but it might not hurt to revert back to official host code and see if using the Sun java comms stuff makes any difference? It's *always* a good idea to go back to the official unmodified codebase when you hit issues, even though in this case if it works, it means my own mod is what broke things!

(2) Also if for some reason you edited low level comms properties by hand, the file will be gnu.io.properties with rxtx and in javax.comm.properties with Sun comms libs. You *shouldn't* need to hack those, but if you do, well, make sure you hack the right one for your comms libs :-)

(3) You and Zach are at the same point, except he has Java-to-network comms and you, apparently, don't yet. Maybe if the two of you work together and chat on #reprap for a while, both seated at your respective reprap host PCs, you'll figure out the significant difference in your setups?

(4) Has anyone looked at recoding poke in Java? If reasonably doable, that would be good, since then it would be more portable, and also would be using the same serial comms libs that the reprap host software uses.

Jonathan

theres already some pretty good info in the wiki, its just a bit buried. one of the things we need to work on is exposing more of this documentation.

[reprap.org]
[reprap.org]

Wow, Zach -- great info, thanks! StepperMotorController looks very useful. It deserves to be more widely known about and read. And ExtruderController [reprap.org] has a similar listing for Extruder boards (though a couple of the commands there apparently lack parameter/return info that could be helpful).

Thinking about why they are not more widely read already... I think if they had been named StepperMotorAPI and ExtruderAPI or (more accurately, since this is a network protocol, not really an API) StepperMotorCommandProtocol and ExtruderCommandProtocol, or similar, I would probably have already clicked on such a WikiWord. "StepperMotor" feels hardware-ish to me, so I never clicked, I'm not yet ready to learn all about stepper motor hardware!

If I could check my work, I'd add a couple of examples to each page of how to generate some of the commands using poke. It's pretty clear to me how to do that from the existing pages, I *think*... but I have an unfair advantage -- I've also skim-read the host software SNAP sources and poke.cc, which ideally shouldn't be required reading for troubleshooting at this level.

I'd found the SNAPComms one earlier, but (for me) it is a bit too much "just a dump of the comments" to be useful for troubleshooting without reading the actual code at the same time.

Jonathan

Thanks for your help, guys. Now that I know that the hardware is capable of talking correctly, I can concentrate on resolving software issues. I think part of the issue I am having with software is related to installing, uninstalling, and reinstalling various versions of Java while troubleshooting. I'll try clearing eveything out and starting from scratch again to see if that takes care of it.

Eric, the host software stuff I can definitely help with, if you see me in #reprap and want real-time advice as you do the reinstall, just ask.

Incidentally I started on a (quick and dirty) package of the host software last night, but Adrian's recent changes to Preferences broke my .jar approach, and I didn't finish "fixing his fixes" to (re-)allow running from .jar files... that may be completed tonight, or is likely to happen somewhere this weekend if not.

Jonathan

SUCCESS!! well, mostly, anyhow, and that's a heck of a lot better than I was doing before.

Thanks to Jonathan's assistance in getting the correct version of java on my PC (apparently 1.4.2 doesn't work right, or at least not on my system - 1.5 works awesome though), making sure the system can see the java OK, and getting all of the right libraries in the right locations, I finally got the software to talk to the UCB!! I would strongly suggest adding some troubleshooting with poke into the testing instructions for the UCB - by entering "echo 1 2 |./poke -d 2 -t /dev/ttyS0 -v" (from what I understand, this is a basic move command (1 = move forward, 2 = speed) I was able to get the LED to blink (albeit rather slowly, since 2 is a rather slow speed setting), and therefore I knew that the hardware was essentially OK, and that it was entirely a software issue I was dealing with. This might help people at least pin down whether they are having a software issue or a hardware issue.

I also conected my Sherline stepper motor and tried the stepper exerciser, and it wiggled the motor, but it did not actually turn. I am assuming that this is due to either not enough power or incorrect timing - at one of the speed settings, if I gently nudged the axle while it was wiggling, it would start turning, but would just wiggle as soon as I stopped putting pressure on it. Any ideas on what I would need to do to fix this?

To clarify: the "generic" Java 1.4.2 installed to /usr/local had issues, at least in the state I found it in. The Linux distribution (OpenSuSE in this case) -packaged Java 1.5.0 worked great.

Also... Eric treated me to lunch, and I had an idea while working at his PC which may help me get a simple host software package out... so it was a good day all around :-)

Jonathan

awww... i wish there were RepRappers in my area i could meet up with. thats really awesome that you live near each other like that. i'm very excited for the day when there are RepRap user groups meeting up regularly. that will be very cool.

Zach,

Well... "all" we have to do is get it so it replicates, and package/document things well enough that moderately skilled people (as opposed to expert tinkerers!) can both run the software and build the hardware! Then I strongly suspect those new users will start to appear, and user groups will form. Perhaps faster than we can keep up with!!

Meanwhile, I suppose Eric and I just accidentally started the "Southern California RepRap User Group", or SCRUG :-)

Jonathan

YAY! GO SCRUG!!!

Does this mean I'll have to design a T-shirt now?

Back on more serious issues, I think I found out the cause of my stepper motor issue, but not yet the solution - it appears that the steppers are not getting enough power - if there is absolutely no friction on the shaft, it now turns, but if anything even thinks about touching the shaft, it goes back to wiggling. So now I gotta figure out why it's not getting enough power.

I think that I have the same problem as Eric. I can actually get the motors to run, but only a bit of friction and they stop. Also, running multiple motors (yay, I've got all the boards finally done now :-) does not improve on performance ...

Joost

The T-shirt design can wait :-)

Maybe those huge series resistors of yours are just too high a value?? :-)

Maybe try two in parallel per coil, halving the effective resistance?? Or is that too much of a risk to the stepper? I suspect not, unless you let it get *really* hot, your stepper should survive. But then, that's easy for me to say, seeing as it is *your* stepper :-)

Jonathan

Incidentally... maybe we should start a new forum thread, since this is no longer a "frustrating UCB issue", more a "how to get Eric's non-standard steppers to rotate" issue at this point?

\

Status update - Thanks to Jonathan pointing out the 'XAxisTorque' setting in the preferences, I was able to get my motor spinning! I set it to 75% and it's turning powerfully enough that I can't stop it by grabbing the shaft... It seems to work at all speeds and even in reverse now! I am truly a happy camper.

So I think any new issues would go in a different thread anyways.

Oh, one more thing - apparently Joost found out that if you have more than one stepper connected, the second one won't move unless you connect the 'sync' pins on the stepper controllers - pin 1 on x axis to pin 2 on y axis, pin 1 on y to pin 2 on z, etc. until you make a complete loop. Helpful info when troubleshooting.

Eric,

Can you tell me your steppers specs so that I can compare against my Mill steppers.

Basically winding resistance and current is what I need. If you can also add the P/N and posibly the datasheet that would be great.

Are you running them at 12V?


thanks...

Luis,

Did you try increasing XAxisTorque (make sure your L298N is heatsinked)?

An earlier post from Eric [forums.reprap.org] pointed at [www.sherlinedirect.com] which has links to datasheets for two variants of the Sherline stepper. I'm guessing the later one is the one Eric has.

I know Eric has some big honking 10W resistors in series with the stepper coils, because I was there when he hooked it up :-) From, memory, they are 2 ohm 10W I think??

Also check [forums.reprap.org] this thread where Zach posted advice from Adrian that could be relevant to you.

Jonathan

Jonathan,

Thanks for replying... Actually I tested all my cards already with a stepper that has 10 ohm resistance and everything worked perfect. Unfortunately I only have one of those otherwise I would have use them on my mill instead of the ones there which are 2.5 ohm coils.

I guess I'll have to go the same route (honking resistor) when I plug everything together on the CNC Mill and I use those 2.5 ohm coil steppers.

I'm actually studying the posibility to chop the current using PWM by hacking the universal card adding a LM339 comparator. But if that seems too much of a hassle I'll go for the resistor in series.