Back
[00:36:47] <petev> * petev is away: eating
[00:41:31] <jmk_eating> jmk_eating is now known as jmkasunich
[01:00:07] <petev> * petev is back
[01:00:20] <alex_joni> you eat less than jmk
[01:00:27] <petev> yeah
[01:00:29] <alex_joni> [01:25] * jmkasunich is now known as jmk_eating
[01:00:30] <alex_joni> [01:26] * SWPadnos is now known as SWP_Away
[01:00:30] <alex_joni> [01:42] * petev has joined #emc-devel
[01:00:30] <alex_joni> [02:36] * petev is away: eating
[01:00:30] <alex_joni> [02:41] * jmk_eating is now known as jmkasunich
[01:00:32] <petev> or at least faster
[01:01:02] <jmkasunich> I had to finish cooking it first
[01:01:15] <jmkasunich> red beans and rice.... tasty!
[01:01:15] <petev> ahh, I just had a sandwich
[01:01:29] <alex_joni> * alex_joni made some chilli today
[01:01:34] <alex_joni> that was yummy
[01:02:20] <petev> did u guys talk to cradek about the scope of a new branch for some of the code I started?
[01:02:45] <jmkasunich> this is the first I heard of it
[01:03:06] <petev> ok, I sent him some emails earlier to see what he thought
[01:03:06] <alex_joni> petev: you are welcome to add your code in a branch at anytime..
[01:03:15] <jmkasunich> I was hiding yesterday, so I could actually do something instead of talking all night
[01:03:20] <petev> he prefered a branch, but wanted the scope narrow
[01:03:28] <alex_joni> if it doesn't involve adding a lot of new dirs..
[01:03:31] <petev> I was thinking something like "experimental"
[01:03:44] <petev> jmk: yeah, I noticed you hidding the last couple of days
[01:04:04] <jmkasunich> just yesterday
[01:04:08] <petev> alex: I want to get rid of the rs274ngc dir and add an interpreter dir
[01:04:19] <jmkasunich> Thursday I wanted to hide, but wound up on IRC anyway
[01:04:22] <alex_joni> and move the rs274 there?
[01:04:25] <petev> that dir will hold the base class and dirs for other interps
[01:04:31] <alex_joni> right..
[01:04:33] <petev> a subdir to interpreter
[01:04:36] <alex_joni> sounds ok to me..
[01:04:50] <alex_joni> the only problem is dirs are visible to head
[01:04:50] <jmkasunich> agreed
[01:04:55] <petev> but the code is a bit extensive, from task to canon
[01:04:55] <alex_joni> or from a branch to another
[01:05:06] <alex_joni> petev: no kidding ;)
[01:05:10] <petev> yeah, I suggested emc3 module, but cradek didn't like it
[01:05:18] <alex_joni> nah.. that's bad
[01:05:27] <petev> yeah, so what to do?
[01:05:33] <alex_joni> that would be a fork even before emc2 had it's first release
[01:05:38] <alex_joni> go ahead with a branch
[01:05:41] <jmkasunich> agreed with alex: modules should only be added when we're damn sure that is the way we're going
[01:05:55] <petev> ok, so how broad a scope?
[01:06:05] <alex_joni> didn't get that..
[01:06:13] <petev> cradek was thinking petev_interp, but I think thats too narrow
[01:06:27] <alex_joni> interp_rework ?
[01:06:27] <petev> and I don't want guys to feel like it's my private stuff and they can't touch it
[01:06:41] <petev> I'm going to replace task, interp, and canon
[01:06:48] <petev> and maybe some config stuff
[01:06:57] <alex_joni> task?
[01:07:02] <jmkasunich> thats a lot ;-)
[01:07:05] <petev> yeah, emc task
[01:07:05] <alex_joni> * alex_joni is all eyes
[01:07:17] <alex_joni> explain please!!!
[01:07:25] <petev> yeah, I want people to critique and work on it if they want to
[01:07:28] <alex_joni> I'm excited.. :)
[01:07:34] <petev> the code is a mess
[01:07:40] <alex_joni> no kidding
[01:07:40] <jmkasunich> alex: and iocontrol too.... ;-)
[01:07:41] <alex_joni> :P
[01:07:46] <alex_joni> jmkasunich: buggeroff
[01:07:47] <petev> I looked at fixing it, but I think it's easier to replace it
[01:07:48] <alex_joni> :P
[01:07:52] <jmkasunich> lol
[01:08:10] <petev> I want to expand canon to be the machine view for all, not just interp
[01:08:12] <alex_joni> jmkasunich: waiting on some feedback from you in the board room ;)
[01:08:27] <alex_joni> petev: if task gets rewritten
[01:08:36] <petev> I want to have a task object, interp object, canon object, and config object
[01:08:41] <alex_joni> we should get rid of machining specific stuff from there..
[01:08:44] <petev> alex: yes?
[01:08:49] <petev> yes
[01:08:55] <jmkasunich> seriously tho, I think there is no longer any real reason for IO to be done in user space.... mix the IO commands with the motion commands, send both thru the same queue to the motion controller, and let it twiddle the HAL pins
[01:09:05] <petev> I want all machine specific stuff to be a call to canon
[01:09:24] <petev> canon will be the interface to motion, and IO it we keep it
[01:09:30] <petev> it/if
[01:09:32] <alex_joni> petev, jmkasunich: those 2 are related
[01:09:45] <petev> alex: which 2?
[01:10:05] <alex_joni> IO mixed with motion commands, and sent to motion controller
[01:10:14] <alex_joni> petev: can you receive a 1.5 MB mail?
[01:10:17] <alex_joni> jmkasunich: same for you
[01:10:18] <petev> sure
[01:10:27] <jmkasunich> yes
[01:10:45] <petev> jmk: did alex see the doc and pic yet?
[01:10:54] <jmkasunich> (alex: not blowing off the board channel, just can't talk about two things at once)
[01:10:55] <alex_joni> no I didn't
[01:11:03] <alex_joni> sending you guys a mail now
[01:11:17] <jmkasunich> pete: no
[01:11:37] <alex_joni> ok.. this is a software I came across the other day
[01:11:49] <alex_joni> it basicly isn't much.. some windows CNC software
[01:11:57] <alex_joni> but I really liked the GUI
[01:12:11] <alex_joni> not so much the GUI itself, but the things you can set-up, and the way you set them up
[01:12:28] <alex_joni> I took some snapshots with relevant parts..
[01:12:33] <petev> alex: just sent u the docs
[01:12:46] <alex_joni> docs?
[01:13:00] <petev> some notes on changes and a pic jmk made to illustrate
[01:13:39] <petev> so does an "experimental" branch sound too broad to u guys for this?
[01:13:59] <alex_joni> it sounds too.. unknown
[01:14:03] <jmkasunich> I have no problem with pv-experimental
[01:14:04] <alex_joni> not saying much
[01:14:12] <jmkasunich> I want to keep initials
[01:14:32] <petev> jmk: I thought u might use it for the new HAL and TP as well though?
[01:14:33] <jmkasunich> so other folks down the road can use the word experiemntal too
[01:14:34] <alex_joni> I would want to know what it's about by looking at the name..
[01:14:46] <petev> it would be the place to build the new user/RT interface
[01:14:49] <jmkasunich> alex: in that case, emc2....
[01:14:50] <alex_joni> petev: there is a hal-refactor
[01:15:11] <jmkasunich> pete: the hal changes are largely unrelated
[01:15:30] <petev> jmk: which, the meta data stuff or the new motion/TP interface?
[01:15:34] <jmkasunich> I don't want branches with unrelated changes, because management and merging will be a mess
[01:15:55] <petev> so how will new motion/TP interface stuff be tested?
[01:16:07] <jmkasunich> things like metadata are indepenendt - they are improvements to hal
[01:16:14] <alex_joni> petev: got my email?
[01:16:18] <jmkasunich> and have nothing to do with emc
[01:16:23] <petev> I can make an NML canon to test my stuff with emc
[01:16:27] <petev> alex: yes
[01:16:36] <jmkasunich> alex: got it
[01:16:47] <alex_joni> I was thinking about the IO mainly
[01:16:49] <petev> jmk: agreed on the meta data
[01:16:59] <alex_joni> I like the way you can setup up signals
[01:17:02] <alex_joni> name them
[01:17:06] <alex_joni> connect them to M-codes
[01:17:11] <alex_joni> and to physical pins
[01:17:27] <jmkasunich> where is that (looking at the first pic right now)
[01:17:59] <rayh> I gotta say I prefer a new module for this, emc3
[01:18:11] <alex_joni> image7 is naming
[01:18:16] <alex_joni> cool7 I mean
[01:18:26] <alex_joni> cool8 is connecting to m-codes
[01:18:30] <jmkasunich> rayh: in the long run I agree
[01:18:43] <petev> ray, that was my first thought, but I don't care, I just want to get it done
[01:18:49] <jmkasunich> because there would/will be massive changes to directory layout, files, etc
[01:18:55] <jmkasunich> not just changes within files
[01:19:30] <jmkasunich> but I fear the "what the hell is emc3" reaction
[01:19:35] <alex_joni> ahh.. let's not forget our favorite..
[01:19:43] <alex_joni> nml ;)
[01:20:04] <petev> alex: are u referring to the pic
[01:20:15] <alex_joni> didn't get that far..
[01:20:21] <petev> oh
[01:20:30] <alex_joni> still reading
[01:20:36] <alex_joni> the colours aren't very helpfull
[01:20:54] <rayh> I also prefer a good release of emc2 before we get to much time drained away for 3
[01:21:05] <jmkasunich> rayh: I agree...
[01:21:15] <cradek> hi all, I'm back
[01:21:23] <alex_joni> next time use RED and GREEN and BLUE, something to stick out.. but fuchsia and turqoise.. are hard to read
[01:21:32] <jmkasunich> although right now, Pete is doing 99% of the "emc3" work, and he's not involved in the emc2 release
[01:21:49] <petev> alex: are u using kwrite or MS word?
[01:22:05] <alex_joni> ms word
[01:22:14] <alex_joni> and it's 03:21 am
[01:22:22] <petev> alex:hmm, looks good in mine, that's strange
[01:22:42] <alex_joni> it looks good, but they are pretty close together.. not something to stick out in front of tired eyes
[01:22:52] <petev> ahh
[01:23:42] <jmkasunich> also keep in mind that that doc is the product of many days of discussions, and alex is getting it dumped on him
[01:24:02] <petev> true
[01:24:02] <alex_joni> I'm trying to figure out who said what in what order ;)
[01:24:15] <petev> and more discussion after that, that's not covered in there
[01:24:27] <petev> we talked, then I wrote the doc
[01:24:33] <petev> then comments were added
[01:26:18] <petev> is there a way to have a module that doesn't show in the CVS web browse?
[01:27:22] <alex_joni> yeah.. use a different CVS
[01:27:29] <petev> hmm
[01:28:13] <alex_joni> kidding.. not really
[01:28:41] <petev> alex, how do the custom M codes work in that CNC? do they just flip an IO?
[01:29:00] <alex_joni> yeah
[01:29:08] <alex_joni> also they can start a macro
[01:29:19] <alex_joni> cool9
[01:34:21] <jmkasunich> petev: what percentage of the emc2 code do you expect to retain in your experimental version?
[01:35:12] <petev> it depends
[01:35:21] <petev> I can make an NML server on the GUI end
[01:35:26] <petev> and an NML canon
[01:35:36] <jmkasunich> would that be your choice?
[01:35:39] <petev> this would allow the new stuff to work with emc2 as is
[01:35:51] <petev> no, but I think it's probably needed
[01:36:15] <petev> we need some bridge so everything doesn't need to be done at once
[01:39:46] <alex_joni> petev: what do you mean NML server on the GUI end?
[01:40:30] <petev> alex, I want to isolate the comm mechanism from the objects
[01:40:43] <alex_joni> ok..
[01:40:44] <petev> I don't like the way it polutes the EMC code now
[01:40:58] <petev> it's like a wrapper that talks to the objects
[01:41:06] <petev> the same way RPC will be done
[02:18:18] <alex_joni> that's nice
[02:18:29] <alex_joni> sorry I was away for a while.. finished reading
[02:18:33] <alex_joni> petev: still there?
[02:18:35] <petev> ok
[02:20:16] <alex_joni> so.. that's awfull lots of changes
[02:20:54] <alex_joni> not that I don't like it..
[02:25:05] <alex_joni> petev: not that I want to cut your enthusiasm.. but are you aware of what the extent of that is?
[02:28:55] <petev> yes
[02:29:20] <alex_joni> ok.. just making sure ;)
[02:29:42] <petev> I don't think it's as bad as the emc code makes it look ;-)
[02:30:18] <alex_joni> well.. I started by wanting to do minor stuff..
[02:30:25] <alex_joni> and it's taking me a few years ;)
[07:27:53] <jmkasunich> jmkasunich is now known as jmk_sleep
[11:08:24] <rayh> logger_devel: bookmark
[11:08:24] <rayh> See
http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2005-12-11#T11-08-24
[11:38:17] <rayh> Got any ideas what the hard coding of a,b,c as angular is going to have on folk who wish to use these axes as linear?
[14:03:55] <martin> martin is now known as chinamill
[14:04:46] <chinamill> /msg NickServ IDENTIFY gurrag
[14:05:13] <alex_joni> that didn't work as it should have :P
[14:05:18] <chinamill> :)
[14:21:43] <rayh> rayh is now known as rayh_away
[14:57:13] <okalleo> okalleo is now known as chinamill
[18:03:16] <chinamill> For the logger: After changing values to vel and acc in core stepper I got rid of the following errors and the overshooting disapered.
[18:06:02] <alex_joni> great
[18:07:39] <chinamill> * chinamill is away: eat
[18:17:15] <alex_joni> hi pete
[18:17:57] <petev> hi alex
[18:18:38] <SWPadnos_> hi guys
[18:18:49] <petev> hi steve
[18:18:59] <alex_joni_> got disconnected
[18:19:04] <SWPadnos_> hi alex
[18:19:05] <alex_joni_> how's the plans for the branch?
[18:19:14] <SWPadnos_> (that's about all you missed)
[18:19:24] <petev> cradek wanted me to wait until the emc2 release
[18:19:40] <petev> so I setup a CVSNT server on my machine last night
[18:20:58] <petev> hopefully the emc2 release will be soon, and then we can cut over to SF
[18:21:14] <alex_joni_> yeah.. working towards that
[18:29:22] <alex_joni_> I'm working on the runscript right now
[18:34:08] <SWPadnos_> man - I'm looking at emc.hh (in relation to the multi-axis homing question)
[18:34:17] <SWPadnos_> there's a lot of crap that can be ripped out of there
[18:36:26] <alex_joni_> SWPadnos_: check the docs
[18:36:36] <alex_joni_> I spent a few days keeping track of those
[18:37:45] <alex_joni_> alex_joni_ is now known as alex_joni
[18:39:10] <alex_joni> petev: it would be ok to start the branch now.. but that would also have some problems
[18:39:33] <alex_joni> any development on HEAD that you need (like HAL for example), is frozen
[18:39:37] <alex_joni> in your branch at least
[18:39:45] <petev> one sec on phone
[18:39:46] <alex_joni> and you'd have to merge it all manually in there
[18:39:51] <alex_joni> * alex_joni holds his thought
[18:39:51] <jmk_sleep> jmk_sleep is now known as jmkasunich
[18:40:00] <alex_joni> morning sleeping beauty :P
[18:40:27] <jmkasunich> I woke up about 2 hrs ago, was having breakfast, walking the dog, and such
[18:40:45] <alex_joni> nice ;)
[18:40:52] <alex_joni> * alex_joni is cleaning up the run script
[18:41:01] <jmkasunich> still need to sleep about 10 more hours to catch up
[18:41:17] <jmkasunich> petev and swp are evil I tell you...
[18:41:19] <alex_joni> you?
[18:41:29] <jmkasunich> keep me up all night on IRC
[18:41:31] <alex_joni> how long last night?
[18:41:44] <jmkasunich> last night I quit at 2:30am I think
[18:41:50] <alex_joni> that's early :P
[18:41:57] <jmkasunich> but they did it almost every night during the week
[18:42:05] <jmkasunich> it really sucks when you have to get up at 7am
[18:42:06] <alex_joni> then not..
[18:42:15] <alex_joni> kick em
[18:42:20] <alex_joni> or you want me to do it?
[18:42:21] <alex_joni> :D
[18:42:34] <jmkasunich> I can't kick anybody, no ops
[18:42:43] <alex_joni> I was kidding..
[18:42:50] <jmkasunich> I need to learn to kick me
[18:42:53] <alex_joni> try /quit nickname
[18:42:58] <alex_joni> like /kick petev
[18:43:03] <alex_joni> like /quit petev
[18:43:04] <alex_joni> :D
[18:43:48] <jmkasunich> I need to just stop IRCing and focus
[18:44:25] <jmkasunich> what needs done for the emc2 release?
[18:44:43] <alex_joni> I want make install to work properly
[18:44:47] <jmkasunich> (I want to work on my VCP stuff, but I suppose that isn't the highest priority right now.
[18:44:55] <alex_joni> ray said about bridgeport equivalence
[18:45:12] <alex_joni> wanna finish the configs/foo/ stuff today
[18:45:29] <jmkasunich> anything I can do to help?
[18:45:48] <jmkasunich> hmm, I have a PROM from JonE for the UPC, I should finish that testing
[18:45:50] <alex_joni> not really.. maybe look at the stuff I do, proof-reading / testing
[18:46:05] <SWPadnos_> hi - I'm back
[18:46:18] <jmkasunich> * jmkasunich hides
[18:46:39] <jmkasunich> must... not.... talk.... about.....emc...3.....
[18:46:53] <SWPadnos_> how about emc2 then ;)
[18:47:05] <jmkasunich> depends
[18:47:24] <SWPadnos_> hey -what's t he new prom supposed to do?
[18:47:38] <SWPadnos_> make it a ppmc?
[18:47:47] <jmkasunich> turns it from USC to UPC
[18:47:55] <SWPadnos_> ok
[18:47:55] <jmkasunich> so I can test the PWM gen code
[18:48:18] <SWPadnos_> I was going to email him about the bugs we found in the FPGA code (the mysterious +4 or 5)
[18:48:32] <jmkasunich> I already griped at him about it
[18:48:42] <SWPadnos_> ok, good
[18:49:01] <jmkasunich> I think he actually knew, and either didn't care (the loop compensates for it) or embedded the fix in the code and didn't bother to fix the docs
[18:49:26] <SWPadnos_> there are docs? ;)
[18:49:43] <jmkasunich> if the pwm works, I'm gonna close the tracker and call it done... he can test the other stuff (or not)
[18:50:06] <SWPadnos_> yep
[18:50:14] <alex_joni> sounds good
[18:50:30] <SWPadnos_> I wish he didn't fake out input 15
[18:50:35] <SWPadnos_> ehwn SSR8 is off
[18:50:38] <SWPadnos_> when
[18:51:07] <jmkasunich> that whole estop thing is fscked IMO
[18:51:15] <petev> yep
[18:51:19] <SWPadnos_> yep - that's what I meant ;)
[18:52:26] <SWPadnos_> alex - which docs wid you mean regarding emc.hh?
[18:52:34] <SWPadnos_> s/wid/did/
[18:52:53] <alex_joni> there's a csv file, I can send you that
[18:53:05] <SWPadnos_> ok, I'd like to see it
[18:53:05] <alex_joni> petev: back?
[18:53:10] <petev> yeah
[18:53:15] <jmkasunich> damn, the US Postal service bent the snot out of the prom leads...
[18:53:30] <SWPadnos_> needlenose pliers and patience are required
[18:53:37] <SWPadnos_> or great soldering skill ;)
[18:53:46] <jmkasunich> pliers
[18:53:55] <SWPadnos_> yuo'd think that the pins would be in foam or something
[18:54:12] <alex_joni> petev: the thing cradek was worried about is that once you branch devel is frozen
[18:54:13] <SWPadnos_> thanks
[18:54:29] <alex_joni> and if there's improvement in some places (like HAL), you won't get that on your branch
[18:54:35] <alex_joni> unless you merge it in manually..
[18:54:41] <jmkasunich> he stuck it in a tiny (1/2" square) piece of foam, stuck thatin a hole cut in a piece of cardboard, and stuck that in an ordinary envelope
[18:54:44] <petev> alex_joni: hmm, seems easy enough to jus merge the stuff that's unchanged again
[18:55:03] <alex_joni> if you branch of a release, then it's most likely to work for a long time..
[18:55:12] <jmkasunich> combined thickness of the cardboard (especially after the post office got done with it) was less than the original height of the part
[18:55:16] <SWPadnos_> perhaps a piece of cardboard folded over the foam would have been better (or just stick the pins in the cardboard itself)
[18:55:52] <petev> alex_joni: yeah, the CVSNT is working now, so it's not a big deal, hopefully emc2 release won't take long
[18:55:57] <jmkasunich> right now it kinda looks like a SMT leadform...
[18:56:05] <jmkasunich> except they are bent in instead of out
[18:56:18] <petev> J lead
[18:56:29] <SWPadnos_> ok - the original SMT style (J-lead)
[18:56:37] <alex_joni> yeah :D
[18:56:40] <jmkasunich> yeah
[18:56:50] <SWPadnos_> heh
[18:57:22] <alex_joni> SWPadnos_: need help decifering that?
[18:57:32] <SWPadnos_> maybe - le t me open it first ;)
[18:57:42] <alex_joni> any spreadsheet will do
[18:57:49] <alex_joni> that can open csv files
[18:58:26] <jmkasunich> damn its hard to work with a cat in your lap
[18:58:57] <SWPadnos_> OK - I remember this file (from way back)
[18:59:34] <SWPadnos_> I was thinking more of the data in status
[18:59:46] <SWPadnos_> all the PIDFF, backlash, etc aren't needed, since the data is in HAL
[19:00:29] <jmkasunich> maybe this would be more appropriate for emc3, but just tossing the idea out:
[19:00:41] <petev> where do u draw the line between what's in INI and HAL when HAL can pull from INI?
[19:00:58] <jmkasunich> what if all the emcmot_set_foo commands were replaced by hal parameters (still pulled from ini)
[19:01:03] <SWPadnos_> petev: not talking about ini, looking at emc.hh status struct
[19:01:09] <petev> oh
[19:01:13] <petev> back to coding
[19:01:20] <SWPadnos_> but ini is another thing I was thinking about
[19:01:27] <jmkasunich> emc.hh defines all the NML messages, and a lot of them are just setting values
[19:01:35] <petev> yes
[19:02:43] <SWPadnos_> actually, there should just be a generic "EMC_{GET,SET}_HALPIN" nmesasge, that takes a name and either a value or a pointer to a value
[19:03:01] <jmkasunich> param, not pin
[19:03:13] <SWPadnos_> true - for these kinds of things
[19:03:56] <jmkasunich> this is yet another example of what robin used to gripe about with NML
[19:04:10] <SWPadnos_> yep - 1000 messages where 2 or 4 would do
[19:04:15] <jmkasunich> if you send "set name, value", only the sender and receiver need to understand name
[19:04:31] <jmkasunich> if the message has the name hard coded into it, then entire transport layer must know
[19:04:36] <petev> clean it up, it will make the new NML servers easier ;-)
[19:04:46] <SWPadnos_> and you end up with 480-line switch statements
[19:05:05] <jmkasunich> unforch I bet the GUIs (thru emcsh) send some of those messages
[19:05:18] <jmkasunich> for instance, in emc1, you could tune PID using the gui
[19:05:28] <jmkasunich> it sent SET_PID_GAINS messages
[19:05:32] <SWPadnos_> yep - that's what Ray is working on now
[19:05:36] <SWPadnos_> for emc2
[19:05:41] <jmkasunich> if we cleaned up, the GUIs would need rework
[19:06:08] <jmkasunich> unless he's ripping that stuff out anyway
[19:06:09] <petev> do u really think u should be able to tune PID from the GUI?
[19:06:09] <SWPadnos_> actually, don't the GUIs use emcsh?
[19:06:19] <petev> maybe some special integrator tool
[19:06:20] <alex_joni> SWPadnos_: only tcl ones
[19:06:25] <SWPadnos_> ok
[19:06:39] <SWPadnos_> those are the most commonly used though (and cradek and jepler can fix AXIS ;) )
[19:07:08] <jmkasunich> the GUIs use emcsh, so we'd have to fix both emcsh and tkemc and mini
[19:07:34] <SWPadnos_> the trouble is that with HAL, there's a higher level of configuration - you don't know where to send the joint 0 P value until there's a HAL connection
[19:07:35] <jmkasunich> emcsh so it would no longer send the old messages, and tkemc and mini so they would no longer request them
[19:07:38] <petev> fixing emcsh would be mostly deleting code
[19:07:47] <petev> maybe the same for the GUIs
[19:08:04] <jmkasunich> still a lot to do. would delay the release
[19:08:13] <SWPadnos_> the GUIs should be asking to set the P value of joint 0, so what emcsh does should be transparent
[19:08:15] <jmkasunich> save that for 2.1 I think
[19:08:26] <SWPadnos_> (should be)
[19:08:51] <jmkasunich> with HAL, that still demands a lot more smarts from emcsh
[19:08:53] <petev> what about just having emcsh turn em into NOPs?
[19:09:06] <SWPadnos_> no - they should stiull perform the function
[19:09:18] <petev> oh, that's a lot of work
[19:09:22] <jmkasunich> if they aren;t gonna do anything, then they should be removed from the menus to avoid confused users
[19:09:22] <SWPadnos_> if they don't, then people wonder why nothing changes when they retune
[19:10:04] <petev> if the user changes them from the GUI, he surely expects the changes to persistst
[19:10:11] <petev> dam I can't type
[19:10:17] <SWPadnos_> yes
[19:10:22] <petev> how will the persistance be handled?
[19:10:29] <jmkasunich> and thats why emc rewrites the ini file
[19:10:31] <SWPadnos_> good question
[19:10:31] <petev> the param settings need to be saved
[19:10:34] <jmkasunich> (something I find offensive)
[19:10:42] <SWPadnos_> the connections as well
[19:10:46] <petev> yep
[19:10:53] <petev> HAL configurator
[19:10:59] <petev> rip it outa the GUIs
[19:11:06] <SWPadnos_> incidentally, that was something I couldn't find - where the heck is the code that rewrites the ini file?
[19:11:29] <SWPadnos_> I searched the entire tree for OUTPUT_SCALE, and didn't see anything that looked like an ini *write*
[19:12:01] <petev> but u confirmed it was being written?
[19:12:06] <SWPadnos_> yes
[19:12:09] <alex_joni> it is written
[19:12:15] <alex_joni> hang on, I'll get the snips
[19:12:27] <jmkasunich> I vaguely remember, I'll dig it up
[19:13:07] <SWPadnos_> ok - it's in dumpaxis, in iniaxis.cc
[19:13:22] <SWPadnos_> they just don't have the string itself in the code
[19:13:43] <alex_joni> that's it
[19:13:53] <SWPadnos_> line 1028, in my copy
[19:15:10] <jmkasunich> yet another chunk of code that has to be aware of all the params
[19:16:59] <SWPadnos_> ok - all of those vars are only used by HAL now - should the entire dump just be removed?
[19:16:59] <SWPadnos_> (backlash, output_scale, ferror, min_ferror
[19:16:59] <SWPadnos_> )
[19:17:19] <jmkasunich> backlash is used by motmod, not by hal
[19:17:38] <jmkasunich> actually, of the four, only outputscale is HAL
[19:17:44] <jmkasunich> the other three are motmod
[19:19:41] <jmkasunich> hmm, something went down
[19:20:03] <alex_joni> brown is down ;)
[19:21:06] <jmkasunich> welcome back
[19:21:32] <jmkasunich> swp: you there?
[19:21:54] <SWPadnos_> ah - so much better
[19:22:11] <SWPadnos_> thanks - same to you
[19:22:16] <alex_joni> where did you go?
[19:22:18] <alex_joni> :P
[19:22:19] <jmkasunich> last thing you said was "should the dump be removed" and listed 4 vars
[19:22:32] <SWPadnos_> yep - that was the last thing
[19:22:33] <jmkasunich> of those 4, 3 are still used by motmod (only)
[19:22:39] <jmkasunich> only output scale is HAL now
[19:22:57] <jmkasunich> crap
[19:24:17] <jmkasunich> nasty weather on IRC today
[19:24:26] <alex_joni> welcome back
[19:24:27] <SWPadnos_> thanks - same to you
[19:24:27] <SWPadnos_> (alex)
[19:24:50] <alex_joni> :)
[19:25:20] <alex_joni> ok.. maybe you can find 1-2 minutes to look at the modified runscript?
[19:25:54] <petev> jmk, couldn't u make the couple of params into HAL params for motmod?
[19:26:09] <jmkasunich> could, but that should be an all-or-nothing thing
[19:26:14] <jmkasunich> (IMO)
[19:26:22] <petev> yeah, I mean the ones that aren't HAL now
[19:26:26] <jmkasunich> and I don't want to do all before the release
[19:26:29] <petev> that way they would all be HAL
[19:27:05] <jmkasunich> what about things like MAX_ACCELERATION and such? they're not dumped by ini_axis, where do they get saved?
[19:28:15] <petev> u guys think there should be max limits on things like file paths, or use dynamic allocation?
[19:28:18] <SWPadnos_> I'd say that it's the responsibility of the tuning app to save the changes or not
[19:28:31] <petev> swp: agreed
[19:28:51] <SWPadnos_> that way, if you screw something up, there's still the possiblity of an "undo"
[19:29:03] <jmkasunich> right
[19:29:27] <jmkasunich> although it may be indirect, the tuning app is basically "editing" a document with the config info
[19:29:35] <alex_joni> who knows a bit of bash?
[19:29:44] <SWPadnos_> yes, with live demonstrations of the effects of the edit ;)
[19:29:48] <jmkasunich> its just that it also simultaneously edits the running machine
[19:30:17] <SWPadnos_> WYSIWYG for machining
[19:30:18] <alex_joni> I'm trying to figure out what the difference between 2> >> and 2>> is
[19:30:41] <jmkasunich> as an editor, the "file save" or "discard changes" function should be handled there, not by EMC always saving the ini when it shuts down
[19:31:00] <jmkasunich> alex: sorry, dunno that one
[19:31:10] <SWPadnos_> > recreates the output file if necessary, >> appends, and 2> or 2>> means take stderr (I think) and recreate or append the output file
[19:31:29] <jmkasunich> but 2> >>?
[19:31:41] <SWPadnos_> 2>& will redirect stderr to stdout, so both will be captured in the same stream
[19:31:49] <jmkasunich> I understand 2>foo >>bar
[19:31:57] <jmkasunich> but without a name after the 2>....
[19:32:07] <alex_joni> there is a name after 2>
[19:32:08] <SWPadnos_> oh - were those two separate things, or 3 (I interpreted that as "2>", ">>", and "2>>"
[19:32:17] <jmkasunich> 2>foo >>bar means replace foo with the output of stderr, and append the output of stdout to bar
[19:32:19] <alex_joni> 3 different separate things
[19:32:24] <SWPadnos_> ok
[19:32:33] <jmkasunich> 2 is stdout
[19:32:41] <SWPadnos_> stderr, no?
[19:32:45] <alex_joni> stderr
[19:32:48] <jmkasunich> yes, sorry
[19:33:15] <SWPadnos_> if you want an error log, you would do 2>> errorlog
[19:33:15] <jmkasunich> 2>foo means replace foo with the output of stderr, 2>>foo means append stderr output to foo
[19:33:23] <jmkasunich> leave off the 2 and its stdout
[19:33:43] <SWPadnos_> if you want a log of combined stderr and stdout, then 2>& >> errorlog
[19:34:00] <SWPadnos_> oops - 2>&1 (right?)
[19:34:08] <jmkasunich> I think
[19:34:13] <jmkasunich> thats where I get rusty
[19:34:17] <SWPadnos_> heh
[19:35:05] <alex_joni> nm.. :)
[19:35:12] <alex_joni> didn't want to interrupt that much
[19:35:52] <SWPadnos_> no problem - we hand't had any diversions for at least 3 minutes
[19:38:02] <jmkasunich> damn, looks like the PWM output is inverted
[19:38:35] <SWPadnos_> just like the step output (relative to geckos, anyway)
[19:38:51] <SWPadnos_> hmmm - I should look at the Mariss mode on the scope
[19:39:04] <jmkasunich> command duty cycle of 0.1 and you get 90% high, 10% low
[19:39:20] <SWPadnos_> maybe there should be an invert param?
[19:39:27] <SWPadnos_> (anyway)
[19:39:56] <jmkasunich> perhaps
[19:40:16] <jmkasunich> this isn't like a DAC where you can change the scale to negative
[19:40:35] <SWPadnos_> I suppose you could, but it's easier to change a param
[19:40:36] <jmkasunich> btw, IMO the PWM output is stupid - there is a PWM out, and a DIR bit
[19:40:58] <SWPadnos_> well - I'm sure it works with Jon's PWM drives
[19:41:00] <jmkasunich> should be two PWM outs, one pulses for negative command, one for positive command
[19:41:23] <jmkasunich> I'm sure it does, he probably has steering logic in the drive
[19:45:02] <jmkasunich> this is just fucked
[19:45:09] <alex_joni> huh
[19:45:22] <jmkasunich> duty cycle of 0.999, output is almost always low (as expected, given the inversion)
[19:45:33] <jmkasunich> go to 1.000, and it goes high and stays hi
[19:46:07] <alex_joni> and 0.000 gives low?
[19:46:15] <SWPadnos_> that gives a 0 divisor in the code, right? (or equal to the PWM period)
[19:47:05] <SWPadnos_> you'd think that those unused dipswitches could have been put to use as per-PWM "invert" settings
[19:47:17] <jmkasunich> 0.001 gives mostly high (as expected)
[19:47:38] <jmkasunich> 0.0 gives mostly high, but still a 100nS low pulse
[19:47:38] <alex_joni> how about 0.000 ?
[19:47:49] <alex_joni> ahh.. strange, but ok
[19:48:51] <SWPadnos_> he isn't resetting the pin dependent on the setpoint - it always goes to 1, then gets reset to 0 when the pulse width gets reached
[19:49:46] <jmkasunich> thats not quite it
[19:50:00] <jmkasunich> 0.000 - normally hi, goes low for 100nS
[19:50:12] <jmkasunich> 0.001 - normally hi, goes low for 0.001 of period
[19:50:25] <jmkasunich> 0.999 - goes low for 0.999 of period
[19:50:30] <jmkasunich> 1.000 goes low all the time
[19:50:48] <jmkasunich> wrong
[19:50:50] <SWPadnos_> I thought you said that 1.000 goes high all the time?
[19:51:12] <jmkasunich> 0.9999 goes low all the time (except maybe sometimes it tries to go high, never makes a true logic 1 tho
[19:51:18] <jmkasunich> 1.00, high all the time
[19:51:53] <jmkasunich> so I have to go back to looking at exactly what I write to the HW, just like we did with the stepgen
[19:52:43] <jmkasunich> I swear, my commit message is gonna say "revised PWM driver to deal with yet more screwed up undocumented shit"
[19:53:01] <SWPadnos_> yep - he does explicitly state that the output will be "1" when the rate counter overflows
[19:53:16] <SWPadnos_> then it gets set back to 0 when the count is reached
[19:53:31] <SWPadnos_> you need to make sure that the duty cycle is 1 less than the period
[19:53:42] <SWPadnos_> and at least 1, I'd bet
[19:54:01] <SWPadnos_> (I suspect that it doesn't deal with 0 correctly)
[19:54:38] <jmkasunich> I need to verify what I'm actually writing
[19:54:45] <SWPadnos_> yep
[19:55:01] <jmkasunich> there are a couple places where the code does 65536 - foo, maybe one of those shouldn't be there
[19:55:12] <SWPadnos_> I suspect that you need to bound the pulse width between 1 and period-1
[19:55:19] <jmkasunich> that too
[19:55:33] <SWPadnos_> rather than between 0 and pulse_width
[19:55:59] <jmkasunich> although that would imply that you can't get either 0% or 100% duty cycle, which frankly would suck
[19:56:09] <SWPadnos_> well - it looks like it sucks
[19:56:55] <SWPadnos_> just for giggles, write a constant 0 to the pulse width, then try the constant pulse_width -1, and see what they look like on the scope
[19:57:08] <SWPadnos_> sorry - period_width-1
[19:58:17] <SWPadnos_> actually - that should have been "write the period to the pulse width, and see what happens"
[19:58:54] <alex_joni> I have a question about config dirs
[19:59:04] <jmkasunich> yeah, I need to run a number of tests, that is just one of them
[19:59:11] <jmkasunich> alex: shoot
[19:59:17] <alex_joni> do we keep configs/emc.ini ?
[19:59:29] <alex_joni> or make that obsolete?
[19:59:44] <SWPadnos_> what will be the default ini file when you run emc (or emc.run ;) )?
[19:59:54] <jmkasunich> good point
[20:00:05] <alex_joni> I have: configs/mazak, configs/motenc, configs/ppmc, configs/sim, configs/step_cl, configs/stepper, configs/stg
[20:00:15] <jmkasunich> I vote for sim as the default
[20:00:21] <petev> why not configs/default
[20:00:30] <SWPadnos_> link to the default dir
[20:00:31] <jmkasunich> that way no matter what hardware you have or don't have, it works
[20:00:40] <alex_joni> petev: thought about that.. but what do you place in there?
[20:00:50] <petev> a link like swp says
[20:01:02] <jmkasunich> users don't know about links
[20:01:03] <alex_joni> can't have links in CVS I think :)
[20:01:04] <petev> at least then u know what the default is
[20:01:08] <petev> hmm
[20:01:15] <alex_joni> I can put anyone as the default
[20:01:20] <SWPadnos_> actually, a file that has the name of the preferred config would be better
[20:01:20] <alex_joni> the run script takes care of that
[20:01:31] <jmkasunich> the run script needs new logic for that tho
[20:01:31] <alex_joni> if no ini passed as argument, it uses the default
[20:01:37] <SWPadnos_> but then that would be emc.ini, huh?
[20:01:42] <alex_joni> the run script has the logic now
[20:02:05] <alex_joni> I would say: configs/sim/sim.ini is default
[20:02:14] <jmkasunich> how about (in the run script): if arg, use arg, if no arg and "default" exists, use "default", else use "sim"
[20:02:19] <petev> if u have to pick one, sim is best
[20:02:42] <jmkasunich> and CVS would not contain a default directory
[20:02:43] <SWPadnos_> will the default behavior be to look for $arg/$arg.ini?
[20:02:46] <petev> jmk: that sounds pretty good too
[20:03:14] <alex_joni> if you pass an abs. path (/path/to/foo.ini) it uses that
[20:03:15] <petev> swp: why not $arg/*.ini ?
[20:03:15] <SWPadnos_> (so emc sim would look for sim/sim.ini?)
[20:03:24] <alex_joni> if you pass foo.ini it looks in configs/foo.ini
[20:03:31] <jmkasunich> that way we encourage the user to put his custom config in default
[20:03:40] <alex_joni> if you pass foo, it looks for configs/foo/foo.ini, then for configs/foo.ini
[20:03:57] <alex_joni> jmkasunich: I'm good with that
[20:04:04] <jmkasunich> I would never look for configs/anything.ini
[20:04:12] <jmkasunich> don't encourage them to put ini files in there
[20:04:21] <SWPadnos_> ok, so if the arg has no path, and doesn't end with ini, then it does look for configs/$arg/$arg.ini
[20:04:24] <alex_joni> that's the last resort.. (don't want to break older configs)
[20:04:32] <jmkasunich> fuckem
[20:04:34] <alex_joni> SWPadnos_: correct
[20:04:42] <SWPadnos_> cool - I'm happy with that
[20:04:44] <alex_joni> jmkasunich: not very friendly today :P
[20:04:56] <SWPadnos_> he's working on the ppmc driver ;)
[20:05:03] <petev> nuff said
[20:05:06] <alex_joni> SWPadnos_: I was thinking about configs/$arg/default.ini too, but scraped that
[20:05:14] <alex_joni> jmkasunich: sorry about that :)
[20:05:16] <jmkasunich> it isn't even officially released yet, things change... when we do the release, I want everybody to get on the same page
[20:05:19] <SWPadnos_> or configs/$arg/emc.ini
[20:05:40] <alex_joni> yeah.. but that ends up with problems.. if you have more than one config in $arg
[20:05:48] <SWPadnos_> no particular reason why I should have to rename the file if I create a new config
[20:05:50] <alex_joni> you won't know which one is the default, etc
[20:06:07] <SWPadnos_> can you specify more than one config at a time?
[20:06:08] <alex_joni> searchorder is a bitch
[20:06:08] <alex_joni> :)
[20:06:13] <jmkasunich> you shouldn't have more than one config in a directory
[20:06:17] <alex_joni> why should you can?
[20:06:21] <jmkasunich> (if thats the way we're going)
[20:06:28] <alex_joni> jmkasunich: I think so too
[20:06:42] <alex_joni> maybe the runscript can take care of that ;) rm any extra .ini's
[20:06:43] <alex_joni> ROFL
[20:07:07] <SWPadnos_> in that case, there's not much need to rename the ini files (except to make it more human-friendly)
[20:07:18] <SWPadnos_> ie, every config dir can have n emc.ini in it
[20:07:21] <alex_joni> I like stg/stg.ini
[20:07:23] <SWPadnos_> s/n/an/
[20:07:24] <jmkasunich> you know that is one attractive thing about petes ideas for config... I hate XML with a passion, but all info in one file is attractive
[20:07:25] <alex_joni> and sim/sim.ini
[20:07:43] <alex_joni> but that's for emc3
[20:07:46] <alex_joni> and xml is good
[20:07:53] <alex_joni> just hard to read (for humans)
[20:07:56] <SWPadnos_> internally, it's even better - you can still have multiple files, but all the config info is in a single data object internally
[20:08:20] <petev> swp:true
[20:08:23] <alex_joni> and we do need a config utility anyways.. so that'll take care of editing it
[20:08:28] <SWPadnos_> actually, the thing to look at is the KDE settings system
[20:08:42] <petev> u can even have multiple files if u really want, with the SYSTEM include
[20:08:47] <SWPadnos_> it uses ini file style settings, and has hierarchy, and immutability of settings
[20:08:49] <jmkasunich> SWP: the attraction is all in one file, so when somebody has problems, they send one file and you know you have their exact config
[20:08:52] <petev> they can even be remote URLs
[20:09:09] <jmkasunich> anyway, back to emc2
[20:09:20] <SWPadnos_> yes - as long as the system supports writing the data, you could always write a single file that contains all the data from all the other files
[20:09:24] <petev> to me the attraction is the internal rep, and the tree strucure
[20:09:32] <cradek> jmkasunich: when alex's config directory changes are done, you can just tar up the config directory to solve that problem
[20:09:48] <alex_joni> lol
[20:09:48] <jmkasunich> the ini is going to be in configs/foo/<foo|emc/?>,ini
[20:10:27] <jmkasunich> will the ini format allow you to pull things like core_stepper.hal from other directories, or will you need a copy of that in configs/foo?
[20:10:34] <jmkasunich> there are pros and cons to both approaches
[20:10:58] <cradek> sure, I'm not trolling, I'm just saying the problem you mentioned does not require xml to fix
[20:11:03] <jmkasunich> IF core_stepper is considered a "standard" file, then you want CVS updates to update it, that means it needs to live in one place
[20:11:20] <SWPadnos_> no - you don't necessarily want the file updated
[20:11:22] <jmkasunich> if it is to be customized by the user, then you don't want CVS updates to fsck with it
[20:11:36] <SWPadnos_> right
[20:11:51] <SWPadnos_> you can have a core/ directory, that gets CVS updates
[20:12:21] <SWPadnos_> the sample configs can reference ../core/core_*, and have comments saying that the user should make a copy if they want to change it
[20:12:27] <cradek> yeah, cvs has porked my emc2 emc.ini several times now
[20:12:32] <jmkasunich> cradek: I think taring the entire directory is an excellent idea
[20:12:52] <alex_joni> jmkasunich: I have these files in configs/
[20:13:33] <petev> jmk: you're not serious about the tar?
[20:13:34] <alex_joni> TkEmc, client.nml, core_servo.hal, core_sim.hal, core_stepper.hal, emc.nml, simulate.., standard_pinout, xylotex_pinout
[20:14:06] <SWPadnos_> tar is easy, especially if there's an option to emc.run "get_help"
[20:14:21] <cradek> petev: it's true that if we put just the config files in a directory, sending the entire config to someone becomes trivial
[20:14:24] <SWPadnos_> which can tar up the appropriate directory for the (l)user
[20:14:25] <jmkasunich> why not? its easy to tell someone on IRC, even a linux newbie: do this: cd <yourmachinedir>, tar -cvf foo, mail me the file
[20:14:32] <alex_joni> SWPadnos_: there is no emc.run anymore :P
[20:14:34] <petev> swp: well that sure invalidates the comments about attaching config info to an email for viewing
[20:14:43] <SWPadnos_> phew - I was wondering if I should add the suffix ;)
[20:14:52] <SWPadnos_> yes it does
[20:15:01] <alex_joni> emc.run still is there.. but it's going away soon
[20:15:17] <jmkasunich> here is another radical thought
[20:15:19] <SWPadnos_> good - is it renamed to emc?
[20:15:25] <SWPadnos_> (or emc2??)
[20:15:27] <alex_joni> there's another for emc
[20:15:34] <jmkasunich> maybe emc.run needs to be a nice user friendly GUI
[20:15:34] <alex_joni> it's called emc.in
[20:15:54] <SWPadnos_> I had that thought as well - list the available config dirs if no arg is given
[20:16:00] <alex_joni> because it gets parsed by ./configure, and some stuff gets replaced
[20:16:00] <alex_joni> like dirs & such
[20:16:04] <jmkasunich> with options like "run emc", "create new config", "modify config", etc
[20:16:45] <SWPadnos_> I think that such a GUI is a good idea, but not as "emc" - it should start the machine by default
[20:16:57] <cradek> I agree with swp
[20:17:06] <jmkasunich> yeah
[20:17:08] <cradek> I'm picturing it as a "setup wizard"
[20:17:17] <cradek> not a "main menu"
[20:17:25] <jmkasunich> maybe each gui should have a way to activate the wizard
[20:17:32] <SWPadnos_> maybe that silly "startup tips" thing can tell a user the first time that they should go to menu XX and select a configuration
[20:17:37] <SWPadnos_> right ;)
[20:17:47] <petev> maybe it's one prog and a flag to open in gui wizard mode
[20:18:04] <jmkasunich> actually, the GUI can't activate the wizard - by the time the GUI is up, you have already selected a config directory
[20:18:20] <jmkasunich> so "new config" wouldn't be an option (unless you restart emc)
[20:18:36] <cradek> "emc" could start the main menu; "emc config" could start emc
[20:18:42] <jmkasunich> yes
[20:18:43] <SWPadnos_> true, but there's no technical reason why the GUI can't restart itself with a new config (sig HP)
[20:18:46] <jmkasunich> I was just thinking that
[20:18:48] <cradek> ... I guess
[20:19:00] <petev> ugly
[20:19:06] <SWPadnos_> HUP that was
[20:19:09] <petev> maybe u just configed a new gui
[20:19:14] <jmkasunich> if no arg, instead of picking a default for the user, list all the available dirs, plus the option of creating a new one.
[20:19:39] <SWPadnos_> could be - the GUI can return a value to the run script, that would tell it to restart (not unlike the restart param for init scripts)
[20:19:41] <jmkasunich> SWP: gotta do more than restart the GUI, gotta unload and reload the new hal config
[20:19:45] <cradek> I wouldn't object to that, but I might make a funny face
[20:20:02] <petev> keep it simple, this stuff is not that broken. have a separate config program
[20:20:20] <SWPadnos_> true
[20:20:29] <SWPadnos_> emc-config for setup, and emc for running the machien
[20:20:53] <jmkasunich> new users encouraged to run emc-config first
[20:20:57] <SWPadnos_> emc-config can be run be the emc script the first time (have the config script create the initial .ini file)
[20:21:05] <SWPadnos_> s/be/by/
[20:21:10] <cradek> emc --config
[20:21:25] <petev> yes, an arg will do
[20:21:32] <SWPadnos_> no - emc-config, that way a user can see the executable if they do an 'ls'
[20:21:44] <cradek> let's pretend we're like other unix programs here
[20:21:44] <SWPadnos_> args aren't easily discoverable
[20:21:46] <jmkasunich> agree with SWP
[20:21:50] <cradek> argh
[20:21:55] <petev> emc-config can just be a shell script that passes the arg
[20:22:00] <cradek> emc -? or emc --help
[20:22:04] <SWPadnos_> let's pretend we have windows users here ;)
[20:22:11] <jmkasunich> lol
[20:22:15] <jmkasunich> which we do.....
[20:22:15] <cradek> do they often ls in /usr/bin??
[20:22:18] <cradek> come on
[20:22:29] <cradek> nobody does that
[20:22:30] <SWPadnos_> no, but they might type emc<tab>
[20:22:33] <jmkasunich> face it, they're gonna click on the EMC icon
[20:22:41] <cradek> * cradek points at jmkasunich
[20:22:42] <jmkasunich> SWP, not likely
[20:22:47] <petev> put it on the KDE menu the the doze guys
[20:22:48] <cradek> no more likely than emc -?
[20:22:59] <jmkasunich> I don't do tab completion, never got used to it (former dos/windows user)
[20:23:07] <cradek> petev: right, and emc --config can be run by kde just as easily
[20:23:11] <petev> yep
[20:23:31] <SWPadnos_> ok - there should be a file called something like current_config, which gets written by the config script
[20:23:40] <jmkasunich> I still favor the actual config tool being separate, for development flexibility reasons
[20:23:41] <SWPadnos_> if the run script doesn't see it, it runs config
[20:24:05] <jmkasunich> SWP: yes, I was thinking along those lines
[20:24:18] <SWPadnos_> everything happens magically from the icon, or manually from the command line
[20:24:18] <cradek> SWPadnos_: ~/.emcrc
[20:24:25] <jmkasunich> in the configs/ dir, something that is NOT in CVS, that tells emc what config dir to run
[20:24:27] <SWPadnos_> sure
[20:24:36] <jmkasunich> you can override it with a cmd line option
[20:24:36] <cradek> jmkasunich: ~/.emcrc
[20:24:42] <SWPadnos_> heh
[20:24:50] <cradek> think unix everyone for god's sake
[20:24:52] <jmkasunich> but the norm is just to run emc and it sees that file and picks the dir
[20:25:05] <SWPadnos_> it's a machine-specific thing though - this is why the KDE config system should be looked at
[20:25:07] <jmkasunich> if that files isn't there, it invokes the "new user" wizard
[20:25:36] <jmkasunich> the wizard asks them to pick one of the standard configs and a new name, makes the new dir, copies the standard to that dir, and proceeds from there
[20:25:38] <cradek> SWPadnos_: no it's not; if jmkasunich wants to use the machine, he wants tkemc, I want AXIS
[20:25:43] <SWPadnos_> it's more unix-y tohave an /etc/emcrc, then the ~/.emcrc
[20:25:57] <cradek> SWPadnos_: depends if it's system-wide or user configuration
[20:26:12] <SWPadnos_> but you need to be able (as the sysadmin) to prevent people from using the hardware with the wrong drivers
[20:26:26] <SWPadnos_> ie, parport when you have a ppmc connected
[20:26:40] <jmkasunich> both of you: 90% of the config is machine specific, not user specific
[20:26:47] <cradek> jmkasunich: true
[20:26:51] <SWPadnos_> that's my point
[20:26:56] <cradek> it's a bit of a shame that we mix them
[20:27:02] <SWPadnos_> yes
[20:27:27] <jmkasunich> and even in a multi-user shop, the shop owner, integrator, foreman, etc will decide what GUI is used=
[20:27:39] <jmkasunich> you won't have each employee using his own
[20:27:59] <cradek> that's possibly true
[20:28:09] <SWPadnos_> no, but the shop foreman may log in as a different user than the lackeys, and they may have different interfaces
[20:28:34] <SWPadnos_> especially if we get to the point of user-configurable screens
[20:28:51] <SWPadnos_> the lackey would have the display with the big CYCLE_START switch, and little else
[20:28:58] <jmkasunich> true
[20:32:08] <petev> now all we need is jymmm to tell us to use SQL ;-)
[20:32:20] <cradek> hahaha
[20:32:29] <jmkasunich> ok, how (if at all) do we want to address user specific configs?
[20:32:32] <SWPadnos_> take a look at the Lock Down part of this page
[20:32:34] <SWPadnos_> http://www.kde.org/areas/sysadmin/config_file.php
[20:32:35] <jmkasunich> I suggest later
[20:33:08] <SWPadnos_> I'm not sure how far into KDE you have to go to get this config stuff, or if there are libs that can be used
[20:33:27] <jmkasunich> the format is the same as our ini.... key value pairs in sections, one level of hierchary (the sections)
[20:33:50] <SWPadnos_> yes, but there's a define search path, and the immutable tag
[20:33:52] <SWPadnos_> defined
[20:34:24] <SWPadnos_> and you get the combination of all applicable files from the search path
[20:34:56] <SWPadnos_> (that would be the section "Cascading Configuration")
[20:35:04] <jmkasunich> yeah, just read that
[20:35:14] <jmkasunich> so this implies usage of some toolset
[20:35:21] <SWPadnos_> as does XML
[20:35:22] <jmkasunich> to do all these goodies
[20:35:39] <petev> how tied to JDE do we want to be?
[20:35:45] <petev> JDE/KDE
[20:35:49] <SWPadnos_> yes - I'm not sure where the libs reside, or if they're usable outside KDE without major rework
[20:35:54] <jmkasunich> not very if avoidable
[20:36:15] <SWPadnos_> some would argue that KDE would be preferable to XML ;)
[20:36:16] <jmkasunich> people want to run emc on lower powered boxes, KDE is not light
[20:36:26] <alex_joni> look at puppy ;)
[20:36:27] <petev> I think we should only be tied to external libs that are popular and have debs and rpms for install
[20:36:40] <jmkasunich> does puppy use KDE or a lightweight window manager?
[20:36:42] <SWPadnos_> kde-libs is a separate deb
[20:36:50] <SWPadnos_> very lightweight
[20:36:54] <alex_joni> puppy is 30 MB overall
[20:36:57] <SWPadnos_> (at least, it looks like it should be ;) )
[20:37:03] <alex_joni> with web-browser, emc2, etc.
[20:37:23] <petev> what is the future replacement for BDI?
[20:37:28] <jmkasunich> alex: I know what it is, but does it use KDE, or something else?
[20:37:38] <SWPadnos_> kde comments are 30M
[20:37:39] <alex_joni> no way KDE gets in 20MB
[20:37:51] <SWPadnos_> or the icons ;)
[20:37:55] <petev> jmk: puppy is pretty crude if u ask me
[20:38:03] <petev> alex, look at dsl
[20:38:04] <alex_joni> KDE is about 2-300 MB at least
[20:38:07] <cradek> I'll shoot someone (maybe myself) if we require kde libraries to run emc
[20:38:08] <alex_joni> dsl?
[20:38:09] <SWPadnos_> puppy with WindoMaker would be good
[20:38:24] <alex_joni> did I say I hate tcl?
[20:38:32] <SWPadnos_> I don't recall
[20:38:38] <alex_joni> I HATE TCL
[20:38:39] <cradek> who hasn't said that?
[20:38:40] <petev> alex:
http://www.damnsmalllinux.org/
[20:38:47] <SWPadnos_> kde libs, not necessarily KDE proper
[20:39:06] <alex_joni> SWPadnos_: that's stupid IMHO, keeping some KDE libs just for fun
[20:39:27] <petev> alex: many of the packages are like that
[20:39:35] <petev> the GTK stuff was all for gnome
[20:39:38] <petev> what's the diff?
[20:39:40] <SWPadnos_> it's no different, IMO than XML libs (unless they're inextricably tied to the KDE environment)
[20:39:43] <alex_joni> yeah.. I know ..
[20:39:56] <SWPadnos_> or qconfig, for that matter
[20:40:07] <alex_joni> but usually you have lots of dependencies on kde-libs
[20:40:13] <alex_joni> like kde-core & u name it
[20:40:29] <alex_joni> but I don't know enough to go into details.. so I'll shut up
[20:40:33] <petev> well each lib should be evaluated to depends, etc. before deciding to use it
[20:40:35] <alex_joni> and fight with tkemc some more
[20:40:52] <petev> to/for
[20:41:04] <SWPadnos_> kdelibs doesn't depend on kdecore
[20:41:44] <SWPadnos_> on my Ubuntu machine, it's a metapackage that depends on kdelibs4c2, kdelibs-bin, and kdelibs-data
[20:42:06] <SWPadnos_> likely, the only needed part of that would be kdelibs4c2
[20:42:32] <SWPadnos_> which is around 30M O_O
[20:43:22] <jmkasunich> ok, how the hell did we get into KDE packages anyway
[20:43:34] <jmkasunich> we started talking about config directories
[20:43:53] <SWPadnos_> their config method allows us to use the ini file format, but get many of the desired features of XML
[20:43:57] <jmkasunich> we're talking about emc-2.0.1 here
[20:44:08] <alex_joni> what's a print in tcl?
[20:44:12] <SWPadnos_> echo
[20:44:53] <alex_joni> nope
[20:45:12] <jmkasunich> can I suggest that user specific configs be deferred to emc-2.2.1?
[20:45:36] <alex_joni> what do you mean by user-specific configs?
[20:45:52] <SWPadnos_> yes
[20:46:00] <SWPadnos_> what do you mean print, alex?
[20:46:11] <alex_joni> puts
[20:46:16] <jmkasunich> thats how this started - formeman logs i as user "boss" and wants to run axis, workers log in as user 'peon' and have to use mini
[20:46:19] <SWPadnos_> ok -then use puts
[20:46:36] <alex_joni> defer
[20:46:54] <alex_joni> that'll only drag the release out
[20:46:54] <SWPadnos_> 2.2.0 maybe (assuming the old kernel numbering scheme)
[20:47:00] <jmkasunich> yet both "boss' and 'peon' need the other 90% of thier config the same (machine speficic stuff)
[20:47:03] <alex_joni> 2.1.x then ;)
[20:47:14] <SWPadnos_> maybe that's the way to do all these branches, BTW
[20:47:16] <alex_joni> peon only needs to know the name
[20:47:19] <jmkasunich> I just started using that, but I think I'm gonna propose it
[20:47:25] <SWPadnos_> make a 2.0-stable and a 2.1-devel branch at the outset
[20:47:26] <jmkasunich> (the kernel numbering
[20:47:41] <SWPadnos_> I'd vote for that
[20:47:49] <jmkasunich> yes, 2.0.1 is the release, 2.0.2, etc are bugfixes
[20:48:08] <jmkasunich> 2.1.1, .2, .3, are testing/development releases
[20:48:14] <SWPadnos_> 2.1.0-xx are development, on a 2.1
[20:48:37] <SWPadnos_> no - .2 wouldn't be - 2.2 would be a point release of a stable 2.x series
[20:48:39] <jmkasunich> why the -xx
[20:48:57] <SWPadnos_> aI should have written 2.1.0 - 2.1.xx
[20:49:15] <jmkasunich> yes, we both meant the same thing
[20:49:29] <jmkasunich> I meant 2.1.1, 2.1.2, 2.1.3, etc
[20:49:35] <SWPadnos_> ok ;)
[20:49:42] <alex_joni> 2.1.99 :P
[20:49:48] <jmkasunich> .999
[20:49:53] <SWPadnos_> english - the language of ambiguity
[20:50:01] <alex_joni> and petev is talking about 99.1.xx
[20:50:02] <alex_joni> :D
[20:50:12] <jmkasunich> petev is talking about 3.0.1
[20:50:14] <alex_joni> or maybe only 3.1.xx
[20:50:22] <jmkasunich> emc2 = 2.x.x, emc3 = 3.x.x
[20:50:27] <SWPadnos_> 2.9.xx - the branch before 3.0
[20:50:28] <alex_joni> I think 2.9.xx is more appropiate
[20:50:31] <alex_joni> yeah
[20:50:42] <alex_joni> and 3.0.x the realease :D
[20:50:52] <jmkasunich> 2.9 is the branch after 2.8
[20:51:12] <SWPadnos_> yes, and in preparation for 3.0
[20:51:29] <jmkasunich> not really, for all we know, 2 will last thru 2.24
[20:51:35] <SWPadnos_> true
[20:51:57] <jmkasunich> 3.0.1 is the first release of emc3
[20:52:01] <alex_joni> 2.999 ? :D
[20:52:15] <alex_joni> start with 3.-1.xx then
[20:52:16] <alex_joni> :D
[20:52:16] <jmkasunich> just like we're approaching 2.0.1 as the first release of emc2, even tho its been in the works for two years
[20:52:42] <jmkasunich> alex: just start with CVS, like we are in emc2 now
[20:52:49] <alex_joni> yeah.. ok
[20:55:18] <alex_joni> so.. how about the configs/ dir for emc2 now?
[20:55:20] <alex_joni> should I commit=
[20:55:22] <alex_joni> ?
[20:55:23] <jmkasunich> getting back to alex's original questions... lets focus on stuff that directly moves us toward releasing 2.0.1
[20:56:04] <jmkasunich> let me say some stuff without interrupting, then stand back and hear other's ideas
[20:56:20] <jmkasunich> configs should be nearly empty of files, only have subdirs
[20:56:35] <jmkasunich> in CVS, there are several subdirs with "standard" configs
[20:57:08] <jmkasunich> when the user starts emc2 for the first time, it looks in configs for some kind of "marker" file that tells it which subdir to use
[20:57:22] <jmkasunich> since it is the first time, the marker isn't there (no marker in CVS)
[20:57:45] <jmkasunich> so it asks him which standard config does he wnat to start with, and what name does he want to give it
[20:58:28] <jmkasunich> then it does mkdir <newname> and cp <standard>/* <newname>/*, and creates the marker, so subsequent startups will go to <newname> and skip that step
[20:58:47] <jmkasunich> anytime, he can explicitly specify a subdir when he starts, and it uses that one
[20:58:53] <jmkasunich> ok, now I shut up
[20:59:46] <alex_joni> sounds good.. just some ideas
[20:59:57] <alex_joni> 1. the top configs/ dir shouldn't be completely empty imho
[21:00:01] <alex_joni> default stuff can be there
[21:00:09] <alex_joni> like nml files
[21:00:15] <alex_joni> NO-ONE touches those
[21:00:23] <alex_joni> or very unlikely at least
[21:00:36] <jmkasunich> I would also say that NO-ONE touches anything in any of the standard configs
[21:00:42] <jmkasunich> they should always match CVS
[21:00:47] <alex_joni> core_servo / stepper / sim, could be there too
[21:01:01] <jmkasunich> I'd put those in their own standard config dirs
[21:01:10] <alex_joni> hal/ ?
[21:01:16] <jmkasunich> yes
[21:01:22] <alex_joni> so say I have a stg
[21:01:34] <alex_joni> stg/stg.ini stg/stg_io.hal stg/stg_motion.hal
[21:01:35] <jmkasunich> each standard config dir would be a complete setup, ready to be copied and modified for a users needs
[21:01:49] <jmkasunich> yes
[21:01:53] <alex_joni> hal/core_servo.hal ?
[21:02:09] <jmkasunich> I see your point
[21:02:20] <alex_joni> or stg/core_servo.hal ?
[21:02:32] <petev> can't you just say hal/core_servo.hal in the stg file?
[21:02:35] <jmkasunich> NOT hal/code_servo.hal
[21:02:42] <jmkasunich> s/code/core
[21:03:02] <jmkasunich> but stg/core_servo.hal means multiple copies of core_servo, thats bad
[21:03:06] <alex_joni> petev: you can, and I also can make it to find it by it's own
[21:03:22] <jmkasunich> what is "it"?
[21:03:29] <alex_joni> jmk: how about parsing the stg.ini the first time, and looking for hal files, and copy those over to the user dir?
[21:03:48] <SWPadnos_> the person configuring the machine should probably bve explicit about the version (e.g., of core_servo) they want to use
[21:03:59] <alex_joni> petev: you can, and I also can make it to find hal/core_servo.hal by it's own (even if only core_servo.hal is specified)
[21:04:02] <petev> alex: no, cause cvs updates with new HAL pins will break it
[21:04:09] <SWPadnos_> so they should have ../core/core_servo.hal
[21:04:26] <jmkasunich> again it comes down to which files are standard (never modified by the user, keep up to date from CVS) and which ones are custom (modified by user, CVS shouldn't touch)
[21:04:27] <petev> I think fully specify the HAL file from the config dir down
[21:04:39] <petev> if the user wants his own, he can change his INI
[21:04:56] <alex_joni> petev: I'm ok with that for emc.nml for example
[21:05:12] <alex_joni> but core_servo.hal is something that might change in the case of motmod to change
[21:05:24] <alex_joni> and I'd want the user to get that without needing to edit by himself
[21:05:28] <jmkasunich> I'm very nervous about having a users ini file point to a common file
[21:05:36] <petev> alex: right, that's why other ini should point to a single hal core_servo
[21:05:45] <jmkasunich> how do you force them to copy the common file before they edit it?
[21:05:46] <petev> jmk: why?
[21:06:00] <petev> when they CVS up, they will learn
[21:06:12] <jmkasunich> not the way to treat newbies
[21:06:27] <jmkasunich> and besides, they probably don't have cvs, they're getting this from a tarball
[21:06:32] <petev> if it's not common, when they cvs up it will be more painful
[21:06:56] <petev> jmk: u assume emc is too stable
[21:07:04] <petev> every user I know cvs up on emc2
[21:07:10] <jmkasunich> if its a file they never edit, then it can (and should) be common
[21:07:28] <petev> how often do you edit core_servo.hal?
[21:07:36] <jmkasunich> if its a file they always edit, it should be copied,and they will have to manually apply updates
[21:07:39] <petev> only when you make code changes for the most part
[21:07:42] <jmkasunich> the bad ones are the ones in between
[21:08:10] <jmkasunich> right now lots of people are editing core_stepper.hal to deal with the thrice-damned overhead problem
[21:08:30] <alex_joni> but that can be overcome by the ini param you put in
[21:08:35] <petev> so maybe there is something in core_stepper that shouldn't be there?
[21:08:35] <jmkasunich> yes
[21:08:40] <SWPadnos_> maybe there should be a few default configs in cvs, then have a new module called configs, to house the extras
[21:08:57] <jmkasunich> SWP: rather not
[21:09:01] <alex_joni> right
[21:09:07] <alex_joni> ok.. let's rewind a bit
[21:09:10] <jmkasunich> configs aren't that big, keep everything together
[21:09:16] <alex_joni> we agree that we want configs/foo
[21:09:22] <petev> yes
[21:09:26] <jmkasunich> yes
[21:09:31] <alex_joni> and most of them have some common stuff like emc.nml
[21:09:32] <jmkasunich> foo being user specific
[21:09:40] <SWPadnos_> ok
[21:09:42] <alex_joni> which won't ever get changed by the user
[21:09:59] <alex_joni> foo beeing = stepper, stg, motenc, sim, user_specific, etc
[21:10:10] <jmkasunich> split out user specific
[21:10:25] <alex_joni> 1. when emc runs the first time it looks for configs/default
[21:10:30] <jmkasunich> stepper, stg, motenc, etc are templates
[21:10:38] <alex_joni> without the first time..
[21:10:47] <petev> jmk: to become user specific, no?
[21:10:47] <alex_joni> when emc runs it looks for configs/default
[21:11:13] <alex_joni> if it's not there it informs the user there is no default configuration, and that he should chose a template
[21:11:19] <jmkasunich> petev: user should never edit anything in configs/stepper, configs/stg, etc
[21:11:20] <alex_joni> from the configs/* list
[21:11:32] <jmkasunich> always copy to new dir, then edit
[21:11:40] <alex_joni> next it will copy the template to configs/default
[21:11:43] <petev> jmk: right, but they will copy and mod those files
[21:12:19] <jmkasunich> petev: they will not use cp, we should do the mkdir and cp for them
[21:12:28] <petev> ok
[21:12:34] <alex_joni> I agree
[21:12:54] <jmkasunich> alex: with you so far (except I don't like "default"), we can discuss that when you finish
[21:13:00] <alex_joni> so what's in configs/. ?
[21:13:09] <jmkasunich> mostly directiryes
[21:13:17] <jmkasunich> if I could spell anwyay
[21:13:21] <jmkasunich> fsck
[21:13:21] <alex_joni> jmkasunich: maybe prompt the user for a name, and use that following on
[21:13:28] <jmkasunich> mostly directories
[21:13:33] <jmkasunich> yes
[21:13:38] <alex_joni> jmkasunich: never mind the spelling.. we all can read IRC
[21:13:42] <petev> alex_joni: are you going to do this all command line?
[21:13:50] <alex_joni> petev: for now yes
[21:13:55] <alex_joni> in the run script
[21:13:59] <petev> ok
[21:14:00] <alex_joni> a few lines should do it
[21:14:10] <alex_joni> lateron this can be extended
[21:14:13] <petev> sure
[21:14:24] <alex_joni> up to the point where you have a dropdown on the GUI with load config
[21:14:28] <jmkasunich> alex: I'd recommend that the "prompt, then mkdir, cp, etc" be a separate script, invoked by the run script
[21:14:42] <jmkasunich> then later we can easily replace it with a fancier wizard
[21:14:44] <alex_joni> and the gui restarts (along with emc) with the new config
[21:14:48] <alex_joni> jmkasunich: ok
[21:14:58] <alex_joni> so.. how about the hal stuff?
[21:15:07] <alex_joni> do it like I said?
[21:15:19] <alex_joni> parse the template ini, and copy all the hal files to the user dir?
[21:15:30] <jmkasunich> configs/core has core_stepper, etc
[21:15:32] <petev> I hate to see the core hal files copied
[21:15:39] <jmkasunich> configs/stg has stgio.hal
[21:15:47] <alex_joni> jmk: yes on that
[21:15:47] <jmkasunich> the ini invokes them with paths
[21:16:17] <jmkasunich> however each ini also invokes custom.hal, and that is copied
[21:16:32] <jmkasunich> so if the user wants to customize he can do it there
[21:16:50] <jmkasunich> custom.hal is invoked last, so it can override settings made by the standard files
[21:16:54] <petev> jmk: so if the full path is specified, then no copy?
[21:17:01] <jmkasunich> right
[21:17:05] <petev> ok
[21:17:13] <jmkasunich> actually, it can be simpler than that
[21:17:31] <jmkasunich> never mind, I take that back
[21:17:48] <alex_joni> ok.. say that again for me please
[21:17:52] <jmkasunich> heh
[21:18:11] <alex_joni> I have stg/stg_io and stg/stg_motion.hal
[21:18:11] <jmkasunich> I retracted the "simpler than that" part
[21:18:12] <petev> if the INI file calls out a full path to the HAL file, then don't copy it
[21:18:17] <alex_joni> and core/core_servo.hal
[21:18:27] <jmkasunich> and stg/stg.ini
[21:18:32] <alex_joni> petev: you're assuming some stuff I'm not
[21:18:38] <alex_joni> jmkasunich: right
[21:18:43] <jmkasunich> and core/custom.hal (empty except for some comments)
[21:18:54] <alex_joni> OK
[21:19:19] <alex_joni> stg.ini specifies: stg_io.hal, stg_motion.hal and ../core/core_servo.hal
[21:19:30] <alex_joni> and custom.hal
[21:19:31] <jmkasunich> when you create a new dir "mystg" from template "stg", you need to copy stg/stg.ini to mystg/mystg.ini
[21:19:40] <alex_joni> ok so far
[21:19:46] <jmkasunich> core/custom.hal to mystg/custom.hal
[21:19:54] <alex_joni> right, that too
[21:20:01] <jmkasunich> what else gets copied?
[21:20:03] <jmkasunich> var file?
[21:20:05] <alex_joni> also stg/*.hal mystg/*.hal
[21:20:18] <alex_joni> var file, tbl file
[21:20:41] <jmkasunich> ok, why are we copying *.hal ( stgio.hal and stgmotion.hal)?
[21:20:53] <jmkasunich> so they can customize pinouts, right?
[21:21:03] <alex_joni> yes
[21:21:11] <alex_joni> and axis assignments
[21:21:27] <jmkasunich> then they really don't need custom.hal, because they have two private hal files already
[21:21:27] <alex_joni> just had this with till, he had a faulty encoder on axis 2 and used the one on axis 6
[21:21:37] <alex_joni> right
[21:21:42] <petev> jmk: almost true
[21:21:46] <petev> custom should run last
[21:21:59] <alex_joni> but custom.hal empty there will make the life easier for the user
[21:22:03] <petev> that may not be the case for other HAL, but why paint into a corner
[21:22:06] <alex_joni> we can argue about that later
[21:22:16] <jmkasunich> I have no problem keeping custom
[21:22:22] <alex_joni> ok
[21:22:35] <jmkasunich> I thought we were trying to avoid copying the stg_xx.hal files tho
[21:22:41] <alex_joni> another question: how about existing templates, can we run those?
[21:22:50] <alex_joni> jmkasunich: no we were not
[21:23:07] <jmkasunich> just trying to avoid copying the core-xxx ones?
[21:23:08] <alex_joni> I mean: should we be able to run templates fresh out of CVS?
[21:23:15] <petev> jmk: we don't want to copy the core hal files
[21:23:15] <alex_joni> jmkasunich: you are yes..
[21:23:29] <alex_joni> I'd let them where they are and use them from there
[21:23:40] <alex_joni> only copy what is in the foo/ dir
[21:23:45] <petev> yes
[21:23:51] <jmkasunich> alex: agreed
[21:23:54] <alex_joni> and not even that
[21:24:00] <alex_joni> I mean.. copy it
[21:24:02] <SWPadnos_> um - if the config dirs contain "emc.ini", "core.hal", "io.hal", and "motion.hal", can't you just copy the files to a new dir?
[21:24:14] <SWPadnos_> leave off the xtg_, ppmc_, m5i20_...
[21:24:17] <SWPadnos_> stg
[21:24:20] <jmkasunich> yes
[21:24:26] <jmkasunich> excellent idea
[21:24:34] <jmkasunich> (IMO)
[21:24:38] <SWPadnos_> thank you
[21:24:38] <alex_joni> what is?
[21:24:54] <SWPadnos_> have the names for function, not for the driver in use
[21:25:01] <jmkasunich> instead of stg/stg_io.hal, have stg/io.hal
[21:25:03] <SWPadnos_> emc.ini = the ini file for emc
[21:25:11] <SWPadnos_> io.hal = the io configuration for hal
[21:25:13] <SWPadnos_> ...
[21:25:35] <alex_joni> that comes back to my question: should we be able to run templates?
[21:25:38] <jmkasunich> after copy, it is mymachine/io.hal, mymachine/emc.ini
[21:25:41] <alex_joni> without the copy stuff ?
[21:25:43] <jmkasunich> yes
[21:25:46] <alex_joni> OK
[21:25:54] <jmkasunich> if they are a subdir of configs, they should be runnable
[21:26:14] <alex_joni> I don't like having them all called io.hal
[21:26:18] <jmkasunich> in fact, that is an argument for not putting the core stuff in a subdir, but keeping it a toplevel
[21:26:23] <jmkasunich> why not?
[21:26:24] <alex_joni> that's hard to debug on stupid users
[21:26:32] <jmkasunich> thats what subdirs are for
[21:26:32] <alex_joni> ask him what he's running
[21:26:37] <alex_joni> mymachine/
[21:26:41] <alex_joni> ok.. what's in there?
[21:26:44] <alex_joni> io.hal
[21:26:49] <alex_joni> and emc.ini
[21:26:58] <SWPadnos_> and motion.hal
[21:27:00] <alex_joni> no clue if it's stg or motenc
[21:27:06] <alex_joni> or m5i20
[21:27:16] <SWPadnos_> you need to look in the file
[21:27:26] <petev> guys, how about u just make links in the config dir to the correct files in sub dir?
[21:27:28] <alex_joni> and you can't trust aunt tillie to look in the motion.hal and figure out what he selected
[21:27:41] <jmkasunich> during the copy from template: touch mymachine/<templatename>
[21:27:41] <SWPadnos_> a stupid user might take stg.hal, and have it load ppmc tomorrow - the name doesn't tell you what's in the file
[21:28:01] <alex_joni> SWPadnos_: unlinkely
[21:28:19] <jmkasunich> the stupid user won't do that, the one too smart for his own good will
[21:28:34] <SWPadnos_> well - I changed emc.ini to load ppmc.hal ....
[21:28:39] <jmkasunich> the one who really wants to customize
[21:28:41] <petev> just make io.hal->stg/stg_io.hal
[21:28:45] <petev> etc..
[21:28:52] <alex_joni> petev: that's bad
[21:28:57] <petev> why
[21:28:58] <jmkasunich> no symlinks
[21:29:03] <alex_joni> if he changes pinouts.. he'll get problems on cvs up
[21:29:07] <petev> the config script makes them
[21:29:24] <petev> alex: I don't follow
[21:29:25] <SWPadnos_> petev: there are two things going on, one, the desire to have common files, and two - the desire to have separate configs
[21:29:27] <SWPadnos_> (trying to balance them is tricky)
[21:29:29] <jmkasunich> that directory is his playground, he should be able to edit anything in there without touching the standard files
[21:29:38] <petev> swp: I understand
[21:29:44] <petev> right
[21:29:55] <petev> I'm saying u copy the files to some user dir
[21:29:59] <petev> then make links to it
[21:30:07] <petev> that's how emc knows what to run
[21:30:17] <jmkasunich> once copied, the links don't buy you mich
[21:30:19] <jmkasunich> much
[21:30:23] <alex_joni> that's ok.. but not the issue we debate now
[21:30:33] <alex_joni> jmkasunich: link that you know what default dir to run
[21:30:42] <alex_joni> either symlink, or a file saying that
[21:30:48] <petev> yes
[21:30:56] <alex_joni> petev: we all agree on that
[21:30:58] <petev> ok
[21:31:03] <alex_joni> the problem is with common hal files
[21:31:14] <jmkasunich> assume configs has 5 standard subdirs, and two user created ones
[21:31:19] <alex_joni> 1. duplicate them all over the subdirs (bad)
[21:31:23] <jmkasunich> if you run emc without an arg, which does it run
[21:31:26] <petev> I thought we decided to copy whatever was in configs/foo
[21:31:36] <alex_joni> 2. run them always from the same place
[21:31:43] <petev> jmk: it runs what the symlink points to
[21:31:43] <alex_joni> 3. copy them over to his playground
[21:32:00] <alex_joni> jmk: the last one configured by emc-config
[21:32:04] <jmkasunich> alex: what od you mean by common? the core_xxxx ones, or stg_xxx.hal?
[21:32:09] <alex_joni> core
[21:32:14] <alex_joni> stg_xxx is not common
[21:32:17] <alex_joni> that's stg specific
[21:32:37] <alex_joni> it belongs in configs/stg/ and it gets copied along with the whole dir
[21:32:39] <jmkasunich> core are invoked in the ini by path... if we don't have a configs/core dir, it would be ../core_stepper.hal
[21:32:52] <jmkasunich> then stg-io.hal (or just io.hal)
[21:33:07] <jmkasunich> the io file would be a copy, in his playground
[21:33:11] <petev> jmk: we should have a core or common dir
[21:33:28] <alex_joni> jmkasunich: that's how I have it now
[21:33:38] <alex_joni> without the core/ dir, but I can easily add that
[21:33:42] <jmkasunich> pete: I kinda agree, except... every subdir in configs/ should be a runnable config
[21:33:44] <alex_joni> so we start to agree
[21:33:47] <jmkasunich> is core runnable?
[21:33:51] <alex_joni> nope
[21:34:15] <petev> jmk: why every one runnable? for config script choices?
[21:34:18] <jmkasunich> its more like a library than a config itself
[21:34:33] <jmkasunich> you start out with a group of "stock" configs
[21:34:43] <jmkasunich> runnable for developer testing if nothing else
[21:34:56] <jmkasunich> then you make your custom by copying one of the stock ones and modifying it
[21:35:10] <petev> yeah, but it's ugly to clutter configs with a bunch of core stuff
[21:35:18] <petev> some of which isn't even used on the machine
[21:35:26] <jmkasunich> we can treat the core dir as a special case
[21:35:27] <SWPadnos_> I have an idea for a change to halcmd (or a sister program), that may have bearing on this discussion (though it's more far-ranging than where to put configs)
[21:35:39] <petev> jmk: agreed, special case
[21:36:03] <jmkasunich> if its far ranging, we don't wanna know now unless it affects what we're deciding right now
[21:36:06] <SWPadnos_> would you like me to wait (since it's more of a change than you're talking about)
[21:36:10] <SWPadnos_> it could
[21:36:16] <jmkasunich> spit it out
[21:36:23] <SWPadnos_> I'll toss out the concept, and you can decide if I shuold wait
[21:36:40] <petev> and I'm the trouble maker ;-)
[21:37:09] <SWPadnos_> what if halcmd or something like it could read an ini file, and take settings from it (such as [ppmc.0]stepgen.00-03.scale = 43.2
[21:37:26] <SWPadnos_> you can put the whole thing into a single file if you like
[21:37:38] <jmkasunich> technicaly you can do that now
[21:37:49] <SWPadnos_> not really
[21:37:51] <jmkasunich> look at the [HAL] section of an ini file
[21:38:00] <alex_joni> http://solaris.cs.utt.ro/emcstuff/configs.tar.gz
[21:38:02] <jmkasunich> there are two parts, one a list of hal files, the other a list of hal commands
[21:38:05] <alex_joni> look at that guys..
[21:38:09] <SWPadnos_> if you include every possible param in the .hal file, you'll get a zzillion errors when things aren't found
[21:38:12] <jmkasunich> you could put 100 hal commands in there
[21:38:25] <SWPadnos_> ok - in that case you can (sort of)
[21:38:56] <jmkasunich> that was added so if you needed one or two hal commands to tweak your config you wouldn't have to edit a hal file or make a new one
[21:39:16] <SWPadnos_> OK - that might be a good first step toward what I envision
[21:39:18] <alex_joni> jmkasunich: seen the tar.gz I posted?
[21:39:25] <jmkasunich> looking now
[21:39:27] <petev> alex_joni: that's good but make a core or common dir
[21:39:33] <alex_joni> * alex_joni wants to finish today..
[21:39:47] <alex_joni> and there's only 21 minutes left of it..
[21:39:48] <SWPadnos_> (one part of my idea is that you can use shorthand for the actual param names inside e.g. the ppmc section)
[21:39:49] <alex_joni> :D
[21:40:00] <jmkasunich> where are the inis?
[21:40:07] <jmkasunich> mazak.ini, stg.ini?
[21:40:10] <alex_joni> in some dirs..
[21:40:17] <alex_joni> those don't exist in CVS today
[21:40:23] <alex_joni> we need to add them
[21:40:27] <jmkasunich> ok
[21:40:35] <alex_joni> you never commited the mazak.ini :P
[21:40:45] <jmkasunich> did so
[21:40:49] <alex_joni> the mazak ini is there
[21:40:55] <alex_joni> in the mazak dir
[21:41:01] <jmkasunich> duh
[21:41:02] <SWPadnos_> ppmc actually may need two dirs, one for USC and one for PWM
[21:41:02] <jmkasunich> sorry
[21:41:04] <alex_joni> maybe mazak_rf/ is more appropiate
[21:41:13] <jmkasunich> rf means roland friestad
[21:41:21] <jmkasunich> that is specific to his machine
[21:41:22] <alex_joni> retrofit
[21:41:23] <alex_joni> :P
[21:41:32] <SWPadnos_> ReFurbish
[21:41:39] <jmkasunich> note: I don't want to just copy all the stuff that is in there to the new layout
[21:41:50] <jmkasunich> I don't think we should have a "mazak" directory
[21:41:58] <petev> jmk: so where do we put sample stuff like the RF mazak?
[21:41:59] <alex_joni> OK.. so that one can be left out
[21:42:07] <alex_joni> petev: wiki ;)
[21:42:12] <petev> ok
[21:42:27] <SWPadnos_> there probably should be an example dir, with some more comples configs (including larger ladders)
[21:42:27] <alex_joni> wiki, dropbox, ini-server whatever
[21:42:34] <SWPadnos_> complex
[21:42:57] <jmkasunich> we might want to keep it in CVS, but we don't want it be be called "mazak"
[21:43:05] <jmkasunich> it is a case study
[21:43:10] <alex_joni> ok.. so what's wrong with the tar.gz ?
[21:43:14] <alex_joni> 1. the mazak stuff
[21:43:18] <SWPadnos_> casestudies/mazak_rf
[21:43:23] <jmkasunich> ppmc needs split into usc and upc
[21:43:27] <petev> no core or common dir
[21:43:30] <alex_joni> 2. configs/*.hal to configs/core/ ?
[21:43:41] <petev> xylotex_pinout.hal under configs
[21:43:54] <jmkasunich> standard pinout and xylotexpinout should be in the stepper dir
[21:44:15] <petev> client.nml under configs
[21:44:16] <jmkasunich> simulated_limits.hal to sim/
[21:44:23] <petev> should it be under core/common?
[21:44:38] <jmkasunich> no
[21:44:44] <petev> standard_pinout.hal under configs
[21:44:46] <jmkasunich> its only used for testing an such
[21:44:55] <jmkasunich> if you don't have real limits, you use soft limits
[21:45:05] <alex_joni> jmkasunich: I would want to have an stepper-mm in there
[21:45:07] <jmkasunich> sim limits uses HAL comps to simluate real limit switches
[21:45:09] <petev> we don't want anything in configs, except dirs and sym links, no?
[21:45:25] <alex_joni> that's why I left the standard_pinout.hal and xylotex
[21:45:48] <alex_joni> what's wrong with nml files in the configs/ dir?
[21:46:00] <petev> why not in common?
[21:46:10] <alex_joni> petev: because it's a PITA to move them
[21:46:21] <jmkasunich> not a very good reason
[21:46:24] <petev> can't you just add it to the paths
[21:46:24] <alex_joni> unless you specify ../common/emc.nml in your ini
[21:46:26] <jmkasunich> I'll help
[21:46:35] <alex_joni> jmkasunich: not CVS worries me
[21:46:38] <jmkasunich> (editing all the inis)
[21:46:57] <alex_joni> ok.. so we have : ../common/emc.nml in the ini?
[21:47:00] <alex_joni> then I'm good
[21:47:03] <petev> hmm, does SF give SSH access to make the CVS stuff easy? ;-)
[21:47:12] <petev> I mean as a shell
[21:47:14] <jmkasunich> whats the differnece between ../emc.nml, and ../common/emc.nml
[21:47:19] <alex_joni> petev: again, not the CVS stuff worries me
[21:47:23] <alex_joni> jmkasunich: no difference
[21:47:40] <alex_joni> but there's a BIG difference between emc.nml and ../common/emc.nml
[21:47:54] <alex_joni> and having emc.nml from a default location
[21:48:10] <jmkasunich> alex: given that we'll have stepper-in and stepper-mm, then I agree that the pinouts can go in common....
[21:48:23] <alex_joni> ok.. so we decide on a common dir
[21:48:24] <jmkasunich> however, if somebody wants a custom pinout (not one of those) then what?
[21:48:29] <alex_joni> and hal & nml stuff goes in there
[21:48:35] <jmkasunich> then need to manually copy it
[21:48:40] <alex_joni> if someone wants a custom pinout they copy one to their dir
[21:48:44] <jmkasunich> change the ini to point to their copy
[21:48:46] <alex_joni> and the runscript will use that
[21:48:47] <jmkasunich> and edit their copy
[21:48:53] <petev> jmk: agreed, user can copy
[21:48:53] <alex_joni> no need for the ini to change
[21:49:03] <jmkasunich> ?
[21:49:08] <alex_joni> runscript looks in current dir for hal files, or common if not found
[21:49:28] <jmkasunich> the ini either says ../common/pinout.hal, or is says pinout.hal, can't say both
[21:49:28] <petev> alex: sounds ok
[21:49:37] <alex_joni> the ini says pinout.hal
[21:49:41] <jmkasunich> ok, you are getting fancy
[21:49:45] <petev> alex is saying let it say emc.nml
[21:49:49] <petev> and run will search
[21:49:53] <alex_joni> NOOOO
[21:49:56] <alex_joni> not for emc.nml
[21:49:57] <alex_joni> please
[21:50:04] <jmkasunich> be consistent
[21:50:06] <alex_joni> for HAL ok..
[21:50:10] <alex_joni> but for NML never..
[21:50:13] <petev> yes, should be all or none
[21:50:15] <jmkasunich> either you exactly follow the specified paths, or you search
[21:50:19] <alex_joni> 4 places do that
[21:50:29] <alex_joni> io, task, emcsh, iosh and axis
[21:50:30] <jmkasunich> but don't do searching sometimes and exact paths other times
[21:50:41] <alex_joni> they all open the ini and look for the nml file
[21:50:41] <petev> I agree with jmk
[21:50:54] <alex_joni> ok, then exact path it is
[21:51:19] <petev> alex, what's the prob with a file find sub?
[21:51:23] <jmkasunich> I prefer exact path anyway, that way a user editing the ini won't get confused:
[21:51:29] <petev> if exact path, no search
[21:51:34] <jmkasunich> "emc.nml? where is that?
[21:51:38] <petev> otherwise look in current, then common
[21:51:47] <alex_joni> exact path it is..
[21:51:49] <cradek> IMO explicit is always better than implicit
[21:52:02] <jmkasunich> no search at all
[21:52:08] <alex_joni> petev: want to look at a diff that does that?
[21:52:15] <petev> no
[21:52:20] <alex_joni> I already did those changes.. but they are ugly
[21:53:03] <jmkasunich> so the template inis will refer only to files in configs/common, and to names with no path
[21:53:15] <jmkasunich> the ones with no path will be copied to the users dir
[21:53:17] <alex_joni> ok
[21:53:59] <jmkasunich> and the copy doesn't need to examine the ini, it just copies the entire directory
[21:54:12] <jmkasunich> then renames the ini
[21:54:28] <alex_joni> right
[21:54:37] <alex_joni> * alex_joni is good with that
[21:54:45] <alex_joni> I'll start on it in half an hour..
[21:54:49] <alex_joni> got a bath getting cold
[21:55:05] <jmkasunich> once I finish this ppmc PWM stuff, if I can help I will
[21:55:26] <jmkasunich> uh, one other suggestion
[21:55:40] <jmkasunich> in each template directory, a description file
[21:55:43] <alex_joni> shoot
[21:55:45] <jmkasunich> just plain text
[21:55:56] <alex_joni> I'll leave that to you :P
[21:56:04] <jmkasunich> that the wizard can display when giving the user a choice of what to start with
[21:56:05] <jmkasunich> OK
[21:56:10] <alex_joni> ok.. back in 20 mins
[21:56:18] <jmkasunich> want me to do the wizard script?
[21:56:23] <alex_joni> OK
[21:56:36] <alex_joni> let me commit the emc.in stuff I changed
[21:56:41] <jmkasunich> ok
[21:57:04] <jmkasunich> I'm gonna try to wrap up this ppmc stuff
[21:57:08] <alex_joni> you need to run ./configure to change emc.in to emc
[21:57:08] <jmkasunich> jmkasunich is now known as jmk_hiding
[21:57:18] <alex_joni> and make to make it executable
[21:57:36] <jmk_hiding> "change" emc.in to emc, or copy?
[21:57:55] <jmk_hiding> I assume emc.in remains unchanged, and emc is produced
[21:58:11] <alex_joni> yes
[21:59:05] <alex_joni> after you already have run configure for the first time, config.status will work a lot faster (only does the replace in the files needed), saves some time
[21:59:26] <alex_joni> so if you (or anyone else) changes emc.in, config.status will produce a new emc
[21:59:40] <alex_joni> alex_joni is now known as alex_joni_away
[22:04:54] <SWPadnos_> jmk_hiding: would you object to a change in halcmd that allows one to just say "param = value", if the command name isn't recognized (because it's the param name)?
[22:05:14] <jmk_hiding> instead of setp param value?
[22:05:21] <SWPadnos_> in addition to setp
[22:05:24] <SWPadnos_> yes
[22:05:32] <SWPadnos_> alternative, I guess
[22:05:32] <petev> that's ugly
[22:05:38] <SWPadnos_> no - it's ini syntax
[22:05:49] <petev> it would get in the way of new HAL keywords, etc.
[22:06:01] <SWPadnos_> halcmd ppmc.0.stepgen.00-03.pulse-width = 1000
[22:06:21] <jmk_hiding> pate: actually, new (and existing) hal keywords would get in the way of parameter names
[22:06:25] <SWPadnos_> no - only if a fully qualified param name is the same as the new name
[22:07:19] <jmk_hiding> if you tried that syntax with a parameter whose name matches a keyword, you won't get the assignment you expect
[22:07:21] <SWPadnos_> it would only happen if the command name isn't recognized
[22:07:46] <SWPadnos_> you'd get an error, becuase "=" wouldn't be likely to match a valid first parameter for the command
[22:07:54] <jmk_hiding> its not totally ugly, but it ain't gonna win any beauty contests
[22:08:01] <jmk_hiding> I suppose I have no real objection
[22:08:25] <SWPadnos_> it would allow one to put hal commands that look like ini settings into the ini file, or make parameter .hal files that look a lot like ini files
[22:08:36] <SWPadnos_> ok - I'll think about it. I think it's about a 10-line change
[22:08:55] <jmk_hiding> basically you are saying "if you don't recognize the command, assume its an setp"
[22:09:01] <SWPadnos_> yep
[22:09:11] <jmk_hiding> "but require there to be an equal sign in it"
[22:09:15] <SWPadnos_> yep ;)
[22:09:25] <jmk_hiding> is = safe on the command line
[22:09:27] <jmk_hiding> ?
[22:09:32] <cradek> yes
[22:09:38] <jmk_hiding> I know arrows arent, because of the redirection at >
[22:09:57] <SWPadnos_> this is mostly intended for ini files anyway, so shell issues wren't a big deal
[22:10:04] <SWPadnos_> (and you can always quote
[22:10:06] <SWPadnos_> )
[22:10:16] <SWPadnos_> and at <
[22:10:26] <jmk_hiding> right, I was being lazy
[22:10:32] <SWPadnos_> ;)
[22:10:50] <SWPadnos_> anyway, thanks for the answer - you can go back into hiding
[22:10:56] <SWPadnos_> (if you like)
[22:11:04] <jmk_hiding> .......
[22:26:39] <alex_joni_away> alex_joni_away is now known as alex_joni
[22:26:54] <alex_joni> make clean finished ;)
[22:28:53] <alex_joni> ok.. I'm unleashing the config-hell
[22:41:46] <alex_joni> jmk_hiding: one quick question
[22:42:06] <jmk_hiding> ok
[22:42:26] <alex_joni> you don't have anything with the names I chose.. right?
[22:42:44] <alex_joni> because after I add them to CVS it'll be too late
[22:42:47] <jmk_hiding> I have some problems with some names
[22:42:49] <jmk_hiding> right
[22:43:01] <alex_joni> then say now
[22:43:12] <jmk_hiding> question: do we need inch and mm variations?
[22:43:18] <alex_joni> YES
[22:43:34] <alex_joni> those seem to cause the most problems with new users
[22:43:35] <jmk_hiding> if we need them for steppers, then we need them for stg, and motenc, and so on and so on
[22:43:40] <alex_joni> but maybe an aditional foo/foo_mm.ini is ok
[22:43:46] <SWPadnos_> how about core_units.hal
[22:43:55] <alex_joni> SWPadnos_: go hide ;)
[22:43:56] <jmk_hiding> hal doesn't see units
[22:44:01] <SWPadnos_> (though it's ini stuff, I guess)
[22:44:02] <jmk_hiding> the problem is in the ini file
[22:44:12] <alex_joni> SWPadnos_: kidding..
[22:44:13] <SWPadnos_> * SWPadnos_ goes back to freeciv^Hcoding
[22:44:19] <alex_joni> ok.. how about what I propose?
[22:44:28] <alex_joni> foo/foo.ini and foo/foo_mm.ini ?
[22:44:44] <jmk_hiding> foo/foo_in.ini and foo/foo_mm.ini
[22:44:50] <alex_joni> right
[22:44:57] <jmk_hiding> no reason to treat inches as the standard
[22:45:07] <alex_joni> and the script you're making figures out what the user wants
[22:45:09] <alex_joni> OK
[22:45:16] <jmk_hiding> I assume the wizard would copy only one to the new dire
[22:45:19] <jmk_hiding> dir
[22:45:31] <jmk_hiding> but when you run directly from the foo dir.... which do you get?
[22:45:35] <alex_joni> I'm happy with that
[22:45:44] <alex_joni> nothing.. you get ini not found ;)
[22:45:49] <petev> make symlinks
[22:45:50] <alex_joni> unless you specify _in or _mm
[22:45:59] <jmk_hiding> because it looks for foo, not foo_in
[22:46:14] <alex_joni> it could look for foo_in
[22:46:20] <alex_joni> or maybe even better ;)
[22:46:28] <alex_joni> look at the users TIMEZONE and decide mm or in
[22:46:29] <alex_joni> :D
[22:46:32] <alex_joni> LOL
[22:46:51] <jmk_hiding> would it be too krufty to have the ini look first for foo.ini, if not found, look for foo_in and foo_mm, if only one found, use it, if both, prompt user?
[22:47:00] <alex_joni> not a problem
[22:47:24] <alex_joni> we already have foo in the script, only need to append _in or _mm
[22:47:27] <alex_joni> I'll do that
[22:47:33] <jmk_hiding> beats having twice as many directories
[22:47:39] <alex_joni> yes
[22:47:40] <petev> why not just do *.ini and if more than 1 ask user?
[22:47:46] <petev> then make a symlink for run
[22:48:00] <alex_joni> petev: will you drop the symlink already ? :D
[22:48:12] <alex_joni> but it's a good idea
[22:48:14] <jmk_hiding> symlinks such
[22:48:26] <jmk_hiding> if there is foo/foo.ini, use it unconditionally
[22:48:31] <alex_joni> jmk_hiding: then a hardlink :)
[22:48:38] <jmk_hiding> if not, then do ls *.ini, and give a menu
[22:48:41] <alex_joni> he said only if there are 2, ask the user which to use
[22:48:53] <alex_joni> and link foo.ini to that one
[22:49:01] <alex_joni> but cp would be just as good if not better
[22:49:02] <SWPadnos_> but then there are 3
[22:49:02] <petev> alex_joni: actually, if there are more than 1
[22:49:08] <alex_joni> petev: yes
[22:49:18] <alex_joni> that's what I meant
[22:49:28] <jmk_hiding> thats where we disagree - I don't care if there are 20, if one of them matches the directory name use it
[22:49:29] <alex_joni> jmk_hiding: back to directory names
[22:49:44] <alex_joni> jmk_hiding: in case it doesn't match do the above
[22:49:45] <jmk_hiding> (unless the user specifically said use foo/foo_bar.ini
[22:49:52] <jmk_hiding> yes
[22:49:55] <alex_joni> jmk_hiding: back to directory names
[22:49:58] <alex_joni> stg ok?
[22:50:07] <jmk_hiding> if match dir, use it, if not, list all and pick one
[22:50:14] <jmk_hiding> yes
[22:50:20] <alex_joni> stepper
[22:50:23] <petev> jmk: why the dir match?
[22:50:24] <jmk_hiding> stg, motenc, stepper all ok
[22:50:25] <alex_joni> step_cl
[22:50:35] <petev> seems like a source for confusion
[22:50:38] <jmk_hiding> that is a demo / case study only
[22:51:02] <alex_joni> petev: default is to have configs/foo/foo.ini
[22:51:09] <alex_joni> if user wants emc foo,
[22:51:17] <petev> right
[22:51:20] <alex_joni> the above is the default
[22:51:25] <petev> but what if foo has more ini?
[22:51:26] <jmk_hiding> if there is also configs/foo/foo_backup.ini, don't wnat to ask the user which one to use
[22:51:29] <alex_joni> if that exists that gets run
[22:51:34] <petev> user will wonder why he didn't get asked
[22:52:06] <jmk_hiding> the guy with more than one (and who wants to be asked) will be the exception
[22:52:18] <petev> jmk: name the backups with a .bak extension
[22:52:31] <petev> but I see the point
[22:52:42] <jmk_hiding> good, backup was just an example
[22:53:02] <jmk_hiding> if he wants asked, just make sure none of them match the dir name
[22:53:10] <alex_joni> another example is users copying the emc1-ini in the same dir for reference
[22:53:14] <alex_joni> don't want to use that
[22:53:32] <petev> are u actually talking about asking at every run?
[22:53:40] <petev> I was thinking only the wizard
[22:53:41] <jmk_hiding> yes
[22:53:45] <petev> then use the links
[22:53:56] <jmk_hiding> the wizard comes into play when you are creating a new directory only
[22:54:02] <petev> right
[22:54:04] <alex_joni> ask once use the link/copy for the default
[22:54:07] <alex_joni> never ask again
[22:54:11] <jmk_hiding> and it will never produce a directory with more than on ini in it
[22:54:12] <petev> alex: yes
[22:54:33] <petev> jmk: unless the user copies more there manually
[22:54:40] <alex_joni> but when you are running a template (developers might want to) then you'll have both _in and _mm there, and no default
[22:54:42] <petev> that's why the link thing
[22:54:53] <jmk_hiding> right, but by definition, they've moved beyond the wizard if they do that
[22:55:02] <SWPadnos_> but how can you tell the links (called foo.ini) from the linked files (called foo_in.ini), without making the script unnecessarily complex?
[22:55:09] <SWPadnos_> you'll have a dir with 3 inis now
[22:55:13] <petev> jmk: yeah, but it shouldn't cause a problem
[22:55:13] <jmk_hiding> forget links
[22:55:35] <petev> jmk: ok, then how do u even know which dir to run?
[22:55:42] <jmk_hiding> ask every time if there are more than one and none match the dir name
[22:55:42] <SWPadnos_> I'm pointing out that the link idea may not work, because the link itself will just look like another ini to choose from
[22:55:46] <alex_joni> user specifies 'emc foo'
[22:56:09] <alex_joni> that's the way to run foo/foo.ini
[22:56:17] <petev> alex_joni: would be nice if user could just say emc after wizard
[22:56:20] <alex_joni> if anything else is needed he has to run 'emc foo/bar.ini'
[22:56:25] <jmk_hiding> in the case where the user just says "emc" without foo, we would like to use the most recently created user-specified directory
[22:56:37] <jmk_hiding> if none, we invoke the wizard to make one
[22:56:38] <alex_joni> what you both said
[22:57:23] <SWPadnos_> ok, so in configs/, there's a file called emc_default, which contains the name of the preferred ini (or is that what all of you are saying)
[22:57:24] <alex_joni> basicly the wizard only creates a file .defaultini with (foo/bar.ini) in it
[22:57:32] <alex_joni> SWPadnos_: yes
[22:57:41] <SWPadnos_> ok - then agree and move on ;)
[22:57:55] <alex_joni> mazak & step_cl
[22:58:09] <petev> ok, I was thinking links in configs instaed of file, but either works
[22:58:16] <jmk_hiding> those are test cases, I have a problem with the names
[22:58:30] <alex_joni> demo_mazak & demo_step_cl ?
[22:58:36] <jmk_hiding> yes
[22:58:55] <alex_joni> anyone second thoughts?
[22:59:18] <jmk_hiding> you can still choose to use them as a starting point... but they aren;t the same as the others
[22:59:21] <alex_joni> OK then
[22:59:43] <alex_joni> I agree. they are different
[22:59:51] <jmk_hiding> (and the wizard will have a way of showing a description of each one)
[22:59:54] <alex_joni> more complex, which can be either good or bad
[23:00:12] <alex_joni> depending on the case
[23:00:16] <SWPadnos_> sample_ may be better than demo_
[23:00:20] <petev> isn't there a name in the top of the INI?
[23:00:36] <alex_joni> there is
[23:00:40] <petev> maybe the wizard can show that or a description field
[23:00:51] <alex_joni> descriptive field as jmk suggested..
[23:00:58] <petev> yes
[23:01:03] <jmk_hiding> I'm thinking sentences or paragraphs, not words
[23:01:07] <SWPadnos_> can the run script examine inivars?
[23:01:10] <alex_joni> a file
[23:01:17] <SWPadnos_> duh - of course
[23:01:18] <alex_joni> SWPadnos_: why not?
[23:01:18] <jmk_hiding> alex: exactly
[23:01:28] <alex_joni> jmk_hiding: XML of course
[23:01:32] <SWPadnos_> description = "This is why I made this ini file"
[23:01:41] <alex_joni> with a picture embedded in it
[23:01:49] <jmk_hiding> * jmk_hiding hides again
[23:02:02] <SWPadnos_> icon = "Zdfg8756XGs90876fho*(&xgui87gkd8XIGU*" (xpm file)
[23:02:17] <alex_joni> we scared him away :D
[23:02:25] <SWPadnos_> you said the deraded XML word
[23:02:26] <SWPadnos_> oops
[23:02:35] <jmk_hiding> bad language
[23:02:38] <petev> it would make all this easy
[23:02:45] <jmk_hiding> no it wouldn't
[23:02:52] <alex_joni> petev: emc3
[23:02:52] <jmk_hiding> just trading one problem for another
[23:02:55] <SWPadnos_> anyway - the script can look for specific ini vars, like desctiption etc, to show the user
[23:02:59] <petev> sure, a nice parser object from XML lib
[23:03:08] <petev> alex_joni: ok
[23:03:09] <SWPadnos_> description might be more descriptive though
[23:03:25] <alex_joni> that's a nice one Swampy
[23:03:36] <SWPadnos_> ty (I think) :)
[23:14:13] <SWPadnos_> jmk_hiding: is it intended behavior that "setp xx " will reset xx to default? (presumably becuase it tries 0, which is then out of range)
[23:14:29] <SWPadnos_> not default I guess, but minimum
[23:14:30] <alex_joni> that's ok ;)
[23:14:31] <jmk_hiding> ?
[23:14:40] <alex_joni> setp xx no-value
[23:14:47] <jmk_hiding> "setp name " with no value?
[23:14:52] <jmk_hiding> should do nothing
[23:15:09] <jmk_hiding> and print an error
[23:15:10] <SWPadnos_> well - it doesn't atm. maybe I messed something up
[23:15:24] <jmk_hiding> maybe it was busted before, let me try it here
[23:15:38] <jmk_hiding> hmm, no error
[23:15:59] <jmk_hiding> I bet its using strtod and not validating the result
[23:16:07] <jmk_hiding> strtod("") = 0.0
[23:16:10] <alex_joni> jmk_hiding: will we have _in and _mm for all the ini's ?
[23:16:10] <SWPadnos_> I haven't tried with non-floats though
[23:16:32] <jmk_hiding> alex: I think so
[23:16:46] <alex_joni> I mean.. should I already add sim.ini as sim_in.ini ?
[23:17:17] <jmk_hiding> sure, why not
[23:17:36] <alex_joni> that makes it harder to run 'emc sim' ;)
[23:17:43] <alex_joni> but the wizard will take care of that
[23:18:03] <jmk_hiding> good point
[23:18:39] <alex_joni> good point harder or good point wizard?
[23:18:51] <jmk_hiding> SWP: I think the code verifys that strtod converted the entire string, but doesn't check for a blank string
[23:19:10] <jmk_hiding> it should check for a blank string before calling strtod
[23:19:29] <jmk_hiding> (actually can do it even before the switch on type, blank should be treated as an error)
[23:19:40] <jmk_hiding> alex: good point harder
[23:19:55] <alex_joni> so what would you think?
[23:20:08] <alex_joni> sim.ini for now, and later sim_in and sim_mm ?
[23:20:24] <jmk_hiding> yes
[23:20:39] <jmk_hiding> we may never even bother with the inch and mm versions
[23:20:45] <alex_joni> ok
[23:29:12] <jmk_hiding> SWPatnos_: question about the PWM...
[23:29:26] <jmk_hiding> should I set a default PWM frequency
[23:29:38] <jmk_hiding> or leave it zero, and have special case code in the RT to deal with that
[23:29:46] <jmk_hiding> (disable outputs if zero)
[23:29:56] <SWPadnos_> good q.
[23:30:19] <SWPadnos_> I'd set the freq to something fairly fast, by default
[23:30:28] <alex_joni> 4MHz
[23:30:41] <SWPadnos_> though the faster it is, the lower the resolution, right
[23:30:45] <jmk_hiding> 500KHz is the max, 153 Hz is the min
[23:30:58] <jmk_hiding> either could be bad news, based on the power stage
[23:31:13] <jmk_hiding> (too much switching loss if high, too much current ripple if low)
[23:31:18] <alex_joni> 250kHz then
[23:31:33] <SWPadnos_> 250 KHz will give you 4 bit resolution
[23:31:36] <SWPadnos_> roughly
[23:31:44] <jmk_hiding> I'm tempted to force it to zero (and disable the outputs), so it requires an explicit setp to choose a frequency
[23:32:03] <SWPadnos_> that's valid
[23:32:28] <SWPadnos_> at 1 KHz, you have 10000 possible settings, right (roughly a 13-bit resolution)
[23:32:48] <alex_joni> jmk_hiding: moving the ppmc stuff, hope you don't mind
[23:33:15] <jmk_hiding> the ini and hal files, don't mind at all
[23:33:19] <jmk_hiding> I never use them anwyay
[23:33:25] <jmk_hiding> I'm testing the naked driver
[23:33:42] <jmk_hiding> alex: hold up....
[23:33:50] <jmk_hiding> we don't want ppmc dirs,
[23:33:53] <alex_joni> ok.. holding
[23:33:55] <jmk_hiding> we want usc and upc
[23:33:59] <alex_joni> DAMN
[23:34:09] <SWPadnos_> heh - I think I mentioned that earlier ;)
[23:34:11] <jmk_hiding> or maybe pico_usc and pico_upc
[23:34:19] <alex_joni> that was half an hour ago
[23:34:41] <jmk_hiding> I think we both mentioned it earlier
[23:34:46] <petev> most of the other configs are just the board name, not company
[23:34:50] <alex_joni> I missed it :(
[23:35:05] <alex_joni> can't you people yell at me?
[23:35:09] <jmk_hiding> petev: good point
[23:35:12] <SWPadnos_> DAMN YOU ALEX!!!!
[23:35:16] <jmk_hiding> but usc is pretty non-informative
[23:35:19] <SWPadnos_> how was that?
[23:35:21] <alex_joni> like that.. I notice that
[23:35:26] <jmk_hiding> (as opposed to say motenc)
[23:35:26] <alex_joni> it's even red
[23:36:03] <jmk_hiding> USC = University of Southern California
[23:36:06] <alex_joni> FSCK it..
[23:36:07] <petev> we could add another leve of dir for company name. petev runs from alex
[23:36:15] <jmk_hiding> no
[23:36:21] <alex_joni> petev: no problem with that ;)
[23:36:26] <alex_joni> but it's ugly
[23:36:36] <SWPadnos_> yeah - and link to their websites for support and drivers
[23:36:38] <alex_joni> anyways.. I'll have a request for SF admins tomorrow
[23:36:46] <petev> would be better than pico_this, pico_that
[23:36:50] <alex_joni> to remove configs/ppmc
[23:37:09] <jmk_hiding> I didn't see the commit message for that, you sure it went thru?
[23:37:33] <alex_joni> directories don't go to CIA
[23:37:35] <SWPadnos_> yeah -that one's missing from the cia messages
[23:37:36] <alex_joni> only mailing
[23:37:41] <jmk_hiding> oh, poop
[23:37:59] <petev> why can't SF just give admins a shell account?
[23:38:02] <alex_joni> ok.. so what's the choice then?
[23:38:04] <SWPadnos_> ok - but ther eare no files there yet
[23:38:15] <alex_joni> petev: they can, but /cvsroot/ is restricted I think
[23:38:24] <SWPadnos_> add univpwm and univstep dirs
[23:38:34] <jmk_hiding> perfect
[23:38:35] <alex_joni> SWPadnos_: right, cvs up -dP will not produce the dir
[23:38:40] <SWPadnos_> and put the configs ther
[23:38:42] <SWPadnos_> e
[23:38:46] <alex_joni> univpwm and univstep
[23:38:50] <alex_joni> OK
[23:38:53] <alex_joni> what configs?
[23:38:54] <jmk_hiding> configs/univpwm and configs/univstep
[23:39:12] <jmk_hiding> alex: leave those alone for now
[23:39:23] <SWPadnos_> maybe copy the ppmc hal file to univstep (it's for that right now)
[23:39:26] <jmk_hiding> SWP and/or Ray and/or I will handle them
[23:39:31] <SWPadnos_> that's fair
[23:39:31] <alex_joni> ok.. I will, I'll delete ppmc_* from configs/ though
[23:39:37] <SWPadnos_> yes
[23:42:07] <alex_joni> so demo_mazak/demo_mazak.ini & co.. right?
[23:42:13] <jmk_hiding> yes
[23:44:14] <SWPadnos_> ok - back in a while