Back
[00:00:26] <alex_joni> right
[00:01:05] <rayh> Yup. The tree widget stuff itself is about 70k of tickle code.
[00:20:15] <alex_joni> rayh: can you separate that tcl code?
[00:20:29] <alex_joni> so we can distribute it to people who lack it?
[00:23:10] <rayh> I believe I can separate it out.
[00:24:04] <rayh> I'll try that tomorrow.
[00:27:36] <SWPadnos> hmmm - have you read the email from JimJames on the emc-users list?
[00:29:09] <rayh> I did and there is NOT a machine on/off pin.
[00:29:26] <SWPadnos> must be a different email ;)
[00:29:57] <SWPadnos> there's one that just came in a couple of minutes ago, saying that the stg config wasn't a choice for him
[00:30:05] <rayh> the closest you come in emc2 is axis.0.amp-enable-out
[00:30:16] <rayh> or any of the other axes that are defined.
[00:30:59] <alex_joni> hmm.. JimJames needs to wait a few days
[00:31:05] <SWPadnos> indeed
[00:31:06] <alex_joni> I'll make a basic ini
[00:31:24] <SWPadnos> is the configs/stg dir just a placeholder, or can it actually work?
[00:31:44] <alex_joni> it holds the hal files so far
[00:31:48] <alex_joni> no ini yet
[00:31:52] <SWPadnos> ah - ok
[00:31:58] <alex_joni> so that might be a bit much for a newbie ;)
[00:32:03] <SWPadnos> heh
[00:32:13] <SWPadnos> the README is oh so helpful as well ;)
[00:32:36] <alex_joni> fix it :P
[00:32:43] <alex_joni> stop complaining about it :)
[00:32:46] <SWPadnos> as is the Windows information when you mouse over it "Type: file"
[00:33:18] <SWPadnos> I'm not the person to fix it - I have no STG card or experience :P
[00:34:02] <rayh> I loaned my stg out a while back.
[00:34:32] <rayh> Does the standard stg pinouts include an amp enable for each axis?
[00:34:50] <rayh> if so that is the pin to refer him to.
[00:35:42] <alex_joni> rayh: the stg_io.hal and stg_motion.hal are done in such a way to emulate emc1 behaviour fully
[00:35:57] <alex_joni> but his problem is that there isn't an ini, and for a newbie that's a bit much
[00:36:12] <rayh> Oh. Okay.
[00:36:28] <alex_joni> I'll do it tomorrow (lateron today :)
[00:36:38] <SWPadnos> right - cahnging MOTION=motmod to MOTION=-hal_stg didn't work ;)
[00:36:41] <SWPadnos> changing
[00:37:26] <SWPadnos> well - time to go out to a party. wee you later
[00:37:31] <SWPadnos> see, that is :)
[00:37:45] <SWPadnos> SWPadnos is now known as SWP_Away
[00:40:42] <jmk_dinner> jmk_dinner is now known as jmkasunich
[06:39:11] <lilo> [Global Notice] Hi all. We just experienced routing problems with a main rotation server. We're pulling it and checking with the sponsor. Apologies for the inconvenience.
[06:47:11] <jmkasunich> jmkasunich is now known as jmk_sleep
[06:56:48] <lilo> [Global Notice] Hi all. We just experienced loss of bandwidth on a main rotation server. We've rearranged things accordingly. Apologies for the inconvenience, and thank you for using freenode.
[08:22:06] <SWPadnos> SWPadnos is now known as SWP_Away
[17:18:27] <jmk_sleep> jmk_sleep is now known as jmkasunich
[17:19:10] <SWP_Away> SWP_Away is now known as SWPadnos
[17:42:26] <tomp> good morning all
[17:42:48] <rayh> Hi Tom
[17:46:51] <SWPadnos> hit
[17:46:53] <SWPadnos> hit
[17:46:56] <SWPadnos> argh
[17:46:57] <SWPadnos> hi
[17:48:26] <tomp> hal_skeleton wont exit nicely, any ideas?
[17:48:48] <SWPadnos> what does it do? (or not do)
[17:49:09] <tomp> tomp is running it now to report...
[17:49:16] <SWPadnos> ok
[17:49:54] <rayh> what's a hal_skeleton?
[17:50:04] <SWPadnos> sample code for writing a new driver
[17:50:10] <jmkasunich> a "skeleton" driver
[17:50:37] <rayh> oh. something I never want to try to do again!
[17:50:37] <jmkasunich> based on hal_parport, with all the parport specific code ripped out and lots of comments to aid the writer of a new driver
[17:50:52] <cradek> cool
[17:51:13] <tomp> it'sd a model, thats not a bad thing to have
[17:51:20] <rayh> I've tried starting a hal from realtime
[17:51:25] <SWPadnos> though it is missing some (obvious) comments near rtapi_app_exit, telling you to free everything before exiting
[17:51:30] <rayh> and adding a few pins and sigs
[17:51:30] <jmkasunich> unforch it also copied somethign I did in parport only, I attempted to make the driver work in RT an in user space
[17:51:32] <tomp> the 1st err is usually the kicker, it is:
[17:51:40] <tomp> ERROR: Module SKELETON does not exist in /proc/modules
[17:51:49] <tomp> so is the name?
[17:51:58] <tomp> is it the name?
[17:52:12] <jmkasunich> tomp: it may be buggy, it hasn't been maintained
[17:52:29] <jmkasunich> do a /sbin/lsmod, and see what the module name is
[17:52:34] <SWPadnos> it's called SKELETON
[17:52:40] <jmkasunich> then do bin/halcmd show comp, and see what its hal name is
[17:52:44] <SWPadnos> comp_id = hal_init("SKELETON");
[17:52:52] <jmkasunich> thats the problem
[17:52:56] <tomp> ok, i just reboot, i used it to get byte sized ops 'u8' instead og _b
[17:53:08] <tomp> ok , I guess ed that, but the fix is???
[17:53:10] <jmkasunich> tomp, no need to reboot
[17:53:45] <tomp> u8 instead of bit
[17:54:05] <jmkasunich> you can manually rmmod it, but you need to do that using the MODULE name, as shown my lsmod
[17:54:18] <jmkasunich> not the HAL name as shown by "halcmd show comp"
[17:54:58] <jmkasunich> halcmd unloadrt assumes that the HAL name is the same as the module name, and does "rmmod <halname>"
[17:55:06] <SWPadnos> right - the file name is hal_skeleton.{o,ko}
[17:55:19] <jmkasunich> all the other modules do indeed use the same name for hal name and module name, that one got missed
[17:55:25] <jmkasunich> (and I'll fix it right now)
[17:57:53] <tomp> ok, su, ( sudo ng for this), then rmmod hal_skeleton (from lsmod) (works) , then rmmod others (ie: hal_lib?)
[17:58:16] <jmkasunich> the others can be removed by "halcmd unloadrt all" "scripts/realtime stop"
[18:00:32] <jmkasunich> ok, bugfix committed
[18:01:59] <tomp> thank you thank you ,that works, up&down nice (much faster to work with it now :-)
[18:04:47] <tomp> neat, running now,got a widget with 4 sliders under tkemc's scripts menu. it uses tcltk & hal to chg the u8 on parports, live
[18:04:53] <tomp> watching the leds now
[18:18:13] <rayh> Great.
[18:18:47] <rayh> This would be a really nice tuning tool inside halconfig.tcl.
[18:31:43] <tomp> sorry, dozing (workingon furnace sheet metal), ray, how to share it?
[18:32:57] <rayh> I guess I was thinking of the layout. Using sliders to set values to tuning params.
[18:33:28] <rayh> rather than the whole u8 to parport pins stuff.
[18:33:53] <tomp> ok, I'll email the .tcl, this vrsn has a 'confirm' and 'reread' btns
[18:33:56] <SWPadnos> VCP should make that part easy - it's the data converter that's important :)
[18:34:20] <rayh> VCP?
[18:34:33] <tomp> the confirm btn eliminates the constant calls to halcmd, the reread is an 'oops'
[18:34:35] <jmkasunich> btw, VCP is on hold right now, I'm aiming for emc-2.2
[18:34:39] <SWPadnos> jmk - isn't that what it'll be called?
[18:34:41] <SWPadnos> ok
[18:34:46] <SWPadnos> Virtual Control Panel
[18:34:48] <jmkasunich> rayh: VCP = virtual control panel
[18:35:02] <jmkasunich> screen widgets that manipulate/display HAL pins
[18:35:06] <rayh> ah okay.
[18:35:28] <rayh> Is my work on halconfig a total overlap of that?
[18:35:48] <jmkasunich> "buttons" work, I was working on an LED widget when I stopped and tried to focus on release stuff
[18:35:58] <jmkasunich> halconfig doesn't really overlap
[18:36:11] <alex_joni> halconfig is for tuning
[18:36:11] <jmkasunich> VCP is a HAL component, you can connect those widgets to others
[18:36:13] <rayh> rayh is now known as rayh-lunch
[18:36:15] <rayh-lunch> brb
[18:36:22] <alex_joni> VCP is for machine use
[18:36:25] <jmkasunich> halconfig is a HAL manager, not a component
[18:37:08] <SWPadnos> will you check VCP into emc2 CVS after the first release?
[18:37:17] <jmkasunich> yeah
[18:37:25] <SWPadnos> ok - I'd like to work on it some
[18:37:33] <SWPadnos> (or at least kibbitz)
[18:37:34] <jmkasunich> I suppose I could branch and check it in now
[18:38:20] <jmkasunich> or just mail you the source
[18:38:53] <SWPadnos> I can wait - I have a long "short list"
[18:38:58] <jmkasunich> heh, ok
[18:39:06] <alex_joni> and a short "long list" ?
[18:39:11] <SWPadnos> no
[18:39:13] <SWPadnos> :)
[18:39:16] <alex_joni> ok then
[18:39:41] <tomp> can inputs get 'overloaded'? like 8 hal bits also referred to as u8? ( union like?) if in the struct?
[18:39:49] <jmkasunich> no
[18:39:58] <alex_joni> tomp: right now it's pretty strict
[18:40:12] <alex_joni> you can only connect things of the exact same type
[18:40:14] <jmkasunich> connecting one u8 to 8 bits would require a splitter component
[18:40:28] <jmkasunich> (which is something that we have discussed)
[18:40:49] <tomp> ok, that why i was messin in hal_skel, to keep 'em separate
[18:40:56] <SWPadnos> yep - maybe I'll do that sometime soon (unless I don't :) )
[18:41:11] <SWPadnos> we always seem to get bogged down in the details of which conversions make sense
[18:41:41] <SWPadnos> I think 32->2x16, 32->4x8, 16->2x8, and 8->8x1 make sense
[18:42:07] <SWPadnos> but then you have signed vs. unsigned (though unsigned only may be fine)
[18:42:23] <jmkasunich> unsigned only...
[18:42:37] <SWPadnos> ok, then you have the same number of "reverse" options
[18:42:39] <jmkasunich> if you are thinking of the data as a value, why are you splitting it?
[18:42:55] <SWPadnos> dunno :)
[18:43:02] <SWPadnos> just being generic about it
[18:43:52] <tomp> uh, the idea would be... this byte is usually like this, and the single bit is the 'but' logic :-) (but logic )
[18:43:53] <SWPadnos> think of the reverse though - grab 4 bytes and make a 32-bit number out of them
[18:44:48] <jmkasunich> when would you want to do that? when interfacing to some HW that talks in 8 bit chunks? then write a proper driver for it
[18:44:56] <jmkasunich> (playing devils advocate)
[18:44:59] <SWPadnos> heh
[18:45:21] <SWPadnos> uh - so you can test hardware before you've written the driver?
[18:46:06] <tomp> yep, pre-deciding function is ok, i just didnt see any drivers using digital io in bytes
[18:46:10] <jmkasunich> maybe... assuming you already have some other driver that will read the bytes, and that it reads them in the proper order (timewise)
[18:46:32] <SWPadnos> a toolchanger would want to use several bits as a byte (like the one on the Mazak, I think)
[18:46:43] <jmkasunich> that one I agree with
[18:47:00] <jmkasunich> bits to bytes, bytes to bits
[18:47:02] <tomp> the CL 'script' would assure the timing
[18:47:30] <SWPadnos> you then need the others so that you can have a conversion from something other than a byte to/from digital
[18:47:40] <jmkasunich> yes
[18:47:43] <alex_joni> jmkasunich: how do you feel about a signal doing this?
[18:47:46] <SWPadnos> for instance, a 16-bit resolver connected to zillions of bits
[18:47:54] <jmkasunich> I was mostly referring to the signed ones
[18:48:05] <SWPadnos> oh - losing those is no problem for me
[18:48:16] <jmkasunich> SWP: what about the 16 bit resolver?
[18:48:16] <alex_joni> jmkasunich: instead of a component
[18:48:22] <jmkasunich> alex: rather not
[18:48:27] <SWPadnos> with parallel output
[18:48:50] <alex_joni> jmkasunich: or maybe halcmd helper functions..
[18:48:51] <jmkasunich> swp: so the 16 bits of resolver signal go to 16 individual digital ins and get combined in hal>
[18:48:54] <SWPadnos> connect to 16 DIN pins, and convert to a U16 (or possibly an S16, for that matter)
[18:49:03] <SWPadnos> exactly
[18:49:07] <alex_joni> because doing this will get nasty hal files (big ones)
[18:49:20] <jmkasunich> disaster waiting to happen - what if the count value changes when half the inputs have been read
[18:49:34] <alex_joni> you probably need atomic operations
[18:49:35] <SWPadnos> that could be a problem
[18:49:42] <SWPadnos> just like the PPMC :)
[18:50:48] <SWPadnos> connected to an M5I20, there wouldn't be a problem, since the read can be 32 I/Os at a time
[18:51:29] <rayh-lunch> rayh-lunch is now known as rayh
[18:53:11] <tomp> ray i opened a can-o-worms, i asked about using hal-bits as hal-bytes, suggested unions, ended up atomic & groups...
[18:53:52] <SWPadnos> yeah - it's all your fault :)
[18:53:52] <rayh> Right variable typing has been an issue for some time.
[18:54:05] <rayh> I don't object to the hard typing.
[18:54:24] <rayh> It seems like a hal mod could be prepared that would convert
[18:54:29] <rayh> either way.
[18:54:37] <SWPadnos> read back a little ;)
[18:54:39] <rayh> eight pins in to a u8
[18:54:49] <rayh> or a u8 to eight pins out.
[18:55:02] <jmkasunich> I perfer hard typing with conversion components where needed: u8->8xbit, 8xbit->u8, u16->2xu8, 2xu8->u16, u32->4xu8, 4xu8->u32
[18:55:15] <jmkasunich> prefer even
[18:55:16] <rayh> That works for me.
[18:55:24] <tomp> or, really I asked for u8 & 8 pins at same time, (cast or union)
[18:55:26] <SWPadnos> that's what I said, you devil
[18:55:54] <SWPadnos> (plus the 32->2x16 and 16->2x8 and 32->4x8)
[18:57:02] <tomp> i went with separate drivers, cuz i didnt see any such capability for >digital< io ( not encoder, float , just digi )
[18:57:03] <SWPadnos> though you're right - if you do the "direct to bits" version for the longer data types, you can get away without the other type conversions
[18:57:12] <jmkasunich> SWP: I know, I was re-iterating ;-)
[18:57:16] <SWPadnos> heh
[18:57:30] <SWPadnos> I'm from the department of redundancy department
[18:57:43] <tomp> where? where?
[18:57:59] <SWPadnos> is there an echo in here echoing?
[18:58:09] <tomp> <goon show>
[18:58:12] <SWPadnos> heh
[18:59:37] <SWPadnos> maybe a "convert" component?
[19:00:12] <jmkasunich> convert would be the file, like blocks, the individial components would be named by the type of conversion they do
[19:00:21] <SWPadnos> right
[19:01:10] <SWPadnos> but what to call the config options?
[19:01:19] <SWPadnos> U8toBits
[19:01:27] <SWPadnos> BitstoU8 ...
[19:01:36] <SWPadnos> could get long
[19:03:17] <tomp> for unsigned it
[19:04:00] <jmkasunich> u8_2_bit
[19:04:06] <jmkasunich> u32_2_u8
[19:04:08] <jmkasunich> etc
[19:04:14] <tomp> for unsigned it's 3 more pairs, for signed, 3more pairs, looks like 12 types
[19:04:29] <jmkasunich> (mixed case isn't used elsewhere in HAL)
[19:05:13] <SWPadnos> ok
[19:05:39] <SWPadnos> and use the same name in the config string as the component name in HAL?
[19:06:12] <jmkasunich> you mean the insmod arg? yes
[19:06:17] <SWPadnos> yep - ok
[19:06:19] <jmkasunich> u8_2_bit=3
[19:06:25] <jmkasunich> if you want 3 of them
[19:06:34] <jmkasunich> just like blocks.c
[19:06:52] <tomp> do we need more scenarios before coding? like see what is practically needed?
[19:07:24] <tomp> we're disacussing how to spell the names already
[19:07:29] <rayh> in that case u8_2_bit would be the component name?
[19:07:50] <rayh> if so I like ddt better.
[19:08:05] <jmkasunich> rayh ?
[19:08:06] <SWPadnos> maybe use "to" instead of "2"
[19:08:21] <tomp> what was ddt? old memories stirred
[19:08:31] <rayh> I'm just thinking of how the pins look with show.
[19:08:31] <SWPadnos> derivative (d/dt)
[19:08:32] <jmkasunich> ddt is the differentiator block in blocks.c
[19:08:38] <tomp> and others
[19:09:08] <tomp> but what did you mean ray?
[19:09:16] <jmkasunich> u8_to_bit, 8utobit?
[19:09:26] <jmkasunich> oops
[19:09:28] <rayh> a ddt pin might be ddt.0.in
[19:09:31] <jmkasunich> u8_to_bit, u8tobit?
[19:09:46] <alex_joni> u8->bit ;)
[19:09:47] <SWPadnos> actually, just calling them "byte.n" would make some sense - you would have pins like "byte.0.bit-0-out"
[19:09:54] <jmkasunich> pins would be u8_to_bit.0.bit.0.in
[19:10:14] <jmkasunich> which way does "byte" convert?
[19:10:16] <SWPadnos> err - u8_to_bit.0.bit.0.out
[19:10:28] <jmkasunich> oops, right
[19:10:30] <SWPadnos> or call them u8 in that case
[19:10:31] <tomp> hierarchical? byte.0 and byte.0.bit.o?
[19:10:35] <SWPadnos> u8.0.bit.0.out
[19:10:41] <tomp> yeh yeh
[19:10:48] <SWPadnos> bits.0.u8.out
[19:10:56] <SWPadnos> bits.1.u16.out
[19:10:58] <SWPadnos> ...
[19:11:06] <rayh> * rayh gets lost in all the possibilities.
[19:11:18] <SWPadnos> (possibly make bits8 and bits16, for cfg purposes)
[19:11:21] <jmkasunich> now you know why we haven't made that component yet
[19:11:24] <SWPadnos> heh
[19:11:26] <tomp> now no need for casts unions overloading, it's poppa and baby-brother
[19:11:36] <SWPadnos> and we haven't even gotten into float / int conversions yet
[19:13:22] <jmkasunich> float/int conversions make little sense to me
[19:13:39] <jmkasunich> floats are for inherently analog (continuous) signals
[19:13:44] <jmkasunich> ints are quantized
[19:13:54] <SWPadnos> yep
[19:14:05] <SWPadnos> but then there's the R-2R ladder you might connect to the parport
[19:14:23] <jmkasunich> we do have drivers that convert from int to float, like the encoders that convert raw counts to position
[19:14:29] <SWPadnos> and it would be a heck of a lot easier to not write a special driver for it
[19:14:38] <tomp> knob detent at posn 5 goes to spindle speed which is a float, spindle speed float goes to led speed5
[19:14:46] <jmkasunich> they also have scale and offset, because analog -> quantized conversions probably involve scaling
[19:14:51] <SWPadnos> yes
[19:15:02] <SWPadnos> you can't just directly convert
[19:15:20] <SWPadnos> ther eare scale/offset float compe, but no way to get that to int (right?)
[19:18:12] <jmkasunich> ok, you win ;-) I'm convinced that there is use for a float to/from s32 conversions
[19:18:34] <SWPadnos> heh
[19:18:43] <jmkasunich> u32 to float would also work, float to u32 has a problem if the float is negative
[19:19:01] <SWPadnos> or >MAXINT
[19:19:20] <SWPadnos> there would probably be max and min params anyway
[19:48:37] <rayh> Hey I need a quick way to change a scientific notated value to decimal?
[19:48:47] <rayh> bc says it won't
[19:49:10] <rayh> see lots of stuff that will convert decimal to scientific notation.
[19:49:26] <SWPadnos> in tcl?
[19:49:36] <rayh> Yes.
[19:49:57] <SWPadnos> it should be able to interpret the scientific notation as a number, then use format to print it
[19:50:07] <rayh> right now it's a [split $string +]
[19:50:12] <SWPadnos> or does it not "get it" with scientific notatipn?
[19:50:23] <SWPadnos> notation
[19:50:26] <rayh> every variable is a string.
[19:50:48] <SWPadnos> eval?
[19:50:55] <jmkasunich> variables get converted to numbers to do math, right?
[19:51:10] <jmkasunich> [ eval $variable + 0 ]
[19:51:19] <SWPadnos> they must, or var = var + 1 would give a long string of '1's
[19:52:29] <jmkasunich> not eval, expr
[19:52:37] <rayh> right.
[19:53:08] <rayh> within expr it can treat variables as having value
[19:53:18] <jmkasunich> set foo 1.4e4 puts [ expr $foo ] gives 14000.0
[19:56:48] <tomp> yep set bar [expr $foo]
[20:14:23] <rayh> Ah I'll try that. Thanks guys.
[20:44:50] <alex_joni> has anyone heard of PCX/DSP from MEI(Motion Engineering Inc, US)
[20:50:19] <alex_joni> jmkasunich: you might be interested by this..
[20:50:33] <alex_joni> it's an 8-axis control board with a fast DSP on it
[20:50:59] <SWPadnos> they provide libraries for it (inthe form of .dll's, I thikn)
[20:51:03] <SWPadnos> think
[20:51:19] <alex_joni> right, and I have an user asking now if it can be modified for emc2
[20:51:30] <alex_joni> to access directly the dac's adc's etc
[20:52:28] <jmkasunich> oh....
[20:52:31] <jmkasunich> * jmkasunich hides
[20:52:37] <SWPadnos> they havea Linux port - have you found out if it's open source?
[20:53:00] <alex_joni> hang on, I have some sources he sent me
[20:54:40] <SWPadnos> it looks like you have to pay for the libraries
[20:55:27] <tomp> sounds like a pmac, maybe ressurrect the old emc wrapper for pmac
[20:55:34] <jmkasunich> I dunno why you would want to pay for a fast DSP only to bypass it and access the I/O directly
[20:55:54] <jmkasunich> it seems like it was designed to handle the RT load so a non-RT OS could be used to do the rest
[20:55:54] <alex_joni> and it seems to do S-curve profile
[20:55:59] <SWPadnos> you can make a HAL pid block that just sends the params on to the DSP
[20:56:11] <alex_joni> it does have PID in it ;)
[20:56:24] <SWPadnos> though a 40MHz DSP may not give any speed advantage
[20:56:54] <SWPadnos> To create a motion sequence, the DSP executes a series of ?frames? that are generated by MEI C library functions and sent from the host. Each frame is an array of 20 words that contain position, velocity, acceleration, jerk, I/O status, and trigger information.
[20:57:13] <SWPadnos> sounds fairly ideal, actually ;)
[20:57:26] <jmkasunich> I bet it would - a 40MHz DSP running an optimised fixed point algorithm will blow the socks of a GHz class general purpose CPU when it comes to latency and jitter
[20:57:36] <SWPadnos> true
[20:57:45] <SWPadnos> a 1MHz DSP might, come to think of it
[20:58:13] <SWPadnos> at least in the jitter category
[20:59:16] <alex_joni> well, I'm not sure what to advise this user..
[20:59:33] <jmkasunich> depends on their skill level and motivation
[20:59:47] <alex_joni> " I thought I will just ask you before I start to involve someone
[20:59:47] <alex_joni> to write a driver, if first of all, is it possible to use this board
[20:59:47] <alex_joni> and just access the low lovel encoder, dac and i/o.
[20:59:47] <alex_joni> And second, may it be worth it, or is it better or cheaper to buy a m5i20 board for around 400 us dollars?
[20:59:49] <SWPadnos> maybe that it wold be possible to write a driver if the specs to the board or the library are made available to the developers ...
[20:59:56] <jmkasunich> if they have coding skills and the dev tools for the DPS, they can certainly make it work
[21:00:22] <SWPadnos> it's a question of having a proprietary driver for emc, I think
[21:00:40] <jmkasunich> I might be willing to write the HAL driver (PC side), but I suspect it will need changes to the DSP code as well, I won't do that
[21:00:41] <SWPadnos> since it looks like the programming specs aren't generally available
[21:02:26] <alex_joni> hmm, there are some functions available to access low level stugg
[21:02:29] <alex_joni> stuff
[21:02:45] <alex_joni> int FNTYPE dsp_port_address(int port, P_INT address) ;
[21:02:45] <alex_joni> int FNTYPE pcdsp_get_io(PDSP dsp, int port);
[21:02:45] <alex_joni> int FNTYPE pcdsp_set_io(PDSP dsp, int port, int value);
[21:02:45] <alex_joni> int FNTYPE pcdsp_init_io(PDSP dsp, int port, int config);
[21:02:55] <jmkasunich> for me at least, any work on a driver would have to wait until after the emc-2.0.0 release
[21:02:57] <alex_joni> and so on...
[21:03:06] <alex_joni> but it certainly wouldn't be GPL
[21:03:20] <jmkasunich> then I won't work on it
[21:03:38] <alex_joni> right
[21:03:39] <jmkasunich> (unless they wanted to pay me lots of money ;-)
[21:03:52] <alex_joni> and me too .. for hooking them up :D
[21:04:08] <alex_joni> you do need a manager afterall :D
[21:04:20] <jmkasunich> ;-)
[21:05:29] <jmkasunich> * jmkasunich tries to figure out how to detect and report RT overruns
[21:07:11] <jmkasunich> I just discovered something interesting... the BDI-2.18 box on the compile farm does NOT have sudo installed or configed
[21:07:23] <jmkasunich> so the new emc2 run script that uses sudo... won't work right
[21:10:23] <alex_joni> oh..
[21:10:37] <alex_joni> but it would I think..
[21:10:45] <alex_joni> sudo gets found by configure
[21:10:57] <alex_joni> and it replaces teh $SUDO with what it finds
[21:11:09] <alex_joni> so if no duso is found $SUDO should be empty
[21:11:22] <alex_joni> s/duso/sudo/
[21:14:09] <rayh> why do I get this -- motmod u8 R- 0 (00) traj.active_tc
[21:14:10] <rayh> m
[21:14:12] <jmkasunich> so the user just needs to do 'su -c "scripts/emc myconfig"'
[21:14:41] <rayh> all the u8 replies give two values
[21:14:50] <rayh> in that column.
[21:14:51] <SWPadnos> using -s?
[21:14:55] <jmkasunich> decimal and hex
[21:14:56] <rayh> Yes
[21:15:02] <tomp> 0 is the simple (hex) is other
[21:15:02] <SWPadnos> maybe I missed that
[21:15:06] <rayh> ah.
[21:15:25] <jmkasunich> -s should fix that
[21:15:31] <jmkasunich> give you decimal only
[21:15:49] <rayh> That would be more consistent with the rest and make my parsing easier.
[21:16:11] <jmkasunich> what command gave you that line? show param?
[21:16:49] <rayh> yes
[21:17:02] <rayh> bin/halcmd -s show param
[21:18:42] <SWPadnos> hmm - are you absolutely positive that -s was in there?
[21:18:51] <jmkasunich> doing the same thing here
[21:18:55] <jmkasunich> all the u8s
[21:19:05] <rayh> stepgen s32 -W 0 stepgen.2.counts
[21:19:14] <rayh> works
[21:19:20] <rayh> only u8 is odd.
[21:19:45] <jmkasunich> originally only u8 displayed the hex (the others it would have been too long)
[21:20:07] <jmkasunich> but SWP added the -s specifically to eliminate the hex (among other script friendly things)
[21:20:15] <jmkasunich> and I thought it was tested and working weeks ago
[21:20:15] <SWPadnos> print_param_info has a separate case for the script mode
[21:20:51] <SWPadnos> data_value must not be printing decimal
[21:21:17] <SWPadnos> that's teh thing - when you get the name, there's no way to get two numbers from that printf
[21:21:36] <SWPadnos> the name of the component
[21:21:43] <jmkasunich> huh?
[21:21:51] <SWPadnos> this is a param, right?
[21:21:57] <jmkasunich> yeah
[21:22:21] <SWPadnos> print_param_info has a printf for the scriptmode case, where the component name is printed instead of the comp_ID
[21:22:31] <SWPadnos> that printf has only one instance of data)value
[21:22:33] <jmkasunich> yeah, I see that
[21:22:35] <SWPadnos> data_value
[21:22:53] <jmkasunich> but data_value returns a string, which can have both dec and hex in it
[21:23:19] <SWPadnos> ok - that should be data_value2
[21:23:21] <jmkasunich> yep, the u8 case doesn't care about mode
[21:23:33] <jmkasunich> yes
[21:23:40] <rayh> I created a new u8 sig
[21:23:49] <rayh> set its value to 15
[21:23:51] <SWPadnos> I guess I had never seen a u8 param before that
[21:23:52] <rayh> and got this
[21:23:56] <rayh> u8 15 MySig
[21:24:16] <SWPadnos> pins, params, and sigs are printed from different functions
[21:24:16] <jmkasunich> sigs work right, params dont, simple type
[21:24:22] <jmkasunich> swp, you wanna fix or should I
[21:24:24] <SWPadnos> typo ;)
[21:24:33] <SWPadnos> you should, I'[m on a Windows machine ATM
[21:24:37] <jmkasunich> ok
[21:24:51] <SWPadnos> I don't want to try Tortoise CVS for checkins right now ;)
[21:26:30] <rayh> Now that's what I call a quick bug fix.
[21:27:38] <jmkasunich> committed
[21:28:08] <alex_joni> lately bugfixes are always quick ;)
[21:28:34] <jmkasunich> second one today...
[21:28:51] <SWPadnos> thank you
[21:29:44] <jmkasunich> 13 mins from report to commit.... heh ;-)
[21:29:59] <rayh> Thanks.
[21:30:15] <alex_joni> and no SF report even
[21:30:25] <rayh> eat your heart out ms
[21:30:34] <jmkasunich> the other one (tomp's prob with skeleton) took 12 mins ;-)
[21:30:45] <SWPadnos> yeah - I didn't get a message about the TODO change
[21:31:12] <jmkasunich> SWP: for some reason that commit message must have gotten lost
[21:31:26] <SWPadnos> yep
[21:31:28] <jmkasunich> later commits from me went thru fine
[21:31:31] <rayh> I just check the tarball at .ro and it's good.
[21:31:36] <SWPadnos> I actually had to cvs up to see the changes - imagine!
[21:32:07] <alex_joni> rayh: good
[21:32:41] <rayh> I've got a guy building a system on 4.30 this afternoon. The tarball will help a lot.
[21:32:43] <rayh> thanks.
[21:32:57] <alex_joni> rayh: no problem ;)
[21:33:22] <alex_joni> the problem was I can't test the tarball on that machine, no RT
[21:33:39] <alex_joni> that's why I didn't notice it was borked
[21:34:49] <rayh> I used to have that problem. Now everything (5) are rtai.
[21:35:28] <alex_joni> jmkasunich: that board looks really good
[21:35:29] <tomp> thanks for the quick fixes, but following you guys is like raking leaves :-) i only get bits ( another dyslexic pun.. i only gets bit )
[21:35:43] <alex_joni> it even does dual loop (linear encoder on axis, and rotary encoder on motor..)
[21:36:27] <rayh> I had a guy the other day copy a compiled emc2 to a different directory.
[21:36:27] <SWPadnos> see if you can get the people who contacted you to push the company to release programming specs
[21:36:32] <SWPadnos> (or even better, the library)
[21:37:08] <rayh> It would not run -- expected, but I suggested he make clean and recompile.
[21:37:11] <alex_joni> rayh: I imagine that doesn't work
[21:37:13] <rayh> that failed.
[21:37:26] <alex_joni> he needs to re ./configure as well
[21:37:31] <SWPadnos> ./configure / make clean / recompile
[21:37:37] <alex_joni> yup
[21:37:38] <rayh> It wouldn't do that.
[21:37:56] <alex_joni> because Makefile.inc has some directory names in it
[21:38:06] <rayh> Is that it.
[21:38:28] <rayh> We'd have to make clean then move then rebuild?
[21:39:25] <alex_joni> no, you need to rerun ./configure
[21:39:34] <alex_joni> after that you can run make clean and make
[21:40:23] <alex_joni> either way, if you move to a new dir, you need to run ./configure again
[21:42:56] <rayh> Okay.
[21:46:42] <alex_joni> ok, guys
[21:46:45] <alex_joni> I'm off to bed
[21:46:46] <SWPadnos> ok
[21:46:47] <alex_joni> night all
[21:46:53] <rayh> see you
[21:46:53] <SWPadnos> see ya
[21:47:55] <tomp> bye alex thanks
[21:51:12] <jmkasunich> night alex
[21:51:29] <jmkasunich> does anyone here have a BDI-TNG install?
[21:51:59] <jmkasunich> or a BDI-Live rc46?
[21:52:19] <jmkasunich> (actually the rc46 is the one I really need)
[21:53:53] <tomp> pretty sure it's in my bdi cd collection, send iso to ---att address?
[21:54:01] <tomp> or parts
[21:54:09] <jmkasunich> thats not it
[21:54:15] <jmkasunich> I need something tested
[21:54:49] <tomp> ok, firing up the 3in1 , it might be rc46
[21:54:50] <jmkasunich> I tried the "realtime start" script in the compile farm BDI-Live slot and it failed with a crapload of undefined kernel symbol messages
[21:55:16] <jmkasunich> the problem isn't emc, hal, or rtapi, it seems to be when loading RTAI itself
[21:55:44] <jmkasunich> I dunno if I have a problem with my install, or if we're loading the wrong modules or something in the realtime script
[21:56:34] <jmkasunich> the compile farm slot installs are a little non-standard, to deal with the fact that they have truly ancient CPUs and graphics, no X, etc
[21:57:52] <tomp> wasnt TNG the redhat 7.2 version?, and rc46 soemthing else?
[21:57:57] <jmkasunich> yes
[21:58:07] <jmkasunich> rc46 was knoppix based IIRC
[21:58:36] <tomp> how can I check ( still booting amdk6-166) ?
[21:58:52] <jmkasunich> do you have emc2 on the box?
[22:00:28] <tomp> no emc2
[22:00:56] <jmkasunich> is it on the internet? (can you download and try emc2?) if not, don't worry about it
[22:01:18] <tomp> not on net, sorry
[22:01:32] <jmkasunich> that's alright, thanks anyway
[22:02:34] <tomp> do you have time to describe this new (to me ) project that has widgets and data types? or a ptr to a desc?
[22:03:51] <jmkasunich> the idea is to be able to pop up a window with a user configurable group of GUI widgets, and have the widgets connected to HAL pins
[22:04:01] <jmkasunich> button widgets control a bit pin
[22:04:12] <jmkasunich> LED widgets display the state of a bit pin
[22:04:22] <jmkasunich> knob or slider widgets would control a float pin
[22:04:36] <jmkasunich> meter or bargraph widgets would display the state of a float pin
[22:05:03] <tomp> tcltk? python? C++?
[22:05:06] <jmkasunich> C
[22:05:17] <jmkasunich> (the program is written in C)
[22:05:27] <tomp> and the widget set uses ? glade?
[22:05:33] <jmkasunich> the actual configuration of the widgets is done by a file using a rather simple syntac
[22:05:36] <jmkasunich> syntax
[22:05:40] <jmkasunich> all text based
[22:05:56] <jmkasunich> usage: vcp <name of .vcp file>
[22:06:19] <jmkasunich> it will read the .vcp file and display a window showing the widgets defined in the file
[22:06:32] <tomp> text files interpreted by the C prog? ( scripted), yep from your VCP note
[22:06:38] <jmkasunich> yes
[22:06:55] <jmkasunich> hang on a sec, let me find something...
[22:21:41] <jmkasunich> I'm tempted to commit VCP as it stands right now
[22:21:48] <jmkasunich> let folks play with it if they want
[22:22:07] <rayh> Go for it.
[22:22:31] <SWPadnos> yeah - if it does *anything*, it'll be good to get a look-see, and possibly make additions
[22:22:40] <jmkasunich> I'm gonna add an "experimental" notice and commit it
[22:22:48] <jmkasunich> along with a sample .vcp file
[22:23:21] <jmkasunich> hmm, before I do, a directory issue to hash out
[22:23:24] <SWPadnos> I can also take a look (sometime) at the qthmi stuff from a while ago, and see how it might interface to HAL (from userspace)
[22:23:41] <jmkasunich> I created a new dir under hal called "user_comps" for user space components
[22:23:44] <jmkasunich> vcp is in there
[22:24:00] <jmkasunich> I haven't yet added that dir to CVS, once added it can't be easily removed
[22:24:10] <jmkasunich> does that seem like the right place for something like this?
[22:24:15] <tomp> thanks john, for you and ray et al, i just used abit of tkzinc, tcl & a new nicer look
[22:24:48] <SWPadnos> yes, though you may want a subdir under there for each component - they may be more complex than one or two source files
[22:25:09] <jmkasunich> vcp has 3 .c and 2 .h files
[22:25:20] <jmkasunich> not worth a subdir imo
[22:25:27] <jmkasunich> its easier to add one later than to remove one
[22:25:37] <SWPadnos> but when I add another thing with 5 or 6 source files, and then Alex adds another ...
[22:25:43] <jmkasunich> ok
[22:25:56] <tomp> what's the acronym, Visual C??? P??
[22:26:02] <SWPadnos> Virtual Control Panel
[22:26:04] <jmkasunich> virtual control panel
[22:26:12] <tomp> thanks
[22:26:39] <jmkasunich> the idea is that you can make on-screen stuff that behaves just like physical buttons and led and such, and connect them thru hal as if they were real
[22:26:54] <jmkasunich> usefull to fake I/O that you don't have for example
[22:26:55] <tomp> ooooh, major tom this is ground control....
[22:27:08] <tomp> yep john, thats what I been thinking aboot
[22:27:26] <jmkasunich> "what will my ladder do if the oil pressure switch trips", connect a VCP button where the oil switch goes, push the button, and find out
[22:27:32] <tomp> ( heh so it is labview )
[22:27:37] <SWPadnos> heh
[22:27:44] <SWPadnos> them's fightin' words
[22:28:29] <SWPadnos> it would also be possible to make user-configurable UIs out of something that uses this (though it would need more stuff as well)
[22:29:10] <jmkasunich> yeah, it would need a "HAL to NML UI connector" such that when the "jog" HAL pin goes true, a jog command is issued
[22:29:28] <jmkasunich> then jog could come from either a physical button (pendant) or a vcp button
[22:29:35] <rayh> I'm seeing issues in halconfig watch if I try to watch more than a few signals.
[22:30:18] <tomp> and i dont see any scripted examples of NML msg generation. the TclTk connection is hanging on by outb, inb
[22:30:30] <rayh> I'm guessing that we will need to open a channel to halcmd rather than using halcmd for each.
[22:31:00] <tomp> yes please, I got file access too often now
[22:31:22] <tomp> every widget interaction becomesa file access
[22:31:31] <rayh> Right.
[22:31:53] <SWPadnos> it should be in cache after the first use, unless you have a very low RAM system
[22:32:09] <jmkasunich> still have process creation and all that
[22:32:18] <SWPadnos> yes
[22:32:32] <SWPadnos> though that was in the millisecond range, IIRC
[22:32:47] <rayh> let me commit what I've got and you work it a bit.
[22:33:17] <tomp> didnt know that about the cache (forgot it )
[22:35:13] <jmkasunich> SWP: milliseconds add up if you invoke halcmd once per each of many vars that you are watching
[22:36:05] <SWPadnos> true - that can be taken care of with tcl though
[22:36:20] <SWPadnos> just run it once, and use named indexes to get the values out
[22:36:32] <tomp> so a reduction could be had if hal knew a struct and we passed that rather than each peanut bit
[22:36:58] <rayh> This is a case of a set of halcmd show pin xxx then xxy then xxxz
[22:37:09] <SWPadnos> like array = [exec bin/halcmd -s show param | awk {print $4 $5} ]
[22:37:30] <jmkasunich> yeah, just invoke halcmd once, then pick out the values you want in tcl
[22:37:32] <SWPadnos> or list - whichever one allows you to set anme = value pairs
[22:37:38] <SWPadnos> ... name ...
[22:38:13] <jtr> jmkasunich: how soon do you need to test against rc46? I have a k62-300 and a P166, but would have to install...
[22:38:40] <jmkasunich> not urgent, but before we do the release (a couple weeks)
[22:39:04] <jmkasunich> rayh: do you have a rc46 box in your collection?
[22:39:16] <tomp> with emc2
[22:40:42] <jtr> Where's the closest copy of the iso? i'm in NC
[22:42:17] <jmkasunich> list of mirrors:
http://www.linuxcnc.org/bdi/iso.html
[22:42:36] <jmkasunich> not sure which ones have the older versions
[22:44:44] <rayh> Yes I do.
[22:44:48] <jtr> I see it on dsplabs; I'll check the others. You don't need a running machine connected to it, I hope?
[22:45:07] <jmkasunich> no running machine, we can test using sim, or the stepper config
[22:45:27] <rayh> What do we need of an rc46?
[22:45:33] <jmkasunich> rayh: wanted to make sure emc2 (specifically the "realtime" script) works properly on rc46
[22:45:48] <jmkasunich> it doesn't on the compile farm slot, but those configs might be screwy
[22:46:13] <jmkasunich> the problem isn't emc proper, it happens when loading RTAI modules
[22:46:30] <rayh> Let me see if I can make rc46 run here.
[22:47:10] <tomp> i have a sys labled rh7.2 and another (runnig) thats sez it uses RTLinux-3.0, any use? ( i can move a cd with emc2 tgz there)
[22:49:39] <jtr> Note: the link to cncgear.com is hosed - EMC and BDI are transposed in the url
[22:49:48] <SWPadnos> from where?
[22:50:14] <jtr> sorry -
http://www.linuxcnc.org/bdi/iso.html
[22:50:20] <SWPadnos> right - from linuxcnc.org
[22:50:36] <SWPadnos> can anyone here change that, or do we need SteveS?
[22:50:47] <rayh> I probably can change it.
[22:51:02] <SWPadnos> ok. the text is correct, but the link is wrong. thanks jtr
[22:51:39] <SWPadnos> maybe that's why my bandwidth usage was never too high ;)
[22:52:39] <jtr> ah, so that's yours
[22:52:43] <SWPadnos> yep
[22:52:48] <SWPadnos> ugly though it is
[22:53:11] <jtr> I like the incoming dir...
[22:54:09] <SWPadnos> is there one? :)
[22:54:30] <SWPadnos> oh right - the AVR stuff I was doing with A-L-P-H-A
[22:54:55] <rayh> try that link.
[22:55:45] <jtr> much better - I gotta learn to type
[22:55:47] <SWPadnos> much better
[22:55:59] <SWPadnos> after a reload, that is ;)
[22:56:31] <jtr> spend all mty/my time correcting the guy that does my typing for me.
[22:56:32] <SWPadnos> ok - Paul's incoming dir (I didn't think I had one)
[22:59:24] <jtr> Ok, wildrice has the rc46, says it needs 256M of ram - I'll have to run it on this machine.
[22:59:52] <rayh> I've seen it run 190
[23:01:22] <jtr> the others have 32 and 64 - it'll have to be this one.
[23:03:42] <rayh> I'm copying emc2 to rc46 now but not certain what I'll have to do to make it compile.
[23:03:52] <jtr> it's on its way - now to learn how to burn a cd under linux
[23:03:58] <jmkasunich> cd ..
[23:04:00] <jmkasunich> oops
[23:04:33] <jmkasunich> ok, prelim version of vcp committed
[23:04:45] <jmkasunich> to play with it, make, then from the top level emc2 dir do:
[23:04:59] <jmkasunich> bin/halvcp configs/sim/test.vcp
[23:05:19] <jmkasunich> (oops, need to do "scripts/realtime start" first to load HAL)
[23:05:26] <SWPadnos> cool, thanks :)
[23:05:40] <jmkasunich> that will pop up a window as defined by test.vcp, with 9 buttons that control 9 hal pins
[23:05:42] <tomp> thanks john, how do i check it out ( cvs newbee) ?
[23:05:55] <jmkasunich> do you have an emc2 cvs checkout?
[23:06:00] <tomp> yep
[23:06:05] <jmkasunich> just do an update
[23:06:07] <jmkasunich> cvs up -dP
[23:06:14] <tomp> too easy
[23:06:30] <rayh> If he is anon then it will take a while to get there.
[23:06:56] <jmkasunich> test.vcp defines buttons that could be used to simulate limit and home switches
[23:07:30] <jmkasunich> rayh: right, some hours (maybe worse if the problem with pserver cvs is still happening)
[23:08:26] <tomp> cvs [update aborted]: end of file from server (consult above messages if any)
[23:08:33] <jmkasunich> damn
[23:08:41] <tomp> so, i should wait?
[23:08:41] <jmkasunich> that is a sourceforge problem
[23:08:42] <SWPadnos> I see the pserver problems are still happening
[23:08:48] <rayh> Perhaps someone with a fast connection could send a tarball.
[23:08:57] <jmkasunich> alex's tarball will be updated tomorrow
[23:09:01] <rayh> rc46 still making
[23:09:15] <tomp> domani, thanks
[23:09:56] <rayh> Used to be that a via 800 was fast.
[23:10:12] <SWPadnos> used to be athat a 486/33 was fast ;)
[23:10:43] <rayh> got one of those also.
[23:10:45] <SWPadnos> I remember seeing the game Centipede run so fast, you couldn't see the motion
[23:10:55] <rayh> off line these days.
[23:11:02] <SWPadnos> I think that was a 386, come to think of it
[23:11:05] <jtr> I'm looking at an hour (or more) to dl the rc46 iso. SWMBO calls - dinner. bbl
[23:11:19] <SWPadnos> see you later
[23:14:09] <jmkasunich> getting to be dinner time here too....
[23:17:12] <rayh> /root/emc2/rtlib/hal_lib.o: /root/emc2/rtlib/hal_lib.o: unresolved symbol rtapi_task_start
[23:17:12] <rayh> ERROR: Could not load 'rtapi'
[23:17:12] <rayh> ERROR: Could not load 'hal_lib'
[23:17:13] <rayh> Realtime system did not load
[23:17:57] <jmkasunich> try /sbin/lsmod, see if the RTAI modules loaded
[23:18:05] <jmkasunich> I bet they didn't
[23:18:15] <jmkasunich> there might be more error messages in dmesg
[23:19:48] <rayh> rtai_math did.
[23:19:58] <jmkasunich> but only that one, right? (same here)
[23:20:03] <rayh> yep
[23:20:18] <jmkasunich> damn and double damn... that is NOT the kind of thing I want to be investigating right now
[23:20:38] <rayh> I wouldn't know where to begin.
[23:20:49] <SWPadnos> what kernel is rc46?
[23:20:56] <rayh> But I do have the box on net now and can test.
[23:21:11] <jmkasunich> 2.4.25-adeos
[23:21:13] <rayh> 2.4.25
[23:21:34] <SWPadnos> ok - pretty close to early BDI4.xx