our deb source tar has .git in it
hm, maybe I still have something wrong (but I did successfully build a new emc2 package) http://pastebin.ca/1898157
cradek: the one you built, or the ones I build?
the one I just built from v2.4_branch
you do something to avoid that?
yes, I use 'git archive' to get the directory I build from
is 'dpkg-source' still too dumb to ignore .git by default?
there doesn't seem to be a way to specify additional ignores in debian/rules or whatever :-/
or maybe you should specify -I or -i to dpkg-buildpackage as a matter of course?
I don't really know
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
any help, or shall I keep looking?
Bah, I keep flooding
Anyway, It's late, I'll scroll back later. Thanks!
EMC: 03cmorley 07v2.4_branch * r06f5788b6754 10/src/emc/usr_intf/pncconf/pncconf.py: fix INI file not honouring invertmotor / invert encoder
EMC: 03cmorley 07v2.4_branch * r1c3ea9af6a64 10/src/emc/usr_intf/pncconf/pncconf.py: fix some white space errors no real changes
EMC: 03cmorley 07v2.4_branch * rb80c0a211afa 10/src/emc/usr_intf/pncconf/pncconf-help/help-axisconfig.txt: add info about standard axis directions
EMC: 03cmorley 07v2.4_branch * rc8fe48847ece 10/src/emc/usr_intf/pncconf/pncconf.py: make homing code more understandable
EMC: 03cmorley 07v2.4_branch * rfaf07826c281 10/src/emc/usr_intf/pncconf/pncconf-help/help-axisconfig.txt: add info about standard axis directions
EMC: 03cmorley 07v2.4_branch * r3de45447f4eb 10/src/emc/usr_intf/pncconf/pncconf.py: fix firemare name errors on 7i43 ans 5i22
EMC: 03cmorley 07v2.4_branch * r646be76669ba 10/src/emc/usr_intf/pncconf/pncconf.py: add firmware for 3x20-1 boards
EMC: 03cmorley 07v2.4_branch * r8a597ccb1f2f 10/src/emc/usr_intf/pncconf/pncconf.py: remove whitespace from 7i43 driver name in firmware array
EMC: 03cmorley 07v2.4_branch * r5831554e4518 10/src/emc/usr_intf/pncconf/pncconf.glade: add connector tab names to mesa page for 3x20-1
does stepgen still have something called doubfreq?
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.
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
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?
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.
(I have been out of the loop for the week)
cradek: do you know if stepgen still have something called doubfreq?
Is that related to the P-port reset?
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."
yes but I don't know how it works exactly
I think stepconf defaults to making doublestep type configs
I think if reset is true on the pin, then that's what you get.
the manual kinda reads like you (the integrator) needs to hook something up to doublestep
but it seems to me that all the connections/settings are in parport
it might just be the wording that is implying that something needs to be done with doublestep to my brain...
No, from what you quoted that does sound like what it is saying.
I think it should read something like ... This will take advantage of stepgen's doublefreq to...
or, ... This will enable stepgen's doublefreq module to ...
JT-Hardinge: doublefreq means simply setting stepspace=0
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)
originally the design actually had a 'doublestep' parameter on stepgen, but this was unneeded (stepspace=0 was enough)
Ok, thanks jepler