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
