Back
[07:44:28] <alex_joni> libnml/cms/tcp_srv.cc 1494: Unrecognized request type received.(131072)
[07:44:29] <alex_joni> libnml/cms/tcp_srv.cc 1494: Unrecognized request type received.(131072)
[07:44:37] <alex_joni> any clue what's wrong there?
[07:55:53] <alex_joni> that comes from a NML communication between a 10.04 client (i386, 2.6.32-122-rtai) to a beaglebone running 3.8.13xenomaibone26.1
[07:56:14] <alex_joni> I suspect some endianness or something, although NML should be insensitive to that AFAIK
[08:29:25] <cradek> 16o131072p
[08:29:26] <cradek> 20000
[08:29:41] <cradek> yeah maybe some word-order thing
[09:00:23] <seb_kuzminsky> nml must die
[09:13:04] <kwallace> .^! # NML Rocks #!^.
[09:31:45] <cradek> the lone good thing about nml is it's already working
[09:37:18] <seb_kuzminsky> yeah, that is a good thing
[09:42:52] <alex_joni> except when it's not :/
[09:56:25] <alex_joni> cradek: what's 16o ... p?
[09:56:31] <cradek> dc
[09:56:42] <cradek> "what's 131072 in hex?"
[09:57:58] <alex_joni> ah, ty
[09:57:59] <cradek> and apparently it's the same as 0000 0002 but swapped
[10:59:00] <alex_joni> it seems ARM > v3 is big endian
[10:59:10] <alex_joni> and x86 should be little endian
[11:02:34] <cradek> I understand arms come both ways
[11:50:37] <skunkworks_> left and right?
[11:52:21] <skunkworks_> cradek: what do you think of Robs latest trajectory paper?
[12:01:24] <cradek> I didn't get all the way through it yet
[12:02:22] <cradek> I'm sorry to see he's not finding a simple answer
[12:07:02] <skunkworks_> cradek: Did you have a feeling there is one?
[12:07:29] <skunkworks_> and what was segment que?
[12:18:17] <cradek> also I think if you use tangent arc to blend between lines you get discontinuous jerk at the transition, where the current scheme is continuous
[12:19:11] <cradek> his table 1 is missing some cases, and he's maybe forgotten that machines are not only xyz
[13:45:09] <riz_> in halui.c what is the difference between emcCommandWaitReceived() and emcCommandWaitdone()
[13:46:02] <riz_> I am trying to implement a multi line mdi command but when I tried implementing it the program runs only the last command so I need something to wait for each command to finish prior to giving the next command
[13:47:16] <cradek> have you considered O<sub> call? that's how touchy does macros.
[13:48:10] <riz_> Yes I have, but I didnt want to go that route
[13:50:22] <riz_> There must be a way to just get a signal that the move has completed and to begin the next command
[13:55:52] <cradek> and you have found that's not what WaitDone does?
[14:01:36] <riz_> I didn't try waitdone
[14:01:48] <riz_> I wanted to understand it prior to trying it
[14:02:00] <riz_> I am curious why it wasnt already used
[14:02:21] <riz_> If that is what it is for I can give it a go
[14:02:38] <riz_> But if it might interfere with some other functionality I dont want to do it
[14:03:14] <cradek> well you usually don't want the gui to wait for it to be done before responding and/or sending other messages
[14:03:23] <cradek> what if the user wants to hit escape to stop the mdi command?
[14:03:51] <cradek> seems like you'll have to experiment with whatever tradeoffs
[14:04:27] <riz_> Right. I see
[14:11:27] <riz_> Is it possible to use the "in_position" flag to wait until the current move is in position to start the next?
[14:11:40] <riz_> Or do you see a flaw with that?
[14:14:00] <riz_> emcmot_hal_data->in_position that is
[14:14:15] <cradek> sure, mdi commands that don't cause motion
[14:15:15] <riz_> Very true...lol
[14:15:34] <riz_> ok. ill have to explore this some more
[14:16:06] <riz_> thanks
[15:44:45] <andypugh> There was some discussion about "contention" between Axis and Halui and breaking NML queues. Did any fix for that get into a release?
[15:49:10] <pcw_home> did you see the link with mhaberler and saschas discussion/patch?
[15:49:38] <pcw_home> not idea if its been incroporated
[15:49:56] <pcw_home> no idea if its been incorporated
[15:52:14] <andypugh> Yes, I looked at it, and it seems to have not been implemented.
[15:52:40] <andypugh> (On the gorunds that it will fix itself when NML dies)
[15:53:16] <pcw_home> Ahh
[15:53:18] <cradek> if there's a patch that works, and would work for 2.6, and is testable, we should incorporate it for 2.6
[15:54:05] <cradek> the eventual heat death of the universe is not a good reason not to fix bugs
[15:54:36] <andypugh> Patch and much discussion here:
http://sourceforge.net/p/emc/bugs/328/
[15:54:43] <cradek> (if the patch is unclear and/or hard to test that's another story)
[15:55:35] <andypugh> I just spotted a second-page, and a happy user on the second page
[15:55:49] <cradek> > But I've seen some inconsistent use of datatypes (int/long) and some missing usage of network byte order macros in tcp_srv.cc
[15:55:52] <cradek> *cough cough*
[15:56:16] <andypugh> (the finalised patch is in the last message of page 1, by the way)
[15:56:17] <cradek> funny he should say that...
[15:56:37] <andypugh> He looks like a useful chap to have on board :-)
[15:57:01] <cradek> certainly
[15:58:53] <cradek> oh my, it changes every message-send and message-read site
[15:59:30] <andypugh> Touchy doesn't let me MDI M3S1000G98G82Z-2R0.1X100Y100
[15:59:51] <cradek> no, not all at once
[16:00:05] <cradek> but you can send each of those separately
[16:00:19] <andypugh> (More "fix-worthy" is that it won't let you add a P to a G3
[16:00:37] <cradek> oh! yeah that's easy
[16:00:43] <cradek> the first thing you said is not a bug :-)
[16:01:04] <cradek> does 2.5 have multiturn arcs?
[16:01:05] <andypugh> Neither are bugs as such, the latter may be a missing feature at worst
[16:01:18] <andypugh> Who runs 2.5?
[16:01:48] <andypugh> (I am running some version of master on the machine)
[16:02:08] <cradek> I don't care what you're running, I care about where to fix that bug
[16:02:22] <cradek> I'll figure it out, never mind
[16:02:26] <andypugh> Part of the reason I am messing with tool setup is that I also intend using my (un-changed since Wichita) tool-table stuff.
[16:05:11] <andypugh> But the NML thing was a complete change to the NML handshaking I think.
[16:05:19] <cradek> yeah
[16:06:54] <andypugh> How hard is it to make that patch available as a buildbot option?
[16:07:13] <cradek> huh, kgb must've fell over again
[16:07:15] <andypugh> (ie, put it in a branch that buildbot builds that we can point people to)
[16:07:28] <cradek> just push it to a new branch and buildbot will test and package it up
[16:08:37] <cradek> but pointing joe-user at it is more trouble than it's worth
[16:08:40] <andypugh> Somebody is having trouble. I have had him hack Axis a bit (didn't help) and suspect that suggesting that he build form source is asking a bit much.
[16:08:57] <cradek> eek
[16:09:08] <andypugh> http://linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/27113-bridgeport-retrofit-keyboard-input-delays-noted/reply/40052?quote=1#40044
[16:09:53] <andypugh> I don't even know of the patch "takes" on 2.5.5
[16:13:35] <cradek> the "try another gig of ram" responses make me want to cry
[16:13:48] <cradek> so much noise (from so many well-meaning people) on the forum
[16:14:19] <andypugh> Luckily it is a cheaper idea than it would have been 20 years ago.
[16:14:55] <cradek> can you tell me what you think the problem is? I haven't waded deep enough in the thread to see it yet
[16:16:42] <andypugh> The symptoms are the same as those discussed in the bug-tracker thread, and also match those apparently fixed for the last-poster to the bug-tracker thread.
[16:16:44] <cradek> is his shuttle thing constantly issuing nml messages? has he turned on the 'task issue' debug?
[16:17:59] <cradek> I've seen so many people be bitten by their gamer usb devices sending messages at unexpected times
[16:18:08] <andypugh> I am unclear on the details, other than that some people have seen problems with Axis becoming unresponsive when they are also making heavy use of user-space UI hardware.
[16:18:40] <andypugh> I am as guilty of good-natured flailing as everyone else in the thread.
[16:19:02] <cradek> if both UIs issue a message simultaneously, one of them can lose and never see its serial number in response -- then there is a timeout
[16:19:29] <cradek> if his misconfigured UI (probably halui) is sending lots of unwanted/unexpected messages this could happen often
[16:19:51] <cradek> I'd suggest turning on debug and looking at the messages being sent
[16:20:11] <cradek> I'd also suggest throwing that thing away and getting a wheel, but that's a bit less "helpful"
[16:21:27] <cradek> reinstall the xserver, oh my god.
[16:21:42] <andypugh> I have been wondering about suggesting that he move the controls into HAL/Realtime
[16:21:59] <cradek> debug messages first
[16:23:04] <andypugh> Do you feel like suggesting it, or do you brak out in hives at the very thought of the forums?>
[16:24:02] <cradek> I have different patience for it at different times. today is not looking good.
[16:24:20] <cradek> the debug option you want is called "task issue" in the AXIS debug panel thingy
[16:25:08] <cradek> I predict you'll see unwanted messages (from halui while not twiddling the shuttle thing)
[16:25:19] <cradek> I predict fixing that will hide the problem quite well
[16:25:57] <andypugh> "Axis UI debug thingy" ?
[16:26:06] <cradek> on the menu
[16:26:09] <cradek> set debug level
[16:26:18] <andypugh> There are bits of LinuxCNC that remain a mystery to me, clearly.
[16:26:35] <cradek> and me too
[16:27:00] <cradek> ideally we'd all have different mysteries
[16:28:05] <andypugh> Where do the debug mesages go to?
[16:28:13] <cradek> stdout or stderr
[16:29:14] <andypugh> nothing in kernel.log
[16:29:16] <cradek> if you run sim/axis and use halcmd to twiddle halui's abort pin you'll see the abort message
[16:29:59] <andypugh> Let me go through this step-by-step so I can give clear instructions.
[16:30:13] <cradek> unfortunately I have to run
[16:30:20] <cradek> thanks for helping him
[16:30:29] <cradek> bbl after concert (yay)
[16:30:37] <andypugh> Think I have it.
[17:19:08] <seb_kuzminsky> linuxcnc-build: force build --branch=v2.5_branch checkin
[17:19:09] <linuxcnc-build> build #1404 forced
[17:19:09] <linuxcnc-build> I'll give a shout when the build finishes
[17:19:32] <seb_kuzminsky> ok, sorry about the un-announced downtime, things should be back to normal now, and stable
[18:34:05] <CaptHindsight> seb_kuzminsky: is there anything special required other than just installing the .debs, rebooting and choosing the newer kernel in grub?
[18:34:16] <CaptHindsight> http://highlab.com/~seb/linuxcnc/rtai-for-3.4-prerelease/
[18:34:27] <CaptHindsight> http://sourceforge.net/mailarchive/message.php?msg_id=31248707
[18:36:59] <linuxcnc-build> build #1079 of package-sim-lucid-source is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/package-sim-lucid-source/builds/1079
[18:37:00] <linuxcnc-build> build #1079 of package-rt-lucid-source is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/package-rt-lucid-source/builds/1079
[18:37:01] <linuxcnc-build> build #1079 of package-rt-hardy-source is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/package-rt-hardy-source/builds/1079
[18:59:51] <linuxcnc-build> build #1404 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1404
[22:10:56] <seb_kuzminsky> CaptHindsight: to test out linuxcnc on rtai on linux 3.4, that should do it
[22:26:18] <linuxcnc-build> build #1080 of package-rt-hardy-source is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/package-rt-hardy-source/builds/1080
[23:58:36] <linuxcnc-build> build #1080 of package-rt-lucid-source is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/package-rt-lucid-source/builds/1080