Reverve the motor

When I single step one axis of my drill machine, it putts along. When I negative step it, it does nothing. When I press home, the motor stops, doesn't reverse and the axis position slider goes home. Since two H bridges are used each time , it can't be the hardware, either the software, firmware or some setup I am unaware of. I am only using one axis now

Check that you have jumpers on both the min and max sensors. I think this is the usual behavior you'd see with a jumper on the max but none on the min. It's refusing to negative step because it thinks you're already at the negative limit.

have both jumpers, still no reverse and when home is pressed, it just stops

I can confirm that using a test stepper here, I get full bi-directional motor control, unless one of those jumpers is loose. If it stops when home is pressed, most likely the "min" jumper is the one giving you grief.

If you want to try and confirm this by looking at the SNAP packets as they fly back and forth, edit ~/.reprap/reprap.preferences so CommDebug=true and then restart the RepRap host software. The terminal session from which you start it should then display a lot of info (in hex at present, unfortunately not that easy to read ... I have plans for improving that!) about each packet sent and received. This should let you eliminate any host-related issue causing this problem.

Since we're running the same firmware, I doubt you have a firmware issue that I don't have. So most likely, what you are seeing is a wiring/construction glitch of some sort, related to the min (home) endstop sensor.

Jonathan

I am using firmware stepmotor.hex stepmotorb.hex and stepmotorc.hex. What is this stepmotor1a.hex? I downloaded them at least a month ago, has their been an update?
I get an error when reprap starts, something about open something 1, will run any way, could this be significant?

The pic has two direction control pins per bridge and an enable (5 pins). Forward has a 4 step sequence, reverse is that 4 step sequence run backwards. all 5 pic pins are used to drive it forwards or backwards, so the pics outputs are right so that verifies the soldering. Besides, I used another axis board and got the same results. The stepper is wired right else it wouldn't go forward. I wired it just the same as the stepper I sent you, red, blue, green and black

Edited 1 time(s). Last edit at 07/21/2007 10:54PM by englewood.

You were right, I managed to miss the middle signal pin (min) with the cowbell jumpers on TWO boards, this must be a record! I really reprapped it this time. I just wish I had one of those molex pin removal tools, so I could finish up the Z axis connection. The X and Y are 1/4" 20 threaded rods, but the Z is geared through a timing belt. Twenty rev per inch or 4000 pulses per inch for the X and Y

Englewood,

I can duplicate the exact behaviour you describe (steps forward work, steps backward do not, Home does nothing), if I remove the jumper from connector K2 (the 3 pin connector closest to the debug LED on the StepperController board).

It really does seem fairly unlikely to me that there is some other issue, unrelated to the min endstop detection, that causes these exact symptoms!

(1) Just in case: with the StepperController board oriented so the power input is top left, you should be jumpering the two rightmost pins of K2 (and also of K1), pins 2 and 3 of the connector. Can you please confirm that is where you have the jumper(s)?

(2) Just use X axis firmware (stepmotor.hex) in one board, until you have that board fully working. Hooking up three boards before the first one passes the tests specified on the Wiki is asking for trouble, IMO! Keep things as *simple* as possible when troubleshooting. There has been no update to the released firmware package since May 29th. Connections from the board to the stepper are apparently fine, as you say. The issue is that your PIC believes the "min" or Home endstop has been reached. Does this problem still happen with just one (X-axis) controller and stepper in the serial ring?

(3) If you can capture the actual error message you are seeing at RepRap startup, rather than "something about", it might help provide a clue. Or it may be totally unrelated! You can use the script command to capture it simply under Linux.

(4) Can you use the "poke" test program to make the stepper move in both directions, or only in one? That would be a good test to eliminate the host software from your list of possible causes. Does the firmware/tools/dance.sh test script work for you (you may need to edit it to use the appropriate serial port first)?

(5) Also, what did you see when running with CommDebug=true? Please attach a log file or something, so we can look it over for clues, too.

I'm pretty confident the issue is a construction/wiring issue of some sort, but if you are not (yet?) convinced of that, then let's work to eliminate the host software and the firmware as likely causes of this issue.

My current hypothesis is that (a) we are running the same host software (b) we are using the same firmware (c) we are using boards and wiring built by different people. Therefore, if differences in operation emerge, (c) is the most likely cause thereof. Combine this with (d) I get the exact behaviour you describe if my jumper across the min endstop contacts is removed... and I think the most likely cause of this issue is pretty clear!

Jonathan

[ Thought for the future: if the ACK packets in response to stepper movement commands could include two bits with the state of the min and max endstops, debugging this kind of issue would become trivial, and if desired the host software could display their status clearly on screen. Do we have two unused bits anywhere in those packets we can use for this purpose? If not, maybe a separate "status please" command could return this info, plus current position and speed settings and sync mode? ]

