Back
[03:05:46] <KGB-linuxcnc> 03Chris Morley 05qtvcp-2.7 af1c3c9 06linuxcnc 10(5 files in 3 dirs) qtvcp -add icon loader for qt designer * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=af1c3c9
[04:33:09] <automata> IS there a motion.* pin that indicates a spindle sync motion is in progress right now?
[04:33:55] <automata> I could not find it.. So my next question is whether such a pin can be created?
[04:38:09] <archivist> see motion.in-position which is the inverse
[05:59:23] <automata> motion.in-position only indicates if the axes are moving
[05:59:42] <automata> I am specifically looking for spindle synchronized motion in progress
[09:42:58] <cradek> darn, missed automata
[09:45:17] <skunkworks> does the motion type pin show synced motion?
[09:50:35] <cradek> I'm too tired to look.
[09:50:59] <archivist> not according to
http://linuxcnc.org/docs/html/man/man9/motion.9.html
[09:52:04] <archivist> but one could have a combination, so is that set of values sensible
[09:53:21] <seb_kuzminsky> i think it's sensible
[09:53:28] <seb_kuzminsky> there might be some values missing
[09:53:41] <seb_kuzminsky> and sometimes there's no motion, so there should be no motion type, but there's no mention of that
[09:54:04] <cradek> I think it might go to zero
[09:54:14] <seb_kuzminsky> that would be good :-)
[09:54:46] <seb_kuzminsky> yeah, looks like it
[09:55:18] <seb_kuzminsky> it's also 0 whiel homing
[09:55:26] <seb_kuzminsky> and jogging
[09:55:47] <seb_kuzminsky> you can't have everything, as they say
[09:55:54] <seb_kuzminsky> unless you write it, i mean
[09:56:09] <seb_kuzminsky> well, off to work
[09:57:04] <skunkworks> we we are || close to getting the edm running. have 55 gallons of edm oil coming..
[09:59:43] <archivist> I think perhaps it should be a bit field, what is the difference between a traverse and a linear move
[10:12:13] <seb_kuzminsky> linear move is g1, traverse is g0
[10:12:22] <seb_kuzminsky> the wording is not very clear
[10:17:14] <seb_kuzminsky> the manpage alreadys says "traverse", "linear feed", and "arc feed", that's actually pretty good
[10:23:52] <archivist> I cannot see how traverse means g0 unambiguously
[10:25:04] <cradek> we usually call it "rapid":
http://www.linuxcnc.org/docs/html/gcode/g-code.html#gcode:g0
[10:25:32] <cradek> I think "traverse" is from the old ngc doc and I agree it's unclear
[10:26:14] <cradek> the docs mention but don't define "the traverse rate"
[10:27:00] <cradek> I wonder what problem automata was trying to solve by having this pin
[10:41:11] <archivist> me running the rotary at the same time as g1 so not linear or indexing :)
[10:41:27] <archivist> or a plain arc
[10:43:10] <cradek> g1 a... x... is still a linear feed
[10:46:41] <archivist> but it cuts an arc/spiral/helix
[10:47:06] <archivist> linear would be a straight line
[10:48:42] <archivist> if linear means tied to g1 then again not unambiguous
[11:02:49] <cradek> I agree with you, please fix it
[11:05:26] <archivist> actually I can think why a new pin is needed, with the value of the gcode in use (to not break any old program
[11:06:22] <archivist> and I imagine some of the odd kins break the meanings
[11:13:24] <cradek> no, it only means g0 vs g1 vs g2/g3 vs g38.x - it has nothing to do with kins, or what shape you're cutting
[11:21:15] <archivist> so new pin with actual gcode number would be more usable probably as g33 or g76 any would all become visible
[11:21:43] <cradek> hm that would be a good way to present it
[11:22:05] <archivist> and is just about future proof
[11:22:11] <cradek> would have to be careful with documentation becasue it wouldn't have all codes of course, just those that make motions
[11:22:27] <cradek> you'd lose 0 for no motion...
[11:22:55] <cradek> I wonder what problems people solve using that pin
[11:23:03] <archivist> there was no 0 in that list
[11:23:04] <cradek> I have never used it except for debugging motion
[11:24:14] <archivist> I think it needs to be a new pin to avoid breakage if anyone does use it
[11:24:40] <cradek> that's sure an argument for just adding another value to the existing one
[11:24:54] <cradek> I'd like to know what problem we're solving
[11:25:20] <archivist> automata, is back in channel, perhaps he will say
[11:25:46] <cradek> automata: you asked about motion pins - what problem do you have that led you to ask this question?
[12:01:29] <automata> If we are tapping an there is a power loss, some method of recovery needs to be provided...
[12:02:08] <seb_kuzminsky> automata: ouch, that'd be a scary situation
[12:02:22] <seb_kuzminsky> is your control computer on a UPS, but the machine itself is not?
[12:02:24] <automata> on big iron removing a M12 or M16 Tap by hand from a stuck tap, now that is not possible...
[12:02:49] <automata> It only means loosing the job or the tap... and that is not an easy decision...
[12:03:05] <cradek> how would this motion pin help with that situation?
[12:03:16] <automata> yes control computer can be on UPS...
[12:04:31] <automata> to start with a recovery cycle, There should be a power fail input relay that triggers a saving of the current tapping mode (ON/OFF) and maybe the tapping pitch on the HDD
[12:05:52] <automata> then aftr power cycle, a retract only cycle could be run (G33 with only M4 instead of M3)
[12:06:09] <seb_kuzminsky> when you have a power failure, do the encoders run off the UPS? otherwise you still can't recover, right?
[12:06:34] <seb_kuzminsky> because you've lost the sync you need to unscrew the tap
[12:06:39] <automata> Nope, the encoder counts are not stored.
[12:06:58] <automata> We need to run an MDI command with no force homing
[12:07:57] <seb_kuzminsky> if the encoders lost power, then the rotation of the spindle & tap is not known, and i don't see how unscrewing the tap would be possible
[12:08:00] <automata> The MDI command would be a standard spindle sync move in only one direction
[12:08:41] <automata> Once a tap is stuck, you assume that during the stopping the tap and job are both still intact.
[12:08:51] <seb_kuzminsky> hmm, yeah
[12:09:14] <cradek> does that actually happen? On my machine I'm sure the spindle inertia would immediately break the tap if the power went out
[12:09:20] <automata> If you know the pitch of the tapping cycle, you could command the Z axis to move in sync with the spindle rotation
[12:09:37] <automata> it could be done via a separate HAL program too
[12:09:40] <jepler> the thread you get from starting with M4 at a random Z coordinate will not match the thread you get starting with M3 at a known Z coordiante
[12:09:42] <automata> need not be too fancy
[12:10:23] <automata> in this un-tapping cycle we should not be looking for an index pulse sync
[12:10:47] <automata> just chain the Z motion to the spindle encoder by the thread pitch
[12:11:09] <automata> I have actually recovered a M12 tap using this method.
[12:11:34] <automata> Now I was hoping to detect this situation automatically
[12:12:18] <automata> I wrote a small HAL component which just set the Z position based on the current spindle position.
[12:13:05] <automata> Upon reaching a certain height, it sent an off command to the spindle and as the spindle stops moving, the Z Axis also slows to a stop without any jerk
[12:13:14] <seb_kuzminsky> neat!
[12:13:37] <seb_kuzminsky> that sounds like something andypugh would do :-)
[12:14:02] <automata> another place where This pin would be helpful would be to allow turning off the spindle during a feed hold
[12:14:36] <automata> ;-)
[12:15:23] <automata> when a feed hold is commanded, I would like a pin to turn off the spindle. This would enable to take some measurements on the job
[12:15:41] <cradek> you can turn spindle override to 0% and the spindle stops
[12:15:50] <pcw_home> tap recovery sounds like something that just needs a special hal/ini file for recovery, not linuxcnc changes
[12:16:39] <cradek> you could also use your own hal logic to turn off the spindle, or a hard power knob like hand/off/auto
[12:16:54] <automata> then on releasing the feed hold, the spindle should rev up to the commanded speed before the feed axes actually start motion
[12:17:38] <cradek> if you manually turn the spindle off, you should do the opposite explicit thing to turn it back on
[12:18:04] <automata> PCW: I agree that tap recovery needs hal components. But to automate those components, information about the current running mode is required
[12:18:41] <automata> cradek: How to wait for spindle-at-speed before feed hold is released?
[12:19:35] <cradek> releasing feed hold is a thing the human does. the human should do it at the appropriate time.
[12:20:25] <cradek> after explicitly turning the spindle on, I think all humans will naturally wait for the spindle to sound right (up to speed) before releasing feed hold
[12:20:52] <cradek> brb
[12:21:58] <automata> I was hoping to try to look for spindle at speed via a hal component before applying a feed hold release
[12:22:51] <automata> and Only allow spindle override=0 to be issued when there is a feed hold commanded
[12:23:21] <automata> commanded feed-hold is ignored when a spindle sync is in progress
[12:28:16] <automata> I could use a motion.current-vel to tell if a feed hold command has been executed
[12:34:05] <automata> I was hoping that since rob was looking at spindle sync more closely right now, a new value for motion.motion-type or a new pin for spindle-sync in progress could be done
[12:36:22] <pcw_home> not sure that automating tap recovery is a good idea...
[12:37:20] <pcw_home> seems like a very special case
[12:37:40] <pcw_home> (and one that needs human intervention)
[12:41:53] <automata> yup.. But this could automatically pop up a message box about a stuck tap with the pitch settings which the operator need only press OK and tap recovery should start
[12:42:13] <automata> if the operator presses cancel, tap recovery will not start
[12:43:03] <automata> automation is only to level of automatically informing the operator about the tap being stuck and hints about the recovery settings
[12:43:33] <automata> I believe that the more information you can give the operator the easier their job will become
[12:45:45] <pcw_home> Is the PC on a UPS?
[12:46:43] <automata> PC may have a UPS or a brown out detector which will save settings on disk
[12:47:01] <automata> via a userland hal component
[12:47:08] <pcw_home> Sounds rather iffy to me
[12:48:26] <automata> I have integrated a FRAM chip over SPI using a MESA FPGA. That way I can save the current mode to FRAM every servo-cycle too
[12:49:26] <pcw_home> but the physical state of the machine is still rather unknown
[12:50:08] <automata> option should be given to the operator whether to run tap retract...
[12:50:35] <automata> the controller cannot automatically decide on running the cycle.. operator intervention is a must..
[12:50:45] <automata> this is only to help the operator out..
[12:51:45] <pcw_home> if the operator cant tell the a tap buried in the work at startup, you need a new operator :-)
[12:52:04] <automata> ;-)
[12:52:34] <automata> you will be surprised at the level of operators we have to deal with
[13:02:07] <automata> Irrespective of the usage of the spindle sync motion pin, it should be helpful in other ways to get that information in the hal fabric
[13:02:24] <automata> I was hoping to get some tips on how to add it in...
[13:05:22] <seb_kuzminsky> automata: what exactly is the change that you want tips on how to add? is it a pin that shows the currently executing g-code?
[13:07:09] <automata> Currently executing motion type from tc segment
[13:07:33] <automata> does tc have information on spindle sync move?
[13:08:06] <seb_kuzminsky> yes, this information is available inside Motion, which is where TC lives
[13:08:30] <automata> when should that pin be reset to idle / no motion state?
[13:08:44] <seb_kuzminsky> have you seen this diagram?
http://linuxcnc.org/docs/devel/html/code/code-notes.html#_motion_controller_introduction
[13:09:36] <automata> yes
[13:10:38] <seb_kuzminsky> automata: if you had a pin that did sort of what motion.motion-type did, but with some difference that i dont really understand, i'd guess it'd go to "idle" when motion was "in position", as per the motion.in-position pin
[13:11:41] <automata> I suppose control.c/process_inputs or control.c/get_pos_cmds would be a good place to inspect the currently executing tc segment?
[13:11:59] <seb_kuzminsky> i'd look for where motion.motion-type is updated
[13:12:16] <automata> ok..that is a good start
[13:12:18] <seb_kuzminsky> because it sounds like that pin does nearly what you want
[13:12:21] <automata> doing that now
[13:13:06] <seb_kuzminsky> cool
[13:13:20] <seb_kuzminsky> i'd also like to direct you to this document, if you haven't seen it already:
http://linuxcnc.org/docs/devel/html/code/contributing-to-linuxcnc.html
[13:15:38] <automata> thanks seb_kuzminsky
[13:20:16] <automata> tc_types.h already has the definition of a TC_segment as one of 4 items (TC_LINEAR, TC_CIRCULAR, TC_RIGIDTAP, TC_SPHERICAL)
[13:20:40] <automata> the idea would be to get this information out to a motion.pin
[14:12:30] <seb_kuzminsky> yeah, i would think at that level, the g-code is long forgotten and the distinction between feeds and rapids no longer exists (except maybe as some kind of "wait for spindle-at-speed" flag)
[15:14:32] <skunkworks__> bpuk, was there a spec you guys where going by for the G71/72?
[15:15:26] <skunkworks__> I am having a heck of a time figuring out the moves needed initially to get sane results.
[15:17:09] <bpuk> it's a modified fanuc spec - I never wrote it up in too much detail
[15:17:59] <bpuk> any profile should be in one of four quadrants, starting position should tell G71/72 which quadrant it's in (i.e. if the starting position is below, to the right - you're probably in the bottom right quadrant)
[15:18:27] <bpuk> and I _think_ andy has kept to that convention
[15:19:21] <bpuk> that answer your question? or have I misunderstood
[15:20:12] <skunkworks__> ok. I just need to play with it more :)
[15:20:19] <skunkworks__> I think I am getting it
[15:21:30] <bpuk> the plan is to create detailed docs before final release ;)
[15:22:07] <skunkworks__> it is just figure out how to get it to cut the right direction and the right direction
[15:22:19] <bpuk> so - once we hit that point, the more questions you have, the better the docs
[15:22:34] <bpuk> gotcha - should be mostly defined by the starting position
[15:23:09] <skunkworks__> starting position in relation to the profile?
[15:23:39] <bpuk> yes
[15:23:47] <skunkworks__> ok
[15:56:57] <CaptHindsight> seb_kuzminsky: please excuse my ignorance of Debian, what is the problem with getting a stable Jessie RTAI kernel? Does Jessie require a kernel of some certain version or above?
[15:57:30] <CaptHindsight> Why doesn't a RTAI kernel for Wheezy work with Jessie?
[15:59:12] <cradek> it sorta might, but one of the reasons people want new kernels is for support of new hardware
[16:01:28] <CaptHindsight> are newer drives what causing the instability or is the reason still unknown?
[16:01:36] <CaptHindsight> drives/drivers
[16:01:50] <cradek> I don't know the details, sorry
[16:02:00] <jepler> the kernels that seb_kuzminsky built were unstable on his buildbot vms, and no heroic kernel debugger has resolved the problem
[16:02:18] <jepler> being unstable for the buildbot, they have never been promoted for general users
[16:02:28] <jepler> we don't really know how good or bad they are on real, non-virtual hardware
[16:02:45] <jepler> but if we can't run them on our buildbot then it doesn't seem likely to be good news
[16:04:22] <CaptHindsight> and Wheezy is only supported until May 2018
[16:09:35] <CaptHindsight> I'll ask memleak to build one the next LCNC project that needs Jessie
[16:12:18] <jepler> someone volunteering is the only way it's going to get done. please keep in mind the product we ship from linuxcnc.org will need to have a debian source package so we know we're meeting our GPL obligations. and it'll need to work right in kvm/qemu virtualization for buildbot. and on a wide range of actual computers...
[16:13:13] <jepler> (no wonder nobody's done it)
[16:14:32] <CaptHindsight> well if we need Debian he'll do that
[16:15:37] <CaptHindsight> he's been building all sorts of customs things and Gentoo lately
[16:34:19] <cradek> that would be great
[16:34:43] <cradek> if we had a good kernel package we might be halfway to making a new cd
[17:33:35] <skunkworks_> andypugh,
http://electronicsam.com/images/KandT/testing/Screenshot-40.png
[17:35:19] <andypugh> Well, yes, but, what would you like it to do?
[17:35:19] <skunkworks_> still not understanding it 100% as far as the start move but getting there
[17:35:21] <skunkworks_> http://pastebin.ca/3746764
[17:35:41] <skunkworks_> well - I wouldn't think the shuttle moves would go into the part
[17:36:04] <andypugh> You are driving the tool straight into the material, it’s a bit hard for it to work out a retract
[17:36:13] <skunkworks_> but could I be expecting too much? I also don't really know the scope of it
[17:36:38] <skunkworks_> ah - maybe that is it. I was trying to get it to cut from out to in but ran out of time
[17:36:50] <skunkworks_> (I will keep playing with it )
[17:37:02] <andypugh> If you are cutting right to left then it cant retract to the left, there is still metal there.
[17:37:43] <seb_kuzminsky> CaptHindsight: i spent a bunch of time building and testing RTAI 5.0-test1, it worked fine except it seems like there was a race condition during shutdown, and running the linuxcnc test suite would trigger it frequently
[17:37:45] <andypugh> It would actually refuse to make the part if you had a tool loaded with frontangle and backangle set
[17:37:56] <seb_kuzminsky> it presents as a lockup while unloading the rtai modules
[17:38:14] <seb_kuzminsky> i had some back and forth with the rtai dev on the mailing list but we never resolved it
[17:38:48] <skunkworks_> andypugh, duh - again - I will play with it more. (I will get the hang of it)
[17:42:48] <seb_kuzminsky> CaptHindsight: i see there's a new kernel patch with some smp-related fixes, maybe i should try again
[18:34:39] <skunkworks_> andypugh, ok - I give up.. :) how would you make a profile that cuts from right to left with G72 cut from the outside to inside?
[18:35:43] <andypugh> Why this enthusiasm for G72?
[18:42:59] <skunkworks_> heh - well - g71 seemed to do exactly what I thought...
[18:43:05] <skunkworks_> g72 - not so much
[18:44:15] <andypugh> http://www.pastebin.ca/3746773
[19:19:15] <andypugh> skunkworks_: Did you see that example?
[19:21:56] <skunkworks_> yes - have not had a chance to play with it yet
[19:22:01] <skunkworks_> thank you though
