Back
[14:08:47] <andypugh> I have my mill running on 64-bit Lubuntu, Xenomai and UB1.
[14:24:27] <archivist> that sounds...wonderful
[14:29:49] <andypugh> Well, it works at least. Modulo a curious limit-switch problem.
[14:29:59] <andypugh> (not related to software at all)
[14:31:23] <andypugh> I am now trying to work out what I need to do to test the changes I made to make that configuration work with the standard 32-bit Ubuntu v2.5 setup. I do hope there is an alternative to a full clean reinstall...
[15:21:08] <memleak> I always wondered about Xenomai and why people decided to make another RT system instead of fixing RTAI.. I mean, that's what I'm doing because the scheduling and interrupt handling is much better.
[15:22:29] <memleak> I mean if RTAI got all the attention Xenomai is getting, 64-bit would be working by now, plus hundreds of other fixes..
[15:34:25] <andypugh> Isn't RTAI based on Xenomai?
[15:34:35] <mozmck> I think it's the other way around.
[15:35:39] <mozmck> From what I recall reading, the xenomai folks split off of rtai because they wanted prettier code, and rtai folks were more interested in performance.
[15:36:37] <memleak> Yes but you can make a project have pretty code, at least cosmetically, without impacting performance at all.
[15:37:57] <mozmck> could be, but I think part of it was the xenomai skins and such.
[15:38:15] <cradek> it's sad but not surprising when the "make it work" and the "make it pretty" folks split ways. either faction is doomed on its own.
[15:39:52] <mozmck> yes. seems like xenomai still does not give the performance rtai does (just from reading, not personal comparison here).
[15:40:21] <mozmck> but it does have more activity!
[15:40:21] <memleak> They did a lot more than just make the RTAI code pretty, thats why.
[15:41:04] <memleak> RTAI could be clean too, but there's just not enough devs who actually care about cleanliness, doesn't mean they hate clean things though.
[15:41:09] <mozmck> http://www.xenomai.org/pipermail/xenomai-help/2006-08/msg00115.html
[15:41:37] <mozmck> yes, on my part, I would like to help on RTAI but lack time and knowledge - two fairly important factors.
[15:43:50] <memleak> all the ones who do have those two things, decide to work on Xenomai over RTAI though, sadly.
[16:26:12] <andypugh> OK, so, __s32 or s32 ?
[16:26:17] <andypugh> What was decided?
[16:27:02] <memleak> Judging from the scrollback I think __s32 is a better fit.
[16:27:28] <andypugh> Or, what about hal_u32_t ?
[16:27:48] <andypugh> (or hal_s32_t actually)
[16:28:21] <memleak> Umm.. that one, i have no idea about. I don't know the definition of that. (not a linuxcnc guy)
[16:29:51] <memleak> Have you tested __s32 or hal_s32_t ?
[16:29:57] <andypugh> __s32
[16:30:22] <andypugh> But now I am re-doing it as I can't get the patch to apply to the 2.5 branch
[16:30:27] <andypugh> (and it only 3 changes)
[16:30:40] <memleak> you can't solve the conflicts?
[16:30:52] <andypugh> I don't even know how
[16:31:05] <andypugh> Either a patch takes, or I do it by hand
[16:31:31] <memleak> I'm really good with git, can you send me the patch? I'm sure i could get it to apply.
[16:32:48] <andypugh> I see the problem...
[16:33:33] <andypugh> There is a feature in Master (multi-turn resolvers) that isn't in 2.5
[16:33:51] <andypugh> But this is a definite bugfix, so needs to go into 2.5
[16:45:32] <andypugh> Actually, is it possible to attempt to run 2.5 on a 64-bit system?
[16:57:08] <jepler> andypugh: I do (sim) all the time
[16:58:43] <jepler> iirc I ran mesa hardware on 64-bit hardy just to prove a point but used 32-bit on my mill because I wanted lucid
[17:27:46] <andypugh> ah,jepler, do you care to opinionate on the wisdom of swapping all cast-to-"long" for cast-to-"__s32" ?
[18:05:02] <jepler> andypugh: if your algorithm requires a specific size of integer to work properly, then specify it
[18:05:26] <jepler> I wouldn't change every 'long' in the system, though.
[18:05:32] <jepler> just the ones you know are problematic
[18:06:44] <jepler> (whether that's from direct experience or from think about the code)
[18:09:18] <andypugh> I don't even necessarily know what I intended with my own code, so stand little chance with anyone elses :-)
[18:09:57] <andypugh> But I am concerned about stepgen
[18:16:53] <jepler> stepgen at least gets tested on 64-bit platforms
[18:17:08] <jepler> that's not to say it's *right* but it is in the testsuite..
[18:17:08] <jepler> bbl
[18:31:10] <KGB-linuxcnc> 03andy 05v2.5_branch a9fb0a0 06linuxcnc 10src/hal/drivers/ 10mesa-hostmot2/hostmot2.h 10mesa-hostmot2/resolver.c
[18:31:10] <KGB-linuxcnc> Fix a Hostmot2 Resolver bug in 64 bit builds.
[18:31:10] <KGB-linuxcnc> Do not assume that "long" is 32 bits in all systems. this bug resulted in the
[18:31:10] <KGB-linuxcnc> resolver module being utterly unusable, with the apparent resolver angle varying
[18:31:12] <KGB-linuxcnc> randomly by thousands of turns
[18:31:15] <KGB-linuxcnc> Signed-off-by: Andy Pugh <andy@bodgesoc.org>
[19:12:08] <memleak> :D nice fix andypugh
[19:13:57] <andypugh> Complete pig to test. I ended up with two SSDs with different systems on (64-bit ub1 and 32-bit 2.5) and then I had to edit the config files to cope with the 7i64 and 8i20 pins changing names. All to test that the fix in 64-bit didn't break 32-bit.
[19:14:36] <andypugh> (The only way to test is on my live system with 7i49 and real resolvers)
[19:17:11] <andypugh> Is the respnse "You are too stupid for LinuxCNC, just give up" ever a reasonable response?
[19:18:47] <jepler> In those cases I try my best to say nothing
[19:19:00] <jepler> it may take practice, particularly if you have a habit of replying to e-mail, but it's for the best
[19:19:33] <andypugh> This is on the other channel...
[19:45:54] <jepler> oh I don't read that anymore
[22:32:44] <memleak> heh I just tried compiling RTAI from the magma CVS tree, tons of compiling errors.. Sheesh.
[22:52:47] <memleak> havent tried doing that in months. didn't know how broken it all was.. I now see why the RT community is happy with our work on github :)