Hi I'm nearing the end of building a DIY gantry router. The router I'm using has soft start, so takes several seconds to come up to speed. I realise I could add dwell commands to the G-Code, but is it possible to add a fixed dwell to Linux CNC after spindle start.
From reading other posts I see that HAL has a spindle-at-speed input that is intended to be used with encoders, but could it be used with a timer? Mike On 22 Apr 2012, at 00:12, charles green <[email protected]> wrote: > optimum value for planning ahead for a possible stop or maximum acceleration > change: take current feed for current block and maximum possible accel of > machine to get distance required for stop. then next N blocks that cover > that distance, and apply appropriately modified feeds to them. > > think of a gcode file as a matrix, each row would correspond to a block, the > first several columns are all the various gcodes, the next several are all > the various x1..xn axes, then several columns covering offset vectors, feeds, > spindle, various Ms, etc. then just tack on another column that is the > achievable feed. when file is loaded to controller, it gets scanned to fill > in the values in the actual feetrate column. maybe there is another similar > column for actual spindle speed that gets filled in similarly, in case it's > being used like a c axis to get coordinated revolution. > > at program execution, the calculated realistic values columns are used to > generate motion. soft program stops during execution may run out a few > blocks. estops are an emergency situation, so who knows.. single stepping > is usual one line check based on stop at end of block. > > are there not already some 'hidden' columns x1'..xn' that result from cutter > radius compensation? > > i guess i'm thinking of linear programs, so in the case of loops and > subroutine calls, the end result is a much longer list of actually executed > blocks. maybe it never ends (= bad gcode). probing would also not fit the > scheme very well - maybe consider probing blocks to be bounded in the code by > stops? or, what if there were choices between more flavors of operation: > advanced lookahead flavor would not allow nuts in it like conditional loops > or surprise probings; crazy probe scanner routine mode wouldnt have the > texture advantage of nice feedrate smoothness. > > > > --- On Sat, 4/21/12, Viesturs Lācis <[email protected]> wrote: > >> From: Viesturs Lācis <[email protected]> >> Subject: Re: [Emc-users] Trajectory planning and other topics from a >> EMC(LinuxCNC) newbie (TheNewbie) >> To: "Enhanced Machine Controller (EMC)" <[email protected]> >> Date: Saturday, April 21, 2012, 12:58 PM >> 2012/4/21 Jon Elson <[email protected]>: >>> >>> The real problem I see is that RATIONAL G-code that was >> correctly written to >>> perform a particular operation cannot be executed as >> fast as the machine and >>> drives COULD allow it to go, due to the stop on next >> block requirement. >> >> I agree. >> What I see the big issue for solving this in trajectory >> planner or >> whatever _inside_ LinuxCNC is that I do not see, how to >> determine by >> some hard facts, what is the best way to determine the >> lookup amount. >> Certain number of lines or a certain travel distance? Ok, >> when the >> method is chosen, how to determine, what is the optimum >> value? >> >> That is why I am in favor of adding a separate filter, which >> would >> take the code and rephrase it to what is really in there - >> either arcs >> or splines/nurbs. In this case the file would be processed, >> when >> loaded (I have not really understood, when it would be >> processed in >> the first variant - also on loading or on the fly, when it >> is >> executed), so it definitely would not affect realtime >> performance, >> because the file would not be executed at that time. I think >> that >> waiting 10-20 seconds for the PC to recalculate the path and >> find, >> what curves would fit the existing profile, defined by tiny >> G1s. >> >> Viesturs >> >> ------------------------------------------------------------------------------ >> For Developers, A Lot Can Happen In A Second. >> Boundary is the first to Know...and Tell You. >> Monitor Your Applications in Ultra-Fine Resolution. Try it >> FREE! >> http://p.sf.net/sfu/Boundary-d2dvs2 >> _______________________________________________ >> Emc-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-users >> > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
