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