Welcome! Log In Create A New Profile

Advanced

Programmig issues - motherboard v1.2

Posted by Adam.m.Nelson 
Programmig issues - motherboard v1.2
May 12, 2011 11:13PM
Ok... I am trying to tune my Mendel. We finally got the thing running, and everything works. Just the steps per mm are wrong on all the axis.

I calculated the changes using the info on this page Reprap Axis Calibration. For the life of me I can't get it to upload to the board.

Windows 7 machine, Arduino 021 environment. I changed the baud rate settings in the device manager com port settings to 38400, but can't find what the other settings should be. I suspect its just a comms issue. Note: The Host software communicates fine with Mendel.

I have had the Arduino 21 environment tell me it has successfully uploaded twice (I've been trying different settings and what not, probably 100 failed uploads). However the changes don't seem to take effect as the axis is still calibrated wrong, and by the exact same 23mm as it was before it "successfully" uploaded. I've been searching around the net and the forum for a little over a day now, and figured I'd just ask.

So my question(s) are:

(1) Does anyone know all the com port settings to upload to the Sanguino chip?
- Baud Rate 38400, Data bits 8, Parity None, Stop Bits 1, Flow Control None. <--That's what I am currently using to program.
- Baud Rate 19200, Data bits 8, Parity None, Stop Bits 1, Flow Control None. <--That's what I am currently using to run the Host software.

(2) Am I tuning the axis right?

(3) If those settings are right... Any more ideas?

I tried to give enough info, If I missed something let me know.

Thanks in advance.


"Get busy living, or get busy dieing" - Red
Re: Programmig issues - motherboard v1.2
May 13, 2011 08:27AM
Be sure you are modifying the correct section.

In your configuration.h file there are settings for a number of boards... you could be changing the steps per mm values for the wrong board.

Ensure you are defining the correct motherboard. I have Gen3 electronics so in my firmware I define (around line 24 of the file)

#define MOTHERBOARD 2 (this is the standard mendel setting)

Then further down AFTER you find the condition (aroundd line 94)

#if MOTHERBOARD == 2

you need to set the (around line 121)
#define X_STEPS_PER_MM 10.047 (or the value you calculate)
and (around line 125)
#define Y_STEPS_PER_MM 10.047 (or the value you calculate)
and (around line 129)
#define Z_STEPS_PER_MM 833.398 (or the value you calculate)

hope this helps.

PS - I am using fairly old firmware so your line numbers may be different, but I doubt it would have changed much)

Edited 1 time(s). Last edit at 05/13/2011 08:28AM by AgeingHippy.
Re: Programmig issues - motherboard v1.2
May 16, 2011 06:27PM
Hey!

I assume your talking about in the config file, and I have all that.

#if BELT_PULLEY_TYPE == MENDEL_8_TOOTH_ORIGINAL
#define X_STEPS_PER_MM 4.784
#define Y_STEPS_PER_MM 4.368
#define Z_STEPS_PER_MM 1766.796

From the look of you line numbers the code has changed a lot, but I appreciate the input
Re: Programmig issues - motherboard v1.2
May 16, 2011 06:48PM
Note: This is the error I get:

Binary sketch size: 28490 bytes (of a 63488 byte maximum)
avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51
Re: Programmig issues - motherboard v1.2
May 17, 2011 02:11AM
For BOTH my Motherboard and my Extruder Controller as soon as I press the upload button on the Arduino software I then press and hold the reset button on the board I am uploading to until the text appears on the Arduino screen then I release the button. Using this method my firmware uploads every time without any problems.


Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse
Re: Programmig issues - motherboard v1.2
May 17, 2011 06:36AM
Thanks bob. I'll try that today!
Re: Programmig issues - motherboard v1.2
May 17, 2011 10:20AM
Bob, your my new favourite person, that did the trick. Now I have other issues lol.

Do you have the red LED blinking when the program is running? Because mine no longer does it, and I don't seem to be communicating properly with the host osftware. I no longer have control over the robot (which I use to have)
Re: Programmig issues - motherboard v1.2
May 17, 2011 03:20PM
ok, I can't get this thing to communicate for the life of me. Sometimes after I program it the led will do nothing (after it blinks fast as the data goes through), and other times it will start blinking almost like it use to (once a second). Am I missing something here?

I now get this as an output from the host console window:


