Back
[00:00:48] <cradek> since G43H3 / G43H13 doesn't show up anywhere in emctop
[00:11:13] <cradek> not a bugfix not a bugfix not a bugfix not a bugfix not a bugfix
[00:12:55] <jmkasunich> heh
[00:15:06] <cradek> dangit I don't want to run trunk already
[00:15:12] <cradek> [post-branch]
[00:17:49] <cradek> when writing that I thought it's so rare to have more than one offset per tool that it won't matter
[00:18:04] <cradek> for this setup I have two tools that way
[00:18:16] <cradek> one is just two drills mounted in one turret position
[00:18:34] <cradek> the other is a triangular insert and I use two corners
[00:19:13] <cradek> oh heyyyy my tool numbers are %8 so I just have to renumber those two 'extras'
[00:19:50] <cradek> that's the ticket
[00:19:51] <jmkasunich> two drills in one spot? offset in X?
[00:19:55] <cradek> * cradek debates with himself
[00:19:58] <cradek> yes
[00:20:08] <cradek> spot drill and normal drill side by side
[12:32:28] <jepler> sooo I never made time to work on stepconf this weekend
[12:47:31] <skunkworks_> nobody is judging you..
[13:03:29] <cradek> weekends are sooo short
[17:00:31] <aystarik> jepler: hi
[17:02:37] <jepler> hi aystarik, what's up?
[17:03:55] <aystarik> I've sent a patch to emc-devel, to add spindle speed display to axis... no response.
[17:04:20] <aystarik> is it rejected?
[17:04:51] <jepler> right now we are only fixing bugs. soon we'll create a branch for 2.3 and start putting new features on TRUNK for 2.4.
[17:05:35] <aystarik> ok. thanks
[17:05:49] <jepler> that patch simply adds commanded spindle speed to the DRO?
[17:07:02] <aystarik> no, to preview window. with the optional disable in menu -- as DTG.
[17:07:47] <jepler> er, that's what I meant (the big ugly dro is fairly new, if I say "DRO" I probably mean the one that's shown over the 3d plot)
[17:09:30] <aystarik> right
[17:10:43] <jepler> I hope we'll do beta2 next weekend and then branch, so ping me about this again then
[17:10:54] <aystarik> ok.
[17:11:45] <jepler> hmm, just a few other notes since you've got me thinking about it:
[17:12:11] <jepler> - there's some code that makes the spindle-related buttons in the MDI tab disable when there appears to be no spindle speed control available. Maybe this new item should disappear under the same circumstances?
[17:12:44] <jepler> - it should probably be shown on both the 3d overlay and the big ugly dro; I think that may be done right now by code duplication but I'm not sure
[17:13:13] <jepler> - the s-number is supposed to show in the misnamed "active g-codes" on the mdi tab but I see it's pushed off by other data. maybe find and kill that code too
[17:14:03] <aystarik> why? it's the interpreter state.
[17:15:56] <jepler> hm, I think I see what you mean -- they can differ
[17:16:50] <aystarik> on first, add "FWD", "REV" in such case?
[17:19:10] <jepler> if there's direction control but not speed control, show "Spn: FWD"? that'd be nice
[17:21:01] <SWPadnos> FWD/REV/OFF
[17:22:13] <aystarik> right
[17:24:29] <jepler> bbl, lunchtime here
[18:18:50] <cradek> even if there isn't speed control, you have to program a nonzero S word. So speed +n or -n would still show
[18:18:58] <cradek> you might progam S1 for instance
[18:19:53] <alex_joni> I think they meant to display FWD/REV/OFF based on the spindle HAL connections which AXIS detects at startup
[18:20:03] <alex_joni> not based on the programmed S-word
[18:30:01] <micges> good evening all
[18:31:12] <micges> would someone look at this config:
http://www.emc-files.webpark.pl/polimery.tar.gz
[18:31:38] <micges> this is my gantry and I think threre are some bugs in there
[18:32:16] <micges> after homing all you can jog below min soft limit
[18:32:25] <micges> without any problems
[18:33:27] <alex_joni> it's empty here after downloading
[18:35:11] <micges> ups
[18:38:11] <micges> http://emc-files.webpark.pl/polimery.zip
[18:39:31] <micges> only Y is moveable
[18:43:57] <SWPadnos> you only have Y0 and Y1 connected to anything
[18:44:10] <micges> yes
[18:44:35] <SWPadnos> so how would you expect anything else to move?
[18:45:00] <SWPadnos> if you don't connect axis.0 and axis.2 somewhere, then X and Z commands never get to the hardware
[18:45:03] <alex_joni> I think it's a problem that you commented HOME_SEARCH_VEL and HOME_LATCH_VEL
[18:45:13] <micges> wait wait
[18:45:15] <alex_joni> you should make them 0 if you don't want them to work
[18:45:24] <micges> this is config changed to run without mesa
[18:45:32] <micges> only Y is moveing
[18:45:55] <micges> and after homing all (Y + XZ meanless)
[18:46:07] <micges> you can jog Y below neg limit
[18:46:14] <micges> on this config and real machine
[18:46:33] <SWPadnos> only Y (Y0 and Y1) have the motor-pos-cmd outputs from the motion controller connected to anything
[18:46:37] <alex_joni> SWPadnos: guess what micges wants to say, is that he hacked this config, so we can run it
[18:46:43] <alex_joni> X & Z are not important
[18:46:54] <alex_joni> after you home Y, you can move it below the min_limit
[18:47:03] <alex_joni> which is the buggy behaviour micges is trying to show us
[18:47:04] <SWPadnos> ah, "you will only be able to use Y" ...
[18:47:09] <SWPadnos> ok
[18:47:21] <alex_joni> micges: how far does it go?
[18:47:27] <alex_joni> further than -14 ?
[18:47:44] <micges> yes
[18:47:54] <alex_joni> n/m I saw in position.txt
[18:48:03] <micges> on machine was about 20mm from hard limit
[18:48:10] <micges> and it can reach it
[18:49:24] <alex_joni> you also have some offsets in the var file
[18:49:31] <alex_joni> 5222477.813106
[18:49:32] <alex_joni> 52232098.971935
[18:50:58] <micges> offsets at axis other than y is debrish
[18:51:25] <alex_joni> I think 5222 is Y
[18:51:31] <SWPadnos> should be
[18:51:57] <alex_joni> although the position in position.txt should be without offsets :)
[18:52:11] <alex_joni> crap, gotta pack :(
[18:52:33] <SWPadnos> on a separate but possibly related note, would it make sense to clear G92 offsets when you home?
[18:58:13] <cradek> no no no
[18:58:18] <cradek> good god no
[18:58:40] <cradek> err, I mean, why do you think that's a good idea?
[18:59:07] <jepler> cradek: G92 offsets baffle users when they're nonzero. ergo, it's a good idea to zero them out sometimes
[18:59:53] <SWPadnos> yep, that's the general thought
[19:00:06] <cradek> seems like sometimes (?) nuking offsets will make the offsets more baffling
[19:00:12] <SWPadnos> that could be
[19:00:29] <SWPadnos> it may make sense as an option though
[19:00:36] <jepler> * jepler hates options
[19:00:40] <cradek> I think we need a way to tell what offsets are in effect. they are mashed together in the stat buffer.
[19:00:46] <SWPadnos> [TRAJ]NUKE_OFFSETS_AT_HOME
[19:00:50] <jepler> cradek: I was just about to say that, but as a question
[19:00:54] <cradek> an option for the baffled user is also baffling
[19:01:00] <SWPadnos> yes, some window like Greg showed could be very enlightening
[19:01:03] <cradek> more options make it worse IMO
[19:01:14] <cradek> greg?
[19:01:17] <SWPadnos> depends on what "it" is
[19:01:19] <SWPadnos> Tormach
[19:01:48] <dgarr> question about [DISPLAY]GEOMETRY and rotations
http://imagebin.ca/view/cki0TTg.html
[19:01:49] <cradek> TLO and 'offsets' are separate in stat, I think
[19:02:17] <cradek> if each kind of offset was separate, we could present them all in the BIG DRO or equivalent
[19:02:18] <SWPadnos> a unified interface to variables would solve this as a side effect
[19:02:30] <cradek> I disagree
[19:02:38] <SWPadnos> aren
[19:02:47] <SWPadnos> aren't all offsets stored as variables?
[19:02:49] <cradek> offsets being variables just confuses the issue IMO
[19:02:57] <SWPadnos> vars, like in the var file
[19:03:14] <SWPadnos> (maybe I shouldn't spell it out all the way :) )
[19:03:35] <cradek> oh #3572423 is set to 3.2451! that's not enlightening. "G92 offset is X 3.2451, Y 0, Z 0" is
[19:03:48] <cradek> that's what the guis should present (IMO)
[19:03:54] <SWPadnos> I mean as a method to making a user-friendly display
[19:04:04] <cradek> (are we talking past each other?)
[19:04:07] <SWPadnos> could be
[19:04:26] <SWPadnos> actually, it seems likely
[19:04:26] <cradek> making the user know which #numbers mean which offsets is not UF IMO
[19:04:27] <SWPadnos> :)
[19:04:39] <SWPadnos> err
[19:04:40] <cradek> so showing #numbers is not the UF solution to this
[19:04:50] <SWPadnos> no, not as #5327=119.26
[19:05:36] <SWPadnos> I guess getting data out of the stat buffer is just as easy as getting data from a var, even with a good (and as yet nonexistent) interface
[19:06:02] <cradek> vars are internal to the interp, and therfore you have readahead
[19:06:17] <SWPadnos> hmmmmm
[19:06:18] <cradek> stat buffer is on the other end and is actually showing what is active as the machine runs (and also during MDI etc.)
[19:06:19] <SWPadnos> mmmmm
[19:06:44] <cradek> for instance look at emctop as a program runs that uses TLO - it shows the right things
[19:08:10] <SWPadnos> heh. I guess another tab behind the big-ass DRO could show this stuff :)
[19:09:11] <cradek> one of my visions (if you can call it that) for the BIG DRO is that we could add this kind of stuff to it willy-nilly without regard for, um, aesthetics
[19:09:41] <SWPadnos> so it becomes the BAUD - Big Ass Ugly DRO
[19:12:13] <dgarr> oops -- fixed typo:
http://imagebin.ca/view/riq5SkyI.html (re c rotation offsets)
[19:12:35] <cradek> dgarr: isn't that correct behavior? I mean, your machine's center of rotation doesn't change when you offset X does it? I'm not sure I even see what that can mean on your machine. It's like a lathe where X0 is the center of rotation and anything else is of questionable value (?)
[19:12:56] <cradek> maybe I am not understanding.
[19:13:53] <cradek> seems to me like you would actually get the pattern shown in the preview (i.e. it would increase the radius if you offset X)
[19:13:53] <SWPadnos> maybe XCYZAB ?
[19:14:03] <dgarr> the rotary axis is on a translation stage:
http://www.youtube.com/watch?v=BPGsMDM_UPU
[19:14:24] <SWPadnos> though you shouldn't need AB or Y, if they aren't present - I think
[19:14:45] <dgarr> correct- the ABY dont matter
[19:15:02] <SWPadnos> I'd try swapping X and C in the order
[19:15:08] <cradek> but if you offset X an inch, the radius of everything you cut increases an inch, like as shown in the preview, right?
[19:15:52] <dgarr> cradek: the machine moves correctly always cutting the pattern shown on the left
[19:16:12] <dgarr> SWPadnos: ive tried swapping, ng
[19:16:14] <cradek> I am not getting it then. let me read what you wrote a few more times.
[19:17:14] <cradek> still no :-)
[19:17:16] <dgarr> the display assumes the rotation is about a fixed, nonoffset alignment of the z axis. my machine, the z axis moves so the rotation needs to be about the offset axis (i hink)
[19:17:34] <cradek> are you saying that setting a 1" X offset makes no difference in the part you cut?
[19:17:37] <SWPadnos> you may need non-trivkins to do what you want
[19:18:53] <SWPadnos> and I'm not sure that will help either
[19:19:20] <dgarr> cradek: orignally i never used offsets. since i've started using axis, it is much more convenient to use the offset, it cuts correctly, only the display is off with offsets.
[19:20:03] <cradek> sorry, let me ask a different way. if you run a certain part program with no X offset and again with 1" X offset, how is the resulting part different?
[19:23:17] <dgarr> i don't use home switches so maybe the confusion is in how i establish tool position at start. if i do not offset, i must set the home (x=0 position) with the tool at the center of rotation. if i use offset, i can set the offset with the tool at a radius (x !=0)
[19:24:15] <cradek> ah I see, I think
[19:24:21] <dgarr> i guess i can't explain it right but i'm making real parts
[19:24:38] <cradek> if you home the machine with absolute X zero at the center of rotation, everything will work right
[19:24:54] <cradek> and I propose that you should do that
[19:25:10] <cradek> you can use an X offset to tweak the radius of your part, and the preview will be right
[19:25:31] <dgarr> yes both the cut and the axis display are right.
[19:25:44] <cradek> this is exactly what you do on a lathe setup too
[19:26:12] <dgarr> on cuts (not like the one pictured) along the side of a cylinder, sometimes it is inconvenient to go to the center and using the offset on the periphery is a great benefit
[19:26:47] <cradek> you don't have to move to the center, but you do have to set up the homing parameters to establish where it is
[19:27:17] <cradek> if one extreme of travel is 4" from the center, you could move there to home, and set HOME_OFFSET=4 or however you do it
[19:27:34] <cradek> then absolute machine coordinate X will always be radius
[19:27:56] <dgarr> i'll have to study that. i suppose HOME_OFFSET is an ini parameter. i may make several setups with out restarting
[19:28:07] <cradek> yes it's an ini parameter
[19:28:23] <cradek> what do you mean setups?
[19:28:41] <cradek> do you move the spindle wrt the X slide or something?
[19:29:29] <dgarr> cutting different patterns on the top or sides of a part. i don't move the spindle but i may move the tool (the tool is stationary during a cut however) --- i know this is an odd configuration
[19:30:01] <cradek> do you mean spindle = the thing turning the workpiece?
[19:30:41] <dgarr> my machine: spindle is the C rotary axis holding the workpiece.
[19:30:47] <cradek> ok, sorry I guess I meant 'do you move the tool' then
[19:30:53] <cradek> and the answer is yes
[19:31:01] <cradek> in that case, you can use a tool offset
[19:31:12] <cradek> with a lathe tool table, you can have X,Z tool offsets
[19:31:44] <cradek> and now, you can use touch off exactly the same way to set the tool offset
[19:32:29] <cradek> mount the tool, measure the resulting radius, select X, touch off, pick "T" tool table, enter the radius
[19:33:32] <cradek> so "T" moves the tool, G54 X changes the radius
[19:33:47] <cradek> brb, coffee is necessary
[19:33:58] <dgarr> i'll have to study that, thanks for your comments
[19:38:56] <micges> sorry for disturb but is this jog issue on my above config is bug or no ?
[19:41:10] <CIA-2> EMC: 03tissf 07TRUNK * 10emc2/docs/src/config/ini_config_fr.lyx: french translation update
[19:41:11] <CIA-2> EMC: 03tissf 07TRUNK * 10emc2/docs/src/gui/halui_fr.lyx: french translation update
[19:41:11] <CIA-2> EMC: 03tissf 07TRUNK * 10emc2/src/po/fr_axis.po: french translation update
[19:48:06] <alex_joni> micges: did you try removing the leftover offsets?
[19:49:49] <cradek> you could switch AXIS to show the absolute, not relative position
[19:51:35] <micges> yes I G92.1
[19:55:08] <micges> http://imagebin.ca/view/wjDEsJu.html
[19:56:20] <cradek> you clearly have an offset
[19:59:12] <cradek> ("origin" nonzero)
[19:59:32] <micges> http://imagebin.ca/view/2G1l55.html
[20:00:03] <cradek> there you go
[20:00:13] <micges> after clearing and restart
[20:00:31] <micges> no limits in both ways
[20:01:13] <cradek> hmmm
[20:01:34] <micges> is override limits checkbox cleared automagically after move from limit?
[20:01:52] <cradek> after one jog it is cleared
[20:02:09] <micges> in this config it isn't
[20:02:12] <cradek> oh wait, you are in teleop mode
[20:02:20] <cradek> in joint mode do the limits work?
[20:03:34] <micges> yes they do
[20:05:05] <cradek> teleop mode needs a lot of work unfortunately
[20:07:07] <micges> so it is unfinished or untested ?
[20:07:52] <cradek> a rewrite is planned. the original design, of which we have remnants, was inadequate for what we want today.
[20:09:27] <micges> ok
[20:09:59] <micges> next problem is not unchecking override limits checkbox in this config
[20:10:11] <micges> on real machine and now on laptop
[20:10:47] <micges> I've created panel checkbox simulating limit switch and it the same bahaviour on teleop and joint mode
[20:10:54] <cradek> I think jepler saw something like that the other day. I don't remember whether he looked into it
[20:11:14] <cradek> er, I meant don't know, not don't remember
[20:11:42] <alex_joni> didn't see a commit about it, so my guess would be no
[20:12:01] <alex_joni> micges: if you were jogging in teleop, then it probably doesn't work to limit you..
[20:12:20] <alex_joni> micges: do you gain anything from running a XYZY config?
[20:12:20] <micges> yes
[20:12:43] <micges> from standard configs ?
[20:12:44] <alex_joni> vs. only links from Y to 2 stepgens?
[20:12:56] <alex_joni> in HAL I mean..
[20:13:18] <alex_joni> not sure if my question made sense for you..
[20:13:41] <micges> you mean unlink 3 joint comletely ?
[20:13:55] <alex_joni> I mean only have a XYZ configuration in the ini file
[20:14:05] <alex_joni> and use the axis.1.position to connect to 2 stepgens
[20:14:13] <micges> I see
[20:14:20] <alex_joni> and feedback the sum of the errors, or something like that
[20:14:27] <micges> moment
[20:14:32] <cradek> yeah, if you can avoid kins, do that
[20:15:18] <alex_joni> at the moment I don't see much of an gain for a gantry to use kins
[20:15:38] <alex_joni> it would be if emc2 could do better homing
[20:16:29] <rayh> do we still have a board list at SF?
[20:16:34] <alex_joni> yup
[20:16:44] <alex_joni> full of spam even
[20:16:47] <rayh> thanks Alex
[20:16:58] <alex_joni> (since we allow posting from non-members, after moderation obviously)
[20:17:06] <cradek> hi ray
[20:17:19] <cradek> are you going to post your thoughts about fest?
[20:17:55] <rayh> emc-board@lists.sourceforge.net ??
[20:18:07] <rayh> Hi Chris.
[20:18:36] <rayh> Sort of going to do that. I got a message from a curious fellow who attended last year.
[20:18:43] <cradek> yes that's it
[20:19:04] <rayh> Maybe I can't post to that list, not being a member and all.
[20:19:07] <cradek> I mean to -users, where we tried to start a conversation
[20:19:19] <rayh> Oh.
[20:20:30] <cradek> seems like people are going to need to start making travel plans soon
[20:20:56] <rayh> Well I can do that. Give me a bit to sweep my thoughts together into a pile.
[20:21:12] <cradek> haha I know the feeling
[20:21:26] <alex_joni> bbl
[20:29:28] <micges> cradek: trivkins in this config make results the same
[20:29:52] <micges> cradek: don't bother any more today
[20:29:58] <micges> bbl
[21:29:02] <alex_joni> good night all
[21:46:58] <rayh> Okay the post is on the way to the user group.
[23:57:43] <SWPadnos> huh. has anyone else received Ray's message yet?
[23:58:01] <cradek> no
[23:58:11] <SWPadnos> oh good. it's not just me