Version 2 Compilation Errors

I'm following the instructions from and trying to compile firmware version 2 (the very 1st time). I am getting errors that are most likely caused by incorrect settings in my Configuration file. I'd appreciate any help/guidance.

My IDEX printer has two X motors, one Y motor, two Z motors and 2 extruder motors. So, 7 motors in total. Each motor is connected to its own driver on Ultratronics Pro board. 'Dual X Axis Printer' configuration sample published here contains the following
#define NUM_AXES 5                   // X,Y,Z and E for extruder A,B,C would be 5,6,7
Why this example contains 5 axes? Dual X printer should have at least two X, one Y, one Z and 2 extruder motors. So, the number should be 6 or higher. If not, than what is the meaning of AXES in this context?

Other 2 settings that are puzzling me are
#define MOTORS \
    { &XMotor, &YMotor, &ZMotor, &AL1Motor, &AL2Motor }
#define MOTOR_NAMES \
    { PSTR("X"), PSTR("Y"), PSTR("Z"), PSTR("Adj. 1"), PSTR("Adj. 2") }
I tried to replace the last 2 entries in each of these lines with with A, B, C and D, but getting several errors like this:
src\motion/MotionLevel3.h:113:9: error: 'AMotor' was not declared in this scope

Prior to this I was getting several Servo related errors, nevertheless I defined NUM_SERVOS as 0. 

Here are couple of them:

src/Configuration_io.h: In constructor 'Servo1Class::Servo1Class()':
src\io/io_servos.h:36:18: error: 'servoMicroseconds' is not a member of 'HAL'
             HAL::servoMicroseconds(slot, neutral, 1000); \
src/Configuration_io.h:179:1: note: in expansion of macro 'SERVO_ANALOG'
 SERVO_ANALOG(Servo1, 0, Servo1Pin, 500, 2500, 1050)

I was able to get rid of these errors by commenting out the line 

