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
