Hallo, I am only a GUI programer, and while coding gmoccapy, some time I got very frustrated, because of the unit handling in the different linuxcnc parts.
I.e. why is it not possible to give the grid size to gremlin in metric units? It will only accept imperial values. I did also make some glade widgets and I really find it very frustrating, to check on so many parts for the units and need to convert. IMHO: it is just a stupid think to have the different parts of linuxcnc handle different units!! The internal units should be metric in any part of linuxcnc, no matter what unit the user selected! Only the way to show values to users should reflect the custom selected unit system. So there is only one conversion needed for getting values from INI or config files and one conversion to display the results to the user, all other stuff in linuxcnc just handle the metric standard. (I recommend metric, because imperial is less used in the world, and even American Motorcycle and car manufactures learned using metric screws increases the acceptance in the world) We should write that on the ToDo for linuxcnc 2.7 and begin to work on it now. Some of you may say, never touch a running system, at the moment there is no bug .... , but that behavior does not make the system better or even more stable for the future, it only maintain unneeded, or more complicated code, giving new contributors even more headaches than they already have. Norbert P.S. how will machinekit handle that in the feature? Am 11.04.2014 18:16, schrieb Jon Elson: > On 04/11/2014 10:46 AM, Chris Radek wrote: >> Minor complexity: we have a freaky result due to >> http://www.linuxcnc.org/docs/html/gcode/overview.html#sec:Order-of-Execution >> >> consider: >> G20 >> F5 >> G1 X1 >> G21 F125 X100 >> >> according to NGC the F125 is taken as inches while the destination >> is taken as mm! I hate this special case and think we ought to >> diverge from NGC if we overhaul units handling. The length units >> setting should be honored before anything else length-related is >> read from the block. >> > Yeah! That is a sick way to do things! Anything modal in a > block should > take effect for the block (not after). (Cutter compensation > is a special > case where it DOES make sense, it is interpolated in/out > DURING the > move.) > > Jon > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
