#emc-devel | Logs for 2007-01-04

[00:17:19] <jepler> jmkasunich: life was calling me too
[00:17:53] <jepler> jmkasunich: perhaps I'll be here when you get back
[03:10:14] <jmkasunich> back
[03:12:58] <SWPadnos> hiya jmk
[03:13:21] <jmkasunich> hiya
[03:16:45] <cradek> can I stay in here so as to avoid any breast-udder correlations that might be lurking on that other channel?
[03:16:53] <jmk-vm03> sure
[03:16:56] <cradek> oh good
[03:17:00] <SWPadnos> heh
[03:17:50] <cradek> jmk-vm03: did you figure out your shlib problem?
[03:18:01] <jmk-vm03> no, I just got back
[03:18:25] <jmk-vm03> and the vm's are clamoring about an update - thats annoying, so I'm dealing with it
[03:20:39] <jmkasunich> damn thats slow
[03:21:02] <jmkasunich> click on the "I wanna update" icon and it takes literally 30-60 seconds for the first sign of any activity
[03:21:30] <jmkasunich> no compiles are going on, CPU load is low, no swapping
[03:21:50] <cradek> it's probably doing apt-get update
[03:22:22] <jmkasunich> no, it does that after asking for the password
[03:22:25] <jmkasunich> it was just very slow
[03:22:27] <cradek> oh right
[03:22:47] <jmkasunich> now its fine (once the password dialog came up and I answered it)
[03:22:56] <jmkasunich> maybe it wasn't seeing my mouse click
[03:23:07] <jmkasunich> who knows... VMs are mysterious sometimes
[03:23:56] <jmk-vm03> ok, that rot is finished
[03:24:07] <jmk-vm03> how does one check on shared libs?
[03:24:34] <cradek> ldconfig
[03:24:48] <cradek> where did it put it?
[03:26:06] <jmk-vm03> looking now
[03:26:14] <jmk-vm03> find is also slow on a VM
[03:26:34] <jmk-vm03> /usr/local/lib
[03:30:02] <jmkasunich> "sudo ldconfig /usr/local/lib/" seems to have fixed it
[03:30:10] <jmkasunich> but I wonder how it got broke
[03:30:17] <jmkasunich> what exactly does ldconfig do?
[03:31:40] <jmkasunich> sets up symlinks it seems (according to the manpage)
[03:31:49] <jmkasunich> I wonder why they went away
[03:31:55] <jmkasunich> I know it was working a while ago
[03:36:55] <cradek> ld.so (the dynamic loader) also caches those paths
[03:36:57] <cradek> or something
[04:07:24] <jmkasunich> well, I think its all fixed
[04:07:35] <jmkasunich> just gotta have somebody break a compile to be sure
[04:07:48] <SWPadnos> hey - I can probably do that :)
[04:15:03] <SWPadnos> so - I was thinking of maybe ordering some of the motor connectors that fit the 7i30, plus the 4-pin connectors that several of the boards use for power (the ones that look like floppy power connectors)
[04:16:06] <jmkasunich> "look like", or "are" floppy power connectors?
[04:16:46] <SWPadnos> they aren't the same, though the pin spacing is the same (and the locking tab)
[04:16:49] <jmkasunich> I saw you mention the motor connectors yesterday? and tried to tell you I wanted some, dunno if you saw that
[04:16:57] <jmkasunich> bummer
[04:17:13] <jmkasunich> I have the cables from a couple of PC power supplies, I thought I was all set
[04:17:20] <SWPadnos> I saw, but wasn't sure of the right part numbers (and the ones I think were appropriate were out of stocK)
[04:17:46] <SWPadnos> you can use them, but you have to remove the +12V wire and shave off the key on the top
[04:18:14] <jmkasunich> thats dissipointing
[04:18:39] <SWPadnos> I thought about that - a PC power supply give s you +- 12V for op-amp circuits, lots of +5V, and lots of +12 for switches / relays etc.
[04:18:42] <jmkasunich> I thought Mesa had specifically designed them to use PC connectors, including making the 12V pin a no-connect
[04:18:53] <SWPadnos> nope = +5 G G +5
[04:19:10] <jmkasunich> lame
[04:19:25] <jmkasunich> the PC's -12 would be inconvenient to access, but +12 would be nice to have
[04:19:44] <jmkasunich> if the current is low enough, converting +12 to -12 on the expansion boards can be pretty cheap too
[04:19:51] <SWPadnos> just get an ATX -> AT adapter and cut off one connector
[04:19:57] <SWPadnos> that gives all the voltages
[04:20:15] <SWPadnos> or ATX24 -> ATX20 (or the other way)
[04:20:20] <jmkasunich> well, the main power supply connector is plugged into the mobo
[04:20:27] <jmkasunich> I'd want to use a drive connector
[04:20:30] <SWPadnos> no - a separate supply
[04:20:40] <SWPadnos> they're $20
[04:20:48] <SWPadnos> (or extra somewhere ... )
[04:21:12] <jmkasunich> why use a separate one?
[04:21:26] <jmkasunich> its not like the grounds are isolated from each other or anything
[04:21:34] <SWPadnos> I like the idea that a wiring problem won't crash the computer
[04:21:55] <SWPadnos> it's one reason I don't like the idea of pulling power from USB connectors
[04:22:08] <SWPadnos> (though those are "protected" by the USB chip)
[04:23:56] <jmkasunich> what I had in mind was power for the interface board, not power that would leave the interface board
[04:24:33] <SWPadnos> right. I was thinking more of "power for eveything else in the cabinet"
[04:24:50] <SWPadnos> 12V relays, analog amp boards, contactors ...
[04:25:05] <SWPadnos> limit / other switches
[04:25:29] <jmkasunich> for contactor coils and limit switches I like 24V
[04:25:37] <jmkasunich> and I also like it isolated if possible
[04:27:28] <SWPadnos> that's a good point
[04:32:34] <jmkasunich> my tentative plan is to use the PC supply for non-isolated power
[04:33:00] <jmkasunich> that eliminates any issues of sequencing - which supply do I turn on first, off last, etc
[04:33:09] <SWPadnos> sure
[04:33:48] <SWPadnos> the thing to do is probably to get several HD -> 2x floppy Y cables, snip the 12V cable at the HD end, and shave off the key on the floppy ends
[04:34:01] <SWPadnos> that leaves the PS pristine (and lets you replace it if needed)
[04:34:43] <jmkasunich> yeah
[04:34:53] <SWPadnos> if you're sneaky, you can also attach the 12V wire to the 5V line at the HD end
[04:36:50] <jmkasunich> I can't imagine any of the interface boards actually needing two pins worth of 5V current
[04:37:13] <SWPadnos> nope :)
[04:37:32] <SWPadnos> I haven't checked to see that both pins are connected - one sec
[04:38:32] <SWPadnos> ok. they are (as I hoped)
[04:39:32] <SWPadnos> and also connected to the +5V from the ribbon cable (makes sense, since the external supply is optional)
[04:40:24] <jmkasunich> how is the 7i33 (+/-10V outputs) powered?
[04:42:37] <SWPadnos> there's a big 6-pin component by Vitek - there may be a booster on board
[04:43:07] <jmkasunich> any xfmrs or inductors?
[04:43:16] <SWPadnos> well, there has to be, since there's only 5V from the PC or external power conector
[04:43:46] <SWPadnos> yes, there's a SMT inductor next to the Vitek thing (Which may itself be a power inductor)
[04:47:15] <SWPadnos> ok - it's a triple coil power inductor, probably 2:1:2, fed from a 5V square wave to the center coil
[04:47:56] <jmkasunich> +/-12V supply
[04:47:58] <jmkasunich> what feeds it?
[04:48:06] <SWPadnos> just logic and discretes
[04:48:31] <SWPadnos> that part number isn't in the datasheet, so it may be a custom 1:3:3 or something
[04:48:51] <SWPadnos> http://www.viteccorp.com/data/g303.pdf
[04:49:01] <SWPadnos> the part number I have is 16Z5777 though
[05:22:40] <jmkasunich> time for sleep
[13:47:21] <lerneaen_hydra> lerneaen_hydra is now known as hydra_away
[14:56:46] <alex_joni> hmmm.. I think there are still 2 languages left from which to control emc2
[14:57:05] <jepler> prolog and fortran?
[14:57:13] <alex_joni> and ada
[14:57:33] <jepler> haskell? scheme? forth? brainfuck?
[14:57:46] <alex_joni> you just made that up
[14:58:29] <alex_joni> hmm.. but some lisp bindings
[15:00:37] <jepler> no, I didn't make those language names up. http://www.muppetlabs.com/~breadbox/bf/
[15:01:43] <alex_joni> jepler: ok, just read about it :P
[15:02:41] <alex_joni> ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.
[15:04:09] <alex_joni> http://www.rpi.edu/~hughes/boof/ <- boolfuck
[15:09:56] <alex_joni> jmkasunich: around?
[15:10:46] <alex_joni> jepler: you looked a bit at homing, is it possible to set it up so that 2 axes don't get homed at once ?
[15:11:42] <alex_joni> * alex_joni wonders if the driver can request that
[15:13:33] <jepler> alex_joni: that's not currently possible. A user can issue NML home messages for as many axes as he likes, and there's no code to prevent them all trying to happen at the same time.
[15:14:05] <jepler> alex_joni: but in 2.1 and newer you can set a "homing sequence" and define shared home switches, so that the "home all" button will always do the right thing.
[15:14:49] <alex_joni> ok, I am just wondering..
[15:14:52] <jepler> see HOME_IS_SHARED and HOME_SEQUENCE in http://linuxcnc.org/docs/2.1/html/config/ini_homing/index.html
[15:15:22] <alex_joni> the STG board (yuck) needs to select a pair of axes to watch for index pulse, then it outputs 2 bits (odd/even)) when that index has arrived
[15:16:04] <alex_joni> so you first select axis 1&2 or 3&4 or 5&6 or 7&8
[15:16:33] <cradek> wonder what they were smoking
[15:17:03] <jepler> sounds like you have to just declare the board broken, and support index pulse on half the axes
[15:17:18] <jepler> e.g., only on 1,3,5,7
[15:18:18] <alex_joni> errr.. no
[15:18:26] <alex_joni> you can select 1&2 to check for index
[15:18:32] <jepler> oh
[15:18:44] <alex_joni> then you get 2 bits (even if axis 2 has hit an index or odd for axis 1)
[15:18:54] <jepler> sounds like you have to just declare the board broken, and support index pulse only on two of the axes
[15:18:56] <alex_joni> so you can only home max. 2 axes at once
[15:19:28] <alex_joni> I think it can work for all, just only one at a time
[15:19:37] <jepler> can the software driver request the bits for axis 1 and 2 in one polling cycle, and so on -- getting all the index pulse information in 4 servo periods?
[15:20:05] <alex_joni> hmm.. don't think so
[15:20:14] <alex_joni> unless the index pulses come at the right time
[15:20:28] <alex_joni> it works like this: you request axis 1&2 then wait for indexes to arrive
[15:20:35] <alex_joni> then you can select 3&4 and wait for that
[15:20:40] <jepler> sounds like you have to just declare the board broken, and place it in the trash bin
[15:21:02] <alex_joni> well, it kinda reminded me why I didn't do this part the first time
[15:21:03] <cradek> alex_joni: how did it work in emc1? I think it did
[15:21:11] <alex_joni> cradek: one at a time
[15:21:23] <alex_joni> but probably without any error checking
[15:21:25] <cradek> you can home all axes together in emc1 too
[15:21:43] <alex_joni> bet no-one used that with the stg
[15:21:56] <cradek> yes I'm sure they do, I've heard les say so
[15:22:08] <alex_joni> of course this is STG1
[15:22:15] <alex_joni> STG2 is completely different
[15:22:17] <alex_joni> :-/
[15:22:18] <cradek> yes, maybe his is STG2
[15:22:56] <cradek> you don't have to inhibit homing, you only have to inhibit the last move that searches for index
[15:23:21] <jepler> just use the emc2.1 homing sequence and always "home all"
[15:23:41] <jepler> the integrator must make sure two axes have a different HOME_SEQUENCE unless they're on the same stg axis pair
[15:24:55] <alex_joni> jepler: right, that's what I was thinking
[15:25:01] <jepler> and the operator must always use the homing sequence when homing more than one axis
[15:25:05] <jepler> s/when.*$//
[15:25:28] <alex_joni> is there a way that he doesn't ?
[15:25:35] <jepler> ??
[15:26:16] <jepler> afaik only axis sends the "homing sequence" nml message, which is "home axis -1". but in all the guis, you can also home one axis at a time
[15:26:53] <alex_joni> one at a time is no issue
[15:27:07] <alex_joni> unless the user pushes home on all the axes rapidly
[15:27:08] <jepler> I guess I don't really mean "one at a time"
[15:27:21] <jepler> in all the guis, you can send homing messages for the axes individually
[15:27:33] <alex_joni> guess he could go to axis 1 push home, then 2 push home, while 1 didn't finish
[15:27:59] <alex_joni> seems STG2 does it a bit better
[15:28:08] <alex_joni> 8 different bits for index pulses
[15:40:08] <cradek> alex_joni: do you have a link to the stg1 documentation? I can't quite understand it by reading emc1 code
[15:41:28] <cradek> does reading this latch reset it? otherwise I don't see the harm in reading more data than you need
[15:42:00] <alex_joni> hang on
[15:42:51] <alex_joni> you need to read some other registers to reset the latches
[15:43:19] <alex_joni> but the minute you select another pair of axes the latched values are of no use any more
[15:43:44] <alex_joni> http://www.servotogo.com/hardman.zip
[15:43:53] <alex_joni> that's for stg1
[15:44:18] <alex_joni> http://www.servotogo.com/hardman2.pdf for stg2
[15:44:41] <cradek> HARDMAN1.DOC: Microsoft Office Document
[15:44:46] <cradek> offs
[15:46:27] <alex_joni> yup
[15:51:07] <alex_joni> OO opens it though
[15:52:53] <cradek> I see these latches but I don't understand what the index actually does - how do you know the count when the index happened?
[15:54:22] <alex_joni> it latches the count
[15:54:37] <cradek> ok (I should read more)
[15:54:51] <alex_joni> so if you have an index latched, you only red from the output register
[15:55:15] <alex_joni> if not, then you need to make it copy from the counters to the OR then read it
[16:01:28] <cradek> wonder which stg people are mostly using
[16:04:11] <alex_joni> probably both
[16:04:37] <alex_joni> I'll try implement both of them
[16:04:42] <cradek> I don't understand how homing on stg1 works - it must not actually work (sometimes) in emc1.
[16:05:08] <cradek> homing one axis at a time can work, right?
[16:06:08] <alex_joni> right
[16:11:51] <skunkworks> the axis go marching 2 by 2
[18:06:47] <hydra_away> hydra_away is now known as lerneaen_hydra