The only real problem with this is that no one is using RCS... for anything new. Of course, that might be an advantage.
A phased development 1 -- Implement the something new with a set of the same existing interfaces, so we have a parallel (RCS like) way of doing what we do now. 2 -- Implement some new, useful stuff using the new technology. 3 -- Gradually re-implement the stuff that uses RCS to use the new technology. 4 -- Pull out the old technology. Ken On 8/7/2012 5:29 PM, Michael Haberler wrote: > a few semi-related notes: > > I'd been looking into potential alternatives to the RCS/CMS/NML code in > Linuxcnc for different reasons: > > - the restrictions are substantial: fixed message size, a very limited > interaction model (no really usable remote procedure call, no > publish/subscribe interaction, an arcane approach to serialization, remote > command injection etc) > - a really distibuted solution should address sharing HAL information across > machines just alike, not just NML messages with ad-hoc HAL contents copied > around at the C level > - it should support late binding, i.e. contents of messages defined at > runtime (no need to recompile because some field/HAL bit is added) > - it should support easier and mostly autogenerated binding to at least Python > - the current NML code is C++-based and hence not kernel-compatible, which is > an issue at the userland/RT component boundary (message transcoding required, > eg. in src/emc/motion/usrmotif.c) > - the current code is substantial, but only a minimal part of the > functionality is currently used, and knowhow on it is scarce > - the current coding style, and mode of use encourage a piecemeal migration > to a single machine model (shared filesystem assumed, poor distribution > options etc), which is somewhat driven by the NML framework's limitations > - some recent ideas about a future linuxcnc structure would suggest a more > close interaction of interpreter ad realtime modules, which has repercussions > on the communications framework, and it is unclear to me whether NML will be > on the help or issue side > > this is btw a very similar laundry list like realtime middleware used e.g. in > stock market transactions, like Tibco Rendezvous > > the best list of candidate components I could find was: > > - zeromq as messaging framework > - status distribution by reliable multicast (openpgm, already integrated in > zeromq) > - google protobuf for message coding/decoding and language binding > - nanopb, a RT-module compatible protobuf library (if one were to use a > unified message format from wire down to RT/userland comms) > > A showstopper is licensing - zeromq is GPLv3 and I understand that excludes > its use in linuxcnc > > -- > > I'm writing this up because it might help someone looking for suitable > components. > > Other than that, it's a thought experiment, not a proposal, and no pending > patch if you will. > > - Michael > > > > > > > Am 07.08.2012 um 21:38 schrieb Viesturs Lācis: > >> 2012/8/7 Kent A. Reed <kentallanr...@gmail.com>: >>> 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"? >>> >> Yes. I still do not know for sure the answer to this question. >> Because I have never seen any system like that, so I have no idea, how >> exactly do they work and I do not want to reinvent the wheel. Can >> anyone share some information or screenshots, what do those existing >> solutions have? What are they capable of? >> >> I guess that in my case requirements could be limited down to this >> list (actually second point alone would do): >> 1) load a separate g-code file for each separate LinuxCNC station and >> separately execute them - this would actually be a remote control with >> several machine being controlled from one GUI; >> 2) upon pressing some button/changing a tab or whatever, make all the >> stations execute one g-code file - this would require modified >> interpreter and non-standard g-code to exceed current number of axis >> words and some additional commands in the middle of the code that >> would put each station on pause and then resume, when all stations >> have reached this "pause" command. I guess that non-standard code is >> not biggest issue, because those machines either run one code for a >> long time (so it is worth spending some time to prepare code) or they >> receive the commands "almost on the fly" from another application; >> >>> Whatever this means, there has to be software written to implement it, >>> and the NML communications is only a small part of that implementation. >> Yes, that is why I am now looking for a programmer. >> >>> If you know CORBA the situation with RCS is analogous. >> Sorry, this is first time I hear about it :)) >> >> >> 2012/8/7 Joachim Franek <joachim.fra...@pibf.de>: >>> >>> Have a look to >>> http://www.orocos.org/orocos/applications/krypton >> BTW today I was pointed to this page: >> http://www.proview.se/v2/ >> >> That seems one very attractive application. And it runs on Linux. And >> it is opensource. >> >> -- >> Viesturs >> >> If you can't fix it, you don't own it. >> http://www.ifixit.com/Manifesto >> >> ------------------------------------------------------------------------------ >> 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 > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
