#emc | Logs for 2005-05-22

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