Back
[08:07:45] <lair82> Good morning gentlemen, I have ran into an issue on one of our turning centers, we keep getting a fault of " Bug: Call stack Underrun" when we try to run a certain program. I am not sure what causes this. Here is a link to the program that is giving us issues,
http://pastebin.com/EfUmTtVm . If this should be on the user channel, let me know.
[08:12:46] <skunkworks> lair82, what version of linuxcnc
[08:21:02] <lair82> skunkworks this machine is running 2.6
[08:27:13] <jepler> that code has g-codes not recognized by stock linuxcnc (m42 is the first one I encountered); this could be a bug in remap, or a bug in the code implementing the machine's specific remap details
[08:28:37] <jepler> so a proper bug submission would require not only the triggering gcode but a "sim" configuration modified with enough of your custom remapped code to reproduce the problem. (by "sim" I mean a configuration which runs without attached hardware)
[08:28:47] <lair82> m42 is my gearchange command, which I checked that stuff, the machine will run any other program just fine, just not this one
[08:29:33] <lair82> We have that m42 in the very beginning of every program. We do most work in high gear, m41 is our low range command
[08:29:35] <jepler> after removing M42 and other nonstandard codes, I end up with
[08:29:42] <jepler> Radius to end of arc differs from radius to start: start=(Z-6.4995,X2.4200) center=(Z-6.5312,X2.4024) end=(Z-6.5056,X2.4362) r1=0.0363 r2=0.0424 abs_err=0.006142 rel_err=14.4866%
[08:29:51] <jepler> N520G03X2.4362Z-6.5056I-0.0176K-0.0317
[08:30:02] <zeeshan|2> looks like an interpolation error to me :P
[08:31:58] <lair82> Thats what I was figuring, G03/G04 problems, after zeeshan mentioned interpolation. Now I have to go get thru the shop supervisors thick skull that his program is crap, and not my turning center!!!
[08:32:10] <lair82> Thanks Guys, :)
[08:33:08] <jepler> that could be true, but it's unclear why you don't get the "good" error message like I do running without remap and just removing your nonstandard codes
[08:33:30] <jepler> that remap code, I know users love it but it's so buggy I wish we had refused to incorporate it in its current form
[08:33:33] <zeeshan|2> lair82: i used to get a similar code when i was using fancy interpolation mode in cam
[08:33:39] <zeeshan|2> i set it back to quadrant mode and it fixed things
[08:33:51] <zeeshan|2> *similar error
[08:35:19] <lair82> I using gmoccapy, if that makes a difference. Do you happen to know what line number in the program it is referencing?
[08:35:30] <jepler> N520 I think
[08:40:09] <jepler> lair82: I do not use gmoccapy. if you are submitting a bug, you would want to determine whether the problem is in fact specific to the UI
[08:42:26] <lair82> No problem there, it's our program, the post processor spits these programs out from time to time with issues like this, and I have seen the fault in the way that you gave it back to me, had I seen that, I would have had this fixed late yesterday. But all I am getting is that call stack underrun.
[08:47:03] <lair82> Speaking of that remap code, here are the links to that m42 code that we use. Is this something that could be done in python, or is the way that I am doing it the best way?
http://pastebin.com/0gF5uz7D http://pastebin.com/qRRuEM5g
[09:23:36] <jepler> linuxcnc gcode has built-in codes to manipulate digital and analog outputs.
http://linuxcnc.org/docs/html/gcode/m-code.html#sec:M62-M65
[09:26:16] <jepler> and personally I'd use a "not" in hal rather than setting two different values
[09:26:28] <jepler> (unless all 4 combinations are actually meaningful)
[09:27:32] <jepler> I don't know enough about remap to say how it's best to use it
[10:43:59] <seb_kuzminsky> i'm switching back and forth between linuxcnc-sim 2.6 and linuxcnc-uspace 2.7~pre debs, and they correctly uninstall each other
[10:44:06] <seb_kuzminsky> so we have that going for us, which is nice
[10:49:37] <seb_kuzminsky> cmorley: did you see the email from Carsten Presser to the emc-users list yesterday? it includes a patch for some typos in pncconf
[11:22:00] <cpresser> seb_kuzminsky: I am baout to post two other fixes.. working on the debian-packaging right now
[11:23:50] <seb_kuzminsky> wow! cool
[11:24:32] <seb_kuzminsky> i can merge the packaging stuff for you, but i really want cmorley's sign-off on the patches that change pncconf - i dont know that code at all
[11:25:02] <seb_kuzminsky> cpresser: are you subscribed to the emc-developers list?
[11:25:23] <cpresser> nope. I am only on emc-users
[11:25:28] <seb_kuzminsky> ah, ok
[11:25:47] <cpresser> I am already involved in to many projects.. right now i am building a machine, thats why I am workign with the code
[11:26:32] <seb_kuzminsky> heh yeah
[11:26:53] <seb_kuzminsky> well, i appreciate that you took the time to report the bugs & send us patches, that's very helpful
[11:27:45] <cpresser> its just my narcism. i want to see my paches in upstream^^
[11:28:31] <cpresser> the basic idea is: i fixed a problem for myself, why not go the extra mile and create a clean patch, so everyone can profit.
[11:30:46] <seb_kuzminsky> that's the noblest definition of narcissism i've heard yet ;-)
[11:33:14] <seb_kuzminsky> if you do yout work in git (see
http://linuxcnc.org/docs/devel/html/code/Contributing-to-LinuxCNC.html), your name will be on the Author: line in out git repo, for all the world to see
[11:33:35] <seb_kuzminsky> regular patches are fine too of course
[11:33:43] <cpresser> i do work with git.. but i am to lazy right now
[11:33:50] <seb_kuzminsky> heh
[11:42:21] <cpresser> okay... the missing pncconf module seems to be a Makefile-isse (install-python-target).
[11:42:43] <seb_kuzminsky> do you know if it works when compiled for run-in-place?
[11:42:54] <cpresser> according to PCW it does
[11:43:21] <seb_kuzminsky> that probably means the module gets installed correctly, but not compied into the debian package correctly
[11:43:28] <cpresser> http://nopaste.info/3dd30ca713.html
[11:43:34] <cpresser> thats from the Makefile.
[11:43:58] <cpresser> in line 10-17 the modules get installed, but _not_ the pncconf modules
[11:44:14] <cpresser> my money is on that. not the debian.files list
[11:46:31] <seb_kuzminsky> hmm
[11:46:45] <seb_kuzminsky> huh, pncconf shebangs python2.4 explicitly, that seems wrong
[11:47:29] <seb_kuzminsky> and it plays tricks with python's libdir at startup time to find its module...
[11:48:07] <cpresser> yep, thats not very nice... i spend some time debugging that^^
[11:48:46] <seb_kuzminsky> so there actually is no pncconf module, just a bunch of submodules that get explicitly pulled in
[11:48:56] <cpresser> proposed (untested!) patch for issue 400:
http://nopaste.info/e89a5979cb.html
[11:49:49] <seb_kuzminsky> *.py seems excessive
[11:50:13] <seb_kuzminsky> the pncconf Submakefile defines PNCCONF_MODULES, that seems like the list to use
[11:50:49] <cpresser> yes... those are copied (by some unknown magic) to /lib/python/pncconf during build
[11:51:18] <cpresser> so .py is safe. its the same for stepconf, ...
[11:51:23] <seb_kuzminsky> ah, i see, yes
[11:53:03] <cpresser> those 3 patches should make pncconf work again. hopfully
[11:53:45] <cpresser> another issue with pncconf is that PID-Tuning is disabled when trying to setup closed-loop-stepper driver. but i wont dig into that
[11:54:15] <cpresser> and its not a big problem.. ppl who want such an unusual setup can do this manually :)
[11:55:25] <seb_kuzminsky> will you attach that latest patch to #400 pls?
[11:55:33] <cpresser> the .hal generated by pncconf when using encoder+stepgen for the same axis are broken.. they have two drivers in the "x-pos-fb" net. one from the stepgen, one from the encoder.
[11:56:29] <cpresser> i dont have a SF.net login. and dont plan to get one. sorry
[11:56:41] <seb_kuzminsky> steppers with encoder feedback are indeed an unusual combination, but i agree if pncconf lets you specify that, then it should emit valid .hal files
[11:56:44] <seb_kuzminsky> ok, i'll do it
[11:56:50] <seb_kuzminsky> logger[psha]: link pls
[11:56:50] <logger[psha]> seb_kuzminsky: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-10-30.html
[12:04:51] <seb_kuzminsky> https://sourceforge.net/p/emc/bugs/401/
[12:05:35] <seb_kuzminsky> cpresser: thanks for the bug report
[12:08:11] <seb_kuzminsky> cpresser: wait, you said 3 patches, but i only count two from you
[12:08:25] <seb_kuzminsky> the private_data.py_typotix.patch that you attached to your email
[12:08:33] <seb_kuzminsky> and the makefile fix that you pasted above
[12:08:38] <seb_kuzminsky> what did i miss?
[12:08:39] <cpresser> one is on the ML, only two lines
[12:09:28] <seb_kuzminsky> oh, i see, it's in the body of the email, not as an attached patch file
[12:09:29] <seb_kuzminsky> got it
[13:20:51] <jepler> cpresser: I don't know if you build kernels, but there's been a kernel patch offered for the /sys "enable" file bug.
https://lkml.org/lkml/2014/10/30/559
[13:22:04] <jepler> I've back-ported the patch to 3.14 and am building a new rt kernel
[13:23:39] <jepler> the patch as I've adapted it for 3.14 is
http://emergent.unpythonic.net/files/sandbox/pci-fix-name-of-enable-sysfs-file.patch
[13:38:53] <jepler> hmm they want to take away our iopl()
https://lkml.org/lkml/2014/10/29/544
[13:40:37] <jepler> with uspace I should test if /dev-based access to the parport is fast enough for epp-style boards
[13:41:06] <jepler> I think that's the only thing that needs iopl (pci stuff doesn't)
[13:55:09] <Tom_itx> mmm plane crashed at our airport today
[13:55:18] <Tom_itx> some of you've been there
[13:55:53] <Tom_itx> hit a flight safety training building
[13:55:58] <Tom_itx> for cessna citations
[14:13:20] <kwallace> Tom_itx, which airport? I'm on this one
http://www.wallacecompany.com/E45/cam2_full.html
[14:15:06] <kwallace> Oh, I got it, Witchita.
[15:11:38] <cpresser> jepler: thanks for the patch. however, i dont want to compile my own kernel. ill rather wait for the patch to hit upstream and get a signed debian package :)
[15:26:18] <seb_kuzminsky> jepler: did you see
https://sourceforge.net/p/emc/bugs/402/
[15:29:58] <jepler> seb_kuzminsky: no, I hadn't.
[15:30:15] <jepler> oh traces of probe_parport are left
[15:30:17] <jepler> we should delete that shit
[15:30:29] <jepler> but on the other hand, software step generation is not gonna work on uspace
[15:31:13] <PCW> well.... i get ~26 usec on Preemt-RT on a haswell
[15:31:28] <seb_kuzminsky> that's pretty good
[15:31:43] <PCW> compiling and running youtube videos
[15:32:07] <jepler> hmmm apparently my debian kernel build on x86_64 builds all of them
[15:32:10] <jepler> it's working on armmp now
[15:33:15] <PCW> and 26 usec is a rare outlier
[15:33:51] <jepler> maybe I misread what was scrolling by
[15:39:59] <skunkworks_> question - when making a python hal componant.. How can you set pins values before it becomes active?
[15:40:23] <seb_kuzminsky> set the pins before calling hal ready?
[15:40:43] <seb_kuzminsky> (i dont know if that works, but that's what i'd try first)
[15:43:58] <jepler> for an output pin you can set a value on it before or after calling ready on the component
[15:44:33] <jepler> I think the ability to set a default value of an unconnected input pin is not present in python. imo it could be added as a new optional value to the "newpin" method of components.
[15:44:34] <skunkworks_> it looks like you can set in pins also from within python.
[15:45:31] <jepler> that's bad :(
[15:45:55] <skunkworks_> I have an issue if my hal componant has 2 lines - loadusr capture and the next line setp capture.blur 1.. It gives me pin not found.
[15:46:07] <skunkworks_> *hal file
[15:46:19] <jepler> you need to use an appropriate -W flag for loadusr to wait for the component to be ready
[15:46:29] <skunkworks_> ah - ok
[15:46:58] <jepler> I agree, there seems to be no write protection of pins in hal module. that's a bug.
[15:53:11] <skunkworks_> -W worked
[18:30:08] <andypugh> Playing more with feed-per-rev and JA6. I get about the right feed rate if I divide the inout to motion.spindle-speed-in by 140.
[18:30:55] <andypugh> (that’s RPM / 8400 in the actual setup I have)
[18:32:06] <cradek> huh, is master wrong too?
[18:32:51] <andypugh> I also found a really good reason _not_ to do a program by looped MDI commands from Python. It’s obvious really, you can’t stop it :-) (well, you can stop one line at a time..)
[18:33:12] <andypugh> If master was wrong people would be complaining, surely?
[18:33:25] <cradek> I bet advanced lathe users are few
[18:33:38] <andypugh> This isn’t a lathe
[18:33:41] <cradek> I really need to exercise lathe features on 2.7 (new tp)
[18:34:02] <cradek> oh ok, no matter, I just think of fpr as a lathe feature
[18:34:23] <andypugh> Yeah, normally, but I am using it on a mill (well, a hobbing machine)
[18:34:57] <andypugh> It would be interesting to try it on a mill running master, just to check.
[19:10:08] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 0ee553b 06linuxcnc 10(12 files in 5 dirs) use /usr/bin/python, not /usr/bin/python2.4 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0ee553b
[20:53:20] <jepler> 2.4 was a particularly excellent python release, I'm sure
[21:01:58] <jepler> .. not quite ten years old. cut down in the prime of its release cycle
[21:49:39] <skunkworks_> how well could you tune a velocity mode servo with 5um scales?
[21:51:28] <skunkworks_> that is about .0002
[21:52:13] <skunkworks_> could you do a lot better if you only used the scale for I?
[22:06:09] <pcw_home> Thats pretty coarse
[22:06:11] <pcw_home> (if the servo needs to keep with 1 mill thats only 5 counts to max error,
[22:06:12] <pcw_home> hard to approximate a linear feedback systen with a 5 count range)
[22:07:59] <skunkworks_> that is what I was figuring.. - have to look for something better
[22:11:08] <pcw_home> might be acceptable for some things (a lot of ~80s bridgeport class machines are like that)
[22:12:45] <seb_kuzminsky> here's also the wtf-worthy sed-ing of our python scripts at install-time to un-2.4-ify them
[22:13:03] <seb_kuzminsky> ... words do what i want them to