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. Regards, Kent ------------------------------------------------------------------------------ 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
