On Jan 14 2017 3:40 AM, Gene Heskett wrote: > On Saturday 14 January 2017 04:09:28 John Morris wrote: > >> On 01/13/2017 08:39 AM, Gene Heskett wrote: >> > On Friday 13 January 2017 04:05:51 John Morris wrote: >> >> On 01/07/2017 02:42 AM, John Morris wrote: >> >>> I've been asked about some seemingly unintuitive behavior: the >> >>> max velocity slider is not applied to rotary-only motion. You >> can >> >>> try this yourself by running the `axis_9axis.ini` config, >> setting >> >>> the max velocity slider to zero, and noting rotary axes still >> move >> >>> after e.g. `g0 a180 f40`. >> >> >> >> So, I now have a proof-of-concept branch that plumbs a max >> angular >> >> velocity from the UI to TP and back. Similar to max [linear] >> >> velocity, it uses units (degree)/minute. In the Axis GUI, it's >> >> easy to scale max angular velocity proportionally to (max >> >> velocity)/([DISPLAY]MAX_LINEAR_VELOCITY) wrt >> >> [DISPLAY]MAX_ANGULAR_VELOCITY. The plumbing involves adding >> extra >> >> args or fields to existing functions, structs and NML messages >> >> related to max velocity, so when one is set, the other is always >> >> set at the same time. >> >> >> >> However, I'm leaning away from submitting the changes for >> mainline >> >> inclusion. My heart isn't really in this one, and I'm not >> feeling >> >> the passion for doing what it takes to ready it for GA (sincere >> >> thanks to Norbert for offering to do the gmoccapy integration!), >> >> although I'm happy to push it somewhere if anyone's curious. >> >> Thanks again for all the replies. >> >> >> >> John >> > >> > This one I can see a need for. I don't often have my table mounted >> > and plugged in, but I have often, thru sloppy coding no doubt, had >> > lcnc ask the table for a faster move than the motor can muster up >> > because that cheap $100 when I bought it years ago table has so >> much >> > backlash that I've tightened it up so that I need to apply an >> > airhose to exert some internal lifting pressure by easing the >> > holddowns friction, an air bearing of sorts. I made a hole into >> the >> > side of the base casting, and a hole in the bearing face that >> > intersected that hole, and a groove for that air all the way >> around >> > the face of the base casting. Without that, perhaps a whole minute >> > for a whole 360 turn. any faster and the motor will stall as its >> > only a 220oz nema23. I've a 12 volt compressor I've always >> intended >> > to rig so I could turn it on with gcode, wait a second for >> pressure, >> > and turn it off when the move was done. But so far that itch >> hasn't >> > been scratched. What I really need is a bigger table that doesn't >> > mount the motor at an angle so its always hitting something. >> > >> > So this one I'll vote up by 1. Being able to limit it, and make >> the >> > rest of the program wait on the slow table, would be helpful to >> me. >> >> As long as your rotary axis has a correct e.g. >> `[AXIS_3]MAX_VELOCITY` >> parameter set, mainline LCNC will do the right thing, and the linear >> axes' velocity will be limited as appropriate by the rotary axis to >> produce coordinated motion (the converse is also true). I actually >> wrote a unit test in this branch that verifies this. So if I'm >> understanding your concern, you're already covered, and don't need >> these changes. >> >> These changes apply only to those wishing to apply the max angular >> velocity slider setting (whether combined with or separate from the >> existing max velocity slider) to pure rotary motion. Many folks >> needing needing to limit pure rotary motion can still use feedrate >> (in >> degrees/minute) for pure rotary G01 A/B/C moves, and there's a >> separate angular jog speed slider in Axis that appears when a rotary >> axis is configured. >> >> John > > What I would try and do, is a wrapper around the angular motion that > starts the little compressor, but exerts a motion hold for long > enough > for the pressure to come up and free the table, say about 1.5 > seconds, > then does the move at 10x the speed, then stops the compressor, > exerting > a motion hold for about thats same 1.5 seconds while the pressure > bleeds > away. Both motion holds would of course be queue breakers, but for > long > moves, like sharpening a tool with a diamond disk, where the moves > would > be say 95 degrees, it would still be faster. > > Sure, I can write it in gcode, but making it work completely self > contained would be handier than that famous sliced bread or bottled > beer. As is I have to set that angular speed limit to about 5% of > what > it can do if 100 psi of air is being fed into the face groove. > > So, I guess I'll keep writing code the old way. But I'd still need 2 > or 3 > more mist/flood type of control signals out of motion on the G0704 as > I > have already repurposed both mist and flood, the m7-8-9 functions on > that machine. m7 turns on the vacuum cleaner for chip collection, and > m8 > enables a positioning flapper to fall down when a new piece of wood > is > being mounted, and an m9 turns off the vacuum and lifts the flapper > out > of the way so its not destroyed by the machining of the same face the > flapper sets the position of. The machine is lifted far enough the > flapper is clear to swing, and it has to run about 13" to start the > next > pass, so I turn the vacuum back on as it lowers the head for the next > pass. 10 seconds of peace and quiet, :)
It seams a little heavy handed to repurpose M7-9. My not just define your own M101-199? That does pose the question that vacuum chip removal that we should probably find and implement a code for it (or a code that toggles yet another power plug). I can intuit repurposing a power switch for the vacuum, but if anyone reads your code they might not know that you repurposed the coolant to vacuum on that machine. Also, if there is any type of feedback line, you could try putting a pressure regulator in line, or maybe a delay circuit/relay in the path. I once had a machine with something lie this <http://timerco.com/index.php?l=product_detail&p=41> wired in. What I am thinking is that a change of state of the air valve triggers a 1.5 second signal trigger. You may be able to wire it inline with whatever you use to read tool-touchoffs and as soon as the line goes active again, you continue the program. Just a thought, and without looking at the schematics of your machine I am not sure what could be wrangled. Also, isn't there some way to access any GPIO pins external to the main controller? Somewhere I thought I saw someone hooking up an arduino, triggering a program, and waiting for a response. Maybe that was not with LCNC... Anyway, hope that helps. EBo -- ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
