Those are nice looking vases. Are you sure it's not the Slic3r defect that is noted near the bottom of the thingiverse pages listed?
I have some nylon filament that is supposed to be dyable with RIT. I think that would make a nice print. On Mon, Aug 5, 2013 at 4:33 PM, Michael Haberler <[email protected]> wrote: > > Am 05.08.2013 um 18:29 schrieb Charles Steinkuehler < > [email protected]>: > > > Before I start seriously diving into debugging this, what is the > > expected behavior of LinuxCNC if the non-real-time task is starved for > > CPU and/or HDD bandwidth? Is it *EVER* possible for the non-RT code to > > 'skip over' any gcode? > > two thoughts: > > 1. a missed command (not sure how this can happen and go undetected, but > assume it does): assuming you have very linear gcode input (no subroutine > calls etc); what you could do is test for monotonically increasing motion > id in motion, and create a log message or wiggle a pin if there is a gap. > > 2. motion underrun: this is a situation where motion runs out of commands > for some reason, which might or might not be end of program (m2) or a queue > buster > > re 2: motion cannot tell, so it just stops: > http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/kinematics/tp.c;h=c115d91f85070733f84f3ea03aa45f491215f3c8;hb=cab03d760374d7e322d48c8190c8f590eeec86df#l688 > > you might want to trap that situation too, either through a debug HAL pin, > or a log message > > -- > > it is a fundamental flaw: what we need is a 'motion flow' or 'transaction' > concept which delimits a sequence of motion commands to be executed in one > go (meaning without underruns at the point above, except at end-of-flow). > These flows are produced by any sequence of RS274NGC commands between queue > busters (counting M2 ff and program start as queue busters). > > Each such flow needs a unique id tagging each motion command, or the flow > is bracketed with 'begin flow'/'end flow' commands. Only then motion will > be able to tell if it is a valid end-of-flow or an underrun which should > not have happened. Right now motion stops and afaict the situation isnt > reported. > > actually it might be sufficient to create 'end of flow' motion commands; > detection would work like so: any command except an end-of-flow, together > with the abovementioned underrun condition, will trigger an underrun event > (log, whatever). An end-of-flow clears the underrun flag. > > > - Michael > > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > > ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
