Back
[08:05:56] <mhaberler> jepler: around? thinking about how to do the getrusage(RUSAGE_THREAD) thing. I wouldnt want to do this on every thread iteration; maybe just if there's an RT timing violation
[08:07:14] <mhaberler> alternative: on demand in a thread function in the rtmon component, triggered by a pinchange - this would take out the issue of rtapi altogether and leave it to user discretion
[08:29:54] <mhaberler> cflags/c90/c99: it's cflags-y: see here
http://stackoverflow.com/questions/2935047/how-to-use-make-and-compile-as-c99
[08:30:05] <mhaberler> oops, wrong window
[09:17:36] <jepler> mhaberler: I sure don't know whether getrusage() takes you out of realtime, for instance...
[11:54:54] <cradek> jepler: I'm getting appropriate-seeming speeds after I add [AXIS_X] MAX_VELOCITY/MAX_ACCELERATION sections
[11:55:44] <cradek> also, world limits for continuous jogs seem to work now
[11:55:44] <seb_kuzminsky> ooh, AXIS_X
[11:55:46] <skunkworks> ooh - ja3?
[11:55:46] <jepler> AXIS_X not AXIS_0
[11:55:46] <jepler> ?
[11:55:46] <cradek> yes
[11:55:47] <jepler> oh
[11:56:19] <jepler> yes, me too
[11:57:43] <cradek> I'm still just getting 1ips in mdi, though
[11:58:06] <jepler> whatever all the things I've changed ar, after doing AXIS_[XYZ] I get 400 when I G1 F400
[12:00:51] <jepler> s/\<ar\>/are/
[12:01:02] <seb_kuzminsky> if only we had some way to tell what we've changed...
[12:01:17] <jepler> I know right
[12:03:40] <cradek> I think my JOINT max velocity is being used for world mode jogging
[12:03:54] <jepler> I made all the numbers super big
[12:04:13] <cradek> woooooo I have incremental jogs in world space
[12:04:15] <cradek> that's awesome
[12:04:28] <seb_kuzminsky> ja3 has some awesome features
[12:04:46] <seb_kuzminsky> i hope to finish my rebase tonight
[12:05:03] * cradek gleefully draws a 1" checkerboard with incremental jog
[12:05:21] <seb_kuzminsky> then i want to push a joints_axes4.0 branch, which should have an identical end point to joints_axes3
[12:05:44] <seb_kuzminsky> then i want to clean up the history and push joints_axes4.1, and review that for merging into 2.6
[12:06:19] <cradek> I bet in that process we'll spot the leftover weirdnesses
[12:06:30] <seb_kuzminsky> i hope so
[12:06:37] <cradek> I think something's off about vel/acc
[12:06:47] <seb_kuzminsky> it'd be good not to destabilize ~pre1 too badly
[12:07:56] <cradek> hm, I thought we had wheel jog in world space, but I don't see axis.0.jog-counts etc pins
[12:09:05] <cradek> there are joint.0.jog-counts etc pins, and when I twiddle them (while in world mode) nothing happens
[12:26:52] <cradek> when jogging I get incorrect "Exceeded negative soft limit on joint 0" (I'm nowhere near the negative joint limit)
[12:26:52] <cradek> probably negative axis limit
[12:47:38] <seb_kuzminsky> hi micges, we were just talking about merging joints_axes3 into master for the 2.6 release
[12:48:01] <micges> hi, good timing ;)
[12:48:43] <seb_kuzminsky> do you think that branch is in pretty good shape? ready to go into 2.6?
[12:49:05] <micges> yeah
[12:49:09] <seb_kuzminsky> great!
[12:49:18] <seb_kuzminsky> it's got some really cool features :-)
[12:51:28] <micges> yep
[12:51:29] <seb_kuzminsky> i'm most of the way through rebasing ja3 onto master, then i'll push a joints_axes4 branch, and then i'll try to clean up the history a bit to make it easier for us all to review
[12:51:37] <seb_kuzminsky> do you have any stuff pending that you want to get into ja?
[12:51:44] <micges> no
[12:51:48] <seb_kuzminsky> ok :-)
[12:51:51] <seb_kuzminsky> then yes, the timing *is* good :-)
[12:52:06] <micges> it has split joints from axes
[12:52:18] <seb_kuzminsky> have you been running this branch on your machines?
[12:52:30] <micges> fixed teleop jogging with jogwheel
[12:53:02] <seb_kuzminsky> soft limits in every mode
[12:53:29] <micges> and what is missing is following joints constraints while in teleop/coord mode
[12:53:34] <micges> but it's HARD
[12:54:07] <micges> yes we had at least 4 24/day machines running ja3
[12:54:57] <micges> only problem to fix is joints/teleop mode funky in gui's
[12:55:14] <cradek> micges: I tried to do wheel jogging in world mode but I don't have axis.0.jog-counts pin. what am I missing?
[12:55:14] <cradek> er axis.x.jog-counts
[12:55:53] <micges> oh
[12:57:10] <micges> it was quite long ago but I'll locate this problem
[12:57:46] <micges> I'm sure it was world mode jogging becouse it was done only on laser with gantry setup
[12:58:07] <cradek> keyboard continuous and incremental jog work in world mode for me (yay!)
[12:58:19] <cradek> but I did not figure out wheel
[13:19:27] <micges> seb_kuzminsky: cradek: I'll dig my archives for jogwheel code/changes today in few hours
[13:19:42] <micges> if it wasn't pushed (most probably) I'll do it
[13:29:57] <pcw_home> micges: I think the encoder error stuff needs some work before its incorporated into then 2.6 release
[13:30:09] <pcw_home> s/then/the/
[13:32:23] <micges> pcw_home: remember me what is the problem?
[13:34:24] <pcw_home> I'm pretty sure that there are circumstances that generate encoder errors at startup (and I know that some changes I am adding to the firmware will generate them). Currently theres no way to clear or mask the error
[13:35:45] <pcw_home> Any change in the encoder mux pin enable will generate errors and also
[13:35:46] <pcw_home> changes in the new muxed encoder deskew register will generate them
[13:36:47] <micges> I see
[13:37:23] <micges> bbl
[13:37:36] <cradek> thanks!
[13:37:39] <cradek> darnit
[13:37:59] <pcw_home> So I think it might be better to have a encoder_error pin and an encoder error_enable pin (if encoder_error_enable is false its clears and masks the error ) too late :-(
[13:38:37] <cradek> jepler: timeguy/rotarydeltakins is working quite well now, got an 8x8x8 work volume
[13:41:44] <jepler> cradek: cool
[13:55:16] <cradek> I need me some CSG so I can put holes where the thighs go through the platform...
[13:56:29] <jepler> vismach can use ASCII STL files, which you could produce with a parametric model in openscad
[13:56:55] <jepler> AsciiSTL("whatever.stl") # searches relative to current directory, i.e., inifile directory
[13:57:54] <cradek> http://timeguy.com/cradek-files/emc/rdelta-workvolume.png
[13:58:08] <cradek> ooh maybe I'll do that as the design becomes less virtual
[13:58:57] <seb_kuzminsky> that's cool cradek
[13:59:01] <jepler> among the things it can do, the docs say openscad can extrude 2d DXFs to 3D, in case you want to go that route
[13:59:49] <cradek> seb_kuzminsky: it actually seems to work, even. I drew the cube with continuous jogs.
[14:00:51] <cradek> git.timeguy.com, rotarydeltakins
[14:01:38] <jepler> cradek: I think I see where you want that CSG :-P
[14:01:46] <jepler> you should have turned it around to the other side so we might not notice
[14:04:29] <seb_kuzminsky> i've never played with openscad, but i've drawn lots of parts like that in freecad
[14:04:42] <seb_kuzminsky> (and freecad has some kind of integration with openscad now)
[14:05:04] <jepler> there are probably a number of ways to get to ASCII STL any of which should work with vismach
[14:07:29] <seb_kuzminsky> even with ja, the work volume is always a cube, right?
[14:07:33] <cradek> when the world limits are all inside the joint limits, you can jog without it freaking out
[14:07:58] <seb_kuzminsky> seems like many kins can access non-rectanguloid work volumes
[14:08:04] <cradek> seb_kuzminsky: yes world space is min/max per axis
[14:08:11] <cradek> certainly so
[14:08:30] <seb_kuzminsky> that's kind of a bummer
[14:09:26] <cradek> a bit hard to tell where to end a continuous jog otherwise
[14:09:55] <seb_kuzminsky> yeah, i can see that
[14:10:19] <seb_kuzminsky> you'd have to intersect the world-mode vector with the joint-mode limits
[14:10:30] <seb_kuzminsky> ugh
[14:10:36] <cradek> I doubt you can count on the world space even being convex
[14:10:47] <cradek> yep, ugh, and also, who cares
[14:10:55] <cradek> all workpieces are rectangular anyway :-)
[14:10:59] <seb_kuzminsky> heh
[14:11:24] <seb_kuzminsky> i was thinking of the igloo-shaped volume that my now-broken robot arm can reach
[14:11:30] <cradek> oh duh, I can put the "platform" on top
[14:11:32] <cradek> jeeez
[14:12:15] <seb_kuzminsky> oh yeah, that would be better
[14:13:17] <cradek> hey now nothing intersects anything else
[14:17:46] <micges> pcw_home: I'll create error_enable pin
[14:21:14] <andypugh> I think that all work volumes should be defined by an STL (or, less specifically, a triangular mesh)
[14:21:47] <andypugh> You could miss your cjuch/toolchanger/etc that way too.
[14:22:06] <andypugh> (chuck)
[14:22:23] <pcw_home> Thanks micges
[14:23:24] <seb_kuzminsky> andypugh: it's not enough to define a volume in 3-space, which is what an stl does i think
[14:23:55] <seb_kuzminsky> some locations in the 3-space work volume might not allow you to access all A, B, and C angles, for example
[14:24:03] <andypugh> STL defines a surface. But the facets have a defined normal which allows you to tell inside from outside.
[14:24:47] <cradek> then you only need the 6d version of that
[14:25:02] <andypugh> Maybe we need to define a 6 dimensional STL for machines with more axes
[14:25:13] <cradek> imagine a puma sticking straight up. it can get to that point, but at only one particular AB orientation
[14:25:26] <seb_kuzminsky> exactly
[14:25:35] <seb_kuzminsky> yes, a 6d stl might do it
[14:25:42] <andypugh> I guess the question is whether you allow those points, or not.
[14:26:17] <seb_kuzminsky> a worthy goal would be for linuxcnc to not impose any more restrictions on the work volume than the mechanics of the machine do
[14:26:44] <andypugh> I am pretty sure I can't visualise a 6D surface, but in the same way as there are Z limits for any XY with a defined volume, the concept extends to A limits for any XYZC...
[14:27:16] <seb_kuzminsky> right
[14:27:17] <cradek> another worthy goal is to have an implementation that is both possible and useful
[14:27:32] <andypugh> Pah! You limit yourself uneccesarily!
[14:27:34] <cradek> (to some extent, the rectangular solid is that)
[14:27:39] <seb_kuzminsky> haha
[14:27:47] <cradek> I'm actually being serious
[14:27:52] <cradek> for once
[14:28:18] <cradek> useful can include things like not inventing a 6d STL that nobody can generate or visualize
[14:28:55] <seb_kuzminsky> practical, implementable, and understandable are all good
[14:29:02] <cradek> yes
[14:29:35] <seb_kuzminsky> anyway, back to $DAYJOB for me, see you guys later
[14:29:59] <cradek> I've considered finding a way to use the kins we already have, which can in theory test a point for "it's possible" and "it's not"
[14:30:35] <jepler> yes, you just return -1 when a point is not feasible .. as long as the caller is checking the return value
[14:30:38] <cradek> for instance -- for jogs, you've got plenty of time to figure out and initiate the jog -- you could do a binary search for the edge
[14:31:01] <seb_kuzminsky> cradek: not if the work volume is concave
[14:31:01] <cradek> if you have to run kins a couple hundred times to start a continuous jog, who cares
[14:31:08] <seb_kuzminsky> DAMMIT i'm going back to work now
[14:31:15] <cradek> haha
[14:31:29] <jepler> seb_kuzminsky: look a pterodactyl
[14:31:47] <pcw_home> Do the kinematics normally chose a pose thats optimum? (isfurther from joint limits optimum?)
[14:31:58] <micges> pcw_home: you think error-enable should be global pin or per encoder instance?
[14:32:04] <andypugh> Though didn't somone say the other day that a jog is just a move with the end-point at the soft-limit? Defining that end-point before the direction is clear might be tricky.
[14:32:17] <pcw_home> could be global
[14:32:57] <micges> I was thinking global too
[14:33:07] <cradek> pcw_home: in degenerate cases, or cases where there are more than one solution, you can pick the one you want using knowledge that comes from outside of the math, or just fail
[14:33:21] <cradek> pcw_home: I'm not sure I understand your question exactly though, so that might not answer it
[14:34:15] <pcw_home> I seems that you would want to keep away from joint limits as much as possible (but I really know nothing about this)
[14:34:16] <cradek> http://timeguy.com/cradek-files/emc/twosolutions.png
[14:34:51] <cradek> for instance in this robot there's another solution for the forward kins, one with the foot above the motors. you pick the right one by knowing about the robot.
[14:35:17] <cradek> I don't think you can assume anything as general as further from limits is better
[14:40:22] <pcw_home> Yeah I was just thinking about bad places that require a large joint space motion to recover,
[14:40:24] <pcw_home> but stiffness of poses or other things may be important
[14:41:07] <cradek> yeah I bet there are lots of gotchas
[14:47:51] <cradek> huh, I wonder if I could home this thing with tilt switches on the thighs, plus encoder index
[14:47:59] <cradek> that would be quite slick
[14:48:33] <cradek> would have to level the machine after moving it, of course
[14:49:29] <cradek> I could put a bubble level on top of the platform and give it three adjustable legs - might be good enough
[14:54:29] <micges> cradek: no trace after this project, seems that I must redone teleop wheel jog
[14:54:58] <micges> give me few days for it
[14:55:03] <cradek> oh nooo, do you mean you already wrote the code but it is now lost?
[14:55:49] <cradek> thanks for doing it, I will test for you when you are done
[14:56:31] <micges> seems so, but I have dozen of hdd and flash drives to check, maybe it's zipped somewhere
[14:57:27] <micges> (as for now it's not in main backup)
[14:58:25] <cradek> thanks for looking!
[14:59:11] <micges> cradek: do you think that fix of my encoder error feature could go into 2.5 ?
[14:59:27] <cradek> micges: do you have a patch for me to look at?
[15:00:26] <micges> will be in half hour
[15:00:59] <cradek> ok
[15:21:43] <KGB-linuxcnc> 03jepler 05rotarydeltakins f3a14a7 06linuxcnc 10lib/python/vismach.py * vismach: make it possible to use HAL pins in any CoordsBase
[15:21:43] <KGB-linuxcnc> 03chris 05rotarydeltakins 658d72f 06linuxcnc 10src/ 10(5 files in 2 dirs) * Rotary delta kinematics
[15:21:45] <KGB-linuxcnc> 03chris 05rotarydeltakins 109ab91 06linuxcnc 10configs/sim/axis/ 03rdelta.ini 03sim_rdelta.hal * rotarydelta config with simulation
[15:21:53] <KGB-linuxcnc> 03jepler 05rotarydeltakins 4022b33 06linuxcnc 10configs/sim/axis/rdelta.ini 10configs/sim/axis/sim_rdelta.hal 10src/hal/user_comps/vismach/Submakefile 03src/hal/user_comps/vismach/rotarydelta.py * rotarydelta visualization
[15:22:01] <KGB-linuxcnc> 03chris 05rotarydeltakins 095c980 06linuxcnc 10configs/sim/axis/ 10rdelta.ini 10sim_rdelta.hal * rdelta config cleanup
[15:22:08] <KGB-linuxcnc> 03chris 05rotarydeltakins cc773b9 06linuxcnc 10configs/sim/axis/rdelta.ini 10configs/sim/axis/sim_rdelta.hal 10src/hal/user_comps/vismach/rotarydelta.py * Fixup ini and units, standardize on inches
[15:22:16] <KGB-linuxcnc> 03chris 05rotarydeltakins 7744519 06linuxcnc 10src/hal/user_comps/vismach/rotarydelta.py * Hexagonal foot
[15:22:22] <KGB-linuxcnc> 03chris 05rotarydeltakins 837dd01 06linuxcnc 10configs/sim/axis/rdelta.ini * This gives a nice 8x8x8 work volume
[15:22:28] <KGB-linuxcnc> 03chris 05rotarydeltakins 63715cd 06linuxcnc 10src/hal/user_comps/vismach/rotarydelta.py * Add gearboxes
