On Fri, Apr 11, 2014 at 08:48:42AM -0400, Robert Ellenberg wrote: > Me too, I've only had time to email a bit due to schoolwork. To answer your > main question: it could make the C++ portions of the code simpler and > easier to maintain.
I see, I was thinking of a bigger goal, which is to eliminate the whole class of errors that pop up from time to time, that are related to units conversion. We've had both missing conversions and double conversions. For a while when my car's MPG display would show 25.4, I'd think OH GREAT - another one. FWIW, they are currently all fixed. But I doubt we've seen the last one. > For example, there are many functions that pass each axis value as a > separate argument, then have blocks of 9 lines for copying and arithmetic. > Defining operators and possibly storing a unit variable could shrink those > 9-line blocks down to a single, clear operation. What do you think of the much bigger proposal of converting to internal units very early (like how diameter conversion is handled in Interp::read_x) and removing units twiddling from all the internal layers? This would still make the canon level simpler, but by removing the need for all the conversions instead of just changing them from explicit to implicit. But it would also make the interpreter simpler and less brittle: see Interp::convert_length_units, qc_scale, tolerance checks in convert_arc_comp[1,2], etc. We've fixed units-related bugs in all these places. Seb pointed out that you'd have to convert to the user's preferred units before printing error messages. In reality we have very few errors that give distances or positions; Surprisingly I found just these few: Invalid absolute position %5.2f for wrapped rotary axis %c (this one is degrees so doesn't matter) BUG: cutter compensation has generated an invalid arc with mismatched radii r1 %f r2 %f (not seen in normal operation) Radius to end of arc differs from radius to start: start=(%c%.4f,%c%.4f) center=(%c%.4f,%c%.4f) end=(%c%.4f,%c%.4f) r1=%.4f r2=%.4f abs_err=%.4g rel_err=%.4f%% Today if you run a G21 program you'll see the above messages in mm regardless of your UI (DRO) units setting or your machine config setting. I think that's probably right (because you'll use that information when you go edit the code). I'm getting too detailed. In the very big picture of the whole program, I see inputs where unit conversions have to happen: Gcode, tool table, var file, hal Outputs: tool table, var file, motion before writing to hal (or should hal do it just before presenting values to the user?), user interfaces (where? before or after the stat buffer?) I am seeing this is really half-baked. Sorry for that. Chris ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
