Back
[00:25:29] <jmkasunich> yeah, if a function is already in a thread you can't add it again
[00:41:00] <jmkasunich> * jmkasunich is back from dinner
[00:42:45] <rayh> I see that. It does work okay with halcmd -fk
[00:43:04] <jmkasunich> k means keep going on errors
[00:43:21] <jmkasunich> IOW, ignore them - probably not a good idea
[00:46:43] <rayh> Well there are a number of issues with rereading the loadrt and addf stuff.
[00:47:15] <jmkasunich> halcmd save gives you a file that will turn an blank HAL into what you had when you issued the save command
[00:47:29] <jmkasunich> but if you have a non-blank HAL, you can get a mess
[00:48:52] <jmkasunich> halcmd scripts are step-by-step instructions to build a specific HAL. Imagine step-by-step instructions for building a house. If you just want to remodel, you can follow instructions that start with "dig a hole for the basement" ;-)
[00:49:06] <jmkasunich> s/can follow/can't follow/
[00:49:36] <rayh> If we have a good/complete tillie interface, the original ini and hal files are largly obsolete.
[00:50:28] <jmkasunich> dunno about that
[00:50:39] <jmkasunich> not everyone wants to use the aunt tillie interface
[00:51:33] <rayh> I can understand that. But even a schematic displayer editor needs an easy way to save it's state.
[00:52:56] <jmkasunich> some parts of what you want are "just a matter of programming" (but still complex and time consuming), other parts simply wouldn't work without fundamental changes
[00:53:24] <jmkasunich> basic problem: halcmd save generates a file that describes a certain HAL config
[00:53:41] <rayh> Right.
[00:53:41] <jmkasunich> if you start from a blank HAL, it is guaranteed that you can return to the saved one
[00:53:53] <jmkasunich> but if you start with something else, it may be impossible
[00:54:19] <rayh> Can we start emc after HAL?
[00:54:20] <jmkasunich> for example, if the saved config has 4 PID blocks, and the current one already loaded the PID module with 3
[00:54:30] <jmkasunich> you'd have to unload the PID module and then reload it to get 4
[00:55:08] <rayh> But it the save IS the hal file then it is okay with the -fk
[00:55:23] <jmkasunich> "start emc after hal" : what do you mean by "emc"? the run script called "emc", or some component(s) of emc that are started by the script (like motion, GUI, task, etc)?
[00:55:32] <jmkasunich> rayh: yes
[00:56:19] <rayh> Yes, motion and iocontrol must be running or the netlist is missing pins.
[00:56:47] <jmkasunich> it is actually possible to load motion and start iocontrol just like any other HAL modules
[00:57:14] <jmkasunich> in fact I considered doing so - removing them from their "special" status in the ini file and loading them from HAL
[00:57:35] <jmkasunich> but I didn't, I knew it would make Paul and possibly others go ballistic
[00:57:52] <jmkasunich> even without that issue I'm not sure which approach is correct
[00:58:00] <rayh> He went anyway!
[00:58:18] <jmkasunich> yeah, but thats beside the point ;-/
[00:58:32] <rayh> I'm casting about for a reasonably quick solution to saving stuff done with halconfig.
[00:58:40] <rayh> I'm open for any suggestions.
[00:59:08] <jmkasunich> are you loading modules with halconfig? reconnecting/disconnecting pins and signals? or just tuning (changing parameters)?
[00:59:35] <rayh> The way it is right now you can start from scratch if you want to.
[00:59:54] <rayh> any command available to halcmd is available in halconfig.
[00:59:57] <jmkasunich> ok
[01:00:25] <rayh> So the range of saved info is rather large.
[01:00:26] <jmkasunich> however, most folks won't actually be doing that
[01:00:44] <rayh> That is how I'd like to teach it at fest.
[01:01:19] <jmkasunich> for emc users? 95% of them will never have a reason to start from blank
[01:01:27] <jmkasunich> only people doing really strange stuff
[01:01:43] <jmkasunich> and even they would probably start with one of the stock configs just because it saves work
[01:01:45] <rayh> Sure.
[01:02:09] <rayh> Tuning for servos is probably the biggest change
[01:02:29] <jmkasunich> the real problem there is that I kinda painted myself into a corner
[01:02:44] <rayh> Once we get the HAL module that emulates emcsh then there will be more connecting going on.
[01:02:56] <jmkasunich> the stock hal files get the values for the tuning params from the ini file
[01:03:06] <rayh> I've never done that;
[01:03:24] <jmkasunich> so saving the numeric values to a HAL file after tuning is only half the battle, you really want to get them into the ini file
[01:03:40] <rayh> Not if you rerun using the netlist.
[01:03:45] <jmkasunich> never done what? gotten P, I, and friends from ini?
[01:03:59] <rayh> no painted myself into a corner.
[01:04:05] <jmkasunich> heh
[01:26:04] <cradek> jmkasunich: the changes you made tonight look great; I've been meaning to fix that in halcmd
[01:26:55] <jmkasunich> that wasn't me
[01:27:03] <cradek> oh? hmm
[01:27:12] <cradek> I deleted it already
[01:27:16] <cradek> oh well
[01:27:26] <jmkasunich> jepler
[01:27:30] <cradek> ah
[01:27:40] <cradek> he's a sharp cookie too
[01:27:54] <cradek> what a strange expression
[01:28:29] <cradek> did you guys make any progress with his servos?
[01:28:51] <jmkasunich> he hasn't shown up yet this evening
[01:32:52] <cradek> jmkasunich: it seemed like we were working together on something before you left, but I can't recall what it was
[01:33:04] <jmkasunich> phone
[01:33:08] <cradek> ok
[01:38:42] <jmkasunich> cradek: need to brainstorm something with you
[01:38:46] <jmkasunich> was just talking to ray
[01:39:12] <jmkasunich> he's getting some grief from hal while trying to implement saving/restoring hal config ingo
[01:39:18] <jmkasunich> mostly because of motmod
[01:39:27] <jmkasunich> (you there?)
[01:39:50] <cradek> yes
[01:39:53] <jmkasunich> motmod is "different" from all other HAL modules in several ways
[01:39:56] <rayh> me to
[01:40:06] <jmkasunich> 1) its loaded by the runscript, not by a HAL file loadrt command
[01:40:24] <jmkasunich> 2) it creates threads, instead of expecting the user or hal script to do it
[01:41:00] <jmkasunich> 3) it adds its own functions to those threads automatically, instead of depending on the user/script to do an addf
[01:41:42] <jmkasunich> the result: when ray saves a HAL config, it contains a loadrt for the motion module, and addf's for motmod's functions
[01:42:02] <cradek> I see
[01:42:14] <jmkasunich> but when you restart emc the next time, the run script loads motmod, and it does its own addfs, so you get errors later when the hal script tries to do that
[01:42:25] <cradek> why is it so different in these ways?
[01:42:43] <jmkasunich> several reasons, some techinical, some not
[01:42:50] <cradek> I'm already thinking this is out of my league
[01:43:20] <cradek> ok so it can't just be "fixed" the obvious (but maybe not easy) way?
[01:43:27] <jmkasunich> when I first started the emc2 makefile, I avoided treating motmod (or other core EMC blocks) as "just another HAL block" because I knew that would irritate some people
[01:43:39] <jmkasunich> the technical reasons have to do with things like BASE_PERIOD
[01:44:07] <cradek> so it's because it needs the PERIODs from the ini?
[01:44:13] <jmkasunich> it would be straightforward to remove the "built in addf" from motmod
[01:44:13] <jmkasunich> yes
[01:44:36] <cradek> I would hesitate to move those out of the ini
[01:45:05] <jmkasunich> removing the addf and explicitly addf'ing controller and command-handler in the HAL file is easy, just causes a distruption to existing users until they add the addf lines to their own hal files
[01:45:25] <jmkasunich> but as you say, the BASE_PERIOD thing is messier, I agree that should stay in the ini
[01:45:45] <cradek> is this the last or first of the problems with halcmd save?
[01:45:54] <jmkasunich> generic "get anything from the ini file" instead of setp and sets only being able to read from the ini file would be a big help
[01:46:07] <jmkasunich> probably (I hope) the last
[01:46:10] <cradek> I understand
[01:46:51] <jmkasunich> if we could get periods (and maybe a couple other things, like SHMEM_KEY ) from the ini. then motmod could be loaded by loadrt in the hal file like any other module
[01:47:03] <cradek> right
[01:47:04] <jmkasunich> (instead of by a special section of the run script as it is now)
[01:47:06] <rayh> One other answer to cradek's question concerns many of the values currently read from the ini.
[01:47:28] <cradek> how did you guys fix the problem where [AXIS_n]VAR gets flattened?
[01:47:32] <rayh> These would be saved as values for parameters in the saved file
[01:48:27] <jmkasunich> cradek: not sure I understand what problem you are talking about
[01:48:31] <cradek> I think that's what I'm asking about
[01:48:34] <cradek> let me ask better
[01:48:38] <cradek> setp stepgen.0.position-scale [AXIS_0]INPUT_SCALE
[01:48:50] <cradek> after I halcmd save, does this get changed to the value?
[01:48:54] <jmkasunich> yes
[01:48:58] <jmkasunich> thats not solved at all
[01:49:21] <jmkasunich> ray proposed a solution that in essence solves the problem by redefining it
[01:49:29] <cradek> I think until that is fixed, this whole thing is very problematic
[01:49:35] <jmkasunich> the values would be removed from the ini file and live only in the HAL file
[01:49:36] <cradek> how's that?
[01:49:42] <cradek> hmm
[01:50:08] <jmkasunich> and they would probably be "edited" by using halconfig on a running EMC, then doing a save
[01:50:26] <cradek> I agree that's better
[01:50:32] <jmkasunich> yes and no
[01:50:35] <cradek> not sure I think it's "good" though
[01:50:53] <jmkasunich> some things should _not_ be changed on a running EMC tho
[01:50:58] <jmkasunich> inputscale being one of them
[01:51:28] <jmkasunich> initial scale is 1000, machine is at 5000 counts (5" from origin) and happy
[01:51:47] <cradek> I understand 100% the need for online tuning etc. and it seems halconfig is a good tool for that
[01:51:50] <jmkasunich> you change the scale to 5000, now feedback is suddenly at 1" while command is 5"
[01:52:06] <cradek> however I am not entirely convinced the save is needed
[01:52:14] <cradek> it sure is problematic
[01:52:16] <jmkasunich> instant following error (and if not, balls-to-the-wall move by the axis)
[01:52:32] <cradek> are comments and =>/<= in the halfiles lost too?
[01:52:37] <jmkasunich> well, if you tune online, how do you get the values back into the ini file?
[01:52:39] <jmkasunich> yes
[01:52:43] <cradek> damn
[01:53:00] <cradek> edit the file when you're done, I guess
[01:53:18] <jmkasunich> to date, when I've tuned online, I do show param, and edit the numbers into the ini or hal file (depending on the situation)
[01:53:27] <jmkasunich> not something we want to ask aunt tillie to do
[01:53:45] <cradek> right, that's what I would do too, so my halfiles don't get sanitized
[01:53:48] <rayh> That is what I've been telling my people to do. Halconfig allows testing, but you've got to manually edit to make it stick.
[01:54:18] <jmkasunich> it is definitely a problem - I've forgotten to edit the file a few times myself:
[01:54:43] <jmkasunich> "wft, it was working a few minutes ago..... before I restarted.... <slaps forehead>"
[01:54:46] <cradek> I can sure see that
[01:54:55] <cradek> then your changes are lost too
[01:55:21] <rayh> Or it doesn't start and the error message says something about cl.
[01:56:07] <jmkasunich> hmm, CL adds a whole new dimension - editing the ladder and forgetting to save it
[01:56:18] <cradek> let me back up for a sec
[01:56:23] <jmkasunich> actually, CL has to address the same problem
[01:56:31] <jmkasunich> editing an online system, then saving the edits
[01:56:37] <cradek> we have human readable, human editable text config files
[01:56:51] <jmkasunich> the "unix-ey way"
[01:56:59] <cradek> we are trying to change them programatically
[01:57:12] <cradek> this is a common unix "growing pain"
[01:57:12] <jmkasunich> yep
[01:57:32] <cradek> it's a paradigm clash and it is very hard to solve
[01:57:34] <rayh> The cl files are pretty obscure for man reading.
[01:58:01] <cradek> unix distros have solved it in many ways:
[01:58:09] <jmkasunich> rayh: thats one way to solve the problem - if you make human editing (nearly) impossible, then you don't have the paradigm clash
[01:58:13] <cradek> for example replacing /etc/rc with /etc/init.d/[lots of files]
[01:58:26] <cradek> where each file does only one thing, and can be added/removed with a package
[01:58:49] <rayh> and we are back to cobol's way of saving data.
[01:59:07] <cradek> also /etc/printcap was a problem when we started having gui printer configurators - we need to generate it, but it has handwritten stuff in it
[01:59:38] <cradek> so I think we need to choose one paradigm
[01:59:49] <cradek> I do not know which one I think it should be.
[02:00:15] <cradek> if we want generated configs (gui editors) we have some work to do, but some is done or mostly done (halconfig)
[02:00:30] <jmkasunich> I will always favor the unix-ey way with text files, but that is a personal preference not suitable for "mass market" users
[02:00:34] <cradek> I do not think we can (or should try to) have both.
[02:01:23] <jmkasunich> halconfig isn't fundamentally different from halcmd tho
[02:01:25] <rayh> I have constructed tickle files that edit man readable like the tbl, var, and ini but they are a real pain.
[02:01:42] <jmkasunich> it issues commands under user control (thru halcmd)
[02:01:57] <cradek> yeah, it's possible, but a continuing source of pain-in-the-assness
[02:02:05] <jmkasunich> it doesn't (nor does halcmd) maintain information about what the config was before or is after the command
[02:02:43] <cradek> there's nothing wrong with halcmd/halconfig except the saving problem
[02:03:25] <jmkasunich> one approach (used by emc for years for the ini) is to read the existing file, echo it back out, and change only the stuff that needs changed
[02:03:33] <jmkasunich> that preserves comments, ordering of lines, etc
[02:03:55] <jmkasunich> but for HAL as used by emc today, its messier
[02:04:17] <cradek> like I said, it's possible, but a continuing source of pain-in-the-assness
[02:04:28] <jmkasunich> we can have multiple "existing" files (core-stepper.hal, standard-pinout.hal, etc)
[02:04:42] <jmkasunich> and they can in turn extract info from the ini file
[02:05:01] <rayh> The tiniest change in the order or nature of the text file causes an update of the configuration stuff.
[02:05:19] <cradek> in order to do that "right" you'd also have to follow through to the ini file and change that
[02:05:26] <jmkasunich> yep
[02:05:27] <cradek> I think we don't want to start down this road, guys
[02:05:33] <cradek> it's madness
[02:05:48] <jmkasunich> you'd actually have to start with the ini file, to find out which hal file(s) need rewritten
[02:06:59] <cradek> if we want full gui editing (and we might) we need to find a reasonable way to do it (xml??), make a branch, and start gutting stuff
[02:07:14] <jmkasunich> "full gui editing"?
[02:07:15] <cradek> if we want to do that, let's keep editing our text files
[02:07:40] <jmkasunich> the GUI part is a red herring
[02:07:44] <cradek> yes, configuring all of emc without editing files (files not human written/readable)
[02:08:30] <cradek> not a red herring in my opinion; that would be the only goal that would justify this kind of work
[02:08:37] <jmkasunich> the problem exists even if I tune by doing "halcmd setp pid.0.pgain 1000" until I'm happy
[02:08:57] <jmkasunich> I still have to manually copy my final value of pgain to some file (either ini or hal)
[02:09:31] <cradek> ok, I see what you mean
[02:09:33] <jmkasunich> or do a halcmd save and get a file that contains the complete state of the HAL, but no comments or anything
[02:09:59] <rayh> and hard coded values for all of these variables.
[02:09:59] <cradek> leave out gui and call it "online" editing or whatever - I just mean that you don't edit the config files for anything anymore.
[02:10:20] <cradek> jmkasunich: what if you loaded three halfiles and you do a save, do you get one big one?
[02:10:22] <jmkasunich> basically we have a disconnect between the process used to get to a config (issuing hal commands, regardless fo the tool used) and the actual config (as a state, not a process)
[02:10:26] <rayh> Imo we are right on the edge of a self referencing system with HAL.
[02:10:27] <jmkasunich> yes
[02:11:02] <rayh> halcmd can querry the HAL state at any time.
[02:11:07] <jmkasunich> save generates _A_ list of commands that will re-create the existing HAL config if you start with a blank slate
[02:11:14] <cradek> ok I understand
[02:11:27] <jmkasunich> that list of commands may be completely different from the actual commands used to get to the config
[02:11:37] <cradek> we lose a LOT of information when that happens.
[02:12:05] <cradek> the user may entirely lose his ability to understand what's going on in the files.
[02:12:21] <cradek> (it's hard enough with comments etc)
[02:12:25] <jmkasunich> some that we want to loose (the 37 values of Pgain I tried before I was happy) and some we don't (the fact that some values came from the ini, and that there were several HAL files each configuring part of the system)
[02:12:41] <rayh> It does shift comprehension from man readable to gui operations.
[02:15:00] <cradek> let me step back and ask exactly what question we are trying to answer tonight
[02:15:47] <rayh> A way to save changes made to a running hal.
[02:16:53] <cradek> I think the answer is that there is not a good way to do that without a big restructuring.
[02:17:59] <jmkasunich> this kind of thing is what Paul was talking about when he said that HAL could lead to a configuration nightmare
[02:18:50] <cradek> possibly, but his alternative was to require the user to write C, which seems somewhat worse to me
[02:19:09] <jmkasunich> agreed
[02:19:15] <rayh> Yep.
[02:19:36] <jmkasunich> all we're really doing is changing languages
[02:19:44] <rayh> No the real answer that he wanted was to have folk like me hire him to write c.
[02:20:03] <cradek> ok let's try not to go here
[02:20:09] <cradek> I don't want to talk about paul
[02:20:23] <jmkasunich> ok
[02:20:49] <jmkasunich> in a way, HAL is a language too
[02:21:15] <jmkasunich> you write the source, then you "compile" it (execute the hal file which builds the system)
[02:21:19] <rayh> Certainly.
[02:21:22] <cradek> I think if we give up the human-readability of the halfiles, we need to replace that functionality (comments used as documentation, etc) with something else, and that is probably a gui
[02:21:36] <jmkasunich> the thing is that instead of making folk edit the source and re-execute, they can modify the executing program
[02:21:50] <jmkasunich> which generates the "how to save said changes" problem
[02:23:51] <cradek> I think the simple answer is to go back and edit the "source"
[02:24:33] <jmkasunich> you know emc1 had the same issue
[02:24:42] <cradek> I think we need to have an honest debate about whether we want human writable/readable config files or a gui to replace that functionality, since I think that's the base problem
[02:24:49] <jmkasunich> simpler because there was only one source file - the ini
[02:25:07] <cradek> yes, and it rewrote it, and we often cursed at it because of that.
[02:25:39] <cradek> it seemed/seems like a bad scheme.
[02:25:56] <rayh> It worked rather well in the old days.
[02:25:59] <jmkasunich> well, if you decide that you are gonna have GUI only editing, its no longer a bad scheme
[02:26:31] <jmkasunich> if you say "thou shalt not manually edit", the actual format, human readable or not, is irrelevant
[02:26:39] <cradek> that's right
[02:27:10] <jmkasunich> the thing is that I personally don't want to say "thou shalt not edit" for HAL
[02:27:32] <jmkasunich> for EMC it might be the right thing to do, but for HAL as a general purpose tool, I hate it
[02:27:38] <cradek> here's a good example:
[02:27:39] <cradek> # send the position commands thru differentiators to
[02:27:39] <cradek> # generate velocity and accel signals
[02:28:06] <cradek> these two lines in my halfile have a lot of utility, but what in a gui will replace them?
[02:28:27] <jmkasunich> nothing that I can think of
[02:28:44] <rayh> Um. If you start emc2 and issue bin/halcmd save you'll see what the result looks like.
[02:28:49] <rayh> It is man readable.
[02:28:51] <jmkasunich> short of a schematic based tool, that allows you to put comments in the drawing
[02:28:59] <cradek> jmkasunich: true
[02:29:13] <rayh> It is still man editable.
[02:29:15] <jmkasunich> ray: man readable, but reordered and without comments
[02:29:35] <rayh> Certainly but it will fool none of the advanced users.
[02:30:04] <rayh> In fact I find it a cleaner read that several .hal files and stuff in the ini.
[02:30:11] <jmkasunich> speak for yourself - I certainly wouldn't want to come back a year later and read any of my code (any - C, bash, or HAL) without comments
[02:30:30] <rayh> True.
[02:31:03] <jmkasunich> on the "one file easier to read than several .hal and one .ini file" side, I think I agree with you
[02:31:19] <jmkasunich> the "several hal files" thing is basically a form of code reuse
[02:31:33] <jmkasunich> irrlevanant to joe user who cares only about his own machine
[02:31:42] <jmkasunich> I can't spell irrelevant
[02:32:01] <rayh> irreverent?
[02:33:16] <jmkasunich> that too
[02:33:20] <cradek> for today I'm firmly on the "edit the files" side of the fence. Especially for the overdue release.
[02:33:58] <cradek> a tool for viewing/editing the running system is still just as useful
[02:34:52] <jmkasunich> it is possible (not neccessarily pretty, but possible) to write an offline tool that takes an ini file (and the hal files it invokes) and a halcmd save output file, and modifies the former to match the latter
[02:35:29] <jmkasunich> (while preserving comments, extraction of values from ini, and multiple .hal files)
[02:36:07] <jmkasunich> it would be reasonable to explicitly invoke such a tool after a tuning session (rather than re-writing the ini, etc, every time)
[02:36:20] <cradek> that sounds very complex, and I think that time would be better spent on the new paradigm if we decide we want it.
[02:36:31] <rayh> IMO the gui viewing and editing tool is of greatly reduced value if it's changes can not be saved.
[02:36:32] <SWPadnos> * SWPadnos is back
[02:37:03] <SWPadnos> I've got an idea regarding update of settings read from the ini
[02:37:20] <SWPadnos> there aren't a lot of them (less than 1000, say)
[02:38:09] <SWPadnos> it's easy ehough to keep an array soemwhere, possibly in a file, of the source ini setting for the parameters set that way
[02:38:42] <SWPadnos> so you have a list, like: pid.0.Pgain AXIS_0 P
[02:39:13] <SWPadnos> 3 fields, first is param name, second is ini section, third is ini item
[02:40:31] <SWPadnos> assuming that halcmd knows where to find this file, those settings can be rewritten as setp pid.0.Pgain [AXIS_0]P
[02:40:53] <jmkasunich> you also have to go modify the value in the ini file
[02:41:04] <steves_logging> steves_logging is now known as steve_stallings
[02:41:08] <SWPadnos> yes, so you'd have to know where the ini is
[02:41:24] <steve_stallings> As a member of the original "Aunt Tillie" movement, I was happy when EMC2 got to the point where configuration was possible without having to run a compile.
[02:41:30] <SWPadnos> that can be stored in the command file as well, or it just writes to the ini specified on the command line
[02:41:39] <steve_stallings> That being said, would it help if a log file was generated with all the changes made to a running system so it could be parsed later, either automatically or manually?
[02:41:44] <jmkasunich> actually, if you are "rewriting" the hal file by reading it (so you don't loose comments and such) theres no need to save the source of the value, its right there
[02:41:50] <SWPadnos> true
[02:41:57] <SWPadnos> though you still need to know the ini file
[02:41:58] <jmkasunich> if the line is "setp foo 100", replace 100 with the curent value
[02:42:26] <SWPadnos> right, there are no strings, nad any value with a [ or ] in it comes from the ini
[02:42:30] <jmkasunich> if the line is "setp foo [bar]blat", echo it unchanged, go to the ini, and set [bar]blat to the current value
[02:42:32] <SWPadnos> s/nad/and/
[02:42:50] <rayh> ah but the line in the hal file will be setp foo barblat [read ini]
[02:43:13] <jmkasunich> ?
[02:43:25] <SWPadnos> no, it's setp foo 1.2334 now
[02:43:28] <rayh> and in the ini file it will be [axis_0] D
[02:43:42] <SWPadnos> it
[02:43:44] <jmkasunich> bar = AXIS_0
[02:43:47] <jmkasunich> blat = P
[02:43:55] <jmkasunich> sorry, I was being too generic
[02:44:00] <SWPadnos> it's the HAL file that has setp pid.0.PGain [AXIS0]P
[02:44:16] <rayh> I was just thinking that the names between HAL and ini are very different.
[02:44:22] <SWPadnos> yes
[02:44:27] <jmkasunich> yeah, but the mapping is right there
[02:44:39] <SWPadnos> I had thought of doing something like the "with" statement in Pascal
[02:44:45] <jmkasunich> the original hal file says "setp pid.0.Pgain [ AXIS_0]P"
[02:44:46] <rayh> So you would have to use a lookup table to get the linkage for editing.
[02:45:19] <jmkasunich> when rewriting it, halcmd would rewrite it unchanged, but it would go to the ini and modify the value of [AXIS_0]P
[02:45:21] <rayh> so you are thinking that the hal file is the lookup.
[02:45:30] <jmkasunich> yeah
[02:46:04] <jmkasunich> what we're talking about now is how to implement the tool I mentioned earlier
[02:46:32] <jmkasunich> for parameters, I'm confident that it can be implemented, and not too ugly
[02:46:44] <jmkasunich> for addf, loadrt, link, and the rest it gets worse
[02:46:51] <SWPadnos> I think that halcmd needs to keep a list of items set by ini vars
[02:47:08] <SWPadnos> consider that a user could manually load something from an ini file
[02:47:15] <jmkasunich> what is the scope of that list?
[02:47:24] <SWPadnos> so there may not be a hal file for all of them
[02:47:28] <SWPadnos> it would have to be global
[02:47:37] <jmkasunich> the run script does halcmd -f some-hal-file
[02:47:40] <SWPadnos> it could be a file in /tmp or something
[02:47:44] <jmkasunich> which gets the pgain from the ini
[02:47:48] <cradek> we still haven't gotten back to the problem with insmod variables coming from the ini
[02:47:51] <jmkasunich> that fact gets noted
[02:48:04] <jmkasunich> then later the user changes the pgain
[02:48:22] <jmkasunich> does that later manual change erase the note that the original value came from the ini?
[02:49:02] <SWPadnos> sure, but I could run an interactive halcmd with an ini specified (possibly even a different one, though I'm not worried about that), and then play around loading things from the ini by hand
[02:49:09] <SWPadnos> there would be no hal file with those lines in it
[02:49:38] <SWPadnos> no, manual value changes should be saved in the "source location" of the setting
[02:49:40] <jmkasunich> any way you slice it is messy
[02:49:48] <SWPadnos> it's keeping track of that source that's a pain
[02:49:50] <SWPadnos> yep
[02:49:55] <rayh> IMO the config would have to know where HAL got each hunk of the language used to make it.values
[02:50:08] <rayh> links
[02:50:11] <rayh> everything.
[02:50:18] <SWPadnos> well, there is a solution to this, similar to the xml one
[02:50:27] <cradek> how many of us breathed a sigh of relief when I took out the ini-rewriting? You are talking about putting that back along with 10 times more complexity
[02:50:48] <SWPadnos> I think I suggested before that a version of halcmd be made that can load hal stuff from ini-like files
[02:50:59] <rayh> Yep. Or simply use halcmd show
[02:51:05] <SWPadnos> and, like XML, ignore sections that aren't meant for it
[02:51:13] <rayh> and edit a bit of motmod.
[02:51:44] <SWPadnos> I think motmod should be changed to be a "normal" hal module, if there is no technical impediment to that
[02:52:08] <jmkasunich> there are three ways in which it is not normal
[02:52:11] <cradek> there is - it needs to be inserted with arguments that come from the ini (no support for that)
[02:52:21] <jmkasunich> 2 can be changed with no technical impediment
[02:52:22] <SWPadnos> threads is a special one as well, since it should be unloaded after it's "done"
[02:52:36] <jmkasunich> (where its loaded from, and how it gets addf'ed)
[02:52:48] <jmkasunich> the third is how it creates threads, using BASE_PERIOD from the ini
[02:53:03] <SWPadnos> and SERVO_PERIOD
[02:53:07] <jmkasunich> yes
[02:53:41] <SWPadnos> well, what if halcmd is modified to just do generic ini var replacement, for all instances of ini vars in the command
[02:53:48] <jmkasunich> extending the [foo]bar syntax to allow it for arbitrary fields in a hal command instead of just the value arg of sets and setp would solve that
[02:53:57] <SWPadnos> exactly ;)
[02:54:04] <cradek> I'm curious how many people here think that if we are going to make these changes, they should be after the release.
[02:54:07] <jmkasunich> I type too slow
[02:54:12] <SWPadnos> the first thing you do is do the substitution, then do the command
[02:54:40] <SWPadnos> well, I'd say that anything that has a profound effect on the ini files should be pre-release
[02:54:56] <jmkasunich> I'm ambivalent
[02:55:06] <SWPadnos> that's one of the external interfaces, which should be kept as sttable as possible, IMO
[02:55:12] <jmkasunich> like cradek, I think we are _WAY_ past the time we should have released
[02:55:12] <SWPadnos> stable
[02:55:21] <jmkasunich> and I would be quite content to release what we have today
[02:55:23] <SWPadnos> there is that ;)
[02:55:30] <steve_stallings> In order to proceed with the "release" of EMC2, would it be possible to deal with only those things (paramaters) that need to be changed in "canned" configurations, like PID and require manual editing for any HAL re-wiring?
[02:55:38] <jmkasunich> but like SWP, I'd really like to avoid a radical and incompatible change post-release
[02:55:38] <SWPadnos> what about making it an early 2.1.x thing
[02:55:44] <rayh> I'm thinking ahead of cnc-workshop but after release.
[02:56:02] <SWPadnos> maybe open 2.1.x at or just before Fest
[02:56:18] <SWPadnos> and decide that some breakage is ok
[02:56:55] <jmkasunich> I'm not going to be working on config issues at fest, I want to do threading
[02:57:02] <cradek> I am adamant that we either keep human writable/readable configs and make the humans write them, or we go to a full gui configurator - not something halfway between that will be an ongoing nightmare.
[02:57:20] <cradek> jmkasunich: and I'm going to be working with you on that
[02:57:23] <rayh> IMO I will go ahead and teach using netlists and simply hack halconfig to remove the most problematic areas.
[02:57:31] <SWPadnos> a single ini-like file that includes hal command sections would be human readable/writable
[02:58:44] <jmkasunich> cradek: why do you think that human readable/editable and GUI are incompatible?
[02:58:52] <jmkasunich> think of apt-get and synaptic
[02:59:18] <SWPadnos> consider that you don't look at the package cache by hand
[02:59:30] <jmkasunich> hmm
[02:59:31] <cradek> jmkasunich: they're not incompatible, but I think they would be an ongoing pain in the rear.
[03:00:01] <jmkasunich> I think maybe the apt-get and synaptic analogy might be a good one
[03:00:04] <rayh> I'm with cradek on that but perhaps in the short run it is something I'll have to do to prepare fo teaching.
[03:00:16] <rayh> for
[03:00:17] <SWPadnos> no, that's command-line / gui, not "text file" / gui
[03:00:21] <cradek> jmkasunich: we have only a few developers and I hate to see any of them wasting time on something that we know should rightly be thrown out because it sucks.
[03:00:25] <jmkasunich> apt-get and synaptic both modify the system, just like halcmd and halconfig
[03:00:41] <jmkasunich> the config data is the cache and other stuff that humans _don't_ modify
[03:01:21] <jmkasunich> cradek: I agree about wasting time
[03:01:40] <jmkasunich> if it was solely up to me, it would be manually edited human readable files till the end of time
[03:01:42] <rayh> There is a fight between hand editing /etc/apt/sources.list and using the ubuntu screwup.
[03:01:51] <jmkasunich> (or until we have a schematic type config tool working)
[03:02:38] <rayh> I just can't imagine teaching a newbee to HAL to edit it the way that I see jmk doing it.
[03:02:40] <cradek> a schematic netlist editor falls into the "when in doubt do it right" category afaic. That wouldn't be wasting time.
[03:03:03] <rayh> Do you think halconfig is a waste of time?
[03:03:14] <jmkasunich> cradek: yes, but it will take far longer than we are willing to delay the release
[03:03:27] <rayh> At least it got us to the place where we have to consider how to save live changes.
[03:03:33] <jmkasunich> rayh: true
[03:03:38] <cradek> I have only looked at it once, but it looked like a good way to examine the running system (I didn't modify anything)
[03:03:41] <jmkasunich> as for what I think, its mixed
[03:03:54] <jmkasunich> halconfig's weakness is that it does the same thing as halcmd, only prettier
[03:04:21] <rayh> IMO halcmd is nearly great.
[03:04:41] <SWPadnos> I think it's probably OK to release with the config system as is.
[03:04:47] <jmkasunich> the problem right now, described in terms of apt-get:
[03:04:57] <SWPadnos> as Steve already said, it's already lightyears ahead of having to recompile to change anything
[03:05:06] <jmkasunich> we save the list of packages installed on the system by generatiing an apt-get install command for each one
[03:07:49] <jmkasunich> lets look at this another way
[03:08:03] <jmkasunich> if halcmd is apt-get, and halconfig is synaptic....
[03:08:16] <cradek> I think we already all understand the problem exactly...?
[03:08:23] <jmkasunich> what are we missing, and how does the apt system solve the same problem?
[03:08:52] <jmkasunich> or doesn't it have the problem?
[03:08:56] <cradek> (I'm not familiar with synaptic)
[03:09:12] <cradek> isn't it just a list of the packages in the cache, with a checkbox by each one?
[03:09:38] <jmkasunich> it lets you check what packages are available, see whats installed, install things - basically a GUI front end to apt-get and/or dpkg
[03:10:05] <rayh> The "truth" is out there somewhere and both synaptic and apt and dpkg all get it rather than having someone write it on the local system.
[03:10:07] <jmkasunich> you can search the package lists, etc (find me all packages with "CNC" in the description, etc
[03:10:43] <jmkasunich> I think maybe apt simply doesn't have the problem
[03:10:52] <cradek> jmkasunich: I agree, I think a list of packages with a state for each one is too simple to compare to a netlist
[03:11:09] <jmkasunich> you apt-get install something (or install it with synaptic) and it is there the next time you boot up, theres no need to "save" anything
[03:11:55] <jmkasunich> our problem is that the state of a HAL is volatile, so you need to save it
[03:12:08] <jmkasunich> the state of the packages on a computer is non-volatile
[03:12:11] <rayh> That was NIST's attempt with the writing of var, tbl, and ini when emc shut down.
[03:12:28] <jmkasunich> heh, we haven't even touched on var and tbl
[03:12:40] <rayh> Save the current state of the machine.
[03:13:10] <steve_stallings> Could EMC2 just log all changes to a set of files and "rerun" the files after reading the INI. Then when the user gets around to updating the INI he could kill off the old log files.
[03:13:10] <SWPadnos> different problem domains - there's a definitive list of options for apt and synaptic
[03:13:15] <rayh> But unless we really standardized all of our hal files, we don't have a simple way to do that.
[03:13:21] <SWPadnos> hal is a bit nmore ephemeral
[03:13:48] <jmkasunich> rayh: you've hit on part of it
[03:13:51] <rayh> steve_stallings, That is what "halcmd show" does now
[03:14:10] <steve_stallings> Yes, but apply it to ALL changes, not just HAL
[03:14:14] <cradek> rayh: I wouldn't be arguing if halfiles were as simple as var or tbl files
[03:14:26] <jmkasunich> if we standardize hal files, then we are back to a system with a few fixed configs - easier to manage, but less flexible.
[03:14:48] <rayh> The problem is that we don't start and end up in the same configuration when we use halcmd save
[03:15:59] <SWPadnos> the problem is that there are a number of source files, and only one save file
[03:16:13] <jmkasunich> SWP: exactly (at least that is part of it)
[03:16:34] <SWPadnos> unless hal (or halcmd, since that's the UI for hal) remembers where it *first* got a piece of info, it's a very tricky problem
[03:16:47] <SWPadnos> even doing that is tricky
[03:18:29] <rayh> It is pretty obvious that there is not an easy answer that meets all the needs.
[03:18:38] <jmkasunich> yep
[03:19:20] <jmkasunich> lets back up a little tho - the main reason we added the ability to pull hal info from the ini is so that joe user could ignore the hal files
[03:19:41] <jmkasunich> so why can;t the tuning utility focus on the ini file instead of the hal files?
[03:20:05] <jmkasunich> granted, that is less powerfull (it can only manipulate things that are in the ini, halconfig can manipulate anytthing)
[03:20:08] <SWPadnos> because it uses halcmd save to save the results?
[03:20:10] <cradek> good question
[03:20:23] <jmkasunich> like this"
[03:20:35] <jmkasunich> read ini file, identify each hal file that is used
[03:21:07] <jmkasunich> read each hal file looking for and remembering [AXIS_0]P items (remember the assocaited hal parameter
[03:21:25] <jmkasunich> then show the user a list of only those things
[03:21:42] <jmkasunich> let them change them, issue setp commands immediately so they can see the result,
[03:21:53] <jmkasunich> when they're happy, rewrite only the ini file
[03:21:54] <cradek> when he changes one, both rewrite the ini and send the halcmd
[03:22:37] <jmkasunich> net result, he sees a list of perhaps 20 items (instead of dozens), but those are the ones he most wants to change anyway (for routine tuning)
[03:22:57] <cradek> jmkasunich: you might still need a whitelist so things like scale aren't in there
[03:23:13] <cradek> I like the general idea
[03:23:28] <jmkasunich> you mean to prevent them from changing scale while tuning?
[03:23:31] <cradek> yes
[03:23:45] <jmkasunich> they can change scale (and lots more) if tuning with halcmd or halconfig
[03:23:55] <cradek> I know, but that's one of the problem I thought you were trying to solve
[03:23:58] <cradek> s
[03:24:00] <jmkasunich> that is really a separate issue that any approach should deal with
[03:24:08] <cradek> ok
[03:24:40] <SWPadnos> changing scale is OK, if it's done right
[03:25:02] <SWPadnos> one approach would be to just zero all axis positions before changing it
[03:25:07] <jmkasunich> that gets us back to the plan of last years fest, which was to keep Aunt Tilly away from HAL and focus her on the ini file
[03:25:10] <SWPadnos> you can't home until you have scale set anyway
[03:25:34] <rayh> You guys are all the way back to the "read the ini into a text widget" and impose a change there but never really check to see that the change was made and that the final saved ini is what was running when the system shut down.
[03:26:05] <SWPadnos> I don't think so, if I understood you correctly
[03:26:22] <jmkasunich> as soon as the change is requested (before you even modify the ini file) you issue a halcmd setp
[03:26:29] <jmkasunich> so the change takes place right away
[03:26:41] <SWPadnos> the ini shouldn't be changed until requested by the user
[03:26:47] <rayh> Most of the code for such a mess is already written and could probably be put together into a tuning system in a few days.
[03:27:10] <rayh> Imagine that I'm running this widget and attempting to tune.
[03:27:13] <SWPadnos> we're working on the problem of getting settings back where they came from
[03:27:23] <SWPadnos> like into the ini, rather tahn a hal file
[03:27:27] <SWPadnos> than
[03:27:33] <rayh> along comes jmk and says hey try a terminal and bin/halcmd setp xxx
[03:27:47] <rayh> Now the HAL is out of sync with the widget we have.
[03:28:03] <jmkasunich> so slap jmk's hand
[03:28:09] <cradek> then kick jmk in the shin and tell him you're using the tuning gui
[03:28:16] <jmkasunich> we're not gonna have perfection
[03:28:20] <SWPadnos> then kick - oh, wait
[03:29:14] <rayh> I think this is clearly the either or thing we laid out earlier.
[03:29:21] <jmkasunich> I'd call that tool something like "tuneini" - the key point is that it only shows the user things that are in the ini file, and that is the only thing he can change
[03:29:28] <steve_stallings> As a potential hardware vendor, I would expect to furnish buyers with a preconfigured HAL, but expect the purchaser to be able to easily set Scale, Max Accel, Max Speed, PID and such. I think this model of users covers many of the folks we are trying to reach.
[03:29:30] <rayh> Is it a point-n-click or is it a unix text based file.
[03:30:01] <SWPadnos> it can be both, as long as you're talking about user interface first, and storage method second
[03:30:05] <jmkasunich> rayh: I think this most recent suggestion simply tries to avoid the problem by looking only at the ini file
[03:30:13] <SWPadnos> but putting a text file into a UI is silly, IMO
[03:30:15] <jmkasunich> on the assumption that Aunt Tilly only needs to edit the ini file
[03:30:31] <jmkasunich> the interface would be tilly friendly, clicky
[03:30:44] <jmkasunich> I'm talking about how the guts work
[03:30:54] <SWPadnos> right - as long as all tuning parameters are in the ini file, then this works well
[03:30:58] <SWPadnos> for tuning
[03:31:05] <cradek> I'm sure this was obvious to everyone but me, but I just looked through the stg halfiles and there are NO tuning parameters in them
[03:31:06] <jmkasunich> (allowing them to freely edit the ini in a text widget _would_ be a disaster, for all the reasons you cite)
[03:31:17] <SWPadnos> they should be in the ini
[03:31:21] <jmkasunich> it was not so obvious
[03:31:25] <jmkasunich> I didn't know that
[03:31:31] <jmkasunich> (that they weren't there)
[03:31:44] <jmkasunich> no PID at all, or no fetching of PID from the ini
[03:31:52] <SWPadnos> none referenced from the ini, or none at all?
[03:31:55] <SWPadnos> right ;)
[03:31:57] <cradek> no tunable parameters
[03:32:04] <jmkasunich> waitaminnit - doesn't the stg config use core-servo.hal?
[03:32:11] <cradek> yes
[03:32:15] <cradek> but all the parameters come from the ini
[03:32:21] <jmkasunich> thats where the PIDs are (and where the gains come from the ini)
[03:32:35] <jmkasunich> ok then, whats the problem?
[03:32:48] <cradek> right, I'm only saying that for any tuning, you don't want to touch the halfiles.
[03:32:57] <jmkasunich> oh
[03:33:03] <jmkasunich> I thought we agreed on that already
[03:33:05] <SWPadnos> again, an ini-style halcmd would solve this tuning thing
[03:33:06] <cradek> * cradek spits it out
[03:33:07] <cradek> sorry
[03:33:34] <SWPadnos> [AXIS_0]
[03:33:38] <jmkasunich> ray's halconfig, like halcmd, can be used for far more than tuning
[03:33:40] <SWPadnos> component=pid.0
[03:33:51] <SWPadnos> PGain = 100
[03:33:51] <cradek> right, but that is not our goal, right?
[03:33:55] <rayh> It would be best to take tuning out of halconfig.
[03:34:00] <jmkasunich> everybody has their own goals
[03:34:24] <jmkasunich> we aren;t gonna come up with a clean way to do the generic stuff, so I was talking about a tuning only tool
[03:35:02] <jmkasunich> it would present a menu (tree, listbox, whatever) of every ini file variable that is used in a hal file
[03:35:23] <jmkasunich> it would know what hal params are associated with the ini vars, but wouldn't show that to the user
[03:35:49] <jmkasunich> when the user clicks on an ini var and gives a new value, it would issue a halcmd setp to make the immediate change
[03:35:54] <rayh> Is there any known instance of one hal file calling another.
[03:36:03] <SWPadnos> no, there's no include
[03:36:06] <jmkasunich> and either right away or on exit it would write the new value to the ini
[03:36:18] <SWPadnos> it's only from the command line or the ini that hal files are used
[03:37:07] <jmkasunich> adding an include capability has been discussed, but as long as this approach descends into included files it would still work
[03:37:19] <rayh> So all of the hal files are listed in order in the ini?
[03:37:24] <jmkasunich> yes
[03:38:40] <rayh> The current thinking sure doesn't meet my needs.
[03:38:53] <rayh> but it should let a stand alone guy tune.
[03:39:01] <SWPadnos> there's no particular reason why you couldn't save the hal files in the [HAL] section of the ini (except that the file would be large and ugly ;) )
[03:39:40] <jmkasunich> that is functionally equivalent to saying there can be only one hal file mentioned in the HAL section
[03:40:23] <SWPadnos> err - I meant put the contents of the hal files into the ini
[03:40:34] <jmkasunich> I know what you mean
[03:40:38] <SWPadnos> ok ;)
[03:40:43] <SWPadnos> it's still a stupid idea
[03:40:45] <rayh> Sure I do this with the ddt's and test stuff now.
[03:40:49] <jmkasunich> if all the files are inline in the ini, that means there is no reuse or anything
[03:41:06] <rayh> I just write a testing.ini
[03:41:10] <SWPadnos> no, for saving purposes you can save an ini file that has all the hal commands as well
[03:41:12] <jmkasunich> so in essence, you have one big hal file (it just happens to be embedded in the ini)
[03:41:16] <SWPadnos> right
[03:41:36] <SWPadnos> but an end user doesn't care, as long as they can tune their machien
[03:41:38] <SWPadnos> machine
[03:42:16] <rayh> If that were really true
[03:42:24] <rayh> we wouldn't be having this discussion.
[03:42:26] <SWPadnos> heh
[03:42:37] <rayh> we'd just use halcmd save
[03:42:42] <steve_stallings> Who is the intended audience for the "release"? Users need simple to configure. Integrators need technically sound methods, even at the expense of some complexity. Developers need systems that can be implemented and maintained without excess d
[03:43:07] <SWPadnos> damned good question!
[03:43:16] <steve_stallings> excess development effort.
[03:43:32] <jmkasunich> the release is for users
[03:44:40] <jmkasunich> developers and risk-tolerant integrators are already using it
[03:45:34] <SWPadnos> I think the file approach is technically sound enough for integrators
[03:45:41] <SWPadnos> file editing, that is
[03:45:50] <SWPadnos> developers should be able to edit text files as well
[03:46:13] <SWPadnos> users could get simple tuning done with a tool like jmk is proposing
[03:46:36] <jmkasunich> its also possible to use halconfig, then save to a new filename (don't overwrite your existing hal file(s))
[03:46:43] <jmkasunich> then edit as needed
[03:50:26] <SWPadnos> ok, there are two issues with a halconfig-type solution right now
[03:50:50] <rayh> gotta run guys. It's been fun. Perhaps someone could explain to me in an email what the consensus is regarding this. Unless the consensus is that we ain't gonna do anything different than we are doing now. In which case I'll remove halconfig and write the little tuning thing you want.
[03:50:52] <SWPadnos> 1) the saved information doesn't mirror the source of the information, so things from the ini are no longer from the ini
[03:51:08] <SWPadnos> 2) motion is a weird hal component
[03:51:11] <jmkasunich> rayh: don't remove halconfig - it still serves a purpose
[03:51:19] <SWPadnos> right
[03:52:11] <jmkasunich> SWP: thats about the extent of it
[03:52:19] <jmkasunich> we can't solve 1 without radical changes
[03:52:27] <jmkasunich> we can address 2 only partly
[03:52:38] <jmkasunich> mostly because of the thread periods
[03:52:42] <SWPadnos> 2 can be done with generic ini string replacement
[03:53:28] <SWPadnos> and that's a manifestation of 1 really
[03:53:45] <SWPadnos> the BASE_PERIOD should come from the ini, like P I D ...
[03:53:52] <jmkasunich> yes
[03:53:57] <SWPadnos> but there's no way to tell at halcmd save time
[03:54:48] <SWPadnos> generic ini replacement should be very easy, as long as everything is read as a string
[03:54:48] <jmkasunich> if the run script did "halcmd loadrt motmod base_period=$BASE_PERIOD etc", then halcmd save would save it correctly
[03:55:34] <jmkasunich> the problem is that the next time you run, the run script does the loadrt motmod, then the hal file (generated by the previous save) also does a loadrt motmod
[03:56:14] <SWPadnos> sure, so take it out of the run script, and make it possible to use halcmd
[03:56:20] <jmkasunich> yeah
[03:56:22] <SWPadnos> make an "emc.hal" file
[03:56:47] <jmkasunich> I'd just add it to the core_*.hal files
[03:57:12] <SWPadnos> true - emc_servo and emc_stepper
[03:57:19] <SWPadnos> rather than core*
[03:57:49] <jmkasunich> the core_* files exist in CVS, I don't see any reason to replace or rename them
[03:57:55] <SWPadnos> true
[03:58:25] <jmkasunich> I think that independent of anything else we've discussed, making motmod more "normal" is a good thing and should be done
[03:58:36] <SWPadnos> yes
[03:58:43] <SWPadnos> and generic string replacement from the ini
[03:58:55] <SWPadnos> before command parsing
[03:58:56] <jmkasunich> yeah
[03:58:58] <cradek> anything that simplifies the crazy emc script is good by me
[03:59:17] <jmkasunich> SWP: can I talk you into doing the halcmd changes (generic ini string)?
[03:59:18] <SWPadnos> yeah - it would take out half of the load, it seems
[03:59:21] <SWPadnos> yes
[03:59:27] <jmkasunich> I can do the changes to motmod and the configs
[03:59:31] <jmkasunich> and the runscript
[03:59:53] <SWPadnos> ok. I'll do the ini string thing. the code's already there anyway
[04:00:23] <jmkasunich> * jmkasunich fires up an editor ;-)
[04:01:00] <SWPadnos> * SWPadnos fires up cygwin
[04:01:50] <steve_stallings> steve_stallings is now known as steves_logging
[04:01:58] <SWPadnos> cradek, I still have a problem with 3D_Chips in axis
[04:02:15] <cradek> what problem?
[04:02:17] <SWPadnos> I can't run the file unless line N50 is commented out
[04:02:23] <SWPadnos> N50T1M6
[04:02:54] <cradek> do you get an error?
[04:03:04] <SWPadnos> nope. axis just stops, no motion, but I can hit the stop button
[04:03:22] <cradek> what configuration?
[04:03:29] <cradek> I wonder if you have a missing tool loopback
[04:03:38] <SWPadnos> at least with my univstep config
[04:03:38] <cradek> try the distributed sim
[04:03:57] <SWPadnos> I added the tool loopback, it didn't help (I think - I'll check that)
[04:04:12] <cradek> it works fine here with the distributed sim
[04:04:21] <SWPadnos> hmm - maybe I didn't
[04:04:21] <cradek> (I've never seen a problem running chips)
[04:04:27] <cradek> aha
[04:04:38] <SWPadnos> no wait, I tested on m5i20 as well , with the loopback added
[04:04:44] <SWPadnos> it's not a single configuration
[04:04:58] <SWPadnos> I'll test them now ;)
[04:04:59] <cradek> still, try sim
[04:05:01] <cradek> ok
[04:05:21] <cradek> that's got to be the problem - it's just waiting forever for the tool change to be done
[04:06:19] <SWPadnos> could be. it may be a good thing to have axis hilight lines that don't cause motion
[04:06:43] <cradek> can't really do that with the current paradigm
[04:07:05] <SWPadnos> ok. it's my config. sorry for the noise
[04:07:13] <cradek> the current line in the stat buffer comes from motion
[04:07:13] <SWPadnos> m5i20 is working for me
[04:07:18] <cradek> no problem
[04:07:40] <SWPadnos> ah - then how does tkemc hilight non-move lines? (or am I wrong on that one as well?)
[04:08:04] <cradek> I'm not 100% sure what scheme it uses, but I bet it's the same
[04:09:03] <SWPadnos> ok. I could have sworn that I've seen it step through every line of code, but I could be hallucinating ;)
[04:09:41] <cradek> it's a good illusion since most lines cause motion
[04:09:53] <SWPadnos> heh
[04:11:10] <SWPadnos> do you suppose that env vars should also just be substituted before parsing?
[04:13:14] <SWPadnos> jmkasunich, is there any reason to keep the NO_INI ifndefs?
[04:13:41] <jmkasunich> yes
[04:13:59] <jmkasunich> if you want to compile HAL independent of EMC/libnml
[04:14:08] <SWPadnos> ah, OK.
[04:14:31] <SWPadnos> and the env var substitution? should that also be done to the whole line before parsing?
[04:14:56] <jmkasunich> dunno, right now nobody uses it anyway
[04:15:02] <jmkasunich> but I guess we should be consistent
[04:15:44] <SWPadnos> yep. it's in 2 places, just like the inifile stuff
[04:16:00] <SWPadnos> funny - this will probably reduce the size of the program ;)
[04:16:05] <jmkasunich> good
[04:16:11] <SWPadnos> yep
[05:37:41] <jmkasunich> SWPadnos: how goes those halcmd mods?
[05:37:56] <SWPadnos> ok, but I'm talking too much ;)
[05:41:40] <SWPadnos> jmkasunich, I'm thinking of making the variable name end at either whitespace or a period
[05:42:00] <SWPadnos> that would allow replacement of module names, such as pid.0
[05:42:26] <jmkasunich> not sure I follow (brain is slowing down)
[05:42:36] <SWPadnos> ok. :)
[05:42:42] <SWPadnos> given this in the ini:
[05:42:46] <SWPadnos> [AXIS_0]
[05:42:57] <SWPadnos> comp = pid.0
[05:43:04] <SWPadnos> P=1000
[05:43:06] <SWPadnos> ...
[05:43:14] <SWPadnos> youcould do this in a hal file
[05:43:33] <SWPadnos> [AXIS_0]comp.PGain = [AXIS_0]P
[05:44:27] <SWPadnos> that only works if I stop the [section]var parsing at the first '.'
[05:44:36] <jmkasunich> so the only restriction implied by that is that variable names in the ini file can't contain a period
[05:44:50] <SWPadnos> which prevenrs variable names with periods (which there aren't any of, that I saw_
[05:44:52] <SWPadnos> right ;)
[05:44:56] <SWPadnos> prevents
[05:45:33] <jmkasunich> seems reasonable, and yet it still bugs me
[05:45:56] <jmkasunich> when bash does substitution it uses parens for delimiting var names
[05:45:56] <SWPadnos> well, I can add that later
[05:46:11] <SWPadnos> are parens used anywhere else?
[05:46:17] <jmkasunich> FOO=hi
[05:46:26] <jmkasunich> echo ($FOO)there
[05:46:28] <jmkasunich> hithere
[05:46:40] <SWPadnos> ok, we can do that
[05:46:43] <jmkasunich> not as part of ini file names
[05:46:46] <SWPadnos> with optional parens
[05:47:35] <jmkasunich> so if the parser sees [ it looks for ] to end the section name, then whitespace to end the var name
[05:47:54] <jmkasunich> if it sees ([ it looks for ] to end the section name, and ) to end the var name
[05:48:10] <SWPadnos> I'd do it as [section](var)...
[05:48:16] <SWPadnos> with the parens optional
[05:48:16] <jmkasunich> if it sees ( followed by anything other than [ or $ it ignores it
[05:48:21] <jmkasunich> oh, ok
[05:48:22] <jmkasunich> thats simpler
[05:48:49] <jmkasunich> but doesn't work for the $ case
[05:49:08] <SWPadnos> I'd do it only for ini substitution, not env
[05:49:28] <SWPadnos> $env, [section]var, or [section](var.yadda).blah
[05:49:57] <jmkasunich> but what if you want to do $COMP.Pgain?
[05:50:25] <jmkasunich> how about $env, $(env), [sect]var and [sect](var)?
[05:50:33] <SWPadnos> ok - that sounds good
[05:50:46] <jmkasunich> $(env) is reversed from the bash norm of ($env), but so what...
[05:50:58] <SWPadnos> I suppose that parens can be used anywhere to group chars, like quotes
[05:51:25] <jmkasunich> wow, its late
[05:51:36] <SWPadnos> yep. do your changes require this mod?
[05:51:36] <jmkasunich> the stuff I committed is independent of your changes
[05:51:40] <SWPadnos> ok, good ;)
[05:51:44] <jmkasunich> don't feel like you need to do it right away
[05:51:52] <SWPadnos> I may do that stuff tomorrow
[05:52:14] <jmkasunich> once your changes are done I will add the loadrt motmod line to each config and remove the crap from the run script
[05:52:29] <jmkasunich> but that is independent of the addf fix which I already committed
[05:52:33] <SWPadnos> ok, cool
[06:01:55] <jmkasunich> goodnight
[06:02:03] <SWPadnos> one question
[06:02:07] <jmkasunich> shoot
[06:02:21] <SWPadnos> why did you remove the thread position from the configs (or at least m5i20)?
[06:02:27] <SWPadnos> on the addf lines
[06:02:39] <jmkasunich> most of them were redundant, and many were wrong
[06:03:00] <SWPadnos> ok. I had changed the m5i20 ones so that the thread made sense
[06:03:16] <SWPadnos> it had write at the beginning, motion calcs after pid, etc
[06:03:20] <jmkasunich> a lot of them were needed before, to explicitly put the functions ahead of the motion control functs that were already there
[06:03:26] <SWPadnos> right
[06:03:38] <SWPadnos> it defaults to the end of the line?
[06:03:40] <jmkasunich> now the motion control functs are explicitly installed in the right place
[06:03:41] <jmkasunich> yes
[06:03:48] <SWPadnos> ok, cool
[06:03:52] <SWPadnos> thanks
[06:03:54] <SWPadnos> good night
[06:03:58] <SWPadnos> :)
[06:04:11] <jmkasunich> I probably should double check those threads, to make sure they're right
[06:04:19] <jmkasunich> but not tonight
[06:04:35] <SWPadnos> that's what distributed development is for ;)
[06:04:44] <jmkasunich> yep
[06:26:53] <SWPadnos> SWPadnos is now known as SWP_Away
[13:37:32] <SWP_Away> SWP_Away is now known as SWPadnos
[13:37:40] <SWPadnos> hi Ray
[13:37:47] <rayh> hey morning steven.
[13:37:51] <SWPadnos> oh yeah, it is ;)
[13:37:54] <SWPadnos> damn
[13:38:21] <rayh> Not another all nighter?
[13:38:31] <SWPadnos> no, only up 'til 2:00
[13:38:47] <rayh> and back up already... I'm impressed
[13:38:55] <SWPadnos> woke up early to make breakfast for the wife, though (birthday)
[13:39:15] <rayh> logger_devel, bookmark
[13:39:15] <rayh> See
http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2006-03-17#T13-39-15
[13:39:40] <SWPadnos> I think the temporary solution to the save problem was fixed by jmk last night
[13:39:49] <SWPadnos> err - was made last night
[13:40:21] <SWPadnos> motion no longer adds itself to the threads, so it can be loaded from a hal save file
[14:13:41] <rayh> addf motion-command-handler servo-thread
[14:13:41] <rayh> addf motion-controller servo-thread
[14:13:45] <rayh> Still in there.
[14:14:04] <SWPadnos> in the hal files now, not done by motion itself (or shouldn't be)
[14:14:16] <SWPadnos> I think it still creates the threads though, so that could be a problem
[14:14:29] <rayh> Okay. So we need em in all of the .hal files. Or core files.
[14:14:40] <SWPadnos> jmk added it to all the *_io files last night
[14:14:51] <SWPadnos> if you cvs up now, you'll get a consistent set
[14:15:05] <rayh> I just did.
[14:15:15] <SWPadnos> ok, then you should have a conssitent set ;)
[14:15:20] <SWPadnos> err - you know
[14:16:27] <rayh> Okay. I see them in core_xx in common.
[14:17:25] <SWPadnos> ok. there were a lot of commit messages about the various configs as well
[14:21:17] <rayh> perfect startup.
[14:21:35] <SWPadnos> cool
[14:37:27] <SWPadnos> I think there's still one problem with reloading an emc HAL config - threads
[14:41:15] <rayh> I didn't see a problem.
[14:41:35] <SWPadnos> no - threads aren't saved by halcmd save
[14:42:24] <SWPadnos> they don't get re-created when you reread a config, but they also don't get created if you try to load from a blank HAL
[14:43:13] <rayh> They must still be made by a script ahead of the hal cause I can run.
[14:43:38] <SWPadnos> yes, motmod create the threads, but no longer adds its functions to them
[14:43:58] <rayh> Sure and the new netlist adds them.
[14:44:05] <SWPadnos> so for your purposes, this isn't a problem
[14:44:07] <SWPadnos> yes
[14:44:07] <rayh> adds motion to them rather
[14:45:07] <rayh> Right. jmk and I talked just a bit about moving thread creation but he said there was an issue with reading the values from the ini.
[14:45:20] <SWPadnos> I'm working on that now
[14:45:32] <SWPadnos> the halcmd part of it, anyway
[14:45:36] <rayh> So we will have another update to the hal files.
[14:45:47] <rayh> configs that is.
[14:45:54] <SWPadnos> I think so
[14:45:55] <rayh> brain is fried already.
[14:46:21] <rayh> No problem. I'll get started on that ini editor of tuning vars.
[14:46:26] <SWPadnos> the run script will be reduced in size and complexity, and one or two lines will be added to the ini
[14:46:34] <SWPadnos> cool
[14:47:01] <cradek> everybody's working configurations are going to be broken, right?
[14:47:09] <SWPadnos> probably
[14:47:21] <SWPadnos> actually, yes
[14:47:38] <SWPadnos> since the new motion controller won't add its functions to the servo thread
[14:52:40] <rayh> I'll revive emctuning.tcl. It's in the tcl/bin file already.
[14:53:18] <rayh> Question though.
[14:53:37] <rayh> As is it uses emcsh to access nml.
[14:53:48] <rayh> It did that so that it could change global tuning variable.
[14:53:55] <rayh> These are not used any more with HAL.
[14:54:28] <rayh> But if we keep emcsh, we could run an axis through motion if we wanted to.
[14:54:49] <rayh> Like a button on the display, that does incremental jogs.
[14:54:53] <rayh> Should we?
[14:55:21] <SWPadnos> hmmm
[14:55:46] <SWPadnos> it would be cool to automatically move some amount, and show a halscope trace of FERROR and the like ;)
[14:56:11] <rayh> If not, I'd switch the display to the standard tk "wish" shell.
[14:56:50] <SWPadnos> what do you lose by using emcsh? (ie, why get rid of it)
[14:56:50] <rayh> Okay for now I'll leave the emcsh shell.
[14:58:19] <rayh> It doesn't need to know where it's run from or much else other than the ini file name.
[14:58:42] <SWPadnos> ah, but emcsh does need access to the NML file and such.
[14:59:03] <rayh> emcsh is the NML connector.
[14:59:10] <SWPadnos> well, if it works, I'd leave it alone
[14:59:17] <SWPadnos> if it doesn't work, change to wish ;)
[14:59:22] <rayh> right.
[15:21:40] <rayh> I see that the original tcl scripts included what we are thinking of as tuning, changing the values of PID +, under calibration.
[15:22:03] <rayh> And a separate tuning thing that did a bit of the motion and watching.
[15:28:28] <rayh> It sounded last night like we wanted to be able to set axis scale from this screen as well.
[15:28:46] <SWPadnos> probably, and that would require emcsh, I think
[15:29:08] <SWPadnos> you need to move to 0 or set home before changing scale
[15:29:34] <rayh> Yes and that would mean we would use it for steppers as well as servos.
[15:29:45] <SWPadnos> actually, you could determine scale as well, for people with dial indicators or the like
[15:30:16] <rayh> I could? ha ha ha
[15:30:22] <SWPadnos> well, one could ;)
[15:30:47] <rayh> Right. Sure command some distance and enter actual.
[15:31:07] <rayh> a teach function.
[15:31:09] <SWPadnos> yep. set scale to 1, move X counts (steps), until the indicator shows 1 (unit)
[15:31:22] <SWPadnos> then scale = position
[15:31:51] <rayh> Oh I was thinking command a distance and input actual rather than keep stepping until.
[15:32:03] <SWPadnos> or commanded vs actual, as you said
[15:32:18] <SWPadnos> you'd need to be in the ballpark first, though
[15:32:53] <rayh> We'd have a backlash problem with add/subtract steps to scaled distance.
[15:33:25] <SWPadnos> I'd always go in the same direction.
[15:34:04] <rayh> Right but most wouldn't.
[15:34:08] <SWPadnos> heh
[15:34:24] <SWPadnos> for an automated move (commanded by the tuning tool), it could
[15:34:33] <SWPadnos> start at some position
[15:34:51] <SWPadnos> move +X (for example), some number of feedback counts / steps
[15:35:06] <SWPadnos> allow the user to move more counts, like jogging
[15:35:18] <SWPadnos> but only in the + direction (a "more" button)
[15:35:37] <SWPadnos> they click "reached my mark" when the indicator shows the reading they expect
[15:35:49] <rayh> This whole issue of dynamic scaling gets mixed up with tuning.
[15:36:05] <rayh> gotta tune so it moves, gotta set scale, gotta tune.
[15:36:23] <rayh> and all that gets mixed up with accel and max vel.
[15:36:26] <SWPadnos> I'd say that you can use some very conservative settings for setting scale, then allow tuning
[15:36:45] <SWPadnos> start with 0.1 for max_vel
[15:37:00] <SWPadnos> and 1 for max_accel
[15:37:14] <SWPadnos> once scale is set, choose some better numbers
[15:38:00] <SWPadnos> if the user knows what they're doing, they can change those default values
[15:38:04] <rayh> I think I'll ignore dynamic stuff and just build it the way it was.
[15:38:14] <SWPadnos> yep, good idea for now.
[15:38:27] <SWPadnos> there should probably be agood plan before getting too complex
[15:39:07] <rayh> I know how I was attacking these issues in halconfig but here...
[15:39:54] <SWPadnos> there are probably more issues than you and I can think of at this moment
[15:40:00] <SWPadnos> or want to, come to think of it ;)
[15:45:33] <rayh> You bet. The list seems nearly endless.
[15:45:46] <rayh> Need one of those flow charting programs.
[15:46:18] <SWPadnos> yep
[15:46:35] <SWPadnos> will there be a projector (or other large screen) available at CNC Workshop?
[15:51:57] <rayh> I'm working on stealing my wife's projector.
[15:52:02] <SWPadnos> heh
[15:52:08] <SWPadnos> it could be useful
[15:52:12] <rayh> 1024x768
[15:52:20] <SWPadnos> still useful
[15:52:23] <SWPadnos> :)
[16:15:32] <rayh> Can I run some logic for simple value setting past you'se guys 'eh.
[16:15:44] <SWPadnos> sure
[16:15:52] <rayh> 1 read the ini for .hal files
[16:15:52] <rayh> 2 read the hal files for step v servo
[16:15:52] <rayh> if freqgen or stepgen
[16:15:52] <rayh> 3 read the .hal files for ini references, make a table of
[16:15:52] <rayh> HAL file and HAL names
[16:15:53] <rayh> and ini section, var name, and var value
[16:15:54] <SWPadnos> but only for a few more hours ;)
[16:15:55] <rayh> 4 Build display widgets for each HAL element
[16:15:57] <rayh> (wonder how to scale sliders if used)
[16:15:59] <rayh> 5 Issue halcmd as values change
[16:16:01] <rayh> 6 Write changes to ini when done.
[16:17:22] <SWPadnos> that looks basically sound
[16:19:28] <SWPadnos> what are the differences between step and servo, for this app?
[16:19:52] <SWPadnos> I'd think that the ini / hal files would already show the differences (ie, which params to adjust)
[16:21:03] <rayh> I've not gotten that far.
[16:21:11] <rayh> Still stuck on 1
[16:21:27] <rayh> if we use emcsh there is a command to get a inivar
[16:21:50] <rayh> but I don't think it will work for the HALFILE, cause there can be more than one.
[16:21:55] <SWPadnos> you need whole the HAL section, I imagine
[16:22:16] <SWPadnos> there's probably an awk program that can do that for you
[16:22:24] <rayh> So I have to forget that emcsh command and find the name and location of the ini that is running.
[16:22:43] <SWPadnos> how do you expect this tool to be run?
[16:22:54] <SWPadnos> (command line or from an emc GUI)
[16:23:07] <rayh> I don't see that that variable is known to tkemc
[16:23:22] <rayh> My guess is that it will be both.
[16:24:07] <rayh> If started without a running emc, then we should let the user select a config using picker.
[16:24:27] <SWPadnos> I think the tuning tool makes no sense without a running emc
[16:24:50] <SWPadnos> or at least a running emc HAL
[16:26:36] <rayh> Unless a body wants to set values before he starts the first time.
[16:27:00] <rayh> So for now we just run it from a menu in tkemc or mini.
[16:27:09] <SWPadnos> or from the config picker
[16:27:19] <SWPadnos> select a config, click a "tune" button ...
[16:27:26] <SWPadnos> instead of "run"
[16:27:48] <SWPadnos> not surehow to implement that, though
[16:28:24] <rayh> -ini $EMC_INIFILE
[16:28:44] <SWPadnos> well, how to run the tuning tool without the normal GUI
[16:28:51] <SWPadnos> from the config picker
[16:29:00] <rayh> So it looks like tkemc knows it's ini file name.
[16:29:10] <SWPadnos> cool
[16:29:20] <rayh> Config picker simply returns selected value to the calling program.
[16:29:29] <SWPadnos> but only if run from the runscript
[16:29:32] <rayh> At least it did early on.
[16:29:34] <SWPadnos> the ini thing
[18:26:30] <rayh> Hey cradek did you get a really sarcastic email from a guy named george?
[19:23:06] <cradek> tecos? I got two very polite emails
[19:23:53] <cradek> he asked me a question a while back, I answered, then he sent another message just the other day saying he figured it out and I shouldn't bother answering because I must be busy (he obviously didn't get my answer)
[19:24:56] <rayh> He called today. I'll call him back and let him know the reply got lost. Thanks.
[19:25:13] <cradek> actually I answered BOTH his emails
[19:25:27] <cradek> he must have some kind of mail problem
[19:25:38] <rayh> K. I'll tell him.
[19:25:55] <cradek> was he upset? he seemed very nice and polite in his messages to me
[19:26:30] <rayh> He is the guy who first moved motors with a PC.
[19:27:07] <rayh> before galil or any of the other cards.
[19:27:34] <rayh> I'm trying to get him to the cnc-workshop for a day or so.
[19:27:52] <rayh> He builds robot controls for welding and other industrial apps.
[19:28:33] <cradek> sounds like an interesting guy
[19:30:18] <rayh> Was a child in Greece. Lives near Detroit now.
[19:31:35] <cradek> I wonder what's wrong with his email - it would be nice if I could get my response to him even if it's late
[19:33:11] <cradek> (I sent a copy of the response again, when I answered his second email)
[19:35:14] <rayh> Must be some sort of mail filter. What addy did the replies go to?
[19:36:05] <rayh> he has both sbcglobal and pantec
[19:37:10] <cradek> [answer in private]
[19:37:36] <rayh> panautosys actually
[20:27:11] <alex_joni> hi guys
[20:33:36] <jepler> hi alex
[20:34:26] <alex_joni> hi jeff
[20:34:31] <alex_joni> hows everything?
[20:34:34] <jepler> oh not bad
[20:34:40] <alex_joni> glad to hear that
[20:34:47] <jepler> I watched a DVD last night instead of working on my servo etch-a-sketch
[20:34:57] <alex_joni> lol.. that's ok
[20:35:07] <cradek> jmk was around all night too, ready to help
[20:35:10] <jepler> yeah I know
[20:35:13] <jepler> I squandered that opportunity
[20:36:18] <alex_joni> help on hte etch-a-sketch ?
[20:36:28] <alex_joni> * alex_joni is kidding
[20:37:13] <jepler> alex_joni: I was having some trouble with hal and freqgen
[20:38:10] <alex_joni> oh.. you did?
[20:39:17] <jepler> well .. hal works just fine, but it's got a learning curve
[20:39:37] <jepler> I may or may not have found a bug in freqgen "type 1" stepping, though
[20:42:48] <alex_joni> still working on your DC conversion?
[20:43:24] <alex_joni> hint: I am starting to make a mental picture of a big version of my tripod..
[20:43:36] <jepler> DC?
[20:43:49] <jepler> Yeah, the DC servo version of etch-a-sketch
[20:44:30] <alex_joni> jepler: you talked about that a while ago ;)
[20:45:55] <alex_joni> guess you'll have a servo then :D
[20:45:57] <jepler> is "tripod" your machine that moved the ring attached to strings?
[20:47:20] <alex_joni> jepler: yes, half a hexapod ;)
[20:48:20] <jepler> hm .. with a 4th motor you could move the ring anywhere inside a tetrahedron
[20:48:24] <alex_joni> jepler: I've been thinking about making a cutting machine (a few meters big - something like 5x5m or bigger) out of that
[20:48:38] <alex_joni> yeah, but I like to have the base clear
[20:48:43] <alex_joni> and I already can do that
[20:48:50] <alex_joni> given gravity, and enough mass
[20:49:07] <alex_joni> probably a few (7-10kg) payload
[20:49:16] <cradek> that's a neat idea
[20:49:28] <alex_joni> cradek: yeah, and it would be very cheap too
[20:49:40] <cradek> you could counterbalance the other end of the "string" with the same mass
[20:49:51] <alex_joni> cradek: I don't have to :P
[20:50:03] <cradek> what kind of motor?
[20:50:06] <jepler> I don't understand how it's going to "cut" anything
[20:50:16] <cradek> jepler: extra mass in the center
[20:50:18] <alex_joni> jepler: you suspend a plasma cuttinghead by the strings
[20:50:26] <cradek> ahh
[20:51:05] <alex_joni> cradek: wanna know my secret plan ?
[20:51:06] <alex_joni> :D
[20:51:14] <cradek> I like secret plans
[20:51:23] <alex_joni> it just occured to me I SELL exactly what I need ;)
[20:51:25] <alex_joni> duh
[20:51:27] <alex_joni> http://www.robcon.ro/ro/prod/97/9341-9344.html
[20:52:04] <cradek> that is a motor?
[20:52:06] <rayh> Hi alex
[20:52:43] <alex_joni> cradek: no, that's a balancer
[20:53:12] <alex_joni> it's a device that delivers some force, so that an operator can move a thing easily (for example a big tool)
[20:53:13] <cradek> ah ok
[20:53:17] <alex_joni> rayh: hello
[20:53:33] <alex_joni> cradek: I plan on putting a motor to drive the wire that comes out of that
[20:53:34] <cradek> so you would pull the cable out of this, wrap it around the motor shaft/pulley, and clamp it to the payload
[20:53:58] <cradek> sounds very simple and clever
[20:54:03] <alex_joni> exactly, but not wrap around, but have 2 rollers (one on the motor, and one that's pressing against it)
[20:54:18] <alex_joni> the second one carrying an encoder
[20:54:51] <alex_joni> so you know the exact movement of the wire (in case the motor slips)
[20:54:57] <cradek> my setup seems more foolproof
[20:55:07] <cradek> I think with some mass it won't slip
[20:55:29] <rayh> who we calling a fool fool?
[20:55:30] <alex_joni> cradek: yeah, but you have to take into accoutn the amount of wire that overlaps, and so on
[20:55:34] <cradek> you could wrap several turns next to each other if the pulley is wide and flat
[20:55:43] <cradek> no, no overlap
[20:55:55] <alex_joni> if you manage to convince it not to overlap ;)
[20:56:09] <cradek> hmm it would walk up and down the pulley wouldn't it
[20:56:13] <cradek> ok not so good
[20:56:28] <alex_joni> cradek: I already do have the stuff I'm talking about
[20:56:29] <rayh> how about a spiral groove around the drum to allign the wire as it wraps on
[20:56:38] <alex_joni> it's the syste that drives the welding wire for MIG/MAG
[20:56:42] <alex_joni> system
[20:57:07] <alex_joni> cradek:
http://www.weldwell.co.nz/images/driverolls.jpg
[20:57:21] <cradek> aha
[20:57:24] <cradek> you're almost done :-)
[20:57:52] <alex_joni> yup, and now with our new facility I even have room to play in :D
[20:58:12] <alex_joni> I'll probably make a smaler one first (3 x 2500mm wires)
[20:58:25] <alex_joni> err.. 2500 travel distance on the wires
[20:58:37] <alex_joni> so probably 3500 wires or more
[20:58:52] <cradek> that seems pretty big to me
[20:59:03] <alex_joni> it seems pretty small to me ;)
[20:59:13] <alex_joni> eventually this needs to be about 10x10m
[20:59:18] <alex_joni> to be competitive :D
[20:59:40] <alex_joni> but 10m involves some serious problems..
[21:00:00] <alex_joni> like stretching of the wires
[21:00:32] <cradek> yes it will stretch for a long time
[21:00:47] <cradek> I bet any size will have that problem
[21:00:56] <alex_joni> I think it stretches about 1 cm / meter
[21:01:05] <alex_joni> probably a bit less
[21:01:14] <cradek> how long until it "stops" stretching?
[21:02:00] <alex_joni> it's not that kind of stretching
[21:02:15] <alex_joni> it will stretch based on the length of the wire
[21:02:34] <alex_joni> so you put out 1000mm of wire, but the head will be at 1020mm away
[21:02:38] <alex_joni> if you get my meaning
[21:02:39] <cradek> ok, you mean it won't stretch over time?
[21:02:45] <cradek> get longer over time
[21:02:49] <alex_joni> I surely hope not ;)
[21:03:18] <alex_joni> it's steel afterall, and the forces aren't that big so that "flowing" starts
[21:03:46] <alex_joni> you need a couple of hundred kg to do that on a 3 mm^2 wire
[21:04:45] <cradek> I see
[21:04:50] <cradek> (I know nothing about this)
[21:04:54] <alex_joni> but only a few kg more and it'll snap
[21:05:02] <alex_joni> so that's not an area where I want to be :D
[21:07:27] <alex_joni> heh, I took apart a robot system in under 1.5 hours today ;)
[21:07:47] <alex_joni> took me 3-4 hours to setup on monday :)
[21:26:41] <alex_joni> ok guys, I'm heading for bed..
[21:26:52] <alex_joni> some issues on emc2 & servo we need to adress this weekend
[21:27:05] <alex_joni> not sure wtf people are having issues with
[21:29:01] <cradek> ok goodnight
[21:29:48] <alex_joni> ok, night chris
[21:32:11] <rayh> see tiy akex
[21:32:19] <rayh> see you alex
[21:32:27] <rayh> better
[21:39:20] <SWPadnos> SWPadnos is now known as SWP_Away
[22:17:56] <rayh> Are we planning to keep max_vel and stepgen_maxvel as separate variables now?
[22:20:39] <cradek> rayh: headroom is still needed for jogging
[22:21:07] <cradek> rayh: we'd have to hash any change out with jmk
[22:21:09] <rayh> Okay
[22:21:12] <rayh> thanks
[22:22:18] <cradek> (my vote is to get rid of it, but I think he doesn't agree)
