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