Dual head firmware sources / endstop issue

Discussions about firmware/slicing software, tweaks and settings
Post Reply
scp
Posts: 19
Joined: Mon Dec 30, 2013 1:02 am

Dual head firmware sources / endstop issue

Post by scp »

I got my Felix dual 3.0 kit on Tuesday and after assembling the printer did a very nice job even on the very first test print. It has behaved fine during it's first 10 hours of operation besides some small issues.

However, when playing in the manual mode and later on with Octoprint on RasPi I ran into some trouble: Even after homeing, all three axes can be sent beyond the physical dimensions and the calculation of the current position does not take the limits into account. This effect will only show up on manual operation and using relative positioning commands (e.g. manual operation via Octoprint)

I'm referring to Guilleaume's version "20140106 - FIRMWARE - Repetier 0.91 - FELIX_3_0_DUAL extrusion", the current one as of today.

First: The settings for the Min-Endstops in Configuration.h must be activated

Code: Select all

#define min_software_endstop_x true
#define min_software_endstop_y true
#define min_software_endstop_z true
otherwise there is no check whether the positions go below zero. The physical endstops are only used for homeing; the ALWAYS_CHECK_ENDSTOPS is deactivated (on purpose IMHO).

Ok, after changing the above I still had the problem that X-Axis and the Z-Axis went beyond their physical dimensions; Y-Axis was fine. I found that the values for X-Axis and Z-Axis are too high; I changed them to

Code: Select all

#define X_MAX_LENGTH 250
#define Y_MAX_LENGTH 205
#define Z_MAX_LENGTH 215
Caution: even after changing the values in the Firmware you must adjust the EEPROM values on your machine, too. They will not be overwritten by default.

After that, the major issue was resolved; the axes did no longer hit their mechanical ends (after homeing). However, the calculation of the current postion is not taking that into account and loses track after exceeding the physical dimensions.

I found that the calculation in the call of PrintLine::queueCartesianMove implicitly limits the movement to the physical dimensions and that almost always after that command the correction (that possibly has occurred) is taken into account by calling Printer::updateCurrentPosition(). But there are two sections where this is missing:

Commands.cpp: in void Commands::executeGCode

Code: Select all

        case 0: // G0 -> G1
        case 1: // G1
            if(Printer::setDestinationStepsFromGCode(com)) // For X Y Z E F
#if NONLINEAR_SYSTEM
                PrintLine::queueDeltaMove(ALWAYS_CHECK_ENDSTOPS, true, true);
#else
                PrintLine::queueCartesianMove(ALWAYS_CHECK_ENDSTOPS,true);
#endif
                Printer::updateCurrentPosition();
            break;
and in Printer.cpp in the function Printer::moveToReal

Code: Select all

#if NONLINEAR_SYSTEM
    PrintLine::queueDeltaMove(ALWAYS_CHECK_ENDSTOPS, true, true);
#else
    PrintLine::queueCartesianMove(ALWAYS_CHECK_ENDSTOPS,true);
#endif
    Printer::updateCurrentPosition();
}
As a last fix I have changed in ui.cpp the fill character from 0 (zero) to '0' ASCII-Character Zero.

Code: Select all

                tmp = seconds/60;
                addInt(tmp,2,0);
                addStringP(PSTR(UI_TEXT_PRINTTIME_MINUTES));
to

Code: Select all

                tmp = seconds/60;
                addInt(tmp,2,'0');
                addStringP(PSTR(UI_TEXT_PRINTTIME_MINUTES));
This will fix the panel display that is showing the totally elapsed printing time of the machine to correctly show the minute values between "00" and "09".

Maybe someone of you has seen the same issues and can crosscheck the fixes.

Regards,
Paul

andrewsi
Posts: 130
Joined: Mon Dec 23, 2013 1:26 am

Post by andrewsi »

Since the firmware is actually Repetiers', I'd suggest contributing these to the active development project on Github so they can integrate the fixes back into the main source tree.
__________________________________________
Andy Silverman, Technogeek in Seattle
Felix Tec4 Single-head

scp
Posts: 19
Joined: Mon Dec 30, 2013 1:02 am

Post by scp »

andrewsi wrote:Since the firmware is actually Repetiers', I'd suggest contributing these to the active development project on Github so they can integrate the fixes back into the main source tree.
I agree with you and I will do that, later. However, the software_endstop configuration and the MAX_LENGTH values are Felix-related.

Paul

Post Reply

Return to “Software/Firmware”