Back
[00:12:21] <rayh> Hey SWPadnos Is it okay to give out
http://www.cncgear.com/joomla/
[00:12:35] <rayh> on the #emc channel
[00:12:52] <SWPadnos> I don't mind, but I'm not sure if the site is "ready"
[00:13:15] <SWPadnos> people can definitely beat on it though, as far as I'm concerned - I'd like to see what might break, if anything ;)
[00:13:28] <rayh> I know that. Seems like feedback would help.
[00:13:34] <SWPadnos> yep. go for it
[00:13:47] <rayh> Perhaps we should make a #emc-web channel and a logger.
[00:13:58] <rayh> So people can comment and we get em.
[00:14:09] <SWPadnos> I think it can be left on #emc for now
[00:14:39] <SWPadnos> incidentally, I was thinking of putting a logger on cncgear / linuxcnc, so that the logs are on a high-bandwidth server
[00:14:46] <rayh> Sure. except I hate to wade through all the water cooler chatter.
[00:14:58] <SWPadnos> heh - yup
[00:18:30] <rayh> rayh is now known as rayh-away
[00:18:34] <SWPadnos> SWPadnos is now known as SWP_Away
[02:26:19] <SWP_Away> SWP_Away is now known as SWPadnos
[05:08:15] <SWPadnos> SWPadnos is now known as SWP_Away
[13:23:41] <rayh-away> cradek, you around.
[13:24:26] <rayh-away> Some of the servo configs seem to be missing the tool loopback.
[14:54:13] <SWP_Away> SWP_Away is now known as SWPadnos
[20:40:23] <SWPadnos_> hi there, Ray
[20:41:31] <rayh> Hi Steve
[20:41:49] <SWPadnos_> how're things?
[20:41:57] <alex_joni> hi guys
[20:42:00] <rayh> I got the 4 axis sherline running today.
[20:42:01] <alex_joni> * alex_joni is in shortly
[20:42:06] <cradek> hi all
[20:42:07] <SWPadnos_> cool
[20:42:09] <SWPadnos_> hi
[20:42:29] <alex_joni> rayh: how is it?
[20:42:30] <cradek> are all the old rotary axis problems gone? (wrong accelerations and feeds)
[20:43:40] <rayh> Still tuning but it seems to work pretty well.
[20:44:01] <rayh> Yes a and a linear seem to accel well and handle max vel properly.
[20:44:13] <alex_joni> * alex_joni is a bit further away than usually (600km+)
[20:44:16] <cradek> that's great to hear
[20:44:28] <SWPadnos_> how's the show, Alex?
[20:44:30] <cradek> that has always been wrong
[20:44:34] <alex_joni> SWPadnos_: sh*tty
[20:44:45] <SWPadnos_> as usual (for the exhibitors) ;)
[20:45:02] <alex_joni> SWPadnos_: exhibitors are great, never seen this level of stuff in .ro till now
[20:45:06] <alex_joni> but visitors are crap
[20:45:18] <SWPadnos_> heh, the exhibitors usually have a terrible time
[20:45:27] <SWPadnos_> especially dealing with the idiot visitors ;)
[20:45:36] <alex_joni> SWPadnos_: small exhibition (about 30 companies or so), but there are 4 robots
[20:45:46] <alex_joni> including mine ;)
[20:45:53] <SWPadnos_> heh
[20:46:59] <alex_joni> SWPadnos_: which, as you might have guessed, is the nicest one ;-)
[20:47:05] <alex_joni> lol
[20:47:10] <SWPadnos_> of course, that went without saying
[20:47:22] <SWPadnos_> plsu, it's the only one I've seen ;)
[20:47:24] <SWPadnos_> plus
[20:48:21] <SWPadnos_> rayh, is there any reason to not change the default font in tkemc to be "courier" (instead of "courier 10")?
[20:48:45] <cradek> SWPadnos_: I made that change so it uses truetype
[20:48:46] <jepler> SWPadnos_: Like I said earlier, I think the reason is Ubuntu.
[20:49:14] <SWPadnos_> cradek, so courier isn't truetype (on ubuntu)?
[20:49:32] <SWPadnos_> jepler, I was wondering if anyone else can think of something else ;)
[20:49:33] <cradek> no, it's a scaled 75dpi font (everywhere I think)
[20:49:48] <cradek> SWPadnos_: like I said, you can set it in the ini if you want a different font
[20:49:49] <SWPadnos_> yet courier 10 is truetype?
[20:49:53] <SWPadnos_> that seems backwards
[20:49:56] <cradek> yes
[20:50:03] <cradek> yeah the names are strange
[20:50:30] <SWPadnos_> well, I can say for sure that on cygwin/X, plain courier is much better looking than "courier 10"
[20:50:33] <jepler> c0419bt_.pfb -bitstream-courier 10 pitch-medium-r-normal--0-0-0-0-m-0-iso10646-1
[20:50:57] <cradek> SWPadnos_: I'm not interested in changing the default to something that looks good on cygwin but bad on ubuntu...
[20:51:07] <SWPadnos_> I wonder if I just don't have "courier 10 pitch" installed
[20:51:20] <SWPadnos_> so it ends up scaling up a fixed pitch font
[20:51:23] <cradek> SWPadnos_: your X server may not do truetype at all, it's fairly new
[20:51:27] <rayh> There were some issues with low res displays.
[20:51:40] <SWPadnos_> lemme run it local, and see what happens
[20:52:09] <SWPadnos_> this is a BDI 4.30 install, so it should be number 2 or 3 on the list of supported distros
[20:52:22] <cradek> SWPadnos_: that's why I left the other options on the menu
[20:53:06] <SWPadnos_> yep - I saw them there. that's a good thing
[20:53:09] <jepler> /usr/X11R6/lib/X11/fonts/Type1/fonts.scale:c0419bt_.pfb -bitstream-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1
[20:53:33] <SWPadnos_> yep - looks like crap on the local machine as well
[20:53:33] <jepler> It looks like BDI has a font file with the same filename, but calls it -bitstream-courier-
[20:54:15] <cradek> SWPadnos_: I'm not interested in changing the default to something that looks good on bdi but bad on ubuntu...
[20:54:20] <cradek> :-)
[20:54:40] <SWPadnos_> I understand that, I'm just wondering how to make it look good on both
[20:55:00] <SWPadnos_> too bad I know next to nothing about X font configuration
[20:55:01] <alex_joni> SWPadnos_: try using ubuntu on the BDI
[20:55:04] <alex_joni> :-)
[20:55:05] <SWPadnos_> prick
[20:55:08] <SWPadnos_> heh
[20:55:13] <cradek> SWPadnos_: setting it in the ini is probably the only option
[20:55:25] <alex_joni> cradek: or in the tkemc resource file
[20:55:56] <SWPadnos_> I assume that getting tcl/tk to enumerate available fonts would be a lot more trouble than it's worth? ;)
[20:56:02] <cradek> alex_joni: not sure if that would work - there's hackery regarding those fonts
[20:56:13] <SWPadnos_> I'd call it quackery, but that's just me
[20:56:27] <jepler> if {[lsearch [font families] {courier 10 pitch}} { option add the right thing for ubuntu } else { option add the right thing for bdi }
[20:56:40] <alex_joni> fonts are icky on X, at least that's how it seems to me..
[20:56:45] <SWPadnos_> oh, font families gives you a list - nice
[20:56:52] <jepler> SWPadnos_: It can't be done at compile time for various reasons
[20:56:57] <SWPadnos_> sure
[20:57:17] <SWPadnos_> hmmm - is font an X utility, or a tk internal?
[20:57:21] <jepler> The runtime [font families] will tell you what families exist on this machine, but not whether they will look good at any particular size
[20:57:25] <jepler> SWPadnos_: font is a Tk command
[20:57:27] <SWPadnos_> ok.
[20:57:56] <jepler> there's "xlsfonts", an X command
[20:58:06] <jepler> it gives you even more information than [font families]
[20:58:16] <rayh> Question. With ubuntu how do I find files that contain "linkpp xx yy."
[20:58:20] <SWPadnos_> cool, thanks
[20:58:36] <rayh> I tried the gnome find utility but it sucks compared to kde and didn't find the correct files.
[20:58:45] <SWPadnos_> inside an editor?
[20:58:49] <SWPadnos_> or at the command line
[20:59:02] <rayh> No across the configs directory.
[20:59:11] <cradek> rayh: grep "linkpp xx yy." *
[20:59:20] <cradek> oh in multiple directories
[20:59:26] <cradek> find . -type f|xargs grep "linkpp xx yy."
[20:59:43] <rayh> Okay will try.
[20:59:54] <cradek> sorry I have no idea how to use gnome
[21:00:01] <SWPadnos_> ise -i in the grep args if you want it to ignore case
[21:00:12] <alex_joni> grep -r -e "linkpp xx yy" *
[21:00:28] <jepler> and you have to put a backslash before dot if you want to search for a literal dot: grep 'linkpp xx yy\.'
[21:00:50] <alex_joni> rayh: as usual, 4 answers and all correct :-D
[21:01:20] <cradek> wow, grep -r, that must be a gnu thing
[21:01:33] <alex_joni> cradek: I use it all the time
[21:01:37] <jepler> cradek: I think it's been there for years; I typically use find|grep even though I'm dimly aware of grep -r.
[21:01:38] <SWPadnos_> it's been around a long time
[21:01:56] <cradek> not as long as me I guess :-/
[21:02:01] <SWPadnos_> but it doesn't work as well as find, because it only matches dirs that match the file pattern
[21:02:17] <SWPadnos_> unless you do */pattern
[21:02:21] <cradek> ugh, strange
[21:02:40] <SWPadnos_> there may be a way to override that, but I'm pretty sure that's what I've seen
[21:02:55] <alex_joni> I usually do '*' nso I didn't even know that
[21:03:06] <jepler> SWPadnos_: you mean 'find -name "*.c" | xargs grep'? I think you can use grep -r --include="\\.c$"
[21:03:31] <jepler> ooh, grep -Z
[21:03:33] <SWPadnos_> ok - that may be
[21:03:59] <jepler> grep --color?
[21:04:08] <jepler> huh. never knew about that..
[21:04:31] <alex_joni> --color ?
[21:04:37] <SWPadnos_> that would be great with variable regexps
[21:05:13] <jepler> and you can write --colour too
[21:06:05] <SWPadnos_> nice
[21:06:13] <alex_joni> jepler: ok, that's how I would spell it..
[21:06:20] <SWPadnos_> who needs all those fancy log file analyzers? ;)
[21:06:50] <alex_joni> SWPadnos_: wot analyzers? :-)
[21:07:27] <rayh> nother question. Are the "common/" files used any more
[21:07:42] <jepler> rayh: yes, they're used by the build process
[21:07:43] <alex_joni> rayh: yes, they get copied all over
[21:07:51] <SWPadnos_> yes, they get copied ;)
[21:08:03] <jepler> cradek: do you have an answer you'd like to give too?
[21:08:04] <SWPadnos_> cradek - your turn
[21:08:10] <cradek> rayh: yes
[21:08:57] <SWPadnos_> of course, that kind of ruins the helpful aspect of the common files anyway
[21:09:05] <rayh> So if I put the tool prep and tool change loopbacks in core_servo.hal they will be
[21:09:23] <rayh> okay when built?
[21:09:23] <SWPadnos_> since make install won't update user-created/copied configs (AFAIK)
[21:09:25] <cradek> SWPadnos_: no it doesn't, it lets ray fix this thing in one place
[21:09:39] <SWPadnos_> but only for the supplied configs
[21:09:42] <cradek> rayh: yes, if you fix the one in common (in cvs)
[21:10:06] <rayh> * rayh is rapidly loosing any understanding he had of configs'
[21:10:20] <SWPadnos_> unless the make-time copy is smart enough to look for other config dirs (that aren't part of the distribution)
[21:10:41] <cradek> rayh: it's simple: the things in common get copied to the right places when you make
[21:10:54] <rayh> Uh that aint simple.
[21:11:27] <rayh> Simple would be in the right place in the cvs.
[21:11:27] <cradek> it's as simple as possible while retaining the goal of not having 10 copies of core_servo all over the place
[21:12:07] <SWPadnos_> what happens when a user uses the ubuntu auto-update, but they normally use a custom congid, under a directory with a new name?
[21:12:07] <cradek> you'd curse if you had to fix ten copies of it too - choose your poison
[21:12:25] <rayh> my head hurts.
[21:12:42] <cradek> SWPadnos_: custom configs go outside the sample-configs directory
[21:12:50] <cradek> SWPadnos_: so they are not touched
[21:12:59] <SWPadnos_> and therefore lose the advantage of single-point updates
[21:13:35] <cradek> I don't think we ever would want to update a file in someone's custom config
[21:13:43] <cradek> that's asking for trouble.
[21:13:55] <SWPadnos_> well, that was the point of core_xx - the custom configs would include the files
[21:14:04] <SWPadnos_> from common/
[21:14:14] <SWPadnos_> if they wanted to change a file, they'd copy it
[21:14:25] <cradek> according to jmk, the point of "common" was to not have copies of the same file all over the place
[21:14:29] <SWPadnos_> if they didn't change it, updates would be automatic for them
[21:14:32] <SWPadnos_> that's part of it
[21:14:35] <jepler> That was a nightmare as soon as you wanted to copy configs with standard unix tools
[21:14:49] <jepler> from /etc/emc2/configs to ~/emc2/configs
[21:14:50] <SWPadnos_> sure - there are good and bad points for either mode
[21:14:54] <cradek> it was a nightmare either way - just a hidden nightmare
[21:18:02] <SWPadnos_> rayh, did you update after the change I made earlier today? (to core_servo)
[21:18:49] <rayh> * rayh is completely lost on how to do this little change.
[21:19:05] <SWPadnos_> just make the change to core_servo, and commit it there.
[21:19:14] <rayh> Nah.
[21:19:23] <rayh> It is a core servo thing.
[21:19:32] <SWPadnos_> it's a totally separate issue as to whether the current config directory structure is the best ;)
[21:19:33] <rayh> It is a standard_pinout thing.
[21:19:42] <SWPadnos_> ok
[21:19:59] <rayh> It should be in the various xxx IO.hals
[21:20:11] <SWPadnos_> ok - the tool prep links?
[21:20:39] <rayh> Yep. I guy my guys going with it so will probably just ignore it for the repository.
[21:21:06] <SWPadnos_> I made the change to m5i20 today, along with some other things
[21:22:04] <rayh> Okay. BTW, the archive of commits is broken as of the first of this month.
[21:22:20] <SWPadnos_> that's not so good
[21:22:23] <cradek> at least cvs is working
[21:22:38] <cradek> I'm getting kind of tired of sf problems, but not sure what to do about it
[21:22:40] <SWPadnos_> have I mentioned that Dreamhost has CVS and SVN available? ;)
[21:23:00] <rayh> Yes and NO.
[21:23:04] <SWPadnos_> heh
[21:23:24] <rayh> -;
[21:24:06] <rayh> I'd hate to see what happens when trying to get700 subscribers moved.
[21:24:44] <SWPadnos_> that would be a problem
[21:25:04] <cradek> we'll talk about it later if sf continues to get worse
[21:25:15] <cradek> it's certainly not time to move right now
[21:25:41] <SWPadnos_> no, though sometime before the release of emc2 might be better than afterwards
[21:26:05] <rayh> Back to the configs problem.
[21:26:41] <jepler> SWPadnos_: do they allow anon cvs or svn?
[21:26:44] <rayh> I download an emc2 from sf and I have one set of configs
[21:26:50] <SWPadnos_> I think so
[21:26:54] <jepler> SWPadnos_: As far as I could tell they didn't support pserver cvs and I didn't look any more at svn
[21:26:57] <jepler> I don't know much about svn
[21:27:02] <rayh> I run make and I have a different set of configs?
[21:27:08] <cradek> rayh: do you mean cvs?
[21:27:12] <SWPadnos_> ok. I haven't checked into it much - you're probably right
[21:27:22] <rayh> yes
[21:27:25] <jepler> I guess svn has some run-over-http mode?
[21:27:27] <cradek> rayh: when you make, things get copied from common the the appropriate directories.
[21:27:33] <cradek> TO the
[21:29:12] <rayh> So in order to see what all gets changed, I need to place the two configs, pre and post make side by side and diff?
[21:29:26] <cradek> what do you mean changed?
[21:29:48] <rayh> Well all of the config directories exist in sf.
[21:29:48] <SWPadnos_> make only copies some files from common, it doesn't change any files (except for possibly overwriting them)
[21:30:18] <cradek> rayh: yes, but in cvs, common files are only in the common directory.
[21:32:02] <cradek> think of the "make" step as not only building the emc binaries but also building the configs. You have to change the "source" which is in the common directory.
[21:33:21] <rayh> But some do and some don't That is the confusing part for me.
[21:33:55] <cradek> yes, if the file is only used in one config, there's no reason to put it in common.
[21:36:14] <rayh> So the config part of make only adds files from common to each of the other directories that need something from there.
[21:36:31] <cradek> right
[21:36:38] <rayh> But how does make know whether to add something.
[21:36:45] <jepler> It's in the Makefile
[21:36:55] <rayh> uh wrong answer\
[21:37:00] <cradek> ?
[21:37:07] <cradek> like always, we wrote the make rules to tell it what to do
[21:37:20] <rayh> shit
[21:37:30] <jepler> around line 317 there's a list of what to copy from common into each individual directory
[21:37:34] <rayh> So that leaves out all of us nonmake types\
[21:37:52] <cradek> if you need help, ask
[21:38:14] <rayh> That is what I'm trying to ask for
[21:38:40] <rayh> I want to put an IO operation linkpp into every
[21:38:41] <jepler> What do you want to do? Do you need an additional file to be copied from common?
[21:39:14] <cradek> go ahead ray, into every which?
[21:39:21] <jepler> If you edit common/core_servo.hal and then 'make' in src, it will be copied to every directory that uses core_servo.hal
[21:39:33] <jepler> edit and commit only core_servo.hal
[21:39:48] <rayh> only it's not a servo thing.
[21:39:53] <rayh> its an IO thing.
[21:39:58] <SWPadnos_> are you adding a file to the common/ dir?
[21:40:06] <rayh> no.
[21:40:24] <cradek> the _io.hal files are not common since they are all different
[21:40:28] <cradek> so you will have to edit each of them
[21:40:39] <rayh> I'm just getting frustrated cause there isn't good logic for what we've done here.
[21:40:41] <cradek> I mean edit and commit each of them
[21:41:45] <alex_joni> rayh: I agree it's nost the bes way to do it, but we couldn't find a better one :(
[21:42:04] <jepler> bbl
[21:42:05] <alex_joni> the alternatives are worse:
[21:42:09] <cradek> if there isn't a better way, that means we have the best one
[21:42:38] <alex_joni> a). having no common/ dir, and having those files replicated in all configs (is a PITA when we want to change something)
[21:43:04] <rayh> Okay core sim has it
[21:43:09] <alex_joni> b). have it like before: the files in common, and the configs use them from there (is also a PITA; when you try to copy it)
[21:43:14] <rayh> core stepper and core servo do not.
[21:45:37] <SWPadnos_> I agree with you that these links should be in *_io files
[21:45:58] <alex_joni> and definately not in common/
[21:46:10] <alex_joni> maybe have sim_io.hal in common/
[21:46:12] <SWPadnos_> right now, that means that the whatever/whatever_io.hal files all need to change
[21:46:15] <cradek> that being the case, this has nothing to do with common/, or make, you just have to edit and commit each one
[21:46:35] <alex_joni> and get that to be copied & used around the configs
[21:46:46] <SWPadnos_> I think it's better to have it in the separate dirs, because I/O is something that needs to be changed for each real machine
[21:47:55] <alex_joni> SWPadnos_: agreed
[21:48:09] <alex_joni> and saying that I'm going to bed ;)
[21:48:14] <SWPadnos_> agreed ;)
[21:48:17] <alex_joni> goodnight all
[21:48:25] <SWPadnos_> night, Alex
[22:30:45] <rayh> sorry phone
[22:31:55] <Roguish> SWPadnos, i see you just added a couple of loop backs to the 5i20. so, where in the heck are those actual, physical pins in which header on the board? i am totally lost in finding outputs above 08 and inputs above 16.
[22:32:19] <SWPadnos_> I haven't gone looking for them yet ;)
[22:32:33] <rayh> Roguish The loopbacks are only from iocontrol back to iocontrol
[22:32:40] <SWPadnos_> I suspect though, that the second and third headers are just I/O if you don't enable the special functions on those pins
[22:32:51] <rayh> They don't attack the m5i20 at all.
[22:33:06] <SWPadnos_> rayh, do you know how to use all 16 / 32 inputs / outputs on the m5i20?
[22:33:16] <SWPadnos_> we were trying to find where they are on the headers
[22:33:49] <Roguish> yes, the loop backs are internal, but where is output 14?
[22:34:10] <Roguish> the actual LubeOn
[22:34:54] <Roguish> i refer to file hostm54e.pin
[22:35:22] <rayh> I had a conversation with petev on this long ago.
[22:35:44] <SWPadnos_> unfortunately, I don't think any documentation came out of that discussion ;)
[22:35:49] <rayh> I thought that that the encoder signals beyond 4 simply overlapped with the io.
[22:35:58] <SWPadnos_> ok - that's what I was thinking
[22:36:18] <rayh> As far as pins, it is the standard mesa pinout.
[22:36:24] <SWPadnos_> if you don't use the extra "special function" inputs, then they are usable as standard inputs
[22:36:39] <rayh> as if you got one of their IO boards and plugged it in.
[22:37:06] <SWPadnos_> ok. I can look through their manual a bit more
[22:37:10] <rayh> Each connector has both sig and ground pins for each sig.
[22:37:36] <rayh> * rayh goes looking
[22:38:16] <SWPadnos_> I didn't immediately see how to rebuild the FPGA pin file, or the big C header file that's used to load the FPGA
[22:39:51] <rayh> The 7i37 card is the one I was thinking as having the proper set of io pins to it.
[22:39:52] <SWPadnos_> hmmm. I don't think I got a disk with my card
[22:40:34] <Roguish> you're right, no disk with the card. all software is download.
[22:43:37] <rayh> The 7I37 is intended to operate with I/O cards that have 24 I/O bits and IO module
[22:43:37] <rayh> rack type connector pinouts (50 pin connector, all even pins grounded, +5 power on pin
[22:43:37] <rayh> 49).
[22:44:08] <SWPadnos_> yeah - it's the mapping of HAL pin XX with pin YY on some headerthat's the problem
[22:44:53] <rayh> So with that in mind, I'd try watching in0 and twiddle pin 1 on the second 50 pin header.
[22:45:31] <SWPadnos_> I was planning on going the other way, but yeah, that's the idea ;)
[22:45:44] <SWPadnos_> (since I have two 16-channel logic analyzers)
[22:45:51] <rayh> The headers are organized in blocks of 24 16 in first 8 out second.
[22:46:20] <SWPadnos_> ok. That's for the second two headers, and the first one is all special functions?
[22:46:21] <rayh> Just me but I'd use watch in halconfig.tcl
[22:46:53] <SWPadnos_> I think I like driving things with the card better - less chance of frying an FPGA pin
[22:47:04] <rayh> The first one is a standard 4 axis setup. It exactly matches the cards for motion.
[22:48:11] <rayh> motion cards like 7i33 or 7i30
[22:48:15] <Roguish> LubeOn is high when the machine is ON, so i have been toggling the on/off and checking up and down the header for action.
[22:48:46] <rayh> There won't be any unless you connect it.
[22:49:08] <SWPadnos_> lube is connected by default, I think
[22:49:47] <Roguish> in classicladder it goes active with machine on
[22:49:47] <SWPadnos_> though the input-14 connection is for the lube level sense input
[22:50:01] <rayh> mope
[22:50:25] <rayh> nope. The stock m5i20 only has a very few io connections.
[22:51:17] <rayh> No you are correct. out 12 is the lube
[22:51:20] <SWPadnos_> hmmm - there are a number of connections in the m5i20_io.hal file
[22:51:32] <SWPadnos_> I'll take a look at the pins.
[22:51:46] <rayh> that would be the 4th signal on the last 50 pin header.
[22:51:48] <SWPadnos_> we were wondering what all the extra functions were (secondary counters and the like)
[22:51:59] <SWPadnos_> and how they work with all that I/O
[22:52:12] <rayh> They replace io.
[22:52:55] <SWPadnos_> ok, so are the extra functions disabled if the corresponding HAL enable pin is disabled
[22:53:08] <SWPadnos_> for example, the encoder 4-7 inputs
[22:54:49] <SWPadnos_> actually, looking at it, I only see input functions on shared pins. all the outputs (DAC and O pins) are on separate pins
[22:55:29] <SWPadnos_> and that should be OK, as long as you don't try to use both the "advanced" function and the same pin(s) as generic input
[22:58:03] <rayh> I'd bet that if you connect an encoder to the second header exactly as it's done on the first, you will see it count as encoder 04
[22:58:12] <SWPadnos_> right
[22:58:28] <Roguish> what are 'advanced functions' ? the secondary encoder inputs?
[22:58:31] <SWPadnos_> the question was about whether those pins can be used as generic I/O
[22:58:33] <rayh> And the input signals that are used by that are just crap.
[22:58:44] <SWPadnos_> yeah - sorry. anything other than basic pin I/O
[22:59:09] <SWPadnos_> well, they'd be too fast to read, probably
[23:00:06] <rayh> It would have been nice if there were parameters that defined these overlapping functions.
[23:00:24] <rayh> something like param encoder-04-enable
[23:00:27] <SWPadnos_> I was thinking that, and also a HAL-pin to physical-pin map
[23:00:48] <SWPadnos_> which is kind of there, but I had to look at several source files to get it
[23:00:49] <rayh> Don't want much do you.
[23:00:55] <SWPadnos_> heh - nope ;)
[23:01:07] <SWPadnos_> I'll make that HAL->physical map and commmit it myself, though
[23:01:13] <SWPadnos_> commit, even
[23:01:36] <SWPadnos_> what I didn't see, adn can't generate myself, is instructions on how to re-synthesize the FPGA configuration
[23:01:40] <SWPadnos_> s/adn/and/
[23:02:12] <rayh> commit? "They're coming to take me away, away."
[23:02:22] <SWPadnos_> no no - that's committed :)
[23:02:42] <rayh> Ah that was all done between petev and petem.
[23:03:11] <SWPadnos_> right. it's just that all the source is needed to be GPL compliant
[23:03:18] <SWPadnos_> I can't tell if it's all there though
[23:03:36] <rayh> fxxk that sxxt!
[23:03:36] <Roguish> i started a spread sheet with the pin file and am adding notes as i go.
[23:03:52] <SWPadnos_> I've tried loading the hostmot5-4e.vhd file into both the xilinx development kit, and into Altium
[23:04:09] <SWPadnos_> neither works for me (though I'm not an expert there yet, so that may just be me)
[23:04:52] <rayh> This gpl crap for that stuff is pure waste of time.
[23:05:10] <Roguish> i can go to Mesa and speak with Peter M. i just don't think i know all the right questions........
[23:05:12] <rayh> In fact. If it becomes a problem, I'll yank it all myself.
[23:05:13] <SWPadnos_> not really. the reason I wanted the info was so that I could make a customized configuration
[23:05:24] <SWPadnos_> not just to be compliant
[23:05:36] <rayh> And therein lies the rub.
[23:05:52] <rayh> making a different config should not reflect on the existing.
[23:06:04] <SWPadnos_> I'm a reaasonably skilled programmer, and I can't figure out how to customize the baord to my needs
[23:06:19] <rayh> Hell I can load the original hostmot stuff on my own.
[23:06:36] <SWPadnos_> I agree. part of the reason for my wanting to modify it was that I didn't understand the way the present configuration works
[23:06:38] <rayh> and simply use the hal mod as a stand alone system.
[23:06:52] <rayh> I favored that but pete v just wasn't listening.
[23:07:14] <SWPadnos_> well - consider that this card could be used as a step generator as well, but not in its present config
[23:07:39] <rayh> Or 72 io and that config is there. Just not a hal module to handle it.
[23:08:03] <SWPadnos_> I did't see any step generators, only PWM
[23:08:15] <SWPadnos_> maybe the PWM is flexible enough to be a step generator as well
[23:08:26] <rayh> We do have to get away from this shitty little Paul_c complaint about gpl and mesa.
[23:08:51] <SWPadnos_> I'm not complaining about that. I'm complaining that I can't make my own FPGA code based on what we already have
[23:09:01] <rayh> Notice I paralleled his own words.
[23:09:16] <SWPadnos_> I didn't notice that, but OK
[23:09:58] <SWPadnos_> do you know if petev is around, or on vacation or something?
[23:10:15] <rayh> I think he is around.
[23:10:32] <SWPadnos_> OK. I'll email him and ask about how to rebuild the FPGA code
[23:10:36] <rayh> busy with some embedded project these days.
[23:11:17] <SWPadnos_> ok - no hurry here. I think Roguish's immediate question is easily answered
[23:11:31] <Roguish> yeah?
[23:11:45] <SWPadnos_> easily but not immediately ;)
[23:11:51] <SWPadnos_> actually, Ray answered
[23:12:19] <SWPadnos_> inputs 0-15 are the first 16 odd-numbered pins on the middle connector
[23:12:32] <SWPadnos_> outputs 0-7 are the next 8 odd pins on that connector
[23:12:53] <SWPadnos_> inputs 16-31 and outputs 8-15 are the corresponding pins on the last connector
[23:13:08] <SWPadnos_> just ingnore the other labels for secondary encoders and latch masks
[23:13:21] <Roguish> got that
[23:13:38] <SWPadnos_> that was all you needed for now, right?
[23:13:42] <Roguish> is LubeOn on by default or controlled by 'machine on'
[23:13:59] <rayh> machine on turns lubon on
[23:14:22] <rayh> You can see that if you try demo_step_cl and look at the second rung.
[23:14:41] <rayh> or halconfig and watch lubeon
[23:14:54] <Roguish> been doing a lot of that.
[23:15:08] <Roguish> how do i start halconfig
[23:15:12] <rayh> It is all a big step up to hal
[23:15:15] <SWPadnos_> is there a G-code that would turn that on/off?
[23:15:21] <SWPadnos_> (that = lube)
[23:15:22] <rayh> from tkemc it's under the scripts menu.
[23:15:30] <rayh> No.
[23:15:43] <SWPadnos_> ok, so for now, lube is equivalent to machine on?
[23:15:46] <rayh> no g code
[23:15:52] <rayh> Right.
[23:15:53] <SWPadnos_> (until some changes are made in motion-controller)
[23:15:54] <SWPadnos_> ok
[23:16:02] <Roguish> ok, i've been using that
[23:16:23] <rayh> If you want to toggle machine on it's <F2>
[23:16:33] <rayh> with tkemc or mini
[23:16:57] <rayh> but estop has to be off <F1>
[23:17:10] <rayh> only don't tell SWP that I uses that estop word.
[23:17:22] <rayh> used
[23:17:28] <SWPadnos_> * SWPadnos_ isn't listening
[23:17:38] <Roguish> got those keyshort cuts. i'll mod the hal file and put an output on a higher pin and look for it.
[23:17:42] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[23:17:45] <rayh> good.
[23:17:59] <SWPadnos> bad ray
[23:18:02] <SWPadnos> oops
[23:18:09] <rayh> yup
[23:18:37] <Roguish> like i said ealier, i would be happy to go over to Mesa (not far away) and ask, but i'm not sure what to ask!
[23:19:12] <SWPadnos> I'm sending petev an email, asking about any other files and/or instructions on building the FPGA config, so let's see what happens there.
[23:19:34] <Roguish> Peter M is a pretty nice guy, but he tend to speak way over my head....
[23:19:46] <SWPadnos> heh
[23:19:48] <rayh> I know that feeling.
[23:19:57] <Roguish> ask for a schematic file for the fpga
[23:20:13] <SWPadnos> if there is one. it may all be in VHDL
[23:20:32] <SWPadnos> how far from San Jose is Richmond?
[23:21:04] <SWPadnos> of course, I could always ask google maps ;)
[23:21:12] <Roguish> i have not found one. but i figure ya gottta be mutant or something to be able to write in pure vhdl.
[23:21:14] <Roguish> Richmond is about 50 miles north
[23:21:27] <Roguish> just north of Berkeley.
[23:21:29] <SWPadnos> hey - be nice to us mutants
[23:21:40] <SWPadnos> (though I don't know VHDL well yet)
[23:22:06] <SWPadnos> I'm surprised that they won't be showing off at ESC
[23:22:16] <Roguish> no offense meant. the only one i know of is a guy who write bios for OQO.
[23:22:34] <SWPadnos> none taken. I enjoy being a mutant
[23:23:19] <rayh> I think at least a recessive mutant gene is essential for emc enjoyment.
[23:23:26] <SWPadnos> heh.
[23:23:33] <SWPadnos> I've got it from both sides, so ...
[23:23:51] <Roguish> but seriously now, what's the best linux distro for this stuff?
[23:24:12] <Roguish> i started with the debian 4.30 bdi
[23:24:38] <SWPadnos> I think ubuntu is the latest best one
[23:24:56] <Roguish> how 'bout the next best one?
[23:25:17] <SWPadnos> especially for net-connected computers, since the automatic update service will tell you about updates to emc2
[23:25:30] <SWPadnos> probably BDI 4.3(0 or 8)
[23:25:39] <SWPadnos> that was supposed to be 4.30 or 4.38
[23:26:11] <SWPadnos> apparently, there;s a 4,29 now, but I don't think anyone working on emc2 has looked for differences
[23:27:26] <Roguish> .29? gone backwards?
[23:27:28] <SWPadnos> hmmm - maybe there isn't, and the support email I'm thinking of had a typo
[23:27:35] <SWPadnos> oops, 39 I meant
[23:27:44] <SWPadnos> there was a 4.29 ;)
[23:28:00] <rayh> Yes but it was bad.
[23:28:05] <SWPadnos> yep
[23:28:21] <rayh> 20 was okay as is 30. Don't know about 38.
[23:28:29] <Roguish> if there is no compelling reason to change, i will stick with what i have now. don't need any more make work.
[23:28:33] <SWPadnos> ok - it was a thinko on my part - someone asked for help on 4.29, and I thought 4.39
[23:28:56] <SWPadnos> the only reason to change is easy updates
[23:29:03] <rayh> Oh right and I was supposed to reply.
[23:29:35] <SWPadnos> I'm not sure if there will be regular package builds for BDI, but there will be for ubuntu
[23:29:38] <rayh> I've got ubuntu on 2 towers and 1 laptop now.
[23:29:59] <SWPadnos> you've gone ubuntu happy ;)
[23:30:04] <SWPadnos> how do you like it?
[23:30:21] <rayh> Some of the desktop stuff sucks compared to kde.
[23:30:31] <rayh> but it is rock solid which kde isn't.
[23:30:36] <SWPadnos> have you tried installing kubuntu?
[23:30:53] <rayh> I miss being able to start a terminal from a file browser.
[23:31:02] <SWPadnos> I have all the normal KDE apps running under the standard gnome UI
[23:31:22] <rayh> dialup control sucks big time. doesn't know its dialup from an outhouse.
[23:31:42] <rayh> I can't get that many extra packages.
[23:31:51] <SWPadnos> ah - I've only used it with ethernet
[23:32:03] <SWPadnos> yeah, it's a big download
[23:32:09] <rayh> Even the first step toward qt is a 40+ meg
[23:32:14] <SWPadnos> I can send you a kubuntu CD if you like
[23:32:54] <SWPadnos> though that's an install CD, so I'm not sure how it would be for just installing the extra KDE packages
[23:33:02] <Roguish> all i want is the best for emc2, i don't care about the rest. i'm a microsloth guy.
[23:33:24] <rayh> Thanks for the offer. I'm going to wait a week and see what comes of the gnome update.
[23:33:41] <SWPadnos> yeah - I was thinking that as well. the update looks to be substantial
[23:33:57] <SWPadnos> though there was talk of delaying the Ubuntu release fora few weeks
[23:34:06] <SWPadnos> until mid-April, I think
[23:34:22] <rayh> I'm working on a guy in town to put a box on line for me there vpn from here with all the hard work there.
[23:34:45] <SWPadnos> can you get a dry pair from the telco?
[23:35:14] <rayh> Nah. They want a fortune for the last 2 miles.
[23:35:35] <SWPadnos> bummer - those are usually less expensive than a regular phone line
[23:35:44] <Roguish> does emc care what the X? KDE or GNOME or what?
[23:36:16] <SWPadnos> nope
[23:36:19] <rayh> Tkemc and mini will run directly under X11, or most any window manager.
[23:36:40] <SWPadnos> the HAL tools need gtk, but that works on just about any WM as well
[23:36:56] <SWPadnos> I think axis is also gtk (pygtk)
[23:37:06] <Roguish> good. thanks. i may switch to ubuntu to stay up with the jones
[23:37:22] <rayh> I would. I've got both here.
[23:38:20] <rayh> gotta run
[23:38:28] <SWPadnos> err - bye
[23:38:32] <Roguish> downloading now underway.
[23:38:46] <SWPadnos> cool. I like ubuntu myself
[23:39:10] <SWPadnos> you may want to wait before burning / installing though, they are less than a month from a pretty major update
[23:39:38] <Roguish> wouldn't that 'automatic' update do it?
[23:39:45] <SWPadnos> yes and no
[23:40:24] <SWPadnos> you'll end up downloading a lot of stuff again, and there'll be remnants of the previous config files et al.
[23:40:42] <Roguish> downloading will stop, it's realllllly slow right now.
[23:41:05] <SWPadnos> heh
[23:42:03] <Roguish> well, i am going to continue my search for the missing io's, given both your and ray's insight. thanks.
[23:42:11] <SWPadnos> sure