Back
[18:58:20] <SWPadnos> I wonder if the friendly folks at DreamHost are killing off that process from time to time
[18:58:44] <cradek> can you use cron?
[18:58:52] <SWPadnos> I think so
[18:59:10] <cradek> then just make a script that starts it if it's not already running
[18:59:14] <SWPadnos> I guess I could make that an hourly
[18:59:41] <SWPadnos> running it is weird though. the script doesn't seem to work unless I source (or .) it
[19:00:08] <cradek> better figure that out first...
[19:00:29] <SWPadnos> the cron job should probably be run under the emcboard login as well
[19:04:25] <jmkasunich> I just made a new hal component that takes a s32 count (as from an encoder), and enable bit, and a float scale
[19:04:42] <jmkasunich> if enabled, when count changes, the float output changes (according to scale)
[19:04:47] <jmkasunich> there are max and min limits
[19:05:01] <jmkasunich> so you can use a jogwheel type encoder to control a float value
[19:05:19] <jmkasunich> can anybody think of a better name than "knob2float"?
[19:05:20] <SWPadnos> cool - kind of an int -> float converter
[19:05:54] <jmkasunich> the plan is to allow a real knob to control things like feed override, etc
[19:06:11] <SWPadnos> sure, but it's a "smart" int->float converter, at its core
[19:06:16] <jmkasunich> right
[19:06:18] <SWPadnos> maybe add an offset as well ...
[19:06:28] <jmkasunich> why?
[19:06:36] <jmkasunich> remember, it works with deltas
[19:06:42] <SWPadnos> err - so it can do everything you may need when converting an into to a float ...
[19:06:52] <SWPadnos> ah, so the output is the delta. I didn't catch that
[19:07:16] <jmkasunich> you can disable it and spin the knob 1000 times without the output changing
[19:07:28] <jmkasunich> when you re-enable it, there is still no change until you turn the knob
[19:07:30] <SWPadnos> ok, in that case there's no need for an offset
[19:07:51] <jmkasunich> the idea is that one knob can supply counts to N of these, you enable one at a time with a pushbutton
[19:07:52] <cradek> halui has that kind of thing for FO already doesn't it?
[19:08:20] <jmkasunich> does it take in counts? or does it expect a float between 0.0 and max FO?
[19:08:35] <cradek> counts
[19:08:36] <SWPadnos> I think it's there for jogging, but not for FO
[19:08:44] <cradek> hmm I better look
[19:08:48] <jmkasunich> for jogging, its implemented in the motion module
[19:08:54] <SWPadnos> at least the enable / offset thing
[19:08:57] <SWPadnos> true
[19:08:57] <jtr> I remember using respawn with getty - would it be applicable to the logger process?
[19:09:07] <SWPadnos> that's probably what I was thinking of
[19:09:18] <jmkasunich> basiclly, this component is the motion module's jogwheel implementation pulled into a separate component
[19:09:37] <SWPadnos> maybe call it a jogdelta then ...
[19:09:38] <cradek> counts = *halui_data->fo_counts;
[19:09:38] <cradek> if(counts != old_halui_data.fo_counts) {
[19:09:38] <cradek> sendFeedOverride( *halui_data->fo_value + (counts - old_halui_data.fo_counts) *
[19:09:46] <cradek> same for spindle override
[19:09:48] <SWPadnos> hmmm
[19:10:00] <jmkasunich> are there enable and scale pins?
[19:10:22] <cradek> scale, not enable
[19:10:29] <jmkasunich> enable is needed for multi-purpose wheels
[19:12:07] <jmkasunich> anyway, I want the standalone component
[19:12:09] <cradek> what did you expect to do with the float once you had it?
[19:12:16] <SWPadnos> well, if you want the functionality to exist in HAL without EMC, then a separate component makes sense
[19:12:20] <cradek> (for FO specifically)
[19:12:46] <jmkasunich> well, I didn't realize halui already had it, I was gonna send the float into the adaptive feed input
[19:12:57] <jmkasunich> but I can use this for other things
[19:12:59] <SWPadnos> you don't want deltas in that case
[19:13:09] <jmkasunich> SWPadnos: why not?
[19:13:15] <SWPadnos> unless you're trying to jog through a program (poorly)
[19:13:31] <SWPadnos> because the delta output will be 0 (ie, stopped) unless the wheel is turning
[19:13:47] <jmkasunich> I'm not communicating what this things does very well
[19:13:55] <SWPadnos> heh :)
[19:14:18] <jmkasunich> have you used the newer scopes that have a wheel that can control cursors, or gains, or position, or .....
[19:14:37] <SWPadnos> aside from max and min, and assuming a scale of 1.0, what would the output be if the input changed from 100 to 101 ?
[19:14:53] <jmkasunich> it would be 1.0 higher than it used to be
[19:15:34] <SWPadnos> ah, so new_out = ld_out if ~enable, else new_out = old_out + scaled delta input counts
[19:15:41] <SWPadnos> s/ld_out/old_out/
[19:15:41] <jmkasunich> yes
[19:15:43] <SWPadnos> ok
[19:17:02] <SWPadnos> a single component is easier to wire, but for HAL it may be better to have a generic int->float converter (with scaling, offset, limits) and a separate "disable-able" counter
[19:17:27] <jmkasunich> this is better for several reasons (IMO)
[19:17:58] <jmkasunich> for example, I can have the scale large, use the knob to get close to the target, then change the scale to a much lower value to tweak
[19:18:16] <jmkasunich> can't do that with a generic converter, changing the scale with a non-zero input will make a step on the output
[19:18:42] <SWPadnos> ok. that's true
[19:18:56] <jmkasunich> basically this thing differentiates, then scales/enables, then integrates
[19:19:05] <jmkasunich> thats not the same as a simple scale
[19:19:15] <SWPadnos> nope
[19:19:42] <jmkasunich> that doesn't mean we shouldn't have a generic int/float converter
[19:19:44] <SWPadnos> well, we have an integrator already, so the trick is to have the scale/enable in the same component
[19:20:20] <SWPadnos> integer ddt -> disable-able scaler -> integrator would do it
[19:20:26] <SWPadnos> if you're into separate components :)
[19:20:36] <jmkasunich> reducing functions down to their simplest building blocks isn't a goal for me
[19:20:48] <SWPadnos> sure - only when useful
[19:20:57] <jmkasunich> its nice to have very simple blocks so a non-coder can build stuff the coders didn't think of
[19:21:04] <SWPadnos> I just wanted to understand why this way is better :)
[19:21:23] <jmkasunich> but if a slightly more complex block saves many lines in the hal file, I'm in favor of having both
[19:21:36] <SWPadnos> that makes sense
[19:21:56] <SWPadnos> another good place for hal "macros" or "bundles" ...
[19:21:58] <jmkasunich> for instance - a mux2 can be a sample/hold if you feed its output back to one input
[19:22:10] <jmkasunich> but a real sample/hold component is easier to use
[19:22:25] <SWPadnos> (marginally, with the net command ...)
[19:22:32] <jmkasunich> yeah, I'd love to be able to do some kind of macro or other heircharcal (sp) design thing
[19:22:41] <SWPadnos> heh - you never get that one right ;)
[19:22:52] <jmkasunich> true, the difference is marginal
[19:23:18] <SWPadnos> with net, all you have to do is add the input pin to the output net line
[19:23:24] <jmkasunich> but the sample/hold component is clearer to the guy who is reading the hal file later
[19:23:27] <SWPadnos> sure
[19:24:20] <SWPadnos> incidentally, "loadusr halcmd -f something" is a viable include facility for .hal files (in case you hadn't figured that out already)
[19:24:39] <jmkasunich> I hadn't
[19:24:53] <SWPadnos> oh. well now you know )
[19:24:55] <SWPadnos> :)
[19:25:29] <jmkasunich> true heirarchy won't happen unless we can come up with "local" namespaces
[19:25:58] <SWPadnos> that's true. that's an include thing rather than a topology change
[19:26:24] <jmkasunich> include alone has its uses
[19:27:09] <jmkasunich> being able to include something that implements an entire axis, then include it again for the next axis, is true heirarchy
[19:27:17] <SWPadnos> sure
[19:27:18] <SWPadnos> hmmm
[19:27:31] <jmkasunich> thats something for 2.3, or 2.4, or...
[19:27:31] <SWPadnos> that may be doable with small changes to halcmd
[19:27:34] <SWPadnos> sure
[19:28:12] <SWPadnos> since halcmd already has variable replacement, it's possible to add a command-line option to set some special name
[19:28:12] <jmkasunich> anyway.... naming this module, so I can commit it
[19:28:32] <jmkasunich> jog<anything> is too domain specific IMO
[19:28:35] <SWPadnos> use that name in the included file and you get something like that functionality
[19:28:35] <SWPadnos> ok
[19:28:57] <SWPadnos> discount (DISableable COUNTer) :)
[19:29:24] <jmkasunich> hmmmm......
[19:29:29] <jmkasunich> nah ;-)
[19:29:32] <SWPadnos> heh
[19:29:46] <jmkasunich> knob is tempting
[19:29:59] <jmkasunich> but sooner or later we'll wish it was more specific
[19:30:34] <SWPadnos> counter_with_pause ...
[19:31:00] <jmkasunich> and scale and limits ;-)
[19:31:16] <jmkasunich> besides, it doesn't do the counting
[19:31:29] <jmkasunich> you use an encoder counter (for SW counts) or a hardware counter and driver
[19:31:38] <SWPadnos> damn you! ;)
[19:31:55] <SWPadnos> oops - it's Sunday. darn you!
[19:32:11] <jmkasunich> I thought you were non-religious?
[19:32:14] <jmkasunich> hi Anders
[19:32:20] <SWPadnos> has it officially taken more time to name it than it did to write it now?
[19:32:20] <awallin> hi
[19:32:22] <SWPadnos> I am
[19:32:32] <SWPadnos> I'm being sensitive to anyone else who isn't
[19:32:33] <awallin> name what?
[19:32:39] <jmkasunich> getting there, but mostly because of digressions
[19:32:47] <jmkasunich> I just made a new component
[19:32:56] <jmkasunich> inspired (sort of) by your siggen vcp
[19:33:09] <SWPadnos> the component that does the following: "take an integer count, possibly add that to an internal counter, then scale, limit and output it as a float"
[19:33:36] <SWPadnos> int_to_float_en
[19:33:39] <jmkasunich> it takes a count (probably from an encoder connected to a knob that you can turn) and turns it into a float with upper and lower limits, scaling (one click of the knob = 0.0001, or 0.1, etc)
[19:33:40] <awallin> oh, what's it useful for? :)
[19:33:44] <SWPadnos> (integer to float, enableable)
[19:34:26] <jmkasunich> send the float to the frequency input of siggen, or the amplitude, etc
[19:34:48] <awallin> right.
[19:34:57] <jmkasunich> it has an enable, so you can actually have several of them hooked to one encoder, and you decide which one changes when you turn the knob
[19:35:25] <awallin> jmk: I thought about the params-> pins, and it will make for quite a long and possibly confusing list of pins
[19:35:32] <jmkasunich> so far its called "knob2float", but that seems so dull
[19:35:48] <awallin> so it would make sense to somehow label parameters
[19:35:59] <awallin> but at the same time I would like to link signals to parameters
[19:36:11] <alex_joni> awallin: right :)
[19:36:16] <jmkasunich> well, if you can link a signal to it, its a pin
[19:36:27] <jmkasunich> thats the definition of a pin ;-)
[19:36:33] <alex_joni> so maybe have parameters as pins, with a slight change in syntax
[19:36:45] <alex_joni> and they appear on a different list.. not sure why
[19:37:16] <awallin> just to make the list shorter, and better organized
[19:37:18] <jmkasunich> main and auxiliary pins?
[19:37:22] <jepler> there's "what should be saved by 'halcmd save'"
[19:37:33] <awallin> jmk: yes something like that
[19:37:50] <jepler> (it would also be nice if 'halcmd save' could know if a value was different from the default)
[19:38:13] <jmkasunich> jepler: and if same as default, don't bother saving it?
[19:38:19] <jepler> jmkasunich: yes, I think so
[19:38:21] <alex_joni> right
[19:38:32] <SWPadnos> that has to be an option
[19:38:37] <SWPadnos> the defaults can change
[19:38:58] <jmkasunich> the only reason for not saving them is to reduce the length of the output?
[19:39:07] <alex_joni> and make it easier to read
[19:39:09] <SWPadnos> also to improve readability
[19:39:34] <jmkasunich> without comments and in semi-random order, its _not_ going to be easy to read anyway
[19:39:52] <alex_joni> who uses halcmd save anyways? :)
[19:40:11] <jmkasunich> emc users don't
[19:40:23] <jmkasunich> people messing around with random HAL stuff might
[19:40:29] <alex_joni> the only use for it would be a halgui
[19:41:10] <jmkasunich> IMO any halgui should be focused on going FROM drawing TO halfile, not the other way around
[19:41:16] <alex_joni> I mean things you do manually to HAL, are also pretty easy to write to a file
[19:41:22] <alex_joni> or sort out from any save
[19:42:28] <jmkasunich> getting back to jeplers original point - if params become pins, save would have to save the following: 1) values of unconnected input pins (as setp commands) 2) values of signals that have no writers (as sets commands)
[19:43:03] <alex_joni> doesn't setp create a dummy signal and link it?
[19:43:15] <jmkasunich> no (at least I hope not)
[19:43:29] <alex_joni> * alex_joni can't remember
[19:43:42] <jmkasunich> every pin has space reserved as a dummy signal, and when the pin is first created, its linked to its own dummy signal
[19:43:44] <jepler> no, it writes into the dummy value field of the pin structure
[19:44:11] <jepler> what jmkasunich said
[19:44:17] <SWPadnos> does that get re-zeroed when a pin gets connected to a signal?
[19:44:28] <jmkasunich> when you link, the dummy retains whatever value it had
[19:44:42] <SWPadnos> ok, so it essentially sets a new default
[19:44:45] <alex_joni> so when you unlink you have the previous value?
[19:44:47] <jmkasunich> if you unlink the pin, it gets reconnected to the dummy, again with whatever value it had
[19:45:02] <alex_joni> ok
[19:45:14] <jmkasunich> the dummys come from the need to avoid checking for null pointers in the RT code
[19:45:24] <jmkasunich> that code can always assume the pin pointer points to _something_
[19:46:39] <SWPadnos> I guess the question is what's "correct" for an unconnected pin. setp just changes the default from 0 to something else
[19:47:11] <alex_joni> I think there are pins which don't default to 0
[19:47:19] <alex_joni> probably by assignment in the code though
[19:47:37] <alex_joni> like scale which is 1.0 afaik
[19:47:54] <jmkasunich> when a pin is created by a call to hal_<type>_pin_new(), the dummy is zeroed by hal_lib
[19:48:07] <jmkasunich> the component is free to set it to some other value itself immediately after the call
[19:48:29] <alex_joni> right.. so what would be the default value then?
[19:48:30] <CIA-8> 03jmkasunich 07HEAD * 10emc2/src/hal/components/knob2float.comp: new component - intended to allow a manual encoder (jogwheel) to be used to control any HAL float signal
[19:48:55] <alex_joni> I mean if halcmd checks to see if the value changed from the default, I don't see how it can check for the initial value
[19:48:56] <jmkasunich> what do you mean by "default"?
[19:49:04] <jmkasunich> oh, that
[19:49:17] <alex_joni> yeah, unless we provide an extra function in hal_lib
[19:49:27] <alex_joni> or we save all pins which are != 0
[19:49:32] <jmkasunich> IMO, having halcmd save not write things that didn't change from the default is a lot of work for marginal benefit
[19:50:14] <jmkasunich> saving all which are non-zero might bite you
[19:50:28] <alex_joni> me?
[19:50:54] <jmkasunich> a comp might set its default to non-zero, and the users sets it back to zero - that value wouldn't get saved, and when you reload, its at the non-zero default instead of what the user wanted
[19:51:11] <alex_joni> oh, right
[19:51:51] <SWPadnos> there's a more data-intensive way of doing it. add a "default" field to the pin structs (could be useful in other places as well), and then compare the two
[19:52:03] <SWPadnos> (and param structs, if params survive :) )
[19:52:44] <jmkasunich> in that case, you'd explicitly pass hal_pin_new the default value, and it would do the setting (set the default field, and copy that to the dummy field)
[19:52:53] <SWPadnos> yep
[19:53:10] <alex_joni> that wouldn't be too hard to code
[19:53:11] <SWPadnos> there would then be a way to reinitialize the HAL to default
[19:53:20] <SWPadnos> which could possibly be useful
[19:53:22] <jmkasunich> the problem with that change is that it would affect a crapload of calls to hal_pin_new
[19:53:56] <alex_joni> hal_pin_new_dv ?
[19:53:59] <SWPadnos> or leave hal_pin_new the same, and modify the (much fewer, Ithink) places where a pin is set to a non-default value
[19:54:34] <alex_joni> SWPadnos: right, have another function that does that
[19:54:37] <SWPadnos> params are already set manually (in general), so changing that to a parameter in the new_param call would likely be a reduction in code
[19:54:56] <SWPadnos> (damn. this is so C++, it's not funny)
[19:55:12] <alex_joni> ha
[19:55:31] <SWPadnos> if not for kernel/RT, HAL would be a perfect textbook case for C++
[19:55:59] <alex_joni> easy now, jmk will hear you :P
[19:56:08] <jmkasunich> too late
[19:56:29] <SWPadnos> incidentally, I noticed a couple of C++-style variable declarations in halcmd (declarations after code in a function)
[19:56:58] <cradek> c99 is 8 years old now...
[19:57:00] <jmkasunich> probably jepler
[19:57:18] <SWPadnos> ok - is that allowed in some regular C?
[19:57:17] <jmkasunich> cradek: just about getting broken in then...
[19:57:37] <SWPadnos> I thought there were compiler complaints on some of the farm systems
[19:58:00] <cradek> it is a problem with gcc2.x
[19:58:01] <jmkasunich> if I counted right, there are 540 calls to hal_pin_xxx_new in the source tree
[19:58:24] <jmkasunich> and 274 params
[19:58:56] <alex_joni> quite a few
[19:59:05] <SWPadnos> there shouldn't be any initializations of pins, since they can vary outside the components control
[19:59:31] <alex_joni> SWPadnos: some are I think
[19:59:35] <jmkasunich> true, its really the params that get initialized
[19:59:39] <SWPadnos> hmmm - outputs are an interesting case, though they don't need to be saved
[19:59:51] <alex_joni> like dac pins, those all default to 0
[19:59:56] <jmkasunich> which brings up something I noticed - comp lets you specify an initial value for a param but not a pin
[19:59:57] <SWPadnos> s/any/many/ :)
[20:00:28] <SWPadnos> hmmm - looks like I'm about to go out with my wife for a bit :)
[20:00:29] <jmkasunich> if we change all params to pins, we'll have to allow setting an initial value for pins
[20:00:30] <SWPadnos> bbl
[20:00:45] <jmkasunich> I have chores to do as well
[20:01:01] <jmkasunich> didn't mean for this to become a long discussion, I just wanted a name for the component
[20:01:05] <jmkasunich> ;-)
[20:01:06] <jepler> jmkasunich: that's not difficult to add, it would be 5 minutes to change comp to have defaults for pins
[20:01:43] <jmkasunich> would you be willing to do that now?
[20:02:01] <jepler> longer to document it :-P
[20:02:20] <alex_joni> def pin(name, type, dir, doc):
[20:02:35] <alex_joni> def pin(name, type, dir, doc, value): ?
[20:04:04] <jepler> a little bit more than that has to be changed
[20:04:12] <alex_joni> just saw that
[20:07:36] <CIA-8> 03jepler 07HEAD * 10emc2/src/hal/utils/scope_vert.c: change logic to get rid of unneeded goto
[20:07:50] <CIA-8> 03jepler 07HEAD * 10emc2/src/hal/utils/comp.g: allow default values for pins
[20:08:16] <jepler> ok so 5 minutes was a bit optimistic -- but I tested it too
[20:08:21] <jmkasunich> thank you
[20:09:24] <CIA-8> 03jepler 07HEAD * 10emc2/docs/src/hal/comp.lyx: document that pins may have starting values
[20:09:41] <alex_joni> it was 7 minutes
[20:10:03] <CIA-8> 03jepler 07HEAD * 10emc2/docs/src/hal/comp.lyx: markup fix
[20:10:42] <jmkasunich> I'm off to the grocery store...
[20:13:51] <fenn> i dont even understand how he types that fast
[20:14:47] <alex_joni> heh.. bet he uses 2 hands
[20:14:48] <alex_joni> :-P
[20:15:04] <fenn> * fenn pecks at the keyboard with his nose
[20:26:55] <awallin> jepler: do you know what the _hull attribute of a Tkinter widget is supposed to be?
[20:30:47] <jepler> awallin: no, that doesn't ring a bell
[20:30:54] <Jymmmm> Yo
[20:31:01] <jepler> hi Jymmmm
[20:31:23] <Jymmmm> hey jepler, how ya doin?
[20:31:25] <awallin> I'm trying a Pmw widget, but since pyvcp expects everything to be Tkinter widgets, it's not really working
[20:32:16] <jepler> Jymmmm: pretty good
[20:32:31] <jepler> awallin: yeah it looks like it's something pmw-specific
[20:33:14] <awallin> jepler: you mentioned a new driver on your page, is this something in addition to the pluto?
[20:33:34] <jepler> awallin: all the stuff for the pluto is in cvs
[20:33:49] <awallin> make: *** [objects/rtobjects/hal/components/knob2float.o] Error 1
[20:33:57] <awallin> HEAD seems to be broken...
[20:34:04] <alex_joni> awallin: jeff just added a new driver for a pci 8255 board
[20:34:16] <alex_joni> awallin: what's the error on that one?
[20:34:25] <awallin> Compiling realtime objects/hal/components/knob2float.c
[20:34:25] <awallin> hal/components/knob2float.comp:36: error: syntax error before ‘s32’
[20:34:40] <awallin> what's the spec for the 8255? url?
[20:34:57] <awallin> and a lot of more errors after that...
[20:35:48] <alex_joni> doesn't look like a syntax error to me
[20:36:17] <jepler> for awallin, 's32' isn't defined as a type
[20:36:26] <jepler> try changing it to say 'long' instead of 's32' in that line
[20:37:17] <awallin> hal/components/knob2float.comp:41: error: ‘s32’ undeclared (first use in this function)
[20:37:24] <alex_joni> hmm.. shouldn't comp translate s32 to hal_s32 ?
[20:37:32] <alex_joni> awallin: there are 2 s32 in that file
[20:38:16] <jepler> alex_joni: no, not after ";;"
[20:38:30] <jepler> alex_joni: there's a 'typedef long s32' available in the kernel headers, but not in the userspace headers
[20:38:32] <awallin> now it seems to be OK, I have doc building enabled, so it takes a while, but it doesn't error out directly
[20:38:41] <jepler> so those of us on sim machines .. get this error
[20:38:57] <alex_joni> ahh.. was wondering why jmk didn't catch it
[20:40:10] <awallin> now make runs cleanly, just some mandb warnings 'bogus filename'
[20:40:32] <awallin> should I commit the two s32->long changes?
[20:42:53] <awallin> ok so I did that.
[20:42:54] <CIA-8> 03awallin 07HEAD * 10emc2/src/hal/components/knob2float.comp:
[20:42:54] <CIA-8> changed two s32 variables to type long
[20:42:54] <CIA-8> won't compile with --enable-simulator otherwise
[20:45:48] <alex_joni> jepler: shouldn't that have been 'signed'?
[20:46:02] <alex_joni> token TYPE: "float|bit|signed|unsigned|u32|s32"
[20:46:08] <alex_joni> taken from comp.g
[21:03:17] <cradek> make[2]: *** No rule to make target `/home/chris/emc2.head/src/hal/drivers/pci_8255.o', needed by `/home/chris/emc2.head/src/abs.o'. Stop.
[21:04:05] <Jymmmm> Jymmmm is now known as Jymmm
[21:05:16] <awallin> after cvs up, I get make: Nothing to be done for `default'.
[21:05:54] <cradek> did something change that you think should recompile?
[21:06:17] <awallin> nope, just wondering where you got your error message from?
[21:06:47] <cradek> I cleaned and built for realtime
[21:07:38] <awallin> ok, so with --enable-simulator it doesn't compile any drivers
[21:07:48] <cradek> no, not hardware drivers
[21:09:14] <cradek> I think the problem is indecision about calling it 'hal_8255' or 'pci_8255'
[21:10:25] <jepler> oops, did I screw it up? I did the checkin from a machine without rt, but I did test it on my real machine
[21:11:02] <cradek> jepler: yeah, pretty sure it's screwed up
[21:11:12] <cradek> I was just fixing it - should I finish?
[21:11:57] <jepler> yes please
[21:12:01] <jepler> thank you
[21:12:06] <cradek> no problem
[21:12:26] <cradek> my realtime machine is so slooowwww...
[21:15:49] <CIA-8> 03cradek 07HEAD * 10emc2/src/ (Makefile Makefile.inc.in): fix some filenames
[21:17:48] <cradek> I wonder why the farm didn't catch that
[21:18:50] <jepler> there's a big red X on the web page
[21:18:58] <jepler> I wonder if the e-mailing part is broken again, and why
[21:19:23] <cradek> oh
[21:20:06] <CIA-8> 03jepler 07HEAD * 10emc2/tests/save.0/expected: update expected to match current (correct) behavior
[21:20:43] <CIA-8> 03jepler 07HEAD * 10emc2/src/hal/utils/comp.g: comp can now build userspace components
[21:22:33] <alex_joni> hmm.. the BDI slot didn't build at all
[21:22:59] <cradek> I tink he was experimenting with suspending the VMs - maybe it's broken
[21:23:17] <cradek> curse you, kbuild
[21:24:14] <anonimasu> hm
[21:24:27] <anonimasu> hm, I have a problem with jogging..
[21:24:49] <anonimasu> when I jog Z and X the Z seems to go too fast..
[21:24:54] <anonimasu> err it starts to miss steps.
[21:25:15] <anonimasu> and I have no idea why, as it should be limited in the config..
[21:27:46] <anonimasu> it dosent happen on rapids..
[21:27:50] <anonimasu> but on g28's..
[21:30:19] <cradek> is your axis vel or accel set higher than the traj vel or accel?
[21:30:49] <cradek> no, that wouldn't do it either
[21:31:04] <cradek> hmm, or maybe it would
[21:33:15] <cradek> I dunno
[21:33:29] <cradek> debug, and then come back with more data :-)
[21:34:30] <alex_joni> at least paste the ini to pastebin.ca
[21:34:57] <jmkasunich> I'm back
[21:35:08] <jmkasunich> that fsckin shared library problem again
[21:35:27] <jmkasunich> (I rebooted the VMs yesterday, I wonder if that broke it)
[21:35:49] <alex_joni> the BDI doesn't build, the other build but don't email
[21:35:59] <jmkasunich> and the BDI VM isn't even running - I could swear I started it yesterday
[21:40:37] <jmkasunich> I did restart it yesterday
[21:40:46] <anonimasu> cradek: it's not..
[21:40:49] <anonimasu> cradek: it's set lower..
[21:41:14] <anonimasu> the box is off right now, but the max_vel and accel is set correctly..
[21:41:17] <anonimasu> it's very odd..
[21:42:17] <anonimasu> cradek: it never occurs on rapids or stuff like htat either..
[21:42:22] <jmkasunich> whatever killed the BDI VM happened within 30 mins of when I started it - the system logger puts "MARK" in the log every 30 mins, and there isn't one between yesterdays power up and todays
[21:43:53] <alex_joni> odd
[21:50:05] <daniel_br> hi guys, are there a hal pin for adjust in realtime (based in a feedback)the tool diameter compensation?
[21:50:08] <CIA-8> 03jepler 07HEAD * 10emc2/src/rtapi/sim_common.h: put error messages back on stderr, accidentally changed when rtapi_set_msg_handler was implemented
[21:51:28] <jepler> daniel_br: no. you can only adjust the tool diameter between runs, by reloading the tool table.
[21:52:28] <CIA-8> 03jepler 07HEAD * 10emc2/src/hal/utils/comp.g:
[21:52:28] <CIA-8> improve manpage for userspace components
[21:52:28] <CIA-8> use options.get("xxx") instead of slightly longer options.get("xxx", 0) when the default is a false value
[21:53:04] <CIA-8> 03jepler 07HEAD * 10emc2/docs/src/hal/ (rand.comp comp.lyx): document how to do userspace components.
[21:53:14] <daniel_br> is possible create a pin for do that?
[21:53:16] <eholmgren> haha ..
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=7554239297&ssPageName=MERC_VI_RSCC_Pr12_PcY_BIN_Stores_IT&refitem=330030386782&itemcount=12&refwidgetloc=active_view_item&usedrule1=StoreCatToStoreCat&refwidgettype=cross_promot_widget
[21:53:31] <eholmgren> just in case you need to throw a caliper on something 80" wide
[21:54:01] <alex_joni> eholmgren: I saw a 5m long one recently
[21:54:21] <jepler> daniel_br: it is not trivial to do. Right now it is assumed that the tool diameter is taken from the tool table, and does not vary as the program runs.
[21:54:23] <eholmgren> does it take two people to operate it? ;)
[21:54:31] <alex_joni> eholmgren: at least
[21:55:10] <jmkasunich> eholmgren: and a third to read the thermometer
[21:55:15] <anonimasu> hm
[21:55:50] <daniel_br> i'm thinking about use a spindle current(amperage sensing) for generate some pwm signal and use some hardware input for feed this in one hal pin
[21:55:58] <awallin> jmk: don't you have a temperature stabilized workshop? ;)
[21:56:19] <jmkasunich> I wish
[21:56:28] <jmkasunich> my mill is in an unheated detached garage
[21:56:51] <awallin> daniel: that's doable
[21:57:09] <daniel_br> Good, think about some machining center for cut and polish glass
[21:57:40] <daniel_br> for a good polish you need such adjust
[21:58:01] <anonimasu> daniel_br: dont you face the wheel and then adjust the tool diameter?
[21:58:02] <awallin> so the spindle current would control feedrate ?
[21:58:25] <anonimasu> daniel_br: or adaptive feed?
[21:58:40] <daniel_br> no adjust the tool diameter compensation
[21:59:11] <awallin> that's harder, like jepler said before.
[21:59:17] <alex_joni> good night all
[21:59:23] <awallin> bye alex
[21:59:40] <daniel_br> gn alex
[21:59:43] <awallin> daniel: can you show a pic of the machinig geometry?
[22:00:18] <daniel_br> this is a 3 axis machininc center with automatic tool changer
[22:00:59] <daniel_br> first the machine use some diamond toll for cut
[22:01:54] <daniel_br> and and after that use some rubber tool for polish
[22:02:35] <anonimasu> why not make it face 0.00X and then substract that from the tool table..
[22:02:36] <daniel_br> for cut glass tables
[22:02:46] <awallin> can you let the spindle current control just the Z-axis?
[22:04:50] <daniel_br> for a straigth cut this can work but not for a interpoled one
[22:09:23] <anonimasu> hm, your problem seems to be defining what you really want..
[22:10:10] <daniel_br> yes, but I don't have programing skills for do that
[22:10:23] <anonimasu> well, maybe you should write what you need down..
[22:10:54] <anonimasu> err write down what you need...
[22:10:57] <anonimasu> first of all
[22:12:05] <daniel_br> I need a float hal pin that can change in real time the tool diameter used in a g42
[22:14:05] <anonimasu> daniel_br: how can you get your tool diameter?
[22:15:57] <daniel_br> i think about somethink like feedoverradi adjust in EDM
[22:17:33] <anonimasu> feed override?
[22:17:33] <daniel_br> in this case one analog feedback can adjust that tool diameter based in the spindle current
[22:17:49] <awallin> but in emc, tool radius compensation is handled by the interpreter (I think), which does not run in realtime
[22:18:21] <daniel_br> this is a problem
[22:18:22] <awallin> feed override on the other hand, is handled by the trajectory controller, which runs in realtime, so changing feed-override in realtime is easy
[22:18:29] <anonimasu> yeah
[22:18:36] <anonimasu> awallin: that's correct
[22:19:01] <daniel_br> so is this impossible?
[22:19:16] <anonimasu> right now, it is..
[22:19:25] <anonimasu> daniel_br: is it possible to have a macro tweak your code?
[22:19:43] <anonimasu> something like python/something
[22:20:13] <daniel_br> i don't know how do this
[22:21:02] <anonimasu> me neither, and I have no idea where you are supposed to get your tool dia from either :/
[22:22:02] <daniel_br> this is for some future project, time for read and think more about this
[22:22:19] <anonimasu> daniel_br: it's possible somehow..
[22:22:25] <daniel_br> thanks anonimasu and awallin
[22:22:26] <anonimasu> daniel_br: I'd make a pass, check my tool dia..
[22:22:37] <awallin> daniel: for someone to help you, please write down clearly what you want, with pictures, in the wiki!
[22:22:52] <anonimasu> then call a macro to read tool dia and tweak and then reload the tool table..
[22:23:06] <daniel_br> ok, iwill try do that
[22:23:08] <anonimasu> and do your finish pass..
[22:24:10] <daniel_br> dinner time here, a salmon waiting for me!
[22:24:18] <anonimasu> enjoy
[22:24:30] <daniel_br> good nigth and thanks
[22:24:36] <anonimasu> good night..
[22:24:42] <anonimasu> hope you fins a solution to it
[22:24:43] <awallin> bye
[22:28:50] <awallin> hi goslow
[22:29:47] <Goslowjimbo> I found a IDE named ERIC which will change Qt3 files to XML files (I think). Could this be used with PyVCP to create GUIs for HAL?
[22:30:01] <Goslowjimbo> awallin: hi
[22:30:54] <Goslowjimbo> It uses PyQt
[22:31:18] <awallin> goslow: no idea, the format of the pyvcp xml file is pretty much my own idea, not any standard
[22:31:28] <awallin> why would you want this?
[22:32:32] <Goslowjimbo> I have tried to get a DRO with numbers big enough for old eyes to easily see in an oily environment. ie: about 1/3 the size of the screen.
[22:32:44] <anonimasu> :)
[22:33:01] <Goslowjimbo> I can't seem to do that in PyVCP
[22:33:43] <awallin> it should be easy, inside <number> put <font>('Helvetica',40)</font> or some bigger number than 40
[22:34:33] <Goslowjimbo> I get to about 80 and it stops getting any bigger.
[22:35:11] <awallin> oh, OK...
[22:35:27] <awallin> what size screen are you running and at what resolution?
[22:36:15] <jmkasunich> 80 point text is pretty darned big
[22:37:18] <Goslowjimbo> I'm not sure how to find resolution, I know it's pretty high. It's an 18" screen
[22:38:04] <jmkasunich> you running ubuntu?
[22:38:12] <Goslowjimbo> Yes
[22:38:39] <jmkasunich> from the main menu, System->preferences->screen resolutuin
[22:38:44] <jmkasunich> will tell you what you have
[22:39:07] <Goslowjimbo> 1280X 1024. Thanks
[22:40:13] <awallin> try lowering that number, see what happens to the text size
[22:40:30] <Goslowjimbo> Lowering the resolution?
[22:40:58] <awallin> yes, set it to 1024x768
[22:42:03] <Goslowjimbo> It'll take a while for me to get set back up. Wow, it seems like everyone is yelling :)
[22:44:30] <awallin> so did it make the numbers appear bigger?
[22:45:41] <Goslowjimbo> I haven't got it to work, yet. I am sure it will be bigger as everything else is. Whether it's big enough for the display, I will find out.
[22:46:18] <anonimasu> :)
[22:46:41] <Goslowjimbo> For some reason, pyvcp is failing on me
[22:48:51] <awallin> what are you trying? what does it say?
[22:50:07] <Goslowjimbo> bin/halcmd -f pyvcp-dro.hal, HAL:20: ERROR: execv(pyvcp) failed
[22:50:07] <Goslowjimbo> HAL:20: ERROR: program 'pyvcp' failed, returned 1
[22:51:31] <awallin> check the line which calls pyvcp, it should read "pyvcp -c pyvcp myfile.xml (where myfile.xml is your XML file)
[22:51:50] <awallin> if you are using the file jmk posted on the list a while ago, I changed they syntax just after that :)
[22:52:19] <awallin> you could pastebin your hal file and your dro file if you want
[22:52:26] <Goslowjimbo> Right. I caught that and changed it also.
[22:52:56] <awallin> try pyvcp on its own: pyvcp -c pyvcp myfile.xml and see what that says
[22:54:33] <Goslowjimbo> Command not found. Do I need to be in a certain directory? I'm in emc2-head
[22:55:15] <awallin> in that directory, run: . scripts/emc-environment (note the dot and the space) then try again
[22:55:27] <awallin> you should be in the directory where your xml file is
[22:59:15] <awallin> you are right, I tried the bigger fonts, and it doesn't really work beyond 40-50 or so...
[23:00:22] <jepler> now I wonder if I added the right file for the '8255 card or not
[23:01:27] <awallin> jepler: did you have an url that describes the 8255
[23:01:29] <awallin> ?
[23:01:44] <jepler> http://www.futurlec.com/PCI8255.shtml
[23:01:54] <awallin> thanks
[23:02:13] <jepler> it's a dumb digital I/O card based on the old 82c55 chip and a pci bridge
[23:02:41] <awallin> so it can't do on-board encoder counting, or pwm generation ?
[23:02:45] <jepler> no, nothign like that
[23:02:49] <awallin> ok
[23:02:55] <cradek> at base period speeds...
[23:02:56] <jepler> it's more like 3 parports on a PCI card
[23:03:04] <jepler> but with a different pinout
[23:03:38] <cradek> one of these days I'll use one for software step generation for a little robot arm I have
[23:03:48] <cradek> phase drive actually, not step
[23:06:08] <jepler> once I'm done with the driver, you can have this card
[23:06:16] <jepler> that is, if skunkworks doesn't want it back
[23:07:07] <cradek> cool
[23:07:31] <cradek> would it be about as fast as a parport?
[23:08:22] <jepler> I think it may be a bit faster but I don't remember the timings
[23:08:46] <jepler> the documentation implies a write would take 16 PCI clocks, and it's 9 writes to update all the outputs.
[23:08:55] <cradek> plenty fast then
[23:09:50] <awallin> goslow really is quite slow....
[23:11:00] <awallin> but he pointed out that the font=xxx argument for a tkinter widget doesn't really work beyond fontsize about 50
[23:11:17] <jepler> the font becomes "blocky"?
[23:11:18] <awallin> which is too small for a full-screen DRO application
[23:11:32] <awallin> no. it just doesn't get any bigger
[23:11:42] <jepler> that surprises me.
[23:12:57] <awallin> although it might be a limitation of the specific font, helvetica?
[23:13:28] <awallin> Roman, Arial work the same
[23:14:42] <awallin> pack(expand=1) doesn't help either
[23:15:38] <jepler> on my system (fedora, so it may not appliy to Ubuntu), "helvetica' and "lucida" do have a maximum size. "times new roman" goes up to 300 pixels just fine.
[23:16:02] <jsr_> I'll try that
[23:16:16] <jmkasunich> awallin: see, you are spoiling people.... the orignal VCP had one font and one size.... did you hear any complaints? ;-)
[23:16:34] <anonimasu> lol
[23:16:43] <awallin> ;)
[23:16:57] <jepler> the font "courier 10 pitch" also works at large sizes
[23:17:08] <awallin> jepler: font=('times new roman',400) does not help over here (Ubuntu 6.06)
[23:19:05] <awallin> jepler: thanks, "courier 10 pitch" goes atleast to 150-200 on my system. goslow: did you hear that? put replace your font tags with <font>('courier 10 pitch',150)</font>
[23:19:17] <jepler> I think he left :(
[23:19:22] <awallin> I guess this depends on what X fonts are installed?
[23:19:27] <jepler> awallin: probably so
[23:19:49] <awallin> I'll post a message to the list
[23:24:03] <Goslowjimbo> At 1024 X 768 resolution, a times new roman of 300 pixels comes out between 1/4" and 1/2"
[23:24:51] <awallin> goslow: try this <font>('courier 10 pitch',200)</font>
[23:25:22] <Goslowjimbo> Ok.
[23:29:51] <Goslowjimbo> Wow, that's almost 2 inches! I'll have to change back to a higher resolution because they overlap on the screen
[23:30:28] <awallin> glad it works!
[23:31:03] <Goslowjimbo> I love it! Thanks.
[23:33:12] <awallin> glad I could help.
[23:34:23] <awallin> if and when you get the encoders hooked up and have a fully working DRO I bet many others would also be interested, so please post your .xml and .hal files on the wiki
[23:36:14] <Goslowjimbo> wiki?
[23:36:45] <awallin> the wiki is at wiki.linuxcnc.org a website that anyone can/should edit
[23:37:01] <awallin> but you can also post your experiences and files(if they are small) to the mailing list
[23:41:29] <awallin> I'm going to sleep now, bye all
[23:41:54] <Goslowjimbo> bye