Back
[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: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:36:19] <alex_joni> what?
[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: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.