Back
[03:39:20] <jmkasunich> yeah, teleop is truly bitrotted
[03:39:41] <jmkasunich> I got impatient waiting for the MDI to unwind B, so I tried to go back to the manual tab
[03:40:09] <jmkasunich> it popped up an error message (which I don't remember), and then popped out of $ mode, back to numbered axes
[03:40:25] <jmkasunich> and of course now I its stuck in that mode
[03:40:30] <cradek> ouch
[03:41:03] <jmkasunich> "all axes must be homed before going into coordinated mode"
[03:41:10] <jmkasunich> even immediately after I hit home all
[03:41:26] <jmkasunich> its gotta be that mess of homed state flags
[03:41:37] <cradek> yeah I bet so too
[03:42:09] <cradek> good or bad news I dunno: teleop accel is also wrong in rt
[03:42:19] <jmkasunich> good I think
[03:42:35] <cradek> I thought I fixed that once already
[03:42:45] <cradek> I wonder if it's a units problem. This is a metric config.
[03:42:46] <jmkasunich> differences between sim and rt are bad
[03:43:02] <cradek> yeah.
[03:44:47] <jmkasunich> * jmkasunich draws a ball by jogging in joint mode
[03:44:54] <cradek> $ grep _FLAG *|wc -l
[03:44:54] <cradek> 256
[03:45:17] <jmkasunich> heh
[03:45:34] <jmkasunich> those aren't even the ones I was talking about
[03:45:48] <jmkasunich> (and most of them aren't homing related)
[03:46:32] <cradek> teleop uvw are totally missing
[03:48:30] <jmkasunich> things like "all_homed" in control.c, and JOINT_HOMED_FLAT, JOINT_AT_HOME_FLAG
[03:48:55] <jmkasunich> checkAllHomed() in command.c
[03:49:14] <jmkasunich> emcmotDebug->allHomed
[03:49:45] <jmkasunich> clearHomes
[03:50:03] <jmkasunich> rehomeAll
[03:50:16] <jmkasunich> all kinds of nasty intercoupled stuff
[03:50:21] <cradek> * cradek hides
[03:50:32] <jmkasunich> * jmkasunich hid a long time ago
[03:50:42] <jmkasunich> (from that stuff anyway)
[03:51:23] <jmkasunich> there is serious bustage in the axis vs. joint distinction (or lack thereof)
[03:52:19] <jmkasunich> checkAllHomed() returning false is the condition that causes the "all axes must be homed before going into coord (or teleop) mode" error
[03:53:35] <cradek> MAX_ACCELERATION = 800.0
[03:53:35] <cradek> DEFAULT_ACCELERATION = 800.0
[03:53:39] <cradek> [TRAJ]
[03:53:44] <cradek> this makes teleop work better
[03:53:46] <jmkasunich> it returns true if emcmotDebug->allHomed is true
[03:53:57] <cradek> but teleop smashes right through soft limits...
[03:54:23] <jmkasunich> if not true, it tests the HOMED_FLAG for all joints, and if all are homed, it sets emcmot_debug->allHomed and returns true
[03:54:38] <jmkasunich> if any joint is not homed, it returns false, and doesn't touch allHomed
[03:55:10] <jmkasunich> the problem with teleop and limits is that you don't know what limits to apply
[03:55:23] <cradek> oh right
[03:55:30] <jmkasunich> are the limits in the ini file applied to the raw joint pos, or to the cartesean coord?
[03:55:39] <cradek> limits are on joints, teleop moves in world
[03:55:50] <jmkasunich> maybe turning C causes X to move out of range
[03:55:54] <cradek> right
[04:00:09] <jmkasunich> goodnight
[04:00:21] <cradek> goodnight - nice to see you around again
[04:12:03] <fenn> hey cradek - why do you make a new hal pin for motion instead of just grabbing it from emcStatus in the kinematics code?
[04:12:47] <cradek> I thought it would be nice to have on a hal pin (not necessarily for use in kins)
[04:13:46] <cradek> is emcStatus even available in kins? they are just modules...
[04:15:19] <fenn> yes, unfortunately :\
[04:15:33] <cradek> yes which?
[04:15:39] <fenn> emcStatus is available
[04:15:53] <fenn> there's no "x input" for example
[04:16:10] <fenn> you have to do emcStatus.tran.x
[04:16:39] <cradek> ??
[04:16:47] <cradek> kins modules have 3 functions that are called by motion
[04:16:55] <cradek> type, forward, inverse
[04:17:08] <fenn> er.. well, it's something like that
[04:17:25] <fenn> x = world->tran.x;
[04:18:02] <cradek> I agree the EmcPose structure is a little goofy if that's what you're saying
[04:18:09] <cradek> it should be three PmCartesians
[04:18:34] <cradek> but ... it's not
[04:18:54] <cradek> (and it would be silly to change it)
[04:20:06] <fenn> aroo.. i think i'm off my rocker
[04:20:15] <fenn> or i fell through a time portal
[04:20:29] <fenn> anyway, emcStatus isnt in kinematics anywhere now that i look
[04:21:00] <cradek> ok, I'll remove my baffled look then
[14:12:00] <alex_joni> cradek: I've been doing 3D stuff all day again
[14:12:24] <alex_joni> and one feature I really use when drawing 3D stuff is the scroll button (zooming) to pan around
[14:12:40] <alex_joni> it usually zooms towards the point where the mouse is positioned
[14:13:01] <alex_joni> so zooming with the mouse in the middle of the screen is quite different than zooming with the mouse close to an edge
[14:13:38] <alex_joni> would this be something to consider for AXIS? I think it's a bit more intuitive..
[14:37:57] <cradek> I agree that would be great
[14:38:08] <cradek> I know other software that does it like that
[14:39:04] <alex_joni> I wonder how hard it is to do
[14:47:37] <cradek> in an ortho view, probably not too hard - in perspective, probably harder
[14:48:11] <alex_joni> yeah, perspective is the one I was talking about
[14:48:37] <alex_joni> does AXIS treat ortho differently?
[14:48:44] <alex_joni> or just a special case of perspective?
[14:51:10] <alex_joni> on another program I have it always rotates around a certain point. but I can change that point (by double clicking the middle button)
[14:51:26] <alex_joni> it puts a point at the intersection from the current view with the first solid it finds
[14:51:31] <cradek> they're different, because you have to do something different in gl to get ortho
[14:51:42] <alex_joni> cradek: ok, gotcha..
[14:56:39] <CIA-18> 03tissf 07TRUNK * 10emc2/docs/src/config/ (9 files): French translation
[14:56:40] <CIA-18> 03tissf 07TRUNK * 10emc2/src/po/fr_axis.po: French translation
[14:56:40] <CIA-18> 03tissf 07TRUNK * 10emc2/docs/src/install/ (compiling_emc2_fr.lyx installing_emc2_fr.lyx): French translation
[14:56:45] <CIA-18> 03tissf 07TRUNK * 10emc2/docs/src/ (Submakefile docs.xml index.tmpl index_fr.tmpl): French translation
[15:13:49] <CIA-18> 03tissf 07v2_2_branch * 10emc2/src/po/fr_axis.po: French translation update
[15:55:32] <CIA-18> 03tissf 07v2_2_branch * 10emc2/docs/src/ (Submakefile docs.xml index.tmpl index_fr.tmpl): French translation
[15:55:32] <CIA-18> 03tissf 07v2_2_branch * 10emc2/docs/src/config/ (8 files): French translation
[16:13:18] <alex_joni> bbl
[16:15:59] <jepler> yay more french documentation!
[16:16:12] <tissf> :)
[16:29:13] <tissf> jepler: Why a single parallel port possible with Stepconf? Why not one OR two?
[16:31:35] <tissf> Now you must create Stepconf II ;)
[16:46:46] <cradek> jepler: in vismach, can I make a cylinder (tool) that changes length with a hal pin?
[16:47:27] <jepler> cradek: good question
[16:48:32] <jepler> not at present, but a new class could easily be written. For your purposes, should it be most like CylinderZ, or most like one of the other cylinder classes?
[16:48:46] <cradek> most like cylinderZ
[16:50:04] <CIA-18> 03cradek 07TRUNK * 10emc2/src/emc/kinematics/5axiskins.c: for tool length compensating moves to work
[16:50:58] <CIA-18> 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/5axisgui.py: make a thing that looks like a spindle.
[16:52:18] <CIA-18> 03cradek 07TRUNK * 10emc2/configs/5axis/5axis.ini: remove stupid comments
[16:52:51] <jepler> cradek: try copying india:/usr/local/jepler/src/emc2/lib/python/vismach.py and use HalCylinder()
[16:52:57] <CIA-18> 03cradek 07TRUNK * 10emc2/configs/5axis/5axis_sim.hal: hook up tool offset to kins
[16:53:17] <jepler> args are comp, z1, r1, z2, r2; if the arg is a string then it's taken to be a component pin name, otherwise it's taken to be a constant
[16:53:24] <jepler> if it doesn't work right away I'll come debug it over your shoulder
[16:53:38] <jepler> er, HalCylinderZ
[16:53:46] <cradek> thank you
[16:56:16] <cradek> uh, -"tool_length"
[16:56:29] <cradek> hmm
[17:31:54] <jepler> cradek: whee
[17:32:41] <cradek> yeah isn't that the coolest
[17:35:19] <jepler> I bet fenn also ran into the need for a CylinderZ where the end points are computed based on hal values, instead of hardcoded
[17:35:40] <jepler> for the hexapod linear actuators
[17:36:09] <cradek> jepler: the gcodemodule fix needs to be backported?
[17:36:32] <fenn> actually i just made them move up and down
[17:36:46] <fenn> but i did write a HalScale transform
[17:37:10] <CIA-18> 03cradek 07TRUNK * 10emc2/configs/5axis/ (5axis.var 5axis_sim.hal): 5 axis tool length offset, and tool length visualization in vismach
[17:37:10] <CIA-18> 03cradek 07TRUNK * 10emc2/nc_files/cone.ngc: 5 axis tool length offset, and tool length visualization in vismach
[17:37:11] <CIA-18> 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/gcodemodule.cc: 5 axis tool length offset, and tool length visualization in vismach
[17:37:11] <CIA-18> 03cradek 07TRUNK * 10emc2/lib/python/vismach.py: 5 axis tool length offset, and tool length visualization in vismach
[17:37:15] <CIA-18> 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/5axisgui.py: 5 axis tool length offset, and tool length visualization in vismach
[17:49:07] <cradek> alex_joni: didn't we help ray with this PROGRAM_PREFIX thing before?
[17:49:42] <cradek> (it works for me)
[17:51:57] <alex_joni> cradek: I just answered him
[17:52:05] <alex_joni> he's using a sample config from /etc/emc2
[17:52:17] <alex_joni> and those I think have busted PROGRAM_PREFIX values
[17:52:26] <cradek> oh is that what he meant
[17:52:34] <alex_joni> if you select to copy the config to your own dir, it gets fixed during the copy
[17:52:54] <alex_joni> at least that's how I understood it..
[17:53:01] <cradek> ok
[17:53:30] <cradek> I read something else entirely, but I can also see your interpretation
[17:53:32] <alex_joni> (not the best bugreport..)
[17:53:41] <cradek> no, not at all.
[17:53:58] <alex_joni> I would have liked emc2-version, rip vs. installed, steps to duplicate.. etc
[17:53:59] <alex_joni> :D
[18:02:51] <CIA-18> 03cradek 07TRUNK * 10emc2/nc_files/cone.ngc: make this less confusing
[20:07:38] <alex_joni> haha:
https://mail.rtai.org/pipermail/rtai/2017-July/thread.html
[20:19:38] <fenn> aw ffs lyx totally munges the entire file
[20:23:06] <fenn> should i run lyx2lyx if i'm using lyx 1.4x?
[20:23:31] <alex_joni> check the lyx file version
[20:23:59] <fenn> < #LyX 1.3 created this file. For more info see
http://www.lyx.org/
[20:23:59] <fenn> < \lyxformat 221
[20:23:59] <fenn> ---
[20:23:59] <fenn> > #LyX 1.4.4 created this file. For more info see
http://www.lyx.org/
[20:23:59] <fenn> > \lyxformat 245
[20:24:09] <alex_joni> yup.. it needs to be 221
[20:24:52] <fenn> oh there's an export 1.3 option
[20:27:41] <tissf> Export in V1.3 is 221?
[20:27:52] <alex_joni> in case someone ever asks about USB and RT
[20:27:54] <alex_joni> https://mail.rtai.org/pipermail/rtai/2007-October/017940.html
[20:28:48] <fenn> tissf: yes it says 221 in the exported file
[20:29:28] <tissf> yay :)
[20:32:38] <CIA-18> 03fenn 07TRUNK * 10emc2/docs/src/gcode/main.lyx: added named parameters section, cleaned up wording of numbered parameters.
[21:36:02] <jepler> alex_joni: you broke the stepper-xyza configuration
[21:37:17] <CIA-18> 03jepler 07v2_2_branch * 10emc2/configs/stepper-xyza/inch.ini: revert changes accidentally committed in rev 1.12
[21:37:33] <CIA-18> 03jepler 07TRUNK * 10emc2/configs/stepper-xyza/inch.ini: revert changes accidentally committed in rev 1.12
[21:37:55] <alex_joni> argh.. really?
[21:38:05] <alex_joni> oh bugger it.. sorry
[21:38:15] <alex_joni> * alex_joni goes to remove those pesky gamepad.hal's
[21:39:29] <jepler> are there more? I didn't look..
[21:40:25] <alex_joni> huh.. that was 6 months ago..
[21:41:10] <alex_joni> I don't see any other commited
[21:46:00] <alex_joni> jepler: I see it's added in some other configs, but commented out
[22:13:08] <Roguish> cradek: did you intend to take these ">>>>>>> 1.5" out of the 5axisgui.py file? 'cause it really doesn't want to compile with them in.
[22:13:35] <Roguish> of course i could be full of sh... as you're not done yet...............................
[22:13:55] <Roguish> just courious
[22:15:36] <Roguish> or i did something wrong in a cvs update.
[22:17:30] <jepler> Roguish: that means you edited the file and so did another developer, and cvs couldn't automatically "merge" both sets of changes
[22:17:49] <jepler> Roguish: your changes appear between ">>>" and "===", and the other developer's changes appear between "===" and ">>>"
[22:17:59] <jepler> google "cvs conflict" should turn up more information
[22:18:18] <jepler> at this point you can: remove the file, 'cvs up' again to get the version from the cvs server and discard all your changes, or manually edit the file
[22:18:24] <Roguish> ok. that figures. how do i fix it? delete the file and update again?
[22:18:45] <Roguish> duh, good guess on my part.
[22:19:11] <Roguish> i don't commit any changes to cvs (at least not yet.)
[22:20:25] <Roguish> updating now. thanks.
[22:21:47] <Roguish> do you have any docs on how all that modelling (box, cylinder, ect.) is written? kinda cool. i'ld like to try and make a model.
[22:23:06] <jepler> you'll get some documentation by typing 'pydoc vismach' (after sourcing emc-environment for RIP)
[22:23:48] <Roguish> ok, what do you mean
[22:24:09] <Roguish> sourceing emc-environment for RIP )run in place
[22:24:40] <Roguish> sorry about the typing. i'm on a little mini keyboard.
[22:26:04] <fenn> Roguish: if you look at tracking-test.py, it has a pretty minimal set of stuff you need to make a new gui/visualization
[22:27:18] <fenn> in src/emc/usr_intf/axis/scripts/
[22:28:32] <fenn> it can get tricky with setting up the various coordinate systems
[22:30:09] <Roguish> ok. i believe that.