On Sun, 22 Apr 2012 07:25:26 +0100 Mike Bennett <mjb1...@gmail.com> wrote:
> 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 <xxzzb...@yahoo.com> 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 <viesturs.la...@gmail.com> > > wrote: > > > >> From: Viesturs Lācis <viesturs.la...@gmail.com> > >> Subject: Re: [Emc-users] Trajectory planning and other topics from > >> a EMC(LinuxCNC) newbie (TheNewbie) To: "Enhanced Machine > >> Controller (EMC)" <emc-users@lists.sourceforge.net> Date: > >> Saturday, April 21, 2012, 12:58 PM 2012/4/21 Jon Elson > >> <el...@pico-systems.com>: > >>> > >>> 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 > >> G4 P <delay> is meant to delay movement while the spindle gets up to speed. Dave > >> ------------------------------------------------------------------------------ > >> 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 > >> Emc-users@lists.sourceforge.net > >> 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 > > Emc-users@lists.sourceforge.net > > 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 > Emc-users@lists.sourceforge.net > 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