C:\Program Files\Reprap>rem reprap-host -- runs Reprap Java host code with an ap
propriate classpath

C:\Program Files\Reprap>rem Amount of RAM to allow Java VM to use

C:\Program Files\Reprap>set REPRAP_RAM_SIZE=1024M

C:\Program Files\Reprap>rem reprap.jar file and stl file

C:\Program Files\Reprap>set REPRAP_DIR=C:\Program Files\Reprap

C:\Program Files\Reprap>rem Java3D and j3d.org libraries

C:\Program Files\Reprap>rem set JAVA_LIBRARY_DIR=C:\Program Files\Reprap

C:\Program Files\Reprap>rem cd so we can find the reprap-wv.stl file. Can we av
oid this??

C:\Program Files\Reprap>IF NOT EXIST reprap-wv.stl cd "C:\Program Files\Reprap"


C:\Program Files\Reprap>java -cp ".\reprap.jar;.\RXTXcomm.jar;.\j3dcore.jar;.\j3
d-org-java3d-all.jar;.\j3dutils.jar;.\swing-layout-1.0.3.jar;.\vecmath.jar;." -X
mx1024M org/reprap/Main
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7
comms: G-code: N0 M110 *3 dequeued and sent [0.015s/-1305664305818ms]
ERROR: GCodeWriter.waitForResponse() - dud response from RepRap:stX-strtstastrt
[1.566s/1551ms]
comms: Response: stX-strtstastrt [1.567s/1ms]
comms: G-code: N0 M110 *3 dequeued and sent [1.569s/2ms]


