Back
[02:02:53] <seb_kuzminsky> i can reproduce leonardo marsaglia's bug report
[02:06:53] <seb_kuzminsky> it's apparently because the name of the .ko file (senito.ko) doesn't match the name of the comp (sincos) given to hal_init()
[02:12:24] <seb_kuzminsky> that's a requirement of 'halcmd loadrt', which is not documented in the comp docs
[02:13:35] <seb_kuzminsky> http://www.linuxcnc.org/docs/2.5/html/hal/comp.html#_syntax
[02:13:41] <seb_kuzminsky> or at least i couldn't find it anywhere
[02:17:13] <archivist> I just looked and could not find either
[02:18:09] <seb_kuzminsky> it's also not documented in the halcmd section on loadrt
[02:21:36] <seb_kuzminsky> opened
https://sourceforge.net/p/emc/bugs/377/ to fix the docs
[02:33:30] <Robert302> Hello! I have a problem with the emcrsh! I find the same question here:
http://en.it-usenet.org/thread/18399/4980/! Yesterday I started a debug session and i found out that the software is hanging in a while loop! The Loop is in shcom.cc and is named emcCommandWaitReceived
[02:36:07] <Robert302> i've added there a printf to show the states. The Problem i have is strange there on a MachineOn Command dhe emcStatus->echo_serial_number is set to 13 and the serial_number of the command which is requested is 13. The software also executes the machineOn but after that the emcrsh does not request any commands because the software is running this while loop.
[02:37:19] <Robert302> sorry the requested serial_number is 3. So it is lower than the emcStatus->echo_serial_number which is 13
[02:41:41] <Robert302> why is it possible that the emcStatus->echo_serial_number is already 13 and the serial_number if the shcom.cc is only 3? i only executed 3 commands!
[02:51:42] <seb_kuzminsky> are there any other UIs running? halui maybe?
[02:52:19] <Robert302> yes the gui on the machine is running
[02:54:31] <seb_kuzminsky> i think it's this bug:
https://sourceforge.net/p/emc/bugs/265/
[02:54:39] <seb_kuzminsky> open since 2011 :-(
[02:54:40] <Robert302> are they accessing the same command buffer? because then it is clear for me because same serial_numbers could be created
[02:55:09] <seb_kuzminsky> there's a serial number collission issue with multiple UIs
[02:55:29] <Robert302> okay so this is more a concept problem to be fixed
[02:55:35] <seb_kuzminsky> yeah
[02:55:54] <seb_kuzminsky> the bug is very deep unfortunately
[02:56:46] <seb_kuzminsky> the workaround is to only run one ui (emcrsh and axis count as UIs here, halui does not)
[02:59:07] <seb_kuzminsky> if you're feeling brave you could try applying this hacky workaround to emcrsh.c:
[02:59:38] <seb_kuzminsky> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/usr_intf/halui.cc;h=0fc32a1a6a6a3131c2685bed1602a192ca35a21e;hb=refs/heads/master#l402
[02:59:39] <Robert302> this could be a fast solution for me now because i do not really understand the structure behind the command handling until now. =) maybe i will find some time to start a fix
[03:00:32] <seb_kuzminsky> heh, the line that says "XXX it would be nice to have a real fix here XXX" was added in 2007
[03:00:40] <seb_kuzminsky> 7 years later it'd still be nice
[03:00:47] <seb_kuzminsky> good luck Robert302, i'm off to bed
[03:00:50] <Robert302> =) all right
[03:01:04] <Robert302> thanks for your help
[03:01:16] <Robert302> first of all i wan't to finish the comedi driver .. =)
[03:01:36] <Robert302> bye
[06:55:10] <KGB-linuxcnc> 03John Thornton 05v2.5_branch ddd42e6 06linuxcnc 10docs/src/hal/comp.txt Docs: add info about file naming * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ddd42e6
[10:50:18] <lair82> Hello guys, We switched one of our turning centers over to gmoccapy from gscreen just to see something different, and to see maybe if the memory leak issue I was talking about might go away. we havent actually ran any production yet so I am not sure how it is going yet, But I have noticed one thing already, we randomly through out the day, on any of the three linux machines in our shop will get the following error, "Requested t
[10:51:48] <lair82> What will cause that when that tool could have been used a hundred times already that day, and then all of a sudden we get that error, and almost always have to delete that tool from the tool table and re-enter a new tool with that data to resume operations.
[11:02:49] <archivist> you got cut off following error, "Requested t
[11:04:38] <lair82> following error, "Requested tool XX not found in the tool table".
[11:04:50] <lair82> What will cause that when that tool could have been used a hundred times already that day, and then all of a sudden we get that error, and almost always have to delete that tool from the tool table and re-enter a new tool with that data to resume operations.
[11:21:14] <CaptHindsight> lair82: is it the same tool on each of the 3 different machines? and random tool?
[11:24:32] <lair82> Nope, any tool, on any machine, at any time
[11:32:12] <lair82> We are using this patch on all three machines, directly related to the tools,
http://www.linuxcnc.org/index.php/english/forum/20-g-code/24387-tool-offset-patch?start=30.
[11:32:33] <lair82> Would this have any bearing on the problem at hand?
[13:20:58] <skunkworks> https://github.com/machinekit/machinekit/issues/202
[13:27:11] <seb_kuzminsky> saw the email
[13:30:16] <skunkworks> oh - heh. for some reason I thought it was on machinekit...
[13:30:56] <skunkworks> seb_kuzminsky: did you see my first commit? Huh?
[13:32:02] <cradek> it was a thing of beauty
[13:32:22] <cradek> no unnecessary changes, no whitespace weirdness
[13:32:37] <cradek> you should venture forth and make a second bugfix commit
[13:32:51] <skunkworks> well - I hear all the complaining.. :)
[13:34:01] <skunkworks> it seems like a slippery slope..
[14:09:12] <lair82> Is what mhaberler mentioned on the machinekit thread related to my issues? What you guys are talking about sounds like the tool patch and the whitespace errors I get when applying it to my builds.
[14:13:41] <cradek> reading back -- looks like you got a answer about your misspelled arrows. what memory leak issue? is there a bug report for it?
[14:15:24] <lair82> I was posting on the users list, sorry about that.
[14:16:16] <lair82> I was not able to nail down though if it was in fact a memory leak
[14:24:08] <lair82> The link to get to the users archive is not working on the linuxcnc community page to repost what I was talking about. We notice through out the day that making changes to the tool table, namely the "wear offsets, tools 10001 etc" will gradually start slowing down the control until the point that it freezes solid and we have to force a restart on the pc and start all over again
[14:25:09] <cradek> you could run top and see if something is growing
[14:26:11] <lair82> It will run all day without issue if they dont make any changes to that table. "micges" said it was possibly a memory leak, and I started watching memory consumption and didnt really notice any thing out of the ordinary comparing a machine that had been on for days, and a freshly retarted control
[14:26:42] <cradek> how did you watch it?
[14:27:27] <skunkworks> wear offsets? is that part of rogges patch/
[14:27:40] <lair82> using top, I did notice in the system monitor that CPU was always running at or near 100% even with linuxcnc idle
[14:28:06] <cradek> skunkworks: yes he must be running some kind of modified linuxcnc
[14:28:16] <lair82> Yes this is rogges patch,
[14:28:17] <cradek> cpu at 100% is abnormal. what is using it?
[14:28:38] <lair82> Gscreen was running in 65-70% range
[14:29:26] <cradek> running 2.5 I have milltask 4%, axis 2%
[14:29:34] <lair82> only 1 maybe 2 other processes running when i looked at it everytime, system monitor alone would run at 10-15%
[14:29:38] <cradek> I have not tried gscreen
[14:30:11] <cradek> does your configuration have a base thread?
[14:30:25] <lair82> We switched to gmoccapy to see if it would make a difference.
[14:30:30] <lair82> yes
[14:30:46] <cradek> it can be easy to use up the cpu with overly-taxing thread settings
[14:31:12] <cradek> gmoccapy and gscreen are the two least-well-tested UIs; they are brand new
[14:32:08] <cradek> so you are using several things I don't know much about
[14:33:45] <lair82> actually my bad, I do not have a base thread listed in my INI file, only a servo period, it is 1250000
[14:34:14] <skunkworks> odd servo period...
[14:34:25] <skunkworks> why 1250000?
[14:35:25] <lair82> honestly, I couldnt tell you, I think the default is 1000000, I tweaked it a little to see if that would help.
[14:36:11] <lair82> Front and center, I know just enough to very dangerous with LinuxCNC. LOL
[14:38:09] <lair82> I dont build from PNCconfig, where base thread is input (I believe) i build straight from master
[14:40:12] <lair82> We use resolvers for feedback thru a mesa 7i49, so PNCconfig is not that handy for us.
[14:40:17] <cradek> from the little you've told me I suspect a gscreen problem if it takes all your cpu while idle
[14:40:46] <cradek> if you don't have a base thread and your cpu is reasonable, that is
[14:40:57] <cradek> what's your cpu?
[14:42:27] <lair82> We use Gigabyte boards, GA-D525TUD, Intel NM10/rev.1.4 Atom D525
[14:42:35] <cradek> halcmd show thread will show you how much time your thread is taking. you can use that to get an idea how much cpu you should have left over
[14:42:47] <cradek> ah ok, so a little underpowered but not bad
[14:43:02] <cradek> I'd check halcmd show thread, next
[14:43:15] <cradek> mine shows period 1000000, time to execute 32991
[14:43:23] <cradek> so clearly I have a lot of cpu left over for nonrealtime stuff
[14:44:26] <lair82> Heading out there now, what is a good board?
[14:44:44] <cradek> really those should be fine. lots of people are using them.
[14:44:59] <cradek> if you were running complex kins, maybe not, but these are just lathes right?
[14:48:36] <lair82> Period 999969 Time 1001331, Max Time 1206999
[14:48:48] <lair82> Looks upside down to me???????
[14:48:49] <cradek> whoah
[14:49:11] <cradek> what all is in your thread? anything weird?
[14:51:00] <lair82> 30 Items,
[14:51:49] <lair82> Nothing I see as crazy, but I could be in the parking lot, behind Left field, not even in the game.
[14:52:04] <skunkworks> cradek: I think those are in clocks.. (unless seb changed it)
[14:52:30] <KGB-linuxcnc> 03Norbert Schechner 05master 1d53333 06linuxcnc 10configs/sim/gmoccapy/gmoccapy_lathe.ini 10configs/sim/gmoccapy/lathe.tbl 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_1_5_3 - bug in NO_FORCE_Homing handling * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1d53333
[14:53:23] <lair82> I will have to pastebin a screenshot in the morning, end of my shift, I will pick back up tomorrow.
[14:53:25] <lair82> Thansk
[14:53:35] <lair82> Thanks for the help guys
[14:53:43] <cradek> ok, goodnight
[14:54:09] <cradek> Realtime Threads:
[14:54:09] <cradek> Period FP Name ( Time, Max-Time )
[14:54:09] <cradek> 1000000 YES servo-thread ( 18045, 77690 )
[14:54:26] <cradek> skunkworks: mine sure looks like they're times
[14:55:09] <skunkworks> I knowit says time... but I am pretty sure that it is clocks...
[14:55:25] <cradek> I thought you could get runtimes for each func
[14:56:22] <skunkworks> we went through this a few months back when we where playing with the 7i80.. on one of my systems - the max time was higher than the servo period. (and no realtime delays...)
[14:56:58] <skunkworks> but I think seb was going to change it in master maybe. let me see if I can find the conversation
[14:57:06] <skunkworks> logger[mah]:
[14:57:06] <logger[mah]> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-05-28.html
[14:57:17] <cradek> hmm, and I'm running sim so I guess it might be different
[14:57:36] <KGB-linuxcnc> 03Norbert Schechner 052.6 86fcfc8 06linuxcnc 10configs/sim/gmoccapy/gmoccapy_lathe.ini 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_1_5_3 - bug in NO_FORCE_HOMING handling * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=86fcfc8
[14:58:46] <cradek> (sigh)
[15:03:11] <skunkworks> I can't find it..
[15:09:23] * seb_kuzminsky hides under his desk
[15:10:03] <seb_kuzminsky> JT-Shop_: thanks for the docs fix, that was quick!
[15:10:25] <seb_kuzminsky> do you want to close #377 or should i?
[15:17:47] <JT-Shop> seb_kuzminsky, did I fix a bug?
[15:18:09] <seb_kuzminsky> the comp docs thing, wasn't that you?
[15:19:11] <JT-Shop> yes, but I didn't know there was a bug report on it, I just picked it up from the mailing list
[15:19:43] <seb_kuzminsky> heh
[15:19:45] <seb_kuzminsky> cool
[15:21:24] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 d4498c7 06linuxcnc Merge remote-tracking branch 'origin/v2.5_branch' into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d4498c7
[15:22:22] <micges1> cradek: skunkworks: those times in halcmd are cpu ticks
[15:23:03] <JT-Shop> I've never cleared a bug do you need special permissions to do that?
[15:23:06] <micges1> I remembered it like skunkworks, but also just checked source to be sure
[15:23:44] <CaptHindsight> I was asking in the other channel about what to do for UI on Linuxcnc controlled machines that are not machine tools
[15:23:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master a3fb929 06linuxcnc Merge remote-tracking branch 'origin/2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a3fb929
[15:23:59] <CaptHindsight> wire bending, rope cutters, pick-n-place etc etc
[15:24:14] <seb_kuzminsky> JT-Shop: i think you need some special permissions on sourceforge, but i'm not sure...
[15:24:15] <CaptHindsight> I was looking at open source SCADA as well since they have the GUI builders and the backends with drivers for instrumentation and process contro
[15:24:36] <CaptHindsight> what do you guys think? Try to use some open SCADA tools for custom GUI's or maybe write a tool to make customizing AXIS easy, or???
[15:25:07] <seb_kuzminsky> JT-Shop: if you go to
http://sf.net/p/emc/bugs/377, do you see an Edit button in the top right of the bug?
[15:26:03] <seb_kuzminsky> CaptHindsight: you might try gscreen instead of axis as the foundation for your custom ui, i think it's designed for extensibility like that
[15:26:13] <seb_kuzminsky> cmorley would be a good person to ask
[15:26:36] <CaptHindsight> seb_kuzminsky: yeah, was looking at gscreen earlier today
[15:27:23] <seb_kuzminsky> how did it look? i haven't used it
[15:28:15] <CaptHindsight> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Gscreen it's neat!
[15:30:06] <JT-Shop> seb_kuzminsky, like near the Labels:?
[15:31:03] <seb_kuzminsky> JT-Shop: yeah, just above labels, on the right side of the title bar of the bug
[15:31:21] <seb_kuzminsky> you probably have to be logged in to SF, and your account has to have some kind of special permissions that you can get from cradek
[15:31:28] <JT-Shop> no, I don't see it
[15:31:40] <seb_kuzminsky> or you can ping me on irc and i'll do it ;-)
[15:32:07] <JT-Shop> I see your listed as developer-bug maintainer and I'm listed as developer
[15:32:16] <JT-Shop> but I'm not logged in
[15:32:28] <seb_kuzminsky> SF is so baroque
[15:33:05] <seb_kuzminsky> i just closed it
[15:33:15] <JT-Shop> ok, great
[15:33:55] <JT-Shop> lol trying to remember my login name
[15:42:29] <JT-Shop> seb_kuzminsky, after logging in I see the Edit button
[15:44:40] <seb_kuzminsky> makes sense
[15:49:32] <JT-Shop> I need to get more in tune with the bug tracker
[15:49:45] <cradek> do you have the access you need?
[15:52:50] <JT-Shop> yes
[15:53:38] <skunkworks> http://www.machsupport.com/forum/index.php/topic,27120.msg192941.html#msg192941
[15:53:54] <skunkworks> (emc is still dormant...)
[15:54:50] <CaptHindsight> hehe dormat
[15:55:05] <CaptHindsight> cheek speeling
[15:56:29] <skunkworks> heh
[16:05:01] <cradek> "industry standards!!"
[16:07:02] <cradek> http://www.machsupport.com/wp-content/uploads/2013/05/Try-Before-Buy2.jpg
[16:11:08] <JT-Shop> when you close a bug mark it closed-fixed or just closed?
[16:11:24] <cradek> if you fixed it, use closed-fixed
[16:11:28] <JT-Shop> ok
[16:11:53] <JT-Shop> yea I closed a fixed bug
[16:12:15] <cradek> yay
[16:27:09] <cradek> how about this: when you call G43, if the H number is composite, it sums all the tool offsets of the prime factors
[16:27:48] <cradek> so you can load arbitrarily many tool offsets at the same time with one command
[16:28:46] <cradek> so you simply have to use prime tool numbers
[16:29:29] <cradek> hm, wonder if H4 should double T2's offset
[16:29:39] <cradek> I have to work on this proposal some more
[23:16:27] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6-comp-name-check 09b5704 06linuxcnc 10src/hal/utils/comp.g comp: reject .comp files whose names dont match the component name * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=09b5704
[23:16:27] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6-comp-name-check 7b36721 06linuxcnc 10(5 files) tests: verify that comp rejects .comp files whose names dont match the component name * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7b36721
[23:16:37] <seb_kuzminsky> cradek: do you want 2.6-comp-name-check in 2.5? otherwise i'll put it in 2.6
[23:16:56] <seb_kuzminsky> it makes comp error out if the filename doesnt match the component name, as andypugh suggested
[23:17:49] <seb_kuzminsky> it would have prevented the problem leonardo marsaglia ran in to the other day
