JT Lets leave it as is for now. I am busy with my next build already and I will test all the features properly and give feedback.
On 2014-07-08 12:45, John Thornton wrote: > Seems to me the biggest problem is swapping topics of the conversation > back and forth between corner lock tolerance (which works fine) and > correction velocity. It has my head spinning and gives me a headache. > > > On 7/8/2014 5:39 AM, Gene Heskett wrote: >> On Tuesday 08 July 2014 03:19:17 Marius Liebenberg did opine >> And Gene did reply: >>> Yes I will try. Even though the F word asked for say 3500mm/min, the >>> planner will slow the feed rate down when it comes to the end of a >>> segment. If the next segment is at an acute angle to the current one >>> then the velocity will slow down towards the corner. Once the corner is >>> turned, the velocity will accelerate again to match the F word. During >>> this slow down period the torch voltage will change due to the fact >>> that more metal is blown away and it then seems like the torch is to >>> high. The THC will bring the torch down and crash it into the job. >>> So its not the F word that changes but the way the planner accelerates >>> and decelerate the system as it moves with every Gcode request. >>> >>> If you have a very light weight gantry on a plasma you can set the >>> acceleration parameter very high and this problem becomes less >>> noticeable. But for bigger machines this is a real problem. If you look >>> at the latest work Les Newell (Sheetcam) has done on the plasma post >>> processors to enable users to include programmable codes that will stop >>> THC at a distance before a corner and resume at a distance after the >>> corner again, you will get an idea of how much of an issue this is. >> I'm understanding you to say that when its slowing down for the corner, >> the THC meeds to be disabled to keep it from crashing into the work? But >> it is not turned off. >> >> I probably don't fully understand the problem. But it seems to me a bit >> of work in the hal file, adding a wcomp to compare the requested speed to >> the F word speed could be cobbled up, with the idea being to freeze the >> THC, wherever its at, when the requested speed has dropped below whatever >> percentage you set in the wcomp settings. I can imagine that would cause >> it to cut a slightly wider cut though, so I would think allowing some >> lowering of the head might result in a more precise cut. >> >> Another approach, also in the hal, might be to lower the THC's control >> gain, which might let it get close, but not crash, and crank the gain back >> to normal when the actual speed is normal, following the accel as it >> speeds up after the corner. The equ of switching the control off, but >> perhaps smoother. >> >> Success of that approach depends on what sort of signals can be extracted >> from the motion module of course. >> >> After showing how little I know about it, I'll get me coat now. :) >> >> Cheers, Gene Heskett > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > -- Regards /Groete Marius D. Liebenberg +27 82 698 3251 +27 12 743 6064 QQ 1767394877 ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
