Upgraded my V2 with the new ball arms ,etc and the HE280 head.
Ran the calibration and it worked the first time. Then I changed beds to PEI and it no longer worked. It kept repeating the horizontal radius calibration over and over until turned off. Using Matter Control console I discovered it was outputing an error about z probe failed. I returned to the original glass bed and the same thing happened. I started over and cleared the EEPROM and then it worked once more but only once. It again said z probe failed on the horizontal radius portion.
After much experimenting I discovered that if you change the EEPROM value for Max Z max length of 361.725 back to 375 then it will work. Once the calibration is finished on my machine that value is 361.725.
Anyway I wonder if anyone else has discovered this issue and the fix?
Dale Eason
HE280 Z collibration issue
-
Dale Eason
- Printmaster!
- Posts: 191
- Joined: Fri Mar 06, 2015 8:56 pm
Re: HE280 Z collibration issue
I have done much debugging and changing the software to figure out what is happening.
The problem happens on the G30 command and sometimes the G68 commands. These commands will prob the center of the bed with two taps. It records the distance the head moves from the 25 mm height park position just before the actual probe to when it is stopped by the bed. To know when it is stopped by the bed it samples the accelerometer sensor. If the acceleration is above a threshold it knows it has hit the bed.
I added code to print out that distance on each tap. I found that many times it thinks the first tap has only moved only 1 to 9 steps from the 25 mm position. That means that there may be a false acceleration signal. It only happens on the first try and the second try has an expected good value of the distance moved. When it does happen the code checks that both taps are at the same distance within .1 mm. When the values mismatch too much that triggers the code to start over with a home command. I modified the code to do more than one tap and take the average of the distances. So what was two taps has become multiple taps for each of the original two taps. Each group of taps is averaged and that fixes the problem because all but the first tap work correctly.
I don't know why the first tap is a problem. It seems to be related to the distance it has to travel because if I change the default Z height eeprom value to 375 it seems to always work. However that calibration will change the Z height value to 362 on my machine and so the next time the code is run it will start with that value and fail if it does not have my modification.
The modifications are fairly simple. Change the configure.h file to change the number of Z_PROB_REPETITIONS from 1 to 3 or more. I settled on 10 probes. Have not heard of others seeing this issue. But as the number of upgraders increases maybe it will show up more. Could be caused by some sort of noise on the lines but I don't see how or why it only happens at the cetner position.
Dale Eason
The problem happens on the G30 command and sometimes the G68 commands. These commands will prob the center of the bed with two taps. It records the distance the head moves from the 25 mm height park position just before the actual probe to when it is stopped by the bed. To know when it is stopped by the bed it samples the accelerometer sensor. If the acceleration is above a threshold it knows it has hit the bed.
I added code to print out that distance on each tap. I found that many times it thinks the first tap has only moved only 1 to 9 steps from the 25 mm position. That means that there may be a false acceleration signal. It only happens on the first try and the second try has an expected good value of the distance moved. When it does happen the code checks that both taps are at the same distance within .1 mm. When the values mismatch too much that triggers the code to start over with a home command. I modified the code to do more than one tap and take the average of the distances. So what was two taps has become multiple taps for each of the original two taps. Each group of taps is averaged and that fixes the problem because all but the first tap work correctly.
I don't know why the first tap is a problem. It seems to be related to the distance it has to travel because if I change the default Z height eeprom value to 375 it seems to always work. However that calibration will change the Z height value to 362 on my machine and so the next time the code is run it will start with that value and fail if it does not have my modification.
The modifications are fairly simple. Change the configure.h file to change the number of Z_PROB_REPETITIONS from 1 to 3 or more. I settled on 10 probes. Have not heard of others seeing this issue. But as the number of upgraders increases maybe it will show up more. Could be caused by some sort of noise on the lines but I don't see how or why it only happens at the cetner position.
Dale Eason
Re: HE280 Z collibration issue
I'm suffering this issue too, there appears to be too many hard coded values in the code. My arms are 300mm trim laser arms I had to modify the horizontal radius too else it smashes into the towers.
I'll post back my source delta once I have it fixed.
Rostock Max v2 + HE280 upgrade & 300mm trick laser carbon arms running v3 patched firmware
I'll post back my source delta once I have it fixed.
Rostock Max v2 + HE280 upgrade & 300mm trick laser carbon arms running v3 patched firmware