Back
[01:10:59] <cradek> jepler: thanks
[01:11:56] <cradek> our deb source tar has .git in it
[01:16:40] <cradek> hm, maybe I still have something wrong (but I did successfully build a new emc2 package)
http://pastebin.ca/1898157
[01:30:45] <jepler> cradek: the one you built, or the ones I build?
[01:31:04] <cradek> the one I just built from v2.4_branch
[01:31:22] <cradek> you do something to avoid that?
[01:31:46] <jepler> yes, I use 'git archive' to get the directory I build from
[01:32:03] <cradek> oh ok
[01:32:34] <jepler> is 'dpkg-source' still too dumb to ignore .git by default?
[01:32:49] <jepler> there doesn't seem to be a way to specify additional ignores in debian/rules or whatever :-/
[01:34:29] <jepler> or maybe you should specify -I or -i to dpkg-buildpackage as a matter of course?
[01:34:32] <jepler> I don't really know
[05:29:01] <KimK> jepler: Another EMC2 Mesa firmware update popped up, so I looked for the "This change is not coming from a source that supports changelogs" business. I found the "Debian Policy Manual - Source Files" at
http://www.debian.org/doc/debian-policy/ch-source.html in "4.4 Debian changelog: debian/changelog" it has a few things to say. Possibly you have looked at this before, but I don't know how long ago you last looked or what has changed since then. Is this
[05:29:01] <KimK> any help, or shall I keep looking?
[05:29:11] <KimK> Bah, I keep flooding
[05:29:41] <KimK> Anyway, It's late, I'll scroll back later. Thanks!
[07:04:07] <CIA-2> EMC: 03cmorley 07v2.4_branch * r06f5788b6754 10/src/emc/usr_intf/pncconf/pncconf.py: fix INI file not honouring invertmotor / invert encoder
[07:04:08] <CIA-2> EMC: 03cmorley 07v2.4_branch * r1c3ea9af6a64 10/src/emc/usr_intf/pncconf/pncconf.py: fix some white space errors no real changes
[07:04:09] <CIA-2> EMC: 03cmorley 07v2.4_branch * rb80c0a211afa 10/src/emc/usr_intf/pncconf/pncconf-help/help-axisconfig.txt: add info about standard axis directions
[07:04:10] <CIA-2> EMC: 03cmorley 07v2.4_branch * rc8fe48847ece 10/src/emc/usr_intf/pncconf/pncconf.py: make homing code more understandable
[07:04:11] <CIA-2> EMC: 03cmorley 07v2.4_branch * rfaf07826c281 10/src/emc/usr_intf/pncconf/pncconf-help/help-axisconfig.txt: add info about standard axis directions
[07:04:12] <CIA-2> EMC: 03cmorley 07v2.4_branch * r3de45447f4eb 10/src/emc/usr_intf/pncconf/pncconf.py: fix firemare name errors on 7i43 ans 5i22
[07:04:12] <CIA-2> EMC: 03cmorley 07v2.4_branch * r646be76669ba 10/src/emc/usr_intf/pncconf/pncconf.py: add firmware for 3x20-1 boards
[07:04:15] <CIA-2> EMC: 03cmorley 07v2.4_branch * r8a597ccb1f2f 10/src/emc/usr_intf/pncconf/pncconf.py: remove whitespace from 7i43 driver name in firmware array
[07:04:16] <CIA-2> EMC: 03cmorley 07v2.4_branch * r5831554e4518 10/src/emc/usr_intf/pncconf/pncconf.glade: add connector tab names to mesa page for 3x20-1
[13:03:36] <jthornton> does stepgen still have something called doubfreq?
[13:04:22] <jthornton> If -reset is TRUE, then the reset function will set the pin to the value of -out-invert. This can be used in conjunction with stepgen's doublefreq to produce one step per period.
[13:36:12] <Dave911> How do you guys deal with the Mesa bit files no longer residing in the source files? I copied them into \lib\firmware\hm2 and that worked even though I was using a RIP setup. I know the bit files are kept in the Git
[13:36:14] <Dave911> repository, but honestly I don't want to have to recompile the bit files each time I do a git clone to setup a system. Perhaps I am doing something wrong?
[13:37:27] <Dave911> bbl
[14:51:14] <jepler> Dave911: install one of the deb packages to get the firmwares. You'll find hostmot2-firmware-<cardname> in the package manager if you've got a normal 8.04 system.
[17:27:14] <skunkworks> Nice release!
[17:27:18] <skunkworks> great work!
[17:27:28] <skunkworks> (I have been out of the loop for the week)
[21:32:11] <JT-Hardinge> cradek: do you know if stepgen still have something called doubfreq?
[21:32:14] <JT-Hardinge> have/has
[21:32:47] <andypugh> Is that related to the P-port reset?
[21:33:10] <JT-Hardinge> yes
[21:33:29] <JT-Hardinge> from the manual "If -reset is TRUE, then the reset function will set the pin to the value of -out-invert. This can be used in conjunction with stepgen's doublefreq to produce one step per period."
[21:33:30] <cradek> yes but I don't know how it works exactly
[21:33:39] <cradek> I think stepconf defaults to making doublestep type configs
[21:34:04] <andypugh> I think if reset is true on the pin, then that's what you get.
[21:34:11] <JT-Hardinge> the manual kinda reads like you (the integrator) needs to hook something up to doublestep
[21:34:58] <JT-Hardinge> but it seems to me that all the connections/settings are in parport
[21:35:52] <JT-Hardinge> it might just be the wording that is implying that something needs to be done with doublestep to my brain...
[21:39:18] <andypugh> No, from what you quoted that does sound like what it is saying.
[21:42:36] <JT-Hardinge> I think it should read something like ... This will take advantage of stepgen's doublefreq to...
[21:45:16] <JT-Hardinge> or, ... This will enable stepgen's doublefreq module to ...
[22:45:32] <jepler> JT-Hardinge: doublefreq means simply setting stepspace=0
[22:46:34] <jepler> so that step can be asserted on every period in HAL (and then toggled off by parport after being asserted for a short time, the parport reset-time or whatever it's called)
[22:49:04] <jepler> originally the design actually had a 'doublestep' parameter on stepgen, but this was unneeded (stepspace=0 was enough)
[22:53:35] <JT-Hardinge> Ok, thanks jepler