Stepper Exercisor, maybe, maybe not

I got my new USB-R232 cable that works with linux. When I tried to establish the stepper exercisor, I got this

Opening port /dev/ttyUSB0
Experimental: JNI_OnLoad called.
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
Receive error, re-sending: Timeout receiving byte
0->8: 0
When I pulled the pic and jumpered pin 7 to 8, the stepper window appeared. I de-energize, replaced the pic and downloaded reprap-host-0.8.1. When I started stepper, the window appeared and I plugged in the stepper and played with the rotation speed. It would spin until the actual position was equal to the set position. I was so thrilled! This morning, I started the computer in linux using the same software, cards and connections and this is what I got, ( I didn't forget the jumpers for the gnd input for the LS)

Opening port /dev/ttyUSB0
Experimental: JNI_OnLoad called.
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
Receive error, re-sending: Timeout receiving byte
0->8: 0
I don't know what else to do. This is what it was doing in Windows XP!

basically that error means that the packet isnt getting around the token ring. triple-check all your tx and rx connectors. if theres a loose one, fix it

if its something else, i'm not sure... try powering your reprap down, unplug/replug your usb cable, and then power it up.

Actually , I have all three axis's turning! The motors are assume! I think if I change the stepmotor.h file from Define Maxsensor bit of A or B byte to define Maxsensor !bit# of A or byte. This will correct for my reverse polarity optostops. I am reading the manual on SDCC so I have an understanding of the compiler. I know we can use the steps/mm in the preferece, but I would rather use half step. I believe all we do is remove making halfstep a comment and it will choose the half step option

As Zach said, this sounds like a bad connection somewhere in the serial ring network -- a dry solder joint, or a wire not crimped fully to a crimp-on connector, maybe?

I'd suggest going back to testing with poke until that works, and only then running the host software. If you have more than one UCB, go back to a "network" of just the PowerComms board and one UCB, so you have minimal wiring to check. Scale up only when that initial minimal network is reliably working.

In one sense, it's good that you are seeing similar things in both OSes -- that means the host software and libraries are (probably) doing their job on both platforms, and the underlying issue is (probably) in your soldering or electronics construction, not a new software flaw we need to track down.

Jonathan

Our posts "crossed"! Can you let us know how you solved the earlier issue with the serial ring, so others can benefit from your work?

Jonathan

I truly don't know. The new software worked great on Thursday night, but friday morning I was getting no return bytes. I tried it friday afternoon and viola! I then daisy chained the other two axis's and had three spinning motors. I connected Tx from comm to RX on X axis, Tx on X axis to Rx on Y axis, Tx from Y axis to Rx on Z axis and Tx on Z axis to Rx on the comm board. I of course, cowbell jumpered all 6 max and min switch to ground. I energized and started the stepper exerciser. Now on Saturday morning, it is still working. The software gods have smiled on me! All of my comm cables are twisted connectors from old computer cases. I am making up shielded cables for the permanent installation though. I could get the null modem cable and the other laptop out and see if I can see the transmitted characters and convert them into binary bytes and check the snap protocol, but let me enjoy the spinning motors for a little while.

Well I turned off the power and then just to be sure, re-energized it and started the reprap software and behold, I have the same error! I can't believe this, I CHANGED NOTHING! I only closed the reprap program and de-energized the computer power supply. I did this to check if it was repeatable before I hooked up the null modem cable. I am all confused right now. How can it work one time and not another. I had three motors spinning, I SWEAR! I am going to start the software again and see, yup there it is again
Opening port /dev/ttyUSB0
Experimental: JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7
RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0
Receive error, re-sending: Timeout receiving byte
0->8: 0
Receive error, re-sending: Timeout receiving byte
0->8: 0
Receive error, re-sending: Timeout receiving byte
0->8: 0
Receive error, re-sending: Timeout receiving byte
0->8: 0

I removed the Z axis and it came up. On the Y slider, you have to slide it twice to get a response and for the line test, only the X axis moved! I copied the terminal window, the cards are sending back data instead of an acknowledgment. I worry what will happen when I power down.
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 4 not present
Received data packet when expecting ACK
sendMessage error - retrying
Received data packet when expecting ACK
sendMessage error - retrying
Received data packet when expecting ACK
sendMessage error - retrying
Unexpected ACK received instead of message, not supported yet
Unexpected ACK received instead of message, not supported yet
Unexpected ACK received instead of message, not supported yet
Ignored IO exception in position update: java.io.IOException: Timeout receiving byte

The X axis moves great, set the desired point and the actual point slides right to it. The Y axis moves when you slide the slider twice and doesn't track to the actual position. In the Line program only the X Axis respon
Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7
Device at address 8 not present
Device at address 4 not present
Ignored IO exception in position update: java.io.IOException: Timeout receiving byte
Ignored IO exception in position update: java.io.IOException: Timeout receiving byte

This is when I try to run the Y axis
When I run calibration I get this "Problem during calibration Java.IO.io.ExceptionTimeout receiving byte.
The Yaxis spins though. I haven't re-re verified the program, but it was double checked

Englewood, please slow down... :-)

