Great progress!! Turns out the sticker on the printer describing its wires' input is backwards. I found that out reviewing this guy's code
! This other guy's code and Thermal.h lib
is what I ended up using to get the printer going.
My first real use of the thermal printer was to print out the results of various "speed" settings for the stepper motor. With the Easy Driver's potentiometer adjusted for minimum current, I wanted to see how speed affected the stepper's performance. Three of the TPSs I sell have a return spring loaded on the input shaft and I know from my 1st test bench that this force needs to be overcome by the stepper motor. Speed is a value from 0.1 to 1. This (of my 4 TPSs) stutters with speed set to 0.75, but can complete the sweep with speed set to 0.6. The below printouts are a listing of 1 degree measurements of the ADC input for speed values of 1, 0.5, and 0.1.
With speed set to 1.0, it couldn't even complete the sweep!! The next test, I ran "speed" values of 0.9, 0.75, and 0.6. I could hear 0.9 and 0.75 stutter, but 0.6 was OK, so I set that as the speed factor setting for this particular TPS.
Next up, to start the process of plotting the voltage to angle response curve of the TPS. My initial goal was to display this curve to the operator of the test bench to help decide if they believe the Arduino when it decides if the TPS is good or bad. Test bench 1.0 only tests 35 points and uses a character LCD display to SAY good or bad based on the program's observation of point-to-point analysis. This is certainly better than the industry-standard test of 4 points: off, on, and 2 points in the middle. YES, this 4 point test is what you normally pay $100+ to buy a TPS for!
OEM parts sometimes fail my v1.0 bench with its measly 35 test points...
I found out that with this proper stepper motor and the Easy Driver board coupled with my 18:54 (1:3) gearing that 13 and 1/3 microsteps (u-steps) is 1 degree. With 14 u-steps per measurement, I got 90+ points of data! So I need to decide if I want to depict degree data at all through this, and if it should have accuracy. 3 degrees = 40 u-steps. I'll either do 10 u-steps per measurement or 14. Twenty u-steps is too similar to the current test bench and therefore, "not good enough".Now that I have a power_test() function sorted out
, I started on the test() function. It's really about the same as the power_test(), only we're only iterating once at a speed factor known to have enough power to complete the test. test() sweeps through the known range of TPS valid values and records each step to an array. Then the stepper returns the input shaft to initial position and my rest() function drives ENABLE input to Easy Driver high, turning off the current through the stepper, prolonging its life, saving energy, and keeping the stepper motor at a cooler temperature.
With the sweep of the TPS's range done, I iterate through the array and figured out how to plot the values from bottom left to top right. I used the map() function
and known beginning and end points of the TFT to map() the idx (as x) and test[idx] ADC values to to x and y for each step. I then "looked ahead" and instead of drawing points, I drew lines from this x,y to the "next x,y". And ended the for() loop one entry too soon since my look ahead induced a one-off error.
And here's the plot:
Non-casual observers will notice that the plot is non-linear. The theory behind non-linear TPS is great: the most important time a person is using the throttle is from closed to half open. This is when you are mid-corner or entering into a parking lot, etc. Very crucial moments! With a steep 1st half of the plot, there is great resolution between inputs. This helps the fuel injection computer (referred to an an ECU) more precisely understand what your input is at during these crucial moments.
And then past what I call the "knee", the slope of the curve is gentle. From half throttle, there isn't much point in differentiating the operator's input; most people go to wide open throttle (WOT) from half throttle very quickly anyway.
There we are today. 1 of 4 TPSs pretty well handled. Next up, convert that array of idx to ADC values into a bitmap so I can print it out on the printer. Of the four TPSs I sell, two are non-linear and two are linear. The linear ones are pretty easy to programatically determine good or bad, but the non-linear ones quickly become miserable before-and-after rules and exceptions.
Anyhow, I am very very
for today and honestly
that I'm able to graphically show the display. From the first time I plotted idx vs ADC values in a spreadsheet, I knew that showing the response curve was the best way for the operator running the test bench to decide if this particular TPS is good or bad.
Never happy with it just being... always have to push it a bit too far.