On 8/10/2013 6:45 PM, andy pugh wrote: > On 11 August 2013 00:32, Michael Haberler <mai...@mah.priv.at> > wrote: > >> Flatly, the idea of using locally generated serial numbers to tag a >> commands in a shared memory buffer and hoping for no collisions to >> occur was - to put it mildly - a lapse in design to start with. > > I can think of several ways to make that work, if that was a > requirement. For example MAC addresses are guaranteed unique (Well, > unless you deliberately spoof them) as is the process ID (locally) > of the creating process, so a hash of MAC, PID and local sequence > can probably be collision-free. > > Not that I am saying that that is sensible, necessary or wise.
Actually, I work with a design that uses tiny 8-bit fields for an autonomous command tag and it works just fine. There are never more than about 64 outstanding in-flight commands, and there's no delay in trying to synchronize between what is in essence two different timing domains. ...and the SCSI bus gets along quite well with 16 totally non-tagged in-flight elements. ...but I'm anxiously awaiting ZMQ and ring buffers, so I can start seriously hacking on the interpreter to motion/hal interface. This whole manual/MDI/Auto mode is beginning to drive me <ahem> bat-shit insane (pardon my french!), especially as I test out the older GUIs where it wasn't hidden quite so well as in Axis. I also fail to understand why I can't stop my gcode program, swap out filament, extrude a bunch (manually jog the A axis) to flush the hot-end, and start back up again. Yes, I've read the "motion while paused is hard" wiki page, but most of the bits mentioned aren't really hard. The _actual_ hard part mentioned in the wiki seems to boil down to two key features: 1) We can't properly manage the motion queue (ie: pause/flush/purge and repopulate) without getting all different kinds of confused 2) We can't run the gcode interpreter backwards (required to refill the flushed motion queue with new data reflecting updates to a tool offset or similar) The queue management issue is easy (well, as easy as doing any inter-process communications without creating race conditions and randomly occurring bugs, but that's a known/solved problem). Being able to run the interpreter backwards is IMHO the truly hard part, and if necessary I think it would be OK to cheat and just keep a bit of state around for the last N lines of gcode (or more likely the last N state changes for things like tool and coordinate offsets). -- Charles Steinkuehler char...@steinkuehler.net
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
