Back
[00:02:41] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/tests/threads.1/ (checkresult test.hal): check that the 'tmax' of a thread is nonzero
[00:03:09] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/src/rtapi/sim_common.h: fix zero thread/function time/tmax on amd64/sim
[00:05:03] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/comp.g: tweak optimizer to get correct behavior for doubles
[00:05:58] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/src/Makefile.inc.in: tweak optimizer to get correct behavior for doubles
[02:06:51] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/src/ (configure configure.in config.h.in): on some systems, rdtscll is available from asm/msr.h in userspace. check for it, we'll use it soon
[02:10:18] <SWPadnos> other than consistency (with HAL and previous versions of stepconf), can anyone think of a good reason not to have stepconf ask for velocities in IPM?
[02:10:22] <SWPadnos> oh, maybe accel is a good one
[03:08:02] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/src/hal/hal_lib.c: fix cast for 64-bit systems
[03:08:37] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/src/rtapi/sim_common.h: asm/msr.h defines timestamp read function sometimes; use it if we can
[03:08:47] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/src/rtapi/sim_rtapi.c: fix 64-bit warning
[03:11:57] <jepler> (strangely, ubuntu broke <asm/msr.h> between dapper and hardy)
[03:20:34] <jmkasunich> nice
[03:20:48] <jmkasunich> and people wonder why NIH programming happens
[03:37:35] <cradek> hm, I wonder if my changes to CL today are wrong for 64 bit
[03:40:22] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/docs/man/man3/rtapi_get_time.3rtapi: seems these functions are not in ulapi
[03:40:35] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/docs/man/man3/ (intro.3hal intro.3rtapi): overview of realtime considerations
[03:42:00] <cradek> hm, this looks like serious work, I wonder what he's doing
[03:42:07] <jepler> me? oh, nothing
[03:42:33] <cradek> "we'll use it soon"... <cue ominous music>
[03:42:52] <jepler> oh, that -- I was just fixing the "time/tmax always shows 0 on 64bit/sim" bug
[03:42:58] <cradek> ah
[03:43:01] <jepler> which was actually just a typo, it turns out
[03:43:12] <cradek> I saw the ____patch
[03:43:18] <jepler> exactly
[03:43:26] <cradek> I bet that was very easy to miss
[03:44:51] <jepler> is "classicladder works on 64 bits" something I can test easily?
[03:45:17] <cradek> you could run demo_sim_cl or however it's spelled
[03:45:35] <cradek> but I bet you could see only very basically that it works
[03:45:52] <jepler> sounded like you were worried about something specific
[03:46:07] <cradek> the stuff I fixed was modbus
[03:46:21] <cradek> but maybe it's all busted, I have no idea
[03:46:25] <jepler> oh
[03:46:36] <jepler> the demo_sim_cl ladder works
[03:46:41] <cradek> I think the modbus code I touched is definitely busted wrt byte orders
[03:46:57] <jepler> rewoffl!
[03:47:00] <cradek> ah, that's nice at least. the things light up and it comes out of estop?
[03:47:04] <jepler> yep
[03:47:09] <cradek> did you figure out what's wrong with rewoffl?
[03:47:24] <jepler> no, once I figured out to type "rewi" or "rewo" I forgot about it
[03:47:50] <jepler> I swear the dg unix mt that I know best took "mt rew" as a synonym for "mt rewind"; I dunno if it's because "mt rewoffl" didn't exist yet or what
[03:47:54] <jepler> surely rewoffl existed though
[03:48:10] <jepler> anyway, I still type it even though it hasn't worked on any unix mt I've ever use
[03:48:14] <jepler> d
[03:48:15] <jepler> er, any linux mt
[03:48:18] <cradek> I'm also used to rew being rewind
[03:49:08] <jepler> there are at least 5 "mt"s in ubuntu, I should try them all
[03:49:17] <jepler> /bin/mt-gnu /usr/bin/mt-dds /usr/sbin/mt-daapd /bin/mt-st /bin/mt-star
[03:49:18] <cradek> that's just amazing
[03:49:29] <jepler> I think I have mt-gnu now
[03:49:46] <jepler> and that system's offline anyway
[03:50:11] <cradek> you should just use the one that comes installed with the base system along with dump and restore - you can be sure it will work
[03:50:25] <jepler> anyway, from the ltrace I'm 95% sure it's trying to print the error message that 'mt rew' is ambiguous
[03:51:07] <cradek> * cradek calls troll on cradek
[03:52:29] <jepler> oh, thanks for that
[03:52:32] <SWPadnos> cradek, the modbus byte order looks correct. it's supposed to be high byte then low byte
[03:53:05] <jepler> I really wish somebody would split out the modbus interface into its own component
[03:53:12] <SWPadnos> heh
[03:53:35] <SWPadnos> if we can come up with a reasonable way to specify what's where on the bus(es), then I'm all for it
[03:53:56] <SWPadnos> I have the older LGPL2 version of a modbus library, which works
[03:54:31] <jepler> * jepler spins the wheel of answers
[03:54:36] <SWPadnos> I think the LGPL3 version would require that EMC2 be released as (L)GPL3, so I don't want to use it
[03:54:41] <jepler> SWPadnos: looks like the answer for "reasonable way to specify" turns out to be: XML
[03:55:02] <SWPadnos> well, yeah - I was thinking something like what pyvcp uses
[03:55:21] <SWPadnos> do we have an xml-like parsing library that can be used by multiple modules?
[03:55:29] <jepler> if you write it in python
[03:55:32] <SWPadnos> heh
[03:56:03] <SWPadnos> there's the halvcp version too
[03:56:14] <SWPadnos> or whatever the original vcp was called
[03:59:31] <jmkasunich> that wasn't XML
[03:59:39] <jmkasunich> it was some abomination that I made up as I went along
[03:59:42] <jepler> incidentally, classicladder's modbus interface is lgpl
[04:00:04] <SWPadnos> jmkasunich, it was close to XML though :)
[04:00:14] <jepler> hm I could swear I had a python modbus master implementation half-written somewhere here..
[04:00:20] <SWPadnos> you did, I remember
[04:00:28] <jmkasunich> close only counts in horseshoes, hand-grenades, and nuclear warfare
[04:00:37] <SWPadnos> well, I remember you talking about it - there's a python modbus library somewhere on the intarweb
[04:02:19] <jepler> no, this was a from-scratch implementation
[04:02:49] <jepler> hm I can't find it on any of the machines that seem like likely candidateds..
[04:02:56] <SWPadnos> hmmm. maybe it was based on pyserial (however that's spelled)?
[04:03:18] <SWPadnos> oh right - I think you might have stopped when you hit the CRC function
[04:03:40] <SWPadnos> like they had some sample code but the spec didn't say what kind of CRC it was
[04:04:04] <jepler> yeah it was the day we had that discussion that I was working on it
[04:04:12] <jepler> I recall that I eventually found what the crc was
[04:04:39] <SWPadnos> this one works:
https://launchpad.net/libmodbus
[04:04:55] <SWPadnos> the 1.2.x versions are LGPL2
[04:05:10] <SWPadnos> the 2.x are LGPL3
[04:05:13] <jepler> then get 1.2.x
[04:05:23] <jepler> or take the one in classicladder, it's lgpl as well
[04:05:50] <jepler> oh right, the insane timeout specification that's contradicted right in the footnote.
[04:05:51] <SWPadnos> what I have is based on 1.2.5, modified so the library (optionally) won't print any errors
[04:05:55] <SWPadnos> yep
[04:06:12] <SWPadnos> I don't know if this library is compliant on that front
[04:06:24] <jepler> that's OK, the spec says nobody conforms to that part of the spec
[04:06:30] <SWPadnos> but I do know that it communicates fine, and it notices when there's no communication
[04:06:39] <SWPadnos> the spec doesn't conform to that part of the spec
[04:06:46] <jepler> 'night guys
[04:06:51] <SWPadnos> see you
[04:06:59] <jepler> SWPadnos: anyway, now that you've been told the answer is "XML", you should finish the implementation by friday.
[04:07:08] <SWPadnos> ok
[04:07:16] <SWPadnos> where do we want the libmodbus code to go?
[04:07:23] <SWPadnos> that was another problem I had
[04:07:34] <SWPadnos> where to stick outside code that may be used by several modules
[04:08:38] <jepler> you mean because classicladder could use it too, or because you imagine some less-generic modbus driver is waiting to be written?
[04:08:56] <SWPadnos> there is a less-generic driver already, and I don't want to un-write it :)
[04:09:04] <SWPadnos> namely the GS2 VFD driver
[04:09:14] <jepler> you know, with 'alias' it's unimportant for the generic modbus master to have a complex scheme for naming pins
[04:09:29] <SWPadnos> naming pins is the least problem involved
[04:09:40] <jepler> oh
[04:09:48] <SWPadnos> multiple ports (can be solved by running multiple instances)
[04:09:53] <SWPadnos> multiple devices on a single power
[04:09:54] <SWPadnos> port
[04:10:08] <SWPadnos> multiple "endpoints" in a single device
[04:10:20] <SWPadnos> strange packing of bits/bytes/words/dwords
[04:10:42] <jepler> modbus doesn't specify anything besides bits and 16-bit values, so everybody makes different shit up?
[04:10:45] <jepler> sigh
[04:10:45] <SWPadnos> multiple address spaces in the spec (registers, coils, etc)
[04:10:49] <SWPadnos> yes
[04:11:03] <SWPadnos> there are 32-bit values, which are usually pairs of contiguous words
[04:11:10] <jepler> oooh hooray, I just flipped back over into not caring about this
[04:11:11] <jepler> yay
[04:11:13] <jepler> I feel so much better
[04:11:15] <SWPadnos> night
[04:11:17] <SWPadnos> :)
[04:11:40] <jmkasunich> I think I have pin aliases working
[04:11:51] <SWPadnos> yay!
[04:12:03] <jmkasunich> probably need some completion tweaks
[04:12:22] <SWPadnos> ok
[04:12:29] <jmkasunich> and params will need to be done (copy paste, so might as well get the kinks out of pins first)
[04:12:36] <jmkasunich> show pin needed _zero_ changes
[04:12:51] <SWPadnos> the G540 is arriving tomorrow, so I'll probably play with that most of the day
[04:12:53] <SWPadnos> nice
[04:13:44] <SWPadnos> if you show pin original_name, does it work?
[04:13:48] <jmkasunich> gotta test a few edge cases, then I'll commit
[04:13:56] <jmkasunich> no
[04:13:59] <SWPadnos> ok
[04:14:28] <SWPadnos> I think some things will need to, like link / net
[04:14:58] <SWPadnos> if they don't, the pin may as well be renamed instead of aliased
[04:15:33] <jmkasunich> for most purposes, an alias is a rename (but with an undo button)
[04:16:10] <SWPadnos> right - it's things like "subroutine" HAL files that would need the originals to be visible
[04:16:16] <jmkasunich> you can do "net <signal> <some-old-name>"
[04:19:22] <jmkasunich> also linksp <sig> <oldpin> (or <alias>)
[04:19:29] <jmkasunich> and unlinkp <oldname> or <alias>
[04:19:34] <jmkasunich> (just tested those cases)
[04:19:38] <SWPadnos> ok, as long as those work I'm happy
[04:19:54] <SWPadnos> show should only show one copy, which the plan we discussed would do
[04:19:58] <jmkasunich> they use find_pin_by_name, and it recognizes matches to either name or oldname
[04:20:02] <SWPadnos> cool
[04:20:39] <SWPadnos> heh - net parport.0.pin-1-in axis.*.jog-enable :)
[04:20:55] <jmkasunich> only thing I haven't tested is unalias
[04:21:02] <jmkasunich> snce the parser doesn't recognise that
[04:21:13] <SWPadnos> right. I'll work on that
[04:22:24] <jmkasunich> I think I like what I have - gonna review the diff, then commit
[04:23:54] <SWPadnos> ok. I'll plug in the laptop :)
[04:25:07] <cradek> SWPadnos: what hardware do I need to use your gs2 driver?
[04:25:13] <cradek> other than, obviously, a gs2
[04:25:15] <SWPadnos> a GS2 and a serial port
[04:25:24] <cradek> serial aka rs232?
[04:25:27] <jmkasunich> cradek: you have a GS2 on the lathe, right?
[04:25:37] <SWPadnos> yes, but you'll need a special cable I think
[04:25:55] <CIA-42> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/utils/ (halcmd.c halcmd_commands.c): halcmd side of 'alias' command - for pins only (still need 'unalias')
[04:26:15] <cradek> yes
[04:26:20] <SWPadnos> the pinout is available, it's a DB9 to RJ12 cable I think
[04:26:41] <jmkasunich> that should get you 'alias pin', 'show alias', 'show pin', and 'status mem'
[04:26:49] <cradek> I have fwd/reverse/analog speed
[04:26:57] <SWPadnos> hmmm. routine fsck. it'll be a few minutes
[04:26:57] <cradek> jmkasunich: yay!
[04:27:07] <cradek> cabling is not a problem
[04:27:14] <SWPadnos> oh - this will read back the actual speed IIRC
[04:27:16] <cradek> maybe I should try it.
[04:27:21] <jmkasunich> time to walk mr. dog.... I'll do params tomorrow
[04:27:27] <SWPadnos> ok
[04:27:27] <jmkasunich> goodnight
[04:27:42] <SWPadnos> cradek, any ideas on where to put the (third party) libmodbus code?
[04:27:58] <SWPadnos> just stick it in the hal/user_comps dir maybe, since that's all that can really use it
[04:28:02] <cradek> I'd like to get "at speed" and "fault" from it which I currently don't have
[04:28:28] <SWPadnos> I'll have to see if it has an "at speed" output
[04:28:41] <SWPadnos> I'm pretty sure it reads back actual speed
[04:28:53] <SWPadnos> (in supplied Hz or something)
[04:29:00] <cradek> lib/modbus?
[04:29:10] <SWPadnos> oh, that may make sense :)
[04:29:40] <SWPadnos> I'm not sure I know how to do the dependencies for that though
[04:30:06] <SWPadnos> (include lib/modbus.h, and make sure that lib/modbus.c gets compiled and linked with whatever needs it)
[04:30:50] <SWPadnos> there should be examples though, I guess
[04:31:27] <cradek> if not, we'll get it to build tomorrow
[04:31:33] <cradek> but for now, I'm going to bed
[04:31:36] <SWPadnos> ok
[04:31:42] <SWPadnos> still waiting for the laptop to boot ...
[04:31:50] <cradek> I hate that
[04:31:57] <SWPadnos> yep
[04:32:01] <cradek> always when you're waiting for it.
[04:32:10] <SWPadnos> fsck is not very fast on a 200GB notebook drive
[05:04:10] <seb_kuzminsky> buildmaster: status all
[05:04:11] <buildmaster> dapper-x86-2.2-realtime-deb: idle, last build 102294 secs ago: build successful
[05:04:11] <buildmaster> dapper-x86-2.2-realtime-rip: idle, last build 103290 secs ago: build successful
[05:04:11] <buildmaster> dapper-x86-2.2-sim: idle, last build 103143 secs ago: build successful
[05:04:11] <buildmaster> dapper-x86-trunk-realtime-deb: idle, last build 3838 secs ago: build successful
[05:04:11] <buildmaster> dapper-x86-trunk-realtime-rip: idle, last build 1618 secs ago: build successful
[05:04:12] <buildmaster> dapper-x86-trunk-sim: idle, last build 1980 secs ago: build successful
[05:04:14] <buildmaster> hardy-x86-2.2-realtime-deb: idle, last build 102641 secs ago: build successful
[05:04:16] <buildmaster> hardy-x86-2.2-realtime-rip: idle, last build 102955 secs ago: build successful
[05:04:18] <buildmaster> hardy-x86-2.2-sim: idle, last build 102301 secs ago: build successful
[05:04:20] <buildmaster> hardy-x86-trunk-realtime-deb: idle, last build 1503 secs ago: build successful
[05:04:22] <buildmaster> hardy-x86-trunk-realtime-rip: idle, last build 3834 secs ago: build successful
[05:04:24] <buildmaster> hardy-x86-trunk-sim: idle, last build 2154 secs ago: build successful
[05:04:40] <SWPadnos> buildmaster, shut up already
[05:04:42] <SWPadnos> :)
[05:05:11] <seb_kuzminsky> buildmaster: status hardy-x86-trunk-sim
[05:05:11] <buildmaster> hardy-x86-trunk-sim: idle, last build 2214 secs ago: build successful
[05:05:27] <SWPadnos> buildmaster: help
[05:05:27] <buildmaster> Get help on what? (try 'help <foo>', or 'commands' for a command list)
[05:05:31] <seb_kuzminsky> if it's too chatty i can turn it down or turn it off
[05:05:33] <SWPadnos> buildmaster: help commands
[05:05:34] <buildmaster> Usage: commands - List available commands
[05:05:36] <SWPadnos> ok
[05:05:42] <seb_kuzminsky> buildmaster: commands
[05:05:42] <buildmaster> buildbot commands: commands, dance, destroy, excited, force, hello, help, last, list, source, status, stop, version, watch
[05:05:50] <SWPadnos> right - figured that out finally :)
[05:05:55] <SWPadnos> buildmaster, dance
[05:06:04] <SWPadnos> hmm, colons only I guess
[05:06:06] <seb_kuzminsky> not all of these work, i need to upgrade it to 0.7.9, but that didnt make it into hardy
[05:06:14] <seb_kuzminsky> SWPadnos: or \/msg it
[05:06:19] <SWPadnos> right
[05:29:08] <seb_kuzminsky> silly
[05:29:13] <seb_kuzminsky> buildmaster: What happen ?
[05:29:14] <buildmaster> Somebody set up us the bomb.
[05:59:06] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[06:00:06] <CIA-42> EMC: 03swpadnos 07TRUNK * 10emc2/src/hal/utils/ (halcmd_commands.h halcmd.c halcmd_completion.c): Add halcmd support for alias and unalias pin and param
[06:01:01] <CIA-42> EMC: 03compile-farm 07Ubuntu 6.06 LTS (dapper) non-realtime (2.6.15-52-386) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot8_log.txt
[06:02:21] <CIA-42> EMC: 03swpadnos 07TRUNK * 10emc2/src/hal/utils/halcmd_commands.c: Oops - forgot one file for completion. my bad
[06:02:36] <SWPadnos> jmkasunich, alias/unalias should be complete now, except for the commented code to handle params in do_alias_cmd and do_unalias_cmd
[06:03:07] <SWPadnos> jmkasunich, completion should work for both with no changes, since the param structs already have the oldname field
[06:06:54] <CIA-42> EMC: 03compile-farm 07Ubuntu 6.06 LTS (dapper) non-realtime (2.6.15-52-386) * 10emc2head/: build PASSED
[06:16:02] <seb_kuzminsky> is the compile-farm output on irc new? i dont think i noticed it before
[06:16:13] <SWPadnos> no, it's been there for years
[06:16:28] <seb_kuzminsky> was it enabled?
[06:16:41] <SWPadnos> it only says something when a build fails or the first time it passes after a failure
[06:16:49] <seb_kuzminsky> that explains it
[06:17:11] <seb_kuzminsky> okie doke, goodnight
[06:18:37] <LawrenceG> cradek, you still awake?
[06:21:11] <LawrenceG> cradek, I am looking for a python wrapper for the freetype version 2 libs... there is PyFT for version 1... I would like ttt functionality as a python module to insert into another python project... any ideas ?
[06:46:36] <CIA-42> EMC: 03swpadnos 07TRUNK * 10emc2/src/hal/user_comps/ (modbus.c modbus.h gs2_vfd.c Submakefile):
[06:46:36] <CIA-42> EMC: First check-in of GS2 VFD module
[06:46:36] <CIA-42> EMC: This communicates with an Automation Direct GS2 VFD, and provdes start, stop, speed,
[06:46:36] <CIA-42> EMC: and direction control. Some status, including actual speed, are read back as well.
[06:46:36] <CIA-42> EMC: Right now, the serial port is hard-coded as ttyS0, 38400/O/8/1 (default for the GS2)
[06:46:39] <CIA-42> EMC: modbus.c and modbus.h can be used in any userspace components.
[07:07:26] <CIA-42> EMC: 03swpadnos 07TRUNK * 10emc2/configs/sim/gs2.hal:
[07:07:26] <CIA-42> EMC: This HAL file can be added to most any config, and will make necessary HAL
[07:07:26] <CIA-42> EMC: signals and connections to let you use the basic features of a GS2 VFD
[12:45:16] <rayh> Yea. Thanks SWP.
[12:56:18] <alex_joni> hi rayh
[12:57:28] <alex_joni> bbl.. nap
[13:03:59] <rayh> Hi alex. Rest well.
[13:21:00] <jepler> SWPadnos: your checkin causes an odd failure on an old fedora core box, which is where I build the documentation
[13:21:03] <jepler> make: Entering directory `/home/jepler/emc2-docbuild/src'
[13:21:06] <jepler> Depending hal/user_comps/modbus.c
[13:21:08] <jepler> In file included from /usr/include/glib-2.0/glib/galloca.h:30,
[13:21:11] <jepler> from /usr/include/glib-2.0/glib.h:30,
[13:21:13] <jepler> from hal/user_comps/modbus.c:34:
[13:21:16] <jepler> /usr/include/glib-2.0/glib/gtypes.h:385:2: error: #error unknown ENDIAN type
[13:23:09] <jepler> hi skunkworks
[13:23:25] <skunkworks> good morning jepler
[13:24:35] <skunkworks> it's friday!!
[13:47:22] <jepler> argh, I should go to the office
[13:58:45] <jepler> SWPadnos: oh, you need to do autoconf stuff for gtk; the setup on this system differs from yours, and -I/usr/lib/glib-2.0/include doesn't work
[14:01:00] <seb_kuzminsky> SWPadnos: oops, and the debs dont build any more:
http://emc2-buildbot.colorado.edu/buildbot-admin/builders/hardy-x86-trunk-realtime-deb/builds/116/steps/compile/logs/stdio
[14:03:49] <jepler> seb_kuzminsky: can't read that page without logging in
[14:06:18] <jepler> anyway, maybe corrected now...
[14:14:54] <cradek_> cradek_ is now known as cradek
[14:54:04] <SWPadnos> huh. odd problems from that I guess
[15:03:26] <seb_kuzminsky> jepler: oops
[15:03:27] <seb_kuzminsky> http://emc2-buildbot.colorado.edu/buildbot/builders/hardy-x86-trunk-realtime-deb/builds/116/steps/compile/logs/stdio
[15:03:44] <seb_kuzminsky> i keep using the admin part of the site, not the public one
[15:03:48] <seb_kuzminsky> the above url should work for all
[15:04:17] <cradek> works, thanks
[15:08:00] <seb_kuzminsky> * seb_kuzminsky kicks CIA-38
[15:34:53] <jepler> seb_kuzminsky: thanks for fixing
[15:38:14] <seb_kuzminsky> sure :-)
[15:44:16] <seb_kuzminsky> jepler: thanks for dealing with paul
[15:44:24] <SWPadnos> heh
[15:44:36] <SWPadnos> thanks everyone for fixing my commit droppings :)
[15:44:57] <SWPadnos> has anyone else tried alias?
[15:45:04] <jepler> I got the impression it wasn't done yet
[15:45:07] <jepler> is that incorrect?
[15:45:19] <SWPadnos> it is, except that param aliases aren't implemented in hal_lib yet
[15:45:27] <jepler> oh, but pin aliases are?
[15:45:30] <SWPadnos> yep
[15:45:46] <seb_kuzminsky> SWPadnos: i havent played with it yet but i will
[15:45:58] <SWPadnos> so you can do neat things like alias pid.0.Pgain Pgain-X
[15:46:41] <seb_kuzminsky> SWPadnos: each pin always has a "real" name, and it has zero or one aliases?
[15:46:46] <SWPadnos> I think I got the completion right - most pin and parame related things will match both the alias and the old name
[15:46:59] <SWPadnos> each pin has one name, and possible an old name as well
[15:47:22] <SWPadnos> so yes, that's right except that the alias replaces the original name in the pin struct (and it gets re-ordered)
[15:47:33] <seb_kuzminsky> i see
[15:47:46] <SWPadnos> the alias more or less replaces the old name - it's used preferentially in list/show/save output
[15:47:54] <SWPadnos> oh. I don't know if save is done yet
[15:48:16] <seb_kuzminsky> what's the intended use cases?
[15:48:50] <SWPadnos> renaming your long hm2 pin names ;)
[15:52:26] <jepler> SWPadnos: it doesn't work
[15:52:26] <jepler> halcmd: help alias
[15:52:26] <jepler> No help for unknown command 'alias'
[15:54:21] <SWPadnos> :P
[15:55:28] <SWPadnos> the manual is also brokeb
[15:55:30] <SWPadnos> n
[15:57:58] <jepler> I'm not sure why 'pin' is necessary; it could work like 'setp' under the assumption that pin and param names should be distinct (even if that's not enforced)
[15:58:17] <seb_kuzminsky> thanks SWPadnos ;-)
[15:58:19] <seb_kuzminsky> bbl
[15:59:11] <SWPadnos> the type may not be necessary, but it would help if there happen to be a pin and parameter with the same name
[15:59:37] <SWPadnos> for setp the clear choice is to set a parameter first, then a pin (since setp used to operate only on parameters)
[15:59:48] <SWPadnos> for alias, the choice isn't clear
[16:00:37] <jepler> does unalias take the original name or the alias name?
[16:00:57] <SWPadnos> either I think, but completion only lists the aliases (I think)
[16:01:06] <SWPadnos> it was last night so I don't remember any more :)
[16:01:49] <jepler> It must take the original name
[16:01:54] <SWPadnos> hmm
[16:02:26] <SWPadnos> no, it accepts either
[16:02:41] <SWPadnos> but completion only lists aliases
[16:03:39] <SWPadnos> oooh, a test. thanks :)
[16:17:48] <BigJohnT> SWPadnos: have you tried out the gs2 driver?
[16:18:21] <SWPadnos> I tested it with a GS2 at the CNC workshop
[16:18:26] <SWPadnos> that's how it was developed
[16:18:52] <BigJohnT> cool, do I need to add anything to the manual about using it?
[16:19:14] <SWPadnos> now I see some other reasons I didn't want to commit it: it's ugly looking and it has hard-coded serial port info (I see I was starting to add command line processing to it
[16:19:47] <SWPadnos> there should be something, but I should get the getopt stuff working first, since the command line options will be a big part of the manual
[16:20:37] <BigJohnT> ok, just let me know...
[16:21:04] <SWPadnos> will do
[16:21:30] <BigJohnT> Those are some real cost effective drives
[16:25:33] <SWPadnos> yep, they sure are for the smaller ones. I think the big ones get into serious money though
[16:26:35] <BigJohnT> be real handy to have on a spindle I think
[16:27:01] <BigJohnT> my mind went to wandering when I saw your commit :)
[16:27:21] <SWPadnos> heh
[16:27:50] <SWPadnos> well, it worked at the workshop. I think it should still work now, but I don't have any hardware to test it with any more (it was Ray's)
[16:28:31] <SWPadnos> which means I can't test getopt stuff. hmmm
[16:28:52] <alex_joni> well.. getopt should be fine with printf's to test
[16:29:31] <SWPadnos> should, but I can't tell if the comms work correctly
[16:30:38] <SWPadnos> http://pastebin.ca/1267691
[16:30:53] <SWPadnos> help text - OK by you guys?
[16:31:10] <SWPadnos> oh, I should add the type options to unalias
[16:32:55] <alex_joni> looks ok to me
[16:33:22] <alex_joni> I'd say "Add or remove pin or parameter name aliases" instead of "pin and parameter"
[16:33:40] <SWPadnos> ok
[16:39:12] <SWPadnos> * SWPadnos kicks CIA-42
[16:39:13] <CIA-42> ow
[16:39:31] <alex_joni> * alex_joni rubs CIA-42's tummy
[16:39:31] <CIA-42> *purr*
[16:40:13] <alex_joni> seb_kuzminsky: seems the launchpad import worked afterall
[16:40:23] <alex_joni> they didn't have -d:ext: implemented at the time
[16:40:31] <alex_joni> so it took a week
[18:25:57] <LawrenceG> logger_dev, bookmark
[18:25:57] <LawrenceG> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-11-26.txt
[19:18:41] <alex_joni> CIA-42: hi
[19:18:57] <alex_joni> CIA-4!
[19:19:00] <alex_joni> CIA-42!
[19:19:06] <alex_joni> * alex_joni shuts up
[19:24:29] <SWPadnos> holy cow. the G540 is tiny
[19:25:32] <alex_joni> heh.. we want pics :)
[19:25:41] <SWPadnos> it would fit across the opening for a full-height 5.25" drive, with about an inch to spare above it, and it's ~1" thick
[19:26:35] <alex_joni> got it free?
[19:26:43] <SWPadnos> it even comes with DB9 connectors for all 4 motor connections
[19:26:45] <SWPadnos> yep
[19:26:50] <alex_joni> cool deal
[19:26:51] <SWPadnos> gonna make up a stepconf config for it
[19:26:56] <SWPadnos> yeah, I'll say :)
[19:27:15] <alex_joni> too bad it's so far from here :)
[19:27:19] <SWPadnos> I bought motors from Keling for about $50 each
[19:27:21] <SWPadnos> heh
[19:27:43] <SWPadnos> I have big hands, but it's still impressive that it fits easily on my hand
[19:27:58] <alex_joni> brb
[19:27:59] <SWPadnos> that's breakout board, 4 axis drivers, and heatsink/case
[19:33:21] <alex_joni> sounds good
[19:39:48] <seb_kuzminsky> alex_joni: cool!
[19:40:00] <seb_kuzminsky> * seb_kuzminsky does a little dance
[19:40:27] <SWPadnos> * SWPadnos hides
[19:40:36] <alex_joni> * alex_joni looks away
[19:40:47] <alex_joni> <-still feeling some nausea from the cold
[19:41:01] <SWPadnos> and the dancing
[19:41:24] <alex_joni> didn't look.. but it would probably bring back memories
[19:41:29] <alex_joni> (from todays breakfast)
[19:41:40] <alex_joni> and meds too :)
[19:42:58] <seb_kuzminsky> branching it now... :-)
[19:43:19] <seb_kuzminsky> then i'll "diff -x CVS" it against my cvs sandbox
[19:44:00] <seb_kuzminsky> bbl
[19:46:12] <skunkworks> SWPadnos: even the normal gecko drives are way smaller than you think they should be in person.
[19:46:21] <SWPadnos> yeah, I have a few of them
[19:46:27] <SWPadnos> this is even smaller ;)
[19:47:21] <alex_joni> it's odd that it doesn't show on their products page
[19:47:29] <SWPadnos> hmmm. should I take it apart first or make a working config first
[19:47:37] <alex_joni> but if you go to G251 it shows up under related
[19:47:47] <alex_joni> config first ;)
[19:47:54] <SWPadnos> nothing shows up on their page because of stupid flash
[19:48:13] <alex_joni> http://www.geckodrive.com/product.aspx?i=14469
[19:48:20] <alex_joni> it oddly sais G320 DC ...
[19:49:25] <SWPadnos> funny that it shows as related to the G251 instead of the G250, which it actually uses
[19:54:47] <skunkworks> SWPadnos: do you have steppers?
[19:55:05] <SWPadnos> heh, I had to buy a few so I could test this stuff :)
[20:04:56] <skunkworks> http://www.youtube.com/watch?v=xiO9lfdmghI&eurl=http://www.cnczone.com/forums/showthread.php?t=61578&page=22
[20:19:19] <jepler> huh, I never realized the 120Hz flicker of lights was so pronounced
[20:19:26] <jepler> I wonder if the lighting was incandescent or other
[20:19:59] <jepler> skunkworks: I'm not sure what's supposed to be exciting about a motor that can accelerate to 1800RPM and then stop, though
[20:20:09] <SWPadnos> in both directions!
[20:20:22] <SWPadnos> bbiab
[20:22:44] <skunkworks> I just thought the video was neat - time lapse.
[20:23:28] <skunkworks> This guy has been fighting with this step/dir servo drive for months - problems with it counting the encoder consistantly
[20:26:28] <jepler> the guy who posted the video?
[20:27:52] <alex_joni> skunkworks: this is way more exciting:
http://www.youtube.com/watch?v=ElVM0ncEqHs
[20:32:20] <seb_kuzminsky> buildmaster: /msg buildmaster status all
[20:32:23] <seb_kuzminsky> oops
[20:32:50] <alex_joni> buildmaster: hi :)
[20:33:01] <alex_joni> hmm.. it's too silent now :D
[20:33:08] <alex_joni> buildmaster: messages
[20:33:16] <seb_kuzminsky> alex_joni: have you branched trunk from lp?
[20:33:24] <alex_joni> yes
[20:33:38] <alex_joni> why?
[20:33:39] <seb_kuzminsky> buildmaster: hello
[20:33:39] <buildmaster> yes?
[20:33:51] <seb_kuzminsky> it's being incredibly slow for me
[20:34:12] <seb_kuzminsky> i'm trying to branch it into a shared repo with a bunch of other (local) branches, but that should be fine
[20:34:34] <alex_joni> buildmaster: help
[20:34:34] <buildmaster> Get help on what? (try 'help <foo>', or 'commands' for a command list)
[20:34:39] <cradek> units fail: 180 rpm/s^2
[20:34:39] <alex_joni> buildmaster: commands
[20:34:40] <buildmaster> buildbot commands: commands, dance, destroy, excited, force, hello, help, last, list, source, status, stop, version, watch
[20:34:52] <alex_joni> buildmaster: dance ?
[20:34:53] <buildmaster> 0-<
[20:34:55] <buildmaster> 0-/
[20:34:56] <buildmaster> 0-\
[20:35:08] <jepler> well that's precious
[20:35:19] <alex_joni> wonder if seb does that better
[20:35:27] <alex_joni> cradek: yeah, noticed that too
[20:35:40] <alex_joni> maybe he meant jerk in an odd unit :D
[20:35:43] <seb_kuzminsky> heh
[20:36:00] <alex_joni> buildmaster: last
[20:36:07] <seb_kuzminsky> oops
[20:36:07] <alex_joni> oops :/
[20:37:20] <seb_kuzminsky> buildmaster: hello again
[20:37:21] <buildmaster> yes?
[20:37:25] <seb_kuzminsky> buildmaster: What happen ??
[20:37:44] <alex_joni> seb_kuzminsky: I get Service Temporarily Unavailable from the buildbot server
[20:38:01] <seb_kuzminsky> i just restarted it, try again
[20:38:10] <alex_joni> works now
[20:38:35] <seb_kuzminsky> hardy has buildbot 0.7.6, which is over a year old...
[20:38:51] <seb_kuzminsky> the irc and mailing list notifiers were notoriously buggy
[20:39:09] <seb_kuzminsky> i've requested a backport of 0.7.9, which is much better, we'll see what they say
[20:39:34] <seb_kuzminsky> https://bugs.launchpad.net/hardy-backports/+bug/302281
[20:39:58] <seb_kuzminsky> hm, branching the lp pull of our cvs into its own new repo is much faster
[20:40:08] <cradek> alex_joni: if it was 180 rpm/sec, it would take 10 seconds to get up to speed. assuming I'm seeing about 420/60 speedup since it says "Filmed at 420fps" (7x) that would mean 70 seconds. So there's much more fail here than just units.
[20:40:56] <skunkworks> hmm - developer email list sounds like a new nigerian scam ;)
[20:41:46] <alex_joni> skunkworks: what?
[20:41:47] <cradek> that is off-topic for BOTH lists he sent it to
[20:42:17] <alex_joni> ah, got it now..
[20:43:01] <alex_joni> I wonder how the transmitter will send ground
[20:46:03] <jepler> hah, hmm
[20:49:38] <seb_kuzminsky> bzr branch from lp was being slow because i was branching into a shared repo with a different repo backend format, and it was having to convert on the fly
[20:50:01] <seb_kuzminsky> branching into a repo of the same format as lp uses, or into a new repo where it clones the remote format by default, makes it nice & snappy
[20:51:19] <seb_kuzminsky> https://code.launchpad.net/~vcs-imports/emc/trunk
[21:10:27] <alex_joni> seb_kuzminsky: any issues?
[21:14:26] <alex_joni> * alex_joni runs to bed
[21:14:28] <alex_joni> good night all
[21:24:31] <skunkworks> jepler:
http://www.cnczone.com/forums/showpost.php?p=531667&postcount=258
[21:26:48] <jepler> skunkworks: huh, I know cradek uses usdigital encoders without trouble
[21:27:05] <cradek> s/cradek/a zillion people/
[21:27:21] <cradek> probably an electrical incompatibility of some kind
[21:28:23] <jepler> cradek: do you know if the usdigital encoder on your lathe specifies external pull-up resistors?
[21:28:25] <cradek> I had trouble with mine when I put it on the lathe spindle - a bit of lost motion every revolution. but then I took it back apart and tightened the set screw I forgot to tighten
[21:28:57] <cradek> jepler: no, I don't know, but the mesa is jumpered for TTL input so I think it has pull-mumbles.
[21:29:43] <cradek> seb_kuzminsky: what am I supposed to be able to do with
https://code.launchpad.net/emc ?
[21:30:05] <cradek> I did get a read-only copy checked out
[21:33:52] <skunkworks> jepler: I have used them also without issues.
[21:39:25] <cradek> cool, the bzr import merges into changesets, like cvsps
[21:39:47] <cradek> is that bzr or launchpad that does it?
[21:39:58] <jepler> I think that bzr has a cvs import
[21:40:07] <jepler> git has one that uses cvsps to get changesets
[21:40:46] <cradek> I'm glad enough people are still using cvs that this stuff works
[21:41:00] <jepler> heh -- the time is still right to switch away from cvs
[22:41:22] <seb_kuzminsky> cradek: after you run the "bzr branch" command listed at the top of that page, you have two things on your hard disk
[22:41:32] <seb_kuzminsky> 1. a working directory similar to a "cvs checkout"
[22:41:49] <seb_kuzminsky> 2. a repository containing all the history, similar to a cvs repository
[22:42:22] <seb_kuzminsky> you can now do all the standard cvs type things, like log and diff and commit, all locally
[22:42:59] <seb_kuzminsky> you can "push" your branch back to lp, so others can see it, or you can give them a URI to your branch on your computer so they can access it without going through lp
[22:43:19] <seb_kuzminsky> you can branch locally, to make little bugfix branches or experimental feature branches or whatever
[22:43:50] <seb_kuzminsky> you can merge from other people's branches
[22:43:58] <seb_kuzminsky> (or your own)
[22:44:11] <seb_kuzminsky> hmmm, does that answer your question?
[22:44:25] <seb_kuzminsky> bbl
[23:39:38] <cradek> there was a cvs branch I'm interested in. is that in my repository? 'bzr heads' doesn't show anything like that
[23:40:29] <cradek> (I'm interested in the question of whether we can incrementally move developers to using more launchpad and less cvs...)
[23:40:32] <cradek> bbl