>He upset me when he began bragging that > he had fixed a number of bugs without noting that the code he had used > was experimental rather than released. His followers latched onto that > implying that EMC was not well thought out or executed. When we asked > where these bugs were located, he was unable or unwilling to point to > any specific sections.
So, that gives us the opportunity to *BRAG* about Artsoft MACH3 *BASED* on EMC2! Why not to use it in counterstrike? On Sat, Nov 22, 2008 at 3:07 PM, Ray Henry <[EMAIL PROTECTED]> wrote: > > There seems to be a deliberate lack of clarity with this whole > proprietary v gpl/lgpl stuff in this thread. It's not that the > developers are incorrect but more incomplete. You should consider this > post to be my opinion and a near rant and you might want to stay away. > > > On Sat, 2008-11-22 at 05:46 +0000, Chris Morley wrote: > >> That means they are somehow connected to EMC2. > > Yes they are and they connect both through NML and halcmd, which is a > bit like dialing up your friends on a conference call and talking. Most > of what is happening is exactly what the use of NML (Neutral Messaging > Language) does for us. It allows multiple graphical interfaces -- as > long as those interfaces use NML status structure calls rather than > making assumptions about the state of EMC based on something done within > that GUI. (AXIS did a bit of this early on as did Mini.) NML allows > proprietary systems to develop NML messages and send and receive them in > a system neutral way. > > There are two Tcl/Tk based extensions to Tcl's wish shell that connect > between a Tcl/Tk based program and the NML channels. The original, > written by FredP at NIST is emcsh. It is commonly run on a single > computer with the rest of EMC2. The second is the remote system emcrsh > that was written by EricJ and described in his documents at > http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emcrsh > I use emcsh for most all of my connections to NML and don't see any > significant loss of computer ability because of the extra messaging. > Even at 20-50 loops a second the cost is trivial and is all on the user > side of things rather than the rtai side. > > Now if you prefer not to use Tcl/Tk, a similar library of NML message > classes could be developed for other languages. In fact, a set of Java > and/or C++ NML message classes can be autogenerated using a system > maintained by WillS at NIST. > > If you prefer writing these classes in a pristine clean room way you > could study the public domain code from EMC and write the additional > codes that have been added to EMC2 to provide additional functionality > -- if you need these. This pristine authorship of a QT4 library is what > Smithy did. (See the last paragraphs of my post for additional thoughts > on Smithy and Synergy.) > > Adding the use of HAL messaging is another issue that may need a bit of > legal clarification. My memory is foggy these days but I think that the > intent of the LGPL licensing of the source that makes up halcmd was that > it should allow a proprietary system to send properly formed, plain text > commands to halcmd. Most of the functionality desired for SheetCam/EMC2 > would not require direct HAL connections. Again Smithy uses a > connection to Halcmd for a couple of signals. > > As for talking with the coordinate systems, tool offsets, or HAL > configuration, those are simple stand-alone files that can be > manipulated apart from EMC and their current values updated using NML > messages. I know that some developers frown on this and want a single > funnel between EMC2 and these files but .... If you're a software > author and can figure out a bulletproof way of handling these things, > why not. The Smithy folk, along with the Synergy folk wrote code to > read certain blocks of a gcode file when it loads it and sets up its > tool table to conform to the tools defined during the Synergy part > drawing process. > > Smithy met with a major share of the EMC2 developers during fest year > before last and described what they wanted to do. Smithy offered to > LGPL their QT library and make it available to others when it was > completed. I don't believe that a formal vote was taken to either > support or work against that implementation at that meeting. Recently, > Smithy offered their part of the GUI to the developers and are willing > to place appropriate licenses on those files. > > Some of the Synergy code included in the EZ-Trol is not open and never > will be. You can cobble together much of the EZ-Trol ability by > downloading Synergy Lite and the Smithy part of EZ-Trol (when the > developers accept it) but you will not be able to build a complete > system until you pay the Synergy license. > > This whole license BS is designed and furthered in this thread to try to > obfuscate truths and scare folk away from EMC2. If I were to add a > "Copyright 2008 All rights reserved. Raymond E. Henry" to this post, you > would be forced to honor that regardless of the nature of the software > code used to prepare, transmit, route, or receive this post. TALKING > WITH MOST OF EMC2 is no different. Running a gcode program through EMC2 > to a machine does not make that gcode open. Opening a set of NML > channels does not infect the software or device that has done that. > > HTH > > Rayh > > BTW -- I was the conduit between Tom Kramer, the author of the EMC > interpreters and Artsoft. I asked Tom for the set of files for the new > interpreter that he was working on so that I could test and comment. He > permitted me to share them with Art. > > Those files would eventually have to be released into the public domain > because they were a work done by a USA federal employee. They were not > complete but Art wanted them anyway. There was NO expectation that he > would return his modifications. He upset me when he began bragging that > he had fixed a number of bugs without noting that the code he had used > was experimental rather than released. His followers latched onto that > implying that EMC was not well thought out or executed. When we asked > where these bugs were located, he was unable or unwilling to point to > any specific sections. > > Artsoft's use of EMC code was not the trigger for GPL licensing. It is > the belief of most of the developers that we are a community freely > sharing our work with each other and ask only that those modifying or > extending our work do the same. > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
