Back
[02:44:41] <jepler> it's a pity that the kernel folks are actively hostile to the idea of C++ in kernel space.
[02:46:17] <SWPadnos> are you serious?
[02:46:52] <SWPadnos> I only ask because you sometimes seem to be hostile to C++ in any space :)
[02:47:00] <jepler> well that's true too
[02:47:05] <SWPadnos> heh
[02:49:44] <jepler> a class which overrides 'operator=' and 'operator double' would make it possible to write hal code using floats without sacrificing nice syntax like 'out = in * scale + gain'
[02:49:57] <jepler> er, "write hal code using doubles"
[02:50:05] <SWPadnos> hmm
[02:50:21] <SWPadnos> there's still the non-blocking atomicity to contend with
[02:50:36] <SWPadnos> but I agree in principle - there are a lot of places where HAL would benefit from c++
[02:50:43] <jepler> sure, you have to *write* the code that goes inside 'operator=' and 'operator double'
[02:51:01] <SWPadnos> it's already relatively strongly typed, and having the compiler help with checking that stuff would be a big bonus
[02:51:41] <SWPadnos> there's supposed to be a "C++ in kernel space" option for RTAI - I don't know how well it works
[02:51:52] <jepler> yes -- I also see that option is present
[02:55:41] <jepler> I also found this but didn't get anywhere useful.
http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-09/4806.html
[02:57:33] <SWPadnos> there's a bit of useful information in Sam Ravnbourg's reply
[02:57:41] <SWPadnos> -u
[02:59:29] <SWPadnos> did you see this:
http://netlab.ru.is/exception/LinuxCXX.shtml
[03:05:29] <jepler> dear god, it's a huge patch
[03:05:33] <SWPadnos> heh
[03:05:44] <SWPadnos> it looks like it's very "feature-rich", and probably overkill
[03:05:50] <SWPadnos> with RTTI and exceptions ...
[03:05:54] <jepler> it's twice the size of RTAI
[03:06:08] <jepler> er, the adeos patch, that is
[03:06:20] <SWPadnos> whichever - still big
[03:08:00] <SWPadnos> hmmm. when you built the kernel recently, do you recall if you had any of the "pseudo-RT" stuff turned on?
[03:08:20] <SWPadnos> pseudo-RT being Ingo's patches, the "interruptible kernel" option, etc
[03:08:21] <jepler> (I managed to get the kernel build process to run g++, but then you encounter the fact that the linux headers use 'new' as an identifier, and other things that conflict with C++)
[03:08:52] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/config-2.6.24-12-rtai
[03:09:16] <SWPadnos> yeah - looking at the "using LinuxCXX" page, they have headers to include before and after the kernel headers - I didn't download the patch to look at what magic is done there
[03:09:23] <jepler> looks like I ended up with
[03:09:24] <jepler> CONFIG_PREEMPT_VOLUNTARY=y
[03:09:27] <jepler> CONFIG_PREEMPT_BKL=y
[03:10:18] <SWPadnos> ok - I think that means no "kernel is preemptible" setting - I believe that would be the next one "CONFIG_PREEMPT"
[03:10:35] <SWPadnos> voluntary == cooperative multitasking IMO :)
[03:11:36] <jepler> 'night
[03:11:43] <SWPadnos> see you
[04:05:10] <jmkasunich> are there #variables that contain the current position?
[04:05:50] <cradek> no
[04:06:03] <jmkasunich> there should be ;-)
[04:07:54] <jmkasunich> this program moves about 5" to switch from drill to lathe tool
[04:08:17] <jmkasunich> at startup, it doesn't know where it is, so it has to move in Z far enough out to make sure the drill is clear
[04:08:26] <jmkasunich> then move in X to bring the lathe tool on center
[04:08:39] <jmkasunich> then move back in Z to bring the lathe tool to the work
[04:09:08] <jmkasunich> lots of wasted motion, especially since subsequent runs will be parked much closer to where the tool needs to be
[04:10:38] <cradek> so you could make it better if you'd remember to start in a safe spot
[04:11:41] <jmkasunich> if could use if statements to avoid unneeded movement, but still do the moves if I left it in an unsafe spot, IFF I had access to the current position
[04:12:01] <cradek> 'current position' is complex because of the various sytems and offsets
[04:12:07] <jmkasunich> yes
[04:12:43] <jmkasunich> my idea of "current position" is the one that, if I issue G0<current_pos>, nothing moves
[04:12:53] <jmkasunich> the definition is simple, computing it might not be
[04:13:08] <SWPadnos> are the "analog inputs" available as parameters?
[04:13:20] <SWPadnos> if so, you can loop positions back to those
[04:13:27] <SWPadnos> (no offsets though)
[04:13:32] <cradek> jmkasunich: I bet you could get current position with a clever probing move
[04:13:53] <jmkasunich> or something
[04:14:12] <jmkasunich> not gonna try that elaboration for this project, its just something that I thought of as I wrote the g-code
[04:14:23] <jmkasunich> damn, its after midnight again
[04:14:39] <cradek> g91g38.3z.001
[04:15:11] <jmkasunich> and tomorrow (later today) I'm going to visit family for easter - I may not get to run this until monday
[04:18:11] <jmkasunich> hmm, I dunno what's worse - writing a peck drill loop with O-words, or figuring out how to use the peck drill cycle
[04:18:22] <jmkasunich> "preliminary motion" is confusing
[04:18:50] <cradek> howso? it just goes to "above the hole"
[04:19:27] <jmkasunich> yeah
[04:19:31] <jmkasunich> if only the docs were that clear
[04:19:47] <jmkasunich> I've already coded a G0 to "above the hole, at safe height" anyway
[04:19:54] <jmkasunich> all I want is the pecking
[04:23:49] <jmkasunich> G83F0.66 Z<final_depth> R<safe_depth> Q0.05 seems like a start
[04:24:40] <cradek> tiny tiny hole?
[04:24:46] <jmkasunich> 13/32
[04:25:07] <jmkasunich> but in steel, and I don't have a feel for how it will cut
[04:25:13] <SWPadnos> seems you should be able to go much further than 0.050 per peck (if that's what Q is)
[04:25:16] <jmkasunich> I'll probably increase things on every part till I like it
[04:25:22] <SWPadnos> heh
[04:25:34] <cradek> yeah chips will come out of a drill that big, you shouldn't need to peck much
[04:25:50] <jmkasunich> because I don't have variable spindle speed, my speed and thus my feed is quite slow
[04:26:01] <cradek> it's hard to know how to drill without feeling it cut
[04:26:05] <jmkasunich> speed is set based on the facing
[04:26:06] <jmkasunich> right
[04:26:19] <jmkasunich> so I start gentle and get more aggressive as I go along
[04:26:34] <jmkasunich> this isn't work hardening material, so I don't have to worry about that
[04:27:06] <cradek> to set up a program for so many, I'd cut one by hand with the tailstock and time it
[04:28:47] <jmkasunich> "Y value unspecified in XY plane canned cycle"
[04:29:02] <cradek> you surely want g18
[04:29:04] <jmkasunich> what is Y on a lathe?
[04:29:10] <jmkasunich> I have G18
[04:29:18] <jmkasunich> maybe I didn't copy the message verbatim
[04:29:26] <cradek> the question is what is the XY plane on a lathe...
[04:29:38] <cradek> you must not have G18 if you got that message
[04:29:39] <jmkasunich> the message said XZ plane, sorry
[04:30:08] <cradek> Y unspecified in XZ cycle?
[04:30:09] <jmkasunich> actually, I bet I can't use G83
[04:30:15] <cradek> hmmmm
[04:30:22] <jmkasunich> if the cycle is in the ZX plane, depth is Y
[04:30:31] <cradek> yeah I'm seeing that now too
[04:30:59] <cradek> so you need to be in G17 to peck Z
[04:31:06] <jmkasunich> as long as I don't to any arcs with the lathe tool (I don't), I bet I can (and need to) set G17
[04:31:09] <cradek> I wonder if it will require a (disallowed) Y word
[04:31:34] <cradek> yep I think it'll work
[04:32:03] <jmkasunich> it loaded anyway
[04:34:41] <jmkasunich> running it with no drill in the chuck first
[04:36:45] <jmkasunich> well thats odd
[04:37:07] <jmkasunich> the retract after the very first peck caused a following error
[04:37:39] <cradek> in which joint?
[04:37:45] <jmkasunich> 2 Z
[04:38:15] <jmkasunich> it started back really quick - but I'd need halscope to see how quick
[04:38:29] <cradek> it should be full rapid
[04:38:52] <jmkasunich> I can do G0s on Z all day, this seemed faster than that
[04:38:53] <cradek> cycles are done in exact stop mode so you may be getting twice the accel you're used to (same as you get when jogging)
[04:39:35] <jmkasunich> if it wasn't 12:39 I'd look into it
[04:39:38] <cradek> cycles on lathe might not be very well tested...
[04:39:47] <cradek> yeah I'm interested to hear what you find.
[04:39:58] <jmkasunich> I have to be showered, dressed, breakfasted, and on the road at 11am tomorrow, so I'm gonna call it a night
[04:40:05] <jmkasunich> (still have to walk the dog too)
[04:40:14] <cradek> goodnight
[11:44:39] <alex_joni> jepler: I notice 3 messages while running emc2 TRUNK on sim:
[11:44:46] <alex_joni> shmctl: Invalid argument
[11:45:08] <alex_joni> (this is on shutdown, configs/sim/axis, on dapper, configured --enable-simulator)
[11:45:13] <alex_joni> any ideas what to debug?
[12:10:07] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/docs/src/config/ini_config.lyx: move RS274NGC_STARTUP_CODE to [RS274NGC], currently it's still valid in the old location aswell
[12:12:40] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: move RS274NGC_STARTUP_CODE to [RS274NGC], currently it's still valid in the old location aswell.
[12:12:41] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: move RS274NGC_STARTUP_CODE to [RS274NGC], currently it's still valid in the old location aswell.
[12:21:31] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/debian/changelog: note moving RS274NGC_STARTUP_CODE to [RS274NGC]
[13:01:13] <jepler> alex_joni: imo, only one place in the source would cause that exact message to be printed. src/libnml/os_intf/_shm.c:416: perror("shmctl");
[13:16:18] <jepler> alex_joni: you did something to make lyx unhappy
[13:16:48] <jepler> http://pastebin.ca/953878
[13:19:56] <jepler> by the way, I think you should do it the other way around -- prefer the new, documented setting; use the old, deprecated setting if it's not there
[13:20:06] <jepler> looks like your code prefers the old setting
[13:21:05] <jepler> bbl
[14:07:24] <alex_joni> jepler: just finished lunch, pastebin is down for me :(
[14:08:15] <alex_joni> jepler: I tried to send a emcOperatorMessage() if the [EMC] one is found, but for some reason nothing happened (might be too early in task init), so I left it like this for now
[14:08:31] <alex_joni> I'll move them the other way around, and add a comment
[14:11:34] <alex_joni> cradek: does pastebin work for you?
[14:12:38] <cradek> no
[14:29:49] <cradek> alex_joni: if BJT is seeing a velocity faster than a rapid, it's a bug
[14:30:42] <alex_joni> I agree
[14:31:46] <cradek> I don't think yet another configurable velocity is needed
[14:32:14] <cradek> if his machine can't safely handle a rapid, it's just misconfigured
[14:32:22] <BigJohnT> ok
[14:32:36] <alex_joni> BigJohnT: hi :)
[14:32:41] <BigJohnT> alex_joni: hi
[14:33:01] <BigJohnT> is this the secret place for developers?
[14:33:07] <alex_joni> cradek: I think the "yet another configureable velocity" is indeed needed, at least it makes sense for me
[14:33:09] <cradek> poorly-kept secret if so
[14:33:25] <alex_joni> heh, not really secret .. it's described on the website..
[14:33:31] <BigJohnT> LOL yea if you let me in...
[14:33:42] <alex_joni> BigJohnT: cradek is right, if your machine moves faster than rapid, we need to fix that
[14:34:00] <alex_joni> can you try (again) to grab a halscope snapshot when it happens?
[14:34:12] <BigJohnT> I can't prove it but I can try again
[14:34:16] <alex_joni> ask in here for pointers on setting up halscope :)
[14:34:47] <BigJohnT> ok, I'll have to do it in a little bit
[14:35:51] <BigJohnT> I do know that at vel below about 300IPM it seems to move to home smoother
[14:37:15] <BigJohnT> I have to step out for a bit but will try when I get back
[14:37:26] <BigJohnT> thanks alex_joni:
[14:38:11] <alex_joni> ok
[14:38:41] <alex_joni> BigJohnT: it's not in the code just yet, I still want to discuss it with JMK before even thinking about submitting it..
[14:39:24] <BigJohnT> alex_joni: he didn't like the idea when I asked before...
[14:40:16] <BigJohnT> maybe you can be more diplomatic than I can...
[14:43:46] <alex_joni> BigJohnT: well, depends on the reasons to do this
[14:53:49] <alex_joni> BigJohnT: pastebin.ca/953939
[14:54:03] <alex_joni> jepler: pastebin is up again, I'll see what that index's problem is
[15:01:28] <BigJohnT_> alex_joni: just popped back and I remember from some experiments that I could set the velocity high enough that it would stall the servo during a move to home
[15:01:36] <BigJohnT_> but it would still do a G0
[15:01:49] <BigJohnT_> without stalling
[15:02:20] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/docs/src/config/ini_config.lyx: never ever use index names with _ in them, spaces work fine
[15:02:26] <alex_joni> BigJohnT_: see the patch above (pastebin.ca/953939)
[15:02:30] <alex_joni> gotta run for a while now
[15:02:38] <BigJohnT_> yes looking at it
[15:02:48] <alex_joni> I only tested that it still runs on configs/sim, without a special home_vel
[15:02:55] <alex_joni> bbl
[15:02:58] <BigJohnT_> ok thanks
[15:03:07] <BigJohnT_> me too bbl
[18:11:43] <alex_joni> hi
[18:12:28] <SWPadnos> hi
[18:27:35] <micges> alex_joni: you changed ini settings RS274NGC_STARTUP_CODE
[18:28:39] <micges> I've searched source code to find where to put settings like RS274NGC_START_CODE and RS274NGC_STOP_CODE
[18:29:03] <micges> and no success
[18:29:13] <micges> little help ?
[18:29:56] <alex_joni> micges: you mean things that get executed before and after a program?
[18:30:14] <micges> yes
[18:30:22] <alex_joni> I'm not sure how to do that..
[18:30:30] <alex_joni> especially the after a program part is tricky
[18:30:48] <alex_joni> once you found M2/M30 or whatever, you can't send any more g-codes
[18:30:54] <alex_joni> you need to switch to MDI to do that
[18:31:19] <alex_joni> I think what you want is to wait until lerman allows overloading G and M codes
[18:31:31] <alex_joni> then redefine M2 to include you needed calls
[18:32:21] <micges> any info about lerman works?
[18:32:25] <SWPadnos> use a named subroutine, and change the program end to OM2
[18:32:56] <SWPadnos> have a file called m2.ngc in your nc_files dir, with the needed codes, plus an M2
[18:33:04] <SWPadnos> that should work in TRUNK now
[18:33:27] <micges> ok this is on end of code
[18:33:42] <micges> but what about after pressing escape ?
[18:33:51] <SWPadnos> that's a different thing
[18:34:01] <SWPadnos> and wouldn't work this way :)
[18:34:56] <micges> surely :)
[18:51:33] <alex_joni> micges: then the place you need to put it is in emctaskmain.cc
[18:51:50] <alex_joni> but I still can't see how exactly you can accomplish that..
[18:59:50] <alex_joni> micges: what kind of codes do you want to set?
[19:25:17] <micges> for now one G0 and M50 or M52
[19:29:01] <alex_joni> hmm.. G0 will be tricky after an abort
[19:29:18] <SWPadnos> and it seems M50 and M52 are unnecessary when the machine isn't running
[19:29:33] <SWPadnos> though they do affect MDI as well
[19:29:48] <SWPadnos> I think they do anywat
[19:29:50] <SWPadnos> y
[19:30:09] <alex_joni> those are various overrides.. right?
[19:30:18] <alex_joni> * alex_joni is too lazy to look them up
[19:30:19] <SWPadnos> yes, adaptive feed and FO
[19:30:26] <SWPadnos> * SWPadnos just loked them up :)
[19:30:30] <SWPadnos> +o
[19:30:41] <alex_joni> and I didn't get a nice cheat sheet
[19:30:53] <SWPadnos> I used the in-tar-web
[19:33:06] <micges> point is that machine in program run in "quite complicate mode" and operator want to stop it and check result (which must be done by move machine manually and cant be done in "quite complicate mode") and after that restore executing program from stopped point in state before hitting escape
[19:34:27] <micges> then auto->manual switching must have disabling some hal modules and so on
[19:34:41] <micges> and some M codes too
[19:34:50] <SWPadnos> well, it could be simple, but I don't think so
[19:35:37] <SWPadnos> there is a function that runs when an abort or restart occurs - you could probably change that to run some G-codes when thoseevents occur
[19:35:59] <SWPadnos> (different functions for abort and start, of course)
[19:36:15] <micges> what function you talking ?
[19:36:21] <SWPadnos> I don't know the name :)
[19:36:59] <SWPadnos> but there are functions that get called to deal with any NML messages, and to issue commands to IO and motion (and the interp)
[19:37:32] <SWPadnos> so somewhere there's a line like "case EMC_ABORT_TYPE:" (or similar), with the code to handle an abort
[19:37:53] <SWPadnos> could be a longer/different name, like EMC_INTERP_ABORT_TYPE ...
[19:37:57] <alex_joni> they are in emctaskmain.cc
[19:38:10] <alex_joni> but.. I don't see how you can send g-codes at that state
[19:38:18] <alex_joni> the interp is stopped, aborted
[19:38:26] <alex_joni> so you'll have to trigger a MDI change
[19:38:30] <alex_joni> and send them through MDI
[19:38:31] <SWPadnos> it shouldn't be yet - it should be "aborting" ...
[19:38:33] <SWPadnos> hmmm
[19:39:02] <micges> yes that will be before abort
[19:39:23] <alex_joni> emcTaskAbort9)
[19:39:26] <alex_joni> ()
[19:39:30] <alex_joni> in emctask.cc
[19:39:39] <alex_joni> emcMotionAbort();
[19:39:39] <alex_joni> emcIoAbort();
[19:39:39] <alex_joni> // clear out the pending command
[19:39:39] <alex_joni> emcTaskCommand = 0;
[19:39:41] <alex_joni> interp_list.clear();
[19:39:58] <alex_joni> you *could* hack it with some commands after interp_list.clear()
[19:40:19] <micges> I see this
[19:41:25] <SWPadnos> you would need some way of letting those commands finish before setting the interp state idle though, I think
[19:41:39] <alex_joni> EMC_TASK_PLAN_RUN is the one sent when a user wants to run a program
[19:42:25] <SWPadnos> (this is in src/emc/task/emctask.cc, in case you're looking for it :) )
[20:15:28] <micges> ok I found important places
[20:15:58] <micges> I saw that RS274NGC_STARTUP_CODE is executed by interp.execute command
[20:16:31] <micges> can I use it after abort and before reset emc state ?
[20:28:11] <alex_joni> anyone around?
[20:29:09] <BigJohnT> hi
[20:29:14] <BigJohnT> just got back
[20:29:49] <BigJohnT> how do I use the patch you did for me?
[20:30:02] <alex_joni> patch -p1 < file.patch
[20:30:03] <micges> me too (using alex idea for hacking emc task)
[20:30:09] <alex_joni> you need to be in src/ for that
[20:30:13] <BigJohnT> I searched and only found info on submitting a patch
[20:30:24] <alex_joni> and adjust p1 to some other number if it doesn't work (like p0)
[20:30:45] <BigJohnT> after I patch just run emc?
[20:31:11] <alex_joni> you need to compile first
[20:31:25] <BigJohnT> I kinda thought so
[20:31:27] <alex_joni> aka: make
[20:33:25] <BigJohnT> .
[20:33:45] <BigJohnT> src in my emc2-trunk directory?
[20:34:30] <alex_joni> yup
[20:36:39] <BigJohnT> do I need to copy the patch file to src and name it something special?
[20:36:48] <alex_joni> nope
[20:37:03] <alex_joni> you need to be in src/ and use patch -p1 < /path/to/file.patch
[20:37:25] <BigJohnT> that makes sense
[20:39:02] <BigJohnT> * BigJohnT reading man patch to understand -p
[20:52:54] <micges> alex_joni: putting interp.execute() in fubction emcTaskAbort()
[20:54:24] <micges> after clearing interp list working, but only for Gcode that is executed immadietly (all moving gcodes not working)
[20:54:41] <alex_joni> micges: that's what I would have expected
[20:56:43] <micges> alex_joni: I think that this is very usable , what you thinking ?
[20:58:27] <alex_joni> dunno, you said you want G0 in there..
[20:58:51] <micges> yes but working M52 is half of my success
[21:00:36] <micges> fenn said that G0 can be done somehow in HAL
[21:00:59] <SWPadnos> yes, but it's a Bad Idea
[21:01:13] <alex_joni> no, it's really a *BAD IDEA*
[21:01:56] <micges> ok I get It :)
[21:05:53] <fenn> uh, what?
[21:06:04] <BigJohnT> alex_joni: I managed to get the patch done
[21:06:22] <BigJohnT> and made notes on how to do it...
[21:06:24] <alex_joni> BigJohnT: cool, if it even compiles it's even better
[21:06:48] <alex_joni> fenn: hackish G0 moves in HAL is a bad idea imo
[21:06:49] <BigJohnT> I checked each file to be sure the patch was applied
[21:07:01] <BigJohnT> how do I compile it?
[21:07:03] <alex_joni> BigJohnT: it would have said if something failed
[21:07:15] <alex_joni> BigJohnT: go to src/ and type make? like usually?
[21:08:07] <BigJohnT> ok, I haven't compiled a program in many years...
[21:08:58] <alex_joni> hmm.. I thought you have emc2 compile set up already
[21:09:04] <alex_joni> you need to run configure first
[21:09:06] <BigJohnT> nope
[21:09:29] <alex_joni> go to src/ and type: ./configure --enable-run-in-place
[21:09:34] <alex_joni> then make
[21:09:38] <alex_joni> then sudo make setuid
[21:09:51] <alex_joni> (but ./configure will probably fail ..)
[21:09:59] <fenn> alex_joni: yep, keep motion commands coming from one source
[21:10:19] <BigJohnT> configure worked
[21:10:31] <alex_joni> BigJohnT: what's the last few lines?
[21:10:41] <alex_joni> did it say everything is ok, and you should run make?
[21:10:48] <BigJohnT> configure: error: version.h not found - Is the kernel headers package installed ?
[21:11:09] <alex_joni> well.. as long as you have error's in there, it didn't work :P
[21:11:20] <alex_joni> try: sudo apt-get build-dep emc2
[21:11:23] <BigJohnT> checking /usr/src/linux-headers-2.6.15-magma/include/linux/version.h usability... no
[21:11:47] <alex_joni> that should load a couple of needed things.. might take a while though
[21:12:06] <BigJohnT> it's working
[21:31:25] <CIA-22> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/ini/iniaxis.cc: test branch creation
[21:51:18] <CIA-22> EMC: 03alex_joni 07joints_axes * 10emc2/configs/scara/ (scara.ini scara_sim_4.hal): scara config - doesn't run atm, but eventually the code should support such a config
[22:31:42] <micges> BigJohnT: configure works ?