Back
[04:04:20] <CIA-22> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: pulled bitfile opening out to a reusable function
[04:04:50] <CIA-22> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: adding some whitespace before I go cross-eyed
[04:05:27] <CIA-22> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: look up the boardtype-to-program in the board info table
[04:06:32] <CIA-22> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: turn the device_id into a board number (for pci only)
[04:07:11] <CIA-22> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: locate the requested PCI board
[04:10:06] <CIA-22> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c:
[04:10:06] <CIA-22> EMC: program the device! yay!
[04:10:06] <CIA-22> EMC: New-style command-lines are now fully supported. The usage output needs
[04:10:06] <CIA-22> EMC: updating, it needs a manpage, and the old-style command-line needs to
[04:10:06] <CIA-22> EMC: be deprecated. Its progress output could be prettier.
[04:23:11] <CIA-22> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: verify board chip type against bitfile chip type
[10:51:13] <alex_joni> morning all
[11:01:54] <sCOTTo> hey guys anyone here?
[11:03:47] <sCOTTo> i have questions for all you smart ppl
[11:03:51] <sCOTTo> ;)
[11:06:11] <alex_joni> sCOTTo: ask away
[11:06:44] <sCOTTo> i have a customer who is using austocad... he has come to me asking HARD questions.... i need your help....
[11:07:34] <alex_joni> not sure you'll get any good autocad answers in here, but you can try
[11:07:42] <sCOTTo> he wants to find something - maybe opensource / free - to convert his autocad to either IGES or STEP extension to use with CNC machines.... can you point me in the right direction?
[11:08:01] <sCOTTo> autocad... yes i know - you guys dont use it :)
[11:08:04] <alex_joni> is it 3D ? or 2D?
[11:08:22] <sCOTTo> not sure but it looks 3d to me.
[11:08:24] <sCOTTo> i think
[11:08:36] <sCOTTo> he is designing a motor or something i think
[11:08:42] <sCOTTo> he has no budget though :(
[11:08:48] <BigJohnT> he should be able to do a save as in acad
[11:08:51] <sCOTTo> he is also a friend - so i want to help him if i can....
[11:08:56] <sCOTTo> ACAD?
[11:08:57] <alex_joni> I usually use Alibre for 3D (kinda free)
[11:09:06] <alex_joni> and it exports IGES and STEP
[11:09:15] <alex_joni> ACAD = autocad
[11:09:18] <sCOTTo> Alibre - is that opensrc?
[11:09:34] <alex_joni> nope
[11:09:40] <sCOTTo> bugger
[11:09:46] <sCOTTo> is it expensive?
[11:09:49] <alex_joni> but it's free to use
[11:09:53] <sCOTTo> hehehe
[11:09:55] <BigJohnT> just checked and no on the save as
[11:09:56] <sCOTTo> ok....
[11:10:01] <sCOTTo> bugger
[11:10:29] <BigJohnT> alex will it open a dwg file?
[11:10:32] <BigJohnT> I forget
[11:10:42] <alex_joni> BigJohnT: yes, but I don't recommend it
[11:10:48] <alex_joni> it's fine for work on solids
[11:10:53] <alex_joni> importing 2D stuff is painful
[11:11:19] <BigJohnT> ok
[11:12:32] <BigJohnT> morning alex
[11:12:43] <alex_joni> hiya
[11:13:40] <sCOTTo> so any other ideas guys?
[11:15:02] <BigJohnT> even if he converts it to IGES or STEP he still has to convert it to G-Code with cam software
[11:15:37] <sCOTTo> i dunno
[11:15:44] <sCOTTo> all i have is an email...
[11:17:59] <sCOTTo> he lives next door from me i might go chat with him - bbs
[11:19:34] <alex_joni> sCOTTo: wither way, I think #emc is more appropriate than #emc-devel
[11:19:46] <alex_joni> (this channel is mostly for development inside emc2..)
[11:20:12] <BigJohnT> I was wondering....
[11:20:22] <alex_joni> there is also a #cam you might want to visit
[11:20:34] <alex_joni> BigJohnT: wondering what?
[11:20:47] <BigJohnT> about all the chatter on cad/cam
[11:29:38] <BigJohnT> when EMC2.3 comes out will it be on the 8.n of ubuntu?
[11:29:58] <alex_joni> emc2.x is not directly tied to an OS
[11:30:05] <alex_joni> you can run it on whatever you like :)
[11:30:50] <alex_joni> if we have 8.04 packages and liveCD & so on, by the time emc2.3 comes out, then surely we'll build 2.3 packages for it too
[11:31:02] <BigJohnT> ok
[11:35:41] <alex_joni> that doesn't mean we won't have 2.3 packages for dapper
[11:59:17] <alex_joni> bbl
[12:45:20] <christle> [Global Notice] Hi all! It appears we are having some problems making our EU and US hubs speak with eachother, I'm going to do some noisy re-hubbing and hopefully we'll be back to normal shortly! Thank you for using freenode and have a great day!
[13:10:23] <christel> [Global Notice] Hi all, Sorry about the disturbance there -- all should be back to normal-ish now. Have a good day.
[13:33:38] <alex_joni> hi, anyone around?
[13:36:35] <fenn> meep
[13:36:44] <alex_joni> 'lo
[13:39:50] <fenn> alex_joni: what do you think about a emc-docs package?
[14:00:39] <alex_joni> fenn: you mean to sepparate the docs?
[14:00:47] <alex_joni> I'm not opposed
[14:08:07] <alex_joni> cradek, jmkasunich: let me know when you're around
[14:51:17] <jmkasunich> alex_joni: I'm around right now, but only for a few minutes - I have chores to do this morning
[15:20:09] <alex_joni> jmkasunich: it can wait for later
[15:20:16] <alex_joni> I want to discuss how to do homing
[15:20:23] <alex_joni> (at the task<->motion level)
[15:20:33] <alex_joni> actually GUI<->task<->motion
[15:20:41] <alex_joni> so I have something to keep myself busy
[15:25:58] <jmkasunich> I wish I had that problem
[15:26:38] <jmkasunich> I have enough stuff to keep me busy for months, maybe years ;-)
[15:45:00] <alex_joni> well, me too.. but I try to keep myself busy on emc
[15:47:44] <jmkasunich> lately I feel kind of guilty because I haven't done anything for the project
[15:48:02] <alex_joni> I know how that goes
[15:48:13] <alex_joni> but I guess we'll strike your pay for the current month
[15:48:19] <alex_joni> maybe that will make you feel better :)
[15:50:10] <jmkasunich> oh, now I'm poor _and_ guilty
[15:50:35] <alex_joni> haha
[17:50:04] <alex_joni> jmkasunich: now, that you've blown your cover ..
[17:50:14] <jmkasunich> darn
[17:50:19] <alex_joni> heh, kidding..
[17:50:27] <alex_joni> I was wondering about a design issue
[17:50:49] <alex_joni> we can jog joints (incremental, continuous) and axes (velocity mode atm)
[17:50:56] <jmkasunich> ok
[17:51:00] <alex_joni> should we have a difference at GUI level?
[17:51:11] <alex_joni> or should GUI just jog the first active thing
[17:51:20] <alex_joni> and motion decide if it's a joint or an axis
[17:51:27] <alex_joni> depending on the mode in?
[17:51:31] <jmkasunich> well, from motion's point of view, you are either in joint mode or axis mode
[17:51:40] <alex_joni> right, I know..
[17:52:10] <jmkasunich> I was thinking to reuse the same EMCMOT_JOG_CONT, EMCMOT_JOG_INCR, etc commands
[17:52:29] <jmkasunich> but I'm not against EMCMOT_JOG_AXIS_INCR and EMCMOT_JOG_JOINT_INCR
[17:54:33] <alex_joni> I think it would clear up code a bit
[17:54:47] <alex_joni> if we only have EMC_JOG_CONT and EMC_JOG_INCR
[17:55:02] <jmkasunich> the main difference is that if we do the latter, motion might issue errors like "can't jog axis in joint mode" or "can't jog joints in axis mode"
[17:55:40] <jmkasunich> it would be simpler to just have JOG_INCR etc
[17:56:00] <alex_joni> ok, sounds good
[17:56:17] <jmkasunich> if the GUI doesn't know what mode the machine is in, we have worse problems than misinterpreting axis jogs as joint or vice-versa
[17:56:21] <alex_joni> and the pointer to the joint/axis to jog is a simple counter..
[17:56:40] <alex_joni> 0 for joint 0 _or_ axis X
[17:56:51] <jmkasunich> yes
[17:57:00] <jmkasunich> today it works like that, pass a joint number
[17:57:19] <jmkasunich> in this case, it would be treated joint number OR axis number depending on mode
[17:57:36] <alex_joni> there is another thing
[17:57:45] <alex_joni> currently for teleop we can supply all vectors
[17:57:56] <alex_joni> so one can jog in carth. space in multiple directions at once
[17:58:29] <jmkasunich> heh, actually only one direction at a time, but that direction doesn;t have to be aligned with a cartesean axis
[17:58:46] <fenn> 9-axis space
[17:58:52] <alex_joni> ok, right.. that's what I meant
[17:59:39] <jmkasunich> currenty you can sort of do that with joint jogs (but not as nicely)
[18:00:04] <jmkasunich> you can issue a jog for joint 2, then a another one for joint 4, and they sum to produce a vector
[18:00:09] <jmkasunich> but they are not coordinated
[18:00:11] <alex_joni> that's why I want to discuss this through and find a really good way to do it
[18:01:24] <jmkasunich> what exactly is "it"
[18:01:32] <alex_joni> so: we have INCR jogging (which is simply an increment in a specific direction for a joint/axis)
[18:01:44] <jmkasunich> INCR, CONT, and ABS
[18:02:00] <jmkasunich> none of the GUIs ever issue ABS, but it exists
[18:02:05] <alex_joni> we have CONT joggign (which is velocity based jogging - sign determines direction, number for joint/axis)
[18:02:17] <alex_joni> and ABS for a certain location
[18:03:07] <jmkasunich> they are all implemented as absolute position based
[18:03:50] <jmkasunich> ABS sets the target position to the given value, INCR changes the target position by the given value, and CONT sets the target position past machine limits, so you have to send an abort to stop it
[18:04:05] <alex_joni> I know, but that's irrelevant for me (I think..)
[18:04:16] <jmkasunich> heh
[18:04:52] <alex_joni> I'm trying to define a clean interface from GUI <-> task <-> motion
[18:05:04] <alex_joni> without caring how GUI implements it, or how motion implements it..
[18:05:33] <jmkasunich> are you trying to maintain the "move along this vector" ability that teleop gives us?
[18:05:41] <jmkasunich> I'm not
[18:05:52] <alex_joni> here's a thought..
[18:06:04] <alex_joni> what if a new jog wouldn't abort an running jog?
[18:06:32] <jmkasunich> a new jog on the same axis, or on a different axis? (or joint)
[18:06:33] <alex_joni> except if there's an explicit jog-stop (implemented as ABORT currently)
[18:06:38] <alex_joni> on a different joint
[18:06:44] <jmkasunich> it doesn't
[18:06:44] <alex_joni> or axis
[18:06:57] <fenn> you can jog diagonal because it doesnt
[18:07:02] <jmkasunich> exactly
[18:07:11] <alex_joni> ok.. then we're pretty close to the move along this vector
[18:07:27] <jmkasunich> JOG_CONT is stopped by "AXIS_ABORT" today, so other axes can keep moving
[18:07:27] <alex_joni> I'd say it's pretty close enough
[18:07:49] <jmkasunich> I do agree that I'd rather have JOG_STOP(axis) instead of using the abort
[18:08:54] <alex_joni> ok, so .. _JOG_CONT (nr, speed), _JOG_INCR (nr, step, speed), _JOG_ABS (nr, pos, speed), _JOG_STOP (nr) ?
[18:09:12] <jmkasunich> yeah
[18:09:35] <alex_joni> ok, sounds easy enough to implement
[18:09:52] <jmkasunich> the hard part has always been keyboard jogging
[18:09:52] <alex_joni> obviously I'll have to fix all GUIs again (what a joy..)
[18:10:01] <jmkasunich> getting the key release events to work right
[18:10:08] <jmkasunich> I scared myself yesterday
[18:10:10] <alex_joni> yeah, but that should already be working
[18:10:25] <jmkasunich> my kb doesn't have page up/page down keys (for jogging Z)
[18:10:28] <alex_joni> changing message names, shouldn't be intrusive
[18:10:37] <jmkasunich> so I hit Z to select Z, then - to jog it down
[18:10:39] <alex_joni> and you used -/= ?
[18:10:46] <jmkasunich> then I hit down-arrow to move Y
[18:10:52] <alex_joni> ouch..
[18:10:57] <jmkasunich> that changed the selection from Z to Y, so when I released -, the Z didn't stop
[18:11:26] <jmkasunich> I was fast enough to the esc key that I didn't crash the tool
[18:11:45] <alex_joni> lucky..
[18:12:09] <alex_joni> * alex_joni strokes his robot pendant
[18:12:16] <alex_joni> it has 6 pairs of jog buttons
[18:12:24] <jmkasunich> heh
[18:12:28] <alex_joni> usually I run out of fingers ..
[18:12:37] <alex_joni> but it's nice :D
[18:13:29] <jmkasunich> yep
[18:50:09] <awallin_emc> any idea why I'm missing 'make' after installing emc2-dev?
[18:50:33] <alex_joni> yeah, it's not in emc2-dev
[18:50:40] <alex_joni> you want to install build-essential
[18:50:47] <awallin_emc> ok.
[18:52:20] <jmkasunich> sad isn't it - that linux distros are no longer installing build tools by default
[18:54:17] <awallin_emc> now I'm missing stddef.h
[18:54:40] <alex_joni> awallin_emc: what are you trying to do?
[18:55:19] <awallin_emc> compile vncrec for making the screen video
[18:55:36] <awallin_emc> the compile instructions start with: xmkmf -a
[18:55:55] <awallin_emc> http://www.sodan.org/~penny/vncrec/
[18:56:28] <alex_joni> no idea why stddef.h is missing
[18:57:56] <awallin_emc> should be in build-essential?
[18:58:43] <alex_joni> nope, that only holds make & gcc iirc
[18:58:50] <alex_joni> try an apt-file search stddef.h
[18:58:59] <alex_joni> (after installing apt-file, and updating)
[19:09:46] <fenn> comes with gcc or linux-headers
[19:21:46] <awallin_emc> fenn: I have bot gcc and linux-headers-2.6.15-magma, but still missing stddef.h
[19:21:53] <awallin_emc> where is it on a properly installed system?
[19:22:26] <alex_joni> I have it from the linux-headers-2.6.15-magma package
[19:22:47] <alex_joni> check /usr/include/stddef.h or /usr/include/linux/stddef.h
[19:23:38] <awallin_emc> yep, it's in /linux the script just doesn't search there
[19:23:44] <awallin_emc> a logical link perhaps?
[19:24:00] <alex_joni> ln -s /usr/include/linux/stddef.h /usr/include/stddef.h
[19:25:29] <awallin_emc> argh. next missing file is stdarg.h
[19:25:45] <alex_joni> I think something is wrong with that package
[19:30:26] <awallin_emc> where would stdarg.h be ??
[19:31:38] <alex_joni> can't find it on my system either
[19:31:59] <awallin_emc> wikipedia says it's a standard library...
[19:32:09] <alex_joni> in libc I think
[19:32:22] <awallin_emc> anyway maybe this screen recording is too complex. point a DVcam at the screen instead :)
[19:32:45] <alex_joni> libc-dev maybe?
[19:33:32] <awallin_emc> libc6-dev is newest version
[19:36:39] <alex_joni> dpkg -L libc6-dev | grep stddef
[19:38:31] <awallin_emc> that gives me nothing? how about on your machine?
[19:38:56] <alex_joni> same here
[19:41:11] <alex_joni> I think stddef is supplied by gcc
[19:46:15] <awallin_emc> I'm just going to forget vnc for now :) doing some hal and halui instead
[19:50:15] <awallin_emc> in HAL, is there the opposite of a mux2? i.e. one input that is directed to either of two outputs depending on a selection bit
[19:50:59] <cradek> sure, use a not and two ands
[19:51:41] <awallin_emc> hm, ok that would work. thanks.
[19:52:45] <awallin_emc> no manual entry for and
[19:52:54] <awallin_emc> and2?
[19:53:03] <awallin_emc> yeah...
[19:59:53] <awallin_emc> hm, it's this edge-triggered vs. level triggered thing again. now I get oscillations with the not+ two ands circuit
[20:00:12] <awallin_emc> basically I want to turn on and off coolant with one pushbutton
[20:00:42] <cradek> man toggle
[20:01:13] <awallin_emc> yes, but then the toggle output needs to go to halui.flood.on and halui.flood.off depending on the current state of the coolant
[20:01:48] <cradek> oh, hmm
[20:02:22] <cradek> you can do it in CL with edge trigger. are you already using CL?
[20:02:43] <awallin_emc> no, I haven't looked at CL at all
[20:03:08] <cradek> -|is on|---|^ button|----(turn off)--
[20:03:30] <cradek> -|is off|--|^ button|---(turn on)--
[20:05:01] <awallin_emc> the toggle works just fine in HAL
[20:05:24] <awallin_emc> would think that based on this working bit signal in HAL I could set the coolant state with halui?
[20:06:19] <cradek> I bet halui triggers on rising edge.
[20:06:30] <awallin_emc> I guess halui gives the order to set coolant on, and before is-on goes up another call to the not+2ands is done and that sets coolant off
[20:06:34] <cradek> you could hook toggle.out->on, /toggle.out->off
[20:08:10] <awallin_emc> by / you mean not?
[20:08:13] <cradek> yes
[20:09:38] <awallin_emc> ah, that works. good. only thing was I get a warning about flood-off cannot be set while machine is not on as emc starts
[20:10:29] <awallin_emc> except you have to press twice if the coolant state changes from MDI or AXIS
[20:11:40] <cradek> yuck
[20:11:51] <cradek> toggle is the wrong thing to use isn't it
[20:12:30] <cradek> will you have more stuff like this? I bet ladder really is the easy way to get what you want
[20:12:43] <awallin_emc> it has state, which goes wrong if I control coolant from outside halui
[20:12:56] <cradek> right, it shouldn't have state
[22:03:57] <alex_joni> jmkasunich: around?
[22:04:07] <alex_joni> (promise it's something simple :P)
[22:04:32] <alex_joni> was wondering if it's much trouble/overhead to add another branch to the CF
[22:27:19] <alex_joni> * alex_joni eats CIA-30
[22:27:19] <CIA-30> * CIA-30 tastes crunchy
[22:29:13] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/nml_intf/ (emc.cc emc.hh emc_nml.hh emcglb.h): started changing jogging NML commands (EMC_JOG_CONT, EMC_JOG_INCR, EMC_JOG_ABS and EMC_JOG_STOP)
[22:29:23] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/ (halui.cc keystick.cc shcom.cc): started changing jogging NML commands (EMC_JOG_CONT, EMC_JOG_INCR, EMC_JOG_ABS and EMC_JOG_STOP)
[22:33:42] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/xemc.cc: started changing jogging NML commands (EMC_JOG_CONT, EMC_JOG_INCR, EMC_JOG_ABS and EMC_JOG_STOP)
[22:46:36] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/nml_intf/emc.hh: fix function names for jogging
[22:47:02] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/task/ (emctaskmain.cc taskintf.cc): changed jogging NML commands (EMC_JOG_CONT, EMC_JOG_INCR, EMC_JOG_ABS and EMC_JOG_STOP)
[22:50:39] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc: update AXIS for changed jogging NML commands (EMC_JOG_CONT, EMC_JOG_INCR, EMC_JOG_ABS and EMC_JOG_STOP)
[22:52:42] <jmkasunich> regarding the toggle coolant thing:
[22:53:10] <jmkasunich> currently halui has input pins that say "turn FOO on", and "turn FOO off"
[22:53:24] <jmkasunich> perhaps it needs an input that says "toggle the state of FOO"
[22:53:27] <alex_joni> jmkasunich: should I touch motion? or will you ? (regarding the jogging changes..)
[22:54:12] <jmkasunich> alex_joni: I just sat down here after yard work and dinner, let me catch up ;-)
[22:54:43] <alex_joni> heh, sounds nice
[22:56:11] <jmkasunich> ok, I see new NML stuff
[22:56:30] <alex_joni> mostly name changes
[22:57:18] <jmkasunich> the next step is changes in emc/motion/usrmotintf.cc and corresponding changes to command.c, etc?
[22:57:35] <alex_joni> I think the commands in command.c are about right
[22:57:36] <jmkasunich> or is there another layer in there that I'm missing?
[22:57:37] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/motion/ (command.c motion.h): remove *teleop_vector*, those will be handled by regular jog messages (with motion controller in TELEOP mode, not in joint mode)
[22:57:44] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/nml_intf/emc.hh: remove *teleop_vector*, those will be handled by regular jog messages (with motion controller in TELEOP mode, not in joint mode)
[22:57:45] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/task/taskintf.cc: remove *teleop_vector*, those will be handled by regular jog messages (with motion controller in TELEOP mode, not in joint mode)
[22:58:06] <alex_joni> jmkasunich: I think you meant taskintf.cc - I think I'm done with that
[22:58:22] <jmkasunich> taskintf.c isn't in the emc/motion directory
[22:58:35] <jmkasunich> duh, nevermind
[22:58:47] <jmkasunich> usrmotintf.cc is generic message handling
[22:58:48] <alex_joni> now all jog commands from GUIs arrive at motion as: EMCMOT_JOG_CONT, EMCMOT_JOG_INCR and EMCMOT_JOG_ABS
[22:58:56] <jmkasunich> the specific messages must be in taskintf.cc
[22:59:13] <alex_joni> yes, the EMCMOT_* names were quite good, so I didn't change them
[22:59:29] <jmkasunich> you added NML messages for JOG_STOP
[22:59:43] <alex_joni> I only changed the name of the functions that send those to shm, the NML that triggered that functions, etc
[22:59:59] <alex_joni> actually I renamed JOINT_ABORT() to JOG_STOP(), as it was it's only use..
[23:00:05] <jmkasunich> ok
[23:00:14] <alex_joni> btw, initially it was called AXIS_ABORT()
[23:00:15] <jmkasunich> did you touch the EMCMOT side of that one?
[23:00:24] <alex_joni> no
[23:00:32] <jmkasunich> ok
[23:00:34] <alex_joni> it's still EMCMOT_JOINT_ABORT I think
[23:00:41] <jmkasunich> I need to get a checkout of joints_axes branch
[23:00:55] <jmkasunich> you were wondering about putting that on the compile farm, right?
[23:00:58] <alex_joni> I think the fastest is to copy your TRUNK
[23:01:07] <alex_joni> and cvs up -rjoints_axes
[23:01:19] <alex_joni> works way faster then a fresh checkout..
[23:01:33] <jmkasunich> a complete checkout only takes 5 mins or so, maybe 10 tops
[23:01:45] <alex_joni> ok.. takes a bit longer here
[23:01:53] <alex_joni> (the docs are mostly the issue I had..)
[23:03:59] <jmkasunich> checkout started
[23:04:07] <jmkasunich> hint - use -z9 instead of -z9
[23:04:25] <alex_joni> * alex_joni is obtuse at this hour
[23:04:32] <jmkasunich> better compression - it helps on a bandwidth limited transfer - there is plenty of CPU at the other end for doing the compression
[23:04:35] <alex_joni> what's the difference between -z9 and -z9 ?
[23:04:40] <jmkasunich> oops
[23:04:45] <alex_joni> :P
[23:04:46] <jmkasunich> -z9 vs. -z5
[23:05:05] <alex_joni> ah, ok ;)
[23:05:37] <alex_joni> brb, gotta get some food ..
[23:07:02] <jmkasunich> checkout done
[23:07:09] <jmkasunich> looks like only 3 mins ;-)
[23:09:54] <jmkasunich> emc/task/taskintf.cc:60: warning: ‘emcmotAxesInited’ defined but not used
[23:09:54] <jmkasunich> emc/task/taskintf.cc:82: warning: ‘localEmcAxisUnits’ defined but not used
[23:11:47] <alex_joni> yeah, I know about those
[23:12:11] <jmkasunich> ok
[23:12:38] <alex_joni> left them as a remainder mostly
[23:14:45] <alex_joni> there are a couple of things I haven't thought through yet
[23:15:14] <alex_joni> for example : canon needs carthesian limits (velocities and accels) when it gets commands from interp
[23:15:38] <alex_joni> should we have those defined in the ini? or should they get computed from joint limits and kinematics?
[23:16:09] <jmkasunich> do you really think I've thought about that?
[23:16:17] <alex_joni> no, I'm sure you haven't
[23:16:34] <jmkasunich> I don't think in the general case you can compute them from joint limits
[23:16:38] <alex_joni> (just bringing it up now, so we can both sleep on it for a couple of days/weeks)
[23:16:53] <alex_joni> no, but you can probably compute them for a specific move
[23:17:31] <jmkasunich> I don't see how
[23:17:43] <alex_joni> say you have a linear move, running that through kins should give some max joint speeds, then scaling eveything so that the resulted joint speeds don't exceed the defined limits
[23:18:01] <jmkasunich> unless you are actually gonna evaluate lots of points along the move, before you actually queue the move
[23:18:03] <alex_joni> basicly you need to simulate the move in userspace
[23:18:07] <alex_joni> yeah
[23:18:10] <jmkasunich> ewww
[23:18:19] <alex_joni> jmkasunich: I'm not sure there is another way
[23:18:36] <jmkasunich> like I said, IMO there is NO way
[23:18:40] <alex_joni> and I'm pretty sure we want to do this in userspace
[23:18:53] <jmkasunich> because simulating the move in userspace is just so fscking ugly that I consider it not a way
[23:18:56] <alex_joni> not do the simulation in RT, with deadlines knocking on the door
[23:19:40] <jmkasunich> the userspace sim may be the best way to do joint constraints, but I was planning on quietly ignoring them
[23:19:47] <alex_joni> jmkasunich: obviously I am a bit biased, by taking a peek at the robots I work with..
[23:20:30] <alex_joni> but they work like this..
[23:20:38] <alex_joni> (oh, and they have no FO :)
[23:22:07] <jmkasunich> thinking about it a bit more, and it probably is the only reasonable way
[23:22:25] <alex_joni> as I said, I only meant to bring it up to attention
[23:22:31] <alex_joni> I'm sure we won't fix it tonight..
[23:22:59] <alex_joni> but having an idea/problem in the back of my head, sure helps sometimes
[23:23:08] <alex_joni> after a while it becomes obvious :D
[23:23:14] <jmkasunich> yeah
[23:23:31] <jmkasunich> I wish the parts I need to run were "start the program and do something else" parts
[23:23:49] <jmkasunich> but they need watched - applying cutting fluid, and changing tool
[23:23:52] <alex_joni> don't feel to bad.. I need to sleep too :)
[23:23:58] <alex_joni> s/to/too/
[23:24:49] <alex_joni> (the sim configs seem to run on the branch)
[23:24:57] <jmkasunich> go to sleep, I'll try to get the parts done, then think about some code
[23:25:18] <alex_joni> I'm not sure they use the proper joint limits (accel/vel, etc).. but it's useable for testing codechanges
[23:25:33] <alex_joni> I'll work on the ini part some more, when we have an idea what to expect there..
[23:26:29] <alex_joni> I wouldn't haved imagined that one day I would enjoy working with NML messages
[23:26:40] <alex_joni> it's quite fun actually
[23:42:48] <alex_joni> good night all
[23:52:43] <cradek> alex_joni: thanks for all that work. it's really coming along.
[23:53:36] <cradek> jepler came up with breaking up the move in userspace and deriving cartesian constraints. I like this because it doesn't change anything in motion/tp. I think it's ugly too, but if there's only one way to do something, and you want to do it, that's the perfect way.
[23:53:55] <cradek> oops, I meant jepler ALSO came up with that scheme