It appears to me that the command to switch from inch to metric, is incompletely done. Or too completely.
Fspeed for instance, is not scaled up to the metric equ, so the sim runs painfully slow. This was observed executing old code probably written in 2.5.0 days and being used just to exercise the sim. Back then I could apparently set f15, thinking in inches, but in 2.6.0 sim the f15 is being done in mm/min. Painfully slow. This is a coding error on my part of course, but its going to make me edit a boatload of old code should I want to use it again. It might serve as a heads up if it was mentioned in the 2.6 docs. Or is it? TBT, I haven't checked... I believe a similar gotcha exists in the MIN_LIMIT/MAX_LIMIT of the .ini files. They are not, when given in inches, scaled to match actual distances without a trip into gedit for a metric translation. I got used to the old way, and its going to bite me trying to run old code in its inch mode. Would it not make more sense in the long run to specify this stuff in machine units? That way, we would be forced to do our own math at coding time, and the inline math to check this stuff, like the limits I should assume, be somewhat simplified and therefore faster at run time. Just thinking out loud. Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ------------------------------------------------------------------------------ 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
