Lerneaen_Hydra_ is now known as Lerneaen_Hydra
jmkasunich: lets move it in here
starting halui earlier solves the original problem (actually, I'd just start it with loadusr from the hal file)
so.. the problem with halui is that it connects to the NML buffers
those need to have been set up by task
so we need a sequence like this:
e.g. axis, tkemc
gui then (not ui)
doesn't iocontrol also connect to the NML buffers?
fwiw axis doesn't do anything with hal but run halcmd for now
cradek: wasn't talking hal..
but yeah.. ok
ok, so here's what I tried:
move emctask before the halui stuff
emphasis on "for now"
jepler: at that point in the runscript it shouldn't matter
HAL should be very useable
cradek: I see, you guys are doing a weird workaround
weird is in the eye of the beholder
alex_joni: it will matter for the same reasons. you want to use the pins axis will create in your .hal files
but, yeah, weird
jepler: that will be a pita
we're working towards circular references here
the normal hal approach is to load all modules (defines all pins) then connect, then run
ok, so probably we need to split the connect & run part
and move it after the GUI's have been started
way back in the runscript
* alex_joni nods
right now, the GUI is last, because it doesn't return
yes, if there was a way to request a hal script be run "late" it would solve most of these problems
but how late is "late enough"?
jmkasunich: none of them returns
when it does return, that means the user exited, and its time to shut down
jmkasunich: but task co are run with & at the end
that's another thing we should fix
so from the script's point of view, they do return, right away
I tried that for task and failed :(
we talked about that a little at fest
the problem is if we move emctask before halui or other guis, then we need a delay again
the idea of having a user space program export hal pins, then fork
one half returns, the other half becomes a daemon and runs in the background
jmkasunich: I realized you could do it the other way around. fork, hal init, and then write a status back to the parent (through a pipe or something)
I tried this for task (no HAL involved)
init, fork and let the child do it's thing
but it's not quite working as I remember it from way ago ;)
jepler: that solves the problems I was fighting with, but requires more programmer effort
win some lose some I guess
jmkasunich: yeah it's less clear if it's worth it
iocontrol, vcp, and halui are the candidate programs at least for now?
because of NML dependencies
it waits on the motion controller
but halui needs to run after it
jmkasunich: get what I mean?
we need to treat halui as another GUI
way back in the runscript
and maybe have it's own hal connection scripts
why it is that iocontrol can start early, but halui can't?
iocontrol exports it's own NML channels
don't both iocontrol and halui hook to the same NML buffers?
and task is the client to them
iocontrol holds some NML channels, task client
task holds some NML channels, GUI's clients
so NML is client/server, not peer/peer?
not really client server
but there's a master that owns the channel
P emc emcCommand LOCAL localhost RW 0 1.0 1 0
P emc emcStatus LOCAL localhost W 0 1.0 1 0
P emc emcError LOCAL localhost W 0 1.0 1 0
P emc toolCmd LOCAL localhost W 0 1.0 0 0
P emc toolSts LOCAL localhost R 0 1.0 0 0
these are the NML channels that task knows
the first 3 are his own (master = 1)
the last 2 (toolCmd & toolSts) are owned by iocontrol
how wierd would it be to have a program who's sole purpose is to create/own the NML buffers
that would run first
then _all_ the other programs would be clients
it wouldn't be weird
would it work?
I'm not sure how feasible it is though..
how about we run emcsrv by default?
and make emcsvr have them?
this would involve only changing the NML file ;)
* alex_joni tries to get away easily :P
you'll never get away
you are now the recoginized NML expert
* alex_joni tries this..
jmkasunich: it works like this ;)
seems I did know wth I was talking about
1.2MB memory usage, and 0% processor usage for emcsvr
so its just sitting there owing the buffers
there are a few problems with running emcsvr by default (1. people can comment it in the ini, and emc2 won't run anymore)
2. if emcsvr can't bind to whatever port is specified it will die, and emc2 won't startup
1) can be fixed - just run it in the emc script, don't mention it in the ini at all
#2 I'm afraid of ;)
it involves user decisions..
then again.. few of them will know how to change the nml
99% (or more) use the stock NML
the only time it gets changed is when somebody wants to use remote GUI (I think)
* alex_joni looks at emcsvr
it doesn't do much :D
it only has one line that does the server thing.. the rest is the same
the same as what?
as the component you mentioned
that does nothing but owning the NML channels
remove 'run_nml_servers()' and you'll have your component :D
so.. what's it gonna be?
does that mean you can remove the rest to have the server component?
I like both approaches
no.. you still need it
it needs to connect to the NML channels anyways
I only changed the NML so the component knows it connects (actually creates)
argh.. sorry, I'm bad at explaining tonight
I'm not sure I understand, but if you do thats good enough
ok, here's the decision
1. have emcsvr run by default (the first one), export the NML channels and start the server, then do almost nothing
2. duplicate the emcsvr (except the NML server part), and have a new component which does #1
downside of #2 is that we duplicate some code
what actual need does emcserver meet (today)?
it makes the buffers available to other computers?
if you have EMC2 on computer A, and a remote GUI on computer B, where do you need emcserver? A, or B, or both?
only on A
so what makes the buffers available on B?
the GUI on B will try to connect to the server on A
it knows to do that because of the NML file?
it knows the buffers are there
P xemc emcCommand REMOTE 192.168.0.4 W 0 10.0 0 10
that is a .nml for a remote box?
process xemc (GUI) tries to connect to the emcCommand channel, it knows it's remote at the 192.168.0.4 ip, at port.. (defined somewhere before in the same NML file)
right, this is for B
lets see if I understand this
you must create buffers on machine A
then apps on machine A can connect direct to them
apps on machine B cannot
they have to connect thru emcserver
emcsvr is like a proxy
as it is today, if you don't run emcserver, different apps create the buffers
io and task
we could have task make the channels, and not io, but that wouldn't help
but server can be configured to create them itself, and thus both local and remote apps can connect
seems like a natural solution to me
put all buffer creation in one place
there might be another solution.. but it would be less natural
we could have io create them all
* alex_joni doesn't trust io
I know who wrote parts of it..
ok.. so do we decide like this?
what are the implications of this change?
emcsvr by default (remove from the inis), export them channels, run first
and what actually needs to change?
changing: emc.in, emc.nml, *.ini
although the ini stuff shouldn't matter
right, change it for neatness and clarity
I can probably have it working in less than an hour
I think this is a good thing
anybody else have any thoughts?
ok.. starting to do it :)
(everybody got very quiet)
I'll remove some cruft from emcsvr too..
they left in agony when they saw NML talks
kerry_ is now known as rayh
since when do we have a sim_inch.ini in stepper ?
rayh: any reason against running emcsvr by default?
we ran into some circular dependency because of the NML buffers & HAL pins
I saw you were working on it.
so we thought we'd run emcsvr by default, as the first one, so it can create all teh NML channels
Right. Try it an see how many folk complain.
then we can run io & halui, and task only later
Sounds to me like a better idea than the approach I took.
ok.. will do ;)
jmkasunich: still around? want to talk about jogwheels?
heh.. for once I'm flooding #emc :D
don't worry about it
I don't :-)
* alex_joni prods jmkasunich
after more playing with the jogwheel I'm going to upgrade my opinion to a bugreport
cradek: yeah? care to share?
it's a little complicated but he can read back
it's about soft limit handling
that's handled in task
no the jog and jogwheel code checks limits
* alex_joni shuts up and listens further
say you have a neg limit of 0
so you turn the wheel to 0 and hit HOME
I have a neg limit of 0
* cradek kicks alex_joni
sorry.. can't resist :D
now I set the jogwheel scale to .001
when I turn it +, it jogs, the on-screen position lines up with the wheel
everything is nice
now I turn it backward past 0, of course the machine stops at 0
now I turn it forward again, but as soon as I turn it one click forward, it jogs up to .001
this means my wheel markings don't line up with the position anymore
oh, I see what you mean
the joggin past the soft limit gets disregarded
but not disregarded when you come back
I would rather it wait until I turn the wheel back to 0+ before it moves the machine
so ideally it should count how far you went over the soft limit, and wait till you jog back to the soft limit
yes I think so
I wasn't convinced this was really a bug until something else happened:
on Z my soft limits cause the jog to stop at 0.0005, not 0
so far I agree, it's not a bug ;)
so if I jog down past 0, and back up, the jog wheel jogs to .0015, .0025, .0035 etc
so unless your soft limits happen to fall on a jogwheel increment, it will mess it up if you ever touch a limit
I think that's a bug, not just a disagreement about how it should work
I'm not sure that's a bug either..
I think jog buttons do the same thing..
yes incremental jogs do that too
well.. like I said.. it can be regarded as a matter of how you like it ;)
if you want to jog incrementally, and you're closer than a jog increment to the soft limit.. either jog onto the soft limit, or not jog at all
I find jogging onto the softlimit somehow usefull..
you couldn't get there otherwise (unless you change the increment till you get one that fits)
and on the jogwheel: simply keep turning it further till it's a 0, then start turning the other way
currently you can't jog up to the soft limit anyway, it stops you short
I think what you said might be the fix
if the soft limit is within one jogwheel increment, don't jog that way
yeah, but probably for both
task & motion
same could be said for incremental jogs from the gui
that seems right and consistent: the commanded thing (jog one increment) can't be done, so no motion should happen
wonder what jmk will think
do you think it's right?
I tend to incline that way ;)
you mean you think you agree but are not entirely sure?
ok I'll tell jmk you agree with me :-)
I'm about 90% sure
argh.. something's fishy :(
halui doesn't want to connect to the NML buffers
not something I want to debug at 1am :((
I think it's ok if halui is broken until morning
lol, not sure how much time I'll have tomorrow
just finished dinner
was reading back re: jogwheels
cradek said: I would rather it wait until I turn the wheel back to 0+ before it moves the machine
I hope you've moved away from that thought
* alex_joni is completely puzzled..
jogwheel is strictly incremental
jmkasunich: yeah, but some are marked
any match between the numbers on the wheel and position is pure luck
if you want to make them line up, disable the wheel, turn till the wheel number matches the display, then re-enable
jmkasunich: a halcmd loadusr.. forks?
can I use -w?
are you saying I didn't actually implement -w?
you did ;)
loadusr -w sleep 5 ;)
I know it's ugly..
I wasn't sure if it's -w or how it's called
heh, I see that loadusr is not in the manpage
not in the manpage thats in stalled on my system anyway
* alex_joni sees weird stuff
can't I have more than one HALFILE?
you should be able to
nope.. seems someone changed that
more than one HALCMD though
thats in the run script, let me take a look
argh.. you should be able to have more than one
the run script does expect more than one, and checks them all
I don't understand this..
what did you call them
HALFILE1, HALFILE2, etc?
if I have more than one HALFILE=.. in the ini, then halui doesn't work anymore :-?
I was confused
where are you loading halui?
(and how? in the emc script, or using hal?)
I moved it in the emc script before the HALCMD stuff
and what happens? seems if its before the halcmd stuff then the halcmd stuff can't possibly have an affect on halui
I KNOW.. that's why I am puzzled
I gotta look at the ini
it seems the problem is with the second hal file
I didn't know halui had its own ini entry
I loaded halvcp.hal from the ini
If I load core_axis.hal it works
what config are you using?
and I suspect: 'loadusr halvcp halui.vcp' is the problem
you probably don't have that in there..
wonder if I should commit the stuff, for you to look at
if you want
I've found a good debug tool is to add "show" commands to the .hal file
like show comp before a loadusr and again after
jmkasunich: alex_joni helped me realize it's a problem with all incremental jogs, no matter whether they come from the jogwheel
incr jogs should be all-or-nothing: if the jog cannot be done because there's not enough travel, it should not cause motion
if you say so
you don't think so?
makes it kinda hard to get close to the limit
but you use incr jogs for a reason - to move a certain distance
you don't use them to run into things (the limits)
jog 1", get within 0.8 of the limit, switch to 0.1, jog 8 times, get within 0.07, switch to 0.01, jog 7 times, etc
so use continuous if you want to hit the limit
you have a point
I'll look into changing it in a bit
alex: are those last few commits the code you want me to look at?
no hurry, it's been that way for a long time!
try to run that config..
I'm totally puzzled here
oh.. I think I start to get it
although it shouldn't happen..
cradek: did you write wait-for-pin ?
I think that was jepler
halui takes quite a while to start up
dunno, I thought I saw one in one of the commit messages
nah, that's after the halvcp
which also takes quite a while ;)
when I try the halui/halvcp sample I get
emc/usr_intf/halui.cc 1850: can't connect to emc
HAL:5: ERROR: pin 'halui.estop.activate' not found
is that what you got?
right, because halui isn't started yet
the HAL error
the first message is from halui, the second is because it failed to start
if you comment out the second HALFILE from the ini, it will connect to emc?
that shouldn't happen!
going back to both files, something fishy is going on...
iocontrol: machine: 'EMC-HAL-SIM' version '1.3'
.....................NOTICE: VCP is still under construction
It may be broken at any time, and should not be used yet!
Got a good tree
connected to HAL
emc/usr_intf/halui.cc 1850: can't connect to emc
HAL:5: ERROR: pin 'halui.estop.activate' not found
I thought you were starting halui _before_ running the .hal files!
yes, I was
you probably didn't run config.status ;)
to rebuild the script
actually I think I did
I _never_ use config.status, I just run ./configure
I just didn't say that to save typing
I have two scripts, ./update and ./build
update does cvs up and configure enable-rip
build does make and sudo make setuid
I ran both before testing
just ran both again
I get halvcp messages, and get the actual vcp window, then the 10 second sleep, and _then_ the message from halui.cc about an error on line 1850
yeah, I know..
but it gets started before..
or am I completely bonkers now?
oh, it waits a long time before it prints that message?
it probably times out
try emc -v
I don't know anything at all about halui.cc
like, where is it in the source tree?
never mind, found it
I think I know what happens
halui can't connect to the buffers before task runs
like I said.. iocontrol is smarter
it assumes it owns the buffers and opens them up differently
I think ;)
the second hal took too long, so halui failed to open the buffers.. looking now how this can be fixed
somthing is fundamentally wrong if iocontrol and halui are using completely different methods to connect to NML
s/completely different methods to connect to// ;-)
heh.. ok ;)
what is %i in sscanf ?
jmkasunich: think I got it
jmkasunich: I know I got it ;)
on phone even
found the damn thing
what was it?
halui is peeking and expects to see something that task puts there?
you got it ;)
looking at the commit message for halui
you moved the halinit stuff earlier
is that before the nml stuff?
then if the nml stuff fails you gotta make sure to call hal exit
anything against that?
don't see any calls to hal_exit added
hmm.. seems I never called that.. shame on me ;)
not calling hal_exit() is the one big sin with HAL stuff ;-)
there isn't even one (hal_exit..)
or only hal_exit(comp_id) ?
free mem. or smthg?
thats it, as long as you call it everything gets cleaned up
everything you allocated for HAL has your comp_id attached to it, when you call hal_exit(comp_id), everything with your ID is freed
yay.. it works
darn.. the commit where I said I fixed the bug #.. got lost by CIA
don't you hate it when that happens
closed another bug :)
go to sleep
I should start working now ;)
got to make a presentation for next week
I'm flying to greece :D
think I'll give it a shot..
it's quiet now.. can concentrate
ayee.. this is bad :(
I ran out of coke
need caffeine from somewhere
and I don't drink coffee
I don't trust the colour :-P
although.. the colour of coke is not very healthy either..
but I'm addictive to it :P
jmkasunich: seen the attemps on a new TUX?
there are some png's there
if you don't want to download the .nc's
btw, that's dapper in those pics
doesn't look very different from breezy
which is a good thing
nothing majour changed
I like dapper..
especially the LTS part
Long Term Support
they want to go radical ways with edgy
so for a while dapper will be the preferred way
I don't believe in radical ways
newer is not always better
not sure how radical it will be.. we shall see