jthornton_ is now known as jthornton
-rw-r--r-- 0/0 2737686 2010-10-09 08:11 emc2-2.4.5/src/emc/usr_intf/pncconf/pncconf.glade
that's a HUGE file!
happily, it compresses REALLY WELL
$ gzip -9 < pncconf.glade | wc -c
(that's a 97.5% reduction in size)
is this normal? http://pastebin.ca/1958195
It loads in hal.\
I was developing it in a sim install on my laptop - this is the first time I compiled it on the actual machine
(just didn't see those errors on my laptop.
skunkworks: yes, these warnings are normal: WARNING: "rtapi_snprintf" [/tmp/tmpV6koCg/gearshift16.ko] undefined!
the real test is whether the module loads
somebody who is not too tired should figure out how to fix it; it probably involves changes to the rtai and emc2 packaging to privde a list of symbols from each of them when building components
seems to load. But I have issues when I am setp'ing some values. but it is probably something I am doing. (componant loads and the function gets added)
EMC: 03jepler 07v2.4_branch * rb5bb7beec1b3 10/ (VERSION debian/changelog): release v2.4.5
well that was only several weeks overdue :-/
researchers have discovered a startling new idea in computer design: make computers out of relays! http://hardware.slashdot.org/story/10/10/09/155202/Electromechanical-Switches-Could-Reduce-Future-Computers-Cooling-Needs
jump to the side?
uhh, switching at 500 kHz... ??
cool, a release!
ok - why would a pin say it is true - but not set the output on the mesa card? The gear comp sets the out put true but the output doesn't turn on. if I unlink the pin and set it true manually it works.
it is the 4 shift rails - the first one seems to work - but the last 3 doesn't work.
it shows true in hal show. I am setting it by sasol = gear & 1
each rail then is = gear & 1 , = gear & 2, = gear & 4, = gear & 8
where gear is a number 1-16 that corisponds to the gear picked
the first rail works (sasol = gear & 1)
but like I say - in hal show - it shows it as true.
but the actual relay isn't turning on
unlink pin and I can set the output true manually with a setp ....
it seems to be an issue with with how I am 'anding' to get the bits. I can set them manually within the comp by manually setting the bits to true
AND do you want to OR
I want to take a 1-16 number and convert it to 4 bits
skunkworks: it looks like you've just discovered a bug in hostmot2 :-/
preparing a patch ..
skunkworks: try with this patch: http://emergent.unpy.net/files/sandbox/0001-hostmot2-handle-a-bit-pin-with-a-value-other-than-0-.patch
cradek: may you take a look at http://psha.org.ru/git?p=psha/emc2.git;a=commitdiff;h=520b6ad2aaa6f256544c5b2ca5338a3320ba9c1a
it adds killing of spawned child processes
jepler: thank you! that worked
If I am not good for much - atleast I am good at finding bugs :)
most bug are discovered few hours after bugfix release ;)
jepler: weird lyx stuff in that patch
yuck, that nasty C feature has sure bitten us a lot of times
psha: I am not at the right computer(s) to apply that - but it looks good to me
psha: I will get it later if nobody else grabs it
so it's in touchy-embed branch
i'll add this to .axisrc too and update wiki page
cradek: I agree, I just imagined my hours spended looking what's wrong
it applied no proglem
proglem? almost make sense
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-10-09.txt
we dumped a bit of oil out before we figured out that we left the old spindle speed magnetic pickup out.
does spindle at speed work with g4px also?
so if I have a spindle speed and then a delay - emc won't start the delay until the spindle is at speed?
I guess I could test that
cradek: oops, ugh
patch updated at same url: http://emergent.unpy.net/files/sandbox/0001-hostmot2-handle-a-bit-pin-with-a-value-other-than-0-.patch
jepler: should I apply that patch?
Or not worry about it?
at what point will That get into trunk?
skunkworks: probably not long
I wish the answer was "in v2.4_branch" and "about 24 hours ago" :-(
heh - I have to use head anyway. not an issue for me. :)
trunk, what ever it is
I had no clue what was happening. I could see that the pin was true - but the little light on the ssr wasn't on. ;)
EMC: 03jepler 07v2.4_branch * r290bf1737b22 10/src/hal/drivers/mesa-hostmot2/ioport.c: hostmot2: handle a 'bit' pin with a value other than 0 or 1
skunkworks: it's a bug I've personally written several times, so I knew what to look for
heh - neat
is psha pavel?