Back
[00:01:09] <jepler> http://en.wikipedia.org/wiki/Sima_%28mead%29
[05:14:38] <psha> jepler: already sleeping?
[06:53:28] <alex_joni> yay, another puma running genserkins
[14:13:25] <jepler> I didn't spot any obvious refcounting bugs in pyhal-pin
[14:13:34] <jepler> I still haven't actually *run* it
[14:16:34] <SWPadnos> jepler, quick (hopefully) question about python checking programs (like pychecker)
[14:17:19] <SWPadnos> I had a program that used getopt, and I had forgotten to set a value before option processing, so the script would error if the option wasn't specified (which wasn't the intended behavior)
[14:17:43] <SWPadnos> do you know if PyChecker, or some other "lint-like" program would catch that type of error?
[14:17:49] <SWPadnos> (no, I haven't tried it yet)
[14:18:23] <cradek> have you tried it?
[14:18:28] <SWPadnos> (no, I haven't tried it yet)
[14:18:46] <jepler> >>> py = h.newpin("y", hal.HAL_FLOAT, hal.HAL_IN)
[14:18:50] <jepler> >>> py.set(3.14)
[14:19:10] <jepler> I was going to complain that this doesn't signal an error, but for that matter neither does >>> h['y'] = 3.14
[14:25:58] <jepler> so there's a bug in pyhal_write_common, but the following is required in pyhal_pin_set too:
[14:26:02] <jepler> static PyObject * pyhal_pin_set(PyObject * _self, PyObject * value) {
[14:26:05] <jepler> pyhalitem * self = (pyhalitem *) _self;
[14:26:07] <jepler> - pyhal_write_common(&self->pin, value);
[14:26:10] <jepler> + if(pyhal_write_common(&self->pin, value) == -1)
[14:26:12] <jepler> + return NULL;
[14:26:14] <jepler> Py_RETURN_NONE;
[14:26:17] <jepler> }
[14:38:15] <SWPadnos> argh. well, pychecker is a little weird
[14:38:52] <SWPadnos> when trying to check an executable script, pychecker assumes it's a module (to be imported) unless the name ends with .py
[14:39:15] <SWPadnos> it then appears to actually execute the script
[14:39:52] <SWPadnos> (I got a serial module error because I don't have my USB->serial adapter plugged in, so there's no /dev/ttyUSB0)
[14:41:59] <SWPadnos> and apparently you can't pass command line parameters to the file being checked
[16:40:12] <micges_work> joints_axes3 is working nice with gantry, 30000mm/min and servo-thread 10kHz without any problems
[16:42:50] <cradek> neat!
[16:43:07] <cradek> are all your changes in git? is there a sample config that makes everything work right?
[16:48:40] <micges_work> yeah
[16:48:54] <micges_work> sample configs is in git from about few months
[16:49:01] <micges_work> all is in git
[16:49:26] <micges_work> and after last huge master merge to ja3 all is correct
[16:50:01] <cradek> yay! that's great news
[16:50:15] <micges_work> today and tomorrow I'll test it further
[16:50:23] <micges_work> up to 60000mm/min
[16:51:41] <micges> micges is now known as micges_gluemachi
[16:53:12] <micges_gluemachi> micges_gluemachi is now known as micges
[17:53:18] <micges> hmm
[17:54:34] <micges> if min_ferror > ferror in ini file then following error trips on random ferror values
[17:55:06] <micges> random but greather than ferror
[17:55:41] <cradek> you can scope ferror_lim, trigger on ferrored
[17:55:49] <cradek> (doubt it's random)
[17:56:21] <micges> sounds to me ja3 issue
[17:59:14] <micges> what is behaviour of ferror_lim ?
[17:59:27] <micges> it's hold max ferror up to time?
[17:59:51] <cradek> I think it's the calculated trip point (based on your two ferror settings and velocity)
[18:01:25] <micges> I see
[18:04:07] <micges> bbl
[18:11:50] <jepler> yes, I think cradek's right about what ferror_lim (aka joint->ferror_limit) is supposed to mean
[18:12:46] <jepler> the trip point vs current command velocity curve should have a shape like _/
[18:19:57] <jepler> yay, got ubuntu-hardy-server-i386 installed in libvirt/qemu
[18:28:07] <micges_work> ok thanks
[19:20:38] <alex_joni> micges: got an email from another genserkins user that uses it for a puma 500
[19:21:08] <alex_joni> Ted Hyde, says it works great for him :)
[19:21:20] <micges> he's using ja3 or master?
[19:21:29] <alex_joni> 2.4 or master I think
[19:21:37] <micges> cool
[19:21:41] <alex_joni> so there's still room to improve things :)
[19:21:49] <alex_joni> he asked me an interesting question
[19:22:22] <alex_joni> if we want a coordinate system attached to the workpiece (rotated and translated from the regular coordinate system origin)
[19:22:31] <alex_joni> what options are there
[19:23:27] <SWPadnos> G92?
[19:30:15] <psha> buildbots are still down?
[19:31:48] <micges> alex_joni: I don't really understand question
[19:32:13] <micges> our coordinate systems are attached to workpiece after G10 right?
[19:32:17] <cradek> same here
[19:35:37] <jepler> in max5kins the UVW axes moved in the orientation defined by the BC rotation.
[19:48:57] <alex_joni> imagine a turn/tilt table
[19:49:02] <alex_joni> (not moved by emc2)
[19:49:21] <alex_joni> the workpice is in a arbitrary (but fixed) postion and rotation
[19:49:44] <alex_joni> the g-code which Ted wants to execute should be in the workpiece coordinate system
[19:50:07] <alex_joni> so I think a simple transformation matrix (applied to all g-code coordinates befor executing could be enough)
[19:50:13] <alex_joni> for example an AXIS filter
[19:50:20] <SWPadnos> eek
[19:50:34] <SWPadnos> that wouldn't necessarily obey joint limits
[19:51:03] <cradek> well, we don't have that ability
[19:51:09] <cradek> we only have rotation in XY
[19:51:41] <SWPadnos> oh right, before executing
[19:51:50] <SWPadnos> duh me
[20:05:58] <alex_joni> SWPadnos: well.. usually robot programs are fairly small compared to work envelope
[20:06:08] <alex_joni> but I think a simple py filter called from AXIS solves this
[20:06:20] <SWPadnos> I was thinking of accel and vel actually :)
[20:06:34] <alex_joni> oh that doesn't matter imo
[20:06:35] <SWPadnos> possibly, but I imagine it's not so simple
[20:06:44] <SWPadnos> unless there are no canned cycles or arcs
[20:06:49] <alex_joni> right
[20:06:59] <alex_joni> arcs should still work.. I see no issue why not
[20:07:19] <alex_joni> oh, in g-code arcs are XY/YZ/XZ constricted
[20:07:31] <alex_joni> I keep forgetting that ;)
[20:07:42] <alex_joni> ok, no arcs then :)
[20:08:02] <alex_joni> gotta pack ..
[20:08:34] <cradek> arbitrary arcs work - you get them if you rotate in xy and then do g18/g19 arcs.
[20:09:32] <cradek> you can't currently get ANY arc, but you can get nonplanar and they work
[20:13:56] <alex_joni> well, there is probably a computational way to do it, but I don't think it's straightforward
[20:14:45] <cradek> do what?
[20:15:15] <alex_joni> take an XY arc, and rotate it (along with the coordinate system of the program) to an arbitrary XYZ orientation in space
[20:15:31] <alex_joni> (and still have it expressed in a way that emc2 can run it)
[20:15:39] <cradek> you can't express it in gcode
[20:15:57] <cradek> well I guess I still don't know what you mean
[20:16:09] <cradek> if it's post-gcode, we don't have that arbitrary-rotation operation
[20:16:22] <cradek> if you're talking about filtering gcode, you can't because the arc cannot be expressed
[20:16:27] <alex_joni> take a look at this pic:
http://smerobot-tools.prospektiv.de/robotic/eng/werk-koord.jpg
[20:16:45] <alex_joni> but imagine that the table is not parallel with the floor
[20:16:49] <cradek> THAT we can do currently
[20:16:54] <alex_joni> so there is also another rotation in there
[20:16:56] <cradek> oh - then fix the table
[20:17:19] <alex_joni> well, basicly there are more than one workplace around the robot
[20:17:30] <alex_joni> and with a 6-dof robot parts are very rarely planar
[20:17:49] <cradek> the tool vector would need to change, too
[20:18:37] <alex_joni> tool vector?
[20:18:47] <alex_joni> you mean the tool orientation? yeah, sure
[20:18:53] <alex_joni> but that's part of XYZABC
[20:19:30] <cradek> well not really
[20:19:44] <cradek> I think how you get from (any two of) ABC to tool vector depends on the machine
[20:20:32] <cradek> we do have ABC coordinate system offsets - maybe that's enough to do the tool vector rotation?
[20:22:07] <alex_joni> that's why I love teach-in on robots :D
[20:22:15] <alex_joni> makes everything soo much easier
[20:22:16] <cradek> yes - a nice cop-out
[20:22:32] <alex_joni> especially when you're up to 12-18 DOFs you need to move
[20:22:57] <alex_joni> (during a circular interpolation even :)
[20:23:26] <jepler> at some point victory comes in admitting emc is not just one small tweak away from being the software you need :-/
[20:23:52] <alex_joni> jepler: who says I'm looking for a small tweak :P
[20:24:06] <cradek> whatever you're looking for, seems like you're not finding it here...
[20:24:15] <alex_joni> but yeah, I get it, just trying to figure out what can be done without basicly rewriting the whole thing
[20:24:48] <cradek> you'd have to do the offsetting before you make the gcode
[20:24:57] <cradek> I think you can't do anything else
[20:24:59] <alex_joni> I still think that a simple filter changing coordinates from the regular carthesian coords to an arbitrary translated/rotated coordinate system should work
[20:25:12] <cradek> alex_joni: you're not the first person to think that
[20:25:48] <alex_joni> another way to consider it is adding some extra 3 dofs to genserkins
[20:26:16] <alex_joni> to rotate the whole robot
[20:26:16] <cradek> you can't change 'offsets' in kinematics
[20:26:18] <alex_joni> then use g92 for the translation
[20:26:25] <cradek> that's after position interpolation
[20:26:27] <alex_joni> cradek: this is most likely a one-time thing
[20:26:42] <alex_joni> change, start emc2, run the program
[20:26:55] <alex_joni> change as in a couple of setp's in the hal file
[20:27:03] <cradek> weird, but ok
[20:27:15] <alex_joni> anyways, I'll have to drive a couple hours tomorrow, so surely time to think about it ;)
[20:27:27] <alex_joni> * alex_joni is off to bed early
[20:27:30] <alex_joni> see you all
[20:27:32] <cradek> 'night
[20:28:42] <jepler> yes, 'night
[20:28:48] <jepler> in just two or three short hours I might be asleep too
[20:31:16] <SWPadnos> wow. I just got a spam with an "@lycos.com" return address. I didn't think they were still around
[20:31:34] <SWPadnos> (or maybe they aren't but the spambots don't know that yet)
[20:32:34] <cradek> lycos.aol@webtv.geocities.hotmail.net?
[20:33:01] <SWPadnos> .net.com
[20:37:01] <skunkworks> what was the free email from back in the day? didn't need a isp - could use their 1-800 numbers?
[20:37:12] <cradek> I couldn't think of it either
[20:37:19] <skunkworks> heh
[20:39:42] <SWPadnos> not compuserve (they weren't free IIRC)
[20:39:47] <SWPadnos> but something like them
[20:39:51] <skunkworks> started with a v?
[20:40:08] <skunkworks> wow - I think that was my first email address.
[20:40:10] <cradek> certainly not compuserve
[20:40:18] <skunkworks> you would think I would remember that.
[20:40:28] <cradek> 14352,127@... haha
[20:40:29] <jepler> there were a number of free dialups in the early days of consumer internet but I thought they generally had local access numbers (not 1-800)
[20:40:44] <cradek> this one had both - they liked it if you used the local number.
[20:40:46] <skunkworks> juno
[20:41:01] <skunkworks> is what I was thinking of
[20:41:28] <SWPadnos> I remember them. they weren't available everywhere though, only in some metro areas it seemed
[20:41:35] <skunkworks> so it didn't start with a v
[20:41:39] <SWPadnos> or maybe everywhere but Vermont
[20:45:22] <psha> jepler: may you take a look on python hal.pin patch?
[20:47:06] <psha> http://psha.org.ru/cgit/psha/emc2.git/commit/?h=pyhal-pin
[20:47:14] <psha> or somebody else...
[20:49:13] <SWPadnos> psha, check the logs, I think jepler made some comments on the patch earlier
[20:49:22] <SWPadnos> (or at least they were python and hal related :) )
[20:49:25] <SWPadnos> bbl
[20:53:30] <psha> thanks
[20:54:51] <psha> hm, found link to
http://en.wikipedia.org/wiki/Sima_%28mead%29 :)
[20:56:16] <psha> jepler: maybe get_param will be useful too
[20:56:20] <psha> to separate pins/params
[20:58:44] <psha> holding name in pin object is nice feature, i'll add it tomorrow
[20:59:36] <psha> as for different objects for pin/param - i don't think it's really important
[20:59:47] <psha> maybe on python level, not in for c-api
[21:00:36] <psha> something like hal.py and hal.so renamed to _hal.so will solve this with much less effort
[21:18:06] <CIA-2> EMC: 03seb 07master * r3aef19dca46c 10/src/hal/drivers/mesa-hostmot2/doc/encoder/ (13 files): add some docs on the hm2 driver's encoder handling
[21:34:02] <psha> pin/param separation seems useless until any form of signal handling (link/unlink) is introduced in python
[21:34:43] <psha> but link/unlink is not needed now as i understand
[21:35:15] <jepler> If a thing is actually a param, I don't like that I call a function getpin() to find it, and I don't like that type(it) is "pin"
[21:36:11] <jepler> it's true that it's mostly cosmetic
[21:36:22] <psha> getparam will be nice
[21:36:32] <psha> maybe renaming hal.pin to hal.item?
[21:37:26] <psha> i really don't think that pin/param separation have to be implemented in c-api
[21:38:08] <psha> maybe is_pin() function with python wrappers for Pin/Param types will be better?
[21:38:55] <jepler> if writing it in python is the best way to achieve it, I'm not against it
[21:39:07] <psha> it's not best
[21:39:15] <psha> but less verbose...
[21:40:14] <psha> i'll add pin/param name and then try to experiment with different ways of pin/param separation
[21:40:21] <jepler> OK
[21:40:40] <psha> bb
[21:40:47] <jepler> I'll fix the ability to set IN pins and look at adding the item name to the structure so that it can be shown in the repr of an item
[23:00:28] <andypugh> Default Trap Handler: vector 14: Suspend RT task eede0800
[23:00:37] <andypugh> That's a null pointer isn't it?
[23:01:22] <andypugh> (Oddly, Halrun doesn't blink an eyelid. Only clue is one line in the dmesg when I was wondering what was wring with the thread timings)
[23:15:55] <jepler> yes
[23:16:44] <jepler> * jepler goes in search of dinner
[23:17:14] <andypugh> Got it, I think,
