Problems with gcode firmware scale factors

Re: Problems with gcode firmware scale factors

ZachHoeken — Thu, 23 Oct 2008 14:12:05 -0400

sorry it took me so long to reply to this thread!

the problem is that the currently released version of the arduino gcode interpreter defaults to inches instead of mm. so its interpreting the movement sent as inches.

if you use the latest subversion firmware, then that will fix your problems.

i'll try to make a new release of that firmware ASAP.

Re: Problems with gcode firmware scale factors

x2800m — Tue, 21 Oct 2008 13:33:57 -0400

I was using the version bundled with the regular firmware download, I believe it is v1.3. Actually I've decided to give the regular (non gcode) firmware another try. Apparently I don't get any crashes when I use the Reprap Live CD for a host. This leads me to believe the cause of all my troubles was within the RXTX libs or latency somewhere in the OS (I tried windows XP and Vista, as well as Ubuntu). Once I've finished tuning the machine for HDPE I may decide to give gcode another shot.

Well, the problem is not actually gone, as I just discovered. It simply takes longer to manifest itself. Oh the aggravation:X...

Re: Problems with gcode firmware scale factors

Wade — Mon, 20 Oct 2008 23:53:05 -0400

hey x2800m,

I don't think ReplicatorG changes the scaling on the gcodes before sending them; I believe the scaling is just used for the simulator window, so you can see what's where at the proper scale.

I have almost the exact scaling factors in my Arduino code, and I'm running a BfB cast Darwin, so those are probably correct. I rounded my x and y scaling factors to 8.0, because I figured I wasn't running a fractional number of teeth per revolution.

THe problem might be with your gcode file. Mine always start with a G21 code, which sets the units to mm - I don't see that in your posted code, so perhaps the default is inches. That might explain it.

Which version of the arduino gcode software are you running? I've been plaing with Zach's latest Experimental version, so I can use the extruder encoder.

Wade

Problems with gcode firmware scale factors

x2800m — Sun, 19 Oct 2008 14:37:56 -0400

Well, its been a frustrating week... So I've decided to switch to gcode after being unable to solve the arduino crash problem (even with the extruder motor unplugged). After figuring out how to use the gcode generation package (for those of you who can't seem to make sense of the output try opening the .stl file in AOI then applying a -90 degree rotation about the x-axis then exporting the corrected file. That should help you make sense of everything :)) I've run into another problem. I've decided to make use of the ReplicatorG software package (Thanks Zach) However when I use the jog controls within the control panel, a 1mm jog command results in a 20mm movement on the machine. At first I thought this was obviously a result of miscalculating the steps/mm or steps/inch constants in either the firmware, or the machines.xml file. However I've gone over these several times and I cannot seem to find the error. The settings I've used are displayed below. (BTW I'm using a laser cut B from B rep(st)rap). Any ideas would be most appreciated.

---------------------My machines.xml file--------------------------------

3-Axis Simulator
20

Allistair's Darwin

(homing routing)
G91
G1 Z10 F75
G1 X-999 Y-999 F2000
G92 X0 Y0 (set xy as home)
M104 S200
M108 S20
M101
G04 P10000
M103
G04 P5000
G1 X150 Y150
G1 Z-10 F75
G92 X0 Y0 Z0
(ready to print)

M104 S20
G91
G1 Z10 F50

-----------------------------------------------------------------------------
-------------------Firmware Configuration------------------------------------
-----------------------------------------------------------------------------
// define the parameters of our machine.

#define X_STEPS_PER_MM 8.0402
#define X_STEPS_PER_INCH X_STEPS_PER_MM * 25
#define X_MOTOR_STEPS 400

#define Y_STEPS_PER_MM 8.0130
#define Y_STEPS_PER_INCH Y_STEPS_PER_MM * 25
#define Y_MOTOR_STEPS 400

#define Z_STEPS_PER_MM 158.6927
#define Z_STEPS_PER_INCH X_STEPS_PER_MM * 25
#define Z_MOTOR_STEPS 200

//our maximum feedrates
#define FAST_XY_FEEDRATE 120.0
#define FAST_Z_FEEDRATE 10.0

// Units in curve section
#define CURVE_SECTION_INCHES 0.019685
#define CURVE_SECTION_MM 0.5

// Set to one if sensor outputs inverting (ie: 1 means open, 0 means closed)
// RepRap opto endstops are *not* inverting.
#define SENSORS_INVERTING 0

// How many temperature samples to take. each sample takes about 100 usecs.
#define TEMPERATURE_SAMPLES 5

/****************************************************************************************
* digital i/o pin assignment
*
* this uses the undocumented feature of Arduino - pins 14-19 correspond to analog 0-5
****************************************************************************************/

//cartesian bot pins
#define X_STEP_PIN 2
#define X_DIR_PIN 3
#define X_MIN_PIN 4
#define X_MAX_PIN 9
#define X_ENABLE_PIN 15

#define Y_STEP_PIN 10
#define Y_DIR_PIN 7
#define Y_MIN_PIN 8
#define Y_MAX_PIN 13
#define Y_ENABLE_PIN 15

#define Z_STEP_PIN 19
#define Z_DIR_PIN 18
#define Z_MIN_PIN 17
#define Z_MAX_PIN 16
#define Z_ENABLE_PIN 15

//extruder pins
#define EXTRUDER_MOTOR_SPEED_PIN 11
#define EXTRUDER_MOTOR_DIR_PIN 12
#define EXTRUDER_HEATER_PIN 6
#define EXTRUDER_FAN_PIN 5
#define EXTRUDER_THERMISTOR_PIN 0 //a -1 disables thermistor readings
#define EXTRUDER_THERMOCOUPLE_PIN -1 //a -1 disables thermocouple readings

--------------------------------------------------------------------------------

Edit:

Well it turns out that if I use Chris Meighan's jogging GUI, the machine repsonds correctly, i.e. a 100mm jog is 100mm. This leads me to believe my problem lies within the configuration of the replicatorg software package.

Edit #2:

Apparently the ReplicatorG software (version 0002) thought 1 inch = 1 mm so by setting the Arduino firmware values for steps/inch equal to the values for steps/mm I can get the ReplicatorG jog GUI to function correctly.