// SERVO_ANALOG(Servo1, 0, Servo1Pin, 500, 2500, 1050)
from Configuration_io.h file, but I don't know if this is good workaround.




  • Hope you are refering to Stacker X2 config for IDEX. That is my idex I run with V2 and it's configuration that works fine.

    5 Axis are X, Y, Z, E and A - A axis is second X axis but works independent. The 2 extruders share E axis with the active one being inserted as E stepper.

    You sample seems from Felix Pro 1 which has 2 extra steppers to physically level bed AL1Motor and AL2Motor belong to that. You do not have them. In your case it looks more like

    #define NUM_MOTORS 6
    #define MOTORS \
        { &XMotor, &YMotor, &ZMotor, &AMotor, &E1Motor, &E2Motor }
    #define MOTOR_NAMES \
        { PSTR("X left"), PSTR("Y"), PSTR("Z"), PSTR("X right"), PSTR("E0"), PSTR("E1") }

    You also need to add A motor for send x axis like done in stacker X2 sample.
    As said better take that as preset as it is same printer type and default at least compiles for stacker board. You need to set it of yourse to ultratronics and maybe change some pin numbers and heaters - they are quite unusual.
  • Repetier Thanks for the hint! I started from stacker X2 sample and spent almost whole day setting up version 2 on my IDEX. I made good progress, but to-do list is still pretty long. I documented all problems I faced and how I addressed them. I'm planning to make a separate post here describing this. Hopefully it will save others time and help developers to understand what is regular user's experience when upgrading from version 1 to version 2.

    While most of the issues were caused by incorrectly settings in header files, I experienced one error that I am pasting below. Not sure what is causing it. I temporarily commented out BEEPER_PIN and moved on, but would be good to know what is causing this:

    src\PrinterTypes\Printer.cpp:94:10: error: 'TonePacket' in 'class Printer' does not name a type
     Printer::TonePacket toneQueueBuf[Printer::toneBufSize];
    src\PrinterTypes\Printer.cpp: In static member function 'static void Printer::addToToneQueue(TonePacket)':
    src\PrinterTypes\Printer.cpp:1494:5: error: 'toneQueueBuf' was not declared in this scope
           toneQueueBuf[seekToneIndex] = packet;
    src\PrinterTypes\Printer.cpp: In static member function 'static void Printer::processToneQueue()':
    src\PrinterTypes\Printer.cpp:1509:41: error: 'toneQueueBuf' was not declared in this scope
           if ((curTime - lastToneTime) >= toneQueueBuf[curToneIndex].duration) {
          *** [.pio\build\due\src\PrinterTypes\Printer.cpp.o] Error 1
    Apart from this I have 2 questions: 

    - In version 1 I was able to have 2 Z-motors connected to separate stepper drivers. They were moving in sync. How can I replicate such setup in version 2? My 2nd Z-motor is connected to Extruder 2 slot.

    - Configuration file contains several references to TMC drivers which I don't have (yet). Is there any particular place where I need to disable them in configuration files?


  • Tone problem was a bug I fixed and thought I had uploaded. Have now updated github with proper fix.

    You define 3 motors for Z. Z1Motor and Z2Motor are regular motor drivers for Z and E2 axis. The third one is a mirror motor driver:
    STEPPER_MIRROR2(ZMotor, Z1Motor, Z2Motor, endstopNone, endstopNone);

    Use everywhere ZMotor - it send identical signals to Z1Motor and Z2Motor. Same if you need 3 or 4 motors or for any other axis.

    TMC nothing to disable. If they get not configured they are not used. The advantage of the module concept that it only includes used modules.

  • Thanks, this worked. 
    I was making really good progress until I stumbled on the extruder motor step per mm setting, or rather lack of it. I need to reduce current value 2.66 times. Tried to define EXT0_STEPS_PER_MM  and EXT1_STEPS_PER_MM  values but that had no effect. I cannot find anything about this in documentation and other sample configs. Could you please advice where/how to set extruder steps ?

    Thanks again!
  • edited December 2019
    you have to adjust it in configuration_io.h , extruder is handled as tool

    search for TOOL_EXTRUDER

    // TOOL_EXTRUDER(name, offx, offy, offz, heater, stepper, resolution, yank, maxSpeed, acceleration, advance, startScript, endScript)

    (resolution is the steps/mm value)

    also refer to documentation :

  • RAyWB Thanks for your reply. I was searching documentation under steppers section...
    I managed to set this up correctly right before seeing your post. I changed the following 2 lines. 
    TOOL_EXTRUDER(ToolExtruder1, 0, 0, 0, HeaterExtruder1, E1Motor, 1.75, 140, 5, 30, 5000, 177, "M117 Extruder 1", "", &Fan1PWM)
    TOOL_EXTRUDER(ToolExtruder2, 0, 0.1, 0, HeaterExtruder2, E2Motor, 1.75, 140, 5, 30, 5000, 177, "M117 Extruder 2", "", &Fan2PWM)
    Sample configuration that I used had 500 where I now have 140.

  • Updated Printer.cpp file to the latest revision. This cleared Beeper related compilation errors and Beeper is working now. Thanks to @Repetier

    Made the 1st successful test cube print after manually leveling the bed.

    Now, trying to configure ABL. With the following settings Print-head moves to the position of the first measurement, then the board resets itself.
    #define Z_PROBE_TYPE 1               // 0 means no ABL 
    #define Z_PROBE_HEIGHT 4.5           // Distance bed-nozzle when trigger switches
    #define Z_PROBE_BED_DISTANCE 5.0     // Optimal starting distance
    #define Z_PROBE_SPEED 5              // Speed for z testing
    #define Z_PROBE_X_OFFSET 26.5        // x offset relative to extruder 0,0 offset
    #define Z_PROBE_Y_OFFSET 18          // y offset relative to extruder 0,0 offset
    #define Z_PROBE_COATING 0            // Coating thickness if not detected by probe
    #define Z_PROBE_DELAY 0              // Extra delay before starting again. Only needed on electronic probes keeping state for a while
    #define Z_PROBE_REPETITIONS 2        // How often should we probe, 1 is minimum
    #define Z_PROBE_USE_MEDIAN 0         // 0 = use average, 1 = use middle value after ordering z
    #define Z_PROBE_SWITCHING_DISTANCE 1.5 // Minimum distance required to safely untrigger probe - used for faster repeated measurement
    #define Z_PROBE_BORDER 10            // Safety border to ensure position is allowed
    #define Z_PROBE_START_SCRIPT ""
    #define LEVELING_METHOD 1
    #define GRID_SIZE 5
    #define ENABLE_BUMP_CORRECTION 0          // CPU intensive, so only activate if required
    #define BUMP_CORRECTION_START_DEGRADE 0.5 // Until this height we correct 100%
    #define BUMP_CORRECTION_END_HEIGHT 2      // From this height on we do no correction
    #define BUMP_LIMIT_TO 2                   // Maximum allowed correction up/down
    Log output of G32 command shows this:
    ok 0
    Info:Autoleveling disabled
    X:-54.00 Y:343.00 Z:150.000 E:0.0000 A:406.00
    endstops hit: x_min:L y_max:L z_max:H a_max:H
    Warning:Endstop for axis 4 did not untrigger for retest!
    X:-54.00 Y:343.00 Z:150.000 E:0.0000 A:406.00
    Info:Watchdog Reset
    Free RAM:76512
    Card successfully initialized.
    EEPROM read from sd card.
    ok 0

    Looks like I am missing something related to z-probe sensor/Endstop settings. As you can see I tried to add 


    to Configuration.h file, nevertheless it was not present here under Standard Z-Probe section, but it did not help.  

    Any suggestions ?


    is not needed any more in V2. Configuration should be complete since it compiled.
    I see you did not move A axis far enough back in homing sequence hence the untrigger warning.
    What happened afterwards until watchdog reset happened?
    What is your stepper frequency set?
    #define STEPPER_FREQUENCY 120000

    When I had this higher on 153000 watchdog reset happened also sometimes on longer z moves due to cpu load > 100% leaving no time for main thread. That might have happened here.
  • edited December 2019
    Stepper frequency is 120000. 
    I executed G28 that properly homed all axes as per my settings 
    #define X_HOME_PRIORITY 2
    #define Y_HOME_PRIORITY 1
    #define Z_HOME_PRIORITY 0
    #define A_HOME_PRIORITY 2
    First was Z to Zmax, then Y to Ymax, then X to Xmin and finally A to Xmax.

    Then I executed G32. It repeated homing moves and then started to simultaneously slowly move bed up and left print-head with probe towards (I think) X=Z_PROBE_BORDER Y=Z_PROBE_BORDER. After reaching that point print-head made quick diagonal move to what looked like X=0 Y=0 and then couple of seconds later firmware restarted.

    Sorry, I cannot understand, if we do not specify Z-probe pin, how can it even make the measurements? My probe is connected to Zmin endstop plug of mainboard and that's how it was configured in version 1 and worked fine. All my endstops and probe are schematically identical. They contain optocouple ITR9606-F and 2 resistors. 


  • edited December 2019
    Forgot to mention - right now I don't have Zmin endstop defined in configuration. Do I need to add it for z-probe?
  • from my setup

    configuration_io.h :

    ENDSTOP_SWITCH_HW(endstopZMin, IOEndstopZMin, Z_AXIS, false)

    has to be defined  and  in  configuration.h

    there should be

    // Define ZProbe by referencing a endstop defined
    CONFIG_VARIABLE_EQ(EndstopDriver, *ZProbe, &endstopZMin)

    in my setup i have home at z-max and probe at z-min input

    difference i have is in home priority for a-axis , but i have a real 4th rotational axis in my setup as mill
    #define X_HOME_PRIORITY 2
    #define Y_HOME_PRIORITY 1
    #define Z_HOME_PRIORITY 0
    #define A_HOME_PRIORITY 3

  • @RAyWB Gave it a quick try before going to work, but there was no change in behavior. Zmin did not appear in M119 output. Will continue looking into it this evening.

  • edited December 2019
    from your log before :
    endstops hit: x_min:L y_max:L z_max:H a_max:H
    seems that z endstop and a endstop don´t untrigger, so check that values( in configuration.h):

    #define ENDSTOP_X_BACK_MOVE 3
    #define ENDSTOP_Y_BACK_MOVE 3
    #define ENDSTOP_Z_BACK_MOVE 3
    #define ENDSTOP_A_BACK_MOVE 3

    may be you can share your configuration.h and configuratio_io.h

  • I currently work on rumba32 support (ST32 based board) which I want to put into my now non working delta. When done I will also test z probing which will be similar to your case with z max homing. Then I will see if there are problems. Currently I only have one "special" printer with zprobe using the 4 point z probe which worked. But might take some days for me to test this since the hardware layer is making troubles.
  • Here is the latest status:

    - Discovered and fixed half-broken wire going to Endstop-A. Now A-stop works reliably.
    - Made few changes to configuration files: 
       - Commented out #define NO_AMAX_ENDSTOP_TEST
       - Replaced #define ZPROBE_ADDRESS nullptr with #define ZPROBE_ADDRESS &endstopZMin
       - Set FEATURE_Z_PROBE to 1 (it was 0 before) 
    These changes caused several compilation errors. The 1st was saying that NUM_EXTRUDER is not defined. I already had line #define NUM_TOOLS 2. It appears that is not sufficient. Added #define NUM_EXTRUDER 2 to Configuration.h file. This took care of the 1st error, but the following errors remain:
    src\communication\GCodes.cpp: In function 'void GCode_134(GCode*)':
    src\communication\GCodes.cpp:725:25: error: 'Extruder' has not been declared
         int startExtruder = Extruder::current->id;
    src\communication\GCodes.cpp:726:5: error: 'extruder' was not declared in this scope
         extruder[p].zOffset = 0;
    src\communication\GCodes.cpp:726:5: note: suggested alternative: 'BitOrder'
         extruder[p].zOffset = 0;
    src\communication\GCodes.cpp:759:14: error: 'startProbing' is not a member of 'Printer'
    src\communication\GCodes.cpp:761:9: error: 'Extruder' has not been declared
    src\communication\GCodes.cpp:762:36: error: 'runZProbe' is not a member of 'Printer'
             float refHeight = Printer::runZProbe(false, false);
    src\communication\GCodes.cpp:773:13: error: 'Extruder' has not been declared
    src\communication\GCodes.cpp:774:37: error: 'runZProbe' is not a member of 'Printer'
                 float height = Printer::runZProbe(false, false);
    src\communication\GCodes.cpp:806:5: error: 'Extruder' has not been declared
    src\communication\GCodes.cpp:807:14: error: 'finishProbing' is not a member of 'Printer'
    src\communication\MCodes.cpp: In function 'void MCode_890(GCode*)':
    src\communication\MCodes.cpp:1376:28: error: 'bendingCorrectionAt' is not a member of 'Printer'
             float c = Printer::bendingCorrectionAt(com->X, com->Y);
    *** [.pio\build\due\src\communication\GCodes.cpp.o] Error 1
    I don't want to overload this thread with the content of my configuration files, so sharing them via Dropbox:

    When I compile this configuration with FEATURE_Z_PROBE=0, I can see all end-stops in M119 printout
    endstops hit: x_min:L y_max:L z_min:H z_max:L a_max:L Z-probe state:H
    but z_min and Z-probe states do not change.

    Reverted firmware back to version 1 to compare behavior - z_min and Z-probe end-stop states did change. So, this is not a wiring issue at this time.
    endstops hit: x_min:L x_max:L y_max:L z_max:L Z-probe state:L

  • Just a separate note: I started new thread that contains my printer's specifications. I am planning to share there detailed description of my experience upgrading from version 1 to version 2. 
  • as i´m busy for the next 2days i´ll try your config on january 2nd.
    best wishes for 2020 !

  • NUM_EXTRUDERS is what was used in V1. Making the firmware more flexible this has become NUM_TOOLS since it could also be laser or spindle or syringe in future. With your FEATURE_Z_PROBE definition you triggered old codeparts that have not been converted yet. Do not add that define - it is not used in V2 parts. Z Probe is define only by

    #define Z_PROBE_TYPE 2               // 0 = no z probe, 1 = default z probe, 2 = Nozzle as probe

    which tells which variant it is. Next type will be 3 = BLtouch which is what I want to add to the delta I'm working on.
    Without FEATURE_Z_PROBE it will only the V2 zprobe parts that are already converted. But as said I need some more days to convert printer so I can also test that variant and then hopefully get the same problem to fix it. If not I can at least post my settings that work.

    Also big thanks for the testing of V2. It helps testing with different variants which is the main problem in development. Parts I use for my test printers work pretty well so far, but I know there are many other combinations and these can trigger unknown problems, als I hope they are all quite easy to solve since most things are already functional and some already better then in V1.
  • @RAyWB  Thanks a lot!

    @Repetier That's good to know. I will remove NUM_EXTRUDER, revert FEATURE_Z_PROBE to 0 and continue "playing" with other settings. I will be posting everything I am doing in another thread. Meanwhile

    HAPPY NEW YEAR TO EVERYONE!! Very best wishes from Seattle! 

  • edited January 2020
    I am putting upgrade on hold for about 10 days. My temporary wire connections to print-heads are giving me troubles.  Designed custom connector PCB and ordered it from EasyEDA. It should arrive within a week. I will post update once I am ready to resume the upgrade.

  • edited January 2020
    Wiring issues have been taken care of and I resumed my attempts to configure version 2.

    I am still having troubles with Z-probe that is connected as Z-min endstop. My bed moves along Z axis. Z-min is at the top and Z-max - at the bottom.  Z-homing happens towards Z-max.
    All my endstops including Z-probe are optical; when covered the output is High, when open - Low. During Z-probing initial output of Z-probe is Low and when Z-probe pin touches the bed it changes to High. 
    This video shows probing process on my printer running older version of Repetier firmware. The video was recorded few months ago to demonstrate another issue; please ignore the fact that bed movements are inconsistent.

    I am testing Z-probe by manually lifting and releasing the pin. When I connect to the board with Pronterface while Z-probe pin is lowered, i.e. optical sensor is not covered and the output signal is Low, I get correct reading. Then when I lift the pin - the signal changes to High. All good until now. But if I then release the pin, the signal does not return to Low and stays in High. If I connect to the printer while the pin is lifted and output is High, it does not switch to Low after releasing the pin. Looks like one way trigger - only can switch from Low to High but never back. 

    Here is M119 printout with Z-probe Low output
    ok 0
    endstops hit: x_min:L y_max:L z_min:L z_max:L a_max:L Z-probe state:L
    and here is with High
    ok 0
    endstops hit: x_min:L y_max:L z_min:H z_max:L a_max:L Z-probe state:H
    I think this is either configuration issue or a bug, because as soon as I rollback to dev. version 1 firmware - this issue is gone and Z-probe works as it should.

    My current configuration files are available from Dropbox

  • edited January 2020
    Finally, my Z-probe works!!  :) The sensor that it used was taken from my old printer and contained a resistor for 12V supply. Ultratronics board feeds endstops with 3.3V and the resistor value was too big causing incorrect readings. 

    My first attempt to run G32 succeeded with few unexpected pauses along the way. I will fine tune settings, collect more data and report results.

  • Great. I'm also nearly finished with my delta. Board is connected and mostly working. Just endstop is not recogniced:-) Will see what I get when it gets detected correctly. Had it working before it connected to printer.

  • edited January 2020
    @Repetier Please update HEATER_3_PIN definition in src/Repetier/src/boards/due/boards/ultratronics.h file. It has value '6' and should be '7'. Pin '6' is also assigned to ORIG_FAN_PIN, which is correct.

    Here is the table showing all heater and fan pin assignments for Ultratronics:
    Pin     Definition     .h file
    D2      Heated bed    HEATER_1_PIN
    D3      Extruder 0     HEATER_0_PIN D5 Fan 2 ORIG_FAN2_PIN D6 Fan 1 ORIG_FAN_PIN
    D7      Extruder 2     HEATER_3_PIN
    D8      Extruder 1     HEATER_2_PIN
    D9      Extruder 3     HEATER_4_PIN


  • Since I spent last 2 weeks troubleshooting hardware issues, I decided to download the fresh copy of ver 2. from, Github. Compiled it as-is and did not get any errors or warnings. Then I started to make changes in configuration files - one change at a time. After setting motherboard type to 409 Ultratronics, and setting FEATURE_CONTROLLER to NO_CONTROLLER, since I don't have LCD, I am getting the following compilation errors:
    In file included from src\boards/pins.h:107:0,
                     from src\Configuration.h:155,
                     from src\Repetier.h:207,
                     from src\Configuration.cpp:29:
    src\boards/due/HAL.h: In static member function 'static void HAL::eprBurnValue(unsigned int, int, eeval_t)':
    src\boards/due/HAL.h:534:20: error: 'EEPROM' has not been declared
             if (pos >= EEPROM::reservedEnd) {
    In file included from src/boards/pins.h:107:0,
                     from src/Configuration.h:155,
                     from src/Repetier.h:207,
                     from src\PrinterTypes\Printer.cpp:19:
    src/boards/due/HAL.h: In static member function 'static void HAL::eprBurnValue(unsigned int, int, eeval_t)':
    src/boards/due/HAL.h:534:20: error: 'EEPROM' has not been declared
             if (pos >= EEPROM::reservedEnd) {
    In file included from src/boards/pins.h:107:0,
                     from src/Configuration.h:155,
                     from src/Repetier.h:207,
                     from src\PrinterTypes\PrinterTypeCartesian.cpp:19:
    src/boards/due/HAL.h: In static member function 'static void HAL::eprBurnValue(unsigned int, int, eeval_t)':
    src/boards/due/HAL.h:534:20: error: 'EEPROM' has not been declared
             if (pos >= EEPROM::reservedEnd) {
    In file included from src/boards/pins.h:107:0,
                     from src/Configuration.h:155,
                     from src/Repetier.h:207,
                     from src\PrinterTypes\PrinterTypeCoreXYZ.cpp:19:
    src/boards/due/HAL.h: In static member function 'static void HAL::eprBurnValue(unsigned int, int, eeval_t)':
    src/boards/due/HAL.h:534:20: error: 'EEPROM' has not been declared
             if (pos >= EEPROM::reservedEnd) {
    *** [.pio\build\due\src\Configuration.cpp.o] Error 1
    *** [.pio\build\due\src\PrinterTypes\PrinterTypeCoreXYZ.cpp.o] Error 1
    *** [.pio\build\due\src\PrinterTypes\Printer.cpp.o] Error 1
    *** [.pio\build\due\src\PrinterTypes\PrinterTypeCartesian.cpp.o] Error 1
    I compared HAL.h files for due and avr boards, but they are so different that I decided to report the issue rather than troubleshoot myself. Also, just as a note - I did not have such compilation errors with the snapshot downloaded on December 28th.

  • Got rid of above error by temporarily commenting out the following lines in due/HAL.h file
       //     if (pos >= EEPROM::reservedEnd) {
       //         eprSyncTime = 1UL; // enforce fast write to finish before power is lost
       //     } else {
                eprSyncTime = HAL::timeInMilliseconds() | 1UL;
       //     }

    Then got warnings:

    src\boards\due\HAL.cpp:532:71: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
             if (!failed && !eepromFile.write(virtualEeprom, EEPROM_BYTES) == EEPROM_BYTES)
    src\boards\due\HAL.cpp:532:24: note: add parentheses around left hand side expression to silence this warning
             if (!failed && !eepromFile.write(virtualEeprom, EEPROM_BYTES) == EEPROM_BYTES)
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Compiling .pio\build\due\src\communication\GCodes.cpp.o
    ~~~~Compiling .pio\build\due\src\communication\MCodes.cpp.o
                            (                                             )
    src\boards\due\HAL.cpp:532:71: warning: comparison of constant '4096' with boolean expression is always false [-Wbool-compare]
             if (!failed && !eepromFile.write(virtualEeprom, EEPROM_BYTES) == EEPROM_BYTES)

    Added parentheses 

    if (!failed && !(eepromFile.write(virtualEeprom, EEPROM_BYTES) == EEPROM_BYTES))
                failed = true;

    The same line also appears in HAL.h files located in SAMD51 and STM32S4 folders. Probably needs to be updated there as well.


  • Go to due/boards/ultratronics.h  line 131

    // Ultronics has no eeprom for storing changeable data
    // as a solution you can use sd card. But this requires always
    // the same sd card when powering up the printer

    try to change comments to


    that should do the trick.

    Reason : no controller also means no sd support and also no eeprom_sdcard  i guess thats why you get errors
  • @RAyWB I restored commented out lines in HAL.h file (see my previous post) and followed your suggestion. It terms of the results I don't see any difference. When EEPROM is disabled I am getting 
    #warning HOST_RESCUE requires eeprom support! Disabling feature. [-Wcpp]
    message, but that's OK for now.

    I moved a bit further - configured X, Y and Z lengths and other IDEX specific settings. I can switch tools and newly selected tool is correctly positioned at the same place as the previous tool.

    My current problem is still Z-probing.  I am trying to measure 5x5 grid with G32. The border is set to 5mm. The measurement starts as it should, but instead of 5x5 grid evenly distributed between Xmin+5, Ymin+5 and Xmax-5, Ymax-5 printer makes 4 measurements per row. After measuring several points it pauses, then continues. Eventually it stops and pushes bed up into the nozzle. At that moment I just pull out the power to protect printer from damage. 

    I have few projects on hold due to this firmware upgrade. Since this is taking much longer than I expected, I will temporarily rollback to version 1, work on other things and try again later.


  • Have just uploaded the fixed firmware. Should now compile also with eeprom sd card. Needed to move function to cpp file so eeprom definition was known.
  • edited January 2020
    @Repetier  Thanks for the fix. I was able to compile the code with enabled EEPROM and did not get the errors I had before. 
    There are still few warning messages, the 1st of which with missing parentheses may affect the functionality. I applied the same fix as mentioned in my earlier post, and I hope this was the way it is intended to work:
    if (!failed && !(eepromFile.write(virtualEeprom, EEPROM_BYTES) == EEPROM_BYTES))
                failed = true;
    Other warnings are listed below:
    In file included from C:\users\boris\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.cpp:25:0:
    C:\users\boris\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.h: In constructor 'TwoWire::TwoWire(Twi*, void (*)(), void (*)())':
    C:\users\boris\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.h:96:7: warning: 'TwoWire::twi' will be initialized after [-Wreorder]
      Twi *twi;
    C:\users\boris\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.h:72:10: warning:   'uint8_t TwoWire::rxBufferIndex' [-Wreorder]
      uint8_t rxBufferIndex;
    Compiling .pio\build\due\lib047\TMCStepper\source\CHOPCONF.cpp.o
    C:\users\boris\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.cpp:95:1: warning:   when initialized here [-Wreorder]
    Archiving .pio\build\due\lib458\libSPI.a
     TwoWire::TwoWire(Twi *_twi, void(*_beginCb)(void), void(*_endCb)(void)) :
    Archiving .pio\build\due\liba37\libWire.a
    Compiling .pio\build\due\lib047\TMCStepper\source\COOLCONF.cpp.o
    In file included from C:\users\boris\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.cpp:25:0:
    Compiling .pio\build\due\lib047\TMCStepper\source\DRVCONF.cpp.o
    C:\users\boris\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.h:108:16: warning: 'TwoWire::status' will be initialized after [-Wreorder]
      TwoWireStatus status;
    C:\users\boris\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.h:90:30: warning:   'void (* TwoWire::onBeginCallback)()' [-Wreorder]
      void (*onBeginCallback)(void);
    C:\users\boris\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.cpp:95:1: warning:   when initialized here [-Wreorder]
     TwoWire::TwoWire(Twi *_twi, void(*_beginCb)(void), void(*_endCb)(void)) :
    ^~~~Compiling .pio\build\due\lib047\TMCStepper\source\DRVCTRL.cpp.o
Sign In or Register to comment.