140329 added a known bug and a wishlist item to readme.
140329 added commenting to k2400.h and main.cpp as a way to help me learn c++ and understand stans program.
140401 added known issue to readme after first breaking attempt
140402 more commenting to k2400.h and k2400.cpp in my quest to learn c++ and understand this program
140402 changed integration time to 10 PLC (power line cycles a.k.a. 1/60Hz) instead of 1 PLC
140403 added header to output file that lists value of all user-input parameters, added more comments.  still need to address what to do with negative voltages.
rearranged the directory structure to be more compatible with VSExpress2013. Had to add 'return 0' line to configure function b/c prototype had return type as int. Had to rename ARRAYSIZE->ARRAYSZ b/c the windows header file has that defined already. Had to change 'and' to '&&' - no idea why my IDE didn't recognize 'and'. Had to change popen and pclose to _popen and _pclose. Not sure why. Note that sprintf and fopen are deprecated. used them anyway. ***This commit compiles, but have not tested it yet.***
140404 removed the line that changes any negative resistance to positive resistance. changed the rampdown=true conditions to be (counter > 6 and (res > res_bench || res <0))
140405 had to change the project compile settings to statically link to libs so i could port the .exe over to probe station computer. this version has been verified as working with nanowires and test resistors.
140405 changed the condition for breaking the measurement to be either backspace is pressed OR volt > voltmax OR there have been 3 consecutive measurements of resistance that are greater than (1-targtol)*targres. This version compiled and is running fine on a nw right now.  the scan hasn't finished so cannot confirm that exit condition is debugged.
140405 changed the condition for ramp down so that even if we are at the beginning of a ramp cycle, if there is negative resistance it throttles back. did this because when using 15 mV ramp down size i had an uncontrolled break in the first 6 steps of a ramp cycle.
changed the calculation of benchmark resistance to reject only the first two data points on a ramp and use the next three as average. changed ramp down condition to be (counter > 2 AND res < 0) rather than res < 0 at any point in the ramp.
changed benchmark averaging back to reject 3 data points then average 3. changed rampdown condition back to r<0 regardless of what counter is. will try breaking with bigger ramp downs.
sweep exits after 3 consecutive res > res_target.  ramp down after EITHER (2 consecutive res < 0) OR (2 consecutive res < res_bench). also now input file name at beginning of each sweep rather than only when parameters are set.
changed ramp down so that instead of just taking one large step of -(rampdownV) it takes 1mV steps with a delay of 0.04 secs to achieve the same total ramp down. it still doesn't write any data during the ramp down. i saw this in several protocols, i'm guessing it just facilitates the breaking.
rejecting first 5 data points on ramp, averaging next 8. printing this to stdout for oversight purposes. looking for 3 consecutive benchmarks or negatives to ramp down.