Heh, You posted while I was creating my response! Anyway, glad it works now.

Jonathan

Well I tried it this morning and I could single step forward and backward, but when I hit home, it would change color and the stepper screen freezes. I have to shut the rep rap software down and restart. It easily moves the drill machine though. I want to calibrate the X Y and Z, is there a procedure for that and an explanation of all of the settings in the preference page?

I just ran it with two axis,(The X and the Z, the boards that were closer). If it hit the Home button, the interface freezes. The Single step for both axes worked great and if the Min or Max jumper is pulled, it stopped. I moved the slider to the actual position bar and the motor stopped. The error at the beginning of the reprap program is something about gtx version 1.2 when 1.3 should be running. It is a warning not an error.

> when I hit home, it would change color and the stepper screen freezes.

Based on [www.reprap.org] it sounds like either your controller is failing the second part of Test #6, or something still isn't right about your home endstop.

Are you following the test process outlined on the Wiki? That behaviour is what I would expect, until you then temporarily remove the K2 jumper (as the instructions suggest) to tell it it reached "home". The host software is (I suspect) not really locked up, it is just waiting for the PIC to ACK the home command, telling the host "OK, I reached home"! It won't send that ACK until pins 2 and 3 of K2 go open circuit. Again, if you turn on CommDebug=true, you can see this happening in terms of the host to PIC communication that is going on.

> It easily moves the drill machine though.

You hooked it to the machine already? Before the board is fully tested? Why? Given your P.E. background, I'm a bit surprised you seem to be skipping tests ... professional engineers don't do that when building bridges or nuclear reactors, etc. RepRap is not as complex (or dangerous) as a nuclear reactor, but proceeding in a step-by-step fashion testing carefully as you go is still very much recommended as you build one :-) [Now I've said this, of course, I'm just *bound* to miss a step somewhere in my own construction process, so everyone can remind me of what I have written!]

> I want to calibrate the X Y and Z ...

Do you now have real endstop switches hooked up, or just jumpers on the min and max connectors? Have you tested the endstops (multimeter across the output on resistance or continuity range, move the flag in and out of the optoswitch and watch what happens)?

The "calibrate" button in the stepper screen is a bit of a mystery to me, I'm not sure whether it has working code behind it. Once you can successfully "home" all 3 axes, I'd suggest talking to EricM on #reprap about calibration for screw-drive milling-machine-based repstrap machines, since his is nicely calibrated now.

Documentation on all the preferences is currently somewhere between non-existent and pretty weak; reading the Java source code is the canonical approach at the moment, I think! There is a recent Wiki page RepRapSoftwarePreferencesDocumentation about the preferences, and a request for people to post their own settings, as part of a process to correct this lack of good information. See [reprap.org] . Hopefully you can contribute to this yourself as you move forward.

Jonathan

It was the home button on the Java interface. The stepper exerciser locks up. not allowing me to slide any of the sliders. The Navy taught me to own up to my mistakes and learn from them. Mistakes happen, repeats shouldn't. I traced all wires from the L298 to my motors on the machine and they are 12VDC stepper, you can't screw them up with less than 12VDC. Each coil is hooked to a bridge. The single step of both axes works fine in fwd and reverse. The slider bars, when moved from the actual position bar, rotate the motors in the correct direction and stop when I slide the slider over to the actual position bar, just like they should. The motors stop when I remove the jumper,(gnd) from the Max input, just like it should. If I hit the Home button on either axes, none of the controls, slider, calibrate and single step work. I can't even close the stepper exercise windows, I have to shut the reprap program down. This is no where near the complexity of a D2G reactor. This starts a 4 step switching sequence to cause the motor to step. Since the position depends on the brake the coils are on all the time when the motor is stopped, they will get hot in time. On my ship I had a step by step manual, I followed it religiously every time. The directions here change from week to week. Essentially, step speed and direction should be tested,
then max and min switches should be tested and then see if it attempt to return home when this control button is pressed, if it does reverse, pull the min jumper to let the controller know it is home and the motor should stop, test complete. Then calibration factors and coordination between the motor to allow for a constant speed, even at an angle. I need the right size molex pins to add the final axis and the 3 mechanical home switches. I have mechanical stops for max limit. My boards were never bigger than 6", no motherboard drilling here, just picstik devices with the pic 16C84 and Pbasic

Edited 2 time(s). Last edit at 07/22/2007 05:42PM by englewood.

whoa there.... you're moving at warp speed and I'm having a very hard time figuring out what the problem is and what you've tried to fix it. If your boards or software aren't working, forget about calibration until you trust them.