You seem to be experiencing intermittent comms issues. I *strongly* suggest that you stop trying to run the stepper exerciser and calibration etc., it is unlikely to be helpful until your comms are stable and reliable. IMO you need to get those comms issues resolved first. It may be boring, but it is necessary.

Try using poke to communicate with each UCB in turn. If necessary, rewire so your SNAP network is just the PowerComms board and one UCB (the X axis). Test with poke. When reliable, repeat using only the Y axis UCB. Test again. Then try the Z axis. Test again. Wiggle your wires and test again. Turn power off and back on and retest... try anything you can think of to try and get it to fail, and retest...!

Then, and only after you have each one on its own communicating reliably, rebuild the full 3 axis network and test some more with poke. Wiggle wires and retest, as before. Power down and back up, and retest. Only when you can reliably poke each of the three UCBs (four if you have an extruder controller already in the ring), and get the expected responses back, *then* fire up the host software and try the stepper exerciser.

If your electronics/wiring are intermittent or unreliable, you are not likely to be able to extrude anything of value... slow down, troubleshoot it and make it reliable. Later on, you'll be glad you did.

[Aside: You've made comments both here in the forums and on IRC that the 0.8.1 host software package lacks a windows .bat file... but it contains one, just as the 0.8 package did. I have checked, more than once! Please can you explain what you are seeing when you try to run that reprap-host.bat file? Thanks. ]

Jonathan

Same board, different PICs.

X axis pic- Comms established, position slider movement starts motor, speed control working and wdhen the "Home" button is pressed and , it moves the slider to home and stops

Y axis Chip Comms establish, position slider movement has no effect and no motor movement.
When calibration is pressed, LED flashes and motor spins rapidly and on pressing home, Motor stops and LED goes solid

Z axis chip, Comms established, position slider movement has no effect and no motor movement
When Calibration is pressed, LED flashes, motor vibrates but doesn't rotate, (same motor, driver chip and hook-up as X and Y tests)e

I used the same board, I just de-energized and changed PICs, This leads to two conclusions
A) My firmware on the Y and Z axis is FUBAR
Java programming may have errors in the Y and Z subprograms

All the PICs are new and have been programmed and verified by an Epic programmer. On comparing all three programs, I found only one byte different, (I assume this is the address) in the HEX code. I used stepmotor.Hex for the X, stepmotorb.hex for the Y and stepmotorc.hex for the Z axis. I thought using the same board would narrow it down to the firmware or the java program. I establish comms to stepper exerciser on all the PICS.

the Y and Z boards need to be connected to the X board via the 'Sync' cable. do you have this plugged in? i'm not sure where the info on it is, but i'm fairly sure that the pins on each board need to be connected to each other (eg pin 1 to pin 1 to pin 1, and pin 2 to pin 2 to pin 2)

this does make it sort of a pain to do testing, but i think the idea is that you test the x first, then the y then the z, plugging in all properly along the way. try attaching that cable and let us know if things change.

sounds like you're making progress though!

No, the reprap program sends out a message for address 2,3,4 and 8 where they are in a daisy chain or stand alone. if 2 is there and replies, that fine. By using the same PCB and driver, I've changed only one thin, the PIC. On the X axis, everything is great except the -step button doesn't step backward

