Talk:CNC Torch Table Z Height Control
Wed Aug 09, 2017
things, that could be optimized in a possible next iteration of the pcb:
- replace J7 with a 5-pole terminal (including the SW signal).
- add a bigger sized terminal at J4 (powersupply via the pcb for the TB6600). Could be same type like the Phoenix-connector of the powerplug.
- add a 4-pole terminal that is connected to the SHIELD-ground
- make J5 pin-compatibel to standard/commercial EndStops
Wed Aug 09, 2017
Hello Oliver. I started a new page for the CNC_Torch_1708 so not to mess with your height controller. Thanks for the pictures man, I finally got it working without the ramps. With the Ramps on, I cannot find the pins for the axes (Emmanouil)
Hey, thats cool ;) , as i can see in  you have already two steppers on one TB6600 ! And yes, i was also thinking that the Ramps can be ommitted, if you supply the TB6600 directly with power and dont use the pololu stamps. The Ramps is just a kind of adapter but maybe for some things like endstops it could be more convenient. Theoretically you could use even any pins on the Mega in an arbitrary order, but if you choose the same pin-numbers like on the Ramps you are immediately compatible to programms like Marlin (without changing its pin-mapping-tables).
For finding the pins for the axes on the Ramps, the silk-screen on  is helpful, if you watch it at highest possible resolution there are very fine pin descriptions in grey color. For the X-axis as an example, there are blue points showing the relevant pins on the x-connector. A diagramm that points out the connections more clearly is on . If you want to connect directly to the mega, the schematic that you uploaded at  is appropriate to identify the pin-numbers on the Mega cpu (and also the (small grey) pin labels on the silkscreen).
Have you already tested it by applying some gcodes ?
Yes, we tested some G codes. I was struggling to find out the wiring. Some pictures have conflicting information, the .pdf about the TB6600 has errors, and on top of that the 2 different ramps I was testing were burned out. Anyway, we tested 4 motors, we put back the Ramps we need it -as you very well mentioned-, and we are going to go to the next step, the wiring with cat5 cable.
Thanks for all the help, everything is so clear right now!
Sat Jul 22, 2017
Specific Steps for Signal Improving
1. Software level?
2. Hardware improvement? Ring size?
5. Calculation vs. observed - are we getting the expected capacitance? What is the current signal to noise ratio?
6. Improving amplitude of capacitance?
7. Better test-rig and -setup
- First place for improvement, e.g. by applying filters for smoothening the signal and timing-related strategies
- hammer out default test-scenario (and test-rig setup)
- Visualization of sample data, e.g. by direct user interface or the host-monitor-tool. With help of the "processing"-IDE one can simulate the effects of any filters etc. based on the sample-data from the running process and have meanwhile a visual introspection. The algorithm-part then can be put modular into the firmware (via the arduino IDE) and tested directly on the board.
- other kinds of signal-processing algorithms and techniques, like frequency distribution (gaussian, variance, chi-square) up to pattern-recognition (ANNs), etc.
- doing something with the registers of the AD7747 chip according to its datasheet. Maybe there are still unused option, e.g. for calibration, or influence sampling-rate, gain etc.
- algorithm in the firmware could still contain bugs to eliminate
- there are some "Adjustment Screws" in the firmware, e.g. width of window for sliding average that can/should be fine-tuned
- Sensor: bigger ring-version
- Better grounding and shielding, has huge influence on signal-quality. I tried to connect the case of the stepper-motor to the shield-potential, but that made the signal much more worse, maybe because GND and SHield-GND are two different potentials
- other kind of shields / EMF-countermeasures, like cages
Filtering and Averaging
- a pre-averaging is implemented and its range is one of the "Adjustment-Screws". Tested with n=4 or n=10. Problem is, that the measurement consumes time, maybe 100ms or more per sample. So you can not get very high here without slowing the whole tracking down. But maybe this could also be an option: is it possible to slowdown or even stop the torch-movement without negative effects on the cut-quality ?
- a sliding average is implemented and its width is another screw. tested with w=4 and w=10. Bigger value means smoother signal noise is well eliminated. Problem is, that you introduce a delay hereby, because width a window of w=10 it needs in case of a real change longer, until it gains its full wheigt within the calculation for statistical reasons. IOW: bigger window = better signal, smaller window = more immediate reaction, but also on noise-artifacts.
- a border-setting of e.g. 2.4 aF is implemented. If the deviation of the sample is not bigger than 2.4 aF difference from the average, it is considered as noise-artifact and the movement doesnt take place. less (unnecessary) movement means less noise caused by the motor, iow. this eliminates, that the tracking follows the noise (like seen in the first part of the video) and instead can hold its position calm and constant. But oth a big border- or difference-value means also a delayed reaction on real changes of the ground level.
- other methods are possible, preferably working statistically, meaning without additional time-needs e.g. for more samples.
Calculation vs. observed
- important. [todo: add calculations here]
- we also need a measurement that controls the correctness of the positioning while development and characterize typical standard-deviations.
Improving amplitude of capacitance?
- i wonder, whether it is possible to make a kind of deal with the AD7747: It seems to be able to measure along a range of up tp 5cm. Could we maybe exchange this towards a smaller range (like 2cm) but with a better resolution ?
Better test-rig and -setup
- add end-stop and implement push-button functionality of the KY-040, for improving the flow and control of the experimental setup. E.G.: A testrun may start with its calibration loop from a manually adjusted home-position and then goes into balancing-loop. But if you start the Serial Monitor from the Arduino IDE, it regularly resets the board and starts again the calibration-loop on a wrong position. Steering this by the jogwheel pushbutton could be helpful in this case.
- Also Host-monitoring could be replaced by a direct-user-interface (like OLED-display).
- maybe the board should be also mounted on the carriage, so that the SeonsorHead-cable is not bend when moving
- adding delays between motor-movements and measuring may help against noise
More sophisticated calibration: Instead of calibrating at min/max value and calculating the in-between positions one could do a more sophisticated calibration by measuring individually at each in-between-position and producing a calibration-table. This could better resemble the real tuning-curve, which may be not exactly linear.