Thanks for looking. (I am not that technical though..) The bit of ladder I have seems to be taking longer than 1ms though. (on this atom330 board)
sam On 02/06/2012 06:02 PM, Chris Morley wrote: > > >> >> >> On Fri, 03 Feb 2012 13:05:02 -0600 >> sam sokolik<sa...@empirescreen.com> wrote: >>> All this talk of lowering the servo thread had me thinking back to when >>> I was setting up the K&T. I wanted to try to lower the servo thread for >>> testing. I could not go much slower the the 1ms default or I would get >>> real time delays. After some consultation on irc - it was decided that >>> the ladder was the issue. I gave up and left my servo thread at 1ms. >>> >>> My ladder does tool chain logic, tool changing, pallet transfer and a >>> few other odds and ends. It has probably over 16 sections and quite a >>> few rungs. when the section display is open - the upper right hand >>> corner has the scan time - it is 135us. vs the classic ladder sample >>> in the sample configs (pretty much just estop logic and oiling) which >>> runs in 17us. >>> >>> I have a older atom330 board here that I am playing with. On a side >>> note - here is the latency test without isolcups=1 >>> http://www.electronicsam.com/images/KandT/testing/atomnonisolcups.png >>> >>> with isolcups=1 >>> http://www.electronicsam.com/images/KandT/testing/atomisolcpus.png >>> >>> I put the classic ladder parts into the emc stepper_inch config from the >>> sample configs (emc version 2.4.6) fresh install from the livecd then >>> updated. I removed the base thread and stepgen functions from the threads. >>> >>> here is the config. >>> http://www.electronicsam.com/images/KandT/testing/stepper/ >>> that has my ladder in it (just running - none of the pins are >>> connected) This is ladder from sometime in the distant past - I am sure >>> it isn't the latest ladder. >>> >>> Now - on this atom - it will not run at 1ms. It seems to run at >>> .909khz. (servo period 1100000) The K&T is using a asus motherboard >>> and amd processor. (don't remember exactly but it is quite a bit more >>> powerful than the atom) The atom board will run the sample ladder logic >>> down to about 5khz. >>> >>> So - the ladder isn't that intense - does classic ladder just take that >>> much time? Is there another issue? am I making any sense? :) It seems >>> to me if I made a much larger ladder - it might stop running on the K&T >>> computer... >>> >>> sam >>> > from the source file module_hal.c: > > void HalWriteFloatOutputs(void) { > int i; > for( i=0; i<InfosGene->GeneralParams.SizesInfos.nbr_phys_float_outputs; > i++) { > *(hal_float_outputs[i]) = ReadVar(VAR_PHYS_FLOAT_OUTPUT, i); > } > } > // This actually does the magic of periodic refresh of pins and > // calculations. This function runs at the period rate of the thread > // that you added it to. > // period, leftover, t0,and t1 are in nanoseconds. > // This function first checks to see if at least 1 millisecond has gone by > // if the period is under 1 MS then if will not refresh rungs yet but > // will keep track of how many NS were left over. Does this each period > // till at least 1 MS has occured, if more then 1 MS then keeps track of > // leftover NS for accuracy. Bottom line is you can run classiclader in > // a thread faster than 1 millisecond but it will not refresh the rungs > // any faster (it can be slower though). If your refresh is too slow and > // your timer are using multiples of 100 microseconds they might not be > accurate. > // t0 and t1 are for keeping track of how long the refresh of sections, > // and HAL pins take (it is displayed in the 'section display' GUI (in > microseconds). > > static void hal_task(void *arg, long period) { > unsigned long t0, t1,milliseconds; > static unsigned long leftover=0; > leftover += period; > milliseconds= leftover / 1000000; > leftover %= 1000000; > > if (milliseconds>= 1) { > InfosGene->GeneralParams.PeriodicRefreshMilliSecs=milliseconds; > *hal_state = InfosGene->LadderState; > t0 = rtapi_get_time(); > if (InfosGene->LadderState==STATE_RUN) > { > HalReadPhysicalInputs(); > > HalReads32Inputs(); > > HalReadFloatInputs(); > > ClassicLadder_RefreshAllSections(); > > HalWritePhysicalOutputs(); > > HalWrites32Outputs(); > > HalWriteFloatOutputs(); > } > t1 = rtapi_get_time(); > InfosGene->DurationOfLastScan = t1 - t0; > } > } > > later the duration of scan (in nano seconds) is divide by 1000 to display > micro seconds > which fit better in the display. > > I believe the idea of limiting the minimum refresh to 1 millisecond is so it > is difficult > to set a refresh rate that is shorter then the duration rate. > > Maybe there is a better idea? > > Chris M > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