And no communication to the host (the host gui doesn't even come up).

I've tried playing with the com port settings in the properties file, in the device manager, and in the code, and they don't seem to change anything. I've also tried two different machines running different OS's. Maybe I should re-download the source code and start from scratch.

Does anyone have any thoughts?

You only need to change settings in the 'configuration.h" file right?
Re: Programmig issues - motherboard v1.2
May 17, 2011 03:49PM
I've also noticed that the mother board won't run of the USB power, but the extruder board will. Is this normal? Currently I need to run the Motherboard form the ATX power supply to program it.
Re: Programmig issues - motherboard v1.2
May 18, 2011 02:05AM
See this post.


Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse
Re: Programmig issues - motherboard v1.2
May 18, 2011 11:30AM
Thanks rhmorrison,

That explains the power issue, but it should be fine to run off of the ATX supply should it not? The whole system seems to be common grounded. Funnily enough I am in London Ontario also, I'll need to see how he made out.

I think my issues are purely code related, best I can tell the code isn't running on the chip.

I know communications work because they worked before I uploaded new firmware, and haven't changed anything since. Im going to try the changes on this page that you led me to.

Mods
Re: Programmig issues - motherboard v1.2
May 18, 2011 11:37AM
Right, should have read closer. Already did those mods.

Can someone send me their firmware? I had to make some changes to get mine to compile, and I can only assume I did something wrong. I tried it a couple times from a fresh download of the firmware, but always run into the same issue with the order of the included, and have to shuffle them around to get it to compile properly.

Mine now looks like this:
#include ctype.h
#include stdio.h
#include HardwareSerial.h
#include avr/pgmspace.h
#include "WProgram.h"
#include "vectors.h"
#include "features.h"
#include "Temperature.h"
#include "configuration.h"
#include "hostcom.h"
#include "intercom.h"
#include "pins.h"
#include "pid.h"
#include "bed.h"
#include "extruder.h"
#include "cartesian_dda.h"

I had to remove the arrow brackets around the first 4 to get the forum to let them post.

Other then that I just set my board type to the Gen3 and set my steps per mm. Not sure why this would break the code, but never the less.
Re: Programmig issues - motherboard v1.2
May 18, 2011 11:48AM
Well, while I am conceding I may as well post the config file too. I nuked the code for the settings for other boards, it shouldn't effect anything (I tried with it in and with it not in) but since the condition to read the code that was in those areas is never true it shouldn't effect anything.


#ifndef CONFIGURATION_H
#define CONFIGURATION_H

#include "features.h"

/*
* This is the configuration file for the RepRap Motherboard microcontroller.
* Set values in it to match your RepRap machine.
*
*
* //*RO means "Read Only" and should probably only be changed if you really
* know what you are doing...
*/


// pre-select a typical setup from the below list
// using typical pinouts and typical capabilities. see features.h for what typical setups we have available
//#define DEFAULTS DARWIN_DEFAULTS
#define DEFAULTS MENDEL_GEN3_DEFAULTS
//#define DEFAULTS MENDEL_MEGA_DEFAULTS
//#define DEFAULTS BATHPROTO_DEFAULTS

#ifndef DEFAULTS
#error Please edit configuration.h and at the very least uncomment one of the DEFAULTS definitions that best-matches your hardware.
#endif



//*********************************************************************************************
// These settings are for a typical "Darwin" machine:
//*********************************************************************************************
#if DEFAULTS == DARWIN_DEFAULTS
#endif

//**********************************************************************************************
// These settings are typical for a standard Gen3 Mendel
// using a STEPPER driven extruder and RS485 Extruder Controller
///*********************************************************************************************
#if DEFAULTS == MENDEL_GEN3_DEFAULTS

//#define MENDEL 1

#define CPUTYPE CPUTYPE_SANGUINO

#define ENABLE_PIN_STATE ENABLE_PIN_STATE_INVERTING // For RepRap stepper boards version 2.x and above the enable pins are inverting.

// RepRap opto endstops with H21LOI sensors are not inverting; ones with H21LOB are inverting.
//#define ENDSTOP_OPTO_TYPE ENDSTOP_OPTO_TYPE_H21LOI
#define ENDSTOP_OPTO_TYPE ENDSTOP_OPTO_TYPE_H21LOB

// are all axes using the same opto?
#define X_ENDSTOP_INVERTING ENDSTOP_OPTO_TYPE
#define Y_ENDSTOP_INVERTING ENDSTOP_OPTO_TYPE
#define Z_ENDSTOP_INVERTING ENDSTOP_OPTO_TYPE

// normal Mendel uses neither a heated bed, nor an Internal extruder PID code:
//#define TEMP_SENSOR TEMP_SENSOR_RRRF10K_THERMISTOR // Temperature measurement ( BED or Internal Extruder code. IF you use BOTH, you MUST use same measurement type - TODO fix this).

#define THERMAL_CONTROL THERMAL_CONTROL_PID

#define EXTRUDER_CONTROLLER EXTRUDER_CONTROLLER_RS485 // mendel usually uses RS485 for temperature, etc and the SDA/SCL lines ( to D9 and D10) for step& direction pins for stepper control.


#define MOVEMENT_TYPE MOVEMENT_TYPE_STEP_DIR // darwin axes are moved around with STEP/DIRECTION logic.


// pick the most likely pulley for a gen3 powered mendel
#define BELT_PULLEY_TYPE MENDEL_8_TOOTH_ORIGINAL

// Axis scaling in stepper-motor steps per mm of movement

// The steps/mm figures are for the original Mendel 8-toothed belt pulley
#if BELT_PULLEY_TYPE == MENDEL_8_TOOTH_ORIGINAL
#define X_STEPS_PER_MM 4.784
#define Y_STEPS_PER_MM 4.368
#define Z_STEPS_PER_MM 1766.796
#endif

// these ones are for the newer 9-tooth pulley: set-screw-drive-pulley_4_6-5_9_7_3off
// See mendel/mechanics/solid-models/cartesian-robot-m4/printed-parts/alternative-parts/readme
#if BELT_PULLEY_TYPE == MENDEL_9_TOOTH_NEWER
//#define X_STEPS_PER_MM 8.9307
//#define Y_STEPS_PER_MM 8.9307
//#define Z_STEPS_PER_MM 740.798
#endif

#ifndef BELT_PULLEY_TYPE
#error PLEASE TELL US WHAT TYPE OF EXTRUDER PULLEY YOU ARE USING.. 8 or 9 toothed?
#endif

#define INVERT_X_DIR 0
#define INVERT_Y_DIR 0
#define INVERT_Z_DIR 0

#define TEMP_SENSOR TEMP_SENSOR_RRRF100K_THERMISTOR // RRRF 100k thermistor is typical for mendel, yes?

#define DATA_SOURCE DATA_SOURCE_USB_SERIAL // well stream the data from USB to the CPU.

// Stepper-driven extruder
// E_STEPS_PER_MM is the number of steps needed to extrude 1mm out of the nozzle.
// E0 for extruder 0; E1 for extruder 1, and so on.

#define E_STEPS_PER_MM 0.9 // NEMA 17 extruder 5mm diameter drive - empirically adjusted
//#define E0_STEPS_PER_MM 2.2 // NEMA 17 59/11 geared extruder 8mm diameter drive
//#define E1_STEPS_PER_MM 2.2 // NEMA 17 59/11 geared extruder 8mm diameter drive

// The number of real extruders in this machine
#define EXTRUDER_COUNT 1

//early extruders were old and large thermal mass, change this if you use a kapton tape extruder!
#define EXTRUDER_THERMAL_MASS EXTRUDER_THERMAL_MASS_LARGE

// Both Darwin and Mendel have MIN endstops, but not MAX ones.
#define ENDSTOPS_MIN_ENABLED 1
#define ENDSTOPS_MAX_ENABLED 0

//our maximum feedrates in mm/minute
#define FAST_XY_FEEDRATE 3000.0
#define FAST_Z_FEEDRATE 50.0

#define ACCELERATION ACCELERATION_ON

// Set these to 1 to disable an axis when it's not being used,
// and for the extruder. Usually only Z is disabled when not in
// use. You will probably find that disabling the others (i.e.
// powering down the steppers that drive them) when the ends of
// movements are reached causes poor-quality builds. (Inertia
// causes overshoot if the motors are not left powered up.)

#define ENABLE_LINES HAS_ENABLE_LINES

#define DISABLE_X 0
#define DISABLE_Y 0
#define DISABLE_Z 1
#define DISABLE_E 0

// classic mendel does not have heated bed, it's a newer feature
#define HEATED_BED HEATED_BED_OFF

// gen3 mendel use stepper motor driver v. 2.3 for XY&Z ( and use Extruder Controller 2.2 over RS485 for E)
#define STEPPER_BOARD STEPPER_DRIVER_TWO_POINT_THREE


#endif

//**********************************************************************************************
// These settings are typical for a Mendel with an Arduino Mega controller and Pololu stepper drivers or similar
// See [reprap.org]
//*********************************************************************************************

#if DEFAULTS == MENDEL_MEGA_DEFAULTS
#endif


//**********************************************************************************************
// These settings are for the Bath prototype Mendel
//*********************************************************************************************


#if DEFAULTS == BATHPROTO_DEFAULTS
#endif

//**********************************************************************************************
// These settings are for Makerbot hardware running Reprap firmware!
//*********************************************************************************************

#if DEFAULTS == MAKERBOT_DEFAULTS
#endif

//**********************************************************************************************
// These settings are for CUSTOM RepStraps, etc.
//*********************************************************************************************

#if DEFAULTS == CUSTOM_DEFAULTS
#endif

//**********************************************************************************************
// All other Settings not specific to the motherboard type, or derived from the above settings
//*********************************************************************************************


// support imperial settings derived from metric:
#define X_STEPS_PER_INCH (X_STEPS_PER_MM*INCHES_TO_MM) // *RO
#define Y_STEPS_PER_INCH (Y_STEPS_PER_MM*INCHES_TO_MM) // *RO
#define Z_STEPS_PER_INCH (Z_STEPS_PER_MM*INCHES_TO_MM) // *RO

// The speed at which to talk with the host computer; default is 57600
#if DEFAULTS == MENDEL_GEN3_DEFAULTS
#define HOST_BAUD 19200
#endif



// Data for acceleration calculations - change the ACCELERATION variable above, not here
#if ACCELERATION == ACCELERATION_ON
#define SLOW_XY_FEEDRATE 1000.0 // Speed from which to start accelerating
#define SLOW_Z_FEEDRATE 20
#endif

#if ENABLE_PIN_STATE == ENABLE_PIN_STATE_INVERTING
#define ENABLE_ON LOW // *RO
#else // *RO
#define ENABLE_ON HIGH // *RO
#endif // *RO

//derived generic thermistor truth test?
#if ( (TEMP_SENSOR == TEMP_SENSOR_EPCOS540_THERMISTOR) \
|| (TEMP_SENSOR == TEMP_SENSOR_EPCOS560_THERMISTOR) \
|| (TEMP_SENSOR == TEMP_SENSOR_RRRF100K_THERMISTOR) \
|| (TEMP_SENSOR == TEMP_SENSOR_RRRF10K_THERMISTOR) \
|| (TEMP_SENSOR == TEMP_SENSOR_RS10K_THERMISTOR ) \
|| (TEMP_SENSOR == TEMP_SENSOR_RS100K_THERMISTOR ) \
|| (TEMP_SENSOR == TEMP_JAYCAR_NTC_125DEG_10K_THERMISTOR) )
#define USE_THERMISTOR 1 //generic definition, set by the above.
#endif

