On Wed, 08 Aug 2012 18:59:05 -0400, Kent A. Reed wrote: > On 8/8/2012 12:38 PM, Jon Elson wrote: >> jeremy youngs wrote: >>> admittedly Im no linux genius and pretty fresh to lcnc I have to >>> ask >>> can linuxcnc be drip fed ? and if so what would stop you from drip >>> feeding several machines from one server and have the synch all in >>> one >>> machine? I understand This post will show my ignorance but I am >>> thinking coding one machine as a master and providing synch from >>> that >>> should be easier than linking multiples together trying to synch >>> interrupts between several machines. just thinking >>> >> Drip feeding doesn't tell you when a machine is DONE performing some >> code. >> You would need to get a message back to tell you it is done. Drip >> feeding >> was used on old CNC controls with very limited memory. LinuxCNC >> has all of virtual memory to store code as it comes in, so it won't >> really >> work like drip feeding, the interpreter will suck up all the code it >> can and >> read ahead. I believe there is a mechanism where G-code can be sent >> via NFS or other method and then LinuxCNC can be ordered to execute >> it via emcrsh. >> >> Jon >> >> > > It seems there already exist a number of ways to establish > communication > to/from parts of LinuxCNC. > > However, at pain of sounding like a broken record, having these > communication capabilities is only a necessary condition, not a > sufficient condition, to accomplish the kind of shop-floor control > Viesturs seems to have in mind. There still needs to be an overall > plan > and design. This old Harris cartoon > http://star.psy.ohio-state.edu/coglab/Pictures/miracle.gif expresses > my > concern. > > Having a methodology, whether the RCS Methodology (see the Wikipedia > article I cite), or the older IDEFx approach the US Air Force banked > on, > or the newer Object-oriented Analysis and Design approaches (using > UML, > for example) that have been the darling of the software engineering > world for more than a decade, or just a simple but disciplined > scratching in a lab notebook, and honestly they are all trying to > accomplish the same thing, helps to avoid nasty surprises during > implementation not to mention helping to decide when it's done. > > It's not that I'm being a methodology zealot. It's just that I've > been > involved in the past in big systems-integration projects using > communications technologies ranging from IPC to CORBA to XMPP; I know > how much effort can be expended in a ready-fire-aim approach and how > brittle the resulting system can become as it goes through revisions. > > If planning isn't going to be done, then at least do a quick-n-dirty > implementation of the just basics to find out earlier rather than > later > what's been overlooked. > > On a personal note, I'm still struggling to understand possible use > cases. It seems to me that dealing with fault conditions in the > various > machines will be a particularly thorny issue.
maybe the original posters can give us several use case sceneries... The ones I can think of are: *) having a robotic arm loading parts onto a mill or router where the work envelop of the two machines overlap and have to coordinate to keep the arm from ripping off the head of the router... *) an automated rail-car system that loads pallets into a machine and needs to get feedback between the two machines. *) a multi gantry system where both gantries move on the same rail and can overlap. WHat happens when the two try to move into the same space? Do they simply stop and tell the user that there is an error, or does one figure out how to smartly move out of the way? === all of these can be coordinated with a single central processor telling which machines to operate between critical sections, but might be better done as cooperating between the machines. just some thinking out loud... EBo -- ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
