2011/10/20 Kirk Wallace <kwall...@wallacecompany.com>: > To take a more anti-NML approach, it > might be argued that extremely few EMC2 machines are in production > environments or even on a network. It seems EMC2 might benefit greatly > by optimizing it for a single computer/user hobby shop context.
I totally disagree on this point! I think that it is completely opposite! What is the area, where EMC2 would realize those great benefits? EMC2 already is great for hobby use. It is extremely flexible with existing components and modules. The definition of "hobby user" already implies that the cost of integration is more important than using machine at maximum efficiency. And EMC2 already can control almost any type of machine without any substantial cost of additional development. Additionally to that I seriously doubt that Michael's proposal of removing iocontrol will allow EMC2 to do things that it is not capable doing now. Maybe it will make it easier to configure and require 2 HAL lines instead of 4 or 5 lines in HAL file, but I do not see anything revolutionary here, compared to Michael's wonderful work on remapping g-code functions. With my recent experience of using EMC2 on advanced industrial machines - welding robot arm, 2-spindle special purpose wood mill and others, I have learned that EMC2 should take (also) the opposite route - back to its origins, where EMC was part of larger control system. Capability of synchronizing different EMC instances would provide substantial benefit in following ways: 1) it would allow using EMC in machines, where it cannot be used at the current moment, because of high number of joints or other reasons. In these cases integrators would inevitably need to tweak EMC thus helping to make it even better; 2) integrating EMC in such machines is commercial service thus allowing for a chance (speaking for myself and my intentions here) to hire a programmer for further improvement of EMC2. I know that there are companies that have based their CNC controllers on original EMC, but I think that separating away and giving their own name is a huge mistake as it creates fragmentation and hurts awareness of their target audience. That is the magic circle - the more awareness in audience, the more users thus more hardware producers (the number of producers of LPT breakout boards and other stuff for Mach is much larger than 2 producers of hardware for EMC - Mesa and Pico Systems), which leads to even better awareness and even more users etc. This applies to EMC2 and Mach - awareness of EMC is much worse than awareness of Mach. I have retrofitted several machines from Mach, because it simply is not capable of meeting the requirements for machine - use 2 independent THC sensors on plasma machine, independently control 2 spindles in milling machine etc. In all of those cases people look at me with large eyes and try to understand, what is that magic tool that can handle their machines. Even today I had a chance to introduce several more Mach users to existence of EMC2 and to 4 reasons, why I would never recommend using Mach; I am not the only one interested in using EMC on large machines, recently Aram inquired about synchronizing separate EMC instances. I am sure that there are others as well. 3) the more sophisticated and advanced machine controlled by EMC2, the more attention attracted from target audience and more people find out about existence of EMC2, thus helping to increase number of users and contributors. > On Wed, 2011-10-19 at 21:24 +0200, Michael Haberler wrote: >> It's just that I havent seen that work item on the EMC road map (ha!). >> Personally >> I'd prefer to work on something which there is consensus on that it's >> desirable >> to do, and get accepted provided its not broken. >> But at that point I'm in the dark here. >> > A few years back, I made a comment on how it seemed impossible to get > more than one person to collaborate on a shared goal. After prodding a > bit, I seem to recall the response I got was that each developer > preferred to work pretty much alone. I'd prefer to see more structure to > the project, but then I suppose that might take many people out of their > comfort zone and that is what a day job is for. It's a bit unnerving to > think that if a relatively few people decided that EMC2 wasn't fun > anymore, I could find myself with a shop full of CNC machines that won't > work, but it is what it is. I agree on this one! I am trying to earn my living by providing services of integrating EMC2 in different machines. With the help from user mailing list I have been able to solve different small issues, but there have been larger issues, that I have not been able to resolve due to lack of my own skills/understanding and lack of support from other developers. I mean the case of genserkins - I wanted (actually I still need that) to introduce support also for linear joints, but got stuck - it worked, but not really correctly and did not see the way to find the cause. The conclusion - every developer is working on their own things, which is good until the moment that it creates fragmentation, effort is invested, but not always the result is achieved due to lack of expertise of particular contributor (my case) or other reasons. I also feel that there is lack of direction. My proposal would be creating prioritized list of issues and then solving them in that order. I know that there is such thing as EMC board. I think that coordinating developers' effort would be the task of the board. Is that true? What is EMC board doing? Viesturs ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
