Back
[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: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: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: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 :-)