steve_stallings is now known as steves_logging
from the haas manual: "If, for any reason, the serial number of the machine is erased in memory, the machine will revert back to a 200 hour limit for your protection."
"for your protection" my a$$
well, if you're acting like page 1, it is for your protection
that guy won't last 200 hours
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-05-12.txt
EMC: 03alex_joni 07TRUNK * 10emc2/src/hal/hal_priv.h: bump HAL size, as it's needed for extended configs, and hopefully doesn't cause issues - 2.3 backport candidate
EMC: 03alex_joni 07TRUNK * 10emc2/debian/changelog: mention HAL size bump
alex_joni: finally :P
alex_joni: do you know anything about velocity mode in hm2 ?
hi guys, i creased my hal memory with the HM2 setup as per convo with cradek few days ago, all is well and no signs of any problems yet, have not used much over what was the default before ether.
could you post the output of "halcmd status" on pastebin, just for reference
also, note that Alex doubled HAL memory earlier today, so a CVS update will still have enough for you
yea ill grab the output again no problem
thanks -just curious as to how close it was
oh, and maybe halcmd show as well, for a good idea of the number of pins/params/signals etc. you have
a CVS update will probably show a conflict or local changed file
best would be to remove hal_priv.h before an update
yea im running the 2.3.0 tree
right back to work for me, ill post the results here later
for 2.3 tree the change is not in CVS
so you'll have to keep your own change for a bit
but it's great that we have another report that the change is fine
that will convince jepler to backport the change before 2.3.1
unless you're using the power of positive thinking, in case WILL is appropriate
what I need is positive news about the change, plus a lack of negative news
I hear it's real good
did you try it yourself?
how can I check memory status of whole RTAI not only HAL ?
micges: rtai provides some stuff in /proc/rtai for this purpose but I'm not very familiar with it
/proc/rtai, /proc/rtapi, halcmd status
(of course only the last of those is available in sim)
sim is running all rt code in userspace available for debugging, right?
yes, except for drivers
though you can't debug kernel related stuff in sim, since it's not the same code
(algorithms you can debug)
so mainly sim is to use emc on platforms without any RT ?
no, sim is to simulate emc2 on machines that have no RT
you can't run a machine with sim
I wrote sim so that I could develop non-driver parts of emc2 on systems where it was inconvenient to run the rtai kernel
you can put it however you like
oh - I guess your original statement is true, depending on what you mean by "use" :)
SWPadnos: I'm still learning English ;)
and it has many meanings, so don't worry about it :)
SWPadnos: you could probably run a machine with sim
gs2 works, I know that :)
right, and probably similar ways to connect to smart servos
alex_joni: you would be a very foolish person
I said SWPadnos could
not me :D
I have problem: I have machine
with 2 years of improovements and so
mechanic is about 0.015 mm precise
3 axis mill table machine
ferror in any axis is 0.15 mm
and once a week I have destroyed material with a move that is not seen in preview
and bad move didn't show up in repeating program that was loaded at the time
aren't certain G0 moves not shown in the preview?
is it a move that's supposed to be there but isn't shown, or is it a move that's not supposed to happen at all?
encoder coupling is loose?
is it always in the same axis?
It seems always in Z
xy path are ok but deep isn't
alex_joni, here is the hall status > http://pastebin.com/m28419d37
hal show > http://pastebin.com/m4fbddc0c
how much does it move? which way?
very vel coupling and few times exchanged electtronics and opto filters
z is moving down
when xy are traverse to another drill location
until it starts to look like an emc bug, I think this is a #emc topic, not #emc-devel
some talk about emc over there wouldn't hurt, either
there isn't much lately, is there
so - looks like I will get the shingle on before the fest. (so we will drive down friday and leave tuesday or there abouts)
Now I have to go read about lodging on the list. ;)
132697 heh, that's only a tiny bit larger than the old limit at 131000
the HAL metadata probably shouldn't be in kernel memory
(like names of things)
the only things that are really necessary in kernel space are the signal storage space and pin pointer space
it's only 256k - does that come out of some very restricted pool? if not it seems silly to even worry about it
SWPadnos: rtapi doesn't have non-locked shared memory; the cost of an extra 200kB of locked memory is maybe smaller than the time to add that feature to hal
cradek: it's non-swappable but as far as I can tell rtai doesn't impose any other limitation
it doesn't have to be physically contiguous, for instance
EMC: 03jepler 07TRUNK * 10emc2/docs/src/hal/halmodule.lyx: markup fixes
EMC: 03jepler 07v2_3_branch * 10emc2/docs/src/hal/halmodule.lyx: markup fixes
EMC: 03jepler 07v2_3_branch * 10emc2/src/ (configure configure.in): try to clarify this configure error