I see a load of cr**p heading our way
and someone needs to be in the firing line to decide what goes in and what doesn't.
paul_c: thought we had a board to decide stuff ;)
I think paul is aiming for someONE, since the having a board seems to diffuse the responsibility to the point where nobody actually acts
The board is only mandated with providing "direction".
So who's it going to be ?
I still don't think it should be one person... if anything we should be extending the boards "mandate" to include such responsibilities
but I still feel that reaching a concensus on the list is the best way to handle such things
jmk: I don't recall seeing a concensus on the list yet
when a topic starts, it gets heavily debated at first
and when a concensus isn't reached, what then ?
then the topic fades
and it gets forgotten
* jmkasunich admits that
so I think people around IRC should get to a concensus
one problem is that in some of these discussions the two (or more) options aren't clearly defined
jmk: IF you leave the list with 2-3 options to vote on, then I hope it'll be better
so.. first discuss it to some extent, to reach those 2-3 options
then present them to the list
right - and if the list still can't agree, then it's time for the board to step in and vote
I'd go with that
for example, in the latest situation, with the 10 or 15 or whatever changes that Keith has done
paul_c: why not?
simplest case would be each change is treated as a separate issue - some are no brainers, so lets vote yes and get on with it
discuss the other ones
humm... who/what is centriod anyway - Never heard of it over here.
a CNC control, like mazak or whatever
rewind a bit...
I don't know the industry too well, they could be an old player (maybe not even around anymore)
* alex_joni feels like he stepped into a longer conversation
not much longer, you missed about 10 lines'
right.. my logger died, so I can't look back :)
oops - he was pasting the discussion, but pasted to much ;-)
centroid control was designed by pen state and is being used and manufactured they are currently tring to design the control for gear hobbing cnc
(what paul said when he got bounced for flooding)
and who is roltek today?
so you owe me ;)
* alex_joni is burried in debt
how about some Guiness?
guinness != beer
don't get him started about irish beer
guinness ~= sump oil (well used)
ok.. let's get back to serious talks ;)
it started from 4). choices paul_c has.. right?
now that Alex is up to date..
and in debt to paul for that...
* alex_joni thinks we all are eager to know about #4
We are now up to who should have overall control of the emc2 tree
paul_c: is that needed/desired?
I think it is, yes.
what would such a project manager be able to do/prevent ?
primarily, coordinate development
ultimately, reject/revert crap when needed.
doesn't sound that bad..
I just don't think that should be in the hands of ONE person
jmk: what if that person would be under supervision of the board?
paul_c: how does it sound to you?
the way I see it, if A commits a change and B thinks it's stupid and reverts it, it comes down to A vs. B
but if B is backed by a concensus or vote of either the board or the community at large, then it is not a personal dispute
but we can have M
and A ask for major changes before submitting
and if M does not agree, then it gets discussed on the list
or even with the board
fine in principle
problem: paul proposed me for M... however if the changes are in the interp, I'm not competent to evaluate them
of course I am not talking about small commits
but you can be competent to delegate ;)
"Hey, I've got a major restructuring of key code"..... But it breaks everything else and will only work with one screwball RT patch.
paul_c: that doesn't need to be decided by a project manager
but by common sense ;)
where were you a year ago ?
I was.. around
yet.. unknowing ;)
had pretty much no ideea what was going on :)
ok.. now let's get back to PM
I think a project manager won't be bad
and maybe he could delegate people for certains areas of the code
ok, so how do we select such a person?
say: make paul_c responsable for libnml (and emc implementation of it)
jmk: that's easy
* alex_joni votes for jmkasunich
that makes 2/3 .. so we decided
oh paul OT but I wanted you all to see a 6 year old post from fred on rtlinux.com
About the trapaziodal planner ?
alex: not so fast...
I vote for jmkasunich
those whose commits are likely to be rejected might not agree with a M selected by a vote of 3
no voting for me! heh
you are talking about giving one person more authority than we gave the board
les: you havent tried emc2 have you?
it makes great parts.
jmk: not it's 3/4
stop being difficult
jmk: just kidding..
how about list-voting?
Ge I think John is DESTINED to be a manager.
this isn't linux, where everyone involved acknowledges linus as the leader and respects his decisions
well.. project manager is not like that
that is only a small part imho
actually, being a project manager is a good task.. you get to delegate everything.. to others..
you are talking about authority to reject patches
the big (and important) part is to focus development power
* anonimasu_ agrees
jmk: reverting patches
you can do that right now ;)
so can any developer... but we don't, unless there is a concensus, because that way lies chaos
well the g92 and other things for example kinda changes the whole rs274 spec doesn't it?
but... say I have an ideea
like I decide today to strip NML out of emc2
I have to leave in about 35 mins... this is important stuff, lets try to get thru it
and replace it with my kick-ass-message layer
* paul_c has already stated he will unilaterally revert any screwball commits in the bdi-4 branch
who should I ask about this?
post a message to emc-dev list
if I'll write to the list.. then I'll start a flame war
about NML over other protocols
* paul_c revokes alex_joni's cvs access
won't help a bit
see... that's what I meant :P
the way it should happen...
alex_joni: I know where you are coming from...
if your idea sounds stupid, you'll get flamed and go away
if your idea seems to have merit, in spite of being radical, you'll be told to try it on a branch
But there will be a vocal lunatic fringe that will support any screwball idea.
if you come back a month later and say, "check out branch foo, I have my kick ass messaging working and it's better than NML", who knows... maybe we'll adopt it
hmm, didn't really make my point..
and the sheepish majority will remain silent.
hm, so a month of a developer working on somthing that might not be of any use.. :D
his own choice... but i guess that doesn't matter
sure I'd rather have him working on something more beneficial
that was the point.
that's where a PM is welcomed :)
I see it like this..
there are developers out there (on the dev list)
but the PM must be recognized as A) unbiased and B) competent before people will accept his decisions
who want to do some work
right.. and that gets recognized during the voting
* paul_c is biased
* jmkasunich is also biased
and probably fails the second requirement
that wasn't nice ;)
jmkasunich bounced in too quick...
I'll be back after dinner..
right - I understood what you meant
in some areas one of us is more competent than others, and vice-versa
which gets back to the delegation thing
note that I didn't say the PM had to be A and B, I said he had to be recognized as A and B
that's why linux has no problems when he tells somebody "no, your patch isn't going into the kernel"
and why almost any of us would have problems, depending on the patch and the patcher
why is that?
because linus started linux.. right?
jmkasunich: if you get a reply from him at all.
so why would I have any issues about you telling me the same thing about HAL ?
jmkasunich: sending it to andrew morton you've got a much better chance of a responce ;)
or paul_c about some BDI stuff?
nevyn: my point is that people accept it because of who he is - the recognized leader
alex: I have no problem with me managing HAL stuff and Paul managing BDI stuff, because we are the recognized leaders in those areas
jmkasunich: I understand the point.
but an overall leader is a different thing
jmk: seriously, how many such patches do you expect?
ones that are to be rejected without discussion?
we're having this discussion because of the Rumley changes to the interp
jmkasunich: so are you working mostly on the emc2 tree? or the emc1 tree?
nevyn: everybody should work on emc2 only
only the emc2 tree (except for a fix to some backlash code in emc1)
The emc1 tree is depreciated
at least besides bugfixes
paul_c: let's say it has reached production/stable and no further development will be invested there
les: what are you making turkey calls with? emc1, no?
I was john
bdi4 branch now works fine too
we are starting up again soon
And I have a big business delimna
ok, before we had emc1 and emc2(head), now we have emc2(bdi4) and emc2(head)
I just can't keep halving or quartering my productivity to accomodate a defective planner
I can't do it
I can use emc on a bridgeport or something
off_topic: how about adding some final tgz's for emc1 in the download area
then you have to either write a better planner or get a different control
but I may have to pull it from the router
damit Les... I was leading 'em round the garden path before dropping that in.
Pulling emc will cost me a lot
dammit again... we're digressing, and I have very little time before I have to leave
I don't want to do it
can we go back to the PM issue
right.. so overall I think a PM would be beneficial to emc2
if backed up by the board, and recognized by the developers
the immediate issue is the interp changes... I argue that while I'm willing to (and in fact already do) fill that role for HAL, I don't know enough about the interp to do it for these interp issues
ok..now let's see.. who knows enough about the interp?
lemme see.... there's a guy who lives on a big island
not that big
and don't you dare say greenland
nope - wrong sea
Rockall.... That's N. Atlantic.
only prob with that guy is he's not so much a fan of how do you say it "concensus seeking" ;-)
ok.. now let's scrap the talk about islands..
well.... If you are nominating me a PM, I warn you now...
I can be blunt, rude, bloody minded, and stubborn
tell me something I don't already know ;-)
but don't we all know that already
I'd nominate jmk for PM (if he delegates paul_c for interp business ;)
btw, I'm not nominating you... I don't think we need an overall PM
that'll keep people away from the interp :P
jmk: how about dividing emc2 into fields
and have a PM for every field?
It's not just the interp.... There are other issues arising from the codeFest
maybe one person could have more than one field assigned?
nevyn_ is now known as nevyn
I sort of did something like that when I set up trackers some months ago... there are catagories for bugs and feature requests, with the provision to automatically assign a person based on the catagory
I'm assigned to emc2 motion control, rtapi, and hal issues
but I didn't set up the other areas - didn't want to "volunteer" people
ok.. so you're the PM for emc2 motion, rtapi & HAL
what other areas are there?
* jmkasunich looks
I think of : libnml, io, task, interp
* anonimasu nods
build sys, interp, guis, libs, motion, task, hal, rtapi, docs
I wouldnt mind being involved in the GUI
that list can be modified to some extent
ok.. do we have a decision regarding this?
but still .. someone overviewing there PM's would be great
or is it the board?
the board imo
otherwise we need another election
I'm all in favor of "area" PM's, who would obviously need to discuss changes that impact more than one area
paul was promoting a single PM... what does he think?
too many "areas" and you end up back at square one.
we have 9 now (and docs doesn't really count)
One PM, yes. Two, maybe.
ok.. now let's see:
but any more than that, and you still have the same mess.
diffusion of responsibility?
jmk got motion, hal, rtapi
paul_c could get interp, libs, task
that would leave build sys & guis
alex gets build sys (your reward for all the work on autoconf) ;-)
heh.. I could do both
if I get voted ;)
I have to leave in about 5-10 mins
if rayh shows up, somebody send him a log of this session - I want to hear his opinion
my logger's up.. so it's there
ok.. so do we have a conclusion about this?
paul_c: gonna snort at me again?
well... It looks like one camp is happy with status quo
and another is calling for better management.
I agree we need better management... just not sure how to go about it
Impeach the founders!
and board members too!
shoulda sunk the ship mid Atlantic.
hm, hm, I wouldnt mind alex as manager over the GUI
anyone seen Les lately?
30 mins ago
before he went to hit balls into lakes or forests..
poor lil forest creatures!
anonimasu: marbles ;)
time for me to go
back in about 5 hours
jmkasunich is now known as jmk_away
so do we decide anything ?
paul_c : BBQ baby back ribs slow cooked in a smoker for 5 hours. (hows that for a decision?)
paul_c: I think we could limit it down to 2 people
two at most.
three will get no where.
so jmk should take over: hal, rtapi, motion, build_sys
and paul_c (or who else gets voted.. if voted is required): interp, libs, task, gui
how does that sound?
I've seen this mentioned a few times, so I gotta ask casue I guess I'm missing something here... In respect to screw ends; Why would I need/want angular contact bearings? I would think you would want the ends to be somewhat rigid if aligned properly that is.
Oh ffS.... don't try going to centriodcnc.com
Angulars are thrust bearings. the only significant force on a leadscrew is thrust.
Paul I must confess I am not crazy about this PM thing
for what it's worth
I see us getting nowhere without one.
les : So, I wouldn't want to have the screw rigidly mounted in respect to it's axis to reduce play?
Jymmm angular pairs will make it rigis axially, in bending, but not in rotation
one one side
the other side has to float axially
ridgid not rigis
paul_c: isn't it centroidcnc.com ?
les: make that rigoris
les : Ok, I'm now confused (sorry). I bought some radial bearings to use as screw ends. Am I going to have problems with these?
you will have play
radials have clearance
and they are very soft axially
let me get you some reading materials
les : I have enough to double up on the screw ends if that makes a difference.
[17:35:57] <les> http://pergatory.mit.edu/2.007/lectures/final/Topic_06_Screws_and_Gears.pdf
Jymmm: are you sure you want to go to the pergatory?
[17:38:51] <les> http://www.nookindustries.com/endmount/EndMachiningGlossary.cfm#EndFixity
* asdfqwega volunteers for position of benevolent tyrant
Now write a new trajectory planner...immediately.
I say.. go x+
that should be fairly easy
we will add y+ next week
the other directions are kinda similar to code ;)
only need to invert the direction :D
the TP talks to the interp, right?
and gets movement commands?
other way around
actually to taks
other way around?
Task places commands on to a queue....
I would think....
and the tp pulls them off the other end
that cannonicals send messages to task?
and converts the commands in to moves for each axis.
paul_c: how does it get converted?
all the axis start/end simultaneous?
From that old post from fred is seemed that he felt triangular motion plans were specifically what broke down and caused starvation
for G0 at least
add_line(x=2, y=3, z=-3500.275, f100)
TP looks at how much time is neede to complete the move
and says - X, velocity 0.1. Y, velocity, 0.15, Z, velocity MAX
(skipping the cubic & PID here...)
even if the resulting velocity isn't F100 ?
say Z needs to move 120 in order for the tool to move 100
and max_velocity is 110
at the TP level, moves are calculated on how far to move in one servo period
so TP runs as a servo thread?
so at F100, every 1milliSec, you will move 0.1
this is the old post from fred on what it does:
[17:52:16] <les> http://firstname.lastname@example.org/msg00924.html
asdfqwega hey you!
breaking the TP down a bit further....
The Trajectory loop breaks each move up in to servo loop slices
servo loop slices?
and the cubic sub-interpolator ensures those slice targets are met.
iow... Where do you need to be at T0, T1, T2, T3,T4....Tn+x
where T= the servo loop time period.
might be easier with skype.
yeah.. but I think it'll suck right now
as I'm on dial up, and downloading some updates
not much bandwidth left :(
an0n is now known as anonimasu_
is Paul here?
Just us chickens.
just wanterd to let ya know
it was the cd disk
alex_joni: ring when you're done.
les when you got a second, I wanted to ask you about router bits
burned a new one and updated everything
went very smoothly
was going to suggest either the CD or the drive.
wanted to put a burner in ne way
wth is "ne" ?
faster 4 me
paul_c : ne == No edjumakation
what do I need to drop in teh ~emc directory to use the sherline interface again?
the sherline ini from /usr/local/emc
weyland: I think you refer to mini
mini is in cvs
asdfqwega the deer thing yo made, what did you use to cut that out?
I've been using the sherline version or interface or whatever its called
I'd like to continue with it
Jymmm: A herring
Jymmm: Ancient Chinese secert
asdfqwega looks laser cut
weyland: edit your ini file, look for a line that says "DISPLAY = tkemc"
change it to "DISPLAY = mini"
asdfqwega : is it laser cut?
missed some interesting discussions today
rayh: read all about it http://184.108.40.206/irc/irc.freenode.net:6667/emc/2005-05-22#T17-07-39
rayh: and tell us your 2 cents
And as for making decisions on our own, Name someone currently developing who has not done something that didn't cause issues for someone else.
so you're not in favor of PM's?
Is that prime minister?
what rayh said
was that the cat?
Jymmm: cover your ears!
IMO. If we do "elect" a PM we have two choices.
Pay NIST $100k for 10% of Dr. Fred Proctor, Ph.D.
pay $30k for 80% of Matt Shaver.
IMO anyone else will be to controversial and will cause a split.
rh goes back to reading for a minute.
You could always pick a 'dark horse' candidate
"<jmkasunich> if rayh shows up, somebody send him a log of this session - I want to hear his opinion."
I very much favor an open approach.
The internet has proven that software evolution works. Tightly regulated, highly designed systems like the early vendors just failed
yeah, but software evolution can lead stuff to go in the wrong directions..
They were so tightly held that they could not interoperate at all.
and developers need to get directed in the right direction
rayh: everyone works on their personal part leads nowhere either..
I grant you that in the short run a guy with a big hammer and agenda might produce more features in less time.
The question is whether the product would be better.
rayh: the whole idea is to make the product better
and not better for a certain individual
<Jymmm> Impeach the founders!
17:12:33 <Jymmm> and board members too!
perhaps this is more insiteful (inciteful) than jy thinks.
rayh: a planned effort will yeild better results in the long run..
I subscribe in large measure to the "vision" if not the purpose of the founders.
rayh: and avoid things like the switch statement ;)
When I recommended a board, three years ago, pushed it hard two years ago, and wouldn't let others leave the meeting until they voted last year,
I was thinking more of handling contributions and funneling resources to issues, than I was of being a software PM.
rayh: not really sure if the board is that usefull in it's current task assignment
"a planned effort" will yield better short term results.
We didn't really assign a task to the board.
and long terms too
We excluded them from the only thing that I thought was critical.
But I was wishing at the time that they would take up the leadership role.
didn't quite see that :(
* anonimasu_ agrees
Failing that, we might just as well impeach the bastards.
brb phone -- your chance to get a word in edgewise.
what's impeach ?
* Jymmm was ebing a smartass (ray, you're gonna get me in trouble for starting a coo (sp))
alex_joni fire, terminate, kicked out of office, etc
now that's radical ;)
a bit too radical for my taste
now here's a thought
we just had the majority of the board around today
paul_c, jmk, and rayh
there's jon elson to complete the list
This board WILL: 1. develop an EMC mission statement
2. oversee the move towards GPL
3. persue GPL infringments, etc.
4. oversee relationships with business and industrial users.
5. maintain a prioritized list of features to be added
6. establish broad guidelines for testing and release of EMC
"This board WILL: 1. develop an EMC mission statement" I proposed one of these
in the fest stuff a year ago.
rayh "Taking over the world" is NOT a mission statement!
Jymmm: that was the brain, not rayh
Oh You've been reading the pysol front page, have you.
I was wondering about #5
SOB... I can't find a angular contact bearing with 1/2" or 13mm bore. Smallest seems to be 20mm - weird.
Jymmm: look for C and H Surplus online. They have 1/2" bore angular contact bearings for $5 ea
[18:59:36] <dan_falck> http://www.aaaim.com/u/web/aaaimc/cgi-local/shop991/shop.pl/SID=278026201/page=MOUS.htm#BR2504
look down the page for ND-12
sorry, should be "NICE #124"
dan_falck Thanks, but somethign about surplus/used bearings just doens't sit well with me =)
Well, I bought some radial bearings, maybe I could dbl them up
I have an EMC board of directors question: are there any minutes from meetings that we could read?
are there any meetings? :)
hm, I need to run, bbl..
alex_joni read topic
Jymmm: nothing about _board_ meetings there
Jymmm is now known as Red70sShow
Red70sShow is now known as Jymmm
this is the dev meeting, I agree
alex_joni They have a secret board room for that =)
alex_joni : It's has pony rides and everything!
* alex_joni wants to ride the pony
"pide a painted pony, let the spinning wheel spin"
rayh how was your pony ride?
I favor a close view of project management.
The dev guys who attended recent fest agreed in principal to one combining step.
I'd like to see us implement that step, however poorly, quickly.
rayh whats all tha kaos about (seriously) that ppl are talking about PM, etc?
just lack of direction at the moment?
IMO that was to move essential stuff into emc2, make it work with 2.6
Get the HAL going as the hardware layer
"inner race is same thickness as outer race"
Ok, so is maintaing two things worth it?
emc1 -vs- emc2
Could you describe the two?
* Jymmm are ig nor ant
Ah that is the essence of devFest's agreement.
The future is EMC2 with HAL as the low level and 2.6 as the prefered kernel.
The stipulations are in the wiki i believe.
It needs to run bridgeport and minimill equivalent logic
servo and stepper systems
and w/o HAL or 2.6 that can't be done?
rayh: 2.6 does work
jmk wants to merge it to head today
and permit access to visual displays of pins like IO_Show,
you have hal_meter
but.. I agree, if you're used to IO_show
NO NO NO
then IO_Show it is ;)
you seeme yelling.
I hear you ;)
Hal scope and hal meter are gret for the dev guys.
rayh YES! YES! YES! OH GAWD YES!
They are killers for me when I have to close my eyes, talk a guy on the other end of the phone
through the reasons why his $%#@! machine is screwing up.
But the good news is that we just need to substitute some variant of
halconf for the inb outb inl outl outw inw commands
in the three tcl scripts I use.
care to explain?
With iosh we create a NML connector to directly pull or read bytes, longs, and words.
I can use iosh to read a pin, and issue an nml message.
I can read an nml message and pull a pin.
As a bonus, I can use all of the computational and scripting power of tcl
and all of the display power of tk.
ok.. short question
reading / pulling the pins ...
iosh does that directly.. right?
inb, outb ?
and it should stay like that?
No. It only needs to direct HAL to read and write values.
Well if bridgeport like logic is directed to a parport or a 8255
I'd like to be able to read what pin values are there and be able to change outputs as needed to troubleshoot a system.
but you'd have to connect to hal pins
For example, a customer calls saying my big letters are red.
and those pins are already attached to the parport
Yestrday they were yellow.
and they have the value of the parport
My first question is where are the axes.
If they are not sitting on a limit, wipe the limits clean.
If the letters are still red, we need to look at the specific pins where those signals are located
That is where I use iosh and IO_Show.
rayh: I agree given the user didn't use a custom wiring
Yes. I agree but think of that as an integration issue rather than a service call.
but if he did, he'd be smart enough to figure things out by himself
ok.. back to aunt tillie ;)
I can ask the customer to start tcl/scripts/IO_Show.tcl
I just did
and up pops a diagnostic screen.
and I can see the lights blinking
rayh: My interface box will have LED logic readouts for the lines.. Whack all the limits one at a time and watch the leds flash to show that they are working.
Fido: you don't suit the Aunt Tillie profile
Good. I do the same thing in software.
sorry.. but that's it..
rayh: I have an emc2 running (on BDI4-20)
just now milling Chips (no real machine unfortunately)
alex_joni: Send Aunt Tillie over and we'll see how she likes me. :)
Yes and you did real good work on that.
and I ran IO_Show
and I can see parallel port 0x378
Ah that is the second way to get to that script.
and I see the Output pins toggle
from time to time (as I can't see that fast as they really toggle)
0x2BC on athinkpad =)
0x2BC on a thinkpad =)
Ys the toggle is a time based interference pattern.
ok.. so it seems to me it does work
but .. this is with direct port access
There are three locations available on IO_Show. 278, 378, 3bc
I sounds like iosh compiled.
Just curious... is there enough current to drive LED's on ALL I/O pins of a parallel port directly while operating drivers?
So DIO_Exercise should work as well.
depends on how you drive the LED's
and how you drive the drives
alex_joni I/O + resistor + LED
if you drive a transistor -> LED, then surely
Now we come to the heart of the problem.
Jymmm: if you wire the LED to Vcc and pull it down by the port, then probably
btw, chips came out nicely
iosh is very powerful
the exercise programs can easily screw up most anything.
If you want to test that, set the port address to 010 and set a value.
Or set a value someplace up in 0xb567
not very nice ...:)
ok.. go on
Jymmm: Use a 74LS04, 74LS06 or a 74LS32 and it solves the drive level problem.
I've lived with that ability for several years.
And screwed up my machines at home
ok.. so how should iosh behave in presence of HAL ?
But the ability to read the input from a switch or pull a specific solenoid or relay
overrides the risk as long as the user knows what she/he is doing.
With HAL, the risk is increased.
If we simply copy the function of outb, pulling a pin, hence a relay or whatever.
We don't immediately know if that is a real parport pin or a hal pin connected to some other hal module.
We need a bit bigger thing.
Or a bit smaller thing.
first of all .. you need to specify what hal pin you want to connect to
If you run one of the exercise programs.
Phydbleepy, yse a 7404. LS series are really finicky with their power levels.
Now, you will have two paths to the pin, HAL and INB.
and HAL will always win
because it updates the pins from the base_thread
A similar thing is true with emc as it is now.
You can aim an exercise program at a byte that is written by freqmod
rayh: I think it'll be simpler if you explain what you want to have
and add steps. or substract steps.
rayh: got that point
and I find it to work as expected
can't really expect to be able to set a pin of the parport
The littler of the IO_Show would simply show all of the pins on a parport.
if there's a program that writes to that port 5-10.000 times / second ;)
Phydbleep : If I could find the opposite of 74LS42 that might work very easily
That would be a first, very valuable tool
rayh: it does that now
The second is a tool that does allow for exercising of pins.
rayh: I just stopped tkemc
If you started IO_Show with a proper ini file, you can toggle the labels for the pins
and IO_Exercise stayed alive
so did iosh
and I was able to set / toggle parport pins
Right. Nice ability isn't it.
In emc you can toggle the lube or coolant output pin and see the effect on
the tkemc display.
or you can toggle the coolant on tkemc and see the effect on parport pins.
Now I'm with you and jmk here that this can all be done with HAL.
The configuration database that HAL creates or reads or whatever when it is initialized
what I can't see.. is where is the limitation?
should provide all of the info needed to create, recreate these same kinds of
* alex_joni still doesn't see what rayh is missing from IO_Show & co
One limitation has been that the pin definitions are not read from ini
like where to put axis_0.step ?
Jymmm: Opposite of a 7432? 7432 is a Schmidt triggre.. use a 7404 in series to invert the signal.
So IO_Show does not display the correct set of labels for the pins.
and axis_0.dir ?
That's it. And about all of it.
Phydbleep no, no.... 10 of 1 decoder instead of 1 of 10... 10 in, bcd out
that leads to the following:
should we put only the parport pins into the ini?
so that IO_Show can read it?
Except that I'd like it to read and write those things from HAL rather than around hal using inb and outb
well.. then you wouldn't care about where it's connected to
Jymmm: You need BCD to Decimal or Decimal to BCD?
say you read X-Limit
Halmeter and halscope can provide the user with a list of signals to monitor.
dec to bcd, then coudl use one of those BAR-GRAPH LEDs - like in VU meters
and HAL knows where that's connected to
Right. So showing a set of 8 signals should be rather easy.
yes.. but you have a lot more signals
I'd be happy to hack up the tickle if I knew how to ask for them.
who decides which to show?
rayh: that we can agree on
say I code an extra function to iosh
Well the extent of the expectation at devFest was that we woud match
the existing functionality.
well.. the functionality is there
Phydbleep Decimal TO bcd
at least imho ;)
now if we go to iosh beeing able to see HAL stuff, that's an improvement
But not the ability to read the pin labels from the ini.
Cause that ain't where the configuration comes from.
Jymmm: 7442 or 74145
Unless we have built in that requirement of devFest as well.
perhaps requirement is to strong a word.
no it's not
recommendation might better serve.
requirement is better
kicks people butts ;)
wakes them up
If you say so.
ok.. now let's go back to the iosh issue
iosh does NML
Yes it does.
* Phydbleep thought that the requirements for dev-fest were "Pizza and Beer and keep it coming." :)
how should iosh connect to HAL ?
limited to io type stuff
remember HAL is just a layer, not a software component by itself
In the distant future, it should read the modules that are running.
it's a bunch of software modules, drivers
rayh: so access HAL directly
like halmeter does
that's not hard
More like halconf or whatever that thing is.
but.. I know paul_c won't like it
that's the little thing.
well.. I think halmeter is more appropiate (not the GUI, but the internal)
halcmd might do that too ;)
paul would rather see us attack an 8255 board using a device definition.
re paul: ok... that would brake the ability to run iosh on a different machine
different from the machine HAL is on
I would assume that we would need iosh's running on each box.
Since NML is open to all boxes
one or two iosh's would not make a great deal of difference.
ok.. now to get you straight
1. add iosh with the ability to comunicate with HAL
2. iosh should be able to see hal components, and pins
3. iosh should be able to read pins
4. iosh should be able to write pins
Is there an easy way to built a variable voltage regulator? Looking to go from 0 or 5V, to 15V, but for 2amps.
A couple dollar chip will do it.
* paul_c returns from feeding the animals.
want a spec sheet?
as I do'nt know what series.
[20:12:26] <les> http://casemods.pointofnoreturn.org/vregtut/tutorial-full.html
this will do 1.5 amp
for more just use a pass transistor.
hmm. that's 1.5 amps?
I don't know.
have to ballast them
I'm ripping out a battery back, and using a transformer.
The lm 317 is good to about 35v or so
dropout is about 1.5v
It can float...so it can be used at high voltages to control as much as 35v less than input
317T more current?
I just stock the 1.5 amp ones
some are prob more
no, lm317 series, max is 1.5amps. :/
The LM317-T is the To-3 case..
1.2v to 37v.
[20:17:48] <A-L-P-H-A> http://ca.digikey.com/scripts/DkSearch/dksus.dll?Criteria?Ref=124484&Site=CA&Cat=31720593
someone else is recommending PWM
oh LM 338...up to 5 amp 40 volt
there you go.
oh... 338. :D
[20:20:22] <les> http://www.national.com/pf/LM/LM338.html
NM.. LM117 is obsoleted.
<shrug> only $11bucks /each.
check digi key
mil version prob
well your money isn't worth anything ;)
let me check.
LM338T-ND LM338T IC REGULATOR ADJ 5A TO-220 National Semiconductor Linear 5A Adjustable Current Limiting & Thermal Protection TO-220 Tube $2.58000
US$2.58 for the TO-220 case
yeah I am getting $2.11
les: You have an acct at DigiKey?
but of course.
That's the diff, I went in the front as a cash sale.
they make you an account everytime you order something.
oh! hey.. $2.58. :D
oh! hey.. $2.58CDN.
I spend a few thousand a year with them
A-L-P-H-A: Yep.. And then they send you a fscking catalog for EVERY acct. :)
I only get one copy.
I could build a house made of digi key catalog bricks
but I always forget my account #.
les, don't you recycle?
ROFL.. I went to the main US DigiKey site and it shows them for $1.98 ea.
keep it up...we are heading toward free here.
A-L-P-H-A: He is recycling.. He needs more catalogs to build the addition onto the shop. :)
matches and lighters are a nono then?
In japan the indigent make shacks out of PCs I read.
indigent = homeless?
well no... their homes are made of PCs.
A-L-P-H-A: Nope.. Pulp them and then mix with bentonite, silica and a few other things.. You end up with a fireproof, very light material. :)
Heck MDF is just thick paper.
* Phydbleep thought MDF was was military toilet paper..
Medium Density Fiberboard
Oh, wait.. The MDF is too fine grained.. Mil spec TP is more like OSB. :)
I had better start the cookout fire...filet mignon cooked on reject cherry turkey calls
les: Where's mine?
This is going to be good I hope
it better be for what those cost.
* Phydbleep slips 10 liters of LOx into les's bbq pit..
I wouldn't want him to get sick from undercooked steak. :)
wouldn't that like just turn into gas really quick?
Makes the bbq start in 2 seconds flat.. Melts the bbq flat in another 28. :)
[20:55:30] <les> http://ep.llnl.gov/msds/Chem120/lox-oxidation.html
"one charcoal briquette soaked in LOX is the explosive equivalent of onw stick of dynamite"
I'll stick to cherry wood.
and you got lox?
ha. I saw a fim of the Perdue BBQ. crazy!
I just used naptha.
les, got an accuracy question for you.
I'm going to start making my spindle housing.
and the housing is only going to be like 3 or 4" long.
I'm gonna drill out a hole, and then ream it clean.
but I'm going to have to bore out the bearing spots.
that's easily done for one side.
the issue it boring the other side. I have a test dial indicator.
A-L-P-H-A Why not use a heavy wall tube with a set of bearings at each end?
how accurately should I get that in?
I mean, how much wobble, should I get within for the other end, which Ihaven't bored the bearing seats yet for?
I can't type... my mind is mush
A-L-P-H-A: may I quote you on that in the future?
lets say I get the first side bored completely. The other wise, is what I'm talking about. it's already got a reamed hole.
basically housings need to be about +.0005" -0.0000 for yours size
A-L-P-H-A: Use the first bearing/hole to carry an inverted cutter?
you can grout em in with epoxy though
<A-L-P-H-A> my mind is mush
I guess I could epoxy them in
A-L-P-H-A: Basicly pretend it's a lathe and use the same sequence as for boring the headstock.
with mold release on at least one...
it must slide
les, there's gonna be bearing seats.
Normally suchthings are line bored.
Still works with seats
what's line bored?
Well that was a long call. Anyone about wanting to still talk about EMC direction.
Horizontal mill...shaft with cutter goes through...easier to make both housings and seats accurate to each other
you take a line, and bore holes in it
I'm like making this as such... taking a 1.75" dia alu 6061-t6 stock 3-4" long. Boring/reaming a 3/4" hole all the way through. Boring out a 1-1/8" seat. Flip part around, and bore out the other 1-1/8" seat.
Flipping the part around is a problem
rayh: some of us still around
les, that's why I'm going to use the test-dial indicator.
And speaking of bbq. I read that the guys testing the rocket motors for the private spacecraft
Yep, You'll lose concentricity when you flip it.
hung steaks and such on the blast wall for static tests.
A-L-P-H-A LOX + BBQ == http://www.doeblitz.net/ghg/morebbq/
Make mine "Sub-Orbital" ?
alex_joni: Is there a decent way to make iosh HAL aware?
rayh: yes, but I don't think it's a decent way to make tcl progs aware of HAL stuff
as in send a bunch of HAL lists to tcl progs
You think we have the bull by the tail?
A-L-P-H-A LOX BBQ videos --> http://www.doeblitz.net/ghg/
rayh: board ?
les what router bits do you use when making signs?
rayh: I see it like this, we can make iosh HAL aware
solid spiral carbide downcut or v cut
and tcl programs to use that
but the tcl programs should know what they want
not get it from iosh
A-L-P-H-A: Why not bore the 1-1/8" hole all the way through and then ream that to fit the bearings?
I guess I lost it paul.
* Phydbleep never had it..
Phydbleep? bearing seats?
You board guys need to talk.
It vanished before it got here. :)
bearings OD is 1-1/8"
A-L-P-H-A: Yeah, That would be the same effect as line-boring.
A-L-P-H-A: So go 1-3/32" and ream
bore the whole thing? and epoxy them into place?
I don't have a 1-1/8" ream.
A-L-P-H-A: No lathe?
boring bar != reamer.
A-L-P-H-A: I didn't say it was.
I have a lathe, yes
alex_joni: Are you thinking a hal library for use by tickle programs?
I think of calling iosh stuff with param of the hal pin you like
like : parport.0.pin-01
And the caller must know what HAL sigs and pins are available.
A-L-P-H-A: Bore 1-3/32, cut internal snap-ring grooves to retain bearings, beg/borrow/rent 1-1/8" reamer?
A-L-P-H-A: Or bore it, groove it and attack it with a brake hone.
So in order to use HALIO_Exercise. I'd have to know both the pin location and the hal name.
Phydbleep, so what's the difference of what I'm doing now?
rayh: something like that.. but beware:
A-L-P-H-A: No turn-over/re-chucking the part.
it's pretty late, and I might not be thinking straight ;)
rayh: get a word with jmk about this
A-L-P-H-A: Well, You'll have to rechuck it, but at that point you are ready to hone.
[21:22:34] <A-L-P-H-A> http://www.use-enco.com/CGI/INSRIT?PMAKA=331-1172&PMPXNO=948602&PARTPG=INLMK32
and let him mail me his thoughts (or maybe your conclusion on it)
A-L-P-H-A: That might work. <jk> :)
That was quick
alex_joni: is jmk_away around?
heh.. didn't have the Monitor switched on?
jmk is away
I've thought several times about just making a tickle front end to halcmd
Without asking permission.
rayh: you'd lose NML conectivity
Yes but with the judicious use of tickle's sockets I can get it back.
HAL & halcmd knows nothing about NML anyways.
paul_c: that's why iosh could be extended with HAL stuff
or.. the tcl frontend to halcmd connects to the actual iosh
the other method
rayh's idea was to be able (from tcl scripts) to check HAL pins and command NML stuff
and the other way around
An expanison of iosh to add hal stuff would permit us to write bridgeportio and minimill io
That would satisfy the fest requirement.
rayh: what does minimillio do?
Returns OK when an io command is issued.
and sets a pin for spindle, lube, mist, etc
also does estop
anyone got any webcoupons or something for use-enco.com?
well minimill doesn't .. but bridgeportio does
well.. afaik that should work with hal too
Bridgeportio passes nml to pins and makes nml from pins.
rayh: simio would fullfill the requirements of minimillio
I did that for emc2 and called it io
paul_c: besides simIoControl.c there's ioControl.c
with some HAL pins exported
rayh: I think it should be enough for driving a bridgeport
but then again.. what do I know ;)
fsckit... those two files share a bunch of common code.
it's kinda the same stuff.. only with hal stuff added
IMO we are moving toward everything having hal stuff added.
and then the old removed or obsoleted.
there was no old in this case
there was only sim-io
as in do nothing, only ack the NML message
rayh: it works like this:
task figures it needs to start lube, and sends a NML message lube_on
and io must ack it
simio only ack's it
io ack's it, and sets a hal pin
you can connect that hal pin to parport, or leave it unconnected (your choice)
same for other usefull pins (like coolant, spindle, etc)
alex_joni: Can I make a suggestion for io.foo.cc ?
your suggestions are always welcomed
* alex_joni won't always follow them though ;)
rather than taking simio.cc (or whatever..)
create a base class that handles the NML side
then use that to build a simio class or a minimill class, etc.
I really don't see the need for a minimill class, a bridgeport class
a simio class
How does that work with changing machine logic?
any IO interface will have to be compiled with g++, so might as well use C++ to do it.
the machine logic (if needed), should be done in CL
rayh: The base class just handles connecting to the NML layer
emc outputs start spindle
derive a minimill class from the base class, and it automatically knows about the NML
paul_c: I agree that such a class would be usefull..
it has little to do with IO control and more about reuse of common code.
what I don't see .. is why is a minimill class usefull?
what does it do?
<bluntly> bugger all.
minimillio just does an ack for most IO NML messages.
* Phydbleep wondered about that as well..
ok.. so we don't need it to drive a minimill.. right?
A base class does become usefull when you want to write a bridgeportio or an iosh
I agree on that...
but ..I don't want to write a bridgeportio class ;)
or any other derived class that needs to use th IO NML channels
or any other derived class
so just do the base class.
well.. would you feel better if it had a class defined in it?
instead of static functions like it does now?
IMO minimill is need to ack IO commands.
paul_c: as it is now (till somebody proves me wrong) I think it can be used to drive mostly any machine
That should be dummy-io
some machines might need a classicladder program
If an IO command is not received and acknowledged the task just sits and waits.
rayh: ioController gets NML commands, and ack's them
Un only i there is nothing to do between the message and the ack,
step back one moment from IO controllers
or the ok.
ok, but it's not really an iocontroller
* alex_joni is stepping back
* rayh is all eyes
All the parts of emc[1|2] that use NML need to connect to a channel and the buffer
the same chunk of code gets copied time and time again...
paul_c: I see your point there
Write a base class that does the NML buffer connests
and for that it's usefull to have a NMLConnector class
maybe does the ini stuff too
you're getting it.
as that's also pretty common
but.. we were talking about something else here
so instead of copying the same 200 lines of code....
I take the point, and will remember it
new NMLconnect("ini file", "yadda", "foo")
rayh: the thing started from minimillio and bridgeportio equivalents for emc2
minimillio is pretty basic
I can say it's already done
now for bridgeport:
IF you are using HAL for the bridgeportio section...
we don't need a minimillio
WE said we would use HAL at devFest.
exactly my point
I see it like this
have one io program
that exports all possible hal pins
and connect the ones you need
for special cases you might even want to connect them through some ladder
best thing.. that's something that already works
(that sucks in my opinion)
yeah, or NML->HAL->h/w
Yes. I can see paul complaint there.
that makes more sense
paul_c: for that you'll need to add a lot of messages
no you don't
you don't ?
what is upstream of NML ?
jmk_away is now known as jmkasunich
where are the NML messages coming from ?
and at that level, the consist of...
the ones that are IO relevant
the ladder logic converts those messages in to turn pin 976 on for 30Sec
If anything, I would suggest the number of messages could be reduced.
so.. how do you convince ladder to check for pin 12 and send a NML message to task
why would task want to know (or care) what state pin 12 is in ?
* Phydbleep thought that HAL polled the ports for that info.
for SET_PUMP_STATE(on|off), I'd like to see it set a HAL pin "pump_state"
which could then be connected to CL or directly to hw
paul_c: say pin 12 is estop
NML already has an estop status.
alex_joni: estop H/W > HAL
paul_c: yeah I know.. was just an example
I think CL needs some big changes to be able to send NML messages back
but I don't really know about that
As long as the status struct is intact...
* paul_c thinks CL would need very little change to work with NML
* alex_joni thinks it would need less to work with HAL ;)
A CL coil is simply a status changing message.
but where is the process logic in HAL ??
paul_c, alex_joni: It sounds like what is really needed is a set of standards on 'what does what and where for whom' :)
I thought bbs'es weren't used anymore
Phydbleep: NML is the standard for passing messages between modules.
there are a few areas where you could use classicladder
* Phydbleep hands rayh a towel.
io controlling (like lube, spindle, etc.)
tool changing (including motion of the machine, or external axes)
I don't dispute CL is well suited to IO control
CL does not do motion though.
paul_c: yet .. the vast majority of the machines won't need CL for IO control
I hope we agree on that
virtually no hobby grade machine needs the complexity of CL, agreed.
nor the hal-setup complexity, agreed too
Small industrial machines would need some form of IO control.
jmk: no offence ;)
I'd say that, if a machine needs to wait for a device it needs cl
small machines could use core_stepper unmodified
So if a sherline needs to wait for lube pressure, it needs cl
If it needs to wait for air to balance the z axis it needs cl.
This list could go on for several hours.
jmk: about that.. I think we should modify core_stepper a bit
The point is that if we build a single location for machine logic we should use that location.
add a spindle_on, and maybe estop too (for defaults)
alex: I'm open to that...
jmk: did you ever run io instead of simio ?
Un no to the core stepper and stuff like estop.
well .. it's basicly the
rayh: make emc2 have the same standard pinout like emc1
not estop, but spindle on is a must
Inhibit i'd buy in a hot minute.
But you see spindle on is a whole different place.
Now you write a line of code in cl that says if spindle is on then release inhibit.
and where's that inhibit connected to?
Yes it is a more round about route for the signal
It is a coil in classic ladder.
Inhibit is a HAL pin in the core_stepper module
there is no core_stepper module
core_stepper is a HAL setup file
So what is core_stepper?
core_stepper is a hal configuration
that configures the connections of HAL with hardware
Ah. And in there we are writing machine logic.
well the intent of "core_stepper" is that it provides a basic config
imagine all HAL stuff as wires
you can extend it or modify it as needed
And why would we want to do that -- other than that we can.
and you connect it where / how you want
and therein lies my biggest complaint about HAL
rayh: say you have xylotex drives
simiar to the way we provide sample ini files, and the user can modify as needed
It can violate every safety rule that a PLC has to live by.
it's easy to connect the pins inverted (2&3, 4&5, etc)
Easy is NOT right.
jmkasunich: this is not a work that can be treated like an ini
well.. I mean it's easier than having the user solder custom cables, etc
rayh: classicladder lets you do the same things
rayh: One thing you can do with a PLC.... Connect a digital input to an AC output
well that won't work in HAL
Ah but classic ladder does not let you violate the read all -- logic all -- write all.
ray: why can't machine config in hal or cl be treated like ini configs?
Which HAL will let you do any time you want.
rayh: how so?
Cause the ini file does not do machine logic.
It only does pin config and that badly.
well neither does hal-config
it only connects modules
ini sets accel limits, axis limits, all kind of stuff
as you would wire PLC's together
but core_stepper will.
* rayh needs four hands and two keyboards.
You just said a bit ago that you wanted to put spindle on in core_stepper as a precondition of motion.
rayh: use usb keyboard guts wired to a custom panel. :)
I didn't say anthing of preconditions
you can't do logic in hal (conditional logic)
you can only connect components
Darn i wish learnout and hauspe hadn't gone out of the voice recog business.
and I said we should connect the output spindle_on to parport-pin12 by default
Of course you can do conditional logic in hal.
because the same way it is done in emc1
of course those components can do logic if you wish (CL component)
rayh: no you can't
ray: how do you do logic in hal?
you can do conditional logic inside HAL components
alex_joni: Is that default in the .ini or will it require a re-compile?
not-limit is a condition of motion
Not sitting on a limit switch.
limit != 1
so what does HAL has to do with that?
there's a motion module
A HAL motion module needs an inhibit.
ok, but that logic is part of the motion module... hal only allows you to connect the limit input of the motion module to something else (could be a parport pin, could be CL)
which does export hal pins (like limit)
and those are connected to you hardware (parport)
but hal only takes the value of the parport pin, and delivers it to the motion module
and the motion (basicly more or less the same motion as in emc1) decides if it's safe to move or not
That is exactly where the HAL failure is.
I agree that you can unlink that limit (between parport and motion-module)
but that's like not connecting the wire to the limit switch
an USER error
I don't see where HAL is failing here...
ray: why do you see it as a failure?
In my opinion, no motion should occur unless the inhibit signal is released by a specific SINGLE process elsewhere.
are you using "process" in the unix sense? or something else?
That is a fundamental PLC concept.
a coil can only be pulled from one rung.
rayh: you only have one module / process / whatever that does motion
If motion-inhibit-release is a ladder coil
and a HAL signal connected to the motion module's "inhibit" or limit input can only be driven by one hal module
yup, you can't have 2 modules writing on the same pin
"you only have one module / process / whatever that does motion"
is exactly backwards.
I don't care how many processes do motion.
but you now have the situation where there is a HAL inhibit pin and an NML MACHINE_ON message (which does the same thing)
but motion inhibit must be a thing by itself.
rayh: what are you talking about?
PLC has the nice advantage of being able to aggregate all of the things that are preconditions of motion
we started about IO, and now we are diggin in motion?
That is because IO must have the ability to inhibit motion.
so you see classicladder connected to motion-inhibit.. right?
Imagine a machine that requires air, hydraulic, lube,
nothing more simple than that
OK... Let's scrap emc2 and port the interp over to matPLC and hang everything off their core PLC module(s)
if air up
if hhdraulic up\
rayh: got your point
if lube within time
if front door closed
that's actually an argument in favor of having CL connect only to HAL
then release motion inhibit.
Sounds like someone needs to make a set of standards on 'machine signals' as well. :)
Not at all.
machine (different signals) -> HAL (parport driver, custom boards) -> CL (logic for inhibit) -> hal -> motion module
Because NML MACHINE_ON can be a contact as easily
If you put that signal directly onto the hal, then the config file can
easily violate the logic
the way I see it, there are two functional blocks here.... NML to coil/contact/pin, whatever you call it, and
logic on coils/contacts/pins
well.. newsflash: classicladder would have a "config" file too (the actual ladder program)
if you load the wrong one.. surely you'll have the logic violated
ray: the config file damn well better be able to "violate" the logic - the config(s) define the logic
so it wouldn't matter if CL is linked through NML or HAL
But classic ladder forces a read of the state of all of it's contacts
they define the whole machine for that matter
then does all of the logic
and then does all of the write.
Hal does not.
rayh: classicladder reads only the contacts that are defined
in the program
then does the logic (from the program)
then writes (all the outputs from the program)
I didn't say at any point HAL should be used instead of CL
And that sequencing avoids a lot of race conditions and imposes a great deal of order
rayh: do you anticipate using CL to write/read directly from HW, or not?
That I do not see when you begin signaling pins together directly within HAL
NO. I see HAL pins providing signals to CL.
still don't see where your problem with hal is?
my assumption all along as been: HAL calls input drivers, they read hw and write to hal pins, then HAL calls CL, it reads the hal pins into its internal memory, runs the logic, writes results to HAL pins, then HAL calls output drivers which read HAL pins and write to HW
sounds like HAL pins & signals need another set of parameters specifying what they can or can not be linked to.
I can see how hal can do proper work with CL but right now I see that it can easily violate
Multiple reads, delayed reads, logical assumptions
rayh: you don't have HAL running out of the blue
you have threads
with functions assigned to them
I like your comment, jmkasunich
that get called in a specific order
Yes and threads could force a ladder like read, logic, write order on things
but they don't have to.
that's why it's configurable
* rayh has to let his fingers rest. Talk on guys.
I can adjust my emc.ini to trash emc completely
that doesn't mean emc is broken
rayh: I agree that given a certain HAL knowledge you can make things violate
but a rookie would probably only trash his emc2
and stop it from working
and as root, I can do "cat /dev/random > /dev/hda", but that isn't the fault of linux when the system goes tits up.
a "rookie" would be using core_stepper or core_servo and not messing around with threads and functions
the core config files would set up threads that read input, then run CL and motion, then write output
so I don't see Aunt Tillie hacking through servo_threads
a small snip out of core_stepper.hal
# first load the stepper module
loadrt stepgen cfg="0 0 0"
# hook its functions to realtime threads
addf stepgen.capture_position servo-thread 1
addf stepgen.update_freq servo-thread -1
addf stepgen.make_pulses base-thread -1
paul_c locking can be implemented
adeos has a usage counter that prevents it from being unloaded.
reference counts can be used to prevent modules from being removed while running
paul_c: I agree that removing a module should remove all it's function references too.. but that's another topic
yes, I admit that today you could rmmod motmod or stepgen, but that is a solvable problem and not related to the issue at hand
it would not be difficult to prevent adding/removing/reconnecting/disconnecting things while the realtime code is active
I don't think I agree with that not being a part of this issue.
paul_c: yet.. you need to be root to rmmod stuff
a side note... we talk about threads plural, but that should not give the impression that HAL has a whole bunch of threads running in parallel and not synchronized...
I think we are at the heart of putting HAL to real work.
emc2.run has to be run by root anyway....
a servo system would use 1 thread, a stepper system would use 2
it works ok with sudo on bdi-4.20
I see it a bit like saying we've got some stone, some water, some concrete
lets make the forms to build this thing.
The forms are what hold the concrete into place.
You guys have one great work with the hal modules.
* paul_c lays all the blame at jmkasunich's feet
rayh: you've hit it on the head... hal provides bricks and mortar... you want to build EMC with it, but I also want to be able to build completely unrelated things with it
Yep. That's it.
* alex_joni wants to build a bed right now
but not out of concrete
with the exception of "bricks" like motmod which are obviously EMC related, I want all the bricks to be as generic and un-restricted as possible
alex_joni has a base class to write firt
I thought it was getting a bit late over there.
[01:57] <alex_joni> kinda
just after dinner time here
I'm much to old to make it to 11.
filet mignon was GOOD
maybe it's telling that ray is thinking of concrete in forms and I'm thinking of bricks and mortar
well.. at least we are not thinking about wooden constructions
hal with no form of locking is more like legos
or those japanese paper houses
hal with locking is like bricks and mortar
take the bottom lego part, and the whole castle comes crumbling down :)
but it is easier to change around and reuse the bricks
alex_joni: That's what superglue is for. :)
We do need to minimize the ability for that to happen.
lego bricks that is... don't need to scrape dried mortar off them
* paul_c thinks a stack of bean tins in a supermarket is a better analogy...
rayh: that's not a major issue
But at the same time we need to keep the ability to flexibly design our systems.
locking is certainly something that can and should be added.
flexibility means that at some point you'll be able to build something that's wrong
How'd you do that!
such that once you do "halcmd start" it will refuse any addf, linksp, loadrt, etc commands until you do "halcmd stop"
well.. logicly it's a sane system
but you might have left out estop
so from the safety point of view .. it's wrong
or you might have forgotten to add a condition (to check for air) to classicladder before permitting motion
or who knows what
then you stop, change something, and restart
(in a locked system)
in an unlocked system you might be able to add it on the fly
well.. all ini changes to emc presume stop emc, change, run again
why should hal be an exception ?
Yes. And I can see times when I'd want that person on the other end of the phone to be able to unlock
and push a signal.
to test the source of an error.
But that person better be limited by the password.
actually ray, I was assuming that lock would not lock the setp and sets commands (used to set parameters of blocks, or to set signals )
I can see an integrator needing unlocked a lot.
so HAL also needs a uid before it can do anything...
locking should probably be done on a coupld levels
rayh: actually that concept is just a CL concept..
anonimasu: Yes it is.
hal locking would be implemented in the hal lib
it dosent work that way with real plcs.
darn he went away
that was anonimasu_
halcmd lock all or halcmd lock config or ....
heh, I was being nice and silent werent I?
I can see times when a integrator might get a sequence of stuff that works
and want to lock it.
* alex_joni goes to bed
well, I wouldnt want people poking around the ESTOP logic..
if I were selling machines..
use attrib to lock the file down.
jmk: I have no reasons against merging the 2.6 to HEAD
Or perhaps like sudo to unlock it.
estop has to be hard wired with industrial machines anyway
except maybe that comment from paul_c on dev list
les: there are other things that might be connected to estop..
I know...I use em
sudo gets set up so that a usr can only execute one or two commands...
alex: which comment?
I let emc power down the amps
about MODULE_PARM deprecated
To me the estop chain starts in the PC. If that ain't going nothin is.
we can do that post-merge
there is another pre-merge issue tho... rtapi_math
les: stuff like turning off amps/coolant/turning on brakes..
what about it?
rtapi_math.h - paul thinks it's an ugly hack (and to a degree it is)
Good discussion guys. Gotta run for a while.
les: what happens if somone gets stuck in the spindle, and the estop logic has been tampered with..
you will break the power to the spindle, but will the brake engage?
an0n: serious estop is not logic ;)
the big red button must work regardless of the state of the control computer.
use power-off brakes on the spindle
an0n: even if you PC power supply fails
system configs can be set up so that not even root can tamper with them...
* Phydbleep uses a 100W light bulb for a brake resistor. :)
I find with My ap that it is better to not brake the spindle
stop the motion first
phydbleep: nice, yet sometimes you need faster braking
let the spindle coast and perhaps still cut
les: if you got a hand in it it better stop..
there are two levels of securing configs - 1) don't let people fsck with the files (doable today with permissions) and 2) don't let them mess with it at runtime (needs locking added to hal_lib)
alex_joni: Not unless I want to play catch with a 10 kilo chuck. :)
jmk: so what about rtapi_math ?
paul has stated that he would rather we not merge it to head because it is ugly and likely to break with later versions of gcc
well.. my eyelids are slowly falling down.. so you do it how you like it best
so jmkasunich is doing a merge tonight less sans rtapi_math.h ?
can do a merge tonight with rtapi_math.h... doing it without means more work, maybe tonight maybe not
(if paul wants to remove rtapi_math.h and the references to it while I eat and commit to kbuild.....)
do a merge tonight, and I can start on a join tomorrow.
les: well, anyway, I wouldnt want the "customer" poking around there :)
les: remember that users are users
time for food
time for heather ale