Back
[02:38:40] <SWPadnos> hey jmk_away, are you around?
[02:38:52] <jmk_away> no, he's not here
[02:38:57] <jmk_away> ;-)
[02:39:01] <SWPadnos> ok - let me know when he returns :)
[02:39:21] <SWPadnos> hey - a question on the time delay component
[02:39:45] <SWPadnos> this is a simple one - I assume that a single update function is preferable to a zillion separate ones?
[02:39:46] <jmk_away> shoot
[02:39:50] <SWPadnos> shot
[02:40:06] <jmk_away> you mean one that updates all delays, vs one per delay?
[02:40:10] <SWPadnos> yes
[02:40:12] <jmk_away> that is a dilemma
[02:40:22] <SWPadnos> heh - flexibility vs simplicity
[02:40:29] <jmk_away> exactly
[02:40:34] <SWPadnos> I can do the group thing like you did with the debounces
[02:40:45] <SWPadnos> (which is what I'm basing the code on)
[02:40:57] <jmk_away> nah, that smacks of cluge
[02:40:57] <jmk_away> kluge
[02:41:08] <SWPadnos> yash, kinda
[02:41:11] <SWPadnos> teah
[02:41:13] <SWPadnos> yeah
[02:41:15] <jmk_away> heh
[02:41:21] <jmk_away> do all in one
[02:41:22] <SWPadnos> too much grasshopper pie ;)
[02:41:24] <SWPadnos> o0k
[02:41:27] <SWPadnos> ok
[02:41:51] <jmk_away> if I ever get that "automatic dependency checker and addf generator" working, then I'd want one per component
[02:41:54] <jmk_away> but that is in the future
[02:42:05] <SWPadnos> emc3.5
[02:42:16] <jmk_away> not that far, I was thinking emc2.4 maybe
[02:42:34] <SWPadnos> that would be cool
[02:42:48] <SWPadnos> however... (there's always a however)
[02:42:48] <jmk_away> I really want to do the hal refactor, just need to make the time
[02:42:59] <SWPadnos> yep - time is always a problem
[02:43:13] <jmk_away> whats the "however"
[02:43:43] <SWPadnos> well - I suppose it doesn't really matter at this point, since you can't change functions while threads are running
[02:43:57] <jmk_away> actually you can
[02:44:10] <jmk_away> you can do addf while its running
[02:44:21] <jmk_away> (I think)
[02:44:26] <SWPadnos> does it actually add the function?
[02:44:30] <jmk_away> yes
[02:44:31] <SWPadnos> I thought it wouldn't do that
[02:44:44] <jmk_away> maybe I'm misremembering
[02:44:48] <jmk_away> lemme check
[02:44:55] <SWPadnos> but I guess it must - you can add scope_rt to a running emc
[02:45:27] <jmk_away> I want to double check that I did it in a thread safe way
[02:45:29] <SWPadnos> hal threads are started during the initialization of emc, right?
[02:45:31] <SWPadnos> heh
[02:49:47] <jmk_away> yeah, its thread safe, the next and previous links in the new funct struct are set before any of the links in the original list point to the new entry
[02:50:34] <jmk_away> the RT code follows the list in one direction only, so it either arrives before the new entry is linked (and doesn't run that funct) or after (and does run it, and then safely moves on to the next one)
[02:51:08] <SWPadnos> is the struct protected by a semaphore or the like?
[02:51:42] <jmk_away> by a mutex, but that is to prevent simultaneous access for things like "show", "addf", etc
[02:51:55] <jmk_away> the RT code can run even tho halcmd holds the mutex
[02:52:13] <SWPadnos> ok - so multiple halcmds simultaneously doing addf will fail or block?
[02:52:25] <jmk_away> but the insert operation itself is atomic
[02:52:35] <jmk_away> block, until the first one finishes
[02:52:42] <SWPadnos> true - it should be one next pointer modification
[02:53:06] <jmk_away> see hal_lib.c line 1669
[02:53:07] <SWPadnos> though you'd have unpredictable function ordering ;)
[02:53:09] <SWPadnos> ok
[02:53:26] <jmk_away> if you had two addfs at the same time, yes
[02:54:24] <SWPadnos> anyway - that was the "however" - if threads are running, you may need to swap the execution order due to any pin connection
[02:54:29] <SWPadnos> that could be a real PITA
[02:54:50] <jmk_away> yes, it could
[02:55:37] <SWPadnos> actually, it doesn't matter if threads are running, you still need to reorder (or run the ordering algorithm) for every pin connection made
[02:55:58] <SWPadnos> unless you delay all that until "start"
[02:56:31] <jmk_away> if you have a signal chain like A->B->C->D->E, and B and D were both delay blocks, that adds a delay of one period
[02:57:09] <jmk_away> yes, if there is an auto-sequencer, it would have to re-evaluate after any signal-pin connection
[02:57:38] <SWPadnos> that would depend on whether B and D are in ascending order or descending order in the delay list
[02:57:42] <jmk_away> in that case, to avoid messiness with relinking on the fly, I'd probably have two lists of functions, one active, one scratch
[02:57:56] <SWPadnos> ok - in the scenario where they have independent update functions
[02:58:31] <jmk_away> with C inbetween, it doesn't matter what order they are within the one big function, there is no way for C to run after B and before D
[02:58:45] <SWPadnos> ah - right
[02:58:51] <SWPadnos> duh
[02:59:26] <jmk_away> anyway, for now we probably want to do "all in one", or do the group kluge, to keep the user from going batty with addfs
[02:59:44] <jmk_away> in the future when addfs are automagic, then one function per block
[02:59:48] <SWPadnos> I'll do them all at once - this is a ladder like thing
[03:00:03] <jmk_away> yes
[03:00:04] <SWPadnos> so they'd expect everything to be read, then operated on, then written
[03:00:47] <jmk_away> * jmk_away hides
[03:01:05] <SWPadnos> hi Pete
[03:01:09] <jmk_away> hi pete
[03:01:17] <SWPadnos> always joining after bedtime in the east ;)
[03:01:35] <jmk_away> yep
[03:03:20] <petev> hi
[03:03:33] <petev> yeah, I was busy this weekend
[03:06:26] <petev> do you guys beleive it's possible to express a kinematics transform with a matrix?
[03:06:48] <jmk_away> certainly in some cases, but not all
[03:06:58] <petev> yeah, that's what I thought
[03:07:01] <SWPadnos> as long as the matrix is of arbitrary size, probably
[03:07:05] <jmk_away> some kins transforms don't have any closed form solution, and need iterative approaches
[03:07:13] <petev> yes
[03:07:24] <jmk_away> along with initial guesses to tell it which side of a discontinuity it is on
[03:07:41] <petev> fenn is trying to do some generic kinematics stuff, but I think he is going to spend a lot of time for not much results
[03:08:09] <jmk_away> hmm, I wonder if the line between close form and open form kins is serial vs. parallel
[03:08:14] <petev> do you have any recommended reading on this stuff?
[03:08:42] <jmk_away> now that I think about it, I suspect that any series structure can use a transformation matrix (closed form)
[03:08:52] <SWPadnos> as long as you do a separate transform for each joint, you can probably get a closed form solution for any physically realizable machine
[03:09:15] <petev> what about the hexapod case?
[03:09:25] <SWPadnos> ok - maybe not ;)
[03:09:26] <petev> here you have several joints that limit each other
[03:09:38] <SWPadnos> that may be the serial vs parallel think jmk is talking about
[03:09:40] <petev> seems like multiple equations
[03:09:44] <petev> yeah
[03:09:48] <jmk_away> there are even series configs that have discontinuities
[03:09:58] <jmk_away> like the scara robot
[03:10:03] <petev> yeah, maybe elbow up/down type stuff
[03:10:06] <jmk_away> yes
[03:10:09] <SWPadnos> is there a photo of the scara somewhere?
[03:10:25] <petev> yeah, I think fenn is barking up the wrong tree, but I don't want to discourage him
[03:10:35] <SWPadnos> did you see the cybaman thing soemone (tomp?) posted earlier?
[03:10:41] <petev> no
[03:10:47] <SWPadnos> http://www.cybamantech.co.uk/cyba/?page=cybaman
[03:11:02] <jmk_away> http://www.20sim.com/webhelp4/gettingstarted/Scara2.gif
[03:11:06] <jmk_away> (scara)
[03:11:14] <jmk_away> that thing is cool (the tomp one)
[03:11:19] <SWPadnos> yep
[03:11:29] <petev> yeah, pretty crazy
[03:11:35] <jmk_away> scara has two rotary and one linear joint
[03:11:35] <SWPadnos> ok - the discontinuity is due to a physical limitation (no slipring), right?
[03:11:52] <jmk_away> look at the pic
[03:11:54] <SWPadnos> and the tool will bind if you try to spin the second rotary joint too far
[03:12:09] <jmk_away> suppose you want the tool to centerpost distance to be less than the maximum
[03:12:22] <SWPadnos> or the minimum ;)
[03:12:40] <jmk_away> that means the middle joint needs to be bent (elbow, sort of, but at 90 deg to a normal elbow)
[03:12:47] <jmk_away> so which way do you bend it?
[03:13:04] <jmk_away> answer (probably) the same way it was bent 1mS ago
[03:13:08] <SWPadnos> it's not that there's a discontinuity, you calculate the middle joint angle to make the hypoteneuse the desired length
[03:13:30] <jmk_away> but the middle joint could be bent into or out of the paper
[03:13:40] <SWPadnos> you run into a problem if the base rotation joint reaches a limit
[03:14:37] <petev> do you guys see much value in generalized arbitray kinematics (if it can even be done)??
[03:14:44] <jmk_away> no
[03:14:50] <petev> me either
[03:15:12] <jmk_away> hey, we're not discouraging what you are doing (too much), so let Fenn have his fun
[03:15:15] <jmk_away> ;-)
[03:15:16] <SWPadnos> I suspect that the mathematics knowledge needed to get a generalized matrix (if it's even possible) is way greater than the fairly simple polar / cartesian math needed now
[03:15:44] <petev> yeah, I'm going to let him try, but I don't think he's going anywhere
[03:15:50] <SWPadnos> I could write a kins module for the SCARA, but damned if I could figure out some closed form matrix transform for it
[03:16:29] <petev> fenn wants to build data structures that represent the joints and links between them
[03:16:32] <jmk_away> I could probably do a matrix that given joint angles would give you end effector position and orientation, but not the other way around
[03:16:43] <petev> then he wants to traverse it and build the matrix
[03:16:48] <SWPadnos> right - and not all matrices are invertible
[03:17:02] <SWPadnos> (if that would even give you the reverse transform)
[03:17:19] <petev> yeah, this isn't easy
[03:17:48] <jmk_away> the matrices I was thinking of transform from end effector coords to world coords, and are invertable (world to end effector)
[03:17:55] <petev> I helped him with data structs, but I don't know the math well enough, my gut says it's going to be very difficult if not impossible
[03:18:03] <jmk_away> but the joint angles are used to generate the matrix
[03:18:26] <SWPadnos> so the matrix changes with every pose - ick
[03:18:34] <jmk_away> not bad
[03:18:54] <petev> sound ick to me
[03:19:02] <jmk_away> sines and cosines - the video game and 3D graphics boys do that in their sleep
[03:19:03] <SWPadnos> I could hand off the problem to my mother, but I'm not sure we'd get an "engineering" answer ;)
[03:19:18] <petev> what good is the matrix if you need a new one for each pose?
[03:19:34] <jmk_away> I've got a library of 3D transform math tucked away somewhere
[03:19:43] <jmk_away> and posemath has some of that already
[03:19:58] <jmk_away> petev: the matrix isn't very attractive for this
[03:20:04] <petev> right
[03:20:07] <petev> tell fenn that
[03:20:30] <jmk_away> in 3D graphics, you generate one matrix for an object, then convert many points from object space to world space to render the object
[03:20:48] <jmk_away> then you move the object (modify the matrix) and repeat for the next frame
[03:20:55] <SWPadnos> maybe we should be using Cg or the like ;)
[03:20:58] <jmk_away> here we only care about 1 point really, the end of the tool
[03:21:08] <petev> right
[03:21:14] <jmk_away> (maybe 3 points, if you wnat to capture tool orientation as well as position)
[03:21:41] <SWPadnos> right - so making a matrix (which basically means calculating the end point), so you can run it through matrix math to get the real answer, seems a bit wasteful
[03:22:16] <SWPadnos> though with tool shape and obstacle avoidance, it may prove useful
[03:22:18] <petev> what do you guys think of the joint accel/velocity limits for rotary robots?
[03:22:20] <jmk_away> there are advantages
[03:22:42] <jmk_away> you can generate a matrix for each joint, then contcatenate them
[03:22:44] <petev> seems like they vary a lot in world space depending on joint position
[03:22:58] <petev> jmk: that's what fenn wants to do
[03:23:08] <jmk_away> sorry pete, was responding to SWP
[03:23:11] <SWPadnos> no - the limits are the same (at the moment), but the end effector speed varies
[03:23:26] <SWPadnos> depending on position
[03:23:36] <petev> swp: seems like on a rotary, the limits in world space would be sin/cos related
[03:23:42] <jmk_away> to do the limits, you need to be able to compute derivatives of the kins transforms
[03:24:08] <petev> hmm, for TP seems like you need small cubes of limits in cartesian world space, no?
[03:24:10] <SWPadnos> well - the ini file isn't really clear on joint vs. world corrdinates
[03:24:34] <jmk_away> heh - +_EMC_+ isn't really clear on joint vs. world coords
[03:24:35] <SWPadnos> you put an axis_0 accel or vel limit there, does it apply to the axis or the joint?
[03:24:40] <petev> swp: the TP seems to use them as world
[03:24:40] <SWPadnos> right ;)
[03:24:50] <petev> yep
[03:25:11] <petev> so do we want EMC to handle non-trivkins correctly?
[03:25:34] <jmk_away> sure, but we need to prioritize that with all the other things we want it to do
[03:25:40] <SWPadnos> I would say yes ;)
[03:25:56] <jmk_away> (one of which is not confuse the living hell out of the 95% of users who have trivkins)
[03:25:58] <petev> then we really need to think about the whole TP and kins stuff
[03:26:42] <petev> how else can you make the TP generic, other than to give it a cartesian map of joint limits?
[03:27:12] <jmk_away> are you talking about position, velocity, or accel limits?
[03:27:30] <petev> yeah, cutting cartesian space into cubes and assigning them
[03:28:01] <jmk_away> no matter what size cube you choose, it will be too small, and too big (at the same time)
[03:28:11] <SWPadnos> figuring out world-based limits is harder for non-trivkins machines, I'm not sure there's any way around that
[03:28:27] <petev> why do you say that? it may not be optimal, but it seems like it would work
[03:28:33] <petev> the cubes would depend on the kins
[03:28:46] <SWPadnos> consider a rotary table
[03:28:46] <petev> for trivkins, one big cube
[03:29:00] <SWPadnos> motorized, of course
[03:29:03] <petev> sure
[03:29:25] <jmk_away> too small as in you've got 20 bajillion of them and have RAM/speed issues, too big as in your work envelope is a jagged approximation of the real thing
[03:29:30] <SWPadnos> the effective cutting load varies depending on the radius
[03:29:46] <SWPadnos> radius from center of table to tool
[03:30:09] <petev> jmk: a semi jagged approx may not be bad with conservative limits
[03:30:38] <SWPadnos> also, it severely depends on the mass of the object, and its shape
[03:30:53] <jmk_away> there are more than just position limits
[03:31:07] <petev> swp: mass is out, we're talking kins, not dynamics
[03:31:11] <jmk_away> assume the rotary table with a radial linear axis above it, and another linear for Z
[03:31:24] <petev> so kin limits need to be conservative to account for mass changes
[03:31:39] <jmk_away> to cut a straight line thru the center of the table, the rotary needs to go to infinite speed as you pass thru center
[03:31:53] <jmk_away> lines near the center need high but not infinite speeds
[03:32:15] <jmk_away> net result, the velocity limit in world coords varies based on where you are
[03:32:33] <petev> right, that's why cubes with limits
[03:32:52] <jmk_away> and you have to check the limits in every cube your path passes thru
[03:33:02] <petev> yes, but that's not hard
[03:33:12] <petev> you can use the graphics clipping algos
[03:33:34] <SWPadnos> even better - you may not know what cube you're in until you've done the inverse kins
[03:33:46] <petev> huh?
[03:33:55] <petev> we are assuming we start in world space
[03:33:59] <SWPadnos> sure
[03:34:01] <petev> and the cubes are in world space
[03:34:02] <jmk_away> I think the problem will just be size of the cube data - this isn't a n^2 problem (which is bad enough) it is n^3
[03:34:06] <SWPadnos> ah
[03:34:37] <jmk_away> and 99% of the cubes will have uninteresting data in them
[03:34:49] <petev> jmk: agreed, but given how loose kins are compared to dynamics, do you really think we would need that many?
[03:35:19] <jmk_away> there are algos (again from graphics) for subdividing, so you use big cubes where things change slowly, and little ones where they change quiclky
[03:35:26] <jmk_away> (google voxels)
[03:35:37] <petev> what other approaches are there that could work with arbitrary kins?
[03:36:21] <jmk_away> if the kins can be put in the form of polynomials, then they have closed form derivatives
[03:37:01] <jmk_away> so you can evaluate joint position, velocity, and accell over the entire path
[03:37:20] <petev> isn't that going to be really slow and repetitive solution?
[03:37:30] <jmk_away> (solve for min and max values of the derivatives)]
[03:37:39] <jmk_away> if you step along the path, yes
[03:38:04] <jmk_away> but if you solve for the zeros of the accel equation, that gives you the points with the max and min velocity
[03:38:31] <jmk_away> solve for the zeros of velocity, gives you max and min positio
[03:38:33] <jmk_away> n
[03:38:43] <jmk_away> solve for the zeros of jerk, and get min and max accel
[03:38:58] <jmk_away> all closed form
[03:39:26] <petev> ok, so you know where the min/max are, but how does that help with the rest of the path?
[03:40:10] <jmk_away> you can calc the min and max, if acceptable, go, if not, either scale down the overall velocity, or subdivide the path and repeat, scaling down the sections that exceed limits
[03:40:45] <petev> I think I'm missing something
[03:40:58] <petev> I thought u were solving hte kins for min/max
[03:41:10] <petev> sounds like you're solving somethig path related
[03:41:11] <jmk_away> of course all of this assumes that you can represent the path in joint space as polynomials in t
[03:41:31] <jmk_away> assume a path in world space is a straight line
[03:41:31] <petev> ahh, that's what I was missing
[03:41:48] <petev> I wasn't assuming path representation in joint space
[03:41:49] <jmk_away> with non-triv kins, the path in joint space probably isn't
[03:43:02] <jmk_away> dammit pete, you've done it again... quarter to 11 on a work night, and I'm talking about future TP issues instead of coding something that is needed for the release we want to do in the next couple weeks. ;-)
[03:43:18] <petev> ok, I gotta go pick my sister up anyhow
[03:43:35] <petev> at least u got somthing to think about now ;-)
[03:44:37] <SWPadnos> he
[03:44:39] <SWPadnos> h
[03:44:57] <jmk_away> "with visions of matrices dancing thru their heads"
[03:45:04] <SWPadnos> glaaaarggghhhh
[03:45:12] <SWPadnos> (that was death by matrix)
[03:45:44] <jmk_away> how about quaterions?
[03:45:47] <SWPadnos> "the castle Aaaahhhhhh - perhaps he was dictating"
[03:46:11] <SWPadnos> What's a quaternion?
[03:46:21] <jmk_away> a way to represent rotations
[03:46:27] <SWPadnos> fsck them
[03:46:31] <jmk_away> in some ways nicer than matrices
[03:46:41] <SWPadnos> rotations in a plane?
[03:46:45] <jmk_away> (fewer nasty things like "gimbal lock")
[03:46:51] <SWPadnos> or in 3-space?
[03:47:02] <jmk_away> rotations in 3-space (or higher, if your brain can handle that without exploding)
[03:47:18] <SWPadnos> I have a klein bottle, and my brain hasn't exploded yet ;)
[03:47:56] <jmk_away> I used a mix of matrices and quaternions back in the day when I was playing with 3d graphics
[03:48:30] <SWPadnos> I could read my "Computer Graphics" book (from way back when I took the class), but I often get bogged down in the math
[03:48:44] <SWPadnos> there's a lot of it, and though I like math, I don't always like slogging through it
[03:48:48] <jmk_away> it is definitely boggy
[03:49:09] <SWPadnos> (I took the Putnam exam in college, and I don't think I even knew what the questions were, let alone how to get the answers)
[03:49:33] <jmk_away> I worked out the various transformations (quat to mat, mat to quat, etc) and built a library way back in the mid 90's
[03:49:51] <SWPadnos> I don't feel too bad about it - of the 4 students and two professors who took it at my university, I don't think there was a single correct answer
[03:49:55] <jmk_away> then I promptly forgot all the math and just used the lib
[03:49:59] <SWPadnos> heh
[03:50:00] <jmk_away> wow
[03:50:03] <SWPadnos> the engineer's way
[03:51:02] <jmk_away> at one time I was working on a modeling tool, that could model for instance a human body - you tell it all about the joints, and give it mesh points attached to the various bones
[03:51:15] <SWPadnos> cool
[03:51:22] <jmk_away> then it would render the mesh (skin), and you could move the joints
[03:52:01] <SWPadnos> the last time I did any 3D programming was using GL on the SGI Personal IRIS (for the graphics class)
[03:52:28] <SWPadnos> it was a speedy 25MHz (or if you were lucky, you cuold use on eof the 33MHz ones) R3000
[03:52:32] <jmk_away> I did this stuff on the PC, using a Matrox graphics card with hardware z-buffering and such
[03:52:50] <jmk_away> it was totally non-portable
[03:53:04] <SWPadnos> heh - from back when they actually released chip programming specs?
[03:53:08] <jmk_away> (the rendering that is - the math should be pretty portable)
[03:53:35] <jmk_away> I got a couple hundred pages from Matrox somehow, ftp site or something
[03:53:48] <SWPadnos> yep - they used to be pretty ood that way
[03:53:51] <SWPadnos> good
[03:54:02] <jmk_away> but I was doing this kind of stuff in DOS, just as windows was taking over
[03:54:20] <jmk_away> so it got pointless after a whil
[03:54:20] <jmk_away> while
[03:54:39] <SWPadnos> yep
[03:54:50] <SWPadnos> once Microshaft decided to stomp all ovber OpenGL
[03:55:22] <SWPadnos> I remember the days when you had to instal Windows, then the DirectX package, just to get certain video and sound updates
[03:55:30] <jmk_away> I was aware of things like direct-draw and direct-3d, but couldn't get excited about them
[03:55:34] <SWPadnos> some cards just didn't work right unless you used the DriectX driver
[03:55:52] <SWPadnos> they were total crap, until the 8th or 9th revision
[03:59:58] <SWPadnos> hey - I think this is the test I took:
[04:00:01] <SWPadnos> http://www.unl.edu/amc/a-activities/a7-problems/putnam/-pdf/2001.pdf
[04:01:23] <jmk_away> ahhhh, my eyes
[04:01:30] <jmk_away> {
[04:01:35] <SWPadnos> yeah - you should have smelled the smoke
[04:01:42] <jmk_away> sorry, that's tcl..
[04:01:47] <SWPadnos> ah
[04:02:04] <SWPadnos> well - tcl gets the brain a bit smoky as well ;)
[04:03:56] <jmk_away> heh, you can tell that it isn't used for math much
[04:04:06] <SWPadnos> tcl?
[04:04:21] <SWPadnos> what - 1+2 = "12" ;)
[04:04:25] <jmk_away> "c = a + b" is written as "set c [expr$a + $b ]
[04:04:32] <SWPadnos> heh
[04:04:35] <jmk_away> "c = a + b" is written as "set c [expr $a + $b ]
[04:04:55] <cradek> that's because ... they're strings
[04:05:03] <SWPadnos> right, else it would be expr[whatever a is] + $b
[04:05:16] <petev> jmk: what were the 4x4 matrices (the ones that let you do translation) in graphics called?
[04:05:26] <jmk_away> tranformation matrices?
[04:05:52] <petev> there wasn't another name for the 4x4 vs 3x3?
[04:06:03] <cradek> I think 4x4 gives you perspective
[04:06:06] <jmk_away> the math types use 4x4, I used 3x4 when I was doing it, because all non-wierd transforms leave the last row all zeros
[04:06:57] <cradek> "weird" = perspective
[04:07:27] <jmk_away> non-weird = translation and rotation - I was doing 3d graphics, flight simulator stuff and/or solid object modeling
[04:07:55] <jmk_away> I used differnent math for the actual projection from 3D space to flat screen
[04:08:11] <petev> cradek: I was test running some stuff with axis today and noticed a couple of things
[04:08:22] <petev> the g-code display was 2 lines behind emc
[04:08:37] <petev> and I couldn't find any control for the optional stop (M1)
[04:09:29] <cradek> can you reproduce that 2-lines-off thing?
[04:09:46] <petev> it did the same thing everytime with the file I was running
[04:09:58] <petev> it was really noticable when an M1 was hit
[04:10:10] <petev> EMC would stop and the display would be 2 lines before the M1
[04:10:46] <cradek> I'm just trying it here and it seems to display the right line...
[04:11:00] <petev> so it highlight the M1 when yours stops?
[04:11:01] <cradek> maybe something is odd baout M1
[04:11:13] <cradek> no, I didn't try an M1
[04:11:23] <cradek> I just ran a program and watched the cone
[04:11:28] <petev> oh
[04:12:25] <cradek> well it shows the line before the M1
[04:12:36] <petev> hmm, mine was 2 before every time
[04:12:39] <cradek> and then I can unpause
[04:12:41] <petev> I wonder what's going on
[04:12:54] <petev> yeah, S worked to continue
[04:12:56] <cradek> what did you mean you couldn't find the control?
[04:13:18] <petev> there was nothing to control whether optional stop stopped or not
[04:13:28] <petev> it's usually a switch on a real control
[04:13:36] <cradek> oh is that in the other guis?
[04:13:42] <petev> I though there would be a radio button or something on the GUI
[04:13:47] <petev> not sure
[04:13:57] <petev> just noticed it cause I ran a prog with M1s
[04:13:57] <cradek> there would have to be an nml message to go with it
[04:14:01] <cradek> don't think I've seen that
[04:14:05] <cradek> it might be in the ini?
[04:14:30] <petev> hmm, the interp handles it, I'll look at the details of what happens and send you an email
[04:14:39] <cradek> I suspect your program had a very quickly-executed line before the M1
[04:14:49] <petev> let me check
[04:14:57] <cradek> since the gui polls for position and line, it probably just missed.
[04:16:26] <petev> there was some coord setting, coolant, a Z move, then an X Y move before the M1
[04:16:35] <petev> I'll email you the file
[04:16:45] <cradek> dcc it if you can
[04:17:02] <petev> I'm on a doze boz
[04:17:04] <petev> box
[04:17:08] <petev> how about zip?
[04:17:44] <cradek> I mean transfer it with dcc
[04:17:48] <cradek> forget it, whatever is fine
[04:17:54] <petev> ok
[04:18:03] <cradek> I don't see anything about optional stop in tkemc
[04:18:49] <petev> may not be there, but it should be
[04:19:29] <petev> I'll dig a bit and see what I can find
[04:19:39] <petev> gotta go pick up my sister now
[04:21:20] <cradek> emc does not currently do optional stop - it always stops
[04:21:26] <cradek> but it's marked as FIXME
[04:21:58] <SWPadnos> at least it's marked ;)
[04:23:11] <cradek> I wonder if that's a bug report or feature request...
[04:23:40] <SWPadnos> feature request - it's not a misbehaving function, but something new (sort of, at least)
[04:23:59] <cradek> well, it's in the interp and canon API, but it doesn't "work"
[04:24:06] <cradek> i.e. it's not optional
[04:24:07] <SWPadnos> true
[04:24:23] <SWPadnos> though it's an optional stop - the user can decide, or the machine can decide
[04:24:31] <SWPadnos> in this case, emc always decides to stop
[04:24:51] <SWPadnos> (it's not incorrect, just not user-controllable)
[04:25:07] <cradek> you'd make a good politician
[04:25:12] <SWPadnos> same to you
[04:25:15] <SWPadnos> :)
[04:25:19] <cradek> haha
[04:25:51] <SWPadnos> I swear too much to be a politician (plus I'm honest and stuff)
[04:26:16] <cradek> being honest gets in the way of a lot of jobs and money-making opportunities
[04:26:29] <SWPadnos> then I'll be poor
[04:26:39] <cradek> same here
[04:26:56] <cradek> it's working well so far
[04:27:00] <SWPadnos> yep ;)
[04:27:03] <cradek> actually I'm not poor, but neither am I rich
[04:27:20] <SWPadnos> not totally poor either, but still have to think about purchases
[04:27:22] <cradek> and I think that's just fine
[04:27:25] <SWPadnos> e
[04:27:26] <SWPadnos> yep
[04:27:42] <cradek> the richest people have to think about purchases - just bigger ones
[04:27:50] <cradek> that probably never goes away
[04:28:17] <SWPadnos> yeah - more than $100 for me, more than $100,000,000 for BillGatus
[04:29:37] <jmk_away> look on the bright side - we don't have to think about $100,000,000 purchases
[04:29:52] <SWPadnos> but I *want* a 727-stretch
[04:30:35] <cradek> M1 is supposed to be optional stop, but currently EMC always stops. The interpreter and canon API have support for this, but the current emccanon always stops.
[04:30:39] <cradek> There should be a checkbutton in the GUIs that controls this, so option stop has to be added to the stat buffer, and there should be an NML message to set it.
[04:30:50] <cradek> before I submit it, does this look right?
[04:31:26] <SWPadnos> there also need to be TP / motion changes to make it stop (or not stop)
[04:31:40] <SWPadnos> and they need to handle having the option change during the last move before the optional stop
[04:31:41] <cradek> no, at that level it'll do the same thing as regular PAUSE
[04:32:04] <cradek> err PROGRAM_STOP
[04:32:13] <cradek> as it's called in canon
[04:32:27] <SWPadnos> that's between interp and TP?
[04:32:34] <cradek> yes
[04:32:51] <cradek> interp -> canon -> [realtime boundary] -> tp
[04:33:00] <SWPadnos> so canon would look at the status, and pause if option is set or not bother if not set?
[04:33:13] <cradek> yes
[04:33:22] <SWPadnos> ie, the actual command stack would differ
[04:33:22] <cradek> one problem is the interp reads ahead
[04:33:29] <cradek> you would pretty much have to set this before you start the program
[04:33:34] <SWPadnos> right - that's the issue I'm seeing
[04:33:49] <SWPadnos> I'd want to be able to change it during a run
[04:34:21] <SWPadnos> for example, so I could change a tool or something if I see that it's getting hot, or to refill coolant or the like
[04:34:25] <cradek> you're talking about a major change then
[04:34:28] <SWPadnos> yes
[04:34:52] <cradek> the only other control software I've used (maxnc) you could set this in the gui's setup screen, not during a program run.
[04:34:53] <SWPadnos> I'm not sure what the option is "meant" for though, so I could just be overcomp]licating things
[04:35:01] <SWPadnos> ok
[04:35:03] <cradek> well I never used it
[04:35:12] <cradek> and their software sucked in other ways, so don't trust that
[04:35:16] <SWPadnos> heh
[04:35:32] <cradek> I'll submit this as-is, and you can certainly add a comment if you like
[04:35:46] <SWPadnos> I'd imagine using this in various places where an operator would want to choose to do some maintenance task or not
[04:35:48] <SWPadnos> ok
[04:36:01] <cradek> yes I can sure see that desire
[04:36:22] <cradek> "here is a good stopping point" (like after a jog at safety hight)
[04:36:25] <cradek> height
[04:37:03] <SWPadnos> sure - or "this part's done, change tools now if you think it's needed
[04:37:49] <cradek> but I guess in that case, an extra pause/resume is the simple solution
[04:38:04] <cradek> I'm not really sure when you would use M1 as I described (configured at the beginning of the program)
[04:38:47] <SWPadnos> yeah - maybe during a test run, to measure tool wear or finish, then turn it off once you decide your machine can handle it
[04:42:04] <cradek> To stop a running program temporarily (but only if the optional stop switch is on), program M1.
[04:42:17] <cradek> by "switch" I wonder what is meant
[04:42:26] <cradek> this could be a hardware switch too
[04:42:33] <SWPadnos> a physical switch on a panel, according to pete
[04:43:14] <cradek> interesting
[04:44:21] <SWPadnos> though with emc, you should be able to make that a software switch (or multiple switches in different locations)
[04:44:21] <cradek> I took out the part about the gui
[04:44:27] <SWPadnos> ok
[04:44:57] <cradek> I agree it should be there, but if I want to call it a bug, I better not want more than the rs274 documentation says...
[04:45:08] <SWPadnos> right ;)
[04:46:03] <SWPadnos> well - I ought to run. it's bedtime and I still need to do some chores :)
[04:46:07] <SWPadnos> see you guys later
[04:46:10] <cradek> goodnight
[04:55:07] <jmk_away> night
[05:07:27] <petev> cradek, u still there?
[05:11:23] <cradek> nope
[05:11:25] <cradek> err, yes
[05:11:37] <petev> sounds like you got a handle on the optional stop
[05:11:44] <petev> while you're looking at it
[05:11:55] <petev> take a look at the optional block delete
[05:12:04] <petev> I don't see anything in the GUIs for that either
[05:12:13] <cradek> is that in the rs274 spec?
[05:12:18] <petev> yes
[05:12:29] <petev> it deletes lines that start with /
[05:12:38] <petev> it's common feature on real controls too
[05:13:37] <cradek> interesting
[05:13:55] <petev> yeah, my BP control has toggle switches for both
[05:16:21] <cradek> would you submit a tracker for this please
[05:16:39] <petev> ok
[05:16:51] <petev> should I put it in for all GUIs?
[05:17:01] <cradek> no, it's not a gui issue
[05:17:17] <cradek> I think it's an interp issue
[05:17:24] <petev> I don't see anything in the GUIs
[05:17:33] <petev> maybe the interp is broken too
[05:17:43] <petev> but it is in kramers doc
[05:17:47] <cradek> many levels have to be touched to implement it
[05:17:57] <petev> so there is no NML now?
[05:18:01] <cradek> but I think at its root, it's interp
[05:18:09] <cradek> no, I don't think there's any support anywhere
[05:18:27] <petev> ok, I'll make it pretty general then
[05:19:27] <cradek> I guess / lines are deleted
[05:19:36] <cradek> I don't get an error loading them
[05:19:39] <petev> should I put it under bugs or feature reqs?
[05:19:49] <cradek> I don't know...
[05:19:53] <petev> it's an optional delete
[05:20:02] <petev> ie, only delete if switch is on
[05:20:09] <petev> I bet the interp runs them now
[05:20:14] <cradek> no, it skips them
[05:20:18] <cradek> I just tried
[05:20:25] <petev> hmm, that seems like a bug then for sure
[05:20:40] <cradek> I think I agree it's a bug
[05:20:47] <cradek> if it's contrary to the spec, it's a bug
[05:21:09] <petev> looks like u already entered one for optional stop
[05:21:23] <cradek> yes I did
[05:30:56] <cradek> thanks
[05:31:13] <cradek> btw, you mean checkbutton
[05:31:27] <cradek> radio buttons are the things like on a car radio (in the old days!) where you push one and the rest pop out
[05:31:34] <petev> yeah, I guess since it's not interlocked with anything else
[05:32:02] <cradek> doesn't matter, the bug reader will know what you meant
[05:32:27] <cradek> we still call it dialing the phone too...
[05:32:34] <cradek> that's funny
[05:32:36] <petev> true
[05:33:29] <cradek> arg, I never tested the file you sent
[05:33:33] <cradek> too late now, maybe tomorrow
[05:33:40] <petev> no prob
[22:21:42] <rayh> Would if be prudent to post a note to both devel and user lists regarding those who use the bridgeportio or tkio stuff and whether they have edited the default config in their ini files.
[22:23:38] <SWPadnos> probably a good plan
[22:24:11] <rayh> We could easily set up a default bpt hal file that a user can add to their config.
[22:24:18] <SWPadnos> so - there's the time delay tou wanted ;)
[22:24:18] <SWPadnos> you
[22:24:20] <rayh> I see you've got the timer checked in
[22:24:23] <SWPadnos> yep
[22:25:01] <SWPadnos> should be easier than CL to set up a spindle delay ;)
[22:25:32] <SWPadnos> be sure to run ./configure after you checkout - I had to change Makefile.inc.in
[22:25:48] <rayh> okay. will do.
[22:26:54] <SWPadnos> I suppose I should have put that in the commit message
[22:27:58] <rayh> IMO most folk will see the changes and know what to do.
[22:28:06] <SWPadnos> true
[22:28:08] <rayh> But thanks for telling me.
[22:28:13] <SWPadnos> heh
[22:28:24] <SWPadnos> I was just going to say - if they don't, they shouldn't be using CVS ;)
[22:29:56] <rayh> Does timedelay become a block that is loaded like other blocks.
[22:30:02] <SWPadnos> yes
[22:30:06] <SWPadnos> loadrt timedelay
[22:30:15] <SWPadnos> then addf process_delays servo-thread
[22:30:45] <rayh> I guess I was thinking of the "blocks" thing with all it's sub parts.
[22:31:17] <SWPadnos> ah - sorry
[22:31:21] <SWPadnos> I made a separate component
[22:31:35] <SWPadnos> the blocks comp is pretty big - I wanted a little thing
[22:31:45] <rayh> k no problem.
[22:39:07] <SWPadnos> should I just go through all the inis and set BASE_PERIOD to SERVO_PERIOD / 2 (for servo card absed ones, that is)?
[22:39:41] <rayh> Is that what we decided needed to be done?
[22:40:33] <SWPadnos> I see something in the TODO about choosing a larger BASE_PERIOD for non-stepper configs
[22:40:41] <rayh> There isn't a need for real high base period except in the mazak where it's used to read the handwheel.
[22:40:44] <SWPadnos> I'm not sure if there was a decision on exactly what that period would be
[22:41:00] <SWPadnos> that's a 100 PPR encoder, right?
[22:41:13] <SWPadnos> or 100 CPR
[22:41:15] <anonimasu> are there components to accept a handwheel?
[22:41:25] <SWPadnos> loadrt encoder
[22:41:28] <anonimasu> ah cool
[22:41:29] <anonimasu> :)
[22:41:35] <rayh> You're asking an alzheimers candidate?
[22:41:45] <SWPadnos> who asked what?
[22:41:49] <anonimasu> I asked it before..
[22:41:51] <anonimasu> :/
[22:41:56] <anonimasu> my memory is so bad
[22:42:14] <rayh> can't be as bad as mine.
[22:42:22] <SWPadnos> who said that?
[22:42:41] <SWPadnos> "well doctor, at least I don't have cancer" ;)
[22:43:01] <rayh> right.
[22:44:00] <SWPadnos> anyway - the BASE_PERIOD - even at 500 us per cycle, a 400 PPR (100 CPR in quadrature) handwheel would have to be going at 2.5 RPS, or 150 RPM, before it became a problem
[22:44:37] <SWPadnos> (maybe half that, if Myquist comes into play)
[22:44:43] <SWPadnos> Nyquist, even
[22:44:52] <rayh> I think that jmk was spinning it pretty fast with his hand.
[22:45:09] <SWPadnos> ok - I can leave that one alone
[22:45:39] <rayh> He did some testing of the module with that setup.
[22:45:44] <SWPadnos> univstep, univpwm, stg, and motenc can probably all use a slower BASE_PERIOD - even SERVO_PERIOD/4 would be fine
[22:45:57] <rayh> You bet.
[22:46:04] <SWPadnos> I suppose I could too - I have a nice handwheel he gave me (and I'm a gamer - have I mentioned that recently? ;) )
[22:46:19] <rayh> That will reduce the load.
[22:46:29] <rayh> whatsagamer?
[22:46:38] <SWPadnos> ok - I'll make all those 250 microseconds
[22:46:54] <rayh> handwheels rather than joysticks or xxx pads.
[22:47:01] <anonimasu> yep
[22:47:11] <SWPadnos> I used to use paddles
[22:47:21] <SWPadnos> Tempest was a great game
[22:47:31] <SWPadnos> and Pong - don't forget Pong
[22:48:13] <rayh> I could state my age "packman"
[22:48:23] <SWPadnos> PacMan was waaaaaay after Pong
[22:48:34] <rayh> oh really.
[22:48:52] <SWPadnos> Pong was the original game that Nolan Bushnell (later the founder of Atari) made - around 1968 or 1969
[22:49:06] <SWPadnos> PacMan was late '70s
[22:49:20] <SWPadnos> before it came Asteroids (I think), Tank II, and Space Invaders
[22:49:45] <SWPadnos> the original Space Invaders - with a B/W screen, and colored cellophane over parts of it for "color"
[22:50:01] <rayh> did that.
[22:50:06] <SWPadnos> and also BattleZone
[22:50:10] <SWPadnos> that was a cool one
[22:50:31] <SWPadnos> there's a console arcade game at Costco - it has like 80 of the old games (not all that old)
[22:50:47] <SWPadnos> it's unfortunately $1600 or $2000
[22:50:51] <rayh> You'd have to compare notes with my kids on those.
[22:51:05] <SWPadnos> but it's a full stand-up game cabinet, complete with (disabled) coin acceptor
[22:51:09] <SWPadnos> heh
[22:51:48] <SWPadnos> anyway - I'll take a handwheel for a "spin" soemtime - just for the heck of it
[22:52:23] <rayh> why not.
[22:52:45] <SWPadnos> but until then, I'll only change those other configs ;)
[22:55:34] <rayh> Thanks for that.
[22:55:51] <rayh> so loadrt gets me 8 delays
[22:56:14] <SWPadnos> only one, unless you specify num_delays=(something else)
[22:57:19] <rayh> okay.
[22:58:42] <SWPadnos> I see that these files have various numbers for max_feed_override - any one that's particularly good (I see 1.2 and 1.5)
[23:00:53] <rayh> 1.2 was default in the original emc stuff.
[23:01:02] <SWPadnos> ok
[23:01:07] <rayh> but over the years it got pushed all around.
[23:01:19] <SWPadnos> I thinkonly the univstep config I have is different - the motenc and m5i20 are both 1.5
[23:01:29] <rayh> we should check the min and max limits as well.
[23:01:35] <SWPadnos> incidentally - the univstep / univpwm aren't in CVS yet
[23:01:48] <SWPadnos> ok - what would you like?
[23:02:00] <SWPadnos> I'd assume Bridgeport size, at least
[23:02:02] <rayh> original was -10 and +10
[23:02:14] <rayh> across all axes.
[23:02:23] <rayh> so they were bigger than many machines.
[23:02:27] <SWPadnos> ok - +- 10 is a bit small for X
[23:03:02] <rayh> emc2's emc.ini used a very small z
[23:03:15] <SWPadnos> maybe I'll take out the stupid ini var save first ;)
[23:03:25] <rayh> and it would not run either cds or the penguin
[23:03:57] <SWPadnos> right - like 3 inches, I think
[23:04:18] <rayh> somebody's router.
[23:04:33] <SWPadnos> heh
[23:05:15] <SWPadnos> would it be a bad thing for me to remove the axis var dump?
