Open solhaga12 opened 3 years ago
Why not using babystepping logic? You may inject babystep pulses depending on arc voltage feedback
Yes, that could be it. I haven't studied the babystepping logic, though. Could you point me to how it works and perhaps the API for it?
I have already changed the temperature timer interrupt in order to sample the arc voltage, so it would be super if the babystepping API could be reached within that context.
@thisiskeithb label is wrong here. This is not a calibration FR. arc voltage following, in plasma & laser machines, is a needed behaviour
@solhaga12 I'm not sure you can talk about API in babystepping or UBL logic. I'm don't know very well how it works, but in general babystep should add some steps inside stepper ISR. Try to take a look at how lcd adds them.
Thanks, @GMagician! I'll dive into the stepper ISR then. By
Try to take a look at how lcd adds them
I guess you mean the way that you can do the "Live adjust Z"?
I guess you mean the way that you can do the "Live adjust Z"?
Yep
I've now looked into baby stepping a bit. But it is too slow for THC. Any idea to speed it up (apart from increasing BABYSTEP_MULTIPLICATOR_Z which doesn't help much)
In the temperature ISR the actual THC voltage is read and then compared with the wanted THC voltage. Depending on if it differs and in which direction babystep.add_mm(Z_AXIS, BABYSTEP); or babystep.add_mm(Z_AXIS, -BABYSTEP); is used. BABYSTEP is 0.1 (mm). Then to speed up the change babystep.task(); is called multiple times.
So in the temperature ISR I have:
Read the differential voltage that represent the torch height:
#if COREXY_PLASMA
case PrepareTHC_1: HAL_START_ADC(VOLTAGE_DIVIDER_PLUS_PIN); break;
case MeasureTHC_1:
voltage_plus = HAL_READ_ADC();
WRITE(PLASMA_VD_UPDATES_PIN, HIGH);
break;
case PrepareTHC_0: HAL_START_ADC(VOLTAGE_DIVIDER_MINUS_PIN); break;
case MeasureTHC_0:
voltage_minus = HAL_READ_ADC();
WRITE(PLASMA_VD_UPDATES_PIN, LOW);
actualThcVoltage = ((voltage_plus - voltage_minus) - OFFSET)/SLOPE;
plasmaManager.setActualThcVoltage(actualThcVoltage);
break;
#endif
Calculated the difference between the wanted and actual voltage and determine whether and the direction of the babystepping:
#if COREXY_PLASMA && ENABLED(BABYSTEPPING) && DISABLED(INTEGRATED_BABYSTEPPING)
// Check if THC is enabled
if (plasmaManager.isThcEnabled() == true) {
// Check hysteresis
if (abs(plasmaManager.getWantedThcVoltage() - plasmaManager.getActualThcVoltage()) > 1) {
// Calculate direction
if (plasmaManager.getWantedThcVoltage() > plasmaManager.getActualThcVoltage()) {
babystep_position += BABYSTEP;
if (babystep_position > 20.0) { // check max limit, should be 20!
babystep_position = 20.0;
} else {
babystep.add_mm(Z_AXIS, BABYSTEP);
}
} else {
babystep_position -= BABYSTEP;
if (babystep_position < -20.0) { // check min limit, should be -20
babystep_position = -20.0;
} else {
babystep.add_mm(Z_AXIS, -BABYSTEP);
}
}
}
}
#endif
I'm not to happy with the snippet above, a little too many if levels.
And then made the babystep:
#if ENABLED(BABYSTEPPING) && DISABLED(INTEGRATED_BABYSTEPPING)
babystep.task();
#if COREXY_PLASMA
babystep.task();
babystep.task();
babystep.task();
#endif
#endif
The reason for having that many calls to the babystep task, is to get the speed of the correction up. The torch can travel up to 140 mm/s in X/Y and the steel can be bent or be bent when cutting.
Hello, good evening. I see that a few years ago you were already looking at how to incorporate THC into marlin, I would like to know if you were able to achieve the correct operation. thank you so much
Hi.I didn’t succeed.The THC correction were applied after the current gcode execution and not during.
Because of serial (and gcode) buffers... To make decent THC you'll have to use couple interrupt-capable pins as babystep input.
Yes, it seems not possible to "squeeze in" anything once the movements are in the buffer.
To make decent THC you'll have to use couple interrupt-capable pins as babystep input.
Do you mean to output the calculated +/- adjustments to pins connected to interrupt pins that have higher priority than the execution of the buffers? In the corresponding ISRs you only +/- the Z babystep?
Yep, it'll be same as with encoder, and without INTEGRATED_BABYSTEP - as immediate as it could be. I don't know much about THC hardware, but isn't up/down or step/dir pulses is more or less default interface?
I've built my own hardware, where the actual voltage is read via an opto insulated (ACPL-790A) ADC-input. I then compare that voltage with the desired THC voltage. So the up/down adjustment information is in software.
The desired THC voltage is in the gcode and set in my Fusion360 CAM; I do not set it an external THC hardware's interface.
What? So your THC is part of marlin already? NVM, i didnt read backlog first
hmm, looking at rthe code - INTEGRATED_BABYSTEPPING might be actually faster...
It's fine. Made me think of the problem again.
If solved in the Marlin software I must be able to insert Z corrections in the buffer's head and not its tail.
I've come a little further: In the Fusion360 post processer, the G1 moves are divided into smaller steps. In Marlin, the G1 command takes into account of the calculated voltage difference and increaseo or descreases the Z height.
In works in principle, but it will require a lot of tuning. One big obstacle is that every parameter changes as the consumables wears.
Here's the post processor and the G1 code along with the plasma gcodes and the temperature interrupts. CoreXY plasma.zip
I used your aproach method and made some minor changes and its works perfectly. Thanks for sharing your findings
1) Added 2 variables:
1- One to set or adjust voltage gap from G2107 (no nided to modify firmware to change this value)
2- Record machine Z higth (avoid height calculation error when working with Workspace Coordinate System (G54....G59)
2) Increase voltage sampling count, for more stable voltage reading.
I am thinking of using bed leveling as THC for a plasma CNC. THC is Torch Height Control, that is adjustment on Z values to compensate for warped steel. The input is the difference between an actual voltage that is compared with a wanted voltage. The difference is not a static value, the steel sheet can warp during cutting so the Z compensation has to be done in real time.
My idea is to fake the bed leveling calibration and use the bed leveling API when moving across the "bed". So instead of returning a value from the bed level calibration matrix at any given X and Y values, I was thinking of returning a Z adjust value based on the difference between the wanted torch voltage and the actual.
Is the bed level calibration value, that is the adjustment in Z, returned in real time, that is only based on current X and Y values and then added/subtracted to/from the Z layer height?
Or is it calculated based on the bed level calibration matrix when reading a G1 string?
My hope of course the former.