Can I take it that we do not want to display configs/common as a possible configuration to copy?
rayh: yes, I suppose you could :)
okay. I'll have this in a few.
actually - I think you can safely leave out any dir that has no *.ini in it
The assumption is that it will be run from emc2 directory.
that's good enough for now - we can change it if necessary
What will the run command look like say for example for sim?
you mean how this script will be invoked if the ini isn't found?
No Right now I assume that this script will be invoked with tcl/bin/setupconfig.tcl
oh - so what does the user type to run the sim config?
What I was thinking was if I make a set of files say raymill
how will I invoke emc2 to run raymill.
or './emc raymill'
I'm not sure where the emc cscript will live - I'm just building now
hmmm - now why would you make things easy for the user by shortening the name emc.run to just "emc", but still put it in the scripts dir?
(not you, I mean "someone")
heh - mini is a bit scary at 3000x1000 pixels
I guess it would be. Suppose I shoulda given max values
not to exceed
just funny to see it stretcched across most of two 1920x1200 monitors ;)
not so mini anymore
Would be easy to use as a touch display.
hard to miss each button.
yep - full screen makes a lot of sense for a dedicated control
jmk didn't like the autosize much!
and making it full screen regardless of monitor upgrades is even better
I think I went 80%
I like it, but an aspect ratio limit might be in order
hmmm - no univstep or univpwm configs yet
by the way, univstep and univpwm will be the new names for ppmc, since the setup is different for the two boards
okay. I'da prefered the names used as stickers on the cards usc and upc
that may work - the dirs haven't been committed yet, AFAIK
though Jon does call them the universal stepper and universal PWM controllers (and refers to them on his websire as univpwm and univstep)
Yea no problem.
looks like the first draft of the copy script is in there.
I don't see that - running "emc" just got me sim
crude and doesn't actually copy the files but at least we can see it.\
Gotta eat brb
rayh is now known as rayh_away
duh - *your* script - duh
* SWPadnos_ slaps self
hmm - one thing I didn't fix, (because I don't know how) - names can't contain periods, or tcl barfs trying to add the radio button
dang! he is hiding
eating, I think
I started a similar tcl wizard
I like mine better ;-)
heh - of course ;)
so - I was looking at sim_rtapi, and came up with a couple of questions
it doesn't work (you know that already I assume)
yeah - that's why I was looking at it
I guess I don't see how it could work, considering that it's suppsed to be linked with kernel modules
it looked like there were some no-no functions in there
that lib is like hal_lib, gets compiled twice, once for kernel, once for user
are you sure the no-nos weren't wrapped in i#fdef ULAPI
isn't that what the two versions are for? (sim_rtapi and sim_ulapi)?
in theory, the sim could do everything except threads
oh, you're right
even those, on kernel 2.6 (kernel threads
sorry, its been a while
heh - no problem
and when I wrote that, kernel 2.6 was a gleam in Linus's eye
I guess all that stuff should still *run*, just not in RT (ie, there should be lists of tasks that run from time to time ...)
yeah, and fast tasks should run more often than slow ones
yep, though that can eaily be done the same way as RTAI - run slower tasks on multiples of the faster ones
yeah, I had thoughts of doing that
to pthreads work in kernel? (I don't think so)
I'll look around. I was just confused by calls to what (I think) are userspace funcs in kernel code
lemme take a look
don't worry about it, unless you have some free time ;)
too late, I'm curious now
well, it's only 10:00 ;)
which functs ;-)
well, wrapper calls an unchecked pointer - that's a bad plan
rtapi_task_start uses pthreads
same for stop (obviously)
ok, anything related to tasks was completely unknown and experimenta
yep, also the shmem function - I'm not sure if that's there without RTAI
pretty much everything else returns "unsupported"
with emc1, compiling sim made an entirely userspace set of apps, right?
I think so
that may be what I had in mind here too
OK - that's why they're using pthreads here
I on';t think you can, you're depending on the kernel linking modules together
but coding the modules themselves to compile as user or module would be nasty
also, is this supposed to be a simulator only, or just a non-realtime version of emc?
rtapi is rtapi, it cares not what it is used for
(just like HAL)
it was supposed to be able to run any rtapi app in simulation
I mean in the context of emc - should the sim mode be functional though non-RT, or just a simulator of the low level code?
there are two kinds of "sim"
there is a sim config that replaces hardware
but still requires a RTOS
then there is the "sim" that we are looking at right now, which doesn't need the RTOS
(but in theory could use hardware if you wanted)
actually, there are two kinds of sim for RTAPI:
1) stubs for lots of function calls, so that you can test your program
2) something that runs RTAPI, but not in realtime
1 is pretty useless
that's mostly what this file is now - I'm not sure how much of that is from the emc1 version
if you call a funct that allocs shmem and its a stub, your program isn't gonna be testable
true - only the thread and memory functions are implemented, for the most part
nothing in RTAPI is from emc1
ok - I noticed some comments like "fred returned success, I changed this to unsupported"
fred started it, what he did was a very thin wrapper over the rtos calls
I added all the checks and reference counts and such
(mostly to reduce the number of oopses and kernel panics that I was experiencing....)
always a good plan
it is pretty robust now... assuming you call rtapi_exit(), its hard to leave the system in an unstable state
but the sim never worked, and may well be unworkable period
(when I got it from fred, it was just a work in progress, none of the versions had ever been tested
sorry -was afk for a mo (heard a crash, figured I'd check on the wife and cat)
which one was it?
did sim work in emc1?
the wife - she dropped a windowshade or something
but that was a completley different build
remember the PLAT crap
yes - the PLAT crap
and ifdefs galore
please - I just ate
whats with the late meals today
Ray needs to get back here, dammit!
what's the big hurry?
I want to talk to him about the config wizard
Now, now, now....
(also, you should say " rayh_away needs to get back here", so he gets the beep
(IRC makes one impatient... instant gratification...)
yeah - like credit cards ;)
rayh_away, where are you?
I manage to do OK with those
apparently cradek has a text mode script as well
maybe if cradek and rayh_away were here, we could all talk about cradek's and rayh_away's programs
but cradek and rayh_away aren't here
so we'll just have to wonder where cradek and rayh_away are, I guess ;)
I think rayh_away uses ksirc, and if its like mine, it doesn't beep
(of course that might be because my box has no sound card... but it does have speaker)
actually, it has sound on the MB, but no speakers plugged into it
mine has a sound card and speaker, but no speakers connected to the sound card, so I get very few sounds
with drivers loaded
I have no idea if there are sound drivers loaded
I can play mp3's if I plug in the speakers, so I know things are workable here
and even dvds
seems I never to anything entertaining with my computer
programming is entertaining ;)
code and talk...
not in tcl it isn't
no - that's like a horror movie
actually, its quite powerfull, I made up a small GUI thing pretty quickly today
but it can easily get ugly
yep - it seems pretty easy to get the basics (like perl, python, etc), but the intricacies aren't so forthcoming
talk about intricacies... the text widget has about a thousand options
that's the issue with most GUI programming environments - learning the options seems harder than writing your own library
ha - solved that problem...
(picked the right option)
the default style for tk widgets is pretty ugly - motif went out of style about 5- years ago
I could care less about style
well - it's ugly anyway ;)
considering that the alternative is ncurses or worse
the text isn't even antialiased - how can I work with this?
I see that the univstep and univpwm configs aren't there yet
no, the configs are gonna need some work
in fact I was thinking about a post to the lists warning people that the configs are in a state of flux
may be a good idea
I can put the deafult ppmc stuff I have into a univstep directory (renamed, of course)
sure, its better than nothing
put a README in there too
you know: This configuration uses the Pico.....blah, blah
we should make a document with recommended names for various signal names and ini variables
(have you tried Rays config tool, it displays the README)
yes - I even fixed it
mine does too, I was originally using a file called description, but README makes more sense
the fix I did was so that it only gets directory names
(except that he has no line breaks in his README, so its butt ugly unless you use the tool to view it
the side effect is that any .ini in the configs/ dir won't be on the menu
mine has a better directory sort
there should be no inis in the config dir, so that is fine
mine looks for directories that contain at least one .ini file
I figured that was desirable, but put the comment in there anyway
so common is automatically skipped
that's the next thing, plus you need separate options for xxx_in and xxX_mm
that would be in the next step
first you select the dir, then the file in the dir
maybe Ray's tree work would be good here
rather than radio buttons
I'm going more for the install wizard approach, one screen after another, with next/back/quit buttons
ah - ok.
let me send you mine and take a look
on the way
right now it just has the first screen, the one you would see if you invoked emc with no config specified, and no default set
where does it go?
in configs (for now)
and run it from there
it needs a cd $EMC2_CONFIGS_DIR
but I actually started at work today, on my doze box
so the directory was faked
ok - I think you need to use $EMC_ORIG_CONFIG_DIR
hmm, that text box needs a scrollbar if the text is too ling
whatever, I didn't know the right variable
that's configs/, and the $EMC2_CONFIG_DIR is set after a config is chosen
is either of those set before you run emc.run?
(I'm testing this stand-alone)
from the run script, yes - otherwise no
I don't like that text box...
gah - I've got to look at how the auto-sizing is done in mini - these fixed size widgets drive me batty
it was designed to allow the user to edit text
(not just yours)
even tho I disabled the editing, it can still take the mouse focus, and then you can't see which item is selected in the upper box
yep - you can copy from the text widget, I think
in my original version I used a label widget
but I don't think that does word wrap, so I used a text widget like Ray did
but no scrollbars available for those, I'd bet
I have a scrollbar for the pick list
(it only shows if there are more than a certain number of choices)
I dunno if one could be hooked to a label or not
ok -I have more dirs, but apparently only 4 with inis in them
you can change config_listbox_max from 8 to 3 to see the scrollbar
I'm sure I'll see it some day ;)
I must admit the widgets on my win2K box look nicer
see! motif does suck ;)
though it's not strictly motif
I never said it didn't
I just said it sucks less than ncurses
but I'm used to Borland C, so text mode dialogs are pretty normal for me
sounds like Turbo-C, circa 1992 or so ;-)
heh - Borland C++ 3 - the best one for editing large numbers of ASM files for embedded projects ;)
I used that alot in my former programming life, before I switched to Watcom, and then got disillusioned by Windows
let you run external compilers / assemblers, etc
I used to be very good with Brief as an editor
also pipe the output into the error window, so you could click on error and jump to the offending source lines
BC was pretty close to brief, and I think it even had a set of brief keybindings
we had brief where I worked at the time, and a copy somehow made it onto my box
B was great (though I never really used it much)
I've been fully windowsified tho, I use kate, and a lot of mixed mouse/keyboard editing
I use ctrl-C, -V, -X, etc, but very few other keyboard shortcuts
yeah - I've almost forgotten all the ctrl-K block stuff
not like the old days when you did everything with hands on the keyboard
I now expect blocks to be overwritten if I type, etc
no - and the thing is, I'm not sure it's really faster now - you have to move between mouse and keyboard too much
so anyway, what do you think of the tcl thing
also, you have to seee where the mouse pointer is
it's pretty cool.
agreed about the mouse thing - the folks who use keyboard only editors A LOT, enough to know all the shortcuts, could run circles around me
I'm not sure if I prefer the wizard approach or the single window approach yet
you should have seen Paul at Fest - he had like 8 mc editors open at a time, and text was flying
going on 11pm and I can't afford to stay up all night on a work day
nope. maybe email would work
I dunno if I should carry on with this or not
I copied him on the mail to you
I could call him ;-)
if you add another wizard pane, then people can decide which approach they like best
I think I'm gonna work on the RUN one tonight
I think that would be valuable, and you could get to bed early tonight ;)
theres only one more pane for that
"Would you like to set the selected config as your default?"
what's the next pane? (make this the default)
I'd also make it work from the tcl/bin dir, like Ray's, and use the right env var
on the NEW side, the next pane is "pick a name", then "which do you want to copy" (reuse the pick list), then "edit the description to fit your application" then "I'm gonna create a dir and copy stuff, OK?"
the env var doesn't exist until the run script runs
true - but the script shouldn't have to be in the configs dir
both scripts will have that problem though, so it'll need to be solved
I'm thinking that you might actually invoke this program all the time... if it can figure out from defaults or the cmd line what you want to run, it would never pop up a window, just invoke the run script
it's meant to be the opposite
if there's no default, it runs the config script
emc does, that is
oooohhh - he's back!
didja get my mail?
swp: I think you might run these things other times too, when you have no intention of running EMC
either to set a new default, or to generate a new config
they might even be able to spawn config editor(s)
Yes I did
same thing, slightly different look and approach
gotta pass it across and then I'll look.
I agree that it would be good to be able to run the config tool(s) from the comamnd line
so we'll need a way of making the dir known to those tools
you can eliminate onw pane in the "new" chain by changing the text to say "click "new" to create a new config based on the selected one" or similar
on second thought..... if they are a true newbie, I just want to let them click new, and then explain to them why they are picking a template
is a newbie that likely to make a new config immediately?
they'll need more help than that, I think
remember, we're gonna be doing all we can to keep them from editing the standard configs
so even if all they need to do is change scale, the first step should be a new config
in fact, if we somehow use these scripts to invoke editors, I'd like to somehow tag the standard configs and refuse to edit them
btw - you should be able to get the dirnames with [glob */] instead of [glob *] then checking whether it's a dir
(of course they could get around that on the cmd line, but it will keep the newbies honest)
there should be no ini in the common dir, I think
I have some ambivalence about calling these file copiers configuration devices.
there isn't one
so they'd never see common as a viable option
right, because its not - common isn't a runnable config, its just a library
the idea would be to run the qconfig or halgui or your config tool (or whatever)
rayh: if all they do is copy, I agree
but what if they spawn an editor on emc.ini, or your tool on the hal files, or.....
incidentally, I thought of another interesting addition to halcmd
(may you live in interesting times ;) )
yep - are you familiar with the pascal use of "with" or "using"?
once upon a time, 25 years ago
so that would be.... no
it basically allows you to set a structure name, then only use member names within the block
so you say using foo, and you can say bar=1, and foo.bar will be 1
setp value 0.1
setp freq 100000
how about "prefix ppmc.0.pwm.00"
and even better, make it so you can pipe in an ini file, and have it only look in the specified section
(probably different functions)
where did ini files come from?
this came from the setp and = thing last night
I'm really not in favor of putting large amounts of hal stuff in ini files
my reason for wanting name=value was so you could have lines in the ini file that look just like regular ini vars
halcmd defines a language
if you add the prefix / inisection options, you can set a bunch of stuff in a module, with the module name as the section, and the vars alone on a line
it doesn't look anything like ini format, for one thing ini is order independent, and hal is a scripting language
there are two semantic parts to the language - creation of objects, and setting their values
setting of values isn't order-dependent
both of which are procedural
setp isn't exactly procedural, I think
tell that to the MOSFETs after you set the enable TRUE before setting a safe PWM frequency
So where do we go from here with this config business
there may be blocks of setp that you want to execute before doing other things (like starting the servo thread)
I was caught by surprise by your commit, obviously we are working on the same thing
swp: IMO, we've stretched the halcmd language about as far as I want to stretch it
enable would be a pin anyway
I have no objection to you making a similar program, or a completely differnt mode for halcmd that interprets a completley differnt source format, but I really don't want add ini format to what we have now
after all, 90% of the lines in an ini file would be ignored by halcmd
ok - I was just thinking of ways to make config easier - putting a line in the ini (STEPGEN_NMAX_OUTPUT) and in a .hal (setp stepgen.00.max_output [AXIS_0]STEPGEN_MAX_OUTPUT) seems redundant
IMO we can rather easily manipulate all of configuration from something like tickle
but it is probably a matter of opinion
sure - we can drop it for now
as you casy - I can always add a new halcmd-like tool that does what I want ;)
lets talk about these config tools for now
without having to create a lot of config handling stuff in hard code.
define "hard code"?
to me, tcl is hard code
something that has to be compiled
Not at all.
I think that distinction is not so important
notice the lower case cause we are getting into tricky waters.
"hard code" is code that isn't trivial to modify
and of course "trivial to modify" is subjective, for you tcl is
trivial for rayh to modify
trivial for anybody to modify
anyone who knows at least *some* programming ;)
as an example, I added the tuning parameters to an ini for ppmc recently
granted I'm a total tcl newbie, but I found many. many stumbling points when I was working on that script this afternoon
They work well from there.
Oh yea. There are a thousand gotchas
ray: how many people could have done that (the ppmc params thing)?
things as simple as [set $whatevervarname]
I guess I was thinking back to emc days when those were ini variables.
and asking myself why would I want to change that.
I see the level of difficulty/"hard codedness" as going: ini file, hal file, tcl file, c/c++ files
That is probably about right.
hopefully, average users edit ini only
advanced integrators edit hal
and nobody edits tcl or C
oops, forgot classicladder files
I wrote a front end to let me tune ppmc direct to halcmd
they're probably between ini and hal
btw, I want to modify core_servo.hal to pull its P,I,D, etc from the ini again
problem with thinking that way is that cl files can't be edited by anything but the cl front end.
but they will be only in a servo ini, stepper inis don't need them
true, but if you have the tool, its probably more intuitive than editing hal files
Right and with the configs/xxx the way they are now, that should be no problem.
exactly - I'm quite pleased with the path alex has started us on
I was kinda wishing that we didn't have to edit each ini for it's location.
you mean paths in the ini?
if they invoke a "common" file they need edited NML_FILE = ../common/emc.nml
you don't have to - the only paths are ../common/
if they invoke a local file, they don't need it
HALFILE = mypinout.hal
okay that will help
but the other side of that coin is that "default" behavior shouldn't be relied on
so you should be explicit anyway, if you don't want things to get screwed up at a later date ;)
a file without a path will be pulled from the "user" config
if it gets screwed up, its because he screwed it
right - the default behavior is like 'ls' - current dir or specified dir
actually its the common ones that worry me, if we change a core_foo.hal, people might have working configs stop working
rather than bash, for example (check /etc/bashrc, then /etc/profile, then ~/.bashrc ...)
I'm very tempted to propose that we copy all files to a users config dir
I've already gotten screwed cause of core_stepper.hal
you made local mods and CVS stompped on them?
or we made mods and cvs up broke you
I made a config and then pulled it into a new checkout.
version change to core_stepper
I'm really in favor of having user configs completely isolated from CVS configs
Not a big thing but while we are making those kinds of changes we break most all existing stuff.
We could make the sample configs read only.
I would like to do that...
discourage, if not outright prohibit, editing of the samples
they are only to be used as templates
If we pull all the relevant files into a users config/dir then we will have to read the ini
No problem doing that but we would need to chase down the complete set.
if only relevent files are in the directory to start with...
duh, we still dont want duplicates of all the common ones in every sample dir
say for example that sim.ini makes reference to common/core_xxx.hal
we need to grab a copy of all of the files and stuff them in there.
and change the ini, so instead of pointing to ../common/core_foo.hal, it points to core_foo.hal (the users copy)
if the local directory search works as promised, we don't have to change the references in the original but they still might confuse some folk.
I'd suggest eliminating the ../common completely from the ini, but then the samples wouldn't be runnable
me for example
if there is an explicit path "../common" in the ini, it should obey the path
should be easy enough to read in an ini, search for common/ and remove it.
anything else would make people crazy (and not just you)
yeah, and at the same time make note of the file so you can copy it from common/
so it is _doable_, the question is, is it the right thing to do
on one side, changes to common/foo might mess people up
on the other side, changes to common/foo that fix bugs would have to be manually copied over by the user
Someone mentioned more than one ini in a configs/dir
yeah, like inch and mm versions
the hal files in that case would probably be identical, only the inis would vary
so instead of two config dirs, just have two inis
How do we handle those cases when we start with a command like "emc sherline"
like the dirs, we would have a mechanism to indicate a default
and like the dirs, the first time it would ask you which one you want
"emc sherline mm"
though two params might be easier
both of those would be hard for the run script to deal with, why not let the wizard do it
so we would need to sort on the first part for dirname
I don't favor wizard start.\
if you have two params, then look for param1_param2 in the param1 dir - not too hard
once the defaults are set, you'd never see the wizard
most of the machines out there are dedicated
but any sherline distro will have both mm and inch
and soon will have the same for mills and lathes.
ok - the mill / lathe thing would be an issue
that screen that I did... after you pick one and hit RUN, it will ask you "do you want to set this config as the default", then continue on and run emc
that's something that people would want to switch back and forth a lot
mill and lathe are two completely different configs
I suppose it is possible to strip out unnecessary dirs on these kinds of releases.
in two dirs
yes, it's the back and forth that's the problem
I suppose the integratopr could have a mill and a lathe config dir
could be simply configs/millmm configs/millinch
if you pass a dir name to the run script, it ignores the default
two mill dirs will in all likely hood have exactly the same hal files in them
(assuming it is the same mill, only a units change)
so if he burns out a parport pin and edits HAL to reroute, he'll have to do that edit twice
(and have to remember to do it twice)
The mill itself will be defined in one unit or the other.
I think the way we left it last time we talked was that if the cmd line had dir and file, it would use exactly that
It's the distro that needs em all.
if the cmd line has dir only, it will go to that dir and use the default file
if the cmd line has nuttin, it goes to the default dir, and uses the default file
you mean as in configs/m5i20/default.ini?
the exact mechanism for defaults isn't decided
I think that's what it is now
just assume there is some way to say "this one is the default"
(looking at the files in CVS right now)
configs/m5i20/m5i20.ini really annoys me.
I was thinking that emc.ini might be the default, and it would be a symlink to the desired one
alpha sorting for lowest named ini?
changing the default means changing the symlink (done by the wiz, not by the user typing unixy stuff)
so x1.ini would start before x2.ini
where would this emc.ini be?
in the individual config dire
ok - if you have two configs in a dir, then making a link called dirname.ini would be OK
so lathe would have an emc.ini, and mill would have an emc.ini
(or emc.ini or default.ini or whatever)
ok - that was my thought as well - no point changing the names of the ini
inside the dir you might have lathe_in.ini and lathe_mm.ini, and emc.ini (or lathe.ini, or default.ini) would be a symlink to one or the other
If we do have many emc.ini files plastered throughout the config stuff.
we will need a way to troubleshoot.
though they are slightly driver-specific - they specify which hal file to load, and that will have the driver in it
but only one per dir
What ini are you using? will not be a trivial question at all.
my recommentation for troubleshooting is to have the user tar up their individual config dir
configs/lathe for instance
I think that's why they have unique names
and what ini does the startup report to bash
the question won't be "what ini are you using", it will be "what config are you using"
because for troubleshooting, we might want to see their .hal and .ladder files too
I'm thinking of the guy who called the other day with a sherline question.
He was starting with the emc in k menu
and getting all the wrong answers.
doesn't the k menu emc invoke the right config?
seems his desktop icons went away.
or did he fsck with it?
well imo it was sloppy distro work.
hmmm - I guess we should have an icon somewhere
generic and emc were in k and millinch and millmm were on desktop.
in the tree
ok, it wasn't his fault, but the icon got changed
heh, I'd have the icon invoke emc, with no ini named at all
the first time run, the wiz would ask them to pick, after that the defaults are set, end of problem
anticipating all of the possible problems to address in a single config wizard is going to be difficult.
I know, it isn't an attempt to manipulate individual pieces of the config, as much as a way to manage the config directories
the trouble is that there's only one default, and someone might want as many as 4 active configs
it scares me that a machine operator has that much ability instantly at his command.
heh, ray wants less flexibility, swp wants more
lathe and mill, inch and metric (silly, but possible)
integrator no problem there is a real need there.
here is what I think the wiz might do (hear me out, then comment)
on - I'm just looking at the issue ray brought up - mill vs. lathe, without typing lathe or mill every time
allow you to delete any config directory (to get rid of unneeded/confusing ones)
you can certainly set up icons with command line params though
allow you to make a new config by copying any other (either one of the samples, or your own)
allow you to run any config
allow you to set any config as the default
allow you to tar up any config, to mail off for help
maybe, if possible, allow you to make an icon that fires off a particular config
and allow you to invoke editors on any config (except the standard)
so the user will get used to refering to "configs", rather than to the inidividual files
ok, I'm done now...
standard config = what? (and should it be deletable if it's not editable?)
asbestos pants on
standard config being the ones we ship
bad chili? ;)
ok - maybe those will need to be made RO
deleteable because once you have your taig working, the maxak sample is just confusing
there would be lots of "are you sure" before allowing that to be deleted
ok, but if you edit it, it either doesn't matter, or it'll go away if you get an update
the edits will go away
CVS won;t do anything with your edits
I'd like to see a set of release specific stock config files preserved someplace untouchable
the "customer" won't be likely to use cvs
if they conflict with changes in the new version, you get conflict tags and the file is fscked
ray - are you saying release specific as in "sherline's CD"?
or as in release 184.108.40.206?
Right or even emc2-1.05
actually, version numbering is something else we should discuss, but not tonight
yesterday we were leaning toward kernel style: emc-2.0.1 is the upcoming stable release
emc-2.1.x is unstable
If these standard files were there we could easily diff for changes
emc-1.something would be our last emc1 release
that's why I said 05
or even just putting versions into the ini / hal files (like the cvs $Revision: string)
swp: that doesn't help if the user edits it, he won't update the string
right - but you'll see what it was based on
not much help
more than no info, I'd imagine
if some guy is on IRC complaining about following errors, I need to know exactly what he is running, not just close
most users won't be doing much editing, other than axis scaling, I'd bet
It will be for revisions to hal modules that cause configs to become obsolete.
I do like the idea of tarballs for configs.
I used to call them personalities.
every release of emc2 will need to have all the standard configs tested to make sure they match the hal modules
any change to the hal pins exported by a hal module would be cause for a new release number, because they are no longer compatible
right but folk will pull forward a config
and have to edit it
in general, changes to hal pin names are a bad thing
we should get our naming convention right, and then stick with it
more like start from scratch if the wizard is the config tool
depends on the amount of hacking they did
if all they did was set scales, then yes, start from scratch, change the ini, done
if they hacked a lot in the hal files, then they will want to save their hacks
one thing: whatever the wiz does, it should be clearly documented, and reproducable from the command line
I'm imagining that each supported hardware would have a sample config
so a servo guy starts the gui
if we can make a recommended set of signal names, then a lot of that will be easier to do
selects his board(s) and gets those configs in configs/hisdir
SWP: that comes down to being smart about the sample configs
actually, it comes down to being smart about the interface the sample configs present
if they're all the same (within reason), then updates to the core* files don't break (much)
I could see the next page of the wizard asking for encoder counts per unit
ray: I wasn't going that far, but that is a logical extension
and then a tuning page.
If this was a non stock kind of install then the text editing pages would be necessary.
I see several independent but cooperating wizards
one manages the configs as a whole - select, copy, tarball, etc
another is used to configure a certain class of machines
At least a modular sort of front end to it.
a servo wiz, a stepper wiz
the qconfig idea would be handy there
from the users perspective it could be seamless
the config manager would call the appropriate machine specific wiz at the appropriate point
When we were working on the qconf idea
we had to build a master file
with all the "hints" and such?
yes - that could be done with halcmd instead
but the acceptable ranges for various params wouldn't be there
I've noticed that once the hal modules are loaded, halcmd can become that knowledge base.
yes - except for limitations on settings
or - limits on settings
many module params have limits, but A) those limits are module limits only, and may be insane for the application
could you illustrate a limit that is hal but not machine?
for instance, the PWM module can make 500KHZ pwm
if you ask for 1MHz PWM, the parameter value will be forced to 500KHZ
not much range there
but you probably want something between 10KHz and 20KHz
that was meant also for the ini file - like listing the allowed display programs
I didn't want to limit the module tho, because other applications might want more
or io or motion programs (if there are options)
actually, it was forthe ini file, come to think of it
not for hal
yeah, alot of things are "choose from this list" rather than "choose between these limits"
We already have a couple of models of ini configuration wizards.
yeah - another reason why I want to think in terms of the select/copy wizard invoking helpers to do the actual configuration, not trying to do it itself
now that we have individual directories for both the sample configs and for user configs, I want to take full advantage of that
that means thinking of a config as the contents of a directory, not just one or two files
So we need to add some auto navigation between wizards as we write them.
I don't like the way that damn small did wizard-wizard.
it's just a set of buttons allowing selection of any.
"you have selected the lathe config, and the lathe_mm ini file... now what do you want to do: RUN, edit ini, tune, edit hal, etc"
We need a path from start to finish
maybe think a bit like the KDE control panel
or not ;)
That kcontrol is not an entirely bad model
no, but it's not exactly start to finish
right, its random access
which is what you want once you get past the first setup
their config model is great as well, but the nice GUI tools are KDE-specific and large
cause you might want to go back and tweak something, and there's no way to know what you want to tweak
now when you first install KDE, and log in the first time, it walks you thru some basic setup
then tells you how to come back later and do it in a ramdom-access kind of way
I think thats the key, we need sequential walkthru for the first time, or for newbies
and random access later, or for experts
heh, need a "config.state" file (maybe hidden)
If we do this will we need a file that saves that first set of selections
thinking a lot alike
when you start, it looks at the state to see how far you got, and invokes the appropriate sequential wiZ
With that config thing I put in the dropbox earlier today,
I read config from the ini file.
once you get to the end, the state is "done", and you can run the machine, or invoke any wiz for tweaking
I'm not sure that's the greatest idea
or invoke the wiz again to write another
the config system shouldn't prevent an expert from running the machine immediately
swp: what part?
assuming that they did things manually, the config.state will be nothing
have an "expert" button that sets the state to "done"
the expert may choose to never run the wizard at all
then nothing is stopping him from running emc
cp core_stepper/* myconfig/*
sure, he can do that
IMO a startup should allow running from read only configs.
yes, the sample configs should be runnable
ok - I'm just thinking back to the idea the "emc" will get the wizard in some cases
emc myconfig won't, assuming that myconfig exists and has an ini file in it
the wiz is for cases where there is ambiguity
hmm, emc myconfig when myconfig doesn't exist can skip the first 2 pages and go right to "which config would you like to copy for your new config 'myconfig'"
How about a front page to this wiz that allows immediate run from 1 or 2 sample files or setup of a new.
there will always be a cancel button, in case it was a brain fart or typo
ray: thats pretty much what my tcl does
gives you a list of configs, 1 click to select, 1 click to run
only if you click new do you get into the copying and such
1 click to say "no, I don't want this to be the default"
But without intervention, only sim, emc, or step_cl will go.
univstep and univpwm should as well
you mean because of missing hardware?
missing hardware prevents any servo system from starting.
SWP: the uni ones won't work without hardware
sure -I'm assuming that things are hooked up
you can't tune or test without that
rayh: I expect that the README for each one would say "this needs X hardware"
"if you have a Universal Stepper Controller connected, this is your config"
Right. I kinda suggested that in the one readme I wrote for sim.
btw, I stole your idea - my version had a file called "description" in the dir, and it displayed that - I changed to README after I saw yours
I thought you were ahead of me.
great minds and all.
and the idea of displaying a description at all came from the qconfig stuff
great minds - yeh, that's it
well, getting late here (again)
Yes and I still like the idea of using simple html in that but that brings a whole other layer of complexity.
didn't add any more code to the tcl, but we have a lot of good ideas going around here
yep - I was just gonna say - it's late, and I'll probably need to clear snow this morning
I did that this evening :-/
it 's snowing now
Nice weather here.
ray - is there an html or RTF text widget (that we can get to work)?
rayh: one thing I don't like about your README - no line breaks, so very hard to read in an ordinary editor or catted to the screen
I've seen some stuff but not tried any.
I understand why you did it tho, so it could re-wrap if the window resizes
Could look a bit tomorrow.
I don't know if there are any good solutions to that
my old "description" file was preformatted, for a 60 char wide window
concat any lines that end in a single newline
but if you resize or whatever, it gets messy
Well inspite of the no line breaks, I did make a fixed size screen so could have.
double newline = new paragraph
SWP: I like that
dunno how hard to do in tcl, but I like it
sed or the like can probably do that (though I don't know how)
pretty limited in tk
s/\n\n/some_unlikely_char/; s/\n// s/some_unlikely_char/\n/
stuff like \n\n
gets messy in a hurry.
yeah - and sed is kind aline based sometimes
[05:47:56] <rayh_away> http://www.hwaci.com/sw/tkhtml/
does it work?
can we (you) make it work? :)
so the README would be in html?
I can try it in the morning.
as long as plain text is an option, it's OK
but I'm gonna look into whether tcl can to the \n \n\n thing
theres also the dependency thing
BDI-old has tcl, but not this package
its not the size, its getting it to the user
I realize its not an issue for Sherline or whatever, they'll have a shiny new CD
you'd have to replace all \n[^\n] with "", then "\n\n" with "\n"
Right we would need to make whatever additions we use available for all.
oops - first replace is ""\1 (or \0) I think
swp: I'd rather do it in tcl
C is my friend ;)
and a part of the package require if we build debs or rpms
it has good string handling (the entire README is just a string), just not so strong at individual chard
we'll have to be careful with dependencies
let me look a bit more. I think McClenahan and company have some html stuff.
in pure tk
if you need to include 300k of source, you might as well just depend on the package ;)
I'm gonna keep chugging away on my wiz, at least for a day or two, then maybe ray and I should sit down and decide what parts of each we want
seems dumb for us both to stay on it much longer than that
I am learning tck/tk tho, so it isn't entirely wasted effort
though you have two different approaches ATM, it may be good for others to see them, and help decide which one to pursue
I'd like both to be visible, but don't want to commit both, because then you have multiple files, some dead
* rayh_away would be pleased to take a back seat on this
yep - the dropbox and an email or conversation with some active folk would probably do
foster-johnson has a section on html.
rayh: I'll run with it a couple days and we'll see what happens
will read a while.
can I count on you for testing, tck critique, and feedback?
my tcl style leaves a LOT to be desired ;-)
but now its bedtime...
yeah - me, too - see ya later Ray
SWPadnos_ is now known as SWP_Away
SWP_Away is now known as SWPadnos_
How is emc2 doing with steppers since the latest modifications there?
I note that the stepper demo config won't load on my machine
* rayh tests
scripts/emc does bring up scope and mini
scripts/emc stepper complains that it can't find motion module "/Project/emc2-check/rtlib/.ko"
sim does the same.
but demo_step_cl works for me
I had the same problem when I tried to make a univstep directory.
I looked at the inis, but didn't see the problem
SWPadnos_: the problem is that there is no stepper/stepper.ini
there is a stepper_in.ini however
ok, so it doesn't et the stepper_in.ini that's there
so starting emc configs/stepper/stepper_in.ini works
no that's the wizard supposed to do
yep - OK
right now it's kinda inbetween
dumb version before, very smart version ahead
sleeping version now
before I forget, shutdow of demo_step_cl from tkemc does not shut down the classicladder display
odd - it did for me
did you use "emc" or "emc/run"?
I think i had to use scripts/emc
yep - scripts/emc (which should be ./emc, IMO)
yes. I just did that, and all the cl stuff went away as expected
not here at all.
odd, even if the RT parts are loaded, you should be able to kill the GUI stuff, right?
just hangs the cleanup waiting for modules to go away.
ah - OK. there's a module problem, not a cl problem
Shutting down and cleaning up EMC...
Could not kill task classicladder, PID=27997
ERROR: Can't remove RTAI modules, kill the following process(es) first
USER PID ACCESS COMMAND
/dev/rtai_shm root 27997 ....m classicladder
are the cl windows still there?
can you close them with the X button?
When I also kill the main cl window it goes on to shutdown complete
ok - weird
* chinamill is away: eating
interesting enough, it requires another start attempt to kill off those modules.
then you can restart.
well - now it's in the logs, someone more knoledgeable than me can see it (like alex or jmk) ;)
If you kill cl display first then it shuts down okay.
ok, so it can be killed by the script, but not when shutting down the first tiem
This is just about the way the system worked when I was starting cl by hand after starting emc2
we'll let alex work on it.
chinamill reminded me to eat.
oh yeah - good plan
hey Alex - can you take a look at the log, and see if you can tell what causes the problem Ray has?
hang on.. what problem?
classicladder prevents him from exiting emc using the demo_step_cl config
look at the log, about the last 50-100 lines
ok.. that's a simple one ;)
good. not so imple for me or Ray ;)
root 27997 ....m classicladder
does he need to cvs up or something?
it's owned by root
the run script is run by the user
probably I missed a sudo where the killing is done ;)
might it be safe to do slaughter as root?
got it - I'm logged in as root on my machine
BAD thing ;)
but I guess you know that
yeah - but it's only being used for emc development :)
ok.. figured it out completely ;)
the classicladder GUI gets started from the hal file
but the hal file also has a loadrt component in it
emc script scans hal files for loadrt commands, and if that's the case runs them as root
so as the insmod won't fail
but that means loadusr commands also get run by root
which means a kill won't work, unless sudo
[21:26] <SWPadnos_> does he need to cvs up or something?
now he does ;)
oops.. not yet
you're too slow ;)
got an up-to-date error
merging and testing ;)
ok.. now he does
hard at work I see.
hi rayh, can you test if it works as expected?
Getting it now.
hrmmm. that's strange
do you have time to explore this a bit more?
you are running as user, right?
I'm between here and a tree widget sample.
1. lets try the old way. 'sudo scripts/emc demo_step_cl'
that should work
if that works we'll move on
btw.. after cvs up, did you rerun configure? or config.status?
does it hurt to always 'sudo killtask'?
because that's the process of recreating the emc script file
SWPadnos_:doesn't hurt.. I think
I added sudo to the -9 part
sudo scripts/emc demo_step_cl works as promised
rayh: my bets that you cvs up'ed and didn't run the src/config.status
that way you still have the old emc script
the 'emc' script gets created by configure from emc.in
one more thing.. after running src/config.status it won't be runnable
so you need to chmod +x scriptsemc
so you need to chmod +x scripts/emc
assume got me again. no new code no need to make or configure
that is automatically done by make (if you compile the first time)
rayh: the problem is on my side, I should add docs to the wiki
README in the root and src dires as well
SWPadnos_: gotcha, doing that now
nope no different
so you did the chmod +x ?
nope no difference from the before chmod +x
It does behave just a bit different now.
When I close from the tkemc display
it waits until i close cl and then cleans up
it will hang for a while (the timeout to the kill)
rather than kicking up an error about not being able to remove modules
if you wait a few seconds it will get killed automatically
but the timeout is 10 secs
the thing is: on shutdown first a normal kill is tried, then if that fails it tries a sudo kill -9
and that one succeeds.. maybe sudo on the first would be ok too
I know I usually am.. *evil grin* :D
After about 20 seconds it does shut down the cl interface.
20 is a bit much.. :(
I'll add sudo to the first one too
Killall with great prejudice should be the next rmmod option
alex - is there a good reason for having the run script in the scripts dir (other than the fact that it's a script ;) )?
ok - then maybe it should be in the emc dir instead
anyone who does an ls in that dir would at least see an executable file
actually the new one can be anywhere.. it doesn't use relative dirs to find stuff
well.. it's not executable at first ;)
sure, but after it's created by the configure script, it should be
or make, or whatever
not really.. the configure script doesn't do chmod, but make does
rayh: care to test again?
after the phone :)
cvs up now
btw.. added some info to emc2/docs/news
woul dbe delighted if you (and everyone else) adds stuff in there
even retroactive stuff
down to about 3 seconds delay
that's probably caused by something else
there shouldn't be a difference from 'sudo scripts/emc' now
any other error messages in the console?
only thing I could still imagine is one of the other processes to run as user now, and not beeing able to access some files (like .var or .tbl)
I know tkemc handles .var files directly
anyways.. is running 'scripts/emc' slower than 'sudo scripts/emc' ?
on the shutdown I mean..
hang on a minute more
* alex_joni is in no hurry
test between sudo and user.
* alex_joni reads last nights discussion on the wizard ;)
no difference now between sudo and user startup and shutdown. Good job.
btw.. I noticed on my machine there's a lag on starting mini (opposed to tkemc)
runnign scripts/emc starts sim (and sim is configured to run mini right now, along with halscope)
I see that.
Yes. Mini is a linear startup rather than sourcing and then running as needed.
I see... well, not bugging me very much.. so I'm not paying much attention to it
I know that I should multi thread it and get the screen up faster.
just have not had the time.
ahh.. it's not that important
ok.. off to bed
Catch you later alex
rayh: didn't drop me the tcl stuff jmk did..
ouch sorry I forgot.
let me get there right now.
np.. will look tomorrow over it ;)
too tired right now, later is fine too