Strange Stepper Exerciser Behavior with McWire, and some McWire Comments
Posted by Ithacacian
|
Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 02, 2008 09:35PM |
Registered: 16 years ago Posts: 37 |
Hi,
I've just completed the mechanical setup for the McWire and have started hooking up all the electronics. My compliments to Zach for his guide, I followed it pretty closely. However, I'm getting some strange behavior when all the boards are set up in their loop, connected to the stages they drive.
To preface, I did and passed all the tests described in the UCB and motor controller fabrication guides. Each of the boards worked fine hooked up singly to the power comms board, with the tests conducted separately on the same stepper. When the x-, y-, and z- motor controller boards are looped (without using sync), all lights are green, all sliders show up in the stepper exerciser dialog.
The board controlling the x-stage works fine. It goes home across its entire working range, and catches up to the stepper exerciser slider wherever I put it, blinking as it should, and stopping when I trip an opto-endstop or pull the shorting pin, whichever way I have it setup.
The board controlling the y-stage is a bit strange. When I press home, it goes quite a ways (farther than the exerciser could take it), but stops short of where its home should be. I haven't calibrated the working area yet. I don't know if this makes a difference. With the x, I just killed the power before it hit the side. More troubling is that during the stepper exerciser test, if I drag it all the way to the right, it stops maybe 1/2 - 2/3 of the way there and dies.
The board controlling the z-stage is most problematic. Whether I home it or test it with the stepper exerciser, it spins maybe twice and then dies.
Note that for my setup, when it dies, it cuts out the power supply, which I've always found strange. For example, if I let the position catch up with the slider without tripping an endstop, it dies. Likewise, the problems with the y and z kill the power supply. It resets in about 20 seconds. I've only ever had this happen before when its load exceeds its capacity, which seems unlikely (even at stall or start torque with these steppers), given the 18A at 12V and 30A at 5V capacity of my Antec.
To debug, I've tested both the y and z connected singly to the power comms board and their respective stages, to eliminate any master/slave issue. Same problem.
I've also switched the pics and stepper connectors between controller boards, to see if any of them were faulty. The pic driving the x works on all three boards. The others still have their problems.
Hand twisting yields a comparable amount of torque to spin each stage, with the y being somewhat less than the x and z. All are close, though, and each should be far less than the torque capacity of the steppers, so I don't think its a torque or power draw issue.
The only things I can think of are that some calibration is needed, or the exerciser is written taking some parameter into account which is different between McWire and Darwin. For the reasons I've stated, I don't think it's something low level like a missed connection or short, because otherwise the x pic wouldn't work on one or more of the boards. However, I could be wrong. If anyone has any help or suggestions, I would greatly appreciate it. A cursory search didn't turn up anything on the forums.
Also, for those building McWire, because physical calibration is so important in contrast to Darwin, which I think by it's design is better calibrated from the start, I would highly recommend not building with hand tools. I did (because I only have time to build when our machine shop is closed), and it caused me headaches moving holes slightly and getting everything to fit together.
Looking at the instructions for attaching the extruder, if you use the 12" segment of pipe in the z, as is instructed in the current McWire build, the bottom home position of the z-stage is still a good 4-5" above the y build stage. With the parts I got for the extruder, from BitsFromBytes, it will need some extending piece. Making the z-rails longer (mine are 12", as per the instructions, though 16" may be right) gives you both more range in the z and removes this problem, at least as I built it, as I understood Zach's guide. I would also probably forego the self-tapping screws for the teflon strips in favor of smaller nuts and bolts.
Thanks
I've just completed the mechanical setup for the McWire and have started hooking up all the electronics. My compliments to Zach for his guide, I followed it pretty closely. However, I'm getting some strange behavior when all the boards are set up in their loop, connected to the stages they drive.
To preface, I did and passed all the tests described in the UCB and motor controller fabrication guides. Each of the boards worked fine hooked up singly to the power comms board, with the tests conducted separately on the same stepper. When the x-, y-, and z- motor controller boards are looped (without using sync), all lights are green, all sliders show up in the stepper exerciser dialog.
The board controlling the x-stage works fine. It goes home across its entire working range, and catches up to the stepper exerciser slider wherever I put it, blinking as it should, and stopping when I trip an opto-endstop or pull the shorting pin, whichever way I have it setup.
The board controlling the y-stage is a bit strange. When I press home, it goes quite a ways (farther than the exerciser could take it), but stops short of where its home should be. I haven't calibrated the working area yet. I don't know if this makes a difference. With the x, I just killed the power before it hit the side. More troubling is that during the stepper exerciser test, if I drag it all the way to the right, it stops maybe 1/2 - 2/3 of the way there and dies.
The board controlling the z-stage is most problematic. Whether I home it or test it with the stepper exerciser, it spins maybe twice and then dies.
Note that for my setup, when it dies, it cuts out the power supply, which I've always found strange. For example, if I let the position catch up with the slider without tripping an endstop, it dies. Likewise, the problems with the y and z kill the power supply. It resets in about 20 seconds. I've only ever had this happen before when its load exceeds its capacity, which seems unlikely (even at stall or start torque with these steppers), given the 18A at 12V and 30A at 5V capacity of my Antec.
To debug, I've tested both the y and z connected singly to the power comms board and their respective stages, to eliminate any master/slave issue. Same problem.
I've also switched the pics and stepper connectors between controller boards, to see if any of them were faulty. The pic driving the x works on all three boards. The others still have their problems.
Hand twisting yields a comparable amount of torque to spin each stage, with the y being somewhat less than the x and z. All are close, though, and each should be far less than the torque capacity of the steppers, so I don't think its a torque or power draw issue.
The only things I can think of are that some calibration is needed, or the exerciser is written taking some parameter into account which is different between McWire and Darwin. For the reasons I've stated, I don't think it's something low level like a missed connection or short, because otherwise the x pic wouldn't work on one or more of the boards. However, I could be wrong. If anyone has any help or suggestions, I would greatly appreciate it. A cursory search didn't turn up anything on the forums.
Also, for those building McWire, because physical calibration is so important in contrast to Darwin, which I think by it's design is better calibrated from the start, I would highly recommend not building with hand tools. I did (because I only have time to build when our machine shop is closed), and it caused me headaches moving holes slightly and getting everything to fit together.
Looking at the instructions for attaching the extruder, if you use the 12" segment of pipe in the z, as is instructed in the current McWire build, the bottom home position of the z-stage is still a good 4-5" above the y build stage. With the parts I got for the extruder, from BitsFromBytes, it will need some extending piece. Making the z-rails longer (mine are 12", as per the instructions, though 16" may be right) gives you both more range in the z and removes this problem, at least as I built it, as I understood Zach's guide. I would also probably forego the self-tapping screws for the teflon strips in favor of smaller nuts and bolts.
Thanks
|
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 03, 2008 04:12AM |
Registered: 17 years ago Posts: 467 |
|
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 03, 2008 08:32AM |
Registered: 16 years ago Posts: 37 |
|
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 03, 2008 08:02PM |
Registered: 16 years ago Posts: 37 |
I just conducted one other test which I think is illustrative and would tend to make me believe that the problem is in the firmware (or how it got coded to the Pic, or in the Pic itself). Maybe this is the result of the pic being damaged or fried, or the programming garbling a byte or two. Or maybe there's some incompatibility between McWire and Darwin, though I doubt that.
So I put the x pic (which has been working fine) in the z controller board (with stepper attached to z stage), and the z pic in the x controller board (with stepper attached to x stage) and opened the stepper exerciser. The z stage was now able to move just fine wherever I put the slider. This in contrast to its previous behavior of dying after two turns. When testing the x stage (with the z pic) it now dies after two turns, when before it was fine with the x pic. So the problem seems to be in the pics and/or firmware.
Can anyone with a decent knowledge of the code comment? Further suggestions? Right now, I'm leaning towards reprogram, try again, if still bad, assume a fried pic and get some new ones, if still bad, definitely a logic error. Though it would be nice if someone with insight could point out the logic error, or recommend further debugging steps.
Thanks
So I put the x pic (which has been working fine) in the z controller board (with stepper attached to z stage), and the z pic in the x controller board (with stepper attached to x stage) and opened the stepper exerciser. The z stage was now able to move just fine wherever I put the slider. This in contrast to its previous behavior of dying after two turns. When testing the x stage (with the z pic) it now dies after two turns, when before it was fine with the x pic. So the problem seems to be in the pics and/or firmware.
Can anyone with a decent knowledge of the code comment? Further suggestions? Right now, I'm leaning towards reprogram, try again, if still bad, assume a fried pic and get some new ones, if still bad, definitely a logic error. Though it would be nice if someone with insight could point out the logic error, or recommend further debugging steps.
Thanks
|
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 04, 2008 03:50PM |
Admin Registered: 17 years ago Posts: 1,487 |
|
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 05, 2008 05:07PM |
Registered: 16 years ago Posts: 37 |
Hello again,
So I've been trying to check off possible things it could be. I reprogrammed each pic, rewired all the boards and pulled on all the cables, etc., even matching them up to the flow chart on the wiki of comms->x->y->z->extruder->comms with sync pins wired. After this was done, the x still worked as it had been, and the y now appears to be working fine as well. The z still spins two turns and dies. I even programmed an unused pic with the stepmotorc.hex, had everything verified in icprog, etc., so I believe that odds are strong that the firmware is programmed as it was written.
I wanted to ask, though, about the following sets of behavior, and whether they were normal, and what they indicate, as I have seen relatively little documentation on proper testing behavior.
When I do the stepper exerciser test, I'll drag the bar all the way to the right, or sometimes partially, and the bar beneath will catch up, and when it does catch up, my power supply cuts out, and the reprap software freezes and has to be restarted. Is this normal? I'm using a relatively new Antec 550, it passed all the pin voltage tests for the UCBs more or less (a couple were off by a bit, as I described in a previous post). If I trip an opto endstop before letting it reach the slider, the power stays on, and the software doesn't freeze.
When I press the calibrate button in the stepper exerciser dialog, it will start moving (towards home), but throw the following error:
Problem During Calibration: Java,io.IOException: Timeout receiving byte
Sometimes it dies of its own accord after doing this before I kill the power, but the host software doesn't freeze.
When I do the working volume probe, there is some erratic behavior. The x homes (towards the stepper), trips the endstop wired to min, kills the power, when I restart and rehome, because its already home, it doesn't kill the power and I can now press advance. Advance slow doesn't seem to work. Advance fast does. The x goes about 8in., then before getting to the other side, dies. The y axis has its own problem. It says its homed wherever it is on the board, then will travel to the other side fine. The z is the most puzzling. It does the working volume probe just fine, over its entire range. This is very strange. Why does the z work for the volume probe but not at all for the stepper exerciser? All settings are default 0.8.3?
One thing to note. I just tried running in terminal, and whenever I open up a dialog, whether it be the stepper exerciser or the volume probe, I get the following error (in terminal, though I can still move the motors etc.):
RXTX Warning: Removing stale lock file. /var/lock/LCK...ttyUSB0
Searching on the forum showed that other people had experienced this error, but I wasn't clear on what the solution was.
So I've been trying to check off possible things it could be. I reprogrammed each pic, rewired all the boards and pulled on all the cables, etc., even matching them up to the flow chart on the wiki of comms->x->y->z->extruder->comms with sync pins wired. After this was done, the x still worked as it had been, and the y now appears to be working fine as well. The z still spins two turns and dies. I even programmed an unused pic with the stepmotorc.hex, had everything verified in icprog, etc., so I believe that odds are strong that the firmware is programmed as it was written.
I wanted to ask, though, about the following sets of behavior, and whether they were normal, and what they indicate, as I have seen relatively little documentation on proper testing behavior.
When I do the stepper exerciser test, I'll drag the bar all the way to the right, or sometimes partially, and the bar beneath will catch up, and when it does catch up, my power supply cuts out, and the reprap software freezes and has to be restarted. Is this normal? I'm using a relatively new Antec 550, it passed all the pin voltage tests for the UCBs more or less (a couple were off by a bit, as I described in a previous post). If I trip an opto endstop before letting it reach the slider, the power stays on, and the software doesn't freeze.
When I press the calibrate button in the stepper exerciser dialog, it will start moving (towards home), but throw the following error:
Problem During Calibration: Java,io.IOException: Timeout receiving byte
Sometimes it dies of its own accord after doing this before I kill the power, but the host software doesn't freeze.
When I do the working volume probe, there is some erratic behavior. The x homes (towards the stepper), trips the endstop wired to min, kills the power, when I restart and rehome, because its already home, it doesn't kill the power and I can now press advance. Advance slow doesn't seem to work. Advance fast does. The x goes about 8in., then before getting to the other side, dies. The y axis has its own problem. It says its homed wherever it is on the board, then will travel to the other side fine. The z is the most puzzling. It does the working volume probe just fine, over its entire range. This is very strange. Why does the z work for the volume probe but not at all for the stepper exerciser? All settings are default 0.8.3?
One thing to note. I just tried running in terminal, and whenever I open up a dialog, whether it be the stepper exerciser or the volume probe, I get the following error (in terminal, though I can still move the motors etc.):
RXTX Warning: Removing stale lock file. /var/lock/LCK...ttyUSB0
Searching on the forum showed that other people had experienced this error, but I wasn't clear on what the solution was.
|
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 05, 2008 05:10PM |
Registered: 16 years ago Posts: 37 |
Update: Now the x and y are sometimes dying after two turns as well in the stepper exerciser dialog. I changed nothing except using the host software on a different computer running linux natively. Now the x and y don't appear to be working properly on either computer. The working volume probe still has its old behavior though, including partially working x and y, and fully working z.
|
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 05, 2008 05:28PM |
Registered: 16 years ago Posts: 37 |
Turned on commsdebug == true and got the following error in console when I opened up the stepper exerciser:
Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7
RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0
comms: tx 0->8: 0 [0.000s/-1207430756607ms]
comms: rx: 52 30 0 8 c3 54 51 33 0 8 0 0 2 15 [0.024s/24ms]
Received data packet when expecting ACK
sendMessage error - retrying
comms: tx 0->8: 0 [0.129s/105ms]
comms: rx: 54 52 30 0 8 c3 [0.152s/23ms]
comms: rx: 54 51 33 0 8 0 0 2 15 [0.163s/11ms]
comms: tx 0->8: 34 7 [0.164s/1ms]
comms: rx: 54 52 30 0 8 c3 [0.184s/20ms]
comms: tx 0->8: 35 4 [0.185s/1ms]
comms: rx: 54 52 30 0 8 c3 [0.209s/24ms]
comms: tx 0->2: e 44 [0.273s/64ms]
comms: rx: 54 52 30 0 2 bd [0.299s/26ms]
comms: tx 0->2: 3 3e 2 [0.320s/21ms]
comms: rx: 54 52 30 0 2 bd [0.359s/39ms]
comms: tx 0->3: e 44 [0.361s/2ms]
comms: rx: 54 52 30 0 3 e3 [0.389s/28ms]
comms: tx 0->3: 3 3e 2 [0.390s/1ms]
comms: rx: 54 52 30 0 3 e3 [0.417s/27ms]
comms: tx 0->4: e 44 [0.424s/7ms]
comms: rx: 54 52 30 0 4 60 [0.452s/28ms]
comms: tx 0->4: 3 80 3e [0.452s/0ms]
comms: rx: 54 52 30 0 4 60 [0.486s/34ms]
Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7
RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0
comms: tx 0->8: 0 [0.000s/-1207430756607ms]
comms: rx: 52 30 0 8 c3 54 51 33 0 8 0 0 2 15 [0.024s/24ms]
Received data packet when expecting ACK
sendMessage error - retrying
comms: tx 0->8: 0 [0.129s/105ms]
comms: rx: 54 52 30 0 8 c3 [0.152s/23ms]
comms: rx: 54 51 33 0 8 0 0 2 15 [0.163s/11ms]
comms: tx 0->8: 34 7 [0.164s/1ms]
comms: rx: 54 52 30 0 8 c3 [0.184s/20ms]
comms: tx 0->8: 35 4 [0.185s/1ms]
comms: rx: 54 52 30 0 8 c3 [0.209s/24ms]
comms: tx 0->2: e 44 [0.273s/64ms]
comms: rx: 54 52 30 0 2 bd [0.299s/26ms]
comms: tx 0->2: 3 3e 2 [0.320s/21ms]
comms: rx: 54 52 30 0 2 bd [0.359s/39ms]
comms: tx 0->3: e 44 [0.361s/2ms]
comms: rx: 54 52 30 0 3 e3 [0.389s/28ms]
comms: tx 0->3: 3 3e 2 [0.390s/1ms]
comms: rx: 54 52 30 0 3 e3 [0.417s/27ms]
comms: tx 0->4: e 44 [0.424s/7ms]
comms: rx: 54 52 30 0 4 60 [0.452s/28ms]
comms: tx 0->4: 3 80 3e [0.452s/0ms]
comms: rx: 54 52 30 0 4 60 [0.486s/34ms]
|
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 05, 2008 05:32PM |
Registered: 16 years ago Posts: 37 |
After trying to slide the z bar in the stepper exerciser, I get the following error (appended to what was listed above):
comms: tx 0->4: 5 e6 80 3e [7.410s/6993ms]
comms: rx: 54 52 30 0 4 60 [7.437s/27ms]
comms: tx 0->4: 5 e6 88 42 [7.462s/25ms]
comms: rx: 54 52 30 0 4 60 [7.501s/39ms]
comms: tx 0->4: 5 e6 ba 5a [7.509s/8ms]
comms: rx: 54 52 30 0 4 60 [7.557s/48ms]
comms: tx 0->4: 5 e6 f8 78 [7.585s/28ms]
comms: rx: 54 52 30 0 4 60 [7.617s/32ms]
comms: tx 0->4: 5 e6 1d 8b [7.618s/1ms]
comms: rx: 54 52 30 0 4 60 [7.655s/37ms]
comms: tx 0->4: 5 e6 32 95 [7.661s/6ms]
comms: rx: 54 52 30 0 4 60 [7.703s/42ms]
comms: tx 0->4: 4 [7.704s/1ms]
comms: rx: 54 52 30 0 4 60 [7.744s/40ms]
comms: rx: 54 51 33 0 4 4 8a 3e 4c [7.745s/1ms]
comms: tx 0->4: 5 e6 2d 93 [7.779s/34ms]
comms: rx: 54 52 30 0 4 60 [7.806s/27ms]
comms: tx 0->4: 5 e6 2d 93 [7.834s/28ms]
comms: rx: 54 52 30 0 4 60 [7.871s/37ms]
comms: tx 0->4: 4 [7.907s/36ms]
comms: rx: 54 52 30 0 4 60 [7.932s/25ms]
comms: rx: 54 51 33 0 4 4 6d 3e 57 [7.935s/3ms]
comms: tx 0->4: 4 [8.139s/204ms]
comms: rx: 54 52 30 0 4 60 [8.159s/20ms]
comms: rx: 54 51 33 0 4 4 4b 3e 3c [8.165s/6ms]
comms: tx 0->4: 4 [8.367s/202ms]
comms: rx: 54 52 30 0 4 60 [8.387s/20ms]
comms: rx: 54 51 33 0 4 4 2a 3e a2 [8.395s/8ms]
comms: tx 0->4: 4 [8.599s/204ms]
Receive error, re-sending: Timeout receiving byte
Edited 1 time(s). Last edit at 04/05/2008 05:33PM by Ithacacian.
comms: tx 0->4: 5 e6 80 3e [7.410s/6993ms]
comms: rx: 54 52 30 0 4 60 [7.437s/27ms]
comms: tx 0->4: 5 e6 88 42 [7.462s/25ms]
comms: rx: 54 52 30 0 4 60 [7.501s/39ms]
comms: tx 0->4: 5 e6 ba 5a [7.509s/8ms]
comms: rx: 54 52 30 0 4 60 [7.557s/48ms]
comms: tx 0->4: 5 e6 f8 78 [7.585s/28ms]
comms: rx: 54 52 30 0 4 60 [7.617s/32ms]
comms: tx 0->4: 5 e6 1d 8b [7.618s/1ms]
comms: rx: 54 52 30 0 4 60 [7.655s/37ms]
comms: tx 0->4: 5 e6 32 95 [7.661s/6ms]
comms: rx: 54 52 30 0 4 60 [7.703s/42ms]
comms: tx 0->4: 4 [7.704s/1ms]
comms: rx: 54 52 30 0 4 60 [7.744s/40ms]
comms: rx: 54 51 33 0 4 4 8a 3e 4c [7.745s/1ms]
comms: tx 0->4: 5 e6 2d 93 [7.779s/34ms]
comms: rx: 54 52 30 0 4 60 [7.806s/27ms]
comms: tx 0->4: 5 e6 2d 93 [7.834s/28ms]
comms: rx: 54 52 30 0 4 60 [7.871s/37ms]
comms: tx 0->4: 4 [7.907s/36ms]
comms: rx: 54 52 30 0 4 60 [7.932s/25ms]
comms: rx: 54 51 33 0 4 4 6d 3e 57 [7.935s/3ms]
comms: tx 0->4: 4 [8.139s/204ms]
comms: rx: 54 52 30 0 4 60 [8.159s/20ms]
comms: rx: 54 51 33 0 4 4 4b 3e 3c [8.165s/6ms]
comms: tx 0->4: 4 [8.367s/202ms]
comms: rx: 54 52 30 0 4 60 [8.387s/20ms]
comms: rx: 54 51 33 0 4 4 2a 3e a2 [8.395s/8ms]
comms: tx 0->4: 4 [8.599s/204ms]
Receive error, re-sending: Timeout receiving byte
Edited 1 time(s). Last edit at 04/05/2008 05:33PM by Ithacacian.
|
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 05, 2008 05:48PM |
Registered: 16 years ago Posts: 37 |
This is what is printed out when debug == true
Java 3D WARNING : reported GLX version = 1.2
GLX version 1.3 or higher is required
The reported version number may be incorrect. There is a known
ATI driver bug in glXQueryVersion that incorrectly reports the GLX
version as 1.2 when it really is 1.3, so Java 3D will attempt to
run anyway.
DEBUG: Opening port /dev/ttyUSB0 [0.000s/-1207431897515ms]
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
DEBUG: CAPA extruder vRefFactor set to 7 [0.413s/413ms]
DEBUG: X axis - setting maximum torque to: 100 [0.496s/83ms]
DEBUG: X axis - setting position to: 574 [0.518s/22ms]
DEBUG: Y axis - setting maximum torque to: 100 [0.547s/29ms]
DEBUG: Y axis - setting position to: 574 [0.572s/25ms]
DEBUG: Z axis - setting maximum torque to: 100 [0.599s/27ms]
DEBUG: Z axis - setting position to: 16000 [0.624s/25ms]
DEBUG: Z axis - seeking position 16000 at speed 230 [7.534s/6910ms]
DEBUG: Z axis - seeking position 18065 at speed 230 [7.558s/24ms]
DEBUG: Z axis - seeking position 18581 at speed 230 [7.582s/24ms]
DEBUG: Z axis - seeking position 19613 at speed 230 [7.617s/35ms]
DEBUG: Z axis - seeking position 20129 at speed 230 [7.646s/29ms]
DEBUG: Z axis - seeking position 21161 at speed 230 [7.672s/26ms]
DEBUG: Z axis - seeking position 23226 at speed 230 [7.705s/33ms]
DEBUG: Z axis - seeking position 24258 at speed 230 [7.735s/30ms]
DEBUG: Z axis - seeking position 26839 at speed 230 [7.762s/27ms]
DEBUG: Z axis - getting position. It is... [7.788s/26ms]
DEBUG: ...16029 [7.817s/29ms]
DEBUG: Z axis - seeking position 28387 at speed 230 [7.818s/1ms]
DEBUG: Z axis - seeking position 30452 at speed 230 [7.855s/37ms]
DEBUG: Z axis - seeking position 30452 at speed 230 [7.878s/23ms]
DEBUG: Z axis - getting position. It is... [7.992s/114ms]
DEBUG: ...16058 [8.017s/25ms]
DEBUG: Z axis - getting position. It is... [8.220s/203ms]
DEBUG: ...16091 [8.244s/24ms]
DEBUG: Z axis - getting position. It is... [8.448s/204ms]
DEBUG: ...16125 [8.473s/25ms]
DEBUG: Z axis - getting position. It is... [8.676s/203ms]
DEBUG: ...16158 [8.705s/29ms]
DEBUG: Z axis - getting position. It is... [8.908s/203ms]
Receive error, re-sending: Timeout receiving byte
Receive error is due to the power supply dying. It looks like it was doing what it was supposed to. It would seem that the error is a communication error.
Anyone able to comment? I certainly would appreciate the help. A google search turned up that it may be a serial communication permission issue, but I have the latest rxtx package from ubuntu, I'm not sure about anything further.
Java 3D WARNING : reported GLX version = 1.2
GLX version 1.3 or higher is required
The reported version number may be incorrect. There is a known
ATI driver bug in glXQueryVersion that incorrectly reports the GLX
version as 1.2 when it really is 1.3, so Java 3D will attempt to
run anyway.
DEBUG: Opening port /dev/ttyUSB0 [0.000s/-1207431897515ms]
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
DEBUG: CAPA extruder vRefFactor set to 7 [0.413s/413ms]
DEBUG: X axis - setting maximum torque to: 100 [0.496s/83ms]
DEBUG: X axis - setting position to: 574 [0.518s/22ms]
DEBUG: Y axis - setting maximum torque to: 100 [0.547s/29ms]
DEBUG: Y axis - setting position to: 574 [0.572s/25ms]
DEBUG: Z axis - setting maximum torque to: 100 [0.599s/27ms]
DEBUG: Z axis - setting position to: 16000 [0.624s/25ms]
DEBUG: Z axis - seeking position 16000 at speed 230 [7.534s/6910ms]
DEBUG: Z axis - seeking position 18065 at speed 230 [7.558s/24ms]
DEBUG: Z axis - seeking position 18581 at speed 230 [7.582s/24ms]
DEBUG: Z axis - seeking position 19613 at speed 230 [7.617s/35ms]
DEBUG: Z axis - seeking position 20129 at speed 230 [7.646s/29ms]
DEBUG: Z axis - seeking position 21161 at speed 230 [7.672s/26ms]
DEBUG: Z axis - seeking position 23226 at speed 230 [7.705s/33ms]
DEBUG: Z axis - seeking position 24258 at speed 230 [7.735s/30ms]
DEBUG: Z axis - seeking position 26839 at speed 230 [7.762s/27ms]
DEBUG: Z axis - getting position. It is... [7.788s/26ms]
DEBUG: ...16029 [7.817s/29ms]
DEBUG: Z axis - seeking position 28387 at speed 230 [7.818s/1ms]
DEBUG: Z axis - seeking position 30452 at speed 230 [7.855s/37ms]
DEBUG: Z axis - seeking position 30452 at speed 230 [7.878s/23ms]
DEBUG: Z axis - getting position. It is... [7.992s/114ms]
DEBUG: ...16058 [8.017s/25ms]
DEBUG: Z axis - getting position. It is... [8.220s/203ms]
DEBUG: ...16091 [8.244s/24ms]
DEBUG: Z axis - getting position. It is... [8.448s/204ms]
DEBUG: ...16125 [8.473s/25ms]
DEBUG: Z axis - getting position. It is... [8.676s/203ms]
DEBUG: ...16158 [8.705s/29ms]
DEBUG: Z axis - getting position. It is... [8.908s/203ms]
Receive error, re-sending: Timeout receiving byte
Receive error is due to the power supply dying. It looks like it was doing what it was supposed to. It would seem that the error is a communication error.
Anyone able to comment? I certainly would appreciate the help. A google search turned up that it may be a serial communication permission issue, but I have the latest rxtx package from ubuntu, I'm not sure about anything further.
|
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 05, 2008 06:22PM |
Registered: 16 years ago Posts: 37 |
I don't think it's a permission issue. I reverified that I am a member of dialout and dip, though the code posted on the wiki referencing moduser didn't work for me. Moot point though. I saw on a different forum how some people had problems with the vanilla rxtx downloaded with synaptic package manager throwing this error, and I saw Zach had some similar errors debugging the Arduino code to work with the host software. But I would tend to think its something else local to my comms setup because I understood the pic environment to be stable.
|
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 07, 2008 10:06PM |
Registered: 16 years ago Posts: 37 |
Hi all again,
So I've been continuing to test what could be wrong. Disconnected the power comms board and retested with minicom. Check. Compared all the resistors and capacitors on all the boards with pictures and resistor chart. Check. Ensured steppers were all wired properly. Check. Rewent through all the developers and software installation instructions. The only thing I found was that RXTXcomm.jar hadn't actually gotten into java-1.5.0-sun, which is what the host software should be using, so I fixed that, still same behavior. I did notice that I had a number of java folders, but the following command only showed 1.5.0:
update-java-alternatives --list |grep java |grep sun |cut -d " " -f3 # Output your Sun JRE(s)
So as far as I can tell, check. Though there could still be a problem, here, not sure.
Disconnected all the boards, tested each pic singly with one of the controller boards. Stepper Exerciser upon startup still throws the console RXTX Warning: removing stale lock file. /var/lock/LCK...TTYUSB0. What is that? Anyone? Problem? Minor inconsequential annoyance? However, both and x and y pics are back to working properly (they were all wired to the motor on the z stage now for the test). The z pic still spins two turns and then dies. Right now, I'm guessing, it's the power supply (though all the rails check out on my multimeter), because it dying (i.e. when the stepper exerciser sliders meet each other) is I think what causes things to crash, ultimately. That or the pics fried, though I already reprogrammed a good one for the z pic, same behavior. The other thing was how the z stepper exerciser was like on a scale of 0-96000, whereas the x and y were both 0-3446. I'm not sure if that's normal, but that's what I've got.
Things I am still going to do: run off the LiveCD when I can get access to a pc notebook. I would love to do serial->serial instead of usb->serial, see if its a problem there, don't know if it'll happen though.
If anyone can verify what their power supply does during the stepper exerciser test, I would be eternally grateful! Really, quite grateful. Because in addition to my seven courses and three projects, I'm still trying to build a pellet feed extruder head for this too. And of course get it debugged. MechE here, not so gifted with the softwares.
Again, I appreciate anyone willing to help an exhausted college student.
Cheers
So I've been continuing to test what could be wrong. Disconnected the power comms board and retested with minicom. Check. Compared all the resistors and capacitors on all the boards with pictures and resistor chart. Check. Ensured steppers were all wired properly. Check. Rewent through all the developers and software installation instructions. The only thing I found was that RXTXcomm.jar hadn't actually gotten into java-1.5.0-sun, which is what the host software should be using, so I fixed that, still same behavior. I did notice that I had a number of java folders, but the following command only showed 1.5.0:
update-java-alternatives --list |grep java |grep sun |cut -d " " -f3 # Output your Sun JRE(s)
So as far as I can tell, check. Though there could still be a problem, here, not sure.
Disconnected all the boards, tested each pic singly with one of the controller boards. Stepper Exerciser upon startup still throws the console RXTX Warning: removing stale lock file. /var/lock/LCK...TTYUSB0. What is that? Anyone? Problem? Minor inconsequential annoyance? However, both and x and y pics are back to working properly (they were all wired to the motor on the z stage now for the test). The z pic still spins two turns and then dies. Right now, I'm guessing, it's the power supply (though all the rails check out on my multimeter), because it dying (i.e. when the stepper exerciser sliders meet each other) is I think what causes things to crash, ultimately. That or the pics fried, though I already reprogrammed a good one for the z pic, same behavior. The other thing was how the z stepper exerciser was like on a scale of 0-96000, whereas the x and y were both 0-3446. I'm not sure if that's normal, but that's what I've got.
Things I am still going to do: run off the LiveCD when I can get access to a pc notebook. I would love to do serial->serial instead of usb->serial, see if its a problem there, don't know if it'll happen though.
If anyone can verify what their power supply does during the stepper exerciser test, I would be eternally grateful! Really, quite grateful. Because in addition to my seven courses and three projects, I'm still trying to build a pellet feed extruder head for this too. And of course get it debugged. MechE here, not so gifted with the softwares.
Again, I appreciate anyone willing to help an exhausted college student.
Cheers
|
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 07, 2008 11:49PM |
Registered: 16 years ago Posts: 37 |
So it seems the RXTX warning issue is perfectly natural. I noticed that I didn't get it when I would start up, only subsequently. Apparently if you open your usb->serial connection and don't have code to close it, it creates a file which is purged when you restart, throwing the warning. So I don't think that's the problem.
Also, the LiveCD doesn't work on a Dell XPSM1330 or an Intel MacBook Pro Santa Rosa. I saw the issue relating to Intel wireless cards but don't really know how to fix it. We both got the same error, something about bash, tty, I don't know.
Also, the LiveCD doesn't work on a Dell XPSM1330 or an Intel MacBook Pro Santa Rosa. I saw the issue relating to Intel wireless cards but don't really know how to fix it. We both got the same error, something about bash, tty, I don't know.
|
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 08, 2008 04:35AM |
Admin Registered: 17 years ago Posts: 7,881 |
If your power supply shuts down it must be a hardware issue. Measure the voltages: if the 5V output is high and the 12V low then you proably need a dummy load on the 5V rail to keep the PSU happy. Use a car bulb or a 10R 5W resistor.
[www.hydraraptor.blogspot.com]
[www.hydraraptor.blogspot.com]
|
Anonymous User
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 08, 2008 12:29PM |
I'm working on the same project as Ithacacian. I'm borrowing a buddy's power supply later today and testing it with his. If we run into the same issues, its a pretty safe bet that there is something wrong either with our electronics, wiring, or the host software.
I'll let you guys know whats up when we finish testing later tonight.
I'll let you guys know whats up when we finish testing later tonight.
|
Anonymous User
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 08, 2008 07:25PM |
So I talked to some ECEs in my Mechatronics project and explained the situation we are running into. One of them ran into a similar problem with his coil gun project. The reason the power supply dies is more than likely it is hitting the over-voltage protection, which causes the power supply to die. Basically, if the the motor is moving and then all of sudden just stops, the voltage is going to spike. The power supply tries to correct it to a point, but once it goes over that limit, the PSU shuts down to protect itself and possible electronics.
Possible solutions they gave me: bigger and badder PSU (we currently have a 550W, more towards 650 or 750W), place a load across the motor rails to help dissipate this huge increase in Voltage. A load can be anything as a big capacitor or a power resistor. A cheap method they mentioned is a car bulb as nophead mentioned earlier.
The PSU I borrowed from a friend is a 330W, so it probably won't work, so I'm going to look for a higher wattage one from another friend.
If anyone knows anything about the firmware, does the motor/stepmotor firmware ramp down or just stop when it gets to the needed point.
Possible solutions they gave me: bigger and badder PSU (we currently have a 550W, more towards 650 or 750W), place a load across the motor rails to help dissipate this huge increase in Voltage. A load can be anything as a big capacitor or a power resistor. A cheap method they mentioned is a car bulb as nophead mentioned earlier.
The PSU I borrowed from a friend is a 330W, so it probably won't work, so I'm going to look for a higher wattage one from another friend.
If anyone knows anything about the firmware, does the motor/stepmotor firmware ramp down or just stop when it gets to the needed point.
|
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 08, 2008 10:24PM |
Registered: 17 years ago Posts: 225 |
|
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 08, 2008 10:33PM |
Registered: 17 years ago Posts: 24 |
|
Re: Strange Stepper Exerciser Behavior with McWire, and some McWire Comments April 08, 2008 10:53PM |
Registered: 16 years ago Posts: 37 |
I have the torque set to 100% for each, but that wasn't the problem. As Nophead suggested, I put a resistor in series and this solved both the erratic stepper behavior and the power supply dying.
I relooked at the wiki to see if this was just me ignoring instructions. I recall looking at the part of the power supply page that stated if you can't turn your supply on, try a shunt resistor. But the disconnect for me (and I assume for many users using decent new supplies) is that I could indeed get the power supply to turn on unloaded, its just the voltage regulator gave me 5 high and 12 low. I was able to get some stuff to work, but then had this hard-to-identify error with the z which occurred erratically. With a load on, it now gives me 5 slightly high and 12 slightly high, which is sufficient to do all the stepper exerciser tests etc.
It might be worth explicitly stating in the wiki that if your voltage tests are a bit off (especially w/r/t the power comms pin testing) or if you're having trouble with erratic stepper exerciser behavior, the FIRST thing to do is put on a shunt resistor (used a 12V car door light across the 5V rail on an unused molex on the same string of connectors, as per Nophead). My pin readings were a bit off as I described here (but close enough to fool me into thinking I might be ok):
[forums.reprap.org]
Thanks to Nophead for advising. After I searched some more I saw he'd already given out that advice in a different thread. Again, might be worth upgrading the prominence of this fix in the wiki.
Thanks
I relooked at the wiki to see if this was just me ignoring instructions. I recall looking at the part of the power supply page that stated if you can't turn your supply on, try a shunt resistor. But the disconnect for me (and I assume for many users using decent new supplies) is that I could indeed get the power supply to turn on unloaded, its just the voltage regulator gave me 5 high and 12 low. I was able to get some stuff to work, but then had this hard-to-identify error with the z which occurred erratically. With a load on, it now gives me 5 slightly high and 12 slightly high, which is sufficient to do all the stepper exerciser tests etc.
It might be worth explicitly stating in the wiki that if your voltage tests are a bit off (especially w/r/t the power comms pin testing) or if you're having trouble with erratic stepper exerciser behavior, the FIRST thing to do is put on a shunt resistor (used a 12V car door light across the 5V rail on an unused molex on the same string of connectors, as per Nophead). My pin readings were a bit off as I described here (but close enough to fool me into thinking I might be ok):
[forums.reprap.org]
Thanks to Nophead for advising. After I searched some more I saw he'd already given out that advice in a different thread. Again, might be worth upgrading the prominence of this fix in the wiki.
Thanks
Sorry, only registered users may post in this forum.