On 8/6/2012 2:26 PM, Viesturs Lācis wrote: >> >Can you share with us what you have in mind? > I have a potential client that is building large machines and I would > like to take over the part of controlling their machines. > It is serious money involved and their existing control guys will do > whatever it takes to convince everybody that my solution (read: > LinuxCNC) is worthless, so I need a working example as a proof of > concept. And only then_maybe_ I will be able to convince them and get > at least a pilot project with them. > > I do not have problem of getting 2 or 3 small machines to be > controlled by LinuxCNC. What I need is to synchronize them, so that > they work all together.
Viesturs: Of course this problem will look different to different people, but to me connecting a LinuxCNC-controlled machine (whether small or large) to some other software component via NML is the easy part. The question you have concerning the compatibility of versions of LinuxCNC with RCSlib seems to me easy to answer with a few tests and any problems that arise seem to me likely easy to resolve. The bigger picture is still very fuzzy and hence harder to answer. What does it mean "to synchronize them, so that they work all together"? Whatever this means, there has to be software written to implement it, and the NML communications is only a small part of that implementation. If you know CORBA the situation with RCS is analogous. One defines a set of messages (in IDL for CORBA; in NML for RCS). This set is then passed through some software which generates code stubs in C/C++, java, whatever. Programmers then have to create all the code beyond the stubs, taking advantage of the libraries provided. The RCSLIB routines don't substitute for most of the RCS applications programming any more than the CORBA libraries substitute for most of the CORBA applications programming. They just ensure the interfaces between modules function correctly. Regards, Kent PS - taking an RCS-centric view Essentially all of the works published about RCS are available in some form on the internet and I won't try to list any here. As a teaser, though, look at the wikipedia article http://en.wikipedia.org/wiki/Real-Time_Control_System Note especially the first figure that shows an RCS view of an advanced machining workstation. The last sentence in the figure caption says "These modules are richly interconnected to each other by a communications system." The arcs in the graph in this figure represent NML communication paths. It is these arcs and their connections to the nodes (the modules) that the RCSLIB helps one create. The last paragraph in the Overview states, "[s]ystems based on the RCS architecture have been designed and implemented to varying degrees for a wide variety of applications." It is this "designed and implemented" that is left for you to do. There is no magic in the RCSLIB that makes this a trivial task. Under History/RCS-2 in this wikipedia article, note the end of the second paragraph and beginning of the following paragraph: "RCS-2 was used to define an eight level hierarchy consisting of Servo, Coordinate Transform, E-Move, Task, Workstation, Cell, Shop, and Facility levels of control. "Only the first six levels were actually built...." I think it can be argued that LinuxCNC (plus G-code programs) fulfills the first four, possibly even five levels of this hierarchy (to me the problem of matching level to level is akin to the problem of matching TCP/IP against the OSI communication model). This would mean that you are trying to add one or more levels which places you right at the horizon of what has been accomplished with RCS in factory applications. I don't want to discourage you from thinking about the coordination of multiple workstations. I just want to impart a sense of the amount of work to be done if you envision the kind of deep integration that was accomplished in the Advanced Manufacturing Research Facility. The section RCS Methodology in the same wikipedia article gives an idea of how much of this work has to be done up-front just to design the control system properly. PPS - It is possible you have in mind a much simpler system which monitors and reports on multiple machines rather than actively sensing and controlling them. In this case, I suspect you could short circuit much of the RCS planning process. As an extreme example, see the MTConnect activity (www.mtconnect.org). ------------------------------------------------------------------------------ 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 Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
