Back
[00:34:03] <petev> SWPadnos : u still there?
[01:16:23] <SWPadnos> here for a bit
[01:18:14] <SWPadnos> rayh, you mentioned something about a demo today - how did it go?
[01:19:15] <petev> swp: I was just thinking it may not make sense to export a lot of the interp status in the API
[01:19:27] <SWPadnos> all of it, actually
[01:19:30] <petev> most of it looks like what should be from canon
[01:19:43] <SWPadnos> you need the API to support debugging and setup, so it's all got to be there
[01:19:49] <petev> I don't see much need for a lot of it from interp
[01:19:52] <SWPadnos> (that's one thing I often forget about)
[01:20:05] <petev> hmm, not so sure about that
[01:20:28] <petev> most of the status from interp is the same as canon, but the interp is just further ahead
[01:20:32] <SWPadnos> maybe have a debugging API which is a superset of the "run" API, but there still should be hooks for debug in there
[01:20:50] <SWPadnos> with G-code, yes. with a more high-level interpreter, that may not be so
[01:21:00] <petev> I'll have to think about debug, but I don't think the API is the way to do it
[01:21:29] <petev> I think many of the GUI problems today are because they get interp status instead of canon
[01:21:38] <SWPadnos> there needs to be a debug API, even if it's an optional component to load
[01:21:43] <SWPadnos> could be
[01:21:49] <SWPadnos> Hi jmk
[01:21:55] <jmkasunich> hi
[01:22:04] <petev> what kind of stuff do u want to see in the debug API?
[01:22:07] <petev> hi jmk
[01:22:23] <SWPadnos_> I'm not sure at this point
[01:22:45] <SWPadnos_> (sorry - I'm thinking about other stuff right now - got a friend coming over in a minute)
[01:22:46] <petev> I think usefull interp debug might be writing the blocks out to a file, the parse tree, etc.
[01:22:51] <petev> ok
[01:23:15] <SWPadnos_> or stuff like HALscope gives us - canon spitting out coefficients and the like (like logging)
[01:23:24] <petev> yes, exactly
[01:23:36] <SWPadnos_> ie, look at it when you're debugging a problem, but otherwise it's dormant
[01:23:54] <petev> yes, and doesn't clutter the API so that the wrong status gets used
[01:23:59] <SWPadnos_> also, a sim API would be good
[01:24:13] <SWPadnos_> (not sure exactly what that would be like, but it just occurred to me ;) )
[01:24:15] <petev> I'm going to make two canon classes
[01:24:20] <petev> the debug one will be first
[01:24:38] <SWPadnos_> right - start with everything, then drop what you don't need / use
[01:24:45] <petev> yep
[01:24:59] <SWPadnos_> (like most technology products)
[01:25:03] <petev> plus not sure what the SHMEM interface will look like yet
[01:25:10] <SWPadnos_> nope
[01:25:27] <SWPadnos_> architecturally, the physical interface shouldn't matter
[01:25:28] <jmkasunich> did I hear SHMEM?
[01:25:38] <petev> yes, from canon to motion
[01:25:38] <SWPadnos_> SHHHHHHH - mem
[01:25:50] <petev> that's why I can't do the SHMEM version, only the debug
[01:25:58] <petev> the API will be the same, of course
[01:26:09] <jmkasunich> heh, I don't know much about interps and such, thats why I've been quiet lately
[01:26:23] <jmkasunich> but when you start talking about the motion interface, I delurk
[01:26:24] <petev> yeh, but what about motion?
[01:26:28] <petev> yep
[01:26:38] <petev> getting down to that layer quickly
[01:26:44] <jmkasunich> you've seen Josh's emails?
[01:26:55] <petev> you should look at the canon header too, it's lacking in the axis/motion area
[01:27:00] <petev> yes, saw it
[01:27:08] <petev> but I come back to cutter comp
[01:27:17] <petev> how do we handle it with splines?
[01:27:47] <jmkasunich> you mean if the language allows you to specify splines? then I dunno
[01:27:52] <petev> yes
[01:28:01] <jmkasunich> if the language is still arcs and lines, then you offset before you convert to splines
[01:28:07] <petev> gets very hard, or at least for my math challenged brain
[01:28:19] <petev> right, arcs and lines are easy
[01:28:27] <jmkasunich> use splines internally because of the good things they do for the planner
[01:28:45] <petev> but I thought the whole idea was to reduce sample error too
[01:28:59] <petev> may not be of much use though if you can't get splines from CAM
[01:30:45] <SWPadnos_> ok - friend's here - may be around, sort of ;)
[01:30:55] <petev> ok
[01:31:10] <petev> jmk: are u up to speed on all of the offsets used in EMC?
[01:31:48] <rayh> the demo got postponed until tomorrow.
[01:32:01] <rayh> good thing gave me a chance to polish.
[01:32:49] <jmkasunich> petev: no
[01:33:17] <jmkasunich> from the command struct in motion.h out to the motors I pretty much know, (except some internals of the TP)
[01:33:21] <rayh> Hi pete john
[01:33:23] <jmkasunich> above that not so well at all
[01:33:27] <jmkasunich> hi ray
[01:33:28] <petev> yeah, it's giving me a headache all the places I see offsets and origin stuff
[01:33:35] <petev> hi ray
[01:33:39] <jmkasunich> ray's your man...
[01:34:03] <jmkasunich> heh
[01:34:25] <petev> yeah, in the interp, canon, etc.
[01:34:35] <petev> I don't have a good handle on it yet
[01:34:58] <rayh> been stumped for a day on how to handle as many pins, params, and such as a good sized installation will show.
[01:35:04] <jmkasunich> as long as the motion controller never sees 'em I'll be happy
[01:35:15] <petev> hah
[01:35:17] <jmkasunich> rayh: GUIing?
[01:35:43] <jmkasunich> scrollbars!
[01:36:01] <rayh> Yep still. Found a BWidget tree
[01:36:14] <petev> jmk: u can probably help on these issues
[01:36:30] <jmkasunich> which ones, rays or yours?
[01:36:35] <petev> how are the feed/speed overrides and optional block delete handled?
[01:36:49] <jmkasunich> not a clue about block delete
[01:36:56] <rayh> that will let me build trees from the answers to halcmd show
[01:37:06] <petev> hmm, seems like it needs to be handled in motion because of the queue
[01:37:19] <jmkasunich> feed override sends a command to motion that sets a variiable called "Vscale"
[01:37:26] <rayh> feedrate override is a scale variable that is applied inside the motion controller
[01:37:45] <petev> but where does it come from, I didn't see an NML for it?
[01:37:56] <jmkasunich> the same variable is used for feed hold, sets scale to zero
[01:38:13] <jmkasunich> I'm not sure of the NML
[01:38:26] <petev> ahh, cycle hold was another issue
[01:38:28] <jmkasunich> lets find out... open motion.h first
[01:38:54] <jmkasunich> in that command enum, EMCMOT_SCALE is the command to set the scale
[01:39:12] <petev> phone, 1 sec
[01:39:53] <jmkasunich> grepping shows emcmotCommand.command = EMCMOT_SCALE; in taskintf.cc
[01:40:27] <jmkasunich> the call that sends that to motion is emcTrajSetScale in taskintf.cc
[01:40:44] <rayh_emc2> ganging up on you
[01:40:55] <rayh_emc2> Issuing EMC_TRAJ_SET_SCALE -- (+209,+20, +7,0.560000,)
[01:40:56] <jmkasunich> the ray brigade
[01:41:18] <petev> yes, I see the set scale
[01:41:21] <jmkasunich> emctaskmain.cc calls it
[01:41:36] <petev> ok, that explains feed
[01:41:43] <petev> does speed use the same thing?
[01:42:11] <jmkasunich> in response to a NML EMC_TRAJ_SET_SCALE_TYPE (one of those gawd-awful switch statements)
[01:42:33] <jmkasunich> what is "speed override"? spindle speed override?
[01:42:37] <petev> yes
[01:42:58] <jmkasunich> motion never sees that, spindle stuff goes off to the io controller
[01:43:16] <petev> ok, don't u think all of this should go through canon?
[01:43:33] <jmkasunich> well, canon is probalby what sent the NML in the first place
[01:43:41] <petev> no, it's bypassed
[01:43:43] <jmkasunich> EMC is like an onion
[01:43:46] <petev> NML goes around it
[01:43:53] <petev> I think canon should send it
[01:43:53] <jmkasunich> lots of layers, and when you open it you cry
[01:44:16] <petev> task must be sending the feed/speed values
[01:44:18] <jmkasunich> so the GUI directly sends that NML?
[01:44:23] <petev> there is nothing in the canon API for them
[01:44:29] <jmkasunich> ok, GUI sends to task, task sends to motion
[01:44:29] <petev> only to enable/disable them
[01:44:39] <petev> yes, that's what I think
[01:44:45] <petev> haven't confirmed it
[01:44:48] <jmkasunich> keep in mind, canon was intended for the interp interface
[01:44:55] <petev> hmm
[01:44:58] <jmkasunich> feed override is never seen by the interp
[01:45:01] <petev> why only the interp?
[01:45:08] <jmkasunich> ask the original designers
[01:45:08] <petev> they say it's the model of the machine
[01:45:29] <petev> well what do you think about using it as the model for the machine?
[01:45:38] <petev> that's the direction I'm going
[01:45:53] <jmkasunich> I'm open to the idea, as I am to lots of other ideas
[01:46:10] <petev> ok, I will proceed along those lines
[01:46:14] <jmkasunich> but I can't give a really informed opinion
[01:46:26] <petev> how far off are u from looking at the new motion interface?
[01:46:35] <petev> I sent stuff to swp and cradek too
[01:46:39] <jmkasunich> I do know that the more you change the architecture, the more likely you are to have strange problems, and resistance from others
[01:46:40] <petev> swp is looking at it
[01:47:11] <petev> yeah, I hear u, but I think they are good changes
[01:47:18] <petev> swp had even more radical ideas
[01:47:30] <petev> I thik the code will be much cleaner and easier to understand
[01:47:31] <jmkasunich> pete: I really appreciate your enthusiasm, and envy your energy, but I just can't keep up
[01:47:58] <petev> I have a good chunk done and it's much smaller than what it replaced in terms of source code
[01:48:09] <petev> it's really not that much code if done right
[01:48:21] <petev> let the tools do the work for you
[01:49:14] <jmkasunich> I'm not talking about code...I can't keep up with your ideas
[01:49:14] <petev> I don't know, seems like the code is out of control now and nobody can make changes without breaking things
[01:49:31] <jmkasunich> there are large sections where that is true
[01:49:41] <jmkasunich> but some folks manage
[01:49:47] <jmkasunich> the lermen interp mods for instance
[01:49:57] <petev> I'm still headed for the ideas in the doc and pic we did
[01:50:11] <petev> swp wants to go even further with binary interps, etc.
[01:50:18] <petev> he has some good ideas
[01:50:30] <petev> I'm scared to look at the lerman stuff
[01:50:41] <petev> the interp is so bad now, I can't imagine how he did it
[01:50:42] <jmkasunich> I have high hopes for at least some of that, but my timescale and yours are about an order of magnitude apart (thats what I mean by I can't keep up)
[01:51:06] <petev> but u totally have a good understanding of what motion has to do
[01:51:11] <petev> why fight with the current code
[01:51:24] <petev> it doesn't seem like it will take that long to just re-write it
[01:51:49] <jmkasunich> question: how much time are you putting in on this lately?
[01:51:53] <petev> I'm spending way more time figuring out how current stuff works than re-writing
[01:52:04] <petev> probably a few hours a night
[01:52:28] <jmkasunich> hell, I've been spending a few hours a night just talking about it ;-)
[01:53:02] <petev> I coded the headers last night when u and swp were talking about the tcl stuff
[01:53:29] <jmkasunich> I intended to work on VCP code last night, but didn't write a line because we were talking
[01:54:07] <petev> I guess I have the advantage that I get my questions answered, u guys go to sleep, then I get a few hours
[01:54:10] <jmkasunich> I did work on VCP sunday, but stayed up till 3:30, which I'll be paying for until Saturday when I can sleep in
[01:54:35] <jmkasunich> exactly - when it was Paul and Alex I had these conversations with, I had the same advantage!
[01:54:45] <petev> yep
[01:54:58] <petev> alex is asleep before I even get here
[01:55:39] <jmkasunich> heh
[01:56:05] <jmkasunich> ray just reminded me of another thing I have to do.... test the UPC driver, now that I have a prom with the UPC fpga config
[01:56:20] <jmkasunich> seems like the harder I work, the behinder I get
[01:56:29] <petev> ok, well I'll keep going , then worese case I'll have to write an NML canon
[01:57:44] <jmkasunich> sorry I can't take a more active role, I really enjoyed our late night discussions (until the time spend caught up with me, both lack of sleep, and lack of progress on other things)
[01:58:15] <petev> no problem, I have a lot I can do now
[01:58:21] <petev> the motion talks really helped
[02:00:05] <jmkasunich> I did try to look at the canons at lunchtime at work, but the doze box made a mess of the unix line endings, and I wasn't sufficiently motivated to fix it
[02:00:27] <petev> ahh, try wordpad
[02:00:30] <petev> it handles them ok
[02:00:53] <petev> I got a really stupid question, why would you ever use the D and H codes?
[02:01:01] <jmkasunich> I thought that is what I used, but maybe it was notepad
[02:01:06] <petev> wouldn't you just want the values from the tool table?
[02:01:09] <jmkasunich> I don't even know what D and H are
[02:01:15] <petev> yeah, notepad yacks
[02:01:27] <petev> D and H are for cutter radius and TLO
[02:01:30] <jmkasunich> I prefer it to wordpad most of the time tho
[02:01:45] <jmkasunich> because wordpad nags me whenever I want to save as plain text
[02:01:56] <jmkasunich> thinks it knows better than me what format I want
[02:02:10] <petev> yeah, a lot of MS stuff is like that
[02:02:11] <jmkasunich> fscking microshaft file formats
[02:02:16] <petev> yep
[02:06:14] <SWPadnos_> brb
[02:16:31] <rayh> a few questions for jmkasunich regarding pwm board
[02:16:39] <jmkasunich> ok
[02:16:57] <rayh> 05 float -W 1.00000e+00 ppmc.0.pwm.00.max-dc
[02:16:57] <rayh> 05 float -W 0.00000e+00 ppmc.0.pwm.00.min-dc
[02:17:10] <rayh> these are the max and min output from ini?
[02:17:56] <jmkasunich> they are the max and min duty cycle that the card will put out
[02:18:08] <jmkasunich> IMO they don't map to any particular ini variables
[02:18:22] <jmkasunich> they will probably be set based on hardware issues
[02:18:49] <jmkasunich> for instance some MOSFET drivers (Jons maybe?) can't do 100% duty cycle
[02:19:01] <rayh> 05 float R- 0.00000e+00 ppmc.0.pwm.00.duty-cycle
[02:19:13] <rayh> How does that fit in
[02:19:24] <jmkasunich> thats a param, right?
[02:19:33] <rayh> all of these are
[02:19:36] <jmkasunich> it is the duty cycle the board is putting out right now
[02:19:54] <jmkasunich> (for scoping, troubleshooting, etc, unused in normal operation)
[02:20:05] <jmkasunich> just like the frequency parameter on the stepgen
[02:20:13] <rayh> oh okay. duh
[02:20:42] <jmkasunich> not duh, these things aren't written down anywhere yet
[02:20:45] <rayh> 05 float -W 0.00000e+00 ppmc.0.pwm.00-03.freq
[02:20:58] <rayh> i should have seen the R-
[02:21:01] <jmkasunich> the desired PWM carrier frequency
[02:21:20] <jmkasunich> 20KHz for quiet, lower for less switching noise in the MOSFETs
[02:21:38] <jmkasunich> these are really params that should be specifed by the guy who builds the power stage
[02:21:40] <rayh> Okay. I presume that i can get some answers from jon's ini on these
[02:22:07] <jmkasunich> I don't know if he ini's the frequency in emc1, or if its hard coded to match his power stage
[02:22:58] <jmkasunich> the last one is the only one a normal integrator would probably mess with
[02:23:00] <jmkasunich> the scale
[02:23:13] <jmkasunich> personally I'd set it to the DC bus voltage
[02:23:24] <jmkasunich> that way, the input command is in volts
[02:23:50] <rayh> 80 volts
[02:23:54] <jmkasunich> you command 24.3, and the duty cycle will be whatever it needs to be to deliver 24.3 volts (average) to the motor
[02:24:04] <jmkasunich> set it to 80 then
[02:24:12] <rayh> okay.
[02:24:23] <jmkasunich> if you command 30V, the duty cycle will be 0.375, and you'll get 30V at the motor
[02:24:36] <rayh> I see.
[02:24:56] <jmkasunich> I like it when the PID output and other internal signals have meaningfull scaling
[02:25:41] <jmkasunich> you could also set scale to 10, if you are a traditionalist... then commanding 10 will give you full on, just like an analog input servo amp
[02:26:00] <rayh> Nice ability.
[02:26:03] <jmkasunich> (+/-10V command)
[02:26:05] <rayh> what about these
[02:26:07] <rayh> 05 bit R- FALSE ppmc.0.pwm.00.enable
[02:26:07] <rayh> 05 float R- 0.00000e+00 ppmc.0.pwm.00.value
[02:26:17] <jmkasunich> value is the command
[02:26:26] <jmkasunich> maybe that name should change...
[02:26:42] <rayh> this is in from the pwm out?
[02:26:43] <jmkasunich> enable is just what it says, when off, the PWM outputs are off
[02:26:57] <jmkasunich> no, it is an input to the PWM
[02:26:59] <rayh> so that is the same as the stepgen enable
[02:27:03] <jmkasunich> yes
[02:27:25] <jmkasunich> I need to do something about R and W, the directions are backwards for pins compared to params
[02:27:44] <jmkasunich> a read param means it is read only for the user, IOW an output from the component
[02:28:02] <jmkasunich> a read pin, is one that the component reads, IOW, an input to the component
[02:28:06] <jmkasunich> fscked up, I know...
[02:28:18] <rayh> we do what we can.
[02:29:22] <jmkasunich> its one of those things that I'm used to, but I will be answering questions from people confused by it for the rest of my life until I fix it
[02:29:42] <jmkasunich> (heck, sometimes it even confuses me)
[02:33:42] <rayh> I don't have that problem cause I'm not used to anything.
[02:47:08] <rayh> I presume here that I need to connect linksp Xoutput => ppmc.0.pwm.00.value
[02:48:29] <jmkasunich> is Xoutput from the PID?
[02:48:33] <jmkasunich> if so, then yes
[02:54:44] <SWPadnos> hey - what does the -R mean?
[02:54:46] <SWPadnos> :)
[02:54:56] <jmkasunich> ?
[02:55:08] <SWPadnos> (pin / param directions - answering questions ... )
[02:55:33] <jmkasunich> read back, I just explained it to Ray
[02:55:41] <jmkasunich> (it's screwy...)
[02:55:46] <SWPadnos> heh - I know (hende the :) )
[02:55:48] <SWPadnos> hence
[02:56:00] <jmkasunich> fwoosh
[02:56:08] <SWPadnos> watch that haircut
[02:56:10] <jmkasunich> (sound of it going right over my head)
[02:56:30] <jmkasunich> no danger there, getting pretty thin on top
[02:56:45] <SWPadnos> heh
[02:56:57] <petev> fsck, these interp axis and origin offesets are giving me a headache
[02:57:01] <petev> there are way too many
[02:57:41] <jmkasunich> there are probably good (or at least plausible) reasons for every single one of them
[02:57:48] <jmkasunich> good luck finding them tho
[02:59:12] <petev> what is the point of both G92 and G54..G59.3?
[02:59:19] <petev> seems like G92 is not needed
[02:59:26] <jmkasunich> ask ray or someon else who knows G-code
[02:59:41] <petev> ray: u still here
[02:59:42] <jmkasunich> G92 has been the center of many a discussion
[03:00:02] <petev> yeah, and it has side effects on G54 data
[03:00:06] <petev> I don't like it
[03:00:07] <SWPadnos> especially with Tom Hubin, I think ;)
[03:00:18] <jmkasunich> oh, don't remind me
[03:00:29] <SWPadnos> heh - my ears still hurt
[03:00:32] <petev> is Tom in dislike of G92?
[03:01:07] <jmkasunich> yes - he was at the EMCFest in April and got into heated arguments with Ray and almost everyone else at one point or another about G92
[03:01:13] <SWPadnos> you could say that
[03:01:23] <jmkasunich> he wanted to do something with it, that everybody else said should be done another way
[03:01:30] <SWPadnos> how "it's different from TurboCNC, which is GOD!!!"
[03:01:46] <SWPadnos> but nyway
[03:01:54] <jmkasunich> but he stubbornly inisisted that it should work the way he wanted it to work
[03:02:09] <jmkasunich> that kind of thing is probalby why there are so many offset and such in there
[03:02:36] <petev> hmm
[03:02:37] <SWPadnos> actually, G92 has a different purpose than the offsets (I think)
[03:02:56] <jmkasunich> g-code in general wasn't designed, it evolved, defined by competing commercial companies who had absolutely no commercial gain from maintaining a uniform, logical standard
[03:03:05] <SWPadnos> like HDTV
[03:03:18] <petev> it seems to set some global notion of offset, but some of the G92 also overrite the G54 values for the system in effect
[03:03:34] <jmkasunich> only worse, at least with HDTV, somebody eventually won and the market moved toward a standard
[03:03:42] <petev> yeah, I wonder what fanuc does with this
[03:03:46] <SWPadnos> G92 doesn't change the offset parameters, it just changes the offsets currently in use (I think)
[03:03:50] <jmkasunich> ray wrote a long paper about G92
[03:04:00] <SWPadnos> well -18 standards. 19 if you count normal TV
[03:04:11] <petev> swp: some version of G92, but G92 itself changes things
[03:04:13] <jmkasunich> I don't know where it is offhand, but it should be required reading if you're gonna tread that minefield
[03:04:32] <petev> I just want to finish the interp
[03:05:01] <jmkasunich> then finish it with a G92 that works exactly like the one we have now
[03:05:08] <jmkasunich> anything else would be a disaster
[03:05:19] <petev> yeah, if I had a good handle on all the subtle side effects
[03:05:23] <petev> easier said than done
[03:05:32] <jmkasunich> thats where ray's oaoer comes in
[03:05:36] <jmkasunich> paper
[03:06:12] <petev> plus there is all this origin and offset stuff in the code
[03:06:25] <petev> not really sure what the diff is
[03:06:30] <petev> seems to be the same thing
[03:07:14] <petev> G92 is offset, but it's changing origin
[03:07:23] <SWPadnos> the G54 to G59.3 offsets are independent sets of offsets
[03:07:29] <SWPadnos> they don't combine with each other
[03:07:41] <petev> according to Kramer, they do
[03:07:43] <SWPadnos> G92 is combined with any other offset
[03:07:54] <SWPadnos> no -G54 and G55 will select different offsets
[03:08:05] <SWPadnos> each of those will be added to the G92 offset, it G92 is in effect
[03:08:11] <SWPadnos> if
[03:08:32] <petev> I understand the G54..G59.3
[03:08:38] <SWPadnos> so, for example, if you break a tool, and replace it with one that's .002 shorter than the last
[03:08:46] <petev> but kramers verbage on G92 is not the greatest
[03:09:24] <SWPadnos> yo ucan move down .002 inches, then issue a G92 Z (here + 0.002), to compensate all G5xx coordinate systems to the new tool length
[03:09:50] <petev> kramer says "when G92 is executed, the origin of the currently active coordinate system moves"
[03:09:53] <SWPadnos> as long as the program doesn't use G92, you'rea ll set
[03:09:59] <SWPadnos> yes
[03:10:22] <petev> yep
[03:10:31] <petev> anyone got a link to Rays paper?
[03:11:08] <jmkasunich> I asked him a few mins ago, no answer, may be away from his box
[03:11:19] <jmkasunich> probably a link at linuxcnc.org
[03:11:26] <SWPadnos> in the dropbox, he said in a user list post
[03:11:29] <petev> ok, I'll check
[03:11:44] <petev> looks like there is a notion of current G92 offsets and saved params
[03:12:17] <jmkasunich> http://www.linuxcnc.org/Dropbox/g92test1.pdf
[03:12:40] <SWPadnos> the current offsets are in params 5211 to 5216
[03:12:55] <petev> no, I don't those are the saved values
[03:13:09] <jmkasunich> heh... the paper describes how it actually works.... "This paper does not attempt to say that this is the way it should work"
[03:13:11] <SWPadnos> when you set G92, the offsets are saved
[03:13:23] <SWPadnos> (according to kramer)
[03:13:24] <petev> you can zero G92 offsets with G92.2 and not change the params
[03:14:06] <petev> yeah, there is G92, G92.1, G92.2, and G92.3
[03:14:07] <SWPadnos> G92.2 disables the mode, but doesn't zero the params, G92.1 disables the mode, and zeroes the params, G92.3 uses the saved params
[03:14:42] <petev> yeah, well the way it seems to disbale the mode is by clearing the interp offest vars, but not touching the params
[03:14:49] <SWPadnos> so you have it all - enable and set new params, enable and use old params, disable and save params, or disable and clear params
[03:14:56] <petev> that's what I mean about the ones in use vs params
[03:15:01] <SWPadnos> that would be an error ;)
[03:15:12] <petev> what would be an error?
[03:15:25] <SWPadnos> petevyeah, well the way it seems to disbale the mode is by clearing the interp offest vars, but not touching the params
[03:15:42] <petev> that's for G92.2
[03:15:59] <SWPadnos> OK - that's to spec
[03:16:06] <petev> the interp is always using it's offsets (I think) and just sets them from params or clears them
[03:16:18] <SWPadnos> that's fine, internally
[03:16:23] <petev> right
[03:17:03] <petev> ok, I think kramers verbage is misleading, because I don't see what he syas in the code
[03:17:08] <petev> says
[03:17:20] <SWPadnos> ok
[03:17:43] <petev> I'm goin with the code ;-)
[03:18:07] <SWPadnos> well - that's how it's *supposed* to work ;)
[03:18:16] <petev> yeah, right
[03:18:37] <petev> I still can't get over the atan swill
[03:18:41] <jmkasunich> rays paper goes into some depth on what exactly it does
[03:19:41] <petev> ok, u know you're in trouble when u need a 22 pg doc on G92
[03:19:51] <SWPadnos> You haven't met Tom
[03:20:29] <SWPadnos> it's not a simple matter though - it does affect all coordinate systems, and has several options on how it's used
[04:01:43] <SWPadnos_> oh - can I get a copy of that "force HAL unlock" program? ;)
[04:11:35] <jmkasunich> I never compiled it last night, too much fscking around to do it from the command line
[04:11:44] <jmkasunich> I should just add it to the makefile and commit it
[04:12:12] <SWPadnos_> either way - I was glad that halcmd isn't what I fubared
[04:12:44] <jmkasunich> you mean the segfault from scope?
[04:12:49] <SWPadnos_> yeah
[04:13:26] <jmkasunich> you only get a lockup if you segfault while holding the mutex
[04:13:42] <SWPadnos_> right
[04:13:52] <jmkasunich> both halcmd and scope do grab the mutex, but only to traverse the linked lists, then they release it
[04:14:24] <SWPadnos_> if I is gonna be a reel programmur, I'z got to be able ta unfubar my fsckups
[04:14:40] <jmkasunich> you know, what I should really do, is put a timeout at the beginning of halcmd
[04:15:07] <jmkasunich> if it tries to get the mutex for more than a couple seconds without succes, it assumes that something is busted and releases it
[04:15:22] <SWPadnos_> right - it only holdsthe locks while it's actually executing commands - should be short
[04:15:33] <SWPadnos_> or havean option to do it
[04:15:39] <SWPadnos_> halcmd -K
[04:15:42] <jmkasunich> an option would be better
[04:16:06] <jmkasunich> I should do that
[04:16:32] <jmkasunich> I seem to have brain freeze on my VCP stuff tonight anyway... keep going around in circles
[04:16:55] <SWPadnos_> circles are good - make nice meters ;)
[04:17:14] <jmkasunich> not when its my brain that is going around and around
[04:17:42] <SWPadnos_> ah - you need a brainmeter
[04:17:50] <SWPadnos_> feel free to use me as a sounding board
[04:18:05] <jmkasunich> sometimes I feel like mine is stuck on "duh"
[04:18:20] <SWPadnos_> heh
[04:19:36] <jmkasunich> tell you what... I'm gonna send you the source for the unlocker...
[04:19:54] <SWPadnos_> ok - I'll merge it int o halcmd with an option
[04:19:56] <jmkasunich> if you want to add it to halcmd, I'd appreciate it
[04:20:02] <SWPadnos_> ok
[04:20:29] <SWPadnos_> any choice for the option / command name? (forceunlock)
[04:20:47] <jmkasunich> its main is 30 lines, and there aren't any functions - the main could be pretty easily turned into "do_release_mutex_cmd()" and called from the parser
[04:20:53] <SWPadnos_> ok
[04:20:56] <jmkasunich> --oshit
[04:21:08] <jmkasunich> heh
[04:21:09] <SWPadnos_> -0shit
[04:21:18] <SWPadnos_> (to reduce the shit :) )
[04:21:27] <SWPadnos_> -unfubar
[04:21:34] <SWPadnos_> I like that
[04:21:50] <jmkasunich> but halcmd only uses short options.... -u I guess
[04:22:07] <jmkasunich> could stand for unfubar, or unlock
[04:22:08] <SWPadnos_> bin/halcmd removethelockIcausedbywritingpoorcodewhichsegfaulted
[04:22:29] <jmkasunich> yep, I like that one
[04:22:44] <SWPadnos_> it should be a command - it needs RT to be loaded
[04:22:46] <jmkasunich> make it a case sensitive compare, and don't list it in the help screen
[04:23:05] <SWPadnos_> (the options are done before RT)
[04:23:37] <jmkasunich> right, but you need to call it instead of hal_init, because if you call hal_init, you will hang waiting for the mutex
[04:23:44] <SWPadnos_> ah - OK
[04:24:02] <jmkasunich> the way I see it, you give this option, halcmd does nothing except release the mutex and exit
[04:24:12] <jmkasunich> ignore all other options, ignore any commands
[04:24:18] <SWPadnos_> ok - maybe a -F -u (Force unlock ;) )
[04:24:29] <SWPadnos_> with a prompt if -F isn't specified
[04:24:47] <jmkasunich> to elaborate
[04:25:14] <jmkasunich> too elaborate I should say
[04:25:22] <SWPadnos_> ah - I was waiting
[04:25:36] <SWPadnos_> (or wondering if you meant "do elaborate ...")
[04:25:50] <jmkasunich> ;-)
[04:25:52] <SWPadnos_> no problem. -u to unlock
[04:26:00] <jmkasunich> just -u, imo
[04:26:54] <SWPadnos_> hmm - do we need a lock check as well? (or can that be done while the mutex is held?)
[04:26:57] <jmkasunich> gotta stop talking and mail it already
[04:27:01] <SWPadnos_> for realtime stop
[04:28:35] <jmkasunich> ok, code on the way
[04:28:44] <SWPadnos_> cool - thanks
[04:28:59] <jmkasunich> you know there is another kind of locking (maybe what you are talking about now)
[04:29:25] <SWPadnos_> you had mentioned that realtime stop couldn't stop
[04:29:39] <SWPadnos_> since it used halcmd, which couldn't initialize
[04:29:52] <jmkasunich> halcmd stop was broken
[04:30:05] <SWPadnos_> ok
[04:30:36] <jmkasunich> the other locking was intended to stop people from doing unlinkp or linkpp or setp on a running machine
[04:30:59] <SWPadnos_> ok
[04:31:13] <jmkasunich> and there are "lock" and "unlock" versions, so -u may be a poor choice for the mutex release
[04:31:16] <SWPadnos_> it would be useful for that to be available to (e.g.) tcl programs ;)
[04:32:16] <jmkasunich> the lock command can be "lock none", "lock tune" or "lock all"
[04:32:21] <jmkasunich> none unlocks everything
[04:33:11] <jmkasunich> tune locks pins and params and loadrt, leaves setp open so you can tune things
[04:33:16] <jmkasunich> all locks everything
[04:33:22] <jmkasunich> there are matching unlock commands
[04:33:27] <SWPadnos_> but you can't check the state of those locks (there's not getlock command)
[04:33:32] <jmkasunich> must be root (sudo) do use the lock and unlocks
[04:33:35] <jmkasunich> status lock
[04:33:38] <SWPadnos_> ok
[04:34:02] <jmkasunich> or just plain status, shows all status
[04:34:09] <jmkasunich> currently status choices are lock and mem
[04:34:12] <SWPadnos_> hm - maybe I'll add the -s option, to suppress headers on show output
[04:34:36] <jmkasunich> -s for script friendly?
[04:34:40] <SWPadnos_> and the extra u8 and u16 print
[04:34:42] <SWPadnos_> yep
[04:34:52] <jmkasunich> sounds good to me
[04:34:58] <SWPadnos_> the help may exceed 25 lines though ;)
[04:35:43] <jmkasunich> heh, its only 20 now
[04:35:53] <SWPadnos_> ok - I'll be OK then
[04:36:17] <jmkasunich> damn thats a long file
[04:36:21] <jmkasunich> 2783 lines
[04:36:31] <SWPadnos_> yep
[04:36:32] <jmkasunich> over 2800 when you get done I'm sure
[04:36:49] <SWPadnos_> definitely - it's up 5 lines, and I haven't added anything yet ;)
[04:36:59] <SWPadnos_> just a var and a case
[04:37:20] <jmkasunich> for the help: -s Script friendly
[04:37:32] <SWPadnos_> yep
[04:37:44] <jmkasunich> still trying to think of what to say about the mutex unlock
[04:37:53] <SWPadnos_> or -s Script friendly (no headers on output)
[04:37:59] <jmkasunich> 99.99% of folks will never need it and might be confused by it
[04:38:00] <jmkasunich> yes
[04:39:07] <jmkasunich> -r Release mutex (for crash recovery only) ?
[04:39:20] <SWPadnos_> I wonder if the get/set sig/pin commands should be moved around in the help
[04:39:37] <jmkasunich> get and set on their own lines?
[04:39:49] <SWPadnos_> ie - gets / getp gets the value of a signal or parameter
[04:39:58] <SWPadnos_> sets / setp sets the value ...
[04:40:05] <jmkasunich> good idea
[04:40:10] <SWPadnos_> so that set and get are correctly alphabetized
[04:40:39] <jmkasunich> heh, they're not alphabetized now
[04:40:44] <SWPadnos_> hmmm - the commands aren't alphabetized (options are)
[04:40:57] <jmkasunich> layed out by function
[04:41:14] <SWPadnos_> ok - I'll leave them where they are, but changethe grouping
[04:41:28] <jmkasunich> yes
[04:42:54] <jmkasunich> get that source yet?
[04:43:05] <SWPadnos_> hmmm - maybe -h prints the info about -r (-u), but plain "halcmd" doesn't
[04:43:48] <jmkasunich> yeah
[04:44:25] <jmkasunich> how about this: you have to give -g (for guru mode), only then will it print the help for the -r ;-)
[04:44:43] <SWPadnos_> and you need -g -r -r to actually unlock
[04:44:44] <jmkasunich> and of course, -g is only documented if you specify it
[04:44:54] <SWPadnos_> which can be abbreviated as -grrrrrrr
[04:44:59] <jmkasunich> lol
[04:45:27] <SWPadnos_> so - do you want -r, or -u?
[04:45:39] <jmkasunich> r I think
[04:45:49] <SWPadnos_> I guess r makes sense (maybe R - just to make it harder ;) )
[04:45:59] <jmkasunich> we have an unlock command, don't want the word unlock to appear anywhere else
[04:45:59] <SWPadnos_> since it is a forced release
[04:46:02] <SWPadnos_> ok
[04:46:03] <jmkasunich> yeah, -R is fine
[04:47:12] <jmkasunich> ideally, nobody will ever need that command
[04:47:18] <rayh> pwm link question when yo get a chance.
[04:47:24] <jmkasunich> shoot
[04:47:31] <rayh> Is this the correct link for pwm out to ppmc in linksp Xoutput => ppmc.0.pwm.00.value
[04:48:06] <jmkasunich> I think so... Xoutput is connected to the output of the PID block, right?
[04:48:22] <rayh> Yes
[04:48:31] <jmkasunich> then that is correct
[04:48:36] <rayh> k
[04:48:40] <rayh> thanks
[04:48:44] <jmkasunich> sure
[04:49:23] <jmkasunich> I wonder exactly how halcmd exited yesterday....
[04:49:52] <jmkasunich> it happened when I tried a list command and instead of redirecting the output to /dev/null, I tried to pipe it there
[04:49:59] <SWPadnos_> should scriptmode be mutually exclusive with "-kf" mode?
[04:50:13] <SWPadnos_> no - nevermind - it shouldn't
[04:50:36] <jmkasunich> linux must have terminated the process after it tried to write to the pipe
[04:51:05] <jmkasunich> thats the only time it would have the mutex (iterating thru the linked list, printing each name)
[04:51:11] <rayh> when I enter the command above it gives no error but doesn't show the signal either
[04:51:41] <SWPadnos_> which command?
[04:51:52] <jmkasunich> enter from the cmd line, or in the .hal file?
[04:52:26] <rayh> command line bin/halcmd linksp Xoutput => ppmc.0.pwm.00.value
[04:52:45] <SWPadnos_> value should be velocity, no?
[04:52:52] <jmkasunich> on the command line you can use the arrow, bash thinks you are redirecting the output to file ppmc.0.blah
[04:53:04] <jmkasunich> you probably have such a file now, with the error message in it ;-)
[04:53:17] <SWPadnos_> => should be an error though
[04:53:20] <jmkasunich> s/can/can't/ CAN NOT user the arrow
[04:53:36] <jmkasunich> I can't type for shit
[04:53:49] <SWPadnos_> I cnat ithre
[04:54:32] <jmkasunich> swp, bash has no problem with that syntax, it opens the ppmc.0.blah file, then invokes halcmd with the rest of the line
[04:54:48] <SWPadnos_> I'd have thought that the '=' would be an error
[04:54:54] <jmkasunich> since the pin name is missing, halcmd errors, but he message goes into the file and you never see it
[04:55:04] <jmkasunich> echo 1 foo => bar
[04:55:20] <jmkasunich> puts "1 foo =" into bar
[04:55:24] <SWPadnos_> ok - the = ends up as a parameter to the func
[04:56:05] <jmkasunich> working better now rayh?
[04:56:44] <rayh> I didn't understand anything you guys said... but tried without the ==> and now it shows.
[04:56:54] <SWPadnos_> heh
[04:56:55] <jmkasunich> thats what counts
[04:57:13] <jmkasunich> rayh: you do know about redirecting to files don't you?
[04:57:25] <jmkasunich> cat foo >bar copies foo to bar...
[04:57:48] <jmkasunich> the > in the arrow is what causes the problem
[04:58:09] <rayh> okay got those now.
[04:58:14] <SWPadnos_> it is ppmc.0.pwm.00.velocity though, not value, right?
[04:58:24] <rayh> no it's value
[04:58:26] <SWPadnos_> odd
[04:58:41] <SWPadnos_> and that's the R- pin?
[04:58:47] <rayh> well that's what halcmd says.
[04:59:20] <jmkasunich> SWP: value is the input to the pwm module
[04:59:33] <SWPadnos_> ok - it's velocity to the stepgens
[04:59:34] <rayh> 05 bit R- FALSE ppmc.0.pwm.00.enable
[04:59:34] <rayh> 05 float R- 0.00000e+00 ppmc.0.pwm.00.value <== Xoutput
[04:59:40] <jmkasunich> after all, PWM duty cycle doesn't produce velocity, only voltage
[04:59:53] <SWPadnos_> ok - but then stepgen should be frequency ;)
[05:00:01] <SWPadnos_> and pwm should be dutycycle
[05:00:38] <jmkasunich> velocity is scaled, so it isn't a frequency (frequency is in Hz)
[05:00:50] <SWPadnos_> ok - I can accept that
[05:00:55] <jmkasunich> value is scaled, so it isn't a duty cycle (duty cycle is 0.0-1.0)
[05:01:12] <jmkasunich> value maybe be a poor choice tho
[05:01:14] <SWPadnos_> (but you had to think about it ;) )
[05:01:26] <jmkasunich> perhaps command or something would be better
[05:01:42] <rayh> 05 bit R- TRUE ppmc.0.pwm.00.enable <== Xenable
[05:01:42] <rayh> 05 float R- 0.00000e+00 ppmc.0.pwm.00.value <== Xoutput
[05:01:47] <rayh> how's that look
[05:01:50] <jmkasunich> looks good to me
[05:01:55] <SWPadnos_> me too
[05:01:57] <jmkasunich> rayh: a question for you
[05:02:20] <rayh> ppmc.0.pwm.00.command for both stepgen and pwm would be easier for a newbee to understand.
[05:02:21] <jmkasunich> suppose that I decided that ppmc.0.pwm.00.command made more sense than value
[05:02:36] <SWPadnos_> I guess you'd be in agreement
[05:02:40] <jmkasunich> I can change the component, and change the ini or hal files in the configs directory
[05:02:50] <jmkasunich> but files like the ones you are developing would break
[05:02:59] <rayh> let em.
[05:03:11] <SWPadnos_> it isn't released yet ;)
[05:03:13] <jmkasunich> even for a purely cosmetic change like a name
[05:03:14] <rayh> who else is developing for it now.
[05:03:45] <SWPadnos_> fix it now, or forever be screwed by all the people who get screwed when you finally get around to it
[05:03:48] <jmkasunich> ok, just figured I'd ask
[05:04:02] <rayh> I understand why it wouldn't work for this but if stepgen and pwm could be combined to a single name
[05:04:06] <jmkasunich> IMO, command instead of value is a no-brainer for pwm
[05:04:13] <rayh> then the same links would work for both.
[05:04:26] <jmkasunich> no they wouldn;t
[05:04:35] <SWPadnos_> or even something kinda generic, like "input" (though that has other connotations)
[05:04:40] <jmkasunich> ppmc.0.stepgen.00.command vs ppmc.0.pwm.00.command
[05:04:42] <SWPadnos_> they should, if the scaling is right
[05:05:01] <jmkasunich> you still have to change stepgen to pwm
[05:05:09] <SWPadnos_> link pid.output to pwm.input - that makes some sense
[05:05:12] <rayh> and that's okay
[05:05:38] <jmkasunich> ok, lets discuss this some more... good people to have for it
[05:05:50] <SWPadnos_> hm - "to" should be accepted in place of the arrows
[05:05:52] <jmkasunich> I avoided "input" and "output" for drivers of any kind
[05:06:09] <jmkasunich> because "input" to a driver probably eventually becomes "output" from the computer
[05:06:16] <jmkasunich> and I was afraid that would be confusing
[05:06:38] <jmkasunich> what do you guys think?
[05:06:42] <SWPadnos_> it can be explained that every "block" in HAL has inputs and outputs
[05:06:51] <SWPadnos_> PID has the input command, and an output value
[05:06:52] <rayh> * rayh looks at some of the IO stuff.
[05:07:08] <jmkasunich> for purely internal blocks the potential for confusion is much lower
[05:07:10] <SWPadnos_> a driver has an input command, and a physical output
[05:07:24] <SWPadnos_> another driver has a physical input, and an internal output
[05:07:26] <SWPadnos_> (encoders)
[05:07:27] <jmkasunich> think about the digital I/O
[05:07:40] <jmkasunich> ppmc.0.dout.00.input seems screwy to me
[05:07:43] <SWPadnos_> yes - a bit is a different puppy though
[05:07:49] <jmkasunich> as does ppmc.0.din.00.output
[05:07:57] <rayh> amp-enable-out i like this
[05:08:09] <SWPadnos_> how about ppmc.0.dout.00?
[05:08:13] <SWPadnos_> no input or output
[05:08:24] <jmkasunich> well there is also ppmc.0.dout.00.invert
[05:08:31] <SWPadnos_> that's a param
[05:08:37] <jmkasunich> and for the inputs
[05:08:46] <SWPadnos_> ppmc.0.din.00
[05:08:51] <jmkasunich> ppmc.0.din.00.in and ppmc.0.din.00.in-not
[05:09:00] <SWPadnos_> ppmc.0.din.00-not
[05:09:20] <SWPadnos_> or just din00 and din00-not
[05:09:38] <SWPadnos_> (though I know there's good separation of functions now )
[05:09:39] <jmkasunich> those make a lot of sense
[05:09:53] <SWPadnos_> one other thing, as long as we're on the subject
[05:09:59] <jmkasunich> I guess in the back of my mind I have the component-pin model
[05:10:04] <SWPadnos_> I think we discussed this at fest, but I'll bring it up again
[05:10:05] <jmkasunich> din.00 is a component
[05:10:08] <SWPadnos_> right
[05:10:13] <jmkasunich> in, and in-not are pins of that component
[05:10:32] <jmkasunich> if I had a schematic editor, the box would be labeled din.00, and the pins in and in-not
[05:11:12] <jmkasunich> with that model, din.00 or din00 would mean a pin with no label at all
[05:11:17] <SWPadnos_> true - but only 0.0003% of the population is familiar with schematics ;)
[05:11:34] <jmkasunich> its not just the schematic thing
[05:12:02] <SWPadnos_> anyway - the thing I wanted to discuss was - can't we just leave the "unit number" off of hardware drivers?
[05:12:08] <SWPadnos_> ppmc.dout.00
[05:12:10] <jmkasunich> if we ever want heirarchical HAL (did I spell it right?) we want blockname/pinname
[05:12:17] <SWPadnos_> the first output on the first board
[05:12:25] <SWPadnos_> (nope ;) )
[05:12:34] <SWPadnos_> but close
[05:12:41] <jmkasunich> hierarchical
[05:12:43] <jmkasunich> ?
[05:12:52] <SWPadnos_> (i before e except after c)
[05:12:57] <SWPadnos_> yes!!!
[05:12:59] <jmkasunich> fuck it, "layered HAL"
[05:13:02] <SWPadnos_> heh
[05:13:21] <rayh> Now you're messing with my head. I thought that "05 RT hal_ppmc" showed that hal_ppmc was the component.
[05:13:29] <jmkasunich> sorry ray
[05:13:35] <jmkasunich> with the ppmc, there are three layers
[05:13:47] <jmkasunich> ppmc.0 is all board(s) on the parport cable
[05:13:49] <rayh> I see that
[05:14:02] <SWPadnos_> no -hold on
[05:14:07] <jmkasunich> pwm.00 is one pwm generator, kinda like a subcomponent
[05:14:13] <SWPadnos_> ppmc.0 is the first board found, right?
[05:14:17] <jmkasunich> and enable is a pin of that subcomponent
[05:14:22] <jmkasunich> nope, ppmc.0 is the bus
[05:14:27] <SWPadnos_> hmmm
[05:14:29] <SWPadnos_> ok
[05:14:46] <jmkasunich> if there are two boards on the bus, you get ppmc.0.encoder.04, 05, 06, 07.blah
[05:14:54] <jmkasunich> likewise with the dins
[05:14:55] <SWPadnos_> ok - that's why you have the next_stepgen vars in the bus struct
[05:15:05] <jmkasunich> ppmc.0.din.23.in
[05:15:10] <jmkasunich> yes
[05:15:28] <jmkasunich> that concept is new for this driver, and maybe what you were getting at a few mins ago?
[05:15:40] <SWPadnos_> sort of
[05:16:01] <SWPadnos_> but it happens with parport as well, I think
[05:16:10] <SWPadnos_> parport.0.dout. ...
[05:16:17] <jmkasunich> parport is a special case
[05:16:21] <SWPadnos_> just like ppmc ;)
[05:16:24] <jmkasunich> the pin numbers there are the physical pins
[05:16:30] <SWPadnos_> ok
[05:16:37] <jmkasunich> because otherwise you need a cheatsheet
[05:17:27] <jmkasunich> and I think on the parport, they are called parport.0.pin-04-out or something
[05:17:40] <jmkasunich> face it, we need a naming convention document for HAL modules
[05:17:47] <SWPadnos_> yep - I checked ;)
[05:18:20] <jmkasunich> I've been writing hal modules for 2 years, and even my own ideas of what is right have changed in that time... add in other folks' opinion, and you have a mess
[05:18:28] <SWPadnos_> definitely
[05:18:41] <rayh> No you have evolution which is good.
[05:19:01] <SWPadnos_> look at the mess we're in with evolution now ;)
[05:19:36] <jmkasunich> evolution is good, but the older drivers should be brought up to date so users can apply the same logic to drivers written 2 years ago and drivers written tomorrow
[05:19:44] <rayh> Yep
[05:20:00] <rayh> at least they should be before the release.
[05:20:08] <SWPadnos_> if we decide on a naming standard, I can get a lot of drivers and ini files changed in pretty short order
[05:20:12] <SWPadnos_> and hal files
[05:20:14] <jmkasunich> list of outstanding HAL issues:
[05:20:29] <jmkasunich> misleading or confusing use of Read and Write for params and pins
[05:20:31] <rayh> I don't think breaking a few test setups will hurt
[05:20:52] <SWPadnos_> and everything is a test setup at this point (for the most part)
[05:21:12] <jmkasunich> lack of consistent naming conventions for pins and parameters
[05:21:17] <jmkasunich> what else?
[05:21:41] <rayh> um how about the name of the pin, param following the name of the module
[05:21:52] <jmkasunich> ?
[05:21:52] <rayh> like iocontrol and classicladder
[05:21:58] <SWPadnos_> ok - print module name instead of owner ID in show
[05:22:08] <SWPadnos_> not a big issue
[05:22:23] <SWPadnos_> (I don;t think)
[05:22:28] <jmkasunich> ray: in some cases they do (some again...)
[05:22:39] <rayh> I was wondering why motmod pins were named axis
[05:22:46] <jmkasunich> oh, those...
[05:23:03] <SWPadnos_> instead of this:
[05:23:04] <jmkasunich> because they are unique to an axis, and there are multiple axes in one motmod
[05:23:06] <SWPadnos_> 05 float R- 0.00000e+00 ppmc.0.pwm.00.value <== Xoutput
[05:23:10] <SWPadnos_> you should have this:
[05:23:16] <SWPadnos_> hal_ppmc float R- 0.00000e+00 ppmc.0.pwm.00.value <== Xoutput
[05:23:42] <jmkasunich> fucks up the column alignment, unless you pad for the longest possible name length
[05:24:15] <jmkasunich> you could do that on the script-friendly version if you want
[05:24:16] <SWPadnos_> true, but column alignment shouldn't be a priority over functionality
[05:24:22] <SWPadnos_> yep - was just thinking that
[05:24:24] <jmkasunich> the human friendly ones needs readibility
[05:24:28] <SWPadnos_> or maybe -n - use names
[05:24:42] <jmkasunich> a human can easily follow with show comps to get a magic decoder ring
[05:24:43] <rayh> btw I found a tree widget that can display the stuff swp and I were talking about.
[05:24:48] <rayh> BWidget
[05:24:59] <jmkasunich> 99% of the time a human doesn't care about the owner field
[05:25:09] <SWPadnos_> ok
[05:25:24] <SWPadnos_> I never got the chance to look at the BWidget page you linked
[05:25:52] <rayh> I just got a start at adding nodes and it looks good.
[05:26:00] <SWPadnos_> incidentally - there should be a list of packages that emc depends on, so that it's easier to aggregate everything into a custom distribution
[05:26:08] <SWPadnos_> so add BWidget to the list ;)
[05:26:22] <rayh> Well let me play and demo it first.
[05:26:34] <rayh> that package is about 250k
[05:26:38] <SWPadnos_> touch list ; echo BWidget >> list
[05:26:58] <rayh> pure tickle so no other dependencies
[05:27:05] <SWPadnos_> 250k should fit on a CD ok ;)
[05:27:57] <rayh> I can imagine pressing a linkpp button and then selecting the two pins from the tree.
[05:28:48] <rayh> I can also imagine pressing a link bundle and selecting an axis node and a pid node.
[05:29:17] <SWPadnos_> ok - that gets back to naming conventions
[05:29:33] <SWPadnos_> (unless you want the tcl program to know all the significant names)
[05:29:41] <rayh> It's not like the entity we were speaking of for bundle. It just makes a set of links.
[05:29:56] <SWPadnos_> right - but which set?
[05:30:15] <jmkasunich> it has some pre-existing knowledge of what an axis and a PID are?
[05:30:23] <SWPadnos_> do you want that in the tcl code (and change it if any pin names change), or have anaming convention that lets you figure it out?
[05:30:27] <rayh> That's it.
[05:30:50] <rayh> um I was thinking of a hard coded set.
[05:31:18] <SWPadnos_> ok - that's easy, but has maintenance issues
[05:31:30] <SWPadnos_> as long aswe don't go changing pin names too often
[05:31:50] <rayh> Dont think I could get my head round the procedure required for automating it.
[05:31:51] <jmkasunich> hopefully the things we would use that for will be pretty stable
[05:31:57] <SWPadnos_> yep
[05:32:12] <jmkasunich> or else the knowledge is imbodied in a file of some kind and imported
[05:32:25] <jmkasunich> something like
[05:32:29] <rayh> That would work also
[05:32:32] <jmkasunich> bundle {
[05:32:42] <jmkasunich> name = PID to axis
[05:33:05] <jmkasunich> pid.<A>,command axis.<B>.motor-pos-cmd
[05:33:07] <jmkasunich> etc, etc
[05:33:25] <jmkasunich> you invoke it by name, and give it A and B
[05:34:20] <jmkasunich> then you just add another bundle definition to the file and your tool gets smarter
[05:34:51] <rayh> Sounds good.
[05:35:05] <jmkasunich> actually, the don't even have to be bundles
[05:35:16] <jmkasunich> what we are talking about is basically hal macros
[05:35:32] <SWPadnos_> with expression replacement
[05:35:32] <jmkasunich> a macro to connect an axis to a pid
[05:35:42] <jmkasunich> a macro to connect a pid to a ppmc
[05:35:43] <jmkasunich> etc
[05:35:47] <rayh> Sure.
[05:36:18] <SWPadnos_> jmk - should I leave the unlocker name as "hal_unlocker", or still use halcmd?
[05:36:51] <jmkasunich> I thought you were gonna extract the code from the unlocker and embed it in halcmd?
[05:37:05] <jmkasunich> that avoids another executable
[05:37:11] <jmkasunich> and a change to the makefile
[05:37:14] <jmkasunich> and another source file
[05:37:18] <SWPadnos_> I did, but it contains a name for the rtapi_init
[05:37:26] <jmkasunich> oh, that...
[05:37:31] <jmkasunich> your call
[05:37:41] <SWPadnos_> ok - left alone
[05:37:50] <jmkasunich> halcmd appends a pid, so you can have more than one at a time open
[05:37:54] <jmkasunich> this doesn't need that
[05:38:06] <SWPadnos_> true - it'll just be the exact code
[05:40:54] <jmkasunich> reboot?
[05:41:05] <SWPadnos_> not that I noticed
[05:41:17] <jmkasunich> there are two of you now
[05:41:22] <SWPadnos_> the windows machine just disconnected and reconnected for no apparent reason
[05:41:29] <SWPadnos_> three of me
[05:42:04] <jmkasunich> hello Dolly
[05:42:23] <SWPadnos__> SWPadnos__ is now known as SWPadnos
[05:43:07] <SWPadnos_> Alan Parsons, actually
[05:43:38] <SWPadnos_> ("The Three Of Me", from "Try Anything Once")
[05:43:47] <jmkasunich> I was thinking of the cloned sheep
[05:43:51] <SWPadnos_> heh
[05:44:53] <SWPadnos_> hmm - I'm thinking of making a lot of things change with script mode on
[05:45:23] <jmkasunich> heh
[05:45:37] <SWPadnos_> like status, show, list (use newlines vs. spaces), maybe others
[05:45:47] <SWPadnos_> any objections?
[05:45:52] <jmkasunich> you can lose the padding I applied around the numbers to make the fields line up in columns
[05:46:10] <jmkasunich> not really
[05:46:13] <SWPadnos_> for sure - data_value2
[05:46:27] <SWPadnos_> ok - I won't change the normal output, so it shouldn't matter
[05:46:33] <jmkasunich> list in particular was intended for parograms in the first place
[05:46:43] <jmkasunich> programs even
[05:46:52] <SWPadnos_> ok - maybe I'll just make that use newlines
[05:47:07] <jmkasunich> I don't recall why it did all on one line instead of one per line
[05:47:16] <SWPadnos_> can you think of any reasons to keep it on one line?
[05:47:20] <jmkasunich> I wish I could remember who wanted that
[05:47:25] <SWPadnos_> probably ValarQ
[05:47:31] <jmkasunich> * jmkasunich checks commit log
[05:47:49] <SWPadnos_> I'll bet that python likes a single line better than a bunch of lines
[05:48:15] <SWPadnos_> I'll leave it
[05:48:43] <SWPadnos_> rayh: any requests for the "show" output?
[05:49:17] <rayh> I'm using list for the first part of it.
[05:49:27] <jmkasunich> list was added back in june
[05:49:31] <SWPadnos_> ok - I'll leave that alone
[05:49:58] <SWPadnos__> SWPadnos__ is now known as SWPadnos
[05:50:00] <SWPadnos_> here I am again
[05:50:36] <petev> guys, I hate to swith topc on you, but cradek brought up an interesting issue in his bug report
[05:51:10] <petev> currently there is no code in the interp for changing origin and offest values when units are changed with G20/21 and it is documented that way
[05:51:18] <petev> do we want to change this behavior?
[05:51:40] <jmkasunich> it is documented which way, the way it works, or the way it doesn't work?
[05:51:46] <petev> what about TLO and cutter comp too?
[05:51:51] <petev> the way it works
[05:51:54] <petev> the broken way
[05:52:09] <jmkasunich> docs match code, but both don't do the "right thing"?
[05:52:17] <petev> yes, IMO
[05:52:38] <jmkasunich> when it comes to the interp, I stay out of discussions about the "right thing"
[05:52:55] <jmkasunich> rayh: did you read cradek's bug report?
[05:53:08] <jmkasunich> it seems like it would be easy to duplicate the problem
[05:53:15] <petev> very easy
[05:53:41] <petev> I don't even think you have to exit, just set the offset with one units, then switch to another
[05:54:01] <jmkasunich> if if you or someone else familiar with the behavior of that part said "this is a bug" then if pete can fix it he should
[05:54:31] <jmkasunich> I wonder if tkemc behaves differntly than axis
[05:54:41] <petev> well I think it's poor behavior, but not a bug since it works as documented
[05:54:49] <jmkasunich> it seems so obvious that somebody should have noticed by now
[05:55:05] <petev> how many people switch units in the middle of setup?
[05:55:18] <petev> I sure don't, learned that the hard way on the BP
[05:55:28] <petev> it doesn't handle it gracefully either
[06:00:14] <SWPadnos_> interesting - the feedrate gets set to F0 when you do G20 or G21 (with AXIS, at least)
[06:00:37] <rayh> Yes I did read the bug report.
[06:02:45] <SWPadnos_> no - the feedrate gets set to 0 if you command a move that results in no motion
[06:02:52] <jmkasunich> do you agree that it is a bug? can you (or do you feel the need to) duplicate it?
[06:02:54] <SWPadnos_> interesting
[06:03:01] <jmkasunich> (addressed to ray)
[06:03:24] <SWPadnos_> yep - I've gone back to halcmd ;)
[06:03:56] <rayh> NIST wanted to be able to directly read and write the tool and offset tables
[06:04:26] <jmkasunich> so they intentionally avoided doing unit conversion on them?
[06:04:40] <rayh> So they assumed that whatever units the interpreter started up using that would be what the numbers in there are interpreted as
[06:05:09] <petev> is it something we want to change?
[06:05:21] <petev> should we put units in the tables?
[06:05:23] <rayh> You do have to be careful when you set offsets.
[06:06:05] <SWPadnos_> the parameter file numbers should probably be in "user units", but that may break some things
[06:06:19] <SWPadnos_> not "currently used" units
[06:06:32] <rayh> If we were to build gui interfaces to all of these things then I'd say write the whole thing in mm.
[06:06:37] <petev> what are user units?
[06:06:49] <SWPadnos_> set in the ini file
[06:06:58] <jmkasunich> mm!?!
[06:07:01] <jmkasunich> ick
[06:07:02] <rayh> lightyears parsecs you name it.
[06:07:04] <petev> oh, why no just put units in the tables?
[06:07:06] <SWPadnos_> the base unit of the machine
[06:07:13] <petev> if you change the ini u have the same problem
[06:07:19] <SWPadnos_> because the parameter file is just a long list of numbers
[06:07:27] <petev> doesn't have to be
[06:07:45] <jmkasunich> they are numbers
[06:08:09] <jmkasunich> for all anyone knows, parameter 5214 is a loop counter for a canned cycle or something
[06:08:37] <jmkasunich> you can't just go thru and multiply them all by 25.4 when you see a G21 (or G20, or whatever)
[06:08:38] <petev> yeah, I'm thinking more of the tool tables, params are a bit ugly
[06:09:05] <petev> sure, if we did it for params, each would have to have it's own units
[06:09:36] <SWPadnos_> emc supports any unit you want to use, within the range of a double
[06:09:40] <petev> maybe units is a bad word for params, more like type
[06:10:10] <SWPadnos_> I don't think that should be limited by using mm, cm, inch, yard, foot, meter, cm, ....
[06:10:13] <petev> yes, but think from the user standpoint, if he switches from inch to mm, he expects stuff to still work
[06:10:21] <SWPadnos_> yes - I agree
[06:10:33] <SWPadnos_> I'd just save all params in user units (as specified in the ini file)
[06:11:07] <rayh> For the most part, that is the way it works now.
[06:11:07] <petev> I guess that's better than the way it is now
[06:11:23] <SWPadnos_> apparently, the offsets aren't converted before saving
[06:11:45] <rayh> The params themselves are unitless
[06:11:45] <SWPadnos_> they should be applied before any G20 or G21 as well
[06:11:53] <SWPadnos_> that's the trouble ;)
[06:12:08] <petev> now you're really talking re-write
[06:12:14] <rayh> That is why the g20 0r g21 is specified in the ini file as the machine default
[06:12:59] <rayh> and yes it was a quick hack by Will at my request when we started getting mm users.
[06:13:46] <SWPadnos_> do you mean in the RS274NGC_STARTUP_CODE?
[06:13:55] <rayh> yes
[06:15:24] <SWPadnos_> ok - I'm thinking that the [TRAJ]LINEAR_UNITS should define the unit in the parameter file
[06:15:42] <SWPadnos_> and any offsets should be applied before RS274NGC_STARTUP_CODES
[06:16:08] <SWPadnos_> (or after, as long as the unit is understood to be in machine units, not user units)
[06:16:37] <SWPadnos_> if you fiddle with the [TRAJ]LINEAR_UNITS, expect the vars to get screwed up
[06:17:11] <SWPadnos_> jmkasunich: do you have any objection to the ternary operator? (a ? b : c)
[06:17:11] <petev> well the interp will always have to convert as G54 or somthing might change origins
[06:17:28] <jmkasunich> not really, I just never got in the habit of using it
[06:17:37] <jmkasunich> I doubt it generates code that is faster than an if
[06:17:38] <SWPadnos_> ok - it'll be handy for scriptmode
[06:17:58] <jmkasunich> I find the if easier to read, but ifs can get bulky
[06:18:04] <rayh> night guys
[06:18:05] <SWPadnos_> very ;)
[06:18:08] <jmkasunich> night ray
[06:18:09] <petev> gnight ray
[06:18:21] <SWPadnos_> too late
[06:18:42] <SWPadnos_> bummer - I wanted some input from him on script mode
[06:29:45] <jmkasunich> I think I have a love-hate relationship with pointers
[06:29:55] <SWPadnos_> indeed
[06:30:09] <SWPadnos_> kind of like guns
[06:30:19] <jmkasunich> ?
[06:30:28] <SWPadnos_> powerful, but watch where they're pointing ;)
[06:30:33] <jmkasunich> ah, yes
[06:30:51] <jmkasunich> inverse of each other in one way
[06:31:03] <jmkasunich> the safest gun is one that is pointing nowhere (if such was possible)
[06:31:11] <SWPadnos_> true enough
[06:31:17] <jmkasunich> but pointers going nowhere lead to segfaults
[06:31:19] <SWPadnos_> pointing at nothing
[06:31:33] <jmkasunich> as I just tracked down...
[06:32:25] <jmkasunich> part way thru allocation/initialization of an object, I find that I can't proceed (syntax error in input file) so I call my free routine on the partly allocated object
[06:32:43] <SWPadnos_> oops
[06:32:47] <jmkasunich> I thought it was robust against partly allocated objects, but there was a tiny hole
[06:32:53] <jmkasunich> fixed now
[06:33:41] <jmkasunich> each object has pointers to a "definition", a parent, possibly a child and/or sibling, and to private data
[06:33:48] <jmkasunich> any or all of which might be null
[06:34:34] <SWPadnos_> and only some of which should be deleted, if allocation fails
[06:34:50] <SWPadnos_> (freed, in C terms)
[06:34:53] <jmkasunich> most of them, except for the definition
[06:34:59] <SWPadnos_> and the parent
[06:35:09] <SWPadnos_> and the siblings
[06:35:16] <jmkasunich> freeing children and siblings is recursive
[06:35:25] <jmkasunich> sibling implies younger sibling
[06:35:29] <SWPadnos_> ah
[06:35:38] <SWPadnos_> next pointer
[06:35:43] <jmkasunich> yes
[06:36:37] <jmkasunich> better...
[06:36:42] <jmkasunich> I have buttons and boxes
[06:36:50] <jmkasunich> of course, I had that two days ago
[06:37:07] <SWPadnos_> heh - but now they're more - um - betterer!
[06:37:41] <jmkasunich> now I have a cleaner way of telling it what widgets can hold what children, and if they can hold more than one
[06:38:23] <SWPadnos_> ah - cool
[06:38:34] <SWPadnos_> getting the constraints right can be a bear
[06:38:34] <jmkasunich> you know, I think GTK would let you nest multiple widgets, maybe even multiple buttons, inside another button
[06:38:54] <SWPadnos_> could well be
[06:39:14] <SWPadnos_> I'm not familiar with the gtk "way"
[06:39:24] <jmkasunich> * jmkasunich tests
[06:39:54] <SWPadnos_> most controls can contain other controls (almost everything has a label, for instance)
[06:40:27] <jmkasunich> yeah, button inherits from bin, which can hold one widget
[06:40:32] <SWPadnos_> imagine if you miss a button within a button though ;)
[06:40:34] <jmkasunich> usaually a lable
[06:40:51] <jmkasunich> typing sucks
[06:40:55] <SWPadnos_> bummer - if it could hold two, that would be good - an icon and a label
[06:41:13] <jmkasunich> but I just put a box inside a button (boxes can hold lots of widgets)
[06:41:17] <SWPadnos_> maybe you can put a panel in the button, which contains a graphic and a label
[06:41:20] <jmkasunich> have two labels in there now
[06:41:21] <SWPadnos_> ok
[06:41:31] <SWPadnos_> box = label
[06:41:33] <SWPadnos_> no
[06:41:35] <SWPadnos_> box = panel
[06:41:36] <jmkasunich> next I'm gonna try sticking a button in the box thats in the button
[06:41:50] <jmkasunich> probalby panel
[06:41:55] <SWPadnos_> what happens if you click the box though - does the button "click"
[06:42:03] <jmkasunich> invisible itself, but you can load it with widgets
[06:42:19] <jmkasunich> right now (two labels in box) it appears to click
[06:42:23] <SWPadnos_> so you can't see it - where does the "click" event go?
[06:42:25] <SWPadnos_> ok
[06:42:28] <jmkasunich> (no handler installed yet)
[06:42:38] <SWPadnos_> check that soon ;)
[06:42:54] <SWPadnos_> you may find that things aren't going where you think
[06:43:48] <jmkasunich> I don't intend to nest buttons, and may install something that rejects that if it is in the vcp file
[06:43:56] <jmkasunich> but right now it appears to work
[06:44:19] <jmkasunich> click the inner button, it appears to click, click outside the inner one and the outer clicks
[06:44:23] <SWPadnos_> "appears" - good word
[06:44:37] <jmkasunich> the screen effect of clicking
[06:44:39] <SWPadnos_> that makes sense
[06:45:03] <jmkasunich> guess I have to add handlers sooner or later
[06:45:07] <jmkasunich> how about now...
[06:45:15] <SWPadnos_> the box thing would concern me, though a box isn't a control, it's a decoration (or a container)
[06:45:33] <SWPadnos_> decorations usually pass user events to their parent
[06:45:45] <jmkasunich> well right now my .vcp file defines a button, holding a box, holding 2 labels and another button
[06:46:03] <jmkasunich> I'll hang event handlers on each button and see what gets called
[06:46:10] <SWPadnos_> have you seen "buttonfly" - the SGI 3D menu demo from way back when?
[06:46:26] <jmkasunich> no
[06:46:30] <SWPadnos_> it's pretty cool
[06:46:43] <SWPadnos_> it presents a menu as several buttons in space
[06:47:04] <SWPadnos_> click one, and it flips over (3drendered, it's an openGL demo), and has a sub-menu of buttons on it
[06:47:12] <SWPadnos_> click one of the buttons, same thing happens
[06:47:13] <jmkasunich> heh
[06:47:26] <SWPadnos_> click the "background" Of the button, and it flips back to the parent menu
[06:51:18] <jmkasunich> lots of gtk error messages
[06:51:24] <SWPadnos_> heh
[06:51:27] <jmkasunich> I must not be connecting the signal right
[06:51:29] <SWPadnos_> better than segfaults
[06:51:44] <SWPadnos_> (which was my only experience with gtk ;) )
[06:51:46] <jmkasunich> the GTK lib has lots of assert() calls
[06:51:57] <SWPadnos_> are you using gtk or gtk2?
[06:52:05] <jmkasunich> gtk1.2 I think
[06:52:07] <SWPadnos_> ok
[06:52:17] <jmkasunich> least common denominator
[06:52:39] <jmkasunich> duh, I see my problem
[06:52:54] <SWPadnos_> that's a good thing
[06:53:04] <jmkasunich> I passed GTK a ptr to my widget struct, not the GTK widget associated with it
[06:53:15] <SWPadnos_> ah
[06:53:43] <jmkasunich> heh, it works
[06:54:08] <SWPadnos_> cool
[06:54:11] <jmkasunich> click on the inner button, it's handler gets called (only), click on the outer, its handler gets called
[06:54:37] <jmkasunich> and now it is bedtime
[06:54:39] <jmkasunich> goodnight
[06:54:43] <SWPadnos_> night
[13:06:17] <rayh> logger_devel: bookmark
[13:06:18] <rayh> See
http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2005-12-07#T13-06-17
[13:08:03] <cradek> hi ray
[13:08:12] <cradek> I'm sorry I missed the discussion about that bug last night
[13:08:20] <cradek> don't you guys sleep?
[13:12:36] <rayh> Hi chris. I was trying to finish up a project
[13:26:10] <alex_joni> hey guys
[14:47:53] <rayh> alex_joni: Hi. Sorry cleaning up my bsmt act
[15:02:42] <alex_joni> oh.. ok
[17:09:07] <SWPadnos_> rayh: are you around?
[17:48:55] <SWPadnos_> Hi, alex
[17:53:39] <alex_joni> hello
[17:53:44] <alex_joni> gone for a while
[17:53:56] <SWPadnos_> me too (had to sleep sometime ;) )
[17:54:09] <alex_joni> err. I'm going away for a while
[17:54:13] <alex_joni> is what I meant :D
[17:54:16] <SWPadnos_> see ya
[17:58:55] <SWPadnos_> hey - that's the opposite of going
[20:16:55] <alex_joni> hello
[20:17:06] <SWPadnos_> ah yes -hello
[20:21:02] <alex_joni> why -hello?
[20:21:08] <alex_joni> :P
[20:21:31] <SWPadnos_> at least it wasn't ~hello ;)
[20:21:47] <alex_joni> heh.. yeah, just briefly read your changes to halcmd
[20:22:08] <SWPadnos_> you like?
[20:22:33] <alex_joni> cvs diff is not that easy to read, but it seems ok
[20:22:58] <cradek> I think diff -u is much easier to read than the default (-c)
[20:23:07] <SWPadnos_> I agree - I can never figure out what was added etc.
[20:23:20] <alex_joni> the second stuff is usually the changed one
[20:23:35] <alex_joni> sometimes it has a + in front if it weren't there
[20:23:36] <alex_joni> but it's harder for !
[20:23:39] <SWPadnos_> my next task is cleaning up the default ini, removing unused settings, and adding others
[20:23:41] <SWPadnos_> yep
[20:23:53] <alex_joni> SWPadnos_: sounds like a good task
[20:24:05] <cradek> the ! lines in the first block are replaced by the ! lines in the second block
[20:24:21] <alex_joni> cradek: yes, but it's hard to read ;)
[20:24:27] <cradek> alex_joni: no argument from me
[20:24:27] <SWPadnos_> one thing I noticed about tkemc (and presumably mini) - the help.txt file isn't there in emc2
[20:24:38] <alex_joni> right.. seems like that
[20:25:06] <SWPadnos_> and if it were there, the path would be relative to configs
[20:25:20] <alex_joni> SWPadnos_: clean up the ini, I should commit the changes needed for subdirs in config
[20:25:33] <SWPadnos_> maybe there should be a separate "documentation" path exported by the run script?
[20:25:44] <alex_joni> and we should make some default configs, for steppers, servo, stg, motenc, classicladder, etc
[20:25:48] <SWPadnos_> $EMC_DOC
[20:25:58] <SWPadnos_> yep - I'm working on that - setting PID and stepgen limits, etc
[20:26:04] <alex_joni> how about man?
[20:26:10] <SWPadnos_> getting rid of cruft from emc0.02-1.0
[20:26:19] <alex_joni> tkemc and mini reading a manpage would not be that hard
[20:26:29] <SWPadnos_> no - for front ends to point at their own documentation
[20:26:29] <alex_joni> installing a manpage is pretty standard stuff too
[20:26:45] <SWPadnos_> that would work, but not so good from within e.g. mini
[20:26:46] <alex_joni> why shouldn't tkemc and mini have their own man page?
[20:27:00] <alex_joni> likewise for axis..
[20:27:08] <SWPadnos_> they should - I'm talking about online help, accessed from within the GUI
[20:27:14] <alex_joni> yeah I know
[20:27:18] <SWPadnos_> not command-line help about the ini ...
[20:27:31] <alex_joni> nah.. online help
[20:27:41] <SWPadnos_> so they should execute man $0 > edit_window?
[20:27:47] <alex_joni> probably
[20:28:01] <SWPadnos_> what about non-installed runs?
[20:28:04] <alex_joni> btw, this reminds me of something :D
[20:28:14] <SWPadnos_> uh-oh
[20:28:25] <alex_joni> man $EMC2_MAN_DIR/$0 > edit_window
[20:28:38] <alex_joni> SWPadnos_: guessed what it reminds me?
[20:28:47] <SWPadnos_> um - I don't know
[20:28:52] <alex_joni> recent changes, man page...
[20:29:02] <SWPadnos_> halcmd man page?
[20:29:04] <alex_joni> recent changes not to the man page..
[20:29:06] <alex_joni> BINGO
[20:29:20] <SWPadnos_> hmm - I guess I could look at that
[20:29:28] <alex_joni> you could ;)
[20:29:33] <alex_joni> try mc, works great
[20:29:38] <alex_joni> view and edit
[20:29:59] <SWPadnos_> kate works - I just need to find the file ;)
[20:30:25] <SWPadnos_> ok - found it
[21:01:40] <SWPadnos_> there :P
[21:03:25] <SWPadnos_> any thoughts on what the default debug level should be? I'm thinking either 1 or 3
[21:03:50] <cradek> 0?
[21:04:09] <cradek> I don't know what the individual bits do, but I leave mine on 0 most of the time when I'm not debugging
[21:04:15] <SWPadnos_> that would work, but I think errors should be output
[21:04:33] <SWPadnos_> 1 is EMC_DEBUG_INVALID
[21:04:40] <SWPadnos_> what that means, I'm not sure
[21:05:11] <SWPadnos_> but it sounds like it might matter, even when not debugging
[21:05:49] <cradek> ah
[21:06:03] <SWPadnos_> I guess I'll leave the default display as tkemc, since AXIS isn't included (hint, hint)
[21:33:44] <alex_joni> heh
[21:54:38] <alex_joni> YAY
[21:54:40] <alex_joni> thx Stephen
[21:55:00] <SWPadnos_> sure (for the manpage?)
[21:55:24] <alex_joni> for doing it all the way ;)
[21:55:33] <SWPadnos_> heh - verbose is my middle name
[21:55:47] <alex_joni> werbose I guess
[21:55:48] <SWPadnos_> along with pedantic
[21:56:10] <SWPadnos_> and grammar-nazi :)
[21:56:21] <alex_joni> lol
[21:56:26] <SWPadnos_> gotta run - brb
[21:56:37] <alex_joni> k