Back
[02:06:22] <steve_stallings> steve_stallings is now known as steves_logging
[02:17:18] <jmkasunich> 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."
[02:17:30] <jmkasunich> "for your protection" my a$$
[02:17:49] <SWPadnos> well, if you're acting like page 1, it is for your protection
[02:18:35] <jmkasunich> that guy won't last 200 hours
[02:19:03] <SWPadnos> 200 ns
[08:37:11] <micges> logger_dev: bookmark
[08:37:11] <micges> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-05-12.txt
[09:14:53] <CIA-67> 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
[09:19:12] <CIA-67> EMC: 03alex_joni 07TRUNK * 10emc2/debian/changelog: mention HAL size bump
[09:20:37] <micges> alex_joni: finally :P
[09:21:59] <micges> alex_joni: do you know anything about velocity mode in hm2 ?
[09:25:27] <alex_joni> nope :)
[12:31:50] <rob> 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.
[12:32:51] <SWPadnos> could you post the output of "halcmd status" on pastebin, just for reference
[12:33:26] <SWPadnos> also, note that Alex doubled HAL memory earlier today, so a CVS update will still have enough for you
[12:34:10] <rob> yea ill grab the output again no problem
[12:34:26] <SWPadnos> thanks -just curious as to how close it was
[12:34:48] <SWPadnos> oh, and maybe halcmd show as well, for a good idea of the number of pins/params/signals etc. you have
[12:38:12] <alex_joni> a CVS update will probably show a conflict or local changed file
[12:38:22] <alex_joni> best would be to remove hal_priv.h before an update
[12:43:33] <rob> yea im running the 2.3.0 tree
[12:44:17] <rob> right back to work for me, ill post the results here later
[12:48:22] <alex_joni> for 2.3 tree the change is not in CVS
[12:48:32] <alex_joni> so you'll have to keep your own change for a bit
[12:48:44] <alex_joni> but it's great that we have another report that the change is fine
[12:49:02] <alex_joni> that will convince jepler to backport the change before 2.3.1
[12:49:13] <SWPadnos> s/will/might/ :)
[12:49:33] <SWPadnos> unless you're using the power of positive thinking, in case WILL is appropriate
[12:53:07] <jepler> what I need is positive news about the change, plus a lack of negative news
[12:53:19] <SWPadnos> I hear it's real good
[12:53:47] <jepler> heh
[12:54:23] <jepler> did you try it yourself?
[12:54:44] <SWPadnos> err. no
[12:54:49] <micges> how can I check memory status of whole RTAI not only HAL ?
[12:55:34] <jepler> micges: rtai provides some stuff in /proc/rtai for this purpose but I'm not very familiar with it
[12:55:56] <micges> ok thanks
[12:56:18] <jepler> /proc/rtai, /proc/rtapi, halcmd status
[12:58:23] <jepler> (of course only the last of those is available in sim)
[13:00:04] <micges> sim is running all rt code in userspace available for debugging, right?
[13:00:23] <SWPadnos> yes, except for drivers
[13:00:44] <SWPadnos> though you can't debug kernel related stuff in sim, since it's not the same code
[13:00:54] <SWPadnos> (algorithms you can debug)
[13:02:03] <micges> so mainly sim is to use emc on platforms without any RT ?
[13:02:19] <micges> s/use/run
[13:02:26] <SWPadnos> no, sim is to simulate emc2 on machines that have no RT
[13:02:34] <SWPadnos> you can't run a machine with sim
[13:03:07] <jepler> I wrote sim so that I could develop non-driver parts of emc2 on systems where it was inconvenient to run the rtai kernel
[13:03:19] <jepler> you can put it however you like
[13:03:29] <micges> I understand
[13:03:55] <SWPadnos> oh - I guess your original statement is true, depending on what you mean by "use" :)
[13:04:48] <micges> SWPadnos: I'm still learning English ;)
[13:04:52] <SWPadnos> heh
[13:05:04] <SWPadnos> and it has many meanings, so don't worry about it :)
[13:08:34] <alex_joni> SWPadnos: you could probably run a machine with sim
[13:08:44] <SWPadnos> gs2 works, I know that :)
[13:08:59] <alex_joni> right, and probably similar ways to connect to smart servos
[13:09:05] <jepler> alex_joni: you would be a very foolish person
[13:10:00] <alex_joni> I said SWPadnos could
[13:10:02] <alex_joni> not me :D
[13:11:12] <micges> I have problem: I have machine
[13:11:36] <micges> with 2 years of improovements and so
[13:11:52] <micges> mechanic is about 0.015 mm precise
[13:12:15] <micges> 3 axis mill table machine
[13:12:27] <micges> ferror in any axis is 0.15 mm
[13:13:14] <micges> and once a week I have destroyed material with a move that is not seen in preview
[13:14:08] <micges> and bad move didn't show up in repeating program that was loaded at the time
[13:14:19] <SWPadnos> aren't certain G0 moves not shown in the preview?
[13:14:42] <micges> no no
[13:14:48] <SWPadnos> 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?
[13:15:00] <micges> second
[13:15:07] <SWPadnos> hmmm
[13:15:15] <cradek> encoder coupling is loose?
[13:15:21] <cradek> is it always in the same axis?
[13:16:11] <micges> It seems always in Z
[13:16:37] <micges> xy path are ok but deep isn't
[13:16:44] <robh__> alex_joni, here is the hall status >
http://pastebin.com/m28419d37
[13:16:56] <robh__> hal show >
http://pastebin.com/m4fbddc0c
[13:17:02] <cradek> how much does it move? which way?
[13:17:43] <micges> very vel coupling and few times exchanged electtronics and opto filters
[13:18:09] <micges> z is moving down
[13:18:42] <micges> when xy are traverse to another drill location
[13:18:45] <jepler> until it starts to look like an emc bug, I think this is a #emc topic, not #emc-devel
[13:19:20] <jepler> some talk about emc over there wouldn't hurt, either
[13:19:59] <cradek> there isn't much lately, is there
[14:00:06] <skunkworks> so - looks like I will get the shingle on before the fest. (so we will drive down friday and leave tuesday or there abouts)
[14:00:18] <cradek> slick
[14:00:36] <skunkworks> Now I have to go read about lodging on the list. ;)
[14:04:11] <alex_joni> 132697 heh, that's only a tiny bit larger than the old limit at 131000
[14:07:04] <SWPadnos> the HAL metadata probably shouldn't be in kernel memory
[14:07:09] <SWPadnos> (like names of things)
[14:07:45] <SWPadnos> the only things that are really necessary in kernel space are the signal storage space and pin pointer space
[14:11:31] <cradek> it's only 256k - does that come out of some very restricted pool? if not it seems silly to even worry about it
[14:11:36] <jepler> 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
[14:11:51] <jepler> cradek: it's non-swappable but as far as I can tell rtai doesn't impose any other limitation
[14:11:56] <jepler> it doesn't have to be physically contiguous, for instance
[20:51:29] <CIA-67> EMC: 03jepler 07TRUNK * 10emc2/docs/src/hal/halmodule.lyx: markup fixes
[20:52:11] <CIA-67> EMC: 03jepler 07v2_3_branch * 10emc2/docs/src/hal/halmodule.lyx: markup fixes
[23:00:41] <CIA-67> EMC: 03jepler 07v2_3_branch * 10emc2/src/ (configure configure.in): try to clarify this configure error