Control probs

Hi Folks,

I'm having really unexpected/intermittent problems with my McWire. I'm using replicatorG (v2) and am having several problems:

1) after I press "build" button on replicatorG, the z-motor moves the extruder (away from the z-motor) closer to the xy-bed. It moves it several centimeters. Is this normal? I'll have to familiarize myself with gcode commands to see if the file dictates this. So after pressing the initial "build", the x-stage and y-stage home back to the "min" opto, then they both go to the "max" opto and keep going sending them off the threaded rod -- they don't stop. (I've read the problems wade, leav, steve, rick had, but I'm not sure my problem is the same). [forums.reprap.org] [forums.reprap.org]

I've attached my test file "diamond_export.gcode" that came from "reprap_python_beanshell.zip".

2) my "max" opto-sensors don't appear to work for all axis'. The stages drive right through them as if they aren't even there. All the "min" opto's work though. Yet I've switched them out with the "min" opto's and so know that they work. I've defined "min" as closer to the motor; "max" as away from the motor.

3) When in the replicatorG "control panel", I'm able to correctly control the stages sometimes (ie: press "X+", it goes forward. press "X-", it goes back. press Y+",it goes fwd, etc). Other times, pressing "X+" or "X-" both make the stage go in the positive direction -- same for the other stages. Makes no sense why it happens sometimes. What could be the problem?

4) I don't have my board grounds terminated to the arduino ground because I followed this wiring: [reprap.org]
Should I have everything share a common ground? I'll try it none the less.

Thanks for any insights --

Arthur

Hi Authur

I think I have made the same errors that you have; though in my repstrap it doesn't un-thread it self.

Anyway you might simply have your motions or your endstop sensors backwards in that it is trying to home the axis and it is looking at the minimum end stop sensor as zips past the maximumn sensor.

Since the McWire has a moving table the motion of the motor is backwards to what you would normally expect. It has to move the table to the right so that the overhead Z axis moves to the left edge of the table on a home of the X axis.

A quick way to indentify which endstop sensor is which and verify that they are working is run Leav's pRINToPTO program.

I have updated his program to also display the endstops and include the pins.h file so it can work on both the Arduino and the Sanguino. It is attached as a zip file, you will need to uncomment the Sanguino defination at the top of the program since you have a Arduino processor and the darwin wiring for it.

And yes it is a good practice to tie the gounds together rather then relying on the grounds through the power cords.

Edited 1 time(s). Last edit at 12/31/2008 02:20PM by freds.

Thanks freds. I'll test that out tonight over a nice tall glass of champagne. Hopefully I can ring in the new year with working opto's

Arthur

freds -- I've attached a picture of how my opto's for each axis are oriented on my Mcwire. Is yours the same? Note placement of motors. In general, the "mins" are on the motor side; "maxes" are opposite side of motor.

Arthur

Arthur Wrote:
-------------------------------------------------------
> freds -- I've attached a picture of how my opto's
> for each axis are oriented on my Mcwire. Is yours
> the same? Note placement of motors. In general,
> the "mins" are on the motor side; "maxes" are
> opposite side of motor.
>
> Arthur

Hi Arthur

I am not building a McWire; though I do have a moving table like one.

The test proceedure for the program I gave you would be to click the serial monitor button after you upload the schetch and observe the program output as you block each sensor to make sure it is visable to your processor.

Though in looking at the labels you have applied to the picture; it seems to me that you have at least the Z axis turned arround.

Image having your extruder attached to the Z axis and all three axis's in the home position. The home position for the tip of the extruder would be at the surface of your table in the lower left corner of your table.

Edited 1 time(s). Last edit at 01/01/2009 11:18AM by freds.

freds -- I used the test program and all my opto's work fine (registering '1' when blocked). Additionally, I brought out the multimeter and all the opto's tested fine:

1) signal 'S' read 5V when blocked
2) signal 'S' read ~0V when unblocked

(On the ardiuno, the 'L' LED "sucks" some current from pin 13 causing the Z-max not to reach 5V when blocked, so I just desoldered that LED from the arduino. No LED now, but that's not really a big deal for me since it is covered by the breakshield anyway).

Still, strangely, when I run the latest Gcode firmware [reprap.svn.sourceforge.net] and ReplicatorG (v2) none of the max-opto's work.

Since I don't have a hardware problem (or at least I don't think I do), it has to do with the software. That requires going into the firmware code to figure it out. Maybe I can just forget the max opto's and handcode some of the Gcode so it doesn't go lower left too much as to run off the threaded rods. Knowing that home is where you said is very helpful.

I also tried the latest SNAP firmware and couldn't get it to work right off the bat -- not too motivated to figure that out. I'll go back to the idea about handcoding some Gcode. Stoked.

Arthur

Hi Arthur

Sounds like your opto's are backwards from mine, mine read a one when unblocked and zero when blocked.

In the parameters.h file there is a value SENSORS_INVERTING that you can set to flip the sense value.

Hi freds -- yeah, we have different opto's.

H21LOB Truth Table (yours, newer)
Status Output LED
Open HIGH Off
Closed LOW On

H21LOI Truth Table (mine, older)
Status Output LED
Open LOW On
Closed HIGH Off

[reprap.org]

Ah, now to figure out how to set home (G29 maybe?) at a specific point so my stages don't run off their rods. More reading, and probably new forum thread

Arthur

Actually I think yours should be the standard as it provides some robustness with the appropriate software.

Our CNC brethren use active low so if a wire breaks or there