Version 2 Compilation Errors
I'm following the instructions from https://docfirmwarev2.repetier.com/ 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 https://docfirmwarev2.repetier.com/config/printer_type/ contains the following
Other 2 settings that are puzzling me are
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:
Thanks
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 https://docfirmwarev2.repetier.com/config/printer_type/ contains the following
#define NUM_AXES 5 // X,Y,Z and E for extruder A,B,C would be 5,6,7Why 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") }
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.
Thanks
Comments
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
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.
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:
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?
Thanks
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.
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!
// TOOL_EXTRUDER(name, offx, offy, offz, heater, stepper, resolution, yank, maxSpeed, acceleration, advance, startScript, endScript)
I managed to set this up correctly right before seeing your post. I changed the following 2 lines.
Thanks
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.
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 https://docfirmwarev2.repetier.com/config/bed_calibration under Standard Z-Probe section, but it did not help.
Any suggestions ?
Thanks
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?
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.
I executed G28 that properly homed all axes as per my settings
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.
Thanks
// Define ZProbe by referencing a endstop defined
CONFIG_VARIABLE_EQ(EndstopDriver, *ZProbe, &endstopZMin)
Thanks
#define ENDSTOP_Y_BACK_MOVE 3
#define ENDSTOP_Z_BACK_MOVE 3
#define ENDSTOP_A_BACK_MOVE 3
- 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:
I don't want to overload this thread with the content of my configuration files, so sharing them via Dropbox: https://www.dropbox.com/sh/eauiinu3uvew8yh/AABI34K00lxXXRYlbjJO8QOOa?dl=0
When I compile this configuration with FEATURE_Z_PROBE=0, I can see all end-stops in M119 printout
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.
Thanks
#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.
@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!
Thanks.
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
My current configuration files are available from Dropbox.
Thanks
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.
Thanks
Here is the table showing all heater and fan pin assignments for Ultratronics:
Thanks
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.
Thanks
// if (pos >= EEPROM::reservedEnd) {// eprSyncTime = 1UL; // enforce fast write to finish before power is lost
// } else {
eprSyncTime = HAL::timeInMilliseconds() | 1UL;
// }
Then got warnings:
Added parentheses
The same line also appears in HAL.h files located in SAMD51 and STM32S4 folders. Probably needs to be updated there as well.
Thanks
// as a solution you can use sd card. But this requires always
// the same sd card when powering up the printer
//#define EEPROM_AVAILABLE EEPROM_NONE
#define EEPROM_AVAILABLE EEPROM_SDCARD
//#define EEPROM_AVAILABLE EEPROM_SDCARD
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.
Thanks
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:
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 ~~~Thanks!