04:20:13 <SWP_Away> cradek, that was kind of an engrish commit message ;)
04:37:50 <cradek> no kidding
04:38:09 <cradek> it's sort of like what I meant to type
04:38:16 <cradek> it's kind of late...
04:38:41 <SWP_Away> ah well
04:38:57 <cradek> meant to ask skunkworks about that bug, but I missed him
04:38:59 <SWP_Away> what did you mean to say?  I haven't gotten the commit message yet
04:39:00 <cradek> maybe tomorrow
04:39:30 <cradek> I think this needs to work (i.e. this bug should be fixed and the report closed)
04:39:35 <SWP_Away> ah
04:39:48 <cradek> for emc-2.0 release
04:39:49 <SWP_Away> that's the differing max vel/accel
04:39:55 <SWP_Away> ?
04:39:56 <cradek> accel
04:40:04 <cradek> I already fixed vel a week ago
04:40:08 <SWP_Away> right
04:40:15 <cradek> I think accel is a whole new ball game
04:40:28 <cradek> I'll have to study it some more
04:40:37 <SWP_Away> probably, though it may be as simple as making sure the axis values are loaded (ha!)
04:40:58 <cradek> I don't think it's that simple
04:41:02 <SWP_Away> nope
04:41:04 <cradek> I think there is lots of code missing
04:41:22 <SWP_Away> hey - I have an off-topic question for you
04:41:27 <cradek> shoot
04:41:53 <SWP_Away> do you know how to find out when a USB->Serial cihp is unplugged (specifically the FT245BM)
04:42:11 <cradek> no
04:42:27 <SWP_Away> I have a program that uses threaded IO (which I don't really understand on Windows), and if I unplug the G-Rex, the software goes haywire
04:42:29 <SWP_Away> oh well
04:42:42 <cradek> I especially don't know about windows
04:42:49 <SWP_Away> yeah - jus tlike the rest of the world
04:42:56 <cradek> maybe it should initiate a reboot when you unplug it
04:43:10 <cradek> sorry, troll
04:43:26 <SWP_Away> the software just gets some garbage - probably because it's asking a drivet that's no longer in memory for information
04:43:31 <SWP_Away> driver
04:43:45 <SWP_Away> actually - rebooting may happen on Win98 - I haven't bothered to check that ;)
04:43:51 <cradek> in unix you would expect read/write to fail and set errno
04:43:55 <cradek> probably to EIO
04:44:21 <SWP_Away> there may be an error - it's juat a real PITA to figure out what the hell it is (also harder due to the multi-threaded nature)
04:44:41 <cradek> sorry, no clue here
04:44:54 <SWP_Away> same here ;)  thanks anyway
04:45:20 <cradek> np
04:45:36 <SWP_Away> I wish Mariss had connected more pins to the FPGA - a 16-byte address window just isn't enough for a 6-axis controller
04:45:59 <SWP_Away> +16 Din/16 Dout/4AIn/4AOut
13:02:27 <alex_joni> alex_joni has joined #emc-devel
13:35:29 <A-L-P-H-A> A-L-P-H-A has joined #emc-devel
13:35:41 <A-L-P-H-A> developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer!
13:35:41 <A-L-P-H-A> developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer! developer!
13:35:43 <A-L-P-H-A> :)
13:35:56 <A-L-P-H-A> courtesy of Steve Ballmer. :)
13:35:57 <A-L-P-H-A> A-L-P-H-A has left #emc-devel
13:36:19 <alex_joni> what?
14:08:02 <lerman> lerman has joined #emc-devel
14:46:05 <rayh> rayh has joined #emc-devel
15:34:25 <alex_joni> alex_joni has quit
15:35:06 <rayh> will this work -- loadrt hal_parport cfg="[EMCMOT]IO_BASE_ADDRESS"
15:52:33 <rayh> Looks like it does not.
17:49:33 <rayh> also tried a loadrt in the ini section but it reads hal files first so can't do that either.]
17:52:31 <SWPadnos> I considered adding "token replacement" for ini vars - so you could do things like [HAL]DRIVER.0.stepgen.maxoutput=[AXIS_0]STEPGEN_MAXVEL
17:52:42 <SWPadnos> where [HAL]DRIVER=ppmc
17:53:04 <SWPadnos> I'd need to get with jmk on how he'd like it to behave though
17:59:10 <rayh> That would work.
17:59:33 <SWPadnos> yep - take a page from tcl - everything's a string until you need to interpret it ;)
17:59:47 <rayh> Hi.
17:59:58 <SWPadnos> hi
18:01:04 <rayh> I was considering a univstep_load.hal file.
18:01:15 <rayh> and putting all the load and add commands in it.
18:01:35 <SWPadnos> yep
18:01:50 <rayh> I'll try that here and see how it goes.
18:01:54 <SWPadnos> that's basically what ppmc_motion.hal is
18:02:31 <SWPadnos> though there was confusion as to whether the load/addf should be in *_motion or *_io, so a separate file probably makes sense
18:09:57 <rayh> I'll add the scope rt in there also.
18:12:38 <rayh> I've not tried the halcmd save thing.  Does it save param values?
18:13:59 <SWP_Away> it saves everything, which can be a bit big ;)
18:16:41 <rayh> Ok I'm going to try that after a bit.
18:17:13 <SWP_Away> it's good to get a base  from which to extract the important stuff
18:17:27 <SWP_Away> I think it doesn't save loadrt though
18:45:12 <rayh> No they don't and you can not reload using halcmd -f "filename" if there are any loadrt commands in the file you want to try.
18:45:31 <rayh> Okay.  I've got a univstep_load.hal running.
18:45:47 <rayh> and removed the loadrt and addf commands from individual hal files.
18:45:58 <SWP_Away> right - that's partly a problem with threads and the like - loadrt threads lets you make up to 3 threads, then you unload and load again if you want more
18:49:57 <rayh> I'm reading the hal doc but halcmd save confuses me.
18:50:08 <SWP_Away> how so?
18:50:09 <rayh> it says that it saves to standard out.
18:50:25 <SWP_Away> yep - prints to the screen, so use halcmd save > myfile
18:50:38 <rayh> thanks
18:50:44 <SWP_Away> np
18:50:50 <SWP_Away> I like the easy ones ;)
18:51:07 <rayh> and I don't think in that many levels at once.
18:51:12 <SWP_Away> heh
18:54:24 <rayh> and I've got a mysave.hal.  whoho!
18:54:52 <SWP_Away> yeah!
18:55:01 <SWP_Away> and it's probably 6x as big as you want ;)
18:55:19 <rayh> Wow.  That single file is a lot easier for me to read than the individual ones.
18:55:42 <SWP_Away> yep - there's a lot of info, but it's a good base from which to make a config
18:56:39 <SWP_Away> I've been wondering about this xyz_io.hal and xyz_motion.hal (+xys_core+core_servo+...) thing
18:56:53 <rayh> Now I can reload it while emc is running.
18:57:05 <SWP_Away> if we're not going to have core files loaded from a common dir, then there's not much need to separate the functions out
18:57:30 <rayh> If you are reading a hal file.
18:57:43 <rayh> It makes sense to create a sig
18:58:11 <rayh> connect it to where it is changed from
18:58:17 <SWP_Away> oh yeah - for params, it's a great thing - change the file, then halcmd -f
18:58:22 <rayh> connect it to where it goes
18:58:43 <rayh> but here with the save file
18:58:48 <rayh> it lists all sigs
18:58:57 <rayh> then pins then params
18:59:04 <rayh> and such but I like it a lot.
18:59:09 <SWP_Away> I thought you could do those separately
18:59:22 <SWP_Away> halcmd save param or the like
18:59:24 <rayh> Yes you could write separate files for each
18:59:44 <SWP_Away> no - just use >> to concatenate the parts you cant into one file
18:59:48 <rayh> but if we are building a configuration script it tickle why would we.
19:00:03 <SWP_Away> s/cant/want/
19:00:40 <SWP_Away> maybe I should make save obey the -s option, and add script-friendly headers to the sections
19:00:52 <SWP_Away> like [PARAMS]
19:02:26 <rayh> If we list in tickle all the available pins
19:02:37 <rayh> then click to link
19:02:43 <rayh> then save
19:02:54 <rayh> we will have a configuration program.
19:03:15 <SWP_Away> true enough
19:03:34 <rayh> the saved file will not be pretty but it doesn't need to be cause we never see it.
19:03:48 <SWP_Away> right
19:04:15 <SWP_Away> the params are easy to do that way, since there's no "state" associated with them (you can change them any time)
19:04:31 <rayh> sure.
19:04:41 <SWP_Away> signals are a little more annoying, since the sigs have to be created first, then have pins connected
19:04:47 <SWP_Away> also not a biggie, but slightly worse
19:05:12 <SWP_Away> and of course, all the components have to be loaded (with the right parameters) before you can do anything ;)
19:05:22 <rayh> sure.  I can see that
19:06:18 <SWP_Away> with the refactor (or some other change), it'll be possible to load a component,. then add parts to it later (like "oops - I need another PID")
19:06:23 <rayh> If we were able to start emc with no loaded components other than the emc ones -- motmod and iocontrol --
19:06:44 <rayh> and we made a listing of what other mods are available from rtlib
19:07:07 <rayh> we could click and load, then look at the pins available
19:07:11 <SWP_Away> yep - you can have a loader, but you don;t know what the possible load-time parameters are
19:07:23 <SWP_Away> like blocks - it needs a lot of config options
19:07:40 <rayh> we will need to supply this info from the tickle
19:08:33 <rayh> The same sort of thing is true of say the parport module
19:08:34 <SWP_Away> that's a maintenance problem - there would need to be a way of telling tcl what options are available, and what the ranges are (like "blocks can create up to 8 and2, 16 sum2, ...)
19:08:50 <SWP_Away> wihtout changing the tcl scripts, preferably
19:08:56 <rayh> cfg="378 278 in"
19:09:27 <SWP_Away> right - it would be difficult to keep track of all those options in the tcl scripts
19:09:34 <rayh> Long ago I wrote an ini configuration thing that read a docs/xxx file.
19:09:56 <rayh> perhaps we should read the docs/man file for the relevant module.
19:10:13 <rayh> it would require that we make those man pages
19:10:25 <SWP_Away> there may be a way of seeing what options are available using some system tools - the cmd-line options are exported as MODULE_PARMs
19:10:46 <SWP_Away> but it won't tell you what the meanings are - only the name and type
19:10:49 <rayh> ah.  that would be handy
19:11:08 <SWP_Away> so all those modules that use a string names cfg won't be too informative
19:11:17 <SWP_Away> s/names/named/
19:12:27 <rayh> the man pages would be better I think.
19:13:12 <SWP_Away> yes, but it's still a maintenance hassle - incorrect manpages would result in an incorrect configurator
19:13:28 <rayh> sure
19:13:54 <rayh> but can we make each module report to us what it needs if we ask it nicely.
19:14:03 <SWP_Away> it would be better to make some kind of file that the modules use to generate their config parser, and then create a file for the config scripts from the same file
19:14:10 <SWP_Away> yes - that would be a good thing
19:14:42 <rayh> something like "parport info"
19:14:47 <SWP_Away> right
19:14:59 <SWP_Away> though that would be "icky" in kernel code ;)
19:15:23 <rayh> and it just returns a string that we would parse and make pretty in tickle
19:15:48 <SWP_Away> tht's easy for parport, but not for blocks
19:16:05 <SWP_Away> maybe that tells us that blocks should be split into several modules
19:16:53 <rayh> I leave that issue to the architects.
19:16:58 <SWP_Away> heh
19:53:05 <rayh> Starting emc...
19:53:06 <rayh> HAL: ERROR: function 'ddt.1' is not reentrant
19:53:06 <rayh> HAL config file /home/rayh/emcdevelop/emc2/configs/univstep/univstep_save.hal failed.
19:53:42 <rayh> got these when I tried to restart univstep with only the load and save hal files.
19:53:57 <SWP_Away> odd
19:54:33 <SWP_Away> it sounds like the function was being added to multiple threads, which isn't allowed with non-reentrant functions
19:55:49 <rayh> ah thanks.  I had the addf in load as well as save.
19:55:51 <alex_joni> alex_joni has joined #emc-devel
19:59:42 <rayh> okay pulled all the addf's from load but get this now.
20:00:03 <rayh> HAL: ERROR: function 'motion-command-handler' is not reentrant
20:00:34 <SWP_Away> are you reloading the motion component?
20:00:37 <alex_joni> probably added it twice
20:00:49 <alex_joni> hello
20:00:51 <SWP_Away> hi
20:01:28 <rayh> alex I'm playing again.
20:01:38 <alex_joni> yeah, I figured :D
20:01:50 <rayh> tried a halcmd save command
20:01:51 <alex_joni> if something's broken.. ray is playing :D
20:01:59 <alex_joni> you know I'm kidding..
20:02:11 <rayh> I think you got me figured out.
20:02:34 <SWP_Away> just - don't commit to CVS ;)
20:03:15 <alex_joni> SWP_Away: why not? that surely makes our life interesting :D
20:03:27 <rayh> I don't see where the motion-command-handler gets added to a thread.
20:03:29 <SWP_Away> our - what's this our?  :)
20:03:50 <SWP_Away> motion-command-handler adds 3 threads, and puts itself into the servo thread
20:03:55 <SWP_Away> motion, I mean
20:03:59 <alex_joni> SWP_Away: that mean me, and a few others, called developers.. maybe you'll join us some day
20:04:01 <alex_joni> :P
20:04:05 <rayh> I wonder if it's hard coded into itself.
20:04:16 <SWP_Away> maybe, but don't count on it ;)
20:04:19 <alex_joni> rayh: when you load the motion module it creates the threads
20:04:21 <SWP_Away> it is hard-coded
20:04:36 <alex_joni> what SWP_Away said
20:04:57 <alex_joni> huh, I actually agreed with him ;) that's new...
20:05:03 <rayh> so we can not use the save file as long as it contains.
20:05:12 <rayh> addf's
20:05:35 <SWP_Away> no - motion and io do some stuff on their own, other components and drivers don't (at this point)
20:05:42 <alex_joni> you can, but can't run it without restarting hal and realtime
20:05:47 <SWP_Away> right
20:06:13 <rayh> so the easy solution is to pass specific things to save and make addf not one of them.
20:06:42 <SWP_Away> no - it has nothing to do with addf - it's motion and io that are the problem (I think)
20:06:46 <alex_joni> I think easy solution is to change only params, and signals
20:06:57 <alex_joni> everything bigger might require restart
20:07:03 <SWP_Away> but - you have to delf each function, or remove the component first
20:07:28 <alex_joni> SWP_Away: you still end up with threads, which you can't delete
20:07:35 <rayh> I'd really like to get away from restart
20:07:36 <SWP_Away> you can't reload an already loaded component, so as long as you unload everything (other than io and motion), you should be OK
20:07:37 <SWP_Away> true
20:07:52 <rayh> cause it's gonna get in the way of configuration.
20:08:41 <SWP_Away> it will only matter for things that are in the [MOTION] and [IO] sections of the ini
20:09:05 <SWP_Away> so if you wanted to change motion controllers, you'd have a problem (or even changing the thread period)
20:09:28 <rayh> otoh we can't change any of the things in the ini like ferror or min_ferror either.
20:10:08 <SWP_Away> true - those should be made into params anyway
20:10:30 <rayh> some of them are but you can't write them.
20:10:47 <SWP_Away> yes - they should be externally settable params
20:11:21 <SWP_Away> that's one of the things I considered changing in the near future, but I may just get rid of the ini dump instead ;)  (at least for the initial release)
20:11:49 <rayh> I don't really care about changing thread timing for motmod or iocontrol
20:12:15 <rayh> I'd rather get a functioning save of a system that a person has configured while running.
20:13:16 <rayh> We had some of that ability in emc(1)
20:13:47 <rayh> could change PID and deadband, and such in the configuration
20:13:51 <SWP_Away> yep - though automatically saving isn't necessarily the answer
20:13:55 <rayh> and it would be saved on shutdown.
20:14:05 <rayh> Right.
20:14:09 <SWP_Away> yep - but if you screwed up a working machine, that wouldn't be desirable
20:14:25 <SWP_Away> so the automatic ini dump isn't necessary any more
20:14:43 <SWP_Away> (and all it does is annoy people when their values get reset to default every run)
20:15:09 <rayh> If you can not change any of the ini variables while running, then there is no value to writing it on shutdown.
20:15:27 <rayh> But the issue remains, how do we save a running configuration.
20:15:29 <SWP_Away> right - though the values may still be settable via nml (I'm not sure)
20:15:47 <SWP_Away> for params and signal connections, halcmd save is fine
20:16:11 <SWP_Away> threads, since they're persistent, can't be changed during a run (ie, you can't restart a thread)
20:16:16 <rayh> changing a global variable like PID does not make a change in HAL
20:16:36 <SWP_Away> no - PID doesn't go to motion, but FEROR might
20:16:44 <SWP_Away> I'm not sure if that was ever settable
20:17:44 <SWP_Away> (while running)
20:17:58 <alex_joni> PID was settable I think
20:18:11 <alex_joni> but this whole mess might be worked around if the values weren't in the ini
20:18:18 <alex_joni> or the halcmd save writes to the ini ;)
20:18:20 <SWP_Away> PID yes, but I'm wondering about FERROR
20:19:15 <rayh> One thing I noticed in xxx_save.hal is that we loose the reads of params from the ini.
20:19:25 <rayh> This is probably a good thing.
20:19:34 <rayh> for a stable configuration.
20:19:35 <SWP_Away> yes - it's a dump of the current settings, not a list of where the settings come from
20:19:55 <SWP_Away> the dump file would replace the ini
20:25:41 <rayh> parts of it anyway.
20:43:28 <alex_joni> alex_joni has quit
20:57:58 <rayh> rayh has quit
22:16:15 <logger_devel> logger_devel has joined #emc-devel
22:16:15 <zelazny.freenode.net> topic is: "Welcome to the Enhanced Machine Control development place. | Regular Developers' meetings 24/7 !"
22:16:15 <zelazny.freenode.net> Users on #emc-devel: logger_devel lerman anonimasu LawrenceG SWP_Away cradek SWPadnos @ChanServ