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