// if user didn't specify they wanted a heated bed, then they normally didn't
#ifndef HEATED_BED
#define HEATED_BED HEATED_BED_OFF
#endif

// if user didn't specify the type of thermistor/sensor on their heated bed, but the heated bed is
// enabled, then assume it's the same as their extruder sensor:
#ifndef BED_TEMP_SENSOR
#define BED_TEMP_SENSOR TEMP_SENSOR
#else
#ifndef HEATED_BED
#error you can not set the BED_TEMP_SENSOR constant without having HEATED_BED also set.
#endif
#endif


// if user specified a single E value, and no E0 value, it's a Darwin, lets define it as E0:
#ifndef E0_STEPS_PER_MM
#ifdef E_STEPS_PER_MM
#define E0_STEPS_PER_MM E_STEPS_PER_MM
#else
#error you currently must define either a E0_STEPS_PER_MM or E_STEPS_PER_MM value
#endif
#endif

// for compatibility in intercom.h
#if EXTRUDER_CONTROLLER == EXTRUDER_CONTROLLER_RS485
#define MY_NAME 'H' // Byte representing the name of this device
#define E0_NAME '0' // Byte representing the name of extruder 0
#define E1_NAME '1' // Byte representing the name of extruder 1
#define RS485_MASTER 1 // *RO
#endif

