Re: [Emc-developers] custom EDM configuration questions
Am 04.02.2013 um 08:25 schrieb Chris Morley: Sure, you can say an EDM will never make a spindle synchronized move, but changes to the motion module need to do sane things regardless of what kind of a machine is being controlled. What about different motion modules optimized different classes of applications? Yes Peter I think your on the best track. Unfortunately that's a big chunk of code to try and understand to change it. I wish there was some way to write down the flow of linuxcnc and keep it current. It's like walking in the dark with a plain sheet of paper as a map :) I fully agree. A good start would be for instance to make the trajectory planner (tp/tc) a module like kinematics. The upside would be an easier path to exploring different trajectory planners, for instance Yishin's; that is kind of hard to integrate into the current monolithic blob, without duplicating the code or using conditional compilation or execution, which would just add to the 'huge blob' problem. this requires abstracting, or removing two RT/non-RT layer transgressions in tp/tc where it hooks into emcstatus for CSS and spindle-synced moves, but given the original base code is very well designed and encapsulated, it is a contained effort. I would think something similar could be done for spindle handling. If it is possible to modularize a linux kernel such that it is basically a module-loading skeleton with minimal supporting code, then this should be possible for motion too. -- that is structural rework with no immediate upside, and I have the impression such jobs with longer-term impact are fairly off-the-radar as opposed to the eternally popular shortest possible fix. At least I dont see much of it. - Michael Chris M -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On Feb 4 2013 1:45 AM, Michael Haberler wrote: Am 04.02.2013 um 08:25 schrieb Chris Morley: What about different motion modules optimized different classes of applications? Yes Peter I think your on the best track. Unfortunately that's a big chunk of code to try and understand to change it. I wish there was some way to write down the flow of linuxcnc and keep it current. It's like walking in the dark with a plain sheet of paper as a map :) I fully agree. A good start would be for instance to make the trajectory planner (tp/tc) a module like kinematics. The upside would be an easier path to exploring different trajectory planners, for instance Yishin's; that is kind of hard to integrate into the current monolithic blob, without duplicating the code or using conditional compilation or execution, which would just add to the 'huge blob' problem. this requires abstracting, or removing two RT/non-RT layer transgressions in tp/tc where it hooks into emcstatus for CSS and spindle-synced moves, but given the original base code is very well designed and encapsulated, it is a contained effort. I would think something similar could be done for spindle handling. If it is possible to modularize a linux kernel such that it is basically a module-loading skeleton with minimal supporting code, then this should be possible for motion too. -- that is structural rework with no immediate upside, and I have the impression such jobs with longer-term impact are fairly off-the-radar as opposed to the eternally popular shortest possible fix. At least I dont see much of it. LinuxCNC-3.0 then as a design philosophy? EBo -- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On Feb 3 2013 11:58 PM, Viesturs Lācis wrote: 2013/2/4 sam sokolik sa...@empirescreen.com: Oh - and this is kinda interesting... http://www.youtube.com/watch?v=eTLs89YPtck Follow and translate the link in the description.. (interesting hack..) If anyone needs translation from Russian: The way this works is a g-code filter, which generates a reverse g-code for a particular g-code line and inserts it _before_ this particular g-code line with a / symbol in front of it. It seems like a change in Axis GUI script to redefine zoom-in and zoom-out buttons, so that it starts taking into account all the lines with / symbol in front of it, when asked to reverse. A little comment from me: It is obvious that this approach can easily reverse _current_ line being executed. But it is not clear to me, how to back up more than one line - it might be necessary if the code consists of really tiny G1 moves. I think multi-line is doable with stack and maybe adding an internal interrupt (in that code only) which incerts another command just like it did whenver it reaches the end of a reversed move. Then when it moves forward it puts the next command on the stack in place until it is once again empty, then it continues normal execution. I do not have time to really crawl into his code, and have the following question that I could see as being a problem: Can a long move be interrupted and reversed? If so, how does it handle the deceleration? EBo -- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
Am 04.02.2013 um 10:25 schrieb EBo: On Feb 4 2013 1:45 AM, Michael Haberler wrote: Am 04.02.2013 um 08:25 schrieb Chris Morley: What about different motion modules optimized different classes of applications? Yes Peter I think your on the best track. Unfortunately that's a big chunk of code to try and understand to change it. I wish there was some way to write down the flow of linuxcnc and keep it current. It's like walking in the dark with a plain sheet of paper as a map :) I fully agree. A good start would be for instance to make the trajectory planner (tp/tc) a module like kinematics. The upside would be an easier path to exploring different trajectory planners, for instance Yishin's; that is kind of hard to integrate into the current monolithic blob, without duplicating the code or using conditional compilation or execution, which would just add to the 'huge blob' problem. this requires abstracting, or removing two RT/non-RT layer transgressions in tp/tc where it hooks into emcstatus for CSS and spindle-synced moves, but given the original base code is very well designed and encapsulated, it is a contained effort. I would think something similar could be done for spindle handling. If it is possible to modularize a linux kernel such that it is basically a module-loading skeleton with minimal supporting code, then this should be possible for motion too. -- that is structural rework with no immediate upside, and I have the impression such jobs with longer-term impact are fairly off-the-radar as opposed to the eternally popular shortest possible fix. At least I dont see much of it. LinuxCNC-3.0 then as a design philosophy? I would rather call it sheer necessity in some cases, although individual perceptions of urgency obviously differ. For instance, I dont think broadening the base of RT operating systems, or removing the 'everything on one CPU' limitation requires a lot of philosophical thinking; it is rather 'what is the minimum to be done asap from preventing this project from keeling over'. That is why I postponed from working on LinuxCNC3 grand visions until the RT OS stuff is done. Of course there's always an alternative, the bits dont go away - keep scavenging hardware which somehow, in some way fits the current operations model. That is a dwindling option afaict, nevermind some of the more bizarre limitations attached. - Michael EBo -- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On Feb 3 2013 10:21 PM, TJoseph Powderly wrote: EBo, your name rings a bell all the way back to Paul Corner EMC days, you been arounf here a long time i think Yes. Paul's nastiness is why I completely disengaged from EMC for a *very* long time. It was the type of two faced - stab you in the back - interaction that the culture I come from tolerates a lot less than a literal punch in the face. Interestingly enough I was being funded to work on EMC at the time, and could have focused on it 40+ hrs/wk, and the kerflufle caused me to just walk away... If that history bothers you, I can easily bow out permanently. ... this constant velocity is totally unsuited to EDM, the finaly mechanical driving element better to jiggly and nervous, else it aint repecting the process uncover the final gear or screw on any real working edm and watch, it approaches a smooth forward motion but IS jiggly and nervous. ... The EDM head I wanted to prototype, based on a some old work I saw once, has the jiggly portions controlled via analog circuitry in an internally closed-loop. All I would need it to do is either output a pause, or an analog feedback that basically adjusts the speed overide from where the user sets it down to 0 (full stop). That way it should be able to fully integrate into LinuxCNC. BTW, I should add, that the EDM head I am talking about is a sink type, and is self retracting a very small distance, but all of that is handled by the head. That is how the current V/C feedback is maintained. mydynac repairs cnc edm for a group in sugar grove illinois 'edm network' owned by Ron Vogel ( iirc) the work done more recently by Scott Haase in WI can reverse and is limited to an upper and lower bound (same as mine) his uses O-word gcode, mine is hal based ( limits sets by mcodes, and motion implemented thru 'offset' hal component ) his o-word may be easier to debug, dunno, but for immediacy, hal should prove mpre responsive because its 1 less layer of control If I can find an old wire fed, or other industrial EDM, then I can see spending a lot of extra time on a project like this. and for the edm gap voltage - arduino - threshold comparison - hal - motion loop of Mr Haase well there many layers removed by directly connecting a window comparator to a hal 'offset' comp If I do the arduino thing, it will be completely independent of LinuxCNC and not an addition to it. I have some experimental code I wrote over a decade ago, when I was taking PhD level courses in Computer Aided Geometric Design, which converts standard G-code into an abstracted motion splines. The intent was to eventually implement the low level as a NURB, but started with Bezier splines because I had several implementations of them at the time. Part of that design was to incorporate a fully runtime polymorphic parser (which allows you to overload things like how comments were handled and different interpretations of the g-coded standards -- which allows you to run very old g-code for a machine without modification on a more modern machine/retrofit). All of the last part could also load user definable modules at startup, so you would not have to recompile/reconfigure the program to use different constructs. Anyway, I let that effort fall by the wayside... out of sequence the idea of orbitining is to use the distance moved away from the 'roughing point' to feed a sine and cosine generator and use that value to move XY along the surface of a circular cone. As the Z motion increases, the circle increases ( and drops ) if the process sees a redcuced input signal , ALL axis collapse to the that 'roughing point'. I will have to think on this. I can see that it could be used to produce a similar effect to adaptive clearing (and share the tool ware over a much greater area). For the moment I have no interest in this, but I can see the benefit of the functionality. EBo -- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On Feb 4 2013 2:58 AM, Michael Haberler wrote: Am 04.02.2013 um 10:25 schrieb EBo: LinuxCNC-3.0 then as a design philosophy? I would rather call it sheer necessity in some cases, although individual perceptions of urgency obviously differ. For instance, I dont think broadening the base of RT operating systems, or removing the 'everything on one CPU' limitation requires a lot of philosophical thinking; it is rather 'what is the minimum to be done asap from preventing this project from keeling over'. That is why I postponed from working on LinuxCNC3 grand visions until the RT OS stuff is done. Of course there's always an alternative, the bits dont go away - keep scavenging hardware which somehow, in some way fits the current operations model. That is a dwindling option afaict, nevermind some of the more bizarre limitations attached. Well, I can see this going two ways. EMC works now. In the past, and I can read it between the lines now, that the invasiveness of the modifications will take so much time and effort that lots of other things gets pushed back. I guess my 2C would be that it would make more sense to incorporate these level of changes into v3 and back port once it is working and time allows. The problem becomes you are spending a LOT more time trying to shoehorn stuff into a structure that it does not well fit. Starting from a cleaner abstraction and moving forward in a methodological fashion will end up getting this done a lot faster than fighting the shoehorning. Also, if people have not done it already, I *strongly* recommend setting up a fully automated unit and regression test suite. I prefer the eXtreme Programming (XP) methodology myself, but any modern software engineering approach will benefit the project. Anyway, that's my 2C EBo -- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
Am 04.02.2013 um 11:29 schrieb EBo: On Feb 4 2013 2:58 AM, Michael Haberler wrote: Am 04.02.2013 um 10:25 schrieb EBo: LinuxCNC-3.0 then as a design philosophy? I would rather call it sheer necessity in some cases, although individual perceptions of urgency obviously differ. For instance, I dont think broadening the base of RT operating systems, or removing the 'everything on one CPU' limitation requires a lot of philosophical thinking; it is rather 'what is the minimum to be done asap from preventing this project from keeling over'. That is why I postponed from working on LinuxCNC3 grand visions until the RT OS stuff is done. Of course there's always an alternative, the bits dont go away - keep scavenging hardware which somehow, in some way fits the current operations model. That is a dwindling option afaict, nevermind some of the more bizarre limitations attached. Well, I can see this going two ways. EMC works now. well, the new RTOS branches do, too - sticking with that for the moment: In the past, and I can read it between the lines now, that the invasiveness of the modifications will take so much time and effort that lots of other things gets pushed back. I dont agree on 'invasiveness'. In fact the RTAPI api is used basically unchanged, barring some new functions for PCI handling; the codebase is much cleaner and easier to maintain I would think. I am not aware of any outstanding bugs, in particular not the RTAI RTAPI. Altogether I think that is a actually an incremental change. I agree on 'lot of effort' but we're spending a disproportionate amount of time on kernel packaging, testing, configuration build; skunkworks nows;) The RTAPI work has settled for quite a while. Btw some of that kernel packaging effort is driven by the 'everything on one CPU' limitation - without that it'd be easier sailing. I guess my 2C would be that it would make more sense to incorporate these level of changes into v3 and back port once it is working and time allows. I dont think that will happen because I dont see anybody to do it, and I dont quite see the point either - I've on purpose left the option open to merge the new RT OS work into either master or v2.5_branch. That option is still open and undecided. I dont care one way or the other, but one should be aware of the fact that merging this into master will accelerate deprecation of the v2.5_branch as few will see benefit in backpatching things into older branches, including me. Putting it further off will widen the gap even further. The problem becomes you are spending a LOT more time trying to shoehorn stuff into a structure that it does not well fit. Starting from a cleaner abstraction and moving forward in a methodological fashion will end up getting this done a lot faster than fighting the shoehorning. Also, if people have not done it already, I *strongly* recommend setting up a fully automated unit and regression test suite. I prefer the eXtreme Programming (XP) methodology myself, but any modern software engineering approach will benefit the project. switching theme to other structural work, for instance removing the 'everything on one CPU' limitation: I dont quite believe in the big-bang architectural changes in the linuxcnc context. There are way too many moving parts affected in parallel, and that isnt doable by a single person either - and that is the modus operandi by and large of this project, give and take some exceptions. Barring a significant sudden cultural change, it is hard to see the team to do that. So I think de-facto forking the codebase is unrealistic. I would rather see it in a parallel evolution of replacement parts. For instance, the duplicate middleware (NML+HAL, both not quite fitting the bill) is a pressing structural problem. The way I would see forward is to make HAL messaging capable such that it can take over the - fairly minimal - messaging aspects of NML, and then start migrating components piecemeal. That would be a limited-impact approach as it can be done and verified in isolated contexts, and it would take the IMO most pressing issue off the list. there are some issues which cannot be resolved by any amount of redesign, because they require a community decision or manpower. For instance, decide to deprecate Tcl use and eventually remove using code; or alternatively find a person which carries that effort forward onto a new base; I dont see either one. The big issue keeping *me* back here is actually relicensing. It is completely unrealistic IMO to address the above problem within the current GPL2only restriction. re motion: I think piecemeal is entirely possible here too - branch off a second component, build in parallel, modularize, and leave it as an option. When it becomes clear it's beneficial, folks will switch; if not, then not - no damage done except some lines of halcmd. I think that doing such
Re: [Emc-developers] custom EDM configuration questions
On Feb 4 2013 4:18 AM, Michael Haberler wrote: Am 04.02.2013 um 11:29 schrieb EBo: On Feb 4 2013 2:58 AM, Michael Haberler wrote: Am 04.02.2013 um 10:25 schrieb EBo: Well, I can see this going two ways. EMC works now. well, the new RTOS branches do, too - sticking with that for the moment: true, but I was not the one complaining that it is difficult to integrate, and thinking that a modular approach would help. In the past, and I can read it between the lines now, that the invasiveness of the modifications will take so much time and effort that lots of other things gets pushed back. I dont agree on 'invasiveness'. In fact the RTAPI api is used basically unchanged, barring some new functions for PCI handling; the codebase is much cleaner and easier to maintain I would think. I am not aware of any outstanding bugs, in particular not the RTAI RTAPI. ok. How difficult would it be to break all the new stuff out into modules, and build a modular framework for it? Altogether I think that is a actually an incremental change. I would love to be proven wrong on this one, but I can see modularizing monolithic code causing all sorts of unforeseen consequences. You might be lucky though. I agree on 'lot of effort' but we're spending a disproportionate amount of time on kernel packaging, testing, configuration build; skunkworks nows;) The RTAPI work has settled for quite a while. Btw some of that kernel packaging effort is driven by the 'everything on one CPU' limitation - without that it'd be easier sailing. what else do you see as changing if you break the 'everything on one CPU' limitation? I guess my 2C would be that it would make more sense to incorporate these level of changes into v3 and back port once it is working and time allows. I dont think that will happen because I dont see anybody to do it, and I dont quite see the point either - I've on purpose left the option open to merge the new RT OS work into either master or v2.5_branch. That option is still open and undecided. So my question to you is how long do you keep the 2.5 branch if/when a 3.0 branch becomes stable and fully functional? It should not be 0, but it also should not be forever. I dont care one way or the other, but one should be aware of the fact that merging this into master will accelerate deprecation of the v2.5_branch as few will see benefit in backpatching things into older branches, including me. Putting it further off will widen the gap even further. absolutely. But where do you dry the line between changes that are big enough that they deserve to be slated for 2.6, 2.7, or 3.0? Working incrementally is all find and good, and if we really refactor various pieces of the code to make them more modular or update HAL so we can drop NML, Each of these changes are serious enough to be designated a revision to version bump. The problem becomes you are spending a LOT more time trying to shoehorn stuff into a structure that it does not well fit. Starting from a cleaner abstraction and moving forward in a methodological fashion will end up getting this done a lot faster than fighting the shoehorning. Also, if people have not done it already, I *strongly* recommend setting up a fully automated unit and regression test suite. I prefer the eXtreme Programming (XP) methodology myself, but any modern software engineering approach will benefit the project. switching theme to other structural work, for instance removing the 'everything on one CPU' limitation: I dont quite believe in the big-bang architectural changes in the linuxcnc context. There are way too many moving parts affected in parallel, and that isnt doable by a single person either - and that is the modus operandi by and large of this project, give and take some exceptions. Barring a significant sudden cultural change, it is hard to see the team to do that. So I think de-facto forking the codebase is unrealistic. But there appear to be issues that are deeply ingrained enough that you will likely never address them until someone either forks EMC or at least makes a branch and changes things whole cloth. I would rather see it in a parallel evolution of replacement parts. For instance, the duplicate middleware (NML+HAL, both not quite fitting the bill) is a pressing structural problem. The way I would see forward is to make HAL messaging capable such that it can take over the - fairly minimal - messaging aspects of NML, and then start migrating components piecemeal. That would be a limited-impact approach as it can be done and verified in isolated contexts, and it would take the IMO most pressing issue off the list. Agreed. I would also advocate using that upgrade to implement/test full regression/unit testing. there are some issues which cannot be resolved by any amount of redesign, because they require a community decision or manpower. For instance, decide to
Re: [Emc-developers] custom EDM configuration questions
Am 04.02.2013 um 14:11 schrieb EBo: On Feb 4 2013 4:18 AM, Michael Haberler wrote: Am 04.02.2013 um 11:29 schrieb EBo: In the past, and I can read it between the lines now, that the invasiveness of the modifications will take so much time and effort that lots of other things gets pushed back. I dont agree on 'invasiveness'. In fact the RTAPI api is used basically unchanged, barring some new functions for PCI handling; the codebase is much cleaner and easier to maintain I would think. I am not aware of any outstanding bugs, in particular not the RTAI RTAPI. ok. How difficult would it be to break all the new stuff out into modules, and build a modular framework for it? well in fact that's what John is doing for RTAPI, with the intent to arrive at a universal build that supports RTAI, Xenomai, RT_PREEMPT and sim 'automagically'; that's not part of the current merge candidate-in-the-waiting though the design and flow stands, and I think it's another incremental change - basically linking RTAPI though support libraries for RT OS x,y or z, that is replaced by loading a .so module - the same stunt Jeff does with the interpreter; since Jeff's change wasnt noticed widely, we hope this one doesnt either. And every HAL module uses a similar method, so that's all safe ground. the idea is that eventually there is a single build per platform, regardless of the underlying RT OS; start it, code autodetects environment, does the right thing for the RT OS in question Altogether I think that is a actually an incremental change. I would love to be proven wrong on this one, but I can see modularizing monolithic code causing all sorts of unforeseen consequences. You might be lucky though. or, of course, insanely bright ;) I agree on 'lot of effort' but we're spending a disproportionate amount of time on kernel packaging, testing, configuration build; skunkworks nows;) The RTAPI work has settled for quite a while. Btw some of that kernel packaging effort is driven by the 'everything on one CPU' limitation - without that it'd be easier sailing. what else do you see as changing if you break the 'everything on one CPU' limitation? the above was remark really was only about the new RTOS stuff, so I wouldnt know what to say here I guess my 2C would be that it would make more sense to incorporate these level of changes into v3 and back port once it is working and time allows. I dont think that will happen because I dont see anybody to do it, and I dont quite see the point either - I've on purpose left the option open to merge the new RT OS work into either master or v2.5_branch. That option is still open and undecided. So my question to you is how long do you keep the 2.5 branch if/when a 3.0 branch becomes stable and fully functional? It should not be 0, but it also should not be forever. I dont know. I would think the 2.5 branch is a maintenance-only thing, but the things that are added to it arent consistent with that. I cannot discern any communicated policies. Clearly there are lots of un-communicated policies around. Re length: look at it this way: the remapping code added to the interpreter was way more massive than the new RTAPI layer in terms of LOC. AFAICT there are no open bugtracker entries with bona-fide bugs (modulo Xmas wishes) wrt remapping, and none which were open more that a few weeks at most. That branch is entirely usable, and is used; the windows of outright brokenness were very short. I dont care one way or the other, but one should be aware of the fact that merging this into master will accelerate deprecation of the v2.5_branch as few will see benefit in backpatching things into older branches, including me. Putting it further off will widen the gap even further. absolutely. But where do you dry the line between changes that are big enough that they deserve to be slated for 2.6, 2.7, or 3.0? Working incrementally is all find and good, and if we really refactor various pieces of the code to make them more modular or update HAL so we can drop NML, Each of these changes are serious enough to be designated a revision to version bump. the line I see goes like so: The messaging-capable HAL layer will have a new API, which subsumes some of the existing HAL lib functionality. This should be a published, usable API, meant as a base the using code in the rest of Linuxcnc (task, GUI's) can be adapted for. I think it should also aim making HAL/RTAPI and the HAL-based GUI tools usable standalone, without the rest of Linuxcnc code draped around it; this isnt only a good sanitary exercise but I think is is a tempting tool for entirely new, not classic LinuxCNC-type applications. In fact I see no competing attempt for doing that, but I see lots of fellows fiddling Arduinos hoping to do something which that could do, and then some. This can be done while the existing code is linked to it
Re: [Emc-developers] custom EDM configuration questions
On 02/04/2013 03:29 AM, EBo wrote: Also, if people have not done it already, I *strongly* recommend setting up a fully automated unit and regression test suite. We have a regression testing infrastructure and a pile of regression tests. We have continuous integration setup that runs the tests on every push (http://buildbot.linuxcnc.org). The CI system also does some static analysis on every push. More tests are always welcome, and are easy to add. Code coverage analysis would be interesting, and a unit testing framework (I've used check on other projects and liked it). -- Sebastian Kuzminsky -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
2013/2/4 EBo e...@sandien.com: I do not have time to really crawl into his code, and have the following question that I could see as being a problem: Can a long move be interrupted and reversed? If so, how does it handle the deceleration? In the video it switches back and forth right in a middle of particular g-code line. http://www.youtube.com/watch?v=eTLs89YPtck -- Viesturs If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On Mon, Feb 4, 2013, at 09:43 AM, Michael Haberler wrote: Am 04.02.2013 um 14:11 schrieb EBo: So my question to you is how long do you keep the 2.5 branch if/when a 3.0 branch becomes stable and fully functional? It should not be 0, but it also should not be forever. I dont know. I would think the 2.5 branch is a maintenance-only thing, but the things that are added to it arent consistent with that. I cannot discern any communicated policies. Clearly there are lots of un-communicated policies around. I think the policy is that changes within a major version should either be bugfixes or improvements that don't break existing configurations. In other words, if a user updates from 2.5.2 to 2.5.3, they should not have to edit their configuraion files (.ini, .hal, tool table, etc). They may choose to edit the files to take advantage of new features, but they should not be forced to edit them just to keep their machine working like it was before. Major revisions are allowed to require changes to configuration files, but the changes should be well documented, preferrably in a step- by-step document. If there are extensive but straightforward changes, a script that can do the grunt work would be much appreciated by the users. Switching from 2.5.6 to 2.6.0 can be expected to cause some pain, but we should try to minimize it. Changing from 2.x.x to 3.0.0 is something we haven't really talked about. Obviously that would imply major structural changes. Re length: look at it this way: the remapping code added to the interpreter was way more massive than the new RTAPI layer in terms of LOC. AFAICT there are no open bugtracker entries with bona-fide bugs (modulo Xmas wishes) wrt remapping, and none which were open more that a few weeks at most. That branch is entirely usable, and is used; the windows of outright brokenness were very short. I see this as something that could be added in a minor revision, since it (hopefully) won't break existing configurations. But to be honest, since it is a major new feature I would think of it more as a version 2.6 thing. absolutely. But where do you dry the line between changes that are big enough that they deserve to be slated for 2.6, 2.7, or 3.0? Working incrementally is all find and good, and if we really refactor various pieces of the code to make them more modular or update HAL so we can drop NML, Each of these changes are serious enough to be designated a revision to version bump. the line I see goes like so: The messaging-capable HAL layer will have a new API, which subsumes some of the existing HAL lib functionality. This should be a published, usable API, meant as a base the using code in the rest of Linuxcnc (task, GUI's) can be adapted for. I think it should also aim making HAL/RTAPI and the HAL-based GUI tools usable standalone, without the rest of Linuxcnc code draped around it; this isnt only a good sanitary exercise but I think is is a tempting tool for entirely new, not classic LinuxCNC-type applications. In fact I see no competing attempt for doing that, but I see lots of fellows fiddling Arduinos hoping to do something which that could do, and then some. What exactly do you mean by making HAL/RTAPI usable standalone? It already is - I've done several things that use halrun and a hal file but never load task, motion, or a LinuxCNC GUI. And I know others have done the same. Are you referring to making HAL/RTAPI an independent package that can be installed without the rest of LinuxCNC? -- John Kasunich jmkasun...@fastmail.fm -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On 02/04/2013 04:18 AM, EBo wrote: On Feb 3 2013 10:21 PM, TJoseph Powderly wrote: EBo, your name rings a bell all the way back to Paul Corner EMC days, you been arounf here a long time i think Yes. Paul's nastiness is why I completely disengaged from EMC for a *very* long time. It was the type of two faced - stab you in the back - interaction that the culture I come from tolerates a lot less than a literal punch in the face. Interestingly enough I was being funded to work on EMC at the time, and could have focused on it 40+ hrs/wk, and the kerflufle caused me to just walk away... If that history bothers you, I can easily bow out permanently. no problem, i got along with paul, but it was minimal interaction. i know he could be difficult. i also think he was smart. hehe i'm an asshole first thing every morning, i try to get it out of the way early, and am not always successful. no problem, we can move on ... this constant velocity is totally unsuited to EDM, the finaly mechanical driving element better to jiggly and nervous, else it aint repecting the process uncover the final gear or screw on any real working edm and watch, it approaches a smooth forward motion but IS jiggly and nervous. ... The EDM head I wanted to prototype, based on a some old work I saw once, has the jiggly portions controlled via analog circuitry in an internally closed-loop. All I would need it to do is either output a pause, or an analog feedback that basically adjusts the speed overide from where the user sets it down to 0 (full stop). That way it should be able to fully integrate into LinuxCNC. the head had the capability of retreating and 'catching up' to the commanded position? like a backslide W controlled by Linuxcnc and a foreslide controlled by analog circuitry? clever, DieterHansen tried similar in early 80's. re: jiggly, people get the silly idea that edm reverses, it doesnt, it goes to the correct position. you can think of it as reversing and totally miss the important bits. during any cut, the tool has zillions of in out feeds. The huge, easy to notice ones are called 'going backward' or 'retracting'. these are gross and do not show the nature of the process. the nature of the process is to constantly adjust the position to enhance the process of discharging. the jiggly effect is constantly in action, as the gap state changes constantly, analoguously. a bit of removed material will chang the gap 'resistance' and the the correct position is new. a bit of clean dielectric enters the gap and again changes the corect position. The people trying to solve 'retracting' without this understanding are missing the point. and, i believe, will implement inadequate solutions. BTW, I should add, that the EDM head I am talking about is a sink type, and is self retracting a very small distance, but all of that is handled by the head. That is how the current V/C feedback is maintained. DH's machine had less than a cm of travel. in theory less than the largest overcut ( oberflache ?) would be ok, so a mm would likely be ok this allows for piezo and other mechanisms as the parallel slide that advances the tool. ditto for orbitiing and the lateral axis. as well as piezos capability of nm motion. the speed that is needed for safe retraction is simply fast enough to reduce the damaging current flow enought ot save the workpiece so , the needed retract speed is simply the speed of electrcicity :) which means, the correct approach is not a better seat belt, (runaway speed) but better process control ( follow the process and you dont need to run away :) brushed dc motors have better low speed characteristics than ac digital ( old school 'rule', maybe not as true today) and very good low speed control ( hi acc, low vel ) is needed for edm ( very quickly get into position and then go slow :) mydynac repairs cnc edm for a group in sugar grove illinois 'edm network' owned by Ron Vogel ( iirc) the work done more recently by Scott Haase in WI can reverse and is limited to an upper and lower bound (same as mine) his uses O-word gcode, mine is hal based ( limits sets by mcodes, and motion implemented thru 'offset' hal component ) his o-word may be easier to debug, dunno, but for immediacy, hal should prove mpre responsive because its 1 less layer of control If I can find an old wire fed, or other industrial EDM, then I can see spending a lot of extra time on a project like this. i've got a friend who restores AGie WEDMs . if you want i can ask. also, an old trick was a 'crossbow' , mounted on head for a 'baloney slicer' ( wedm in only 1 axis ) on one side of head, a supply wheel with fresh wire, on the other, a takeup spool in between were two ruby/diamond (like) guides and power contacts feeds ( carbide usually) Hirschmann and their predecessor SystemH nee Istema nee Imea made them in Switzerland UI Chicago had a couple old AGie single axis machines that they used to sliced
Re: [Emc-developers] custom EDM configuration questions
On 02/03/2013 02:59 PM, EBo wrote: On Feb 3 2013 1:02 PM, Chris Morley wrote: I don't know if the trajectory planner keeps the move history, if it does then it might be possible to allow negative adaptive feed. Unfortunately negative feed would require major rework - there is no history of the path that has been executed. (That has also been discussed at length in the context of EDM.) -- John Kasunich jmkasun...@fastmail.fm Michael did a proof of concept on jog-while-paused once. You can see it on Utube. I think it worked by making a second queue for the jogging part. Then when you were done it picked up the original queue's move. I wonder if that same basic concept could be put to use with backing up an EDM move. possibly, but a more principled hack would be to interface it at the point where it calls the low lever Catmull-Rom spline, and just evaluate it in reverse. I do not know how difficult that would be, but it would require the ability to move in the negitive direction. I have written things like this for moving along splines with custom code, but I would have to look into how to do this in EMC-s low level motion planning. Probably the easiest thing to do would be to set up a reverse-motion pin in HAL, and then evaluate it internally, or modify the adaptive move command to allow positive/negitive feedback voltage which would imply forward/reverse of motion. Anyway that is my thought off the cuff. EBo -- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers looking at the catmull-rom spline, i see the curve is continuous ( tangential ) and should not require any blending at all in wedm for AGies we had a requirement for the paths to be tangential. in higher speed controls i can see this being an advantage ( less jerk ) tjtr33 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On 02/04/2013 04:18 AM, EBo wrote: On Feb 3 2013 10:21 PM, TJoseph Powderly wrote: EBo, your name rings a bell all the way back to Paul Corner EMC days, you been arounf here a long time i think Yes. Paul's nastiness is why I completely disengaged from EMC for a *very* long time. It was the type of two faced - stab you in the back - interaction that the culture I come from tolerates a lot less than a literal punch in the face. Interestingly enough I was being funded to work on EMC at the time, and could have focused on it 40+ hrs/wk, and the kerflufle caused me to just walk away... If that history bothers you, I can easily bow out permanently. The Paul Corner incident left all of us in confusion for some time. He was pushed out of the project after committing some destructive changes to the repository. I sure don't understand what that was all about. He did have some concerns that had at least a hint of legitimacy related to fears that John Kasunich's HAL would make EMC unworkable on lightweight hardware. I think that fear has proven to not be a concern due to hardware advancements, etc. Jon -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
2013/2/3 EBo e...@sandien.com: Long story short I am looking at building a project that would likely work best with EDM. I am looking at building a custom EDM head for a a CNC router that is currently configured for 0.0001 step. What I am trying to figure out is how to configure EMC so that the electronics can return a pause signal until it has burned burned through the requested material, then continue on the tool path. It is straight forward to write this in custom code, but I would prefer not to have to rewrite everything from scratch, and just set up a LinuxCNC configuration for it. Any ideas on how to do that? I'm drawing a blank... Have You considered using motion.feed-hold pin? If I understand You correctly, it seems like a perfect fit for this case - enable it with M53 P1 in code and attach motion.feed-hold to whatever input from Your electronics. And motion will be paused, whenever the input is true. http://linuxcnc.org/docs/html/man/man9/motion.9.html -- Viesturs If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On Feb 3 2013 4:47 AM, Viesturs Lācis wrote: 2013/2/3 EBo e...@sandien.com: Long story short I am looking at building a project that would likely work best with EDM. I am looking at building a custom EDM head for a a CNC router that is currently configured for 0.0001 step. What I am trying to figure out is how to configure EMC so that the electronics can return a pause signal until it has burned burned through the requested material, then continue on the tool path. It is straight forward to write this in custom code, but I would prefer not to have to rewrite everything from scratch, and just set up a LinuxCNC configuration for it. Any ideas on how to do that? I'm drawing a blank... Have You considered using motion.feed-hold pin? If I understand You correctly, it seems like a perfect fit for this case - enable it with M53 P1 in code and attach motion.feed-hold to whatever input from Your electronics. And motion will be paused, whenever the input is true. http://linuxcnc.org/docs/html/man/man9/motion.9.html Viesturs, that looks perfect! Now I just need to fire out how to rewire the router, build the EDM head, and set up the configuration ;-) Unfortunately, it will likely be a little while before I can break out all the time :-( Thanks again, and I will post back when I get a chance to build this up. EBo -- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On 3 February 2013 13:39, EBo e...@sandien.com wrote: What I am trying to figure out is how to configure EMC so that the electronics can return a pause signal until it has burned burned through the requested material, Adaptive feed _might_ work, but there is no way in the current code to run the path backwards. EDM machines that I have seen running seem to have to reverse quite frequently, so this might be a very difficult thing to get working. I don't know if the trajectory planner keeps the move history, if it does then it might be possible to allow negative adaptive feed. -- atp If you can't fix it, you don't own it http://www.ifixit.com/Manifesto -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On Feb 3 2013 4:57 AM, andy pugh wrote: On 3 February 2013 13:39, EBo e...@sandien.com wrote: What I am trying to figure out is how to configure EMC so that the electronics can return a pause signal until it has burned burned through the requested material, Adaptive feed _might_ work, but there is no way in the current code to run the path backwards. EDM machines that I have seen running seem to have to reverse quite frequently, so this might be a very difficult thing to get working. I don't know if the trajectory planner keeps the move history, if it does then it might be possible to allow negative adaptive feed. I was working on a very detailed reply before the circuit breaker tripped... Short answer is that decades ago I was shown a EDM head that could self retract a small distance (enough that you could feed in a couple of mm and the head would self retract via an analog current closed-loop feedback system). I was planning to build and modify that design a little to give me a pause signal and integrate that back into motion control. Anyway, I want to make some *very* small parts (the tooling is likely to be smaller that 0.01 diameter), and I can afford to make and break a bunch of these before I could afford to go out and buy a commercial EDM with capable specs. EBo -- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On 3 February 2013 15:39, EBo e...@sandien.com wrote: Short answer is that decades ago I was shown a EDM head that could self retract a small distance If this is purely a die-sinking application then I suggest not bothering with G-code at all. Do the whole thing in HAL with a custom component, and maybe your own Glade UI to control it. Gabe Willen has built a few machines using this approach (a plunge-grinder was one, I think) -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On Sun, 2013-02-03 at 15:50 +0200, andy pugh wrote: On 3 February 2013 15:39, EBo e...@sandien.com wrote: Short answer is that decades ago I was shown a EDM head that could self retract a small distance If this is purely a die-sinking application then I suggest not bothering with G-code at all. Do the whole thing in HAL with a custom component, and maybe your own Glade UI to control it. Gabe Willen has built a few machines using this approach (a plunge-grinder was one, I think) Some years ago Pete (the last name escapes me) brought an EDM to fest. Stepper powered and controlled by a BASIC (?) program. Both wire and sinker modes. C axis so he could thread. Pretty neat stuff. Maybe Steve Stallings can jump in here with a last name and phone number. Steve was doing something with him on a edm power supply. More hints ... from Wisconsin and drove an early Prius. Sorry I can't be more specific. Dave -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
-Original Message- From: dave [mailto:dengv...@charter.net] Sent: Sunday, February 03, 2013 10:43 AM To: EMC developers Subject: Re: [Emc-developers] custom EDM configuration questions On Sun, 2013-02-03 at 15:50 +0200, andy pugh wrote: On 3 February 2013 15:39, EBo e...@sandien.com wrote: Short answer is that decades ago I was shown a EDM head that could self retract a small distance If this is purely a die-sinking application then I suggest not bothering with G-code at all. Do the whole thing in HAL with a custom component, and maybe your own Glade UI to control it. Gabe Willen has built a few machines using this approach (a plunge-grinder was one, I think) Some years ago Pete (the last name escapes me) brought an EDM to fest. Stepper powered and controlled by a BASIC (?) program. Both wire and sinker modes. C axis so he could thread. Pretty neat stuff. Maybe Steve Stallings can jump in here with a last name and phone number. Steve was doing something with him on a edm power supply. More hints ... from Wisconsin and drove an early Prius. Sorry I can't be more specific. Dave That would be Pete Gruendeman. We have not been in contact since about 2008, a year after the fest where he brought his setup. I keep intending to get back to making something more for EDM, but never seem to get the time. Pete's system did not use EMC, but perhaps used some code ideas from it. He ran Basic which was plenty fast enough considering how slow the EDM process runs. I never had a copy of his code, so I cannot answer any detailed questions. I don't have a phone number. I do have an old email address that may or may not work, but I do not want to publish it on an open list. I would forward a message if you like. Steve Stallings -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
Sure. I would like to touch base with him. If I can not easily run it on emc then I will write a similar C program to drive it (probably via ANdroid) Sent from my Galaxy S®III Original message From: Steve Stallings steve...@newsguy.com Date: To: dengv...@charter.net,'EMC developers' emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] custom EDM configuration questions -Original Message- From: dave [mailto:dengv...@charter.net] Sent: Sunday, February 03, 2013 10:43 AM To: EMC developers Subject: Re: [Emc-developers] custom EDM configuration questions On Sun, 2013-02-03 at 15:50 +0200, andy pugh wrote: On 3 February 2013 15:39, EBo e...@sandien.com wrote: Short answer is that decades ago I was shown a EDM head that could self retract a small distance If this is purely a die-sinking application then I suggest not bothering with G-code at all. Do the whole thing in HAL with a custom component, and maybe your own Glade UI to control it. Gabe Willen has built a few machines using this approach (a plunge-grinder was one, I think) Some years ago Pete (the last name escapes me) brought an EDM to fest. Stepper powered and controlled by a BASIC (?) program. Both wire and sinker modes. C axis so he could thread. Pretty neat stuff. Maybe Steve Stallings can jump in here with a last name and phone number. Steve was doing something with him on a edm power supply. More hints ... from Wisconsin and drove an early Prius. Sorry I can't be more specific. Dave That would be Pete Gruendeman. We have not been in contact since about 2008, a year after the fest where he brought his setup. I keep intending to get back to making something more for EDM, but never seem to get the time. Pete's system did not use EMC, but perhaps used some code ideas from it. He ran Basic which was plenty fast enough considering how slow the EDM process runs. I never had a copy of his code, so I cannot answer any detailed questions. I don't have a phone number. I do have an old email address that may or may not work, but I do not want to publish it on an open list. I would forward a message if you like. Steve Stallings -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On Sun, Feb 3, 2013, at 06:57 AM, andy pugh wrote: On 3 February 2013 13:39, EBo e...@sandien.com wrote: What I am trying to figure out is how to configure EMC so that the electronics can return a pause signal until it has burned burned through the requested material, Adaptive feed _might_ work, but there is no way in the current code to run the path backwards. EDM machines that I have seen running seem to have to reverse quite frequently, so this might be a very difficult thing to get working. Adaptive feed was added to LinuxCNC specifically with the EDM application in mind. The idea is that some combination of external circuits and HAL blocks would generate a value between 0 and 1 which would control the rate at which LinuxCNC traverses the programmed path. I don't know if the trajectory planner keeps the move history, if it does then it might be possible to allow negative adaptive feed. Unfortunately negative feed would require major rework - there is no history of the path that has been executed. (That has also been discussed at length in the context of EDM.) -- John Kasunich jmkasun...@fastmail.fm -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
Ebo.. Please let us know if you hear back from him. I know of several EDM machines that need new controls.. and the ability to back up seems to be really important for a wire edm. Thanks, Dave On 2/3/2013 2:04 PM, ebo wrote: Sure. I would like to touch base with him. If I can not easily run it on emc then I will write a similar C program to drive it (probably via ANdroid) Sent from my Galaxy S®III Original message From: Steve Stallingssteve...@newsguy.com Date: To: dengv...@charter.net,'EMC developers'emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] custom EDM configuration questions -Original Message- From: dave [mailto:dengv...@charter.net] Sent: Sunday, February 03, 2013 10:43 AM To: EMC developers Subject: Re: [Emc-developers] custom EDM configuration questions On Sun, 2013-02-03 at 15:50 +0200, andy pugh wrote: On 3 February 2013 15:39, EBoe...@sandien.com wrote: Short answer is that decades ago I was shown a EDM head that could self retract a small distance If this is purely a die-sinking application then I suggest not bothering with G-code at all. Do the whole thing in HAL with a custom component, and maybe your own Glade UI to control it. Gabe Willen has built a few machines using this approach (a plunge-grinder was one, I think) Some years ago Pete (the last name escapes me) brought an EDM to fest. Stepper powered and controlled by a BASIC (?) program. Both wire and sinker modes. C axis so he could thread. Pretty neat stuff. Maybe Steve Stallings can jump in here with a last name and phone number. Steve was doing something with him on a edm power supply. More hints ... from Wisconsin and drove an early Prius. Sorry I can't be more specific. Dave That would be Pete Gruendeman. We have not been in contact since about 2008, a year after the fest where he brought his setup. I keep intending to get back to making something more for EDM, but never seem to get the time. Pete's system did not use EMC, but perhaps used some code ideas from it. He ran Basic which was plenty fast enough considering how slow the EDM process runs. I never had a copy of his code, so I cannot answer any detailed questions. I don't have a phone number. I do have an old email address that may or may not work, but I do not want to publish it on an open list. I would forward a message if you like. Steve Stallings -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
I don't know if the trajectory planner keeps the move history, if it does then it might be possible to allow negative adaptive feed. Unfortunately negative feed would require major rework - there is no history of the path that has been executed. (That has also been discussed at length in the context of EDM.) -- John Kasunich jmkasun...@fastmail.fm Michael did a proof of concept on jog-while-paused once. You can see it on Utube. I think it worked by making a second queue for the jogging part. Then when you were done it picked up the original queue's move. I wonder if that same basic concept could be put to use with backing up an EDM move. Chris M -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
Steve Stallings wrote: SNIP That would be Pete Gruendeman. We have not been in contact since about 2008, a year after the fest where he brought his setup. I keep intending to get back to making something more for EDM, but never seem to get the time. Pete's system did not use EMC, but perhaps used some code ideas from it. He ran Basic which was plenty fast enough considering how slow the EDM process runs. I never had a copy of his code, so I cannot answer any detailed questions. I don't have a phone number. I do have an old email address that may or may not work, but I do not want to publish it on an open list. I would forward a message if you like. Steve Stallings Pete is a member of the local LUG as am I. Do you want me to look him up? Ed. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On Feb 3 2013 1:02 PM, Chris Morley wrote: I don't know if the trajectory planner keeps the move history, if it does then it might be possible to allow negative adaptive feed. Unfortunately negative feed would require major rework - there is no history of the path that has been executed. (That has also been discussed at length in the context of EDM.) -- John Kasunich jmkasun...@fastmail.fm Michael did a proof of concept on jog-while-paused once. You can see it on Utube. I think it worked by making a second queue for the jogging part. Then when you were done it picked up the original queue's move. I wonder if that same basic concept could be put to use with backing up an EDM move. possibly, but a more principled hack would be to interface it at the point where it calls the low lever Catmull-Rom spline, and just evaluate it in reverse. I do not know how difficult that would be, but it would require the ability to move in the negitive direction. I have written things like this for moving along splines with custom code, but I would have to look into how to do this in EMC-s low level motion planning. Probably the easiest thing to do would be to set up a reverse-motion pin in HAL, and then evaluate it internally, or modify the adaptive move command to allow positive/negitive feedback voltage which would imply forward/reverse of motion. Anyway that is my thought off the cuff. EBo -- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On Feb 3 2013 1:02 PM, Chris Morley wrote: ... Michael did a proof of concept on jog-while-paused once. You can see it on Utube. I just looked this up and the video does not move backward along the jogged path, but straight to where it was before. I would expect that with a wirefed EDM, this would break the tool. That being said, it looks like it has much of the necessary functionality. EBo -- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On Feb 3 2013 1:59 PM, ed wrote: Steve Stallings wrote: SNIP That would be Pete Gruendeman. We have not been in contact since about 2008, a year after the fest where he brought his setup. I keep intending to get back to making something more for EDM, but never seem to get the time. Pete's system did not use EMC, but perhaps used some code ideas from it. He ran Basic which was plenty fast enough considering how slow the EDM process runs. I never had a copy of his code, so I cannot answer any detailed questions. I don't have a phone number. I do have an old email address that may or may not work, but I do not want to publish it on an open list. I would forward a message if you like. Steve Stallings Pete is a member of the local LUG as am I. Do you want me to look him up? Sure. You can also contact me off-list if more appropriate. EBo -- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On Sun, Feb 3, 2013, at 03:59 PM, EBo wrote: possibly, but a more principled hack would be to interface it at the point where it calls the low lever Catmull-Rom spline, and just evaluate it in reverse. I do not know how difficult that would be, but it would require the ability to move in the negitive direction. I have written things like this for moving along splines with custom code, but I would have to look into how to do this in EMC-s low level motion planning. Probably the easiest thing to do would be to set up a reverse-motion pin in HAL, and then evaluate it internally, or modify the adaptive move command to allow positive/negitive feedback voltage which would imply forward/reverse of motion. Anyway that is my thought off the cuff. Where things get ugly is when you try to do this in a general way. For example, what happens if you ask for negative feed while in a spindle synchronized move (single-point threading or rigid tapping)? Actually, that issue must have already been dealt with - adaptive feed would cause the problems in that case even for positive scale factors. But that was just an example. What about probing moves? What about the blend between successive non-co-linear straight lines? What about a profile that consists of many 0.002 long lines? Can you back up more than 0.002? Sure, you can say an EDM will never make a spindle synchronized move, but changes to the motion module need to do sane things regardless of what kind of a machine is being controlled. -- John Kasunich jmkasun...@fastmail.fm -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On Sun, 3 Feb 2013, John Kasunich wrote: Date: Sun, 03 Feb 2013 17:08:37 -0500 From: John Kasunich jmkasun...@fastmail.fm Reply-To: EMC developers emc-developers@lists.sourceforge.net To: EMC developers emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] custom EDM configuration questions On Sun, Feb 3, 2013, at 03:59 PM, EBo wrote: possibly, but a more principled hack would be to interface it at the point where it calls the low lever Catmull-Rom spline, and just evaluate it in reverse. I do not know how difficult that would be, but it would require the ability to move in the negitive direction. I have written things like this for moving along splines with custom code, but I would have to look into how to do this in EMC-s low level motion planning. Probably the easiest thing to do would be to set up a reverse-motion pin in HAL, and then evaluate it internally, or modify the adaptive move command to allow positive/negitive feedback voltage which would imply forward/reverse of motion. Anyway that is my thought off the cuff. Where things get ugly is when you try to do this in a general way. For example, what happens if you ask for negative feed while in a spindle synchronized move (single-point threading or rigid tapping)? Actually, that issue must have already been dealt with - adaptive feed would cause the problems in that case even for positive scale factors. But that was just an example. What about probing moves? What about the blend between successive non-co-linear straight lines? What about a profile that consists of many 0.002 long lines? Can you back up more than 0.002? Sure, you can say an EDM will never make a spindle synchronized move, but changes to the motion module need to do sane things regardless of what kind of a machine is being controlled. What about different motion modules optimized different classes of applications? -- John Kasunich jmkasun...@fastmail.fm -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On Feb 3 2013 3:42 PM, Peter C. Wallace wrote: On Sun, 3 Feb 2013, John Kasunich wrote: Date: Sun, 03 Feb 2013 17:08:37 -0500 From: John Kasunich jmkasun...@fastmail.fm Reply-To: EMC developers emc-developers@lists.sourceforge.net To: EMC developers emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] custom EDM configuration questions On Sun, Feb 3, 2013, at 03:59 PM, EBo wrote: possibly, but a more principled hack would be to interface it at the point where it calls the low lever Catmull-Rom spline, and just evaluate it in reverse. I do not know how difficult that would be, but it would require the ability to move in the negitive direction. I have written things like this for moving along splines with custom code, but I would have to look into how to do this in EMC-s low level motion planning. Probably the easiest thing to do would be to set up a reverse-motion pin in HAL, and then evaluate it internally, or modify the adaptive move command to allow positive/negitive feedback voltage which would imply forward/reverse of motion. Anyway that is my thought off the cuff. Where things get ugly is when you try to do this in a general way. For example, what happens if you ask for negative feed while in a spindle synchronized move (single-point threading or rigid tapping)? Actually, that issue must have already been dealt with - adaptive feed would cause the problems in that case even for positive scale factors. But that was just an example. What about probing moves? What about the blend between successive non-co-linear straight lines? What about a profile that consists of many 0.002 long lines? Can you back up more than 0.002? Sure, you can say an EDM will never make a spindle synchronized move, but changes to the motion module need to do sane things regardless of what kind of a machine is being controlled. What about different motion modules optimized different classes of applications? Sure if you can describe realistic situations... -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On Feb 3 2013 3:08 PM, John Kasunich wrote: On Sun, Feb 3, 2013, at 03:59 PM, EBo wrote: possibly, but a more principled hack would be to interface it at the point where it calls the low lever Catmull-Rom spline, and just evaluate it in reverse. I do not know how difficult that would be, but it would require the ability to move in the negitive direction. I have written things like this for moving along splines with custom code, but I would have to look into how to do this in EMC-s low level motion planning. Probably the easiest thing to do would be to set up a reverse-motion pin in HAL, and then evaluate it internally, or modify the adaptive move command to allow positive/negitive feedback voltage which would imply forward/reverse of motion. Anyway that is my thought off the cuff. Where things get ugly is when you try to do this in a general way. For example, what happens if you ask for negative feed while in a spindle synchronized move (single-point threading or rigid tapping)? Actually, that issue must have already been dealt with - adaptive feed would cause the problems in that case even for positive scale factors. But that was just an example. What about probing moves? What about the blend between successive non-co-linear straight lines? What about a profile that consists of many 0.002 long lines? Can you back up more than 0.002? Sure, you can say an EDM will never make a spindle synchronized move, but changes to the motion module need to do sane things regardless of what kind of a machine is being controlled. I was not saying that it could only go back a single move alone a single spline. I just said it needed to be reversible. I will have o think about the spindle-synchronization as I may need that exact functionality to make certain parts. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
For simple simker EDM I implemented reversing in a gcode loop sensing an analog input: http://code.google.com/p/sector67-sandbox/wiki/FrequencyBasedAnalogInput this was simple for my application, could stand to be refined somewhat, and would get complicated for anything but straight down/up. Scott On Sun, Feb 3, 2013 at 7:50 PM, EBo e...@sandien.com wrote: On Feb 3 2013 3:08 PM, John Kasunich wrote: On Sun, Feb 3, 2013, at 03:59 PM, EBo wrote: possibly, but a more principled hack would be to interface it at the point where it calls the low lever Catmull-Rom spline, and just evaluate it in reverse. I do not know how difficult that would be, but it would require the ability to move in the negitive direction. I have written things like this for moving along splines with custom code, but I would have to look into how to do this in EMC-s low level motion planning. Probably the easiest thing to do would be to set up a reverse-motion pin in HAL, and then evaluate it internally, or modify the adaptive move command to allow positive/negitive feedback voltage which would imply forward/reverse of motion. Anyway that is my thought off the cuff. Where things get ugly is when you try to do this in a general way. For example, what happens if you ask for negative feed while in a spindle synchronized move (single-point threading or rigid tapping)? Actually, that issue must have already been dealt with - adaptive feed would cause the problems in that case even for positive scale factors. But that was just an example. What about probing moves? What about the blend between successive non-co-linear straight lines? What about a profile that consists of many 0.002 long lines? Can you back up more than 0.002? Sure, you can say an EDM will never make a spindle synchronized move, but changes to the motion module need to do sane things regardless of what kind of a machine is being controlled. I was not saying that it could only go back a single move alone a single spline. I just said it needed to be reversible. I will have o think about the spindle-synchronization as I may need that exact functionality to make certain parts. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On 02/03/2013 07:47 PM, EBo wrote: On Feb 3 2013 3:42 PM, Peter C. Wallace wrote: On Sun, 3 Feb 2013, John Kasunich wrote: Date: Sun, 03 Feb 2013 17:08:37 -0500 From: John Kasunich jmkasun...@fastmail.fm Reply-To: EMC developers emc-developers@lists.sourceforge.net To: EMC developers emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] custom EDM configuration questions On Sun, Feb 3, 2013, at 03:59 PM, EBo wrote: possibly, but a more principled hack would be to interface it at the point where it calls the low lever Catmull-Rom spline, and just evaluate it in reverse. I do not know how difficult that would be, but it would require the ability to move in the negitive direction. I have written things like this for moving along splines with custom code, but I would have to look into how to do this in EMC-s low level motion planning. Probably the easiest thing to do would be to set up a reverse-motion pin in HAL, and then evaluate it internally, or modify the adaptive move command to allow positive/negitive feedback voltage which would imply forward/reverse of motion. Anyway that is my thought off the cuff. Where things get ugly is when you try to do this in a general way. For example, what happens if you ask for negative feed while in a spindle synchronized move (single-point threading or rigid tapping)? Actually, that issue must have already been dealt with - adaptive feed would cause the problems in that case even for positive scale factors. But that was just an example. What about probing moves? What about the blend between successive non-co-linear straight lines? What about a profile that consists of many 0.002 long lines? Can you back up more than 0.002? Sure, you can say an EDM will never make a spindle synchronized move, but changes to the motion module need to do sane things regardless of what kind of a machine is being controlled. What about different motion modules optimized different classes of applications? Sure if you can describe realistic situations... -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers i've written and investigated Linuxcnc for EDM for years now maybe this will be of interest there are 3 basic forms of edm and each has unique needs all are EDM though and cannot tolerate the 'in position on time' nature of linuxcnc ( needs a different rule set for where the tool tip must be now ) the tool tip must be in a position dictated by the process, independant of time and independant of the position where we were last check. the 3 types of edm are ( besides edg and a few even rarer modes) 1) hole drilling... only moves along a single axis. usually a single joint 2) sink edm ... retracts to a given point ( maybe 3-8 axis, maybe 1, but the retract path is not neccesarily the approach path ( nor often the same )) because it retacts to a safe point, this is 'sky blue', you need'nt have begun or been there before, its just safe 3) wedm.. retracts along the programmed path thru one or more path pieces ( multiple gcodes/ multiple sequenctial tangential geometric entities) this requires a memory ( at least waypoints, like the segments spit out by the traj planner ) 1 2 are HAL solvable 3 requires changes to linuxcnc position planning ( at least a history that can be un-done, like gps waypoints ) my own tests are only for sink edm ( some for hole poppers but my HiPresure pump is down now ) i suggest something much simpler than the VtoF to HAL to thresholds to motion proposal i simply use a window comparator and output ADVANCE or RETRACT signals to hal hal knows the beginning and ending positions (limits) of the motion and an OFFSET component's input is inc'd/dec'd according to the process ( according to the window comparator ) the machine cannot exceed the depth programmed ( could be x y z c as you like ) so it has 'spark out' with a little hal-foo and timer ( or a higher threshold in mine ) It is not locked at the bottom, simply watch for it to be at the bottom for a len of time w/o backing off... thats a sign the work is really completed the cut could go bad and retract to the RETRACT limit, and I abort at that point ( no where to run ) the cut could get done and spark out at the bottom right now i'm playing with feeding JMK's sine/cosine stepper example to implement orbiting from this lower 'roughing point' i specialize in sink edm. I just rebuilt 2 OKAMOTO's that were terribly dead and abused. they cut fine now. I wrote all the macros for ELox system 8/9/10 fanuc's i wrote all the code
Re: [Emc-developers] custom EDM configuration questions
there was a guy on irc that converted an wire edm to linuxcnc using adaptive feed. I thought it worked pretty well - he had posted pictures of stuff he had cut... his handle on irc was mdynac a post by him on cnczone.. http://www.cnczone.com/forums/463833-post31.html oh - found the pictures - cradek hosted them... http://timeguy.com/cradek-files/emc/edm/MVC-029S.JPG http://timeguy.com/cradek/emc/edm So - it seems doable.. Seems the wire breaking issue could just be back up and RFL... And remember - Linuxcnc keeps getting better and better... sam On 02/03/2013 09:20 PM, TJoseph Powderly wrote: On 02/03/2013 07:47 PM, EBo wrote: On Feb 3 2013 3:42 PM, Peter C. Wallace wrote: On Sun, 3 Feb 2013, John Kasunich wrote: Date: Sun, 03 Feb 2013 17:08:37 -0500 From: John Kasunich jmkasun...@fastmail.fm Reply-To: EMC developers emc-developers@lists.sourceforge.net To: EMC developers emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] custom EDM configuration questions On Sun, Feb 3, 2013, at 03:59 PM, EBo wrote: possibly, but a more principled hack would be to interface it at the point where it calls the low lever Catmull-Rom spline, and just evaluate it in reverse. I do not know how difficult that would be, but it would require the ability to move in the negitive direction. I have written things like this for moving along splines with custom code, but I would have to look into how to do this in EMC-s low level motion planning. Probably the easiest thing to do would be to set up a reverse-motion pin in HAL, and then evaluate it internally, or modify the adaptive move command to allow positive/negitive feedback voltage which would imply forward/reverse of motion. Anyway that is my thought off the cuff. Where things get ugly is when you try to do this in a general way. For example, what happens if you ask for negative feed while in a spindle synchronized move (single-point threading or rigid tapping)? Actually, that issue must have already been dealt with - adaptive feed would cause the problems in that case even for positive scale factors. But that was just an example. What about probing moves? What about the blend between successive non-co-linear straight lines? What about a profile that consists of many 0.002 long lines? Can you back up more than 0.002? Sure, you can say an EDM will never make a spindle synchronized move, but changes to the motion module need to do sane things regardless of what kind of a machine is being controlled. What about different motion modules optimized different classes of applications? Sure if you can describe realistic situations... -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers i've written and investigated Linuxcnc for EDM for years now maybe this will be of interest there are 3 basic forms of edm and each has unique needs all are EDM though and cannot tolerate the 'in position on time' nature of linuxcnc ( needs a different rule set for where the tool tip must be now ) the tool tip must be in a position dictated by the process, independant of time and independant of the position where we were last check. the 3 types of edm are ( besides edg and a few even rarer modes) 1) hole drilling... only moves along a single axis. usually a single joint 2) sink edm ... retracts to a given point ( maybe 3-8 axis, maybe 1, but the retract path is not neccesarily the approach path ( nor often the same )) because it retacts to a safe point, this is 'sky blue', you need'nt have begun or been there before, its just safe 3) wedm.. retracts along the programmed path thru one or more path pieces ( multiple gcodes/ multiple sequenctial tangential geometric entities) this requires a memory ( at least waypoints, like the segments spit out by the traj planner ) 1 2 are HAL solvable 3 requires changes to linuxcnc position planning ( at least a history that can be un-done, like gps waypoints ) my own tests are only for sink edm ( some for hole poppers but my HiPresure pump is down now ) i suggest something much simpler than the VtoF to HAL to thresholds to motion proposal i simply use a window comparator and output ADVANCE or RETRACT signals to hal hal knows the beginning and ending positions (limits) of the motion and an OFFSET component's input is inc'd/dec'd according to the process ( according to the window comparator ) the machine cannot exceed the depth programmed ( could be x y z c as you like ) so it has 'spark out' with a little hal-foo and timer
Re: [Emc-developers] custom EDM configuration questions
Oh - and this is kinda interesting... http://www.youtube.com/watch?v=eTLs89YPtck Follow and translate the link in the description.. (interesting hack..) sam On 02/03/2013 09:20 PM, TJoseph Powderly wrote: On 02/03/2013 07:47 PM, EBo wrote: On Feb 3 2013 3:42 PM, Peter C. Wallace wrote: On Sun, 3 Feb 2013, John Kasunich wrote: Date: Sun, 03 Feb 2013 17:08:37 -0500 From: John Kasunich jmkasun...@fastmail.fm Reply-To: EMC developers emc-developers@lists.sourceforge.net To: EMC developers emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] custom EDM configuration questions On Sun, Feb 3, 2013, at 03:59 PM, EBo wrote: possibly, but a more principled hack would be to interface it at the point where it calls the low lever Catmull-Rom spline, and just evaluate it in reverse. I do not know how difficult that would be, but it would require the ability to move in the negitive direction. I have written things like this for moving along splines with custom code, but I would have to look into how to do this in EMC-s low level motion planning. Probably the easiest thing to do would be to set up a reverse-motion pin in HAL, and then evaluate it internally, or modify the adaptive move command to allow positive/negitive feedback voltage which would imply forward/reverse of motion. Anyway that is my thought off the cuff. Where things get ugly is when you try to do this in a general way. For example, what happens if you ask for negative feed while in a spindle synchronized move (single-point threading or rigid tapping)? Actually, that issue must have already been dealt with - adaptive feed would cause the problems in that case even for positive scale factors. But that was just an example. What about probing moves? What about the blend between successive non-co-linear straight lines? What about a profile that consists of many 0.002 long lines? Can you back up more than 0.002? Sure, you can say an EDM will never make a spindle synchronized move, but changes to the motion module need to do sane things regardless of what kind of a machine is being controlled. What about different motion modules optimized different classes of applications? Sure if you can describe realistic situations... -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers i've written and investigated Linuxcnc for EDM for years now maybe this will be of interest there are 3 basic forms of edm and each has unique needs all are EDM though and cannot tolerate the 'in position on time' nature of linuxcnc ( needs a different rule set for where the tool tip must be now ) the tool tip must be in a position dictated by the process, independant of time and independant of the position where we were last check. the 3 types of edm are ( besides edg and a few even rarer modes) 1) hole drilling... only moves along a single axis. usually a single joint 2) sink edm ... retracts to a given point ( maybe 3-8 axis, maybe 1, but the retract path is not neccesarily the approach path ( nor often the same )) because it retacts to a safe point, this is 'sky blue', you need'nt have begun or been there before, its just safe 3) wedm.. retracts along the programmed path thru one or more path pieces ( multiple gcodes/ multiple sequenctial tangential geometric entities) this requires a memory ( at least waypoints, like the segments spit out by the traj planner ) 1 2 are HAL solvable 3 requires changes to linuxcnc position planning ( at least a history that can be un-done, like gps waypoints ) my own tests are only for sink edm ( some for hole poppers but my HiPresure pump is down now ) i suggest something much simpler than the VtoF to HAL to thresholds to motion proposal i simply use a window comparator and output ADVANCE or RETRACT signals to hal hal knows the beginning and ending positions (limits) of the motion and an OFFSET component's input is inc'd/dec'd according to the process ( according to the window comparator ) the machine cannot exceed the depth programmed ( could be x y z c as you like ) so it has 'spark out' with a little hal-foo and timer ( or a higher threshold in mine ) It is not locked at the bottom, simply watch for it to be at the bottom for a len of time w/o backing off... thats a sign the work is really completed the cut could go bad and retract to the RETRACT limit, and I abort at that point ( no where to run ) the cut could get done and spark out at the bottom right now i'm playing with feeding JMK's sine/cosine stepper
Re: [Emc-developers] custom EDM configuration questions
Scott, Thanks. I will look at this when I get a chance. I may end up reworking an old Bezier spline driver module to straight step direction code if it comes to that. More later, EBo -- On Feb 3 2013 7:17 PM, Scott Hasse wrote: For simple simker EDM I implemented reversing in a gcode loop sensing an analog input: http://code.google.com/p/sector67-sandbox/wiki/FrequencyBasedAnalogInput this was simple for my application, could stand to be refined somewhat, and would get complicated for anything but straight down/up. Scott On Sun, Feb 3, 2013 at 7:50 PM, EBo e...@sandien.com wrote: On Feb 3 2013 3:08 PM, John Kasunich wrote: On Sun, Feb 3, 2013, at 03:59 PM, EBo wrote: possibly, but a more principled hack would be to interface it at the point where it calls the low lever Catmull-Rom spline, and just evaluate it in reverse. I do not know how difficult that would be, but it would require the ability to move in the negitive direction. I have written things like this for moving along splines with custom code, but I would have to look into how to do this in EMC-s low level motion planning. Probably the easiest thing to do would be to set up a reverse-motion pin in HAL, and then evaluate it internally, or modify the adaptive move command to allow positive/negitive feedback voltage which would imply forward/reverse of motion. Anyway that is my thought off the cuff. Where things get ugly is when you try to do this in a general way. For example, what happens if you ask for negative feed while in a spindle synchronized move (single-point threading or rigid tapping)? Actually, that issue must have already been dealt with - adaptive feed would cause the problems in that case even for positive scale factors. But that was just an example. What about probing moves? What about the blend between successive non-co-linear straight lines? What about a profile that consists of many 0.002 long lines? Can you back up more than 0.002? Sure, you can say an EDM will never make a spindle synchronized move, but changes to the motion module need to do sane things regardless of what kind of a machine is being controlled. I was not saying that it could only go back a single move alone a single spline. I just said it needed to be reversible. I will have o think about the spindle-synchronization as I may need that exact functionality to make certain parts. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
On Feb 3 2013 8:20 PM, TJoseph Powderly wrote: On 02/03/2013 07:47 PM, EBo wrote: On Feb 3 2013 3:42 PM, Peter C. Wallace wrote: On Sun, 3 Feb 2013, John Kasunich wrote: Date: Sun, 03 Feb 2013 17:08:37 -0500 From: John Kasunich jmkasun...@fastmail.fm Reply-To: EMC developers emc-developers@lists.sourceforge.net To: EMC developers emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] custom EDM configuration questions On Sun, Feb 3, 2013, at 03:59 PM, EBo wrote: possibly, but a more principled hack would be to interface it at the point where it calls the low lever Catmull-Rom spline, and just evaluate it in reverse. I do not know how difficult that would be, but it would require the ability to move in the negitive direction. I have written things like this for moving along splines with custom code, but I would have to look into how to do this in EMC-s low level motion planning. Probably the easiest thing to do would be to set up a reverse-motion pin in HAL, and then evaluate it internally, or modify the adaptive move command to allow positive/negitive feedback voltage which would imply forward/reverse of motion. Anyway that is my thought off the cuff. Where things get ugly is when you try to do this in a general way. For example, what happens if you ask for negative feed while in a spindle synchronized move (single-point threading or rigid tapping)? Actually, that issue must have already been dealt with - adaptive feed would cause the problems in that case even for positive scale factors. But that was just an example. What about probing moves? What about the blend between successive non-co-linear straight lines? What about a profile that consists of many 0.002 long lines? Can you back up more than 0.002? Sure, you can say an EDM will never make a spindle synchronized move, but changes to the motion module need to do sane things regardless of what kind of a machine is being controlled. What about different motion modules optimized different classes of applications? Sure if you can describe realistic situations... -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers i've written and investigated Linuxcnc for EDM for years now maybe this will be of interest there are 3 basic forms of edm and each has unique needs all are EDM though and cannot tolerate the 'in position on time' nature of linuxcnc ( needs a different rule set for where the tool tip must be now ) the tool tip must be in a position dictated by the process, independant of time and independant of the position where we were last check. the 3 types of edm are ( besides edg and a few even rarer modes) 1) hole drilling... only moves along a single axis. usually a single joint 2) sink edm ... retracts to a given point ( maybe 3-8 axis, maybe 1, but the retract path is not neccesarily the approach path ( nor often the same )) because it retacts to a safe point, this is 'sky blue', you need'nt have begun or been there before, its just safe 3) wedm.. retracts along the programmed path thru one or more path pieces ( multiple gcodes/ multiple sequenctial tangential geometric entities) this requires a memory ( at least waypoints, like the segments spit out by the traj planner ) 1 2 are HAL solvable 3 requires changes to linuxcnc position planning ( at least a history that can be un-done, like gps waypoints ) my own tests are only for sink edm ( some for hole poppers but my HiPresure pump is down now ) i suggest something much simpler than the VtoF to HAL to thresholds to motion proposal i simply use a window comparator and output ADVANCE or RETRACT signals to hal hal knows the beginning and ending positions (limits) of the motion and an OFFSET component's input is inc'd/dec'd according to the process ( according to the window comparator ) the machine cannot exceed the depth programmed ( could be x y z c as you like ) so it has 'spark out' with a little hal-foo and timer ( or a higher threshold in mine ) It is not locked at the bottom, simply watch for it to be at the bottom for a len of time w/o backing off... thats a sign the work is really completed the cut could go bad and retract to the RETRACT limit, and I abort at that point ( no where to run ) the cut could get done and spark out at the bottom right now i'm playing with feeding JMK's sine/cosine stepper example to implement orbiting from this lower 'roughing point' i specialize in sink edm. I just rebuilt 2 OKAMOTO's that were
Re: [Emc-developers] custom EDM configuration questions
Looking at the pictures I really love the PDP-8 in one of them... Thanks for the links! On Feb 3 2013 8:44 PM, sam sokolik wrote: there was a guy on irc that converted an wire edm to linuxcnc using adaptive feed. I thought it worked pretty well - he had posted pictures of stuff he had cut... his handle on irc was mdynac a post by him on cnczone.. http://www.cnczone.com/forums/463833-post31.html oh - found the pictures - cradek hosted them... http://timeguy.com/cradek-files/emc/edm/MVC-029S.JPG http://timeguy.com/cradek/emc/edm So - it seems doable.. Seems the wire breaking issue could just be back up and RFL... And remember - Linuxcnc keeps getting better and better... sam On 02/03/2013 09:20 PM, TJoseph Powderly wrote: On 02/03/2013 07:47 PM, EBo wrote: On Feb 3 2013 3:42 PM, Peter C. Wallace wrote: On Sun, 3 Feb 2013, John Kasunich wrote: Date: Sun, 03 Feb 2013 17:08:37 -0500 From: John Kasunich jmkasun...@fastmail.fm Reply-To: EMC developers emc-developers@lists.sourceforge.net To: EMC developers emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] custom EDM configuration questions On Sun, Feb 3, 2013, at 03:59 PM, EBo wrote: possibly, but a more principled hack would be to interface it at the point where it calls the low lever Catmull-Rom spline, and just evaluate it in reverse. I do not know how difficult that would be, but it would require the ability to move in the negitive direction. I have written things like this for moving along splines with custom code, but I would have to look into how to do this in EMC-s low level motion planning. Probably the easiest thing to do would be to set up a reverse-motion pin in HAL, and then evaluate it internally, or modify the adaptive move command to allow positive/negitive feedback voltage which would imply forward/reverse of motion. Anyway that is my thought off the cuff. Where things get ugly is when you try to do this in a general way. For example, what happens if you ask for negative feed while in a spindle synchronized move (single-point threading or rigid tapping)? Actually, that issue must have already been dealt with - adaptive feed would cause the problems in that case even for positive scale factors. But that was just an example. What about probing moves? What about the blend between successive non-co-linear straight lines? What about a profile that consists of many 0.002 long lines? Can you back up more than 0.002? Sure, you can say an EDM will never make a spindle synchronized move, but changes to the motion module need to do sane things regardless of what kind of a machine is being controlled. What about different motion modules optimized different classes of applications? Sure if you can describe realistic situations... -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers i've written and investigated Linuxcnc for EDM for years now maybe this will be of interest there are 3 basic forms of edm and each has unique needs all are EDM though and cannot tolerate the 'in position on time' nature of linuxcnc ( needs a different rule set for where the tool tip must be now ) the tool tip must be in a position dictated by the process, independant of time and independant of the position where we were last check. the 3 types of edm are ( besides edg and a few even rarer modes) 1) hole drilling... only moves along a single axis. usually a single joint 2) sink edm ... retracts to a given point ( maybe 3-8 axis, maybe 1, but the retract path is not neccesarily the approach path ( nor often the same )) because it retacts to a safe point, this is 'sky blue', you need'nt have begun or been there before, its just safe 3) wedm.. retracts along the programmed path thru one or more path pieces ( multiple gcodes/ multiple sequenctial tangential geometric entities) this requires a memory ( at least waypoints, like the segments spit out by the traj planner ) 1 2 are HAL solvable 3 requires changes to linuxcnc position planning ( at least a history that can be un-done, like gps waypoints ) my own tests are only for sink edm ( some for hole poppers but my HiPresure pump is down now ) i suggest something much simpler than the VtoF to HAL to thresholds to motion proposal i simply use a window comparator and output ADVANCE or RETRACT signals to hal hal knows the beginning and ending positions (limits) of the motion and an OFFSET component's input is inc'd/dec'd according
Re: [Emc-developers] custom EDM configuration questions
EBo, your name rings a bell all the way back to Paul Corner EMC days, you been arounf here a long time i think btw: mydynac ( and RayHenry's) approach could not reverse even 1 unit of measure the 'adaptive speed' method could only reduce forward velocity , can not reverse at all there was no dwell, no reverese, no wait till its ready to take a step this constant velocity is totally unsuited to EDM, the finaly mechanical driving element better to jiggly and nervous, else it aint repecting the process uncover the final gear or screw on any real working edm and watch, it approaches a smooth forward motion but IS jiggly and nervous. mydynac repairs cnc edm for a group in sugar grove illinois 'edm network' owned by Ron Vogel ( iirc) the work done more recently by Scott Haase in WI can reverse and is limited to an upper and lower bound (same as mine) his uses O-word gcode, mine is hal based ( limits sets by mcodes, and motion implemented thru 'offset' hal component ) his o-word may be easier to debug, dunno, but for immediacy, hal should prove mpre responsive because its 1 less layer of control the idea of orbitining is to use the distance moved away from the 'roughing point' to feed a sine and cosine generator and use that value to move XY along the surface of a circular cone. As the Z motion increases, the circle increases ( and drops ) if the process sees a redcuced input signal , ALL axis collapse to the that 'roughing point'. and for the edm gap voltage - arduino - threshold comparison - hal - motion loop of Mr Haase well there many layers removed by directly connecting a window comparator to a hal 'offset' comp regards tjtr33 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
2013/2/4 sam sokolik sa...@empirescreen.com: Oh - and this is kinda interesting... http://www.youtube.com/watch?v=eTLs89YPtck Follow and translate the link in the description.. (interesting hack..) If anyone needs translation from Russian: The way this works is a g-code filter, which generates a reverse g-code for a particular g-code line and inserts it _before_ this particular g-code line with a / symbol in front of it. It seems like a change in Axis GUI script to redefine zoom-in and zoom-out buttons, so that it starts taking into account all the lines with / symbol in front of it, when asked to reverse. A little comment from me: It is obvious that this approach can easily reverse _current_ line being executed. But it is not clear to me, how to back up more than one line - it might be necessary if the code consists of really tiny G1 moves. -- Viesturs If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
If anyone needs translation from Russian: The way this works is a g-code filter, which generates a reverse g-code for a particular g-code line and inserts it _before_ this particular g-code line with a / symbol in front of it. It seems like a change in Axis GUI script to redefine zoom-in and zoom-out buttons, so that it starts taking into account all the lines with / symbol in front of it, when asked to reverse. A little comment from me: It is obvious that this approach can easily reverse _current_ line being executed. But it is not clear to me, how to back up more than one line - it might be necessary if the code consists of really tiny G1 moves. -- Viesturs Thanks Viesturs - now I understand what this code was doing: it set/resets block delete it abort execution then restarts a line behind or a line in front It's a really smart bit of thinking! def zoomin(event=None): c.set_block_delete(0) s.poll() c.abort() c.wait_complete() c.auto(linuxcnc.AUTO_RUN , (s.motion_line-1)) def zoomout(event=None): c.set_block_delete(1) s.poll() c.abort() c.wait_complete() c.auto(linuxcnc.AUTO_RUN , (s.motion_line+1)) -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
2013/2/4 Chris Morley chrisinnana...@hotmail.com: If anyone needs translation from Russian: The way this works is a g-code filter, which generates a reverse g-code for a particular g-code line and inserts it _before_ this particular g-code line with a / symbol in front of it. It seems like a change in Axis GUI script to redefine zoom-in and zoom-out buttons, so that it starts taking into account all the lines with / symbol in front of it, when asked to reverse. A little comment from me: It is obvious that this approach can easily reverse _current_ line being executed. But it is not clear to me, how to back up more than one line - it might be necessary if the code consists of really tiny G1 moves. -- Viesturs Thanks Viesturs - now I understand what this code was doing: You are welcome! it set/resets block delete it abort execution then restarts a line behind or a line in front It's a really smart bit of thinking! def zoomin(event=None): c.set_block_delete(0) s.poll() c.abort() c.wait_complete() c.auto(linuxcnc.AUTO_RUN , (s.motion_line-1)) def zoomout(event=None): c.set_block_delete(1) s.poll() c.abort() c.wait_complete() c.auto(linuxcnc.AUTO_RUN , (s.motion_line+1)) I read the whole thread, it seems that guys back there have some stability issues - it seems that it sometimes does not remain in auto mode. Not sure, if I understood correctly, but it seemed somewhat related to using those zoom-in and zoom-out buttons - in later posts they tried some commands to wait for auto mode and then continue (sorry, I do not understand python code, so cannot explain. In other post they receive error messages in Axis about cannot set TRAJ_SET_TELEOP_ENABLE in auto mode with interpreter idle, so it seems that there are some other workarounds to this, but not completely successful. -- Viesturs If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] custom EDM configuration questions
Sure, you can say an EDM will never make a spindle synchronized move, but changes to the motion module need to do sane things regardless of what kind of a machine is being controlled. What about different motion modules optimized different classes of applications? Yes Peter I think your on the best track. Unfortunately that's a big chunk of code to try and understand to change it. I wish there was some way to write down the flow of linuxcnc and keep it current. It's like walking in the dark with a plain sheet of paper as a map :) Chris M -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
