#emc-devel | Logs for 2008-03-10

Back
[01:58:06] <cradek> jepler: can't read "::on_any_limit": no such variable
[01:58:16] <cradek> I've been getting this for a while in trunk but keep forgetting to say something
[01:58:22] <cradek> this is trunk sim/lathe
[02:04:45] <SWPLinux> did anyone (cradek) look at the G33 issue today
[02:04:48] <SWPLinux> ?
[02:04:58] <jmkasunich> which one?
[02:05:07] <SWPLinux> either, I guess
[02:05:12] <SWPLinux> but more related to the F0 one
[02:05:19] <jmkasunich> cradek and I (mostly cradek, I'm trying to help Ito) are looking at the bobble one
[02:05:26] <SWPLinux> (since that's the one I could posibly claim familiarity with)
[02:05:31] <SWPLinux> ok, cool
[02:16:22] <jepler> cradek: huh, I don't -- looking to see if I have something uncommitted in my tree..
[02:16:44] <jepler> I don't see anything
[02:18:25] <cradek> I get it as soon as I start trunk sim/axis with emc -l
[02:18:46] <cradek> actually I'm getting this constantly (every update?)
[02:21:01] <cradek> my 'override limits' is not greyed out. I think it should be
[02:22:23] <jepler> maybe I haven't run "make" lately; hold on
[02:22:28] <jepler> do you have any local mods in your configuration files?
[02:22:46] <jepler> if you didn't add limit switches to your sim configuration, you shouldn't see the Override Limits button at all
[02:23:32] <cradek> no changes in configs/sim
[02:24:33] <jepler> you did say trunk, right?
[02:24:40] <cradek> yes
[02:25:16] <SWPLinux> I don't see it here, FWIW (sim on 7.10)
[02:25:24] <jepler> cradek: is there more to the error message?
[02:25:29] <jepler> (I'm also sim on 7.10 fwiw)
[02:25:33] <cradek> yes hang on
[02:26:07] <cradek> http://pastebin.ca/936053
[02:30:23] <jepler> too bad I'm too lazy to turn on my 6.06 machine and try it there
[02:30:57] <jepler> cradek: remind me tomorrow and I'll see if I can reproduce it in the office
[02:33:13] <cradek> ok, thanks
[02:37:53] <cradek> jmkasunich: I'm not having much luck. I can change it, but not eliminate it
[02:38:32] <jmkasunich> I was looking at the code, but without knowing a bit about how blending works I'm kinda lost
[02:39:02] <cradek> I can't get results as bad as you did - I changed my accel to 8 but it looks about the same
[02:39:56] <jmkasunich> you mean as bad as the results on my lathe?
[02:40:19] <cradek> yes
[02:40:41] <jmkasunich> I'm thinking this is some kind of a timing thing
[02:40:54] <jmkasunich> because the lathe program has 26 consecutive G33s
[02:41:19] <jmkasunich> I get that severe bobble between #1 and #2, then several that are smooth, then one spot that sometimes has a smaller bobble and sometimes doesn't, etc
[02:41:35] <jmkasunich> the severe bobble happens every time though
[02:41:54] <cradek> anything different about the 1-2 blend?
[02:42:20] <jmkasunich> the "sometimes has and sometimes doesn't" case isn't neccesarily random - I'm comparing consecutive passes at different depths, not the same pass in subsequent runs
[02:42:48] <jmkasunich> re 1-2, nothing jumps out at me
[02:43:34] <jmkasunich> except that segment 1 is the first one, of course
[02:45:03] <jmkasunich> http://jmkasunich.com/pics/threading-bobble.png
[02:45:21] <jmkasunich> the bobble between the 14 and 15 buttons is another one I think
[02:45:48] <jmkasunich> its hard to tell exactly where it is in the program - there are several segments of the same pitch
[02:45:59] <jmkasunich> some things about that trace seem wrong though
[02:46:00] <fenn> between which ones does the pitch change?
[02:46:06] <cradek> I get a slight disturbance but it only lasts a couple servo cycles
[02:46:22] <jmkasunich> you mean in sim?
[02:46:23] <cradek> I think it's just imperfect blending and it would get better with a faster servo rate
[02:46:26] <cradek> yes
[02:47:27] <jmkasunich> for me, the sim bobble lasts from 0.658 to 0.736
[02:47:48] <fenn> jmkasunich: notice the dip just after the move starts? right above the 5 button
[02:47:57] <fenn> does that also count as a bobble?
[02:48:17] <jmkasunich> fenn: thats an overshoot, as the axis tries to match velocity with the spindle
[02:48:45] <jmkasunich> the one at 7-8 is the bobble - that is between two segments that have the same pitch, and should blend smoothly
[02:48:56] <jmkasunich> oh, I just thought of something
[02:49:44] <jmkasunich> can't tell
[02:49:53] <jmkasunich> I was wondering if segment 2 was very short
[02:50:23] <cradek> good question
[02:50:34] <cradek> that might be a problem
[02:50:36] <fenn> it looks to be about 0.1"
[02:50:49] <cradek> your gun is smoking
[02:51:05] <jmkasunich> I dunno where fenn is getting 0.1"
[02:51:21] <fenn> the halscope screenshot (200m/div)
[02:52:59] <jmkasunich> I'm pretty sure the scope pic corresponds to the following g-code:
[02:53:12] <jmkasunich> G0X[0.077250]Z[1.685525+0.100000]
[02:53:12] <jmkasunich> G33K0.032000X0.077250Z1.685525
[02:53:12] <jmkasunich> G33K0.032000X0.077250Z1.520525
[02:53:12] <jmkasunich> G33K0.030000X0.077250Z1.489525
[02:53:12] <jmkasunich> G33K0.028000X0.077250Z1.460525
[02:53:13] <jmkasunich> G33K0.026000X0.077250Z1.433525
[02:53:15] <jmkasunich> G33K0.025000X0.077250Z0.958525
[02:53:17] <jmkasunich> G33K0.026000X0.079250Z0.919525
[02:53:19] <jmkasunich> G33K0.027000X0.083350Z0.892525
[02:53:21] <jmkasunich> G33K0.029000X0.092050Z0.863525
[02:53:42] <jmkasunich> note the monotonically decreasing pitch
[02:53:43] <cradek> so you have several .03" moves
[02:53:57] <jmkasunich> yet the Z vel above the 13 button increases
[02:54:53] <cradek> motion slow down for a short segment will cause position error to wind up, commanding a higher velocity
[02:55:19] <cradek> when you finally get to a longer segment, it will catch up
[02:55:28] <cradek> or on your machine, probably overshoot like that initial move
[02:55:55] <jmkasunich> I need a way to halscope this such that I can tell where each segment begins and ends
[02:56:05] <cradek> motion.active_whatever
[02:56:27] <cradek> motion.program-line
[02:56:36] <cradek> knew it was in there somewhere
[02:56:40] <jmkasunich> dang - I also need to walk the dog - he's whining
[02:57:01] <jmkasunich> and its almost 11pm on a work day - I'll resume this tomorrow evening
[02:57:07] <jmkasunich> thanks for looking at it
[02:57:12] <cradek> sure
[02:57:15] <cradek> goodnight
[02:57:20] <jmkasunich> goodnight
[02:57:27] <cradek> do check program-line
[12:39:31] <jepler> cradek: I don't get that error on trunk / ubuntu 6.06 / sim either
[12:40:21] <CIA-22> EMC: 03jepler 07TRUNK * 10emc2/docs/man/man1/ (halsampler.1 halstreamer.1): note that these programs can use a file instead of stdin/stdout
[12:41:43] <CIA-22> EMC: 03jepler 07TRUNK * 10emc2/scripts/runtests: diff -y format is more compact and I found it useful in reviewing test failures
[12:46:12] <CIA-22> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: do not warn that a file was 'modified' when it doesn't exist
[13:15:55] <skunkworks> logger_dev: boomkark
[13:15:55] <skunkworks> I'm logging. I don't understand 'boomkark', skunkworks. Try /msg logger_dev help
[13:15:59] <skunkworks> logger_dev: bookmark
[13:15:59] <skunkworks> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-03-10.txt
[13:18:55] <cradek> jepler: well crap, I don't either this morning. Maybe *I* wasn't up to date. I'll check more carefully tonight.
[13:22:58] <alex_joni> skunkworks: boomkark?
[13:23:32] <fenn> BOOM KARK
[13:27:27] <skunkworks> :) fingers are not working well this morning.. Too much tile work this weekend.
[13:33:41] <skunkworks> jepler: http://www.cnczone.com/forums/showthread.php?p=422838#post422838
[14:06:47] <SWPLinux> boom shakalaka laka boom she boom KARK!
[14:16:34] <jepler> skunkworks: there are also some relevant fixes in the unreleased emc 2.2.4.
[14:16:38] <jepler> it should be out this weekend
[14:16:44] <jepler> the estop thing sounds like something I don't know about, though
[14:17:00] <jepler> to be specific, * stepconf: fix "Both Limit"-type inputs (SF#1906640)
[14:18:00] <jepler> hm except he is referring to home input, not limit..
[14:19:05] <cradek> Is il possible to use emc2 whit a Fanuc, but i dont now what sort of fanuc it is.
[14:22:27] <skunkworks> I don't get it either..
[14:22:46] <jepler> "It just runs the Z motor till it hits the software position and then it does X and Y.
[14:22:49] <jepler> "
[14:22:54] <jepler> anybody understand what that means?
[14:23:26] <cradek> I don't understand "the software position"
[14:23:37] <cradek> but I think he's getting a homing sequence
[14:24:46] <jepler> Subject: Incredible solution for smallsized babymakers!
[14:27:06] <skunkworks> heh - they keep trying to find new ways to say 'penis enlargement'
[14:31:27] <skunkworks> Translation: I have heard that emc will work with fanuc cam posts.. Which fanuc post will work?
[14:31:40] <skunkworks> ;)
[14:34:31] <jepler> http://pastebin.ca/936569
[14:49:27] <jepler> anybody spot the problem yet? I haven't.
[14:50:39] <cradek> maybe his switches are inverted. It would seem to act funny (trying to move off the switch)
[14:53:27] <skunkworks> Should I have him halscope the signals to make sure they are getting into the computer?
[14:54:06] <jepler> skunkworks: he said he did ...
[14:54:11] <skunkworks> nevermind - he said he did
[14:54:13] <skunkworks> heh
[14:54:36] <cradek> wonder if he would notice inversion
[14:54:44] <cradek> I should probably read the message.
[15:00:05] <micges> jepler: I saw simmilar problems
[15:00:25] <micges> but I must go now becouse have transport to home
[15:00:42] <micges> back in 3 hours
[15:01:08] <micges> I will be have example of *.hal
[15:01:10] <micges> bbl
[15:39:06] <skunkworks> cradek: http://www.cnczone.com/forums/showpost.php?p=422875&postcount=27
[15:50:28] <jepler> yeah whatever
[15:51:25] <skunkworks> :)
[15:52:45] <cradek> yeah whatever
[15:53:11] <skunkworks> not worried??
[15:54:04] <cradek> I'd like to read the patent. I wonder if he can back up his threats with a patent number I can search for
[15:58:34] <skunkworks> how would you ask without bringing attention to yourself? :)
[15:59:38] <jepler> I have read some programmers who think it's better not to read patents (that are in force) though not being aware of the patented methods isn't a defense against infringement claims as far as I know.
[16:05:36] <jepler> Features - FANUC Series 30i/31i/32i - CNC - Product - FANUC
[16:05:36] <jepler> Tool center point control for 5-axis machining (Patent pending)
[16:05:49] <jepler> -- top hit on google search for '5-axis tool compensation patent'
[16:06:35] <jepler> there are several other claims of patent or patent pending on these methods
[16:06:57] <cradek> I guess that's not surprising
[17:48:59] <micges> logger_dev: bookmark
[17:48:59] <micges> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-03-10.txt
[18:42:26] <micges> as I said: http://pastebin.ca/936892 this doesn't work
[18:44:21] <micges> no signal on pos-lim or home-lim
[18:49:05] <cradek> did you add not.5 to a thread?
[18:50:46] <micges> yes
[18:52:31] <micges> this works: http://pastebin.ca/936921
[18:57:22] <cradek> oh are you saying there is a problem with how "net" works? I did not see your original report
[19:00:05] <micges> sorry if I assumed that you readed my message, about 4h ago, when someone on cncforum said that his generated hal file doesn't work
[19:00:28] <micges> I saw simmilar lines in my too and I mentioned that
[19:01:20] <micges> yes problem with NET command
[19:19:02] <jepler> does the output of 'show net STOPX' differ for the two snippets you showed?
[19:19:41] <jepler> when I run something similar to your first form (the one you say doesn't work) the output of 'show net' seems correct. http://pastebin.ca/936956
[19:22:00] <jepler> and it works as I expect, too. http://pastebin.ca/936962
[19:23:20] <jepler> (there was also a 'halcmd: start' that I didn't put in the paste, oops)
[19:23:49] <micges> ok I see
[19:26:55] <micges> jepler: 1 hal, machine can't see home and pos limits, hit to border metal
[19:27:06] <micges> jepler: 2 hal machine works ok
[19:27:21] <micges> I saw that your test works fine
[19:27:52] <micges> must make more tests
[19:28:13] <micges> (write down to not forget)
[19:29:10] <micges> oh that was on shared switches, that is important in any way ?
[19:30:33] <micges> home and limit switch are the same hardware pin
[19:32:50] <micges> jepler: can I ask for the feature on axis:
[19:32:50] <micges> axis.py
[19:38:02] <micges> (making feature reqest)
[19:41:00] <micges> (sf.net not working)
[19:43:01] <micges> reqest is: will be nice in axis have global table of mdi commands that will be wexecuted after stop of program and naother table thaT will be executed before task_run
[19:43:34] <cradek> that is not a function of the gui
[19:44:05] <micges> table will be default empty and if I want I will fill table in .axisrc
[19:44:39] <micges> why not?
[19:45:26] <cradek> they are unconnected. why should an xemc user not have that functionality?
[19:46:12] <cradek> maybe you could back up and explain the problem you are trying to solve, instead of your proposed solution, which is not well thought-out
[19:48:14] <micges> I've configured 6 machines with that solution and it work quite good
[19:49:09] <micges> and problem is: I want emc when running file was in mode M50 P1, after stop I want to be in mode M50 P0
[19:49:40] <micges> (the simplest problem)
[19:53:45] <cradek> it sounds like you don't want FO to affect jogs? is that the actual problem?
[19:54:04] <micges> cradek: I dont understand this, can you clearer: "they are unconnected. why should an xemc user not have that functionality?"
[19:54:29] <cradek> brb
[19:54:33] <micges> yes that is one problem from about 10
[19:55:55] <jepler> cradek means that it is the function of the program "task" to take care of changes in machine state that should occur when an operation like "run program" is requested by the GUI.
[19:56:06] <jepler> not the function of the GUI
[19:56:28] <jepler> one reason is because the machine should "work the same" whether the GUI is axis, xemc, or another program.
[19:57:19] <micges> ah thanks
[20:04:05] <micges> If we not divide to GUI/ non GUI functionality then:
[20:04:07] <micges> problem 2: with this functionality we may also solve problem of no switching spindle when start from middle of program, just add line "M04" to the start_table
[20:54:11] <alex_joni> micges: not really.. then you always start the spindle
[20:54:24] <alex_joni> even if the program is actually an elaborate tool-change program
[20:54:46] <alex_joni> the real fix is remembering the state while skipping through the program
[20:55:09] <alex_joni> micges: you can define some MDI codes to be used with halui
[20:55:21] <alex_joni> then you can link some pin to the halui command
[21:02:02] <micges> alex_joni: how ?
[21:03:35] <alex_joni> not sure :)
[21:12:19] <alex_joni> good night all
[21:14:40] <micges> night alex
[21:14:43] <cradek> halui mdi is described in the docs (development version, not released 2.2)
[21:16:51] <jepler> the feature is only in the development version as well?
[21:17:00] <jepler> http://linuxcnc.org/docs/devel/html/gui_halui.html#r1_2_14
[21:17:34] <cradek> yes that's what I meant to say
[21:18:01] <cradek> I am wrong, it's in 2.2
[22:03:32] <micges> hal mdi works
[22:04:09] <micges> and you have the idea how to use it to solve problem 1 (or 2) ?
[22:33:35] <micges> good night