// The number of 5-second intervals to wait at the target temperature for things to stabilise.
// Too short, and the extruder will jam as only part of it will be hot enough.
// Too long and the melt will extend too far up the insulating tube.
//Use bigger values for lower thermal mass extruders.
#if EXTRUDER_THERMAL_MASS == EXTRUDER_THERMAL_MASS_LARGE
#define WAIT_AT_TEMPERATURE 10
#else
#define WAIT_AT_TEMPERATURE 3
#endif

#ifndef ENABLE_LINES
#error You must define ENABLE_LINES as either HAS_ENABLE_LINES or HAS_NO_ENABLE_LINES
#endif

#ifndef EXTRUDER_CONTROLLER
#error You must define EXTRUDER_CONTROLLER for you machine layout in configuration.h
#endif


// if we are not using aceleration code, we define these constants just to prevent compile errors on the unused 'f' coordinate of the DDA
#ifndef SLOW_XY_FEEDRATE
#define SLOW_XY_FEEDRATE 0.0
#endif
#ifndef SLOW_Z_FEEDRATE
#define SLOW_Z_FEEDRATE 0.0
#endif
// PID gains. E_ = extruder, B_ = bed. The Es are about right for a brass extruder about 8 mm
// in diameter and 30 mm long heated by a 6 ohm coil with a 12v supply. The B_ values are OK
// for the bed described here: [reprap.org]
// Extruding increase biases the input to the extruder heater when the extruder
// is running as it requires more power.
// +/- BAND is the proportional band. Setting this to 0 gives bang-bang control; setting
// it very large gives full PID all the way.

#define E_TEMP_PID_PGAIN 2.0
#define E_TEMP_PID_IGAIN 0.15
#define E_TEMP_PID_DGAIN 0.5
#define EXTRUDING_INCREASE 7
#define E_TEMP_PID_BAND 0.0

#define B_TEMP_PID_PGAIN 2.0
#define B_TEMP_PID_IGAIN 0.07
#define B_TEMP_PID_DGAIN 1.0
#define B_TEMP_PID_BAND 1000.0


//******************************************************************************

// You probably only want to edit things below this line if you really really
// know what you are doing...


void delayMicrosecondsInterruptible(unsigned int us);

// Inline interrupt control functions

inline void enableTimerInterrupt()
{
TIMSK1 |= (1<<OCIE1A);
}

inline void disableTimerInterrupt()
{
TIMSK1 &= ~(1<<OCIE1A);
}

inline void setTimerCeiling(unsigned int c)
{
OCR1A = c;
}

inline void resetTimer()
{
TCNT2 = 0;
}

extern LongPoint zeroHit;


#endif

