I managed to adjust the speeds by putting the standard ones, I had a moment of panic but now everything is ok. Regarding the calibration I proceeded to recalibrate mechanically and it has improved, now I will take back the tool you passed me and I will also recalibrate from there. I've always used this:
Do you have configured a mixing extruder? That is if you mix 2 incoming filaments with some ratio. Default is 50% each. That would be wrong in your case as I understood you. You need to selected shared heater and assign both the same thermistor.
Not sure how the old firmware did handle the problem that only one filament can be loaded. You can have scripts on extruder select and deselect or just keep it in sync on your own and with good slicer scripts.
I proceeded to recalibrate the printer again and the best result I got at the moment is this. For the 3d map I put an initial Z of 5mm starting from X0 Y0. Here it is.
mechanical calibration and Eschel3D:
Without G32 S2, only mechanical and Eshel3D:
with G32 S2
Advice? Not print yet, G33 S2 crashes and dont know why.
EDIT
Despite the calibration below 0.1 and the auto level g32 S2 the nozzle touches the bed halfway..
I tried to print by deleting the G32 with M322 S2 but the result is the same. Is it possible that the self-calibration does not activate?
What is your z probe bed distance? If leveling touches bed it is normally to small so the bed rotation causes it to touch. G33 also uses this distance. WHat does crash mean here? Just scratch or totally wrong move deep inside the bed without any messages? Make sure that the area is not too large where you test. It will otherwise cause problems with illegal moves.
I wonder what the calibration tool changed? Output values are the same as initial values if I see it correctly.
-3° is a big error for a tower position. Also you see in height map that the neutral height has 3 parts which is typical for angle errors. Each tower ha sit's main zone of influence.
The distance of the probe from the bed is 5mm, I noticed that with each different height (5mm, 10mm and 20mm) the probe changes result. The distance from the bed is 5mm and the activation of the probe is 3mm. Unfortunately regarding G33 S2 once it reaches and probes the angle of Y in going back to probe the other end it stops and gives a generic error asking to send M999.
G32 S2 works great and doesn't crash and that's what I don't understand, it has the same 90x90 measures. Before having calibrated with Esher 3D G33 S2 it was fine without crashing. I will try to improve the result.
Please try 1.0.5dev version - you can use same config. There was a bug that every probe did not go back exactly to start position. You never said how big your G33 grid is but if you have many measures and the bug is in 1.0.4 (don't know when I fixed it) that could be part of the problem. Also what is the message you get? M999 means there was a fatal error you need to fix before anything works. This is to protect printer and when you see it firmware detected a problem.
The problem was the calibrations made with eshel3d, for some reason they gave me problems with G33. Regarding the bug I hope but by reversing the position of the probe the differences in the bed have been reversed. I have an offset of X20 Y15 and therefore I assume that the probe experiences the tilt of the platform at the ends of the bed.
I will try to build a probe housing in the center under the nozzle to see if the theory is correct.
At the moment I have printed without autocalibration, only mechanically and it prints regularly. Only with an offset I have to figure out where it comes from.
About the probe everything is ok, it was my oversight and it gives me relief as a thing. About the bug I do not think because I have a tolerance under +/- 0.04. in the end, even with a calibration point close to 0 with the degrees of the towers the result does not change. There will be a way to understand
Good to see it is working again. The G33 L0 shows it is cleared. If you need a correction at some point just send the returned command G33 X90.00 Y45.00 Z0.000
with the z correction you want there. That way you can optimize probelmatic zones a bit.
Absolutely yes! Regarding the motors, I don't know if I can ask here, having a 1.3L rambo I have to reduce the noise (which is high) and I must necessarily act on the firmware since it has digital potentiometers, I am identifying the string:
This thread got hijacked by an unrelated issue, but I wanted to provide update on my progress.
I tried using the "Trash80_IIS2DH" library, but ran into issues.
I went back and ported out the original code from the SeeMeCNC 0.92.2 port of Repetier, and added the accelerometer functionality into Repetier 1.0.4. I have included a configuration.h file for my SeeMeCNC Rostock Max V2 (which is upgraded with the V2->V3 kit and HE280 hot end). I have also rewired the hot end and layer cooling fans to the RAMBO directly (so that the fan can get properly controlled by the firmware). I wired the IIS2DH accelerometer chip trigger line to the Z-MIN endswitch input on the RAMBO (this accelerometer is used to sense when the nozzle hits the bed, and then an output line is toggled high).
I have checked that G30, G31, and G32 work well on my printer. G29 doesn't seem to work correctly, but I'm not using it anyways.
I added a new GCode command (sorry!), G35, that forces initialization of the accelerometer and clear the output trigger line. This sets the Z-probe endstop line low, and allows testing that it's working by calling G31. By calling G35, then G31, the Z-probe should report low. Then lightly tapping the nozzle upwards and calling G31 again shows Z-probe is high.
I added a configuration value for indicating that the z-probe uses this I2C accelerometer: Z_PROBE_IIS2DH. When this value is 1, then the accelerometer specific code is enabled.
I also included the accelerometer sensitivity threshold value, and used the default value from SeeMeCNC: Z_PROBE_SENSITIVITY
#define Z_PROBE_SENSITIVITY 20 // 0-126 7 bit value. Value for (Z_PROBE_SPEED 60) with glass bed
I renamed the constant:
PRINTER_FLAG0_ZPROBEING to PRINTER_FLAG0_ZPROBING (because that's the correct spelling).
It's not necessary to disable the probe afterwards.
I did modify setZProbingActive, but I also needed to add in some configuration code steps, as well as some checks that the I2C chip has been reset correctly in a few locations.
There is actually a very easy solution and place. Before probe move and afterwards the same function is called:
static INLINE void setZProbingActive(bool on) {
flag0 = (on ? flag0 | PRINTER_FLAG0_ZPROBEING
: flag0 & ~PRINTER_FLAG0_ZPROBEING);
} in printer.h
With
on you see if it gets enabled or disabled. So just add your reset code
in on case and disable signal for off case you I guess you are done.
V2
would be in deed easier as it has dedicated z probe classes for
different kinds and also has automatic geometry calibration. But at the
moment avr boards are not supported. It is planned and I hope the 8 bit
boards are fast enough for the new system which is especially for deltas
much better. On the other side avr is quite slow so motion resolution
will still need to be quite coarse. Even a due which is 10 times faster
already allows a much higher frequency of updates and smoother moves.
The nice thing with V2 is that quality will automatically increase with
slower moves, so slow outer perimeter will run it with higher precision
automatically.
We don't have that printer and hence no sample configs, sorry.
1.0.5 contains a bug fix to G32 - not sure if this is relevant for deltas but z was wrong after G32 and that is now fixed. Running home after it would also prevent the problem.
Minor note: Compiling the latest dev (1.0.5) branch in Arduino 1.8.13 was giving me errors because the version of overloaded RMath::max() isn't clear (see below). I fixed this by changing line motion.cpp:2070 to the following:
C:\Users\franc\AppData\Local\Temp\arduino_build_903360\sketch\motion.cpp: In static member function 'static uint8_t PrintLine::queueNonlinearMove(uint8_t, uint8_t, uint8_t)':
motion.cpp:2070:73: error: call of overloaded 'max(int, int32_t)' is ambiguous
I had originally added the HE280 handling in 1.0.4, and when I tried running it in 1.0.5, it wasn't working well. I ended up running into issues related to low memory on the RAMBo 1.3L in 1.0.5. After fixing the memory issues, I had issues with inconsistent probing results.
I decided to use a Teensy microcontroller to handle the I2C, freeing up Repetier to just treat the HE280 as a normal endstop (Z-min input, with a 10 ms high-level trigger output from the Teensy on probe/bed contact). This is much more stable, and doesn't need any extra code/parameters than the normal Repetier. The HE280/Teensy 4/RAMBo adaptor is documented at https://github.com/FEsmondeWhite/HE280AccelerometerInterface. This approach is forked from https://github.com/trash80/HE280AccelerometerInterface which uses the teensy to adapt the HE280 for a Duet2 controller.
In my earlier post, I hadn't pointed out two defines that I was using for setting up the accelerometer in configuration.h. #define Z_PROBE_SENSITIVITY 20 // 0-126 7 bit value #define Z_PROBE_ACCELEROMETER_I2C_ADDR 0x19
With additional testing, I found that the Z-probe wasn't being updated correctly on the development branch.
I would suggest reverting my older HE280 code change, and just pointing people to the Teensy adapter code. This setup works well with Repetier 1.0.5 and the HE280 platform. As a 20$ magic-glue, this is an easier and more reliable option.
In case anyone else is interested in adding
endstops, dual-extruder, and the HE280 support under RAMBo 1.3L to their upgraded SeeMeCNC
Rostock max v2->v3, I am uploading my Configuration.h.
Repetier-Firmware is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
Repetier-Firmware is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with Repetier-Firmware. If not, see <http://www.gnu.org/licenses/>.
/**************** READ FIRST ************************
This configuration file was created with the configuration tool. For that reason, it does not contain the same informations as the original Configuration.h file. It misses the comments and unused parts. Open this file file in the config tool to see and change the data. You can also upload it to newer/older versions. The system will silently add new options, so compilation continues to work.
If you are in doubt which named functions use which pins on your board, please check the pins.h for the used name->pin assignments and your board documentation to verify it is as you expect.
// ################## EDIT THESE SETTINGS MANUALLY ################ // Microstepping mode of your RAMBO board #define MICROSTEP_MODES { 8,8,8,8,8 } // [1,2,4,8,16] // Motor Current setting (Only functional when motor driver current ref pins are connected to a digital trimpot on supported boards) #define MOTOR_CURRENT_PERCENT { 55,55,55,55,55 }
// ################ END MANUAL SETTINGS ##########################
//#define EXTERNALSERIAL use Arduino serial library instead of build in. Requires more ram, has only 63 byte input buffer. // Uncomment the following line if you are using Arduino compatible firmware made for Arduino version earlier then 1.0 // If it is incompatible you will get compiler errors about write functions not being compatible! //#define COMPAT_PRE1 #define BLUETOOTH_SERIAL -1 #define BLUETOOTH_BAUD 115200 #define MIXING_EXTRUDER 0
/* If the firmware is in laser mode, it can control a laser output to cut or engrave materials. Please use this feature only if you know about safety and required protection. Lasers are dangerous and can hurt or make you blind!!!
The default laser driver only supports laser on and off. Here you control the intensity with your feedrate. For exchangeable diode lasers this is normally enough. If you need more control you can set the intensity in a range 0-255 with a custom extension to the driver. See driver.h and comments on how to extend the functions non invasive with our event system.
If you have a laser - powder system you will like your E override. If moves contain a increasing extruder position it will laser that move. With this trick you can use existing fdm slicers to laser the output. Laser width is extrusion width.
Other tools may use M3 and M5 to enable/disable laser. Here G1/G2/G3 moves have laser enabled and G0 moves have it disables.
In any case, laser only enables while moving. At the end of a move it gets automatically disabled. */
/* If the firmware is in CNC mode, it can control a mill with M3/M4/M5. It works similar to laser mode, but mill keeps enabled during G0 moves and it allows setting rpm (only with event extension that supports this) and milling direction. It also can add a delay to wait for spindle to run on full speed. */
#define DELTA_SEGMENTS_PER_SECOND_PRINT 180 // Move accurate setting for print moves #define DELTA_SEGMENTS_PER_SECOND_MOVE 70 // Less accurate setting for other moves #define EXACT_DELTA_MOVES 1
/* ======== Servos ======= Control the servos with M340 P<servoId> S<pulseInUS> / ServoID = 0..3 pulseInUs = 500..2500 Servos are controlled by a pulse width normally between 500 and 2500 with 1500ms in center position. 0 turns servo off. WARNING: Servos can draw a considerable amount of current. Make sure your system can handle this or you may risk your hardware! */ #define FEATURE_SERVO 0 #define SERVO0_PIN 11 #define SERVO1_PIN -1 #define SERVO2_PIN -1 #define SERVO3_PIN -1 #define SERVO0_NEUTRAL_POS -1 #define SERVO1_NEUTRAL_POS -1 #define SERVO2_NEUTRAL_POS -1 #define SERVO3_NEUTRAL_POS -1 #define UI_SERVO_CONTROL 0 #define FAN_KICKSTART_TIME 200 #define MAX_FAN_PWM 255
Comments
https://www.seemecnc.com/pages/delta-calibration-wizard
I think it's the same thing, I am attaching the photo of the mechanical correction without autolevel G32 & G33 and then with the corrections.
Only mechanical
https://i.imgur.com/vqb0MvE.jpg
With G32 & G33
https://i.imgur.com/8O9tWBP.jpg
There is to be improved..
Not sure how the old firmware did handle the problem that only one filament can be loaded. You can have scripts on extruder select and deselect or just keep it in sync on your own and with good slicer scripts.
Edit
MIXING_EXTRUDER setting to 0, thanks so much!
mechanical calibration and Eschel3D:
Without G32 S2, only mechanical and Eshel3D:
with G32 S2
Advice? Not print yet, G33 S2 crashes and dont know why.
EDIT
Despite the calibration below 0.1 and the auto level g32 S2 the nozzle touches the bed halfway..
I tried to print by deleting the G32 with M322 S2 but the result is the same. Is it possible that the self-calibration does not activate?
I wonder what the calibration tool changed? Output values are the same as initial values if I see it correctly.
-3° is a big error for a tower position. Also you see in height map that the neutral height has 3 parts which is typical for angle errors. Each tower ha sit's main zone of influence.
G32 S2 works great and doesn't crash and that's what I don't understand, it has the same 90x90 measures. Before having calibrated with Esher 3D G33 S2 it was fine without crashing. I will try to improve the result.
Also what is the message you get? M999 means there was a fatal error you need to fix before anything works. This is to protect printer and when you see it firmware detected a problem.
The problem was the calibrations made with eshel3d, for some reason they gave me problems with G33. Regarding the bug I hope but by reversing the position of the probe the differences in the bed have been reversed. I have an offset of X20 Y15 and therefore I assume that the probe experiences the tilt of the platform at the ends of the bed.
I will try to build a probe housing in the center under the nozzle to see if the theory is correct.
G33 X90.00 Y45.00 Z0.000
with the z correction you want there. That way you can optimize probelmatic zones a bit.
#define MOTOR_CURRENT_PERCENT { 55,55,55,55,55 }
Can you confirm that this is it?
So for rambo you need
// Values 0-255 (RAMBO 135 =~0.75A, 185 = ~1A)
Here you just set the digipot values of current.
i have only in configuration.h:
Need change
#define MOTOR_CURRENT_PERCENT { 55,55,55,55,55 }
to:
#define MOTOR_CURRENT {135,135,135,135,135}
// Values 0-255 (RAMBO 135 =~0.75A, 185 = ~1A)
in this?
1.0.5 contains a bug fix to G32 - not sure if this is relevant for deltas but z was wrong after G32 and that is now fixed. Running home after it would also prevent the problem.
static inline float max(float a, float b) {static inline int32_t max(int32_t a, int32_t b) {static inline int16_t max(int16_t a, int16_t b) {static inline uint16_t max(uint16_t a, uint16_t b) {#define Z_PROBE_SENSITIVITY 20 // 0-126 7 bit value
#define Z_PROBE_ACCELEROMETER_I2C_ADDR 0x19