wouldn't those patents be long expired? sam On 05/16/2013 12:04 PM, Dave wrote: > Are there any possible patent infringement situations that could result > by cloning Fanuc's CNC machine coding style entirely?? > I wonder if Haas and others pay any type of licensing fees to Fanuc? > Art Fennerty of Mach3 fame told me one time that he altered something > within Mach3 as an attempt to steer clear of Fanuc. > I don't remember what it was, and it was many years ago when we met at > one of the original CNC workshops at Cardinal Engineering. > > Dave Cole > > On 5/16/2013 12:14 PM, David Bagby wrote: >> Hi, >> I've been reading and thinking about this thread; I'd like to offer up >> my 2 cents worth - >> >> I have interest in making LCNC as easy to adopt and use as possible. >> This interest has lead me to I've spend a fair amount of time thinking >> about what aspects of LCNC assist or hinder LCNC adoption. >> >> Gcode syntax and semantics (S&S) is an aspect of a CNC system that falls >> into the "External interface" category. The S&S are important as this is >> a primary CNC control interface used by other entities. In particular, >> GCode is a primary interface between LCNC and the rest of a CNC >> machining "ecosystem". >> >> There are significant advantages to be gained from going with an >> existing, established, market dominate standard. Doing so for gcode S&S >> makes an adoption decision for LCNC easier, as it leverages things in >> the rest of the CNC ecosystem. For example: if LCNC implements Fanuc >> gcode S&S, then existing CAM program output is instantly compatible with >> LCNC (no special LCNC specific post processor is required). >> >> I assert that taking a larger system view (more than just a LCNC >> internal viewpoint) of the adoption costs for LCNC, and striving to >> lower the overall "LCNC cost of ownership" is good for LCNC adoption. >> >> As such, I think it would help LCNC's adoption if the dialect of Gcode >> that LCNC implements is as close as possible to an existing gcode standard. >> Here the word "standard" is a tad fuzzy, but not so fuzzy as to be a >> significant problem for this discussion. >> In this case, the obvious (defacto) "standard" here is the Fanuc >> implementation of Gcode. (Yes, I realize that there are (relatively >> small) variations in gcode S&S within the fanuc product line and that >> some details have evolve over time. That level of detail is not germane >> to the general point I am trying to convey). >> >> Side bar: The secondary, less influential defacto gcode standard choice >> would be Haas' gcode dialect. Given that LCNC is already "fanuc >> flavored", switching horses to Haas would seem to be more work for less >> leverage. Nor do I think it worth considering "establishing a competing >> standard" as LCNC does not have the required market clout for that type >> of activity. >> >> I believe that the benefits from implementing "standard fanuc gcode" far >> out weigh any internal LCNC implementation considerations. Thus when I >> read (paraphrasing) that the Fanuc lathe tool change "style" is hard to >> fit into the LCNC tool table "framework", my immediate conclusion >> appears to be different from that of some folks; To me that means we >> should improve the LCNC tool table structures to support the Fanuc gcode >> S&S goal. This is another way of saying that I don't think that existing >> internal LCNC data structures should be the restricting factor that >> determine gcode S&S (to me that's the tail wagging the dog). >> >> Having expressed the above, I'd like to turn to a related aspect of the >> conversation. >> I've sensed that there may be some thinking that LCNC is trying to, or >> should, implement "one gcode language dialect" that runs many machines. >> It appears this is implicit in the comments along the lines of "we can >> still use G43 Hx to do thus and such". >> >> For better or worse, industry treats Mills and lathes as significantly >> different animals. In the fanuc world there is NOT a single "gocde >> syntax" that is used for all machines. WRT to mills& lathes there is a >> "mill gcode S&S" and a "Lathe gcode S&S". While they have some >> overlapping gcode words, these two Gcode dialects are generally used >> orthogonally. >> >> Again, I think it would serve LCNC well to follow this industry practice >> - as this gains the most ecosystem leverage. >> >> Conceptually, we can think of the Gcode interpreter of a CNC system as a >> swappable module. >> (While swapping out the entire interpreter is technically difficult >> today with LCNCs "non-modular" internal structures, conceptually it >> seems the right approach.) >> >> Thus we should think of LCNC as running either a mill gcode interpreter >> XOR a lathe gcode interpreter. Both the tool change syntax and the >> semantics are fundamentally different and incompatible between these two >> interpreters. WRT to tool changes I suggest that one think of mill/lathe >> more like English/Spanish than LA/New York accent differences. IMHO, >> attempting to intermix the different tool change S&S m within the same >> interpreter is asking for trouble and confusion. >> >> When using the lathe interpreter, tool changes should only be and are >> done using lathe S&S. In this case Txxyy. Any attempt to use mill S&S >> (G43 Hx) should be treated by the lathe interpreter as a syntax error. >> Conversely, when running the mill interpreter, all tool change S&S are >> Tx M6 G43 Hy etc - and any attempt to use Txxyy should result in a >> syntax error. >> >> Finally, I'd observe that people who directly write gocde are a rare and >> vanishing breed. These days gcode is much more a program to program >> interface than it is a human to control interface. Existing gcode >> dialects do the job and there is no significant interest in, or adoption >> of, the alternatives that have been proposed over the years. This >> economic fact of CNC life is why inventing clever new gcode abilities >> (usually at the cost of being "non-standard" gcode) is generally ignored >> by the market. There is simply not sufficient economic incentive to >> materially "improve" gcode. >> >> Thus I have concluded that the best course is to simply target, >> implement and support fanuc gcode S&S. >> >> We can then expend our available energies on other aspects of LCNC >> package where a better ROI is possible. >> >> Dave >> >> ------------------------------------------------------------------------------ >> AlienVault Unified Security Management (USM) platform delivers complete >> security visibility with the essential security capabilities. Easily and >> efficiently configure, manage, and operate all of your security controls >> from a single console and one unified framework. Download a free trial. >> http://p.sf.net/sfu/alienvault_d2d >> _______________________________________________ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers >> >> > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers >
------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