//*************************************************************************
Re: Programmig issues - motherboard v1.2
May 18, 2011 09:54PM
Well just to keep things confusing, I re-compiled the code, uploaded it, and now I have red LED action. It ends up staying on all the time.

Half the time I get this from the console screen:



C:\Program Files\Reprap>rem reprap-host -- runs Reprap Java host code with an ap
propriate classpath

C:\Program Files\Reprap>rem Amount of RAM to allow Java VM to use

C:\Program Files\Reprap>set REPRAP_RAM_SIZE=1024M

C:\Program Files\Reprap>rem reprap.jar file and stl file

C:\Program Files\Reprap>set REPRAP_DIR=C:\Program Files\Reprap

C:\Program Files\Reprap>rem Java3D and j3d.org libraries

C:\Program Files\Reprap>rem set JAVA_LIBRARY_DIR=C:\Program Files\Reprap

C:\Program Files\Reprap>rem cd so we can find the reprap-wv.stl file. Can we av
oid this??

C:\Program Files\Reprap>IF NOT EXIST reprap-wv.stl cd "C:\Program Files\Reprap"


C:\Program Files\Reprap>java -cp ".\reprap.jar;.\RXTXcomm.jar;.\j3dcore.jar;.\j3
d-org-java3d-all.jar;.\j3dutils.jar;.\swing-layout-1.0.3.jar;.\vecmath.jar;." -X
mx1024M org/reprap/Main
DEBUG: The distribution preferences file and yours match. This is good. [0.006s
/-1305774074219ms]
DEBUG: GCode opening port COM4 [0.110s/104ms]
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7
DEBUG: Attempting to initialize Arduino/Sanguino [1.289s/1179ms]
comms: G-code: N0 M110 *3 dequeued and sent [3.295s/2006ms]
ERROR: GCodeWriter.waitForResponse() - dud response from RepRap:stastastat [4.95
8s/1663ms]
comms: Response: stastastat [4.958s/0ms]
comms: G-code: N0 M110 *3 dequeued and sent [4.959s/1ms]



And the other half the time I get:



C:\Program Files\Reprap>rem reprap-host -- runs Reprap Java host code with an ap
propriate classpath

C:\Program Files\Reprap>rem Amount of RAM to allow Java VM to use

C:\Program Files\Reprap>set REPRAP_RAM_SIZE=1024M

C:\Program Files\Reprap>rem reprap.jar file and stl file

C:\Program Files\Reprap>set REPRAP_DIR=C:\Program Files\Reprap

C:\Program Files\Reprap>rem Java3D and j3d.org libraries

C:\Program Files\Reprap>rem set JAVA_LIBRARY_DIR=C:\Program Files\Reprap

C:\Program Files\Reprap>rem cd so we can find the reprap-wv.stl file. Can we av
oid this??

C:\Program Files\Reprap>IF NOT EXIST reprap-wv.stl cd "C:\Program Files\Reprap"


C:\Program Files\Reprap>java -cp ".\reprap.jar;.\RXTXcomm.jar;.\j3dcore.jar;.\j3
d-org-java3d-all.jar;.\j3dutils.jar;.\swing-layout-1.0.3.jar;.\vecmath.jar;." -X
mx1024M org/reprap/Main
DEBUG: The distribution preferences file and yours match. This is good. [0.006s
/-1305774074219ms]
DEBUG: GCode opening port COM4 [0.110s/104ms]
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7
DEBUG: Attempting to initialize Arduino/Sanguino [1.289s/1179ms]
comms: G-code: N0 M110 *3 dequeued and sent [3.295s/2006ms]



I've uploaded a video of the debug LED, until the time I say "I'll start the host software" I've done nothing but reset the board and turn on the 12 volts. Seems it needs to encode on Vimeo, so I will post a link when its ready.
Re: Programmig issues - motherboard v1.2
May 19, 2011 11:10PM
After a team effort and 6 hours of playing around our Mendel still makes little sense with the generic firmware. If we re-start the host software enough times we will get a combination of 5 different outcomes, eventually leading to the debug LED flashing, and the unit reporting a temperature. We thought this was great until we determined that doing anything but watching the temperature or turning on/off the extruder heater would crash the robot solid. Solid red led, and frozen host software.