yes, but if that cable is not present, the firmware does weird things. please try it with that cable in place and see if it fixes it.

Do you need the sync if you are running a single axis, like X, Y or Z? I did forget about the sync

well, the problem is that the xyz firmwares are designed to work when all 3 are connected... and things get tricky when you try to test the Y axis or Z axis alone.

what we really need is a simple, cut-down 'universal' firmware that is designed to be used just to test that the board is working, and then once you've gotten all your boards working, then you put the right firmware on, wire them up properly and you're good to go.

anyone want to look at the firmware code and see how hard it would be to create this?

Do we have a schematic for the UCB? I bought 4 of the older ones with the Cap close to the 12VDC power supply, and I can communicate with the PIC in all of them. The one I recently got that was silk screened and the power cap pushed back from the 12 VDC connectors, I can communicate with. The LED lights up but to comm, just continuous resending. I am going to re convert one of the two extruder boards to a stepper. Praise the lord for de-solder tools! My Z axis pic just causes the stepper to vibrate but the X and Y chips in the same board with the same motor spin great! The Z axis does flash the led though. I then de-energize and swap the chips. I check source forge and I couldn't find a schematic, it has to be somewhere.

Check your torque setting for the Z motor in the preferences - if it is too low, it will cause the motor to wiggle instead of turn. Set it to 100 just to make sure it will turn the motor, then you can ease it down to a more manageable setting later.

Englewood,

Good that you finally got things to work better. As Eric mentioned, change the preference for the Z torque to 100% in the java application. This is an issue both Eric and I bumped into earlier. Maybe the default properties in the packaged java file could be fixed to avoid this (rather annoying) problem. That should solve the "wiggly" motor.

As far as the schematic is concerned, this is on SVN. It is a Kicad file and can be found in /electronics/production/UniversalController. I have attached a PDF version here for your convenience.

Joost

Thanks for the schematic. I have 4 of the old type UCB that work great, but the new one with the 1000 microfarad cap pushed back, won't communicate. I'm thinking maybe the bypass cap is too far from pins 14 and 5, I don't know, but the schematic will help. Yes I did have the Z torque too low!

Joost wrote:

> As Eric mentioned, change the preference for the Z torque to 100%
> in the java application. This is an issue both Eric and I bumped
> into earlier. Maybe the default properties in the packaged java
> file could be fixed to avoid this (rather annoying) problem.

You mentioned this in IRC recently too, so I took a look at it. I *think* it is already fixed!

The default for ZAxisTorque(%) is currently 100. This was changed in subversion revision r673 on 26 June 2007. [Sadly, its committer (Adrian) failed to mention the changing of many default preference values in that commit in his subversion log entry, never mind documenting *why* they all changed so suddenly! Because these changes were not logged, they were not documented in the 0.8.1 README file either.].

Anyway, that (somewhat undocumented!) change to the defaults was made several days before 0.8.1 was packaged, so the current host software package really truly should already have a ZAxisTorque(%) default of 100 when freshly installed. If you test it, and find that it does not, please let me know, with plenty of details on how you tested!

It looks as though you, Eric and Englewood all first used host software earlier than r673 or earlier than 0.8.1, and so stored the old (lower) defaults into your per-user properties files.

Did you remember to delete and re-create your ~/.reprap/reprap.properties file when you installed the reprap-host-0.8.1.zip package, or did you perhaps just keep on going using an older properties file?

(Note: It is arguable that the per-user properties file really should only store *changed* properties, not all of them. I am pretty sure the java.util.Properties class is actually intended to be used that way. But that's not how Adrian implemented RepRap properties, and I'm not about to spend time ripping his code out just to change this. Not yet, anyway!).

[Also note: It can also be argued that when making non-backward-compatible changes to a set of Properties, it is wise to use a PropertyVersion property or similar, so you know which variant of properties you have, and can either warn the user or upgrade his old set of properties automatically... but that didn't happen either. It's extra work to implement, and we're still very much in alpha testing!]

Jonathan (who may actually care about the Torque values for real himself in a day or two, because a test stepper is on its way, thanks to Englewood!)