Home

I'm building a Mcwire repstrap (top picture [www.reprap.org] ) with the G-code firmware, ReplicatorG (0002). When I run this code, my x,y stages first go towards the motors (min_opto), then run away in the positive direction for both x, y towards the max_optos (ie: away from the motors; seems as if the extruder head is trying to position to the lower left part of stage). Is that consistent with the code below? I left my bot running for 5 minutes and the motors just keep on going, and going. Am I having problems with the homing? I also did hear the extruder motor buzz for 2 seconds, and the chrome did heat up.



G21 // mm as units.
G90 // absolute positioning.
G28 // go Home
M103 // turn extruder off.
M105
M106 // turn cooling fan on.
M108 S210.0 // set extruder motor to 210 RPM.
M104 S200.0 // set extruder temp to 200 C.
G1 X-9.11 Y-9.11 Z0.4 F480.0 // go to x,y,z = -9.11, -9.11, 0.4
G1 X-9.11 Y9.0 Z0.4 F480.0 // go to x,y,z = -9.00, -9.11, 0.4
G1 X-9.0 Y9.11 Z0.4 F480.0 // etc...
G1 X9.0 Y9.11 Z0.4 F480.0

Thanks for any insights.

Arthur

Have you set the steps/mm correctly? McWire's have a much higher resolution than a Darwin.

Generally the Gcode interpreter on the Arduino takes the startup position as 0,0,0 (home), but if you're not sure, set it explicitly by finding the min opto switches and then setting that to 0,0,0.

For example, I do something like this in my startup code:
G21
G90
G1 X-1000 Y-1000 //find the XY min optos
G1 Z-100 // find the Z min opto
G92 X0 Y0 Z0 // set the home position; you need to explicitly set them to 0

And then do your moves.

If you go to a negative # after that, beyond the opto endstop, you end up shifting your home position in the current software. Try it and you'll see what I mean.

It's probably easier to just send Gcodes manually from the Arduino serial monitor at first, until you get a feel for which way is up. Try using the right hand rule, and remember it's the motion of the extruder nozzle relative to the bed that you're measuring.

Wade

Hi Wade --

> Have you set the steps/mm correctly? McWire's
> have a much higher resolution than a Darwin.
yeah, it's correct. When I'm controlling the Mcwire using the RepG control panel, it is accurate.


> Generally the Gcode interpreter on the Arduino
> takes the startup position as 0,0,0 (home), but if
> you're not sure, set it explicitly by finding the
> min opto switches and then setting that to 0,0,0.
>
> For example, I do something like this in my
> startup code:
> G21
> G90
> G1 X-1000 Y-1000 //find the XY min optos
> G1 Z-100 // find the Z min opto
> G92 X0 Y0 Z0 // set the home position; you need to
> explicitly set them to 0
I did the explicit G-codes upfront and ReplicatorG/arduino still didn't listen! I had a G-code file do (because I couldn't get serial monitor to work--more on that later):
G21
G90
G1 X-10

And my Mcwire was still initially moving the extruder toward the bed and I don't even have G-code telling it to move the Z. Seems to be running it's own "startup sequence" -- where is it receiving these commands? What in neptune's name could be the problem? Restarting ReplicatorG doesn't flush any buffers and still seems to point to some mysterious place.

I should report that it seems to "basically" work because I'll let it run and it seems to do everything (x,y,z stages move right, heater works, fan works, extruder motor seems to be driven right). There is a discrepancy though between:
1) actual distance moved (cm)
2) what's reported on the RepG simulation window during a build (mm).



>
> And then do your moves.
>
> If you go to a negative # after that, beyond the
> opto endstop, you end up shifting your home
> position in the current software. Try it and
> you'll see what I mean.
>
> It's probably easier to just send Gcodes manually
> from the Arduino serial monitor at first, until
> you get a feel for which way is up. Try using
> the right hand rule, and remember it's the motion
> of the extruder nozzle relative to the bed that
> you're measuring.
That's the other thing, I had the arduino serial monitor up and typed in:
G21 // pressed
G90 // pressed
G1 X-10 // pressed

and it doesn't do anything. Is there a special syntax?


Alright, that just about covers it. Thanks for listening to the ramble of probs.

Arthur

Ah, OK, there is a file called machines.xml in the ReplicatorG directory, and it contains the startup sequence, which included (running from imperfect memory here) about a 1000 mm X and Y move to find the limit switches. If it's going the wrong way, and your limit switches aren't stopping it (McWire's move a bit differently than Darwins), it's not going to work for you. Delete that section to start with, or change it to something that works for your machine.

That gcode snippet you posted should move the head to X=-10. However, if it was already at x=-10, or at the min limit switch, nothing will happen, because you're already there.

More importantly, you should be getting an "ok" back from the Arduino after each command. If not, you've got com port trouble; you might have to unplug and replug the arduino, and check your baud rate settings. I think the gcode interpreter 1.3 uses 19200 baud.

Hope that helps. I've turned off the simulator window, and I'm running a more recent ReplicatorG from the repository, so I can't really help you with the simulator.

Wade

Edited 1 time(s). Last edit at 01/03/2009 02:47PM by Wade Bortz.

Thanks wade. Ah, the machines.xml is key -- I'll check that out. Is there a more recent version of RepG that I can try out? I couldn't find it here [reprap.svn.sourceforge.net] or here [code.google.com]

Arthur

It's on Zach's google code page (which you correctly linked to), but you have to check out a read-only version and compile it yourself. I'm not the guy to show you how to do that, as I can barely do it myself, and only on some machines. ReplicatorG 0002 will be enough to get you up and running though; that's what I used to print out all my parts. If you start running out of memory during very large builds (large meaning about 12 hours of continuous extruding) you might run into memory trouble; that's when you want to look at the more recent code. Hopefully something will be released by then anyway.

Alternatively, I think the Java host can deal with Gcodes too now.

Wade

Awesome -- That was it! I edited the machines.xml file and it mostly works or at least it moves in a logical, mostly predictable way. I'll print something out later. Thanks a lot Wade

Arthur