but defining MANUAL_HOME_POSITIONS should make the new firmware work with "Solidoodle" values.

Adrian, if you have some time could you please check this, if it's not too much trouble? Thanks!

Ok, uncommented MANUAL_HOME_POSITIONS and reset MAX_* to 250 and yes this fixes behavior back to 'whats expected'. Prints are back at the right co-ordinates. Good find!

Might want to add this to your previous post Rincewind!

#define MANUAL_HOME_POSITIONS

is defined (which is not in our case). This was not happening in the older version of the firmware. Actually this is a harmless bug in our firmware: we are defining the MANUAL_HOME_POS values but not enabling them.

Now, I still don't understand why one would want to set the MAX_POS to 250 instead of 200 (maybe it is really for "manual" homing, where you travel far in X and Y, in which case Ian is correct, the firmware might stop the movement before the endstop is reached, but nobody really uses that anymore), but defining MANUAL_HOME_POSITIONS should make the new firmware work with "Solidoodle" values.

Adrian, if you have some time could you please check this, if it's not too much trouble? Thanks!

However, I suggest keeping our firmware as it is, with the correct limits, as I see no reason to change it.

Does MAX_POS override HOME_POS?  I thought the min and max served as software endstops.  When it hits an endstop switch during homing, it should set the coordinate for that position according to the HOME_POS value for that axis.  I would think that setting the MAX_POS higher would make sure that it doesn't stop before it gets to the endstop because it thinks it has already reached max.

The home command already travels to 1.5*MAX_POS, so if you are using the proper firmware homing, having underestimated values will not stop the axes before reaching the endstops. What I didn't get, are you only seeing the axes shifted in Repetier, or is the print shifted as well?

Does MAX_POS override HOME_POS?  I thought the min and max served as software endstops.  When it hits an endstop switch during homing, it should set the coordinate for that position according to the HOME_POS value for that axis.  I would think that setting the MAX_POS higher would make sure that it doesn't stop before it gets to the endstop because it thinks it has already reached max.

I saw the home pos redefined when using the straight SD3 mods as posted. X and Y were shifted.

Note, I did have this same config running using the solidoodle 644p but it didn't exhibit the above behaviour - so therefore this posted firmware is not identical to what shipped.

#define EXTRUDE_MINTEMP 120

This is probably to enable PLA extrusion at reasonable temperatures without the firmware complaining

#define X_MAX_POS 250
#define X_MIN_POS 0
#define Y_MAX_POS 250
#define Y_MIN_POS 0
#define Z_MAX_POS 250
#define Z_MIN_POS 0

#define X_HOME_POS 205
#define Y_HOME_POS 200
#define Z_HOME_POS 0

The maximum limits are set larger than the actual build area, probably to allow "manual homing" (ie move far in X and Y to actually go to home), but I don't think it makes any difference in practice.

I think we could also change the EXTRUDE_MINTEMP in our community firmware (also for SD2), but otherwise we should be good to go.

solidoodlesupport wrote:

I hope you realize this wasn't the intended firmware. We've made mistakes in the past, but we aren't that silly.

I've made the link reflect the correct firmware.

Thanks. We did realize it after the initial puzzlement, so I guess you were lucky that in the meantime nobody tried to flash their SD3 with the file you provided.

We are thanking our lucky stars

I hope you realize this wasn't the intended firmware. We've made mistakes in the past, but we aren't that silly.

I've made the link reflect the correct firmware.

Thanks. We did realize it after the initial puzzlement, so I guess you were lucky that in the meantime nobody tried to flash their SD3 with the file you provided.

Solidoodle has the official firmware for the SD3 available for download (http://www.solidoodle.com/how-to-2/how- … -firmware/). I had a look at it to see what makes it different from the very nicely updated SD2 firmware (from Lawsy) that most of us are using. This is what I found:

1) the firmware is based on a (relatively) ancient Marlin version from December 2011
2) The only changes are in configuration.h and pins.h, and most of these are in common with the "old" SD2 firmware that is also available for download on their webpage (but deprecated, as they suggest using Lawsy's firmware).
3) These are the only relevant changes that I found (with my annotations):

#define INVERT_Z_DIR true //was false
#define Z_HOME_DIR 1 // was -1

maybe these two settings null each other in the end... It seems strange to me that SD2 and SD3 have different designs in this respect

#define DEFAULT_AXIS_STEPS_PER_UNIT   {88,88,384,691} // was 88,88,2268,138 

This is the most puzzling change. The old SD2 code had the comment "Z 384 for Kysan Leas Screw Motor, 2560 for M8 Thread". So it seems to mean that the SD3 is using a Kysan Motor with a very different number of steps per revolution. And also the extruder motor seems to have 5x the steps per unit. But this is very inconsistent with the reports of people successfully using the current Marlin firmware with SD3, as such a miscalibration would have gigantic effects in the functionality of the machine.

There are also some temperature limits redefined, but nothing really impacting the functionality.

I don't have a SD3 to test any of these assumptions, so I would like some feedback from the community about their experience. Who is using the stock firmware with SD3? Who tried to upgrade? If you happen to own both a SD2 and a SD3, do you notice major differences in motors and other components (eg placement of the Z endstop...). The final goal would be to have a unified (and up-to-date) firmware for both machines, with all the newest mods and additions.

I'm working on it and I'm really one small step from completing it, but of course I need some insight on how SD3 works!

The good news is that if you are using the SD2 firmware on your SD3, and you don't notice any major problem, then you are probably fine since anything that could happen would be very well visible.

I hope you realize this wasn't the intended firmware. We've made mistakes in the past, but we aren't that silly.

I've made the link reflect the correct firmware.

I wish we didn't need to do their job... I'll post some comments on the code soon.

I can offer some insight to what ships on the SD3's - Judging by the Date Strings in the firmware, and the Github repository thats listed, it would seem my SD3 (Serial# 3018, Mid-Feb Ship date) had the previous 'most recent' lawsy firmware on it.

I've just pulled my 644p and replaced it with a 1284p using the latest (>24th Feb) firmware from Lawsy.
If anyone wants, I could pull a .hex dump from my 644p if needed (its now 'archived' in my IC's box...)

Ok good to know, thanks! The hex dump is not necessary, I hope they will fix their link and release their firmware soon (they have to according to GPL).