We've tried a new dl of code from the repository, moved the temperature.h include call to get the code to compile (tested on Arduino 018-022, with this working on all but Arduino 022) with various failing results; most leading to the random accurate temperature display on the host. If someone is running a similar setup I would LOVE to see their configured firmware to see what we've done wrong here. Motherboard v1.2, extruder controller v2.2, and stepperdrivers v2.3.

Best I can tell the firmware isn't running on the chip, and it eventually starts after a random number of connection attempts, it almost seems like the init is getting skipped. I know how to check this in a PIC environment, but not Atmel.

We've decided to abandon the standard firmware, and have moved onto trying the teacup firmware. We got a stable connection with the Re-Snapper host, and are working on getting the config right. I won't bother you guys that, I suspect I have a couple days of digging before I should start asking questions.

If someone can send their configured standard firmware I will love them forever, we must have missed something.
Re: Programmig issues - motherboard v1.2
May 20, 2011 09:12AM
Ok curiosity got the best of me and I went back to look at the generic firmware again with a fresh mind. The code is indeed running, all be it not very well. When I use the serial monitor I see the following message stastststststststststststst ect. I changed up the start message to make sure and sure enough I got 123121212121212121212 in a never ending stream.

Does anyone have any ideas? I'm going to keep playing with this, but if someone has input its definitely welcome.
Re: Programmig issues - motherboard v1.2
May 20, 2011 10:23AM
F&% Ya! Found it!

Turns out the RS485_BUF_LEN was set to 20 which is too small?

Note: In the comments in intercom.h it says this setting is in the configuration.h file, but its really in the intercom.h file line 71.

I doubled its value from 20 to 40 and have atleast stable communication, Looks like it needs tweaking, but its a start. The debug LED has also started blinking again.

I got the file from the repository like this, are other people having this issue?

Edited 2 time(s). Last edit at 05/20/2011 12:37PM by Adam.m.Nelson.
Re: Programmig issues - motherboard v1.2
May 21, 2011 07:58PM
ok, so I can communicate, I've tested all the inputs, and can move all the axis (including the extruder). However my Mendel still loves to crash.

Regarding the RS485_BUF_LEN I found the following:

The Original value was 20. Tested Values that give me a debug led 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 60, 63
Failing values 36 and lower, 64 and higher.
Settings that communicate (not all inclusive) 40, 50, 55


Now I have a reset problem with the robot. Using the serial monitor I have been testing the latest issue, I can retrieve information GCode M114, turn on, modify, or monitor the heater and temperatures with out an issue. However if I try to move the robot I get continual errors, in a pattern. For example I can send a code to move an axis, Blue is what I send, Red are responses:

G0 X000 Y10 Z000 E000 F000
ok
G0 X000 Y20 Z000 E000 F000
ok
G0 X000 Y30 Z000 E000 F000
start

This pattern never fails. I did some code testing and commented out the setFatal() conditions one at a time to see what was causing the issue, and it kept happening, same pattern, all the time, leading me to believe its something else doing the resetting. I should note this will happen with X Y Z or E movements in that pattern. My next step I suppose is to add code to set a flag for each kind of Fatal to see if it is indeed that resetting the robot.

While writing this I realised the buffer I changed is probably only used in the comms with the extruder board, as I don't think the rest is RS485, maybe the problems there, more testing to follow.

Also while writing this I got my first restart while pulling info from the Mendel, it crashed while transmitting me data. The serial monitor output is below:

start
G0 X000 Y10 Z000 E000 F000
ok
G0 X000 Y20 Z000 E000 F000
ok
M114
ok C: X:0.start
M114
ok C: X:0.00 Y:0.00 Z:0.00 E:0.00
M114
ok C: X:0.00 Y:0.00 Z:0.00 E:0.00

My question to the people who maintain the code for Mendel:

Has the latest release been tested on Gen3 electronics? Is anyone else having issues like this? These seem like more then just calibration/ configuration issues we are having here.

I know by now no-one is probably listening, but its a good place to keep my thoughts together worst case scenario.

Any thoughts are welcome!

Edited 1 time(s). Last edit at 05/21/2011 08:06PM by Adam.m.Nelson.


"Get busy living, or get busy dieing" - Red
Re: Programmig issues - motherboard v1.2
May 21, 2011 08:24PM
It dawned on me that this is no longer a programming error, so I should probably start a new thread.

Moved here:

http://forums.reprap.org/read.php?146,84522
Sorry, only registered users may post in this forum.

Click here to login