01:33:34 <jmkasunich> jmkasunich has joined #emc-devel
04:05:05 <SWP_Away> hey jmk.  How are you doing?
04:51:11 <jmkasunich> just fiddling around
04:51:21 <SWP_Away> heh
04:51:41 <SWP_Away> I finally finished milling my Y axis motor mount today (yay!)
04:51:56 <jmkasunich> cool
04:52:37 <SWP_Away> you have a Bridgeport, right?  (or is it a "mini-mill")
04:53:14 <jmkasunich> I have a 3-in-1, and a Van Norman mill
04:53:40 <SWP_Away> ah - ok.  Is the Van Norman a "bridgeport close"?
04:53:44 <SWP_Away> clone
04:54:13 <jmkasunich> no, Van Norman's are a thing unti themselves
04:54:18 <SWP_Away> heh
04:54:20 <jmkasunich> unto
04:54:45 <SWP_Away> I guess I could look at some JEKasunich's site about it :)
04:54:54 <jmkasunich> yes
04:55:02 <jmkasunich> was just gonna paste the URL
04:55:14 <SWP_Away> ah, OK.  It's a combination vertical/horizontal mill
04:55:19 <SWP_Away> sort of
04:57:59 <SWP_Away> interesting.  It's the "rosie the riveter" mill
04:58:08 <SWP_Away> if they ever let women use them
04:58:30 <jmkasunich> huh?
04:58:48 <SWP_Away> history - very popular for WWII military production
04:58:58 <jmkasunich> oh, yea
04:59:04 <jmkasunich> mine was made in 1941
04:59:22 <SWP_Away> December 7?  ;)
04:59:46 <jmkasunich> probably not, it is about in the middle of the 1941 range of serial numbers
04:59:59 <SWP_Away> heh
05:00:34 <jmkasunich> hmm, I suppose my mill could have been used to make my pistol... the pistol is from 1943
05:00:42 <SWP_Away> funny
05:02:05 <jmkasunich> I was at the range earlier, part of the "fiddling" was doing for the last hour or so was tearing down, cleaning, and putting back to gether the pistol
05:02:20 <jmkasunich> pretty impressive machining operations needed to make those things
05:02:24 <SWP_Away> ah, the sweet smell of gunpowder and oil
05:02:28 <SWP_Away> yes
05:02:36 <jmkasunich> hoppes #9 ;-)
05:02:57 <SWP_Away> that's the amazing thing about the AK-47.  It's made almost entirely out of stamped sheet metal
05:03:10 <SWP_Away> very low-tech, unlike the M-16
05:03:39 <jmkasunich> you know what's funny... as a kid I was never exposed to firearms - not until the last year or so... but there's something about the smell of hoppes #9 - I swear I smelled it many years ago
05:03:57 <SWP_Away> I would only know it if the Army uses it ;)
05:04:09 <SWP_Away> It was in a green can ;)
05:04:31 <SWP_Away> (just like my shampoo, deodorant, and a lot of other stuff)
05:04:37 <jmkasunich> heh
05:04:47 <jmkasunich> don't get them mixed up
05:04:54 <SWP_Away> no - people would notice
05:05:20 <jmkasunich> when you were in, was the sidearm still the 1911A1, or had they changed to the M9?
05:05:37 <SWP_Away> I think it wasthe 1911, but I never had one (officers only, ya know)
05:05:43 <SWP_Away> or high ranking NCOs
05:05:59 <jmkasunich> or folks who's job needed it (MPs, etc)
05:06:07 <SWP_Away> yep.
05:06:08 <SWP_Away> I've actually never fired a pistol
05:06:19 <SWP_Away> but I have fired a .50CAL machine gun
05:06:28 <jmkasunich> ma deuce
05:06:56 <SWP_Away> have you seen the video of the Oklahoma Full Auto club?
05:07:01 <jmkasunich> no
05:07:20 <SWP_Away> go to google video and search for that - it's interesting
05:07:42 <SWP_Away> a bunch of rednecks firing at things until they blow up
05:07:43 <jmkasunich> saw something similar from the Knob Creek machine gun shoot
05:07:46 <SWP_Away> (the things, not the people)
05:07:53 <SWP_Away> ah
05:08:17 <SWP_Away> this starts out with a guy setting up his 7-year old daughter wiuth a .machine gun O_O
05:08:25 <SWP_Away> (maybe 8 years old)
05:08:36 <jmkasunich> heh - gotta start em young
05:08:41 <SWP_Away> apparently
05:09:05 <jmkasunich> when we were visiting my in-laws in the boonies of eastern shore Maryland, I went to a range
05:09:21 <jmkasunich> guy had a H&K assault rifle - and two kids, probably 10 and 12 or so
05:09:38 <jmkasunich> he had the older one firing single shots and then a couple 3-rd bursts
05:10:10 <SWP_Away> interesting.  good to learn about safety at that age, if the weapons are going to be around the house
05:10:16 <jmkasunich> yes
05:13:17 <jmkasunich> bedtime...
05:13:22 <jmkasunich> talk to you tomorrow
05:13:25 <SWP_Away> see ya
09:39:12 <anonimasu> jmkasunich: seen the page "cnc gunsmithing"
09:39:12 <anonimasu> ?
14:58:11 <rayh> rayh has joined #emc-devel
14:58:24 <alex_joni> morning ray
14:58:32 <rayh> Hi Alex.
14:59:10 <rayh> any significant discussion yet.
14:59:59 <alex_joni> I had a great talk with petev last night
15:00:11 <alex_joni> let me give you a URL to read
15:00:17 <rayh> Good.  Thanks
15:01:09 <alex_joni> http://solaris.cs.utt.ro/emcstuff/petev-discussion
15:06:18 <rayh> Yep.  My only concern is that we allow for these configs to "drop into" a variety of HAL configs.
15:06:39 <alex_joni> it's not near solved yet
15:06:44 <alex_joni> so any discussion is open
15:07:12 <rayh> True.  At a beginning level I'd like to see a bridgeport.hal
15:07:23 <alex_joni> what do you think? should be have a new folder for bridgeport?
15:07:37 <rayh> That would take the standard signals for bridgeport and connect them to a second parport.
15:07:38 <alex_joni> or put that in common, and maybe get some of the configs to work with it
15:07:47 <rayh> common was my thinking.
15:07:48 <alex_joni> I see..
15:08:19 <rayh> It would have to start with a unloadrt of parport
15:08:55 <rayh> but halcmd does not have if/then
15:09:42 <alex_joni> maybe a bridgeport_stepper folder would be best
15:10:24 <rayh> Probably.  Because a integrator could build the bpt stuff using demo_step_cl
15:10:41 <rayh> or directly in hal
15:11:47 <alex_joni> right
15:11:58 <rayh> Could we build a common bridgeport_step.hal that would replace
15:12:04 <alex_joni> the idea is to have a bpt config that's emc1 equivalent
15:12:35 <rayh> Yes.
15:12:48 <alex_joni> we could have a bridgeport_standard_pinout.hal and bridgeport_xylotex_pinout.hal
15:13:40 <rayh> True.  the parport load is in stan or xyl rather than in core.
15:15:27 <rayh> Why don't I have a standard_pinout and xylotex_pinout in common?
15:17:46 <alex_joni> because they are not common
15:17:54 <alex_joni> they are only needed in the stepper setup
15:19:16 <rayh> The loadrt conflict is significant for any bridgeport definition however.
15:19:46 <rayh> and the bridgeport that petev was working with used stg pinouts rather than what was in the INI file.
15:19:58 <rayh> I don't think I said that very clearly.
15:20:34 <rayh> IMO the only bridgeport definitions that we need to concern ourselves with
15:21:13 <rayh> in order to fill the plan from last codeFest is a set of signals connected to a second parport.
15:21:36 <alex_joni> ok, so we only worry about stepper/ then
15:22:03 <alex_joni> I think it's less confusing if we have a new configs dir called bridgeport or bridgeport_stepper
15:22:14 <rayh> No.  Many STG users used the available parport for aux
15:22:48 <alex_joni> I see.. so that's not the second parport then, but the first one
15:23:03 <alex_joni> which makes it even more complicated
15:23:12 <rayh> Right.  to both.
15:23:53 <rayh> I believe this could be handled with multiple ini files in a bpt config
15:24:08 <alex_joni> and multiple hal files
15:24:17 <alex_joni> because you need parport.0. and parport.1
15:24:23 <rayh> The ini can even unload the first parport and load 2
15:24:39 <rayh> and still use standard_pinout.hal
15:25:20 <rayh> but can it load the second .hal file after it has done the loadrt.
15:26:19 <rayh> That would require that the halcmd section issue a bin/halcmd -f
15:27:00 <rayh> How much trouble would it be to modify the "hal section" ini reader so that
15:27:14 <rayh> commands and files could be intermixed.
15:32:35 <rayh> I looked over standard_pinout and it will be easier to just build a bridgeport_step_pinout.
15:37:22 <alex_joni> right
15:42:46 <rayh> If I had a second parport, I could probably do that.  I'll install one later today and build it.
15:43:12 <alex_joni> hmm.. I have a 2-parport PCI card I haven't tried yet
15:43:45 <rayh> There you go.
15:44:29 <alex_joni> I should :D
15:44:44 <alex_joni> I wonder where I've stuffed it..
15:44:51 <rayh> Some of these require the 0xbxxx addy.  Others translate to 378 or so
15:45:01 <rayh> You have that problem also?
15:45:22 <alex_joni> sure..
15:46:11 <rayh> I'm wondering.  There are many specialized versions of bpt out there.
15:46:35 <rayh> I built one overlapping the two definitions on a single parport.
15:47:12 <rayh> Should these things be included with the emc.tgz or emc.deb or should they be wiki material.
15:49:03 <alex_joni> dunno..
15:52:17 <rayh> I think that I favor wiki for much beyond simple standard.
15:53:50 <alex_joni> ok, but some default bridgeport parport setup might be feasible
15:54:46 <rayh> Sure.  And then the wiki page related to it can describe how to rearrange the pins and polarities.
15:55:32 <rayh> For servo systems, a common/bridgeport_io.hal would do the job
15:56:01 <rayh> adds one parport and the default pinouts and polarities.
15:56:44 <alex_joni> bridgeport_io.hal and .clp
15:57:38 <rayh> Oh.  You want to use cl for this.
15:57:57 <rayh> I'd build the most basic with just a .hal but I'm easy.
15:58:36 <rayh> cl would make it reasonably easy for the end user to switch pins and polarities.
16:00:19 <alex_joni> petev has
16:00:31 <rayh> To a second parport?
16:00:36 <alex_joni> no, just clp
16:00:56 <alex_joni> basicly the timers needed for spindle brake & so
16:01:04 <rayh> what does he assume.
16:01:08 <alex_joni> didn't see it yet, so I'm not 100% sure what's in there
16:01:24 <rayh> see spindle brake timing was not a bridgeport thing at all.
16:01:31 <rayh> it was a task
16:01:40 <alex_joni> bridgeporttask afaik
16:03:06 <rayh> * rayh grits my teeth and shuts up.
16:03:23 <alex_joni> rayh: frankly I don't know anything about bpt
16:03:26 <jmkasunich> wassamatter Ray?
16:03:36 <rayh> Nor do I.
16:03:43 <alex_joni> and the more I think about it.. the less I even care
16:04:01 <rayh> So true.
16:04:13 <rayh> but the codeFest agreed.
16:04:21 <alex_joni> great
16:04:22 <jmkasunich> something that has been bugging me about the way these configs are going...
16:04:29 <rayh> I suppose we could simply make a board decision not to.
16:04:40 <rayh> ??
16:04:48 <jmkasunich> we have lots of configs to support different hardware, but they all give pretty much the same configuration
16:05:06 <jmkasunich> few examples show how to config for different machines
16:05:16 <jmkasunich> bport does that, but even it is hardware specific
16:05:41 <jmkasunich> doing samples for N machines and M types of hardware gives N*M samples - not pretty
16:06:06 <rayh> Right.  I favor bpt as separate parport only.
16:06:17 <rayh> hal only
16:06:23 <jmkasunich> steppers only?
16:06:31 <rayh> that way we get two configs
16:06:41 <rayh> one for steppers with an existing parport
16:06:53 <rayh> and one for a single parport as axu io
16:08:09 <rayh> CL is the way I'd really handle aux IO but many don't know ladder.
16:08:44 <jmkasunich> I bet more know ladder than know how to set up a crapload of AND gates, etc with HAL
16:09:05 <rayh> Hi John -- Yes you may be right.
16:09:17 <jmkasunich> I've thought about making CL standard as part of all but the simplest configs
16:10:52 <alex_joni> jmkasunich: it's only 2 lines..
16:10:57 <alex_joni> maybe 3 to load the GUI aswell
16:11:23 <jmkasunich> usually don't want to load the GUI
16:11:27 <rayh> a set of linkpp between iocontrol and cl
16:12:09 <rayh> We could start the gui from a menu in tkemc and mini
16:12:31 <jmkasunich> yeah - start it if and only if you want to check or edit the ladder
16:12:45 <rayh> That would work easy enough.
16:13:38 <rayh> We really need an integrated, easy to use cl gui.
16:13:47 <jmkasunich> yeah
16:13:54 <jmkasunich> frankly the CL gui sucks
16:14:05 <rayh> big time.
16:14:10 <jmkasunich> but fixing it is a man-month project, not something to do for 2.0
16:14:43 <alex_joni> likewise the .clp files suck
16:14:49 <jmkasunich> YES!
16:14:52 <alex_joni> and the possibility to load only one
16:15:01 <rayh> That is about where I bogged down in the wiki page for demo_step_cl
16:16:06 <jmkasunich> in keeping with my propensity to work on things other than emc proper, I've been thinking about tackling the CL problems once the dust settles from the release
16:16:48 <rayh> We should set up a "working group" specifically for that.
16:17:00 <jmkasunich> yeah, pete might be willing to help
16:17:19 <jmkasunich> you know, at some point we should change its name
16:17:20 <alex_joni> he said he has a clp that produces a bpt equivalent
16:17:30 <alex_joni> what name?
16:17:33 <jmkasunich> because Classic Ladder belongs to its original author
16:17:47 <jmkasunich> if we change the GUI and the file format, it isn't CL anymore
16:17:47 <alex_joni> PLC ;)
16:18:13 <rayh> I wonder how that naming of a fork works.
16:18:26 <jmkasunich> don't want to pick the name now, just brought up the idea
16:18:47 <jmkasunich> the other possibility is to talk to the original developer and see if he'll accept our changes
16:18:52 <rayh> "SoftPLC" is trademarked and the folk are violent about it.
16:19:11 <alex_joni> HAL-PLC might be available
16:19:27 <jmkasunich> or SimpleLadder, or something...
16:19:39 <jmkasunich> the name itself isn't the point
16:19:55 <jmkasunich> but we've already forked from original CL (for better or worse)
16:20:05 <jmkasunich> better: don't need to get a CL package from elsewhere
16:20:13 <jmkasunich> worse: its a fork
16:20:32 <jmkasunich> so we don't benefit from future work by the original author
16:21:39 <jmkasunich> anyway, back to emc
16:22:01 <jmkasunich> as I said before, I'm in favor of using CL by default for machine logic, even if its only a couple rungs
16:22:15 <jmkasunich> but maybe that should wait until 2.1?
16:24:01 <jmkasunich> * jmkasunich talking to myself?
16:24:30 <rayh> * rayh being interrupted by fam.
16:24:56 <rayh> Um okay why not all bpt implemented with cl.
16:25:26 <rayh> Why not cl in all of the existing configs.xxx
16:25:33 <rayh> configs/xxx
16:28:08 <alex_joni> right.. I'm good with that
16:28:45 <rayh> It makes modification much easier.
16:28:55 <alex_joni> ok, I need to go away for a while
16:28:59 <alex_joni> I'll be back later
16:29:06 <rayh> see you
16:29:06 <alex_joni> in a couple of hours I think
16:29:14 <jmkasunich> is it possible to put bport style logic in all the motenc, m5i20, stg, etc configs?  just hook the various bport I/Os to digital I/Os on the card, and let the user ignore them?  or do some of them NEED to be connected if the logic is there?
16:30:09 <rayh> The original bpt used only an extra parport.
16:30:38 <rayh> Elson confuses the issue a bit cause he routes estop
16:31:16 <rayh> How about we connect all of iocontrol to cl for all definitions.
16:31:33 <rayh> add the motion pins for m6x
16:31:44 <rayh> But no output.
16:32:29 <jmkasunich> * jmkasunich checks something
16:41:41 <rayh> IMO we should cl everything and cl handles the loopbacks from iocontrol.
16:43:18 <rayh> A single paper describing cl should allow folk to configure IO to their machine.
17:04:54 <rayh> rayh is now known as rayh-away
19:45:03 <jtr> jtr has joined #emc-devel
19:46:00 <rayh-away> rayh-away is now known as rayh
20:59:13 <jtr> jmkasunich: you here?
20:59:27 <jmkasunich> yeah
20:59:43 <SWP_Away> SWP_Away is now known as SWPadnos
21:00:15 <jtr> I had offered to try and test VCP on rc46...
21:01:27 <jtr> I don't see that I will get time before you needed results.
21:01:43 <jmkasunich> no hurry
21:02:25 <jmkasunich> I think some signals got crossed - VCP is something that won't get any serious use (or even testing) until after the 2.0 release
21:02:37 <jmkasunich> there was something else I wanted to test on rc46
21:02:50 <jmkasunich> * jmkasunich racks brain to remember
21:03:30 <SWPadnos> the config picker or something?
21:03:45 <jmkasunich> oh, I remember
21:03:54 <jtr> I got hit with some suprises at work -had to cancel a trip to cabin fever, and will be away on assignment for some weeks.
21:03:58 <jmkasunich> the realtime script wouldn't work (IIRC)
21:04:08 <jmkasunich> no problem
21:04:47 <jtr> Ok - just didn't want to leave you hanging.
21:05:42 <jmkasunich> I appreciate that, thanks
21:06:13 <jtr> you're welcome
21:19:17 <SWPadnos> there was discussion earlier about the various bridgeport config "problems" - does anyone want to continue that?
21:19:30 <jmkasunich> no?  ;-)
21:19:37 <SWPadnos> ok - I'll get more coffee then :)
21:19:49 <alex_joni> * alex_joni plays dead/asleep
21:20:35 <SWPadnos> ZZZzzzzzzz
21:39:18 <SWPadnos> SWPadnos is now known as SWP_Away
22:03:17 <rayh> rayh has quit
22:16:14 <logger_devel> logger_devel has joined #emc-devel
22:16:14 <niven.freenode.net> topic is: "Welcome to the Enhanced Machine Control development place. | Regular Developers' meetings 24/7 !"
22:16:14 <niven.freenode.net> Users on #emc-devel: logger_devel jtr jmkasunich LawrenceG SWP_Away cradek anonimasu jtr_ alex_joni @ChanServ 
22:26:27 <tomp> tomp has joined #emc-devel
22:26:36 <tomp> hello all
22:29:52 <tomp> John, could we (I) get a sample .vcp file?   I got as far as  'vcp {'  in the code and am floundering on format.
22:32:32 <jmkasunich> I thought I stuck a test.vcp in the configs/sim directory?
22:33:26 <tomp> lookin...
22:35:38 <tomp> yep, it's there,  I didn't look there & mc *vcp didnt find it.. thanks
22:36:10 <jmkasunich> no prob
22:51:28 <tomp> and it works too.   all should try it ( off to see what btn does when I hit Y limit )
22:57:24 <jmkasunich> tomp: right now all that test.vcp does is make some buttons that toggle HAL pins when clicked
22:57:38 <jmkasunich> unless you hook those HAL pins to something, nutting will happen
23:03:44 <tomp> jmk: got it, was lookin at the names before i connected em
23:27:01 <tomp> sudo bin/halcmd linkpp button.X-pos-limit axis.0.pos-lim-sw-in     will cause X overtravel by btn press OK :-)