#emc-devel | Logs for 2006-04-27

[11:59:16] <rayh> cradek, you up this early?
[12:13:17] <cradek> I wish not
[12:13:29] <cradek> I'm just here for a minute
[12:13:34] <cradek> what's up?
[12:16:02] <rayh> Talked with matt last night
[12:16:33] <rayh> He says that NIST expects that lathe to be working at your place for a year or so.
[12:18:34] <cradek> oh! I expected to send it back with someone at the end of workshop.
[12:19:11] <rayh> He even suggested that with a brief report of the testing, the time at your place could be extended.
[12:19:44] <rayh> We found the spindle drive on kb and the additional component is an opto-isolator.
[12:19:55] <rayh> the drive takes 0-7 volt
[12:20:04] <rayh> speed signal
[12:20:36] <cradek> have to go, I'll be back in a few hours
[12:20:42] <rayh> see you.
[12:20:47] <cradek> thanks to you and matt for working on this
[12:22:29] <rayh> np
[12:57:39] <rayh> logger_devel, bookmark
[12:57:39] <rayh> See
[15:10:18] <cradek> rayh: by that time maybe I'll have my own lathe converted. it's a long-term goal.
[15:15:49] <rayh> Right long term goals and long term loans are good things.
[15:16:32] <rayh> I've got a line on a high-speed microwave company that may be able to connect here in about a month.
[15:16:42] <rayh> * rayh is cautiously happy.
[15:16:52] <cradek> affordably?
[15:17:08] <rayh> about $450 year.
[15:17:25] <cradek> that's not bad at all if it works nicely
[15:17:31] <rayh> for business service
[15:17:47] <rayh> 375 for home or small business.
[15:17:52] <cradek> hmm, that's less than I pay, never multiply your monthly bills by 12
[15:18:05] <rayh> right.
[15:18:20] <rayh> I picked their annual payment.
[15:18:40] <cradek> I hope it works out for you
[15:18:45] <rayh> so do I
[15:19:42] <rayh> I fixed emccalib pretty much the way I want it for now.
[15:19:53] <cradek> do you have anyplace nearby where you can borrow broadband? If I had dialup and needed to download a CD or something, I'd take my laptop to the coffee shop and drink my $1 coffee while it downloaded
[15:20:09] <rayh> should I also commit that to v2
[15:20:43] <rayh> I've got a friend in town who can burn cd's for me. I give him $10 each.
[15:21:26] <rayh> There is a coffee shop that says wifi over in Iron River. 30 minute drive.
[15:21:33] <cradek> it's hard for me to say without knowing all the details, it's up to you, but I have been putting only bugfixes, and no new features, on there so it tends toward more stable instead of less
[15:21:53] <rayh> I consider this a bug fix.
[15:22:10] <cradek> then it's entirely appropriate
[15:22:18] <rayh> Okay.
[15:31:01] <alex_joni> hi guys
[15:37:46] <Lerneaen_Hydra> hello
[15:41:40] <rayh> hi guys.
[15:48:37] <alex_joni> what's up?
[15:59:50] <alex_joni> * alex_joni goes home
[15:59:53] <alex_joni> laters all
[16:43:32] <alex_joni> hello
[16:56:01] <rayh> Hi alex_joni you're home.
[16:56:08] <alex_joni> indeed
[16:57:12] <rayh> I wonder if we want to add the pickconfig lastconfig ability to v2?
[16:57:22] <rayh> I know it's a feature rather than a bug fix.
[16:57:35] <alex_joni> imo it doesn't affect stability or features of emc2
[16:57:52] <alex_joni> it's more like a user thing.. but I think we need to discuss it with jmk & chris too
[16:58:04] <rayh> Sure.
[16:58:14] <alex_joni> I'm good with either way
[16:59:04] <alex_joni> did you get a chance to look at documents/lyx/emc2/introduction.lyx ?
[16:59:23] <rayh> not yet. will now.
[16:59:55] <alex_joni> btw, I learned some more lyx today :D (adding the stg description to HAL_Introduction)
[17:00:32] <alex_joni> once you know a trick or two, it's really easy to use it
[17:00:33] <rayh> Great.
[17:01:11] <rayh> yes it is. i've not learned all the keystokes stuff for changing things but it is quite complete.
[17:01:27] <alex_joni> I'm still using menus :/
[17:01:30] <rayh> Maxine has written a book using it and a play for her students.
[17:02:02] <rayh> <alt>ps is one I use. switches to standard text mode.
[17:03:31] <rayh> I'm impressed with introduction.lyx
[17:03:45] <alex_joni> you don't have to be.. I only adapted most parts of it
[17:04:02] <alex_joni> most of it comes from emc1
[17:07:20] <rayh> You did a good thing.
[17:08:06] <alex_joni> glad you like it, I'm going to add installing (apt-get install part) and compiling for ubuntu next
[17:10:46] <rayh> only problem and it's just me, the term modern in connection with the AXIS interface suggests that the others are not.'
[17:11:07] <rayh> But then we've had this discussion before.
[17:11:25] <alex_joni> I agree.. I missed a word to say that it's somehow newer (for folks that used to use emc1)
[17:11:29] <alex_joni> maybe recent?
[17:11:42] <rayh> Small images from each would be a nice addition.
[17:11:54] <alex_joni> yeah.. I'll do that now..
[17:12:00] <alex_joni> maybe I can figure out how :D
[17:12:54] <rayh> "Axis, a hell of a nice plotter and machine control."
[17:13:02] <alex_joni> lol
[17:13:28] <alex_joni> AXIS, a GL based interface with a nice 3D-plotter
[17:16:18] <rayh> Fantastic.
[17:16:45] <rayh> I don't intend to put down on the work making axis, I would prefer that it not put down on others.
[17:16:59] <alex_joni> I can see that
[17:21:04] <rayh> Say, I like what jmk is doing to Hal_Introduction.
[17:21:24] <alex_joni> cool
[17:21:51] <alex_joni> btw, did you remove the sorting from pickconfig ?
[17:22:53] <rayh> No I saw that line. Didn't know if it worked.
[17:23:14] <rayh> did it get lost in the work that jmk and I did?
[17:23:20] <alex_joni> I think so..
[17:23:28] <alex_joni> it used to work :), now it doesn't anymore
[17:24:58] <rayh> set subdir_list [ lsort $subdir_list ]
[17:26:18] <rayh> Oh. There is more great new stuff in Hal_Intro
[17:30:10] <rayh> the line above orders the config dirs okay.
[17:31:49] <rayh> nope inifile_list sort got trashed.
[17:31:56] <rayh> I'll fix
[17:46:59] <alex_joni> ok
[17:49:47] <alex_joni> thanks
[17:51:07] <rayh> Thank you for finding my error.
[17:54:19] <alex_joni> not worth mentioning
[17:58:20] <cradek> does that need to be fixed on the branch too?
[17:59:11] <alex_joni> cradek: it can, but it's not 100% needed
[17:59:14] <jepler> cradek: did you do the velocity-after-abort fix on the branch?
[17:59:25] <cradek> yes
[17:59:28] <alex_joni> jepler: I think I saw commits to both places
[17:59:51] <alex_joni> cradek: it only sorts ini's in a config dir by name (nothing crucial)
[17:59:58] <cradek> ok
[18:01:06] <alex_joni> btw, did you see rays question from earlier?
[18:01:21] <alex_joni> should we add the ~/.emcrc stuff to v2_0 too?
[18:01:23] <rayh> cradek. if we fix that on the branch, it will add the .emcrc stuff as well, Ithink
[18:02:14] <cradek> ok, I think we shouldn't do that, it's new functionality, not a bugfix
[18:02:40] <rayh> Damn I'd like to include it so we've got it at fest.
[18:03:36] <rayh> I guess I'll just make my own cd with ray's tarball. That will work for the class.
[18:03:41] <cradek> I don't object if you can tell us it's well tested and reliable
[18:05:37] <rayh> uh. "seems to work here" good enough;)
[18:06:45] <cradek> I think we're close to release, just please be careful
[18:07:12] <rayh> sure.
[18:07:19] <alex_joni> it really seems to be working ok
[18:07:48] <rayh> I'm not going to even try to add halconfig here. I'll do that at class so i might as well do the other as well.
[18:08:06] <cradek> halconfig is already in the releases
[18:08:32] <rayh> Yea but it doesn't save anything.
[18:08:38] <cradek> it has been since 3/12 I think
[18:08:41] <cradek> oh
[18:09:00] <rayh> I've been working on that and netlisting recently.
[18:23:40] <rayh> I'm going to as the devel list for a bit of testing of pickconfig.tcl before we do anything else.
[18:24:33] <alex_joni> rayh: I tested some weirder scenarios (liek removing the ini after the emcrc has been written, then restore it), it seems to work great
[18:24:52] <cradek> I also wondered what happens if you remove the config that was last used
[18:25:12] <alex_joni> cradek: nothing happens, it starts up with a clean display (nothing selected)
[18:25:26] <cradek> great
[18:25:31] <alex_joni> so I stopped it, restored the ini, and ran again, and it showed up selected again
[18:25:58] <alex_joni> it's got my vote :P
[18:26:02] <cradek> ok
[18:26:06] <cradek> thanks for testing it
[18:26:24] <rayh> Yes. thanks.
[18:26:29] <alex_joni> if I would have known tcl better, I probably would have read only the code :))
[18:27:05] <rayh> I'm never able to predict the behavior of the stuff I write.
[18:29:02] <alex_joni> 99 bugs in the code, 99 bugs, you patch one out, commit the fix, 101 bugs in the code. 101 bugs in the code, 101 bugs, you patch one out, commit the fix .. 103 bugs in the code...
[18:30:10] <rayh> Sounds like beer drinking music.
[18:30:46] <alex_joni> lol
[18:31:29] <alex_joni> cradek: can I ask something of you?
[18:32:00] <cradek> of course
[18:32:03] <alex_joni> could you commit a screenshot of AXIS (maybe with 3D_Chips.ngc loaded) to documents/images ?
[18:32:28] <alex_joni> much to my own shame I must say I have no running version of AXIS on this ubuntu :)
[18:33:03] <jepler> you could swipe some screenshot from the axis website
[18:33:31] <rayh> It looks to me like jmk intends to leave both motmod and iocontrol out of Hal_Int...
[18:33:32] <cradek> yeah I was just looking there for a good one
[18:33:44] <alex_joni> there is no screenshots section on axis.unpy.net :((
[18:34:06] <rayh> My thoughts are that we should add serious documentation of these to the handbooks.
[18:34:21] <Lerneaen_Hydra> I have an an ubuntu machine that runs axis, I could start it up if you need some screenshots
[18:34:24] <rayh> probably integrator.
[18:34:42] <alex_joni> http://axis.unpy.net/files/translations/axis-en.png <- looks nice, I'll use this one
[18:35:00] <cradek> yes that's a nice one
[18:35:14] <cradek> I did those in all the languages a while ago
[18:35:18] <alex_joni> ok, I'll commit that one and one for keystick & tkemc
[18:35:22] <cradek> but we have more languages now I think
[18:35:29] <alex_joni> xemc & mini are already in there..
[18:35:55] <alex_joni> cradek: this is for the emc2 introduction part.. think that axis in more languages is overkill for that
[18:36:35] <cradek> sure
[18:37:25] <rayh> IMO a translator of these should produce visuals in that language.
[18:44:20] <cradek> I agree
[18:44:42] <cradek> in this case, it just means grabbing a different picture from the axis site
[18:45:11] <rayh> sure.
[18:45:32] <rayh> What did we call the hal module that returns stuff to emc like emcsh?
[18:47:05] <alex_joni> halui
[18:47:28] <rayh> thanks.
[18:47:31] <alex_joni> rayh: that one?
[18:59:00] <rayh> Will we have anything of this during fest?
[18:59:16] <alex_joni> it does work for some things already
[18:59:24] <alex_joni> * alex_joni looks what does
[19:00:06] <rayh> oh I was thinking of the project you started that made emcsh like pins available to hal.
[19:00:17] <alex_joni> yup, that's halui
[19:00:39] <rayh> So we could wire up a button and when pressed it sent a emc_cycle_start
[19:00:56] <rayh> or emc_mode manual
[19:01:18] <alex_joni> right now:
[19:01:22] <alex_joni> machine on/off works
[19:01:34] <alex_joni> machine is on gets reported (to turn on a lamp or smthg)
[19:01:42] <alex_joni> estop reset, activate
[19:01:44] <rayh> Oh. Okay.
[19:01:46] <alex_joni> estop_is reset
[19:01:57] <alex_joni> lube, mist & flood on/off & is_on
[19:02:36] <alex_joni> the basic framework is there, and most of the NML needed code
[19:02:56] <rayh> I start it with loadrt halui or ??
[19:03:02] <alex_joni> the rest should go pretty fast, but I got stuck because of lack of design ideas
[19:03:09] <alex_joni> no, it's userspace
[19:03:20] <alex_joni> and you usually need to run it from the ini, like emcsrv
[19:03:23] <rayh> so it starts like iocontrol
[19:03:31] <alex_joni> I think I put that part into the runscript
[19:03:35] <alex_joni> yeah like iocontrol
[19:04:14] <alex_joni> no, I didn't add it to the runscript..
[19:04:15] <rayh> why do these start diffferent from motmod?
[19:04:34] <alex_joni> they need things to find the .nml and .ini file
[19:04:40] <alex_joni> motmod doesn't
[19:04:58] <rayh> and motmod doesn't?
[19:05:09] <alex_joni> motmod doesn't use NML
[19:05:25] <alex_joni> motmod is a kernel module which talks SHM
[19:05:47] <rayh> but both sides of shmem
[19:05:56] <alex_joni> the other side is task
[19:06:23] <alex_joni> or milltask to be precise
[19:06:34] <alex_joni> and milltask starts up just like iocontrol & emcsrv
[19:06:53] <rayh> don't iocontrol and halui use shmem
[19:07:12] <alex_joni> not to talk to the motion controller, they use the HAL shmem
[19:07:21] <alex_joni> but that's a different dish
[19:07:47] <rayh> I'm not seeing a common architecture here
[19:08:12] <alex_joni> there are 2 compeltely different things
[19:08:15] <rayh> what happens if motmot gets loaded without milltask
[19:08:24] <alex_joni> nothing..
[19:08:31] <alex_joni> it won't do anything
[19:08:40] <rayh> it can load though
[19:08:52] <alex_joni> right, but it doesn't get any commands
[19:09:12] <alex_joni> you can load some parts of emc2 by themselves
[19:09:20] <alex_joni> but they only work when they are all there
[19:09:22] <rayh> so iocontrol and xxx are not at all like motmod
[19:09:39] <alex_joni> no, those are all user space apps, which only talk NML
[19:09:41] <alex_joni> like a GUI
[19:09:50] <rayh> they also talk HAL
[19:10:06] <alex_joni> that's irrelevant
[19:10:09] <alex_joni> at least to emc
[19:10:15] <rayh> not in my thinking
[19:10:18] <alex_joni> it's not irrelevant to us :)
[19:10:35] <alex_joni> emc doesn't know/care what iocontrol does with the commands it gets
[19:10:54] <alex_joni> imagine this:
[19:11:05] <rayh> I'm trying to find a way to explain iocontrol, and motmod to class.
[19:11:08] <alex_joni> you have an overview of emc's internals
[19:11:18] <alex_joni> like the one JMK did a while ago
[19:12:00] <rayh> I see a line called shmem
[19:12:13] <alex_joni> * alex_joni looks for a picture
[19:12:25] <rayh> i see it serviced on the HAL side by iocontrol and motmod
[19:12:38] <alex_joni> hang on.. I need a picture :)
[19:12:51] <rayh> i see it serviced on the emc side by iocontrol but not motmod.
[19:13:22] <alex_joni> http://wiki.linuxcnc.org/uploads/EMC_Control_LG.gif
[19:13:37] <alex_joni> that one's good enough
[19:14:23] <alex_joni> I guess you know the normal (emc1) data flow and organisation
[19:14:51] <alex_joni> gui <-NML-> task <- SHM -> motion controller
[19:15:01] <alex_joni> gui <-NML-> task <- NML -> io controller
[19:15:26] <alex_joni> ok so far?
[19:16:26] <rayh> sure
[19:16:48] <alex_joni> ok, now we (and I mean jmk) started to add HAL
[19:17:11] <alex_joni> first it was needed at the most interesting part (motion control <->hardware)
[19:17:22] <alex_joni> so that line turns:
[19:17:34] <alex_joni> gui <-NML-> task <- SHM -> motion controller <- HAL -> hardware
[19:18:24] <alex_joni> that was pretty flexible and nice, the HAL related to the motion controller updates and works at RT rates (very fast, almost not adding any delays)
[19:18:57] <alex_joni> then we said, that part works great, it would be best if we had the same functionality on the io controller, so we got:
[19:19:08] <alex_joni> gui <-NML-> task <- NML -> io controller <- HAL -> hardware
[19:19:50] <alex_joni> only this time the HAL is _not_ RT, it's user space, updates a couple dozen times per second
[19:20:29] <rayh> So that's why motion io is different from other.
[19:20:51] <alex_joni> yes, but the beauty of the HAL is that you can link those together. for example all go to 1 parport
[19:21:37] <rayh> I guess I don't see the need for a different path to IO
[19:21:39] <alex_joni> now to make it even more flexible, we started adding halui which lets integrators add hardware panels
[19:21:47] <alex_joni> so the above line turns into:
[19:21:49] <rayh> phone
[19:21:54] <rayh> keep going
[19:22:06] <alex_joni> hardware <- HAL -> halui <-NML-> task <- NML -> io controller <- HAL -> hardware
[19:22:40] <alex_joni> hardware <- HAL1 -> halui <-NML-> task <- NML -> io controller <- HAL2 -> hardware
[19:23:21] <alex_joni> HAL1 and HAL2 can be on different PC's, or on the same one.. doesn't matter. the NML is the one that carries the messages to where they are needed
[19:33:38] <rayh> Okay.
[19:35:00] <rayh> And that situation is not true of motion cause motion is a single NML message.
[19:45:38] <alex_joni> motion is not really NML
[19:45:56] <alex_joni> task & motion controller need to be on the same PC
[19:54:37] <rayh> as do all of the motion-IO things.
[19:54:44] <alex_joni> indeed
[19:54:54] <alex_joni> those are all part of motmod
[19:55:08] <rayh> But now cl is a pure HAL module.
[19:55:11] <alex_joni> btw, I just commited the change needed to run halui to the runscript
[19:55:24] <alex_joni> right, CL is pure HAl and runs ar RT rate
[19:55:31] <rayh> So if I had multiple pc's doing io
[19:55:43] <rayh> I'd have to have multiple cls
[19:55:51] <alex_joni> depends on what kind of IO you want
[19:56:00] <rayh> sure.
[19:56:10] <alex_joni> in some cases it's not even possible
[19:56:22] <alex_joni> for example having more than one PC running iocontrol
[19:56:24] <rayh> ?
[19:56:49] <alex_joni> you can have that, but task has no way how to route the NML messages to 2 places
[19:57:21] <rayh> Right. Task needs to be more central to the emc task handling.
[19:57:23] <cradek> while historically I can see that one might have wanted two machines to run emc, why would anyone want that with modern machines?
[19:57:36] <rayh> distance,
[19:57:38] <alex_joni> cradek: doze GUI & linux rest :)
[19:57:53] <alex_joni> also .. imagine a big factory full of machines
[19:57:58] <rayh> separation of function.
[19:58:01] <alex_joni> only one central admin point
[19:58:08] <rayh> yea task
[19:58:19] <alex_joni> GUI
[19:58:22] <alex_joni> :)
[19:58:38] <alex_joni> I was thinking something like:
[19:58:39] <rayh> GUI should not be central to anything.
[19:58:47] <alex_joni> 1 master PC with GUI & hardware UI
[19:59:01] <alex_joni> plenty emc machines with task & motion & io on them
[19:59:29] <rayh> the pc with gui and hardware ui is NOT master
[19:59:34] <rayh> Task must be master.
[20:00:00] <alex_joni> ok, I didn't mean that kind/type of master
[20:00:12] <rayh> okay. got you.
[20:00:27] <rayh> master as in this is the man place.
[20:01:12] <alex_joni> MOC as in Machine Operations Center :)
[20:01:15] <rayh> Good. At least I can begin to thing about relationships in IO and why they are different from motion.
[20:01:21] <rayh> HMI
[20:01:46] <alex_joni> they aren't THAT different
[20:01:56] <alex_joni> just that motion stuff runs at a higher rate
[20:02:02] <rayh> Sure. Thanks alex.
[20:02:26] <rayh> If iocontrol is started by the run script.
[20:02:38] <rayh> what do I have to change in run to start halui.
[20:03:10] <alex_joni> you don't.. I just did that
[20:03:29] <alex_joni> just add '[HAL]HALUI = halui' to the ini
[20:13:18] <alex_joni> rayh: let me know if it works.. it does work ok here (and I noticed I have done the part to switch modes too : Manual, MDI & Auto)
[20:17:50] <rayh> K
[20:19:06] <rayh> I'm confused, this is not how we start iocontrol.
[20:19:21] <rayh> why would we start halui from an ini line.
[20:19:57] <alex_joni> it's exactly the way we start all emc2 programs
[20:20:06] <alex_joni> you can specify the name of the program in the ini
[20:20:22] <alex_joni> DISPLAY = foo
[20:20:30] <alex_joni> TASK = milltask
[20:20:42] <alex_joni> EMCMOT = motmod (this one is a module)
[20:20:52] <alex_joni> EMCIO = io
[20:21:04] <alex_joni> EMCSERVER = emcsvr
[20:21:10] <alex_joni> HALUI = halui
[20:21:10] <alex_joni> ...
[20:21:32] <alex_joni> this adds the advantage that you can comment out the link with HALUI = halui, and it won't start anymore
[20:21:34] <rayh> and that line is in IO
[20:22:13] <rayh> [EMCIO] or is it in [HAL]?
[20:23:05] <alex_joni> [EMCIO]EMCIO = io
[20:23:18] <alex_joni> [EMCSERVER]EMCSERVER = emcsvr
[20:23:32] <rayh> hal ui is an io module is it not?
[20:23:38] <alex_joni> [EMCMOT]EMCMOT = motmod (this one is a module)
[20:23:43] <alex_joni> rayh: yes and no..
[20:23:55] <rayh> oh shit here we go again
[20:24:00] <alex_joni> it is an io module, but it's a user interface too, and it's a HAL component too
[20:24:17] <rayh> so how is that different from iocontrol
[20:24:31] <rayh> it is hal pins that trigger nml messages.
[20:24:33] <alex_joni> not that different
[20:24:34] <rayh> period
[20:24:55] <rayh> * rayh goes for a walk to calm down. bbl
[20:24:58] <alex_joni> yup.. that's the oposite of iocontrol (NML messages that trigger hal pins)
[20:25:00] <alex_joni> hang on..
[20:25:10] <alex_joni> I'm not saying it must be in [HAL]
[20:25:23] <alex_joni> if you like it better in [EMCIO] that's fine with me too
[20:25:41] <rayh> but now it is in HAL
[20:25:51] <alex_joni> right.. my first guess was HAL
[20:26:09] <alex_joni> I can easily change that.. only one word..
[20:27:29] <rayh> I didn't see anything when I put it in HAL
[20:28:02] <alex_joni> halcmd show comp
[20:28:22] <alex_joni> there is no screen or anything, only hal pins
[20:28:33] <rayh> I saw no pins
[20:28:49] <alex_joni> did you cvs up ?
[20:28:53] <rayh> I saw nothing under comp either.
[20:29:04] <alex_joni> oh, and you need to run src/config.status
[20:29:12] <alex_joni> to rebuild scripts/emc
[20:29:35] <rayh> okay
[20:30:49] <alex_joni> silly me.. forgot to tell you that
[20:31:24] <rayh> I still don't see anything I'll cvs up
[20:31:55] <alex_joni> ok.. make sure you have some lines with halui in your scripts/emc
[20:34:14] <alex_joni> rayh: maybe I should make a new config (halui & halvcp) ?
[20:34:24] <alex_joni> and try a simple UI with those 2
[20:34:55] <rayh> what is halvcp?
[20:35:09] <rayh> jmk's pin setter?
[20:35:42] <alex_joni> yeah
[20:35:47] <alex_joni> virtual HAL pins
[20:38:18] <rayh> Looks like with the new order of .x.x.x.x in naming that I'd better throw out halconfig.
[20:38:49] <rayh> It's just to far to get any information.
[20:38:57] <alex_joni> you mean halui?
[20:39:10] <rayh> no I mean halconfig.tcl
[20:39:38] <alex_joni> no, I mean when you say 'with the new order of .x.x.x.x in naming'
[20:39:57] <rayh> look at halui with halconfig.tcl
[20:40:05] <rayh> and you'll see what I mean.
[20:40:31] <alex_joni> ok, so you meant halui.. the namings are still up for debate :)
[20:41:04] <rayh> jmk has a proposed standard in HAL_Intro now.
[20:41:18] <rayh> I found halui. Thanks.
[20:41:27] <rayh> looks great.
[20:41:43] <rayh> I'll have to test it with real switches tomorrow.
[20:42:06] <alex_joni> I really tried to keep the names short, but understandable..
[20:42:14] <alex_joni> if it's not ok, I'm really open to suggestions
[20:44:43] <rayh> Sure I can understand them in groups but not alone. The tail of the full pin name has no meaning unless the previous name is also included.
[20:45:34] <alex_joni> * alex_joni didn't fully get that
[20:45:55] <rayh> for example in iocontrol coolant-flood is a complete name
[20:46:52] <rayh> in halui is-on has no meaning unless you know that flood is in front of it.
[20:47:08] <alex_joni> ayee.. I see what you mean
[20:47:15] <rayh> there will be a thousand is-on's
[20:47:24] <alex_joni> once again we're very consistent :)
[20:47:49] <rayh> But your way in halui is consistent with jmk's thinking on the subject.
[20:48:11] <alex_joni> otoh, I wrote the HAL part in iocontrol
[20:48:21] <alex_joni> so at one point I wasn't consistent :)
[20:48:49] <rayh> Well I think he is just getting to the point where that pattern is clearly articulated.
[20:55:31] <alex_joni> yay.. this works great
[20:55:44] <alex_joni> I added 2 buttons to a vcp, called machine on and machine off
[20:55:57] <alex_joni> and linked them to halui.machine.on and halui.machine.off
[20:56:23] <alex_joni> I can see tkemc toggling along while I press the buttons :)
[22:02:24] <rayh> that sounds great alex.
[22:29:13] <rayh> Great stuff. Using halui will take some practice thinking like tkemc or mini.
[22:29:45] <rayh> Only for real buttons.