It sounds like almost everything is working the way it should. Maybe everything... On my board, which I assume is working, when I hit "home" with both jumpers in place, the stepper tester interface freezes. It also starts stepping the motor backwards. When you pull the "min" jumper to signal it's at the lower limit, the motor stops, the user interface comes back to life, both the desired and actual sliders for that axis are set to zero. If it takes more than a few minutes for you to pull the jumper, I think you get an IO exception and the interface comes back to life also. I'm working with slightly modified firmware and host software, but I think the frozen interface is a normal thing.

I have broadcom chips built in for wireless. They work great in windows, but not in ubuntu.
I was using an air something card, but I had to give it to my girlfriend for the wireless network I setup for her. I have a Belkin F5D7010 wireless notebook card but guess what, ubuntu hates it! I can only use the reprap software in ubuntu, but I can only get on the net in windows, (I have a dual boot laptop). When I built this drill machine, I bought plans and software from CaMTRONICS and the software was great, I think it was DANCAM. I have lost the original software. I notice that sometimes when I reboot ubuntu, the interphase works great and then, (with the same setup) it acts squirrelly. I need to learn a lot more about Java and Ubuntu to better understand the software side.It does have to be stable before you can calibrate. Did you read about Dr. Higgs's new extruder? I think we should incorporate some of his design features in the kit extruder. Turning that Comm-debug to true does give you great feedback. I just wish that preference page had a manual!

> Did you read about Dr. Higgs's new
> extruder? I think we should incorporate some of
> his design features in the kit extruder.

Hey! Let me get the thing actually printed and at least a few hundred operating hours behind it before we start generating too much excitement, okay?

Englewood,

Our UCB test instructions are fairly detailed, thanks to Zach, and have been unchanged for weeks (I added a single short paragraph yesterday, before that they have had only very minor edits since June). You do not seem to be even close to "following them religiously". [ If the fact that the Wiki is continuously updated really bothers you, I suggest that you take a snapshot of it for your own personal use, and follow the information in that static snapshot. ]

This is the second time you have asked the community for troubleshooting help, and when other Repstrappers (not just me) have taken the time to respond and accurately identified the issue for you, you have then rejected their diagnosis based on your own theories and tests -- and only later come to realize that in fact, the advice you received from the community was correct. There is probably a lesson to be learned from that.

Even if RepRap is a couple of orders of magnitude simpler than a nuclear reactor, which of course it is, the same basic troubleshooting principles apply. If the Reprap system were so simple that it did not require systematic troubleshooting and testing, you'd not be asking for help, you'd already have it working perfectly! You *are* asking for help, therefore it must be sufficiently complex to require a systematic and careful approach.

Please, slow down and work one step at a time towards understanding and resolving your issues.

If you believe there is a fault with the home button in the Java interface, you are free to continue to believe that (and even to search the Java code to find and fix it!). No-one else has duplicated such a fault, running the same software. That same home button works as documented for others, just not (apparently) for you. Is it possible the software and the button work correctly, but your hardware may not be constructed so as to respond to the "home" SNAP command packet the way other people's hardware does? Did you enable CommDebug=true to gain further insight into what happens when you press that button, as I have suggested twice earlier in this thread? If so, what exactly did you see? Having pressed it, what happens when you remove the K2 jumper? Do your results confirm your theory about where the issue lies?

The current set of tests do seem to me to test control of the stepper in both directions, and of the home endstop. The "max" endstop is not tested, an omission which should perhaps be corrected. (I am experimenting with the CMD_SENSOR command today in an effort to understand how that command (returning PORTA and PORTB values, which include the min and max sensor values) may be helpful in endstop testing). The current tests most definitely do test whether the axis attempts to "return to home" when the home button is pressed in the Stepper Exerciser dialogue.

If you have a set of improved test instructions for the RepRap StepperController board, please post them, in full, so that the whole RepRap community can benefit from them. If you have specific suggestions on how they can be improved, please post those, too. Otherwise, I suggest that you go through the existing tests, carefully, in the order listed, and tell us how and when your results differ from those the instructions tell you to expect. I suspect that it will be hard or impossible for you to calibrate your robot until it has working "home" endstops.

Focus on one step at a time, do not jump ahead. That way, together, we can work as a community and help you make progress.

Jonathan

P.S. If you are having wireless networking grief, I suggest you use wired networking under Linux; pretty much every wireless router also has wired LAN ports on it, and most desktop and laptop PCs that have a wireless NIC also have a wired one. Even if for some reason you absolutely cannot network your Linux machine at all, you could still transfer files containing debug logs or screen captures from it using a USB key or even a floppy disk. Or, if you prefer, work on getting the Windows machine to run the RepRap host code. It really does run under Windows too.