Back
[15:24:36] <tomp> is HAL_NAME_LEN applied to HALUI ? ( the additional chars of 'halui' plus 'dot' would use 6 of the available 41 )
[15:52:34] <alex_joni> tomp: HAL_NAME_LEN is applied to all hal pins
[15:52:45] <tomp> thx
[15:53:02] <alex_joni> still better than "iocontrol.0.*"
[15:53:18] <alex_joni> but do you have such long pin names?
[15:53:48] <jepler> if.you.hit.the.limit.you.should.rethink.your.names (whoops, that's too long!)
[15:54:03] <tomp> alex_joni: no, just was making an autonamer for gEDA and saw that limit
[15:55:13] <tomp> the naming scheme is devname.<num>.pinname. Is <num> limited to n digits?
[15:55:31] <jmkasunich> nope
[15:55:35] <tomp> thx
[15:55:38] <jmkasunich> the only hardcoded limit is the total length
[15:55:47] <tomp> gotcha
[15:57:32] <alex_joni> hi jmkasunich
[15:57:39] <jmkasunich> hi
[15:57:41] <alex_joni> you around so early?
[15:57:52] <jmkasunich> almost 11am, thats not early
[15:58:15] <tomp> sorry... the number scheme for parport pins is 0n, for sorting purposes, Does this apply to device numbers ( should i have 01 if i expect 11 devices )?
[15:58:24] <jmkasunich> oh, you mean on a weekday? today is a holiday
[15:58:37] <jmkasunich> tomp: yes
[15:58:41] <alex_joni> oh, didn't know that
[15:58:54] <alex_joni> what kind of holiday?
[15:58:54] <tomp> thanks
[15:59:07] <jmkasunich> yesterday was Thanksgiving, today is traditionally a day off, just to make a four day weekend
[15:59:20] <cradek> yay
[15:59:48] <alex_joni> oh cool
[15:59:58] <alex_joni> happy delayed thanksgiving everyone
[16:00:01] <cradek> I even get today off and my company is notoriously stingy with holidays
[16:02:03] <jmkasunich> Thanksgiving - America's celebration of obesity
[16:02:18] <alex_joni> then I guess you have some catching up to do
[16:03:43] <alex_joni> so.. who's in favour of fixing the joints/axes issue?
[16:04:01] <alex_joni> (beeing in favour doesn't imply you have to do anything about it..)
[16:04:07] <jmkasunich> in that case, aye
[16:04:28] <alex_joni> but it might be that it breaks some configs..
[16:04:34] <cradek> I'm in favor of fixing all sorts of things that I don't have to fix myself
[16:06:05] <cradek> I think we need both [AXIS_0] and [JOINT_0] in the ini
[16:06:12] <jmkasunich> yep
[16:06:17] <alex_joni> I'll try to look over the code, and make a list with stuff
[16:06:24] <jmkasunich> except we don't need to number AXIS_
[16:06:34] <alex_joni> yup
[16:06:37] <jmkasunich> they can be called X, Y, Z, etc
[16:07:01] <cradek> good idea
[16:08:32] <cradek> I'm interested in doing joint constraints.
[16:09:26] <jmkasunich> constraints as in travel limits? or accel and vel? or?
[16:09:59] <cradek> at least vel
[16:10:17] <cradek> we already have travel limits
[16:10:45] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?JointsVsAxes
[16:10:49] <jmkasunich> I guess I was assuming that the majority of the [AXIS_n] data in todays's configs would become [JOINT_n] data
[16:10:56] <jmkasunich> including vels and accels
[16:10:59] <alex_joni> jmkasunich: yes and no
[16:11:19] <alex_joni> you have some stuff which you want to constrain / AXIS
[16:11:29] <alex_joni> and some other stuff which you want to constrain / joint
[16:11:44] <jmkasunich> right, and some that you might want to constrain both ways
[16:11:46] <alex_joni> feel free to add stuff to that page.. I know I will
[16:12:02] <alex_joni> right
[16:12:09] <jmkasunich> travel limits, vels, and accels typically come from real physical things, so joints should have them
[16:12:26] <jmkasunich> axes might want them too, but they are somewhat artificial in axis space
[16:12:29] <alex_joni> same for homing params
[16:12:33] <jmkasunich> right
[16:12:36] <jmkasunich> and pid tuning
[16:12:39] <alex_joni> right
[16:12:57] <alex_joni> as you said.. most of today's AXIS_ should be JOINT_
[16:13:33] <alex_joni> we could complicate the parsing of the ini, and make it read both ways..
[16:13:37] <cradek> if we move limits into joint space we have the unfortunate situation where we can't tell ahead of time where the program will go out of bounds
[16:13:52] <jmkasunich> cradek: we're not the ones creating that problem
[16:14:03] <jmkasunich> the workspace of a puma for example has never been a nice rectangle
[16:14:08] <alex_joni> cradek: I have stuff like that all the time for robots
[16:14:18] <alex_joni> G1 X0 ; X100
[16:14:25] <alex_joni> it can fail in a number of ways
[16:14:37] <alex_joni> even if both points are inside the "bounds
[16:14:39] <alex_joni> "
[16:14:47] <cradek> in axis space you could still define a volume (subset of the robot's volume)
[16:14:56] <alex_joni> yeah, but that's irrelevant
[16:14:56] <cradek> oh I see alex's point
[16:15:02] <jmkasunich> agreed - there should be limits in both axis and joint sections
[16:15:16] <alex_joni> for a certain joint arrangement you can't move from one point to another, even if they are voth valid
[16:15:18] <jmkasunich> so if you want a trivial rectangular workspace you can define it
[16:15:35] <jmkasunich> s/can't move/can't move in a straight line/
[16:15:42] <alex_joni> jmkasunich: yeah, but only usefull as a rough sketch
[16:15:49] <alex_joni> yes, line/circle whatever
[16:15:57] <alex_joni> * alex_joni talks coord move
[16:16:04] <jmkasunich> alex_joni: usefull to validate a program before you run it
[16:16:30] <alex_joni> not validate 100% - I don't think you can do that
[16:16:37] <jmkasunich> assuming you have made a rectangular volume that _is_ completely inside the actual non-prisimatic workspace
[16:16:44] <alex_joni> but for that one can set up a simulation, and run it..
[16:17:12] <jmkasunich> if I have a robot with 1meter long arms, I'm sure I can define a 50cm cube that is completely accessible ;-)
[16:17:20] <alex_joni> jmkasunich: not always
[16:17:41] <alex_joni> remember that you can get into that 50cm cube (same point even) from 4 different joint setups
[16:17:44] <alex_joni> maybe more than 4
[16:17:47] <alex_joni> depends on the robot
[16:17:58] <alex_joni> wrist up/down, elbow up/down, etc
[16:18:31] <alex_joni> you can rotate joint 0 by 180 degrees, and put 2,3,etc backwards
[16:18:38] <jmkasunich> true, I was only thinking ox xyz
[16:18:46] <jmkasunich> of
[16:18:53] <alex_joni> you can't position a puma only in XYZ :)
[16:18:59] <alex_joni> you need ABC too
[16:19:21] <alex_joni> so sometimes you can have lines 2m long, which it can do without problems
[16:19:34] <alex_joni> and sometimes lines 50cm long which it can't do, unless you reorient something
[16:19:41] <alex_joni> but we digress as always :D
[16:21:22] <jmkasunich> the original point was that we might want to allow limits on AXIS, not just joints
[16:21:29] <jmkasunich> (even if they are optional)
[16:21:38] <alex_joni> right
[16:21:51] <alex_joni> you could have a rectangle inside the workrange (sphere)
[16:22:05] <alex_joni> if the program doesn't fit that.. it's sure to be borken
[16:22:12] <alex_joni> if it fits.. it might work/might fail
[16:24:14] <jmkasunich> this touches on the larger problem of constrainst as well
[16:24:27] <jmkasunich> the same thing applies to other limits, like accel and vel
[16:24:44] <alex_joni> yes
[16:24:52] <jmkasunich> you could have a program that contains no feeds greater than 0.1mm/min, but still causes joint vel limits to be exceeded
[16:25:03] <cradek> sure
[16:25:11] <alex_joni> canon uses [AXIS_] constraints, same constraints are used / joint (jogging, homing etc)
[16:25:37] <alex_joni> jmkasunich: especially when a joint tends to go from nan to inf :D
[16:26:04] <alex_joni> we should fix the way limits are handled in task
[16:26:32] <cradek> what do you guys think about using TP for teleop
[16:26:35] <alex_joni> right now task analyses the commands it sends to motion before they get sent, if they exceed limits it reports an error
[16:26:55] <cradek> tpAddLine a long move and abort it when you get the key release/stop message
[16:26:57] <alex_joni> cradek: it would save some duplicated code
[16:27:03] <jmkasunich> what that means (I think) is that you can'y compute a feedrate for each move that will make the entire move comply with limits (as a close form equation in user space prior to queueing the move)
[16:27:18] <cradek> yes the teleop free mode planner is a lot of code
[16:27:34] <cradek> also I'd like to have incremental teleop jogs
[16:27:34] <alex_joni> jmkasunich: right.. but you can have TP scale it down to mathc the slowest joint
[16:27:48] <alex_joni> cradek: that's also kinda easy with TP
[16:27:56] <cradek> yes
[16:28:18] <alex_joni> ok, lets move it all to TP, then fix it in one place only :D
[16:28:21] <cradek> I think tp has to use kins (derivative) at each servo cycle to keep the joints in their vel limit
[16:28:34] <jmkasunich> I'm the one who is guilty of moving manual mode jogs out of the main TP
[16:28:43] <jmkasunich> I wonder if that was a mistake
[16:29:04] <alex_joni> it was a decision.. hard to say if a mistake :)
[16:29:11] <jmkasunich> cradek: I think you are right about kins derivative
[16:29:18] <alex_joni> if it all were perfect, we would be unemployed :D
[16:29:19] <cradek> doesn't matter - just have to decide if it's the right decision to move back
[16:29:34] <jmkasunich> don't worry, I'm not upset about it or anything
[16:29:49] <jmkasunich> today there are three modes: coord, teleop, and manual
[16:29:57] <jmkasunich> manual for homing and trivkins jogs
[16:30:02] <jmkasunich> teleop for non-triv jogs
[16:30:07] <jmkasunich> coord for MDI and programs
[16:30:28] <cradek> well the next wrench in the works is wanting to use jogwheels for teleop
[16:30:29] <jmkasunich> one of the reasons for the "manual mode tp" was for homing and such
[16:31:08] <alex_joni> we should have joint and world mode
[16:31:14] <alex_joni> homing ans such in joint mode
[16:31:19] <jmkasunich> alex_joni: I was just thinking that
[16:31:20] <alex_joni> and the rest through TP in world mode
[16:31:37] <alex_joni> trivkins could/should change at any time from one to another
[16:31:49] <jmkasunich> yep - and no disctinction between trivkins and nontriv (at least in motion)
[16:32:09] <alex_joni> KINEMATICS_IDENTITY
[16:32:37] <jmkasunich> but KINEMATICS_IDENTITY should only change the conditions for making mode changes
[16:32:45] <alex_joni> right
[16:32:47] <jmkasunich> it should not change how things are actually calculated
[16:32:54] <alex_joni> KINEMATICS_IDENTITY should be set for trivkins
[16:33:12] <alex_joni> and the rest of the code should remain the same for trivkins or nontrivkins
[16:34:31] <jmkasunich> I'd kind of like to make "joint mode" and "world mode" be a couple of runlevels
[16:36:02] <alex_joni> in motion?
[16:36:21] <jmkasunich> runlevels are system wide concepts
[16:36:24] <alex_joni> I saw your talk to chris the other day about runlevels
[16:36:39] <alex_joni> I would like to see it hijack some HAL concepts like addf
[16:36:47] <cradek> bbl
[16:37:03] <jmkasunich> the conditions for transitioning between joint and world would be dependent on kins type
[16:37:03] <alex_joni> say we have a very slow thread which only goes from ESTOP to ESTOP-RESET
[16:37:20] <alex_joni> (maybe thread is not the right component)
[16:37:34] <alex_joni> then integrators would have to addf stuff to that transition
[16:37:43] <alex_joni> when all are cleared, it gets to the desired state
[16:38:04] <jmkasunich> addf?
[16:38:29] <jmkasunich> I guess I think of it more as logic, not functions
[16:38:55] <jmkasunich> when in runleven N, and N+1 is requested, and all conditions are satisfied, go to N+1
[16:39:09] <jmkasunich> when in N and any condition for N is not satisfied, go to N-1
[16:41:52] <alex_joni> yeah.. but a mechanism like addf
[16:41:55] <alex_joni> maybe addc
[16:42:14] <jmkasunich> wny hal-ify it?
[16:42:30] <alex_joni> well.. I'd want it settable by the user
[16:42:37] <alex_joni> without recompiling
[16:42:49] <alex_joni> and having yet another format would be bad
[16:43:33] <alex_joni> I think only to keep it similar to existing things..
[16:43:33] <jmkasunich> well.... I would put runlevel config into the ini file, not the hal files
[16:43:43] <jmkasunich> but that is an implementation detail really
[16:43:46] <alex_joni> I think it could get quite big for that..
[16:43:50] <alex_joni> yeah, indeed
[16:44:10] <alex_joni> it's basicly something like: initial_state, conditions, end_state
[16:44:40] <jmkasunich> yeah, pretty much
[16:44:52] <alex_joni> from a fixed set of initial_state's
[16:44:58] <alex_joni> and end_state's
[16:45:02] <jmkasunich> some of which we _will_ hard code - things like joint to world mode transitions
[16:45:32] <jmkasunich> a key thing about runlevels - it is not a traditional state machine, with arbitrary state-to-state transitions
[16:45:34] <alex_joni> yeah, users can only add things.. not remove them
[16:45:50] <jmkasunich> it is a stack of states, and you can only go up or down, not sideways, and not skip steps
[16:46:17] <alex_joni> "halcmd init 4" anyone?
[16:46:22] <alex_joni> </joke>
[16:46:48] <jmkasunich> very much NOT halcmd anything
[16:46:55] <jmkasunich> runlevels are an EMC thing, not a HAL thing
[16:47:14] <jmkasunich> you might have some conditions that are "hal pin 'foo' is true"
[16:47:28] <jmkasunich> but the actual runlevel code should be in EMC itself - task, motion, or some such
[16:47:50] <alex_joni> probably task
[16:48:06] <jmkasunich> well, I wonder about that
[16:48:17] <jmkasunich> if in motion, estop can be a runlevel
[16:48:30] <jmkasunich> if in task, estop needed to be treated differently
[16:48:38] <jmkasunich> s/needed/needs/
[16:48:43] <alex_joni> differently how?
[16:48:52] <alex_joni> hal pin 'estop.foo' is true
[16:48:56] <jmkasunich> task = userspace = inherently not reliable
[16:49:10] <alex_joni> estop.foo is from motion or wherever in RT
[16:49:30] <alex_joni> or you think it would go down the runlevels too slowly?
[16:49:30] <jmkasunich> yeah, motion sets estop.foo
[16:49:48] <jmkasunich> and 350mS later task gets around to noticing that its set and changes the runlevel - not acceptable
[16:50:09] <alex_joni> well.. motion would have aborted by long
[16:50:09] <jmkasunich> the actual state machine should be realtime
[16:50:16] <alex_joni> even if the GUI doesn't report it yet
[16:50:31] <alex_joni> ok, I guess it has some advantages
[16:50:42] <jmkasunich> if we do runlevels right, motion doesn't have to process "abort" separately
[16:50:43] <alex_joni> but also implies problems of passing lots of config data
[16:50:51] <jmkasunich> runlevel changing to a lower number _IS_ abort
[16:52:17] <tomp> for later, when you guys get done... i had problems using '00N' device number format in a hal file . the terminal output, and hal file are here
http://pastebin.ca/795009. i just modified the device number in a working sim-servo config as a test.
[16:52:54] <jmkasunich> tomp: did you change the hypot component to use three digits?
[16:52:59] <tomp> yes
[16:53:09] <tomp> ooops, not sure of the q
[16:53:20] <jmkasunich> so if you do halcmd loadrt hypot, then show funct, you see hypot.000?
[16:53:22] <tomp> ah, the comp file istelf, no
[16:53:52] <jmkasunich> every component defines the names used by that component
[16:53:53] <tomp> will use that as test , thx
[16:54:09] <jmkasunich> I'm not sure its a good idea to change the number of digits across the board
[16:54:54] <jmkasunich> if you have a component that exports more than 10 of some pin (like parport, or a digital I/O card with 24 I/Os) then it should use two digits
[16:55:35] <jmkasunich> but the actual instance numbers in HAL (in otherwords, the first card, the second card, the first hypot, the 12th hypot) should probably NOT be padded out to a fixed length
[16:56:04] <jmkasunich> after all, only the user decides how many hypots are in his system
[16:56:20] <jmkasunich> we shouldn't impose 4 digit numbers just because one insane machine uses 1000 hypot blocks
[16:57:09] <alex_joni> jmkasunich: sorry.. was away a bit
[16:57:15] <skunkworks> yikes - you guys hit the ground running this morning
[16:57:30] <alex_joni> skunkworks: well.. morning was long ago
[16:57:37] <skunkworks> heh
[16:57:38] <alex_joni> even for US guys :P
[16:57:48] <jmkasunich> not so
[16:57:52] <jmkasunich> 11:57 am
[16:57:54] <jmkasunich> 3 mins left
[16:58:02] <skunkworks> 10:57
[16:58:05] <alex_joni> well.. morning is at 7 am
[16:58:09] <alex_joni> I heard
[16:58:24] <jmkasunich> no, 7am is "still sleeping"
[16:58:29] <jmkasunich> aka "night"
[16:58:30] <alex_joni> but it's 18:57 over here
[16:58:56] <alex_joni> back to.. runlevels..
[16:59:11] <alex_joni> those are completely separated from axis/joints issues.. right?
[17:00:06] <jmkasunich> sort of
[17:00:13] <alex_joni> I mean.. not related
[17:00:28] <jmkasunich> except that fixing axis-joint issues is going to require better handling of homing
[17:00:29] <alex_joni> they will have conditions based on axes/joints stuff..
[17:00:38] <jmkasunich> (can't switch to world until all joints homed, etc)
[17:01:02] <alex_joni> but there is code for that iirc
[17:01:04] <jmkasunich> there is an ugly mess of flags and (currently broken) logic to handle that now
[17:01:16] <jmkasunich> runlevels seems like a clean fix for those flags
[17:01:35] <alex_joni> you still need some flags..
[17:01:48] <jmkasunich> re broken - try cradek's five axis bridgemill sim
[17:02:15] <jmkasunich> if you move _any_ axis manually, then even if you later hit home all, it won't let you switch to coord mode
[17:02:22] <jmkasunich> until you restart EMC
[17:02:33] <alex_joni> move any before homing?
[17:02:39] <alex_joni> or after already homed?
[17:02:46] <jmkasunich> maybe the latter
[17:02:55] <jmkasunich> it was nearly a week ago when I was playing with it
[17:03:13] <jmkasunich> the point is, its broken
[17:03:30] <jmkasunich> you _should_ be able to hit home all and then go into coord, regardless of what you did before that
[17:03:54] <alex_joni> right
[17:07:01] <alex_joni> * alex_joni goes to try it
[17:09:00] <alex_joni> I wonder why AXIS displays 0,1,2,4,5,W
[17:09:05] <alex_joni> as joints
[17:09:35] <jmkasunich> I think thats what we call "a bug"
[17:09:53] <alex_joni> in the display it has joints 0..8
[17:10:03] <alex_joni> and hitting home_all only sets home for 0..5
[17:10:13] <alex_joni> it also says "exceeded soft limit"
[17:11:24] <jmkasunich> I think that config is going to find a lot of bugs related to joints vs axes, and non-triv kins in general
[17:11:50] <alex_joni> in tkemc I have 0..9, and was able to home them all
[17:12:15] <alex_joni> when switching to world (which works btw) I can see : X,Y,Z,B,C,W,-,-,-
[17:12:35] <alex_joni> heh.. and teleop for "-" works too
[17:12:49] <jmkasunich> how can it "work"
[17:12:52] <jmkasunich> there is nothing to move
[17:13:02] <alex_joni> well.. it does the same thing as "X"
[17:13:16] <alex_joni> it probably reads axes[0] or something
[17:13:51] <alex_joni> moving Z+ exceeds the softlimit quite fast
[17:14:03] <jmkasunich> I think home is at the top of travel
[17:16:10] <alex_joni> ha.. this is fun
[17:16:19] <alex_joni> jogging B&C in world mode
[17:16:27] <jmkasunich> heh
[17:16:50] <jmkasunich> I found a bug there too the other day (maybe chris has fixed it since then)
[17:17:07] <alex_joni> if you're near the limit bad thigns TM happen
[17:17:12] <jmkasunich> I tried to jog one of those axes negative, and instead it went very very fast positive
[17:17:33] <alex_joni> say I move B so that Z wents out of bounds
[17:17:36] <cradek> I have not fixed anything in teleop
[17:17:57] <alex_joni> the simulated thingies freezes, and nothing happens..
[17:18:05] <alex_joni> except it takes a while to come back out of bounds
[17:18:21] <alex_joni> (just like a scara where the tooltip gets out of bounds)
[17:19:05] <alex_joni> oh, and it shows how broken G0 really is..
[17:19:51] <alex_joni> G0 from X0Y10Z10B0C500W0 to X0Y0Z0B0C0W0
[17:20:20] <alex_joni> I think that's conceptually wrong
[17:20:29] <alex_joni> G0 should imo move in joint space
[17:21:06] <jmkasunich> no, G0 is in auto mode, it should move in a straight line in world space
[17:21:19] <alex_joni> but that's not the shortest path
[17:21:43] <alex_joni> then it's just a G1 with a really high feedrate
[17:22:01] <jmkasunich> I guess that's how I've always thought of G0 anyway ;-)
[17:22:38] <alex_joni> but it seems it's defined like that in the rs274ngc
[17:23:02] <alex_joni> "coordinated linear motion to the destination point"
[17:23:16] <cradek> I understand there's a common setup for infinite rotary axes where it avoids the excessive rotations - is that what's missing?
[17:23:26] <alex_joni> cradek: nope
[17:23:37] <alex_joni> I was thinking of a different G0 for nontrivkins
[17:23:56] <alex_joni> if I have to unwind C500, it will move the machine on X back and forward
[17:24:09] <cradek> haha yep
[17:24:10] <alex_joni> (imagine B at 90 degrees)
[17:24:27] <cradek> that's what we call a feature IMO
[17:24:35] <alex_joni> well.. then I'll skip using G0
[17:24:38] <alex_joni> it's stupid :D
[17:24:57] <jmkasunich> winding and unwinding rotary axes is another thing where one man's feature is another man's bug
[17:25:16] <jmkasunich> if I'm doing a 3600 degree move because I want to machine a spiral, I want it to wind up
[17:25:40] <jmkasunich> and if I have cables going to run the stacked rotary, it better unwind when I command it back to zero
[17:25:51] <alex_joni> jmkasunich: I agree with you
[17:25:53] <jmkasunich> otoh, if there are no cables, then not unwinding saves time
[17:26:00] <cradek> stuart is helping me understand the common setup for rotaries that don't wind up. I'll find or write a spec soon
[17:26:10] <alex_joni> yeah, but not unwinding should be a different command
[17:26:15] <cradek> seems like it's a little odd, but agreed upon
[17:27:54] <cradek> bbl again
[17:31:00] <alex_joni> 1238 pts/1 00:00:00 5axisgui <defunct>
[17:31:32] <jmkasunich> thats the python visualization program?
[17:31:37] <alex_joni> yeah
[17:31:54] <jmkasunich> I had that happen when I was working on the initial scara and puma models
[17:32:02] <alex_joni> it got left behind.. didn't see any issues shutting down emc2
[17:32:05] <jmkasunich> something crashes it, and it leaves droppings
[17:32:07] <alex_joni> can't kill it..
[17:32:22] <jmkasunich> nope, it will be there till you reboot
[17:32:51] <alex_joni> * alex_joni restarts the VM
[17:33:00] <jmkasunich> cheater!
[17:33:23] <alex_joni> well.. it doesn't run so nice on the doze box
[17:33:37] <tomp> jmkasunich: i loaded 100 hypot comps. the hal autonumbering scheme doesnt use 001, it's simply 1 and 10 and 100. so my gEDA scheme will not use preceding 0's and will not use fixed N digits.
http://pastebin.ca/795078 thx
[17:34:00] <alex_joni> tomp: good :)
[17:46:29] <alex_joni> I still wonder how latency can be so low for this VM
[17:46:36] <alex_joni> maybe it's reading the time wrong?
[17:47:08] <alex_joni> I get max_jitter in the range of 21600 ns, for a base_thread of 25000 us
[17:59:58] <alex_joni> jmkasunich: mind if I start by changing ax[e|i]s with joints where applicable in the motion controller?
[18:00:14] <jmkasunich> you mean variable names?
[18:00:21] <alex_joni> and error messages
[18:00:25] <jmkasunich> I think I've already started that
[18:00:30] <jmkasunich> but sure, go ahead
[18:00:33] <cradek> and pins?
[18:00:36] <alex_joni> yeah
[18:00:42] <cradek> whee
[18:00:43] <alex_joni> hmm
[18:00:49] <alex_joni> and all configs :D
[18:00:53] <jmkasunich> oh, pins... that will be externally visible and break all configs
[18:00:57] <cradek> yep, big time
[18:01:02] <jmkasunich> but its the right thing to do IMO
[18:01:02] <alex_joni> I'll skip pins for now :D
[18:01:13] <alex_joni> maybe we can have pin aliases for a while in HAL ?
[18:01:26] <jmkasunich> dunno
[18:01:29] <alex_joni> alias axis.X.fb-cmd joint.X.fb-cmd
[18:02:00] <jmkasunich> IMO, if we decide that its the right thing to do, we should go ahead and make the change early in the 2.3 cycle (like now)
[18:02:11] <jmkasunich> as long as we think it through and don't change again in a month
[18:02:51] <jmkasunich> I don't want to do some alias command in HAL
[18:02:54] <jmkasunich> that way lies madness
[18:04:35] <jmkasunich> changing axis to joint in a hal file is a matter of a bit of sed isn't it?
[18:04:59] <jmkasunich> so when 2,3 comes out, we can have a script that people can invoke to make that change
[18:05:22] <alex_joni> yup
[18:30:57] <alex_joni> wtf: localEmcAxisAxisType[EMCMOT_MAX_AXIS];
[18:34:07] <jmkasunich> don't ask me
[18:38:17] <alex_joni> nice name though
[18:38:27] <alex_joni> guess I should ask yabosukz :D
[18:39:01] <alex_joni> cvs diff -u | wc -l
[18:39:04] <alex_joni> 1238
[18:42:56] <jmkasunich> commit flood coming soon?
[18:43:05] <alex_joni> nah.. this is not even 10%
[18:43:13] <alex_joni> and I only tested that it compiles so far
[18:43:34] <alex_joni> I'll pastebin the diff before commiting it.. maybe someone can throw a view at it
[19:03:02] <alex_joni> whee .. it still runs :)
[19:16:14] <alex_joni> pastebin.com/m6fd3ce3e
[19:39:16] <alex_joni> jepler: saw a small bug in AXIS.. if I'm in world mode, and switch from Manual to MDI, when I switch back to manual it changed to joint mode automatically
[19:39:35] <jmkasunich> thats not a bug I don't think
[19:39:42] <jmkasunich> manual _is_ joint mode
[19:39:56] <alex_joni> no.. you can switch between joint and world mode in manual
[19:40:04] <alex_joni> I was in world mode before I went to MDI
[19:40:10] <alex_joni> (jogging with teleop..)
[19:40:36] <alex_joni> sorry.. poor wording (world view, not world mode)
[19:40:59] <jmkasunich> anyway, modes are all fscked up for non-triv
[19:41:12] <alex_joni> jmkasunich: think it's safe for me to commit that change? (it's only variable names and comments)
[19:41:32] <jmkasunich> I've been looking at it, but my eyes glaze over
[19:41:42] <jmkasunich> the odds of me catching something you missed are slim
[19:41:44] <alex_joni> yeah, it's kinda long..
[19:41:56] <alex_joni> (bet I did miss something.. but we'll see)
[19:42:02] <jmkasunich> there is one thing I question
[19:42:12] <alex_joni> ok?
[19:42:26] <jmkasunich> set num axes, line 106-128
[19:42:50] <jmkasunich> I think I'd continue to use emcmotCommand->axis instead of joint_num
[19:43:06] <jmkasunich> because the number being passes is _not_ a joint number
[19:43:18] <alex_joni> well.. that command should be set_num_joints
[19:43:22] <jmkasunich> (its not an axis either, and we should fix that eventually)
[19:43:36] <jmkasunich> number of joints != a joint number
[19:43:49] <alex_joni> well, yeah, you're right
[19:44:09] <jmkasunich> (that command struct field is being overloaded already, which is bad
[19:44:19] <jmkasunich> overloading joint_num too is worse
[19:44:20] <alex_joni> it should be emcmotCommand.num_joints
[19:44:27] <jmkasunich> yep
[19:44:29] <alex_joni> or max_joints
[19:44:35] <jmkasunich> or emcmotCommand->first_integer_arg
[19:45:02] <jmkasunich> they wanted to avoid bloating the struct, thats why they reused so many fields
[19:45:08] <alex_joni> well.. that's another change
[19:45:15] <alex_joni> I'd rather not mix it in here
[19:45:19] <jmkasunich> I'm not suggesting that
[19:45:24] <jmkasunich> just leave it as it was
[19:45:41] <alex_joni> only for EMCMOT_SET_NUM_AXES ?
[19:45:48] <jmkasunich> eventually we'll fix the overloaded fields some other way, either make more distinct fields, or name the overloaded ones something generic
[19:46:08] <jmkasunich> thats the first one I noticed that was passing something other than a joint number in that variable
[19:46:13] <jmkasunich> I think, lemme check again
[19:46:15] <alex_joni> haha, use bogus castings
[19:46:22] <alex_joni> #define joint_t int
[19:46:34] <jmkasunich> :-P
[19:46:43] <alex_joni> (joint_t) emcmotCommand->first_integer_arg;
[19:46:59] <alex_joni> maybe without the _t
[19:47:34] <jmkasunich> if we were so insane as to do that, it would be #define joint_num_t int
[19:47:41] <jmkasunich> (with or without the _t)
[19:47:47] <jmkasunich> joint is something completely different
[19:47:53] <alex_joni> yeah
[19:48:02] <alex_joni> I _was_ joking though
[19:48:03] <jmkasunich> anyway, I don't want to go there now
[19:48:08] <jmkasunich> I figured
[19:48:15] <jmkasunich> hence the "so insane"
[19:48:48] <alex_joni> I think joint_num applies to the other commands
[19:49:53] <jmkasunich> I think I agree
[19:50:37] <alex_joni> any idea why the rtapi_print_msg() are on 2 lines?
[19:51:17] <alex_joni> rtapi_print_msg(RTAPI_MSG_DBG, "JOG_ABS");
[19:51:26] <alex_joni> rtapi_print_msg(RTAPI_MSG_DBG, " %d", joint_num);
[19:51:41] <jmkasunich> no
[19:52:03] <jmkasunich> lazyness maybe, I bet I initially added the "print the name of the command" lines to every command
[19:52:17] <jmkasunich> then later added command specific "print the command argument(s)" lines to some of them
[19:52:54] <jmkasunich> this change does NOT change the hal pin names, right?
[19:56:13] <alex_joni> right
[19:57:45] <alex_joni> and I did it mostly by hand.. only 2-3 things by search & replace (but even then, with reviewing before doing so)
[20:59:37] <alex_joni> well.. I'm off to bed soon
[20:59:46] <alex_joni> I'll commit this first :)
[21:24:50] <CIA-19> 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/usrmot.c:
[21:24:50] <CIA-19> sort out axes/joints in the motion controller (and closely coupled parts)
[21:24:50] <CIA-19> * this commit merely replaces variable names, and fixes comments
[21:24:50] <CIA-19> * no functional change intended
[21:24:50] <CIA-19> * HAL pin names didn't get updated, as that will break configs
[21:24:52] <CIA-19> (instead further actions have been tagged with comments)
[21:24:54] <CIA-19> 03alex_joni 07TRUNK * 10emc2/src/emc/task/taskintf.cc:
[21:24:56] <CIA-19> sort out axes/joints in the motion controller (and closely coupled parts)
[21:24:58] <CIA-19> * this commit merely replaces variable names, and fixes comments
[21:25:00] <CIA-19> * no functional change intended
[21:25:02] <CIA-19> * HAL pin names didn't get updated, as that will break configs
[21:25:04] <CIA-19> (instead further actions have been tagged with comments)
[21:25:08] <CIA-19> 03alex_joni 07TRUNK * 10emc2/src/emc/motion/ (10 files):
[21:25:10] <CIA-19> sort out axes/joints in the motion controller (and closely coupled parts)
[21:25:12] <CIA-19> * this commit merely replaces variable names, and fixes comments
[21:25:14] <CIA-19> * no functional change intended
[21:25:16] <CIA-19> * HAL pin names didn't get updated, as that will break configs
[21:25:18] <CIA-19> (instead further actions have been tagged with comments)
[22:18:14] <cradek> well I can no longer smugly say that all the gouges in max's table were someone else's doing
[22:21:25] <LawrenceG> cradek: :{.... tell us more
[22:24:28] <cradek> no big deal. I milled a nice little right angle in it
[22:24:52] <cradek> the drawbar was not tight enough and I had the vacuum running so I didn't hear it right away
[22:26:06] <jmkasunich> mill worked out of the collet?
[22:26:25] <cradek> no, the holder came out of the spindle
[22:26:29] <jmkasunich> ouch