On Sunday 02 April 2017 15:22:08 Nicklas Karlsson wrote: > On Thu, 30 Mar 2017 22:04:04 -0400 > > Gene Heskett <ghesk...@shentel.net> wrote: > > On Thursday 30 March 2017 15:07:41 John Kasunich wrote: > > > There was a time (in the late 1990's to early 2000's) when > > > LinuxCNC (EMC back then) had three realtime threads. What we now > > > know as the base and servo threads, and a third slower thread for > > > the trajectory planner. Back in the day, computers couldn't > > > necessarily do all the trajectory planner (and especially > > > kinematics) math quick enough, so the planner ran at 1/10 the rate > > > and the output was interpolated at the servo rate. > > > > > > The third thread went away in 2004 or so when EMC2 rewrote much of > > > the motion controller. > > > > > > There is no mechanism for detecting unused ini file parameters, so > > > it is quite possible that no code has actually used the parameters > > > you mention in more than a decade. > > > > > > I'm not in a position to do it, but I wonder how hard it would be > > > to grep thru the code to see if those parameters are used? If > > > they're not, they should be deleted from the sample configs. > > > > > > John Kasunich > > > > Interesting comment, John K. > > > > So I fired up the editor and took both CYCLE_TIME settings in the > > .ini file out of the ini file for my small mill. > > > > On running it, trajectory did not complain, but emcio did, saying it > > was useing the default timing of .01 seconds, same as the ini file > > setting. That did not prevent it from running. So I restored that > > one, but left it commented out in the [TRAJ] section. > > > > Based on that, the [TRAJ] section CYCLE_TIME could probably go away. > > If there is no feedback it might be better to do more work at once. > With a slower thread priority could be reduced. > FWIW, I put about 95% of the jog-wheel stuff in a separate thread on the pi, running at 200 Hertz. Thats about on a par with my ability to spin the crank. Even if I overrun the motors MAX_VEL (they run on for a bit when I stop the dial in that event) everything does seem to get done with no dropped data that I've been able to detect.
However, a remark about a tool to find unused data triggers another tool idea we need, and that is a tool (I've hat in hand, begging) to compare the order of addf's, with the actual order of the data thru a processing chain. The idea being to spot un-intended delays in arriving at the finished, send it back to the machine data. Without having to spend a day capturing a rockhopper scan, feeding it into a posterizer to make it big enough to read, then printing those half a dozen (or more) 14x17 (yes, I have a printer that big) sheets, trimming them to splice and taping them up on half a sheet+ of plywood and tracing that. And of course its obsolete 1 minute after you hang it on the wall if you find an error. :( Good way to denude a forest... > ---------------------------------------------------------------------- >-------- Check out the vibrant tech community on one of the world's > most engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users Cheers, Gene Heskett -- "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> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
