Back
[13:18:30] <cradek_> cradek_ is now known as cradek
[13:18:35] <rayh> Hi guys. Alex has asked for comment regarding halui. Is it appropriate to make this a wiki page so that the many comments can be merged into a single specification.
[13:19:06] <alex_joni> rayh: yeah sure, go ahead
[13:19:21] <rayh> Will do some time in the next hour.
[13:36:24] <jepler_> jepler_ is now known as jepler
[14:05:20] <alex_joni> morning jeff
[14:05:28] <jepler> hi ale
[14:05:28] <jepler> x
[14:12:30] <alex_joni> how's stuff?
[14:12:49] <alex_joni> oohh.. I see 1.2 is out ;)
[14:14:50] <alex_joni> jepler: short thing to fix:
http://axis.unpy.net/index.cgi/translations
[14:15:00] <alex_joni> it says there that 1.2 is still in development :-P
[14:24:02] <cradek> hi guys
[14:24:32] <cradek> am I an idiot for coming to work?
[14:25:42] <alex_joni> cradek: I wouldn't say.. I'm at work too
[14:25:44] <alex_joni> :-)
[14:26:20] <skunkworks> I took the week off - but it is not snowing here. ;)
[14:26:35] <cradek> welcome to the first day of spring!?
[14:30:41] <alex_joni> it's very nice outside here
[14:30:45] <alex_joni> +15 and sunny
[14:31:02] <cradek> bah
[14:31:02] <jepler> alex_joni: thanks
[14:31:04] <alex_joni> at least it feels like 15
[14:31:05] <jepler> probably on "about" too
[14:31:10] <alex_joni> jepler: no problem ;)
[14:31:16] <alex_joni> I know it's easy to lose track
[14:33:34] <jepler> well .. corrected on "about" and "translations".
[14:33:35] <jepler> bbl
[15:30:38] <rayh> rayh is now known as rayh-away
[15:31:34] <rayh-away> started that page
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Halui
[15:31:57] <alex_joni> rayh-away: nice, I'll look now
[15:38:12] <alex_joni> some things I'd like to comment on.. still there?
[16:00:04] <rayh-away> Yep I'm in and out but yes.
[16:00:17] <alex_joni> ok, spindle-speed ovrride
[16:00:28] <alex_joni> that can be spindle-speed, which I forgot from the list
[16:01:04] <rayh-away> There is nothing out there named spindle override right now.
[16:01:23] <alex_joni> or maybe 2 knobs (one for speed, one for override) and the both get multiplied together
[16:01:39] <rayh-away> phone
[16:01:59] <rayh-away> This should be in usr space or just a HAL?
[16:02:28] <alex_joni> HAL
[16:02:51] <alex_joni> not sure spindle-speed-override is needed
[16:03:01] <alex_joni> spindle speed messages get accepted anytime
[16:03:11] <rayh-away> IMO we should have an equivalent in user space and added to emcsh
[16:08:11] <alex_joni> hmm.. if you say it's needed..
[16:08:17] <alex_joni> * alex_joni goes home
[16:08:25] <alex_joni> I'll be back online in a while (after lunch)
[17:35:06] <alex_joni> hi guys
[17:35:15] <SWPadnos> hi Alex
[17:35:30] <alex_joni> hi SWampy
[17:35:31] <rayh-away> Hey he's back.
[17:35:50] <alex_joni> rayh-away: yeah, and I finished eating too ;)
[17:36:13] <rayh-away> oops making me hungry.
[17:36:21] <SWPadnos> yeah, me too
[17:37:13] <rayh-away> Doc tells me I could do with some sustained hunger!
[17:37:21] <SWPadnos> heh
[17:37:42] <alex_joni> heh, ditto ;)
[17:37:56] <alex_joni> except it's not the doc in my case, but common sense ;)
[17:42:01] <rayh-away> Alex. How do the bidirectional HAL signals work.
[17:42:10] <rayh-away> The signal into emc is a command.
[17:42:16] <alex_joni> you can set them, and also read them
[17:42:22] <rayh-away> The signal from emc is a status.
[17:42:22] <alex_joni> but I think we can do without
[17:42:48] <rayh-away> But what happens when you command something that can't be changed.
[17:43:05] <alex_joni> it'll stay at the sane value
[17:43:41] <rayh-away> So the command has to be momentary.
[17:43:42] <SWPadnos> are you talking about params or pins?
[17:43:47] <alex_joni> pins
[17:43:48] <rayh-away> pins'
[17:43:57] <SWPadnos> are RW pins working now?
[17:44:02] <alex_joni> rayh-away: although I never tried it really..
[17:44:07] <alex_joni> SWPadnos: not sure
[17:44:10] <rayh-away> rayh-away is now known as rayh
[17:44:20] <alex_joni> rayh-away: think we can group those in 2 categories
[17:44:27] <alex_joni> HAL->NML and NML-> HAL
[17:44:47] <SWPadnos> I think jmk and cradek were discussing this last night, and there's a problem in halcmd that prevents an RW from being connected to another RW, or a W pin
[17:45:04] <rayh> Oh. Okay.
[17:45:15] <SWPadnos> which means that RW pins in general are untested, since there's no way to connect them to signals ;)
[17:45:16] <rayh> So we'd have a command pin and a status pin?
[17:45:23] <rayh> I like that even better.
[17:45:30] <alex_joni> yup.. something like that
[17:51:40] <rayh> Who did the fix to the wiki script?
[17:52:02] <alex_joni> which fix?
[17:52:11] <rayh> The new look?
[17:52:22] <alex_joni> chris & I
[17:53:16] <alex_joni> rayh: any problems?
[17:53:19] <rayh> The bottom edge of the edit window blends right into the following stuff. I was thinking a very light background to that edit box would help set it apart.
[17:53:33] <rayh> Only a look and feel thing.
[17:53:44] <rayh> The working of it is great and the look as well.
[17:54:03] <alex_joni> the working isn't changed
[17:55:42] <rayh> It seems to handle plain text a bit better than it used to. Or as I remember it doing when I first started with it.
[17:57:37] <alex_joni> I enabled html tags
[17:57:40] <alex_joni> but that's about it..
[17:57:42] <alex_joni> you could use <html> any html code </html> if you want
[17:59:11] <rayh> Ah that would work nice for some stuff to be transfered in.
[17:59:42] <rayh> logger_devel, bookmark
[17:59:42] <rayh> See
http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2006-03-20#T17-59-42
[18:01:22] <rayh> How do I edit logger's reply for the next earlier log?
[18:02:14] <SWPadnos> change the date string
[18:02:23] <rayh> okay.
[18:02:44] <SWPadnos> also, get rid of the #T17-....
[18:03:59] <skunkworks> http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/
[18:04:08] <skunkworks> will give you a list in date order
[18:04:56] <skunkworks> the ending "/" needs to be on there also or you get a "page cannot be displayed"
[18:05:21] <alex_joni> skunkworks: yeah, my default box name is a local domain, which doesn't get resolved
[18:05:27] <SWPadnos> cool. I've got full environment and ini var replacement working in halcmd
[18:05:37] <alex_joni> and supplying no trailing / will us that name
[18:05:45] <SWPadnos> I'm not sure if I'm embarrassed by the code though ;)
[18:05:58] <alex_joni> SWPadnos: you don't need to be.. no-one will read it ;)
[18:06:04] <SWPadnos> oh yeah :)
[18:06:12] <SWPadnos> I guess I'll commit it then
[18:06:46] <SWPadnos> you can do cool stuff like use vars anywhere in a command, even without whitespace
[18:06:52] <alex_joni> nice
[18:14:09] <rayh> Nice job SWPadnos. But I was just getting to know the old way.
[18:14:18] <SWPadnos> it still works ;)
[18:14:41] <SWPadnos> but now you can add something like PID = pid.0 to the [AXIS_0] ini section
[18:14:46] <rayh> Um. I don't suppose it saves ending values to the places if found them?
[18:15:21] <SWPadnos> and modify the parameters with setp [AXIS_0[(PID).PGain [AXIS_0]P
[18:15:28] <SWPadnos> oops
[18:15:34] <SWPadnos> setp [AXIS_0](PID).PGain [AXIS_0]P
[18:15:45] <SWPadnos> no, I didn't help with that part of it ;)
[18:16:36] <rayh> Could you explain the setp above.
[18:17:00] <SWPadnos> one sec - let me do the commit before cvs times out
[18:17:08] <rayh> k
[18:22:26] <SWPadnos> ok, back
[18:24:03] <SWPadnos> what do you want to know?
[18:24:19] <alex_joni> what's 'setp [AXIS_0](PID).PGain [AXIS_0]P' supposed to be
[18:24:21] <rayh> [AXIS_0]P is the usual look at the ini for this sect and var
[18:24:41] <rayh> what is the (pid)
[18:24:58] <alex_joni> * alex_joni would understand $(PID) but not (PID)
[18:24:59] <SWPadnos> you can add a new ini var that specifies which PID is for each axis
[18:25:22] <rayh> [AXIS_0](PID).PGain
[18:25:30] <SWPadnos> it's the PID var in the AXIS_0 section (which doesn't exist, unless you add it)
[18:25:47] <SWPadnos> it's the same as 0AXIS_0]PID would be
[18:25:51] <SWPadnos> ack
[18:25:57] <SWPadnos> [AXIS_0]PID
[18:26:23] <rayh> * rayh seems to be getting denser with age.
[18:26:35] <steves_logging> steves_logging is now known as steve_stallings
[18:26:36] <SWPadnos> heh - it's not that obvious what's going on
[18:26:45] <rayh> I understand setp
[18:27:16] <rayh> what I don't understand how it finds a hal param to set from [AXIS_0](PID).PGain
[18:27:21] <SWPadnos> the main change is that more than one var can now be used in a halcmd command
[18:27:48] <SWPadnos> PID is an example of something that can be added to the ini file, to control which pid is used for a particular axis
[18:27:54] <alex_joni> SWPadnos: try to use an actual example
[18:28:08] <SWPadnos> there are non, since this capability wasn't there before
[18:28:14] <SWPadnos> s/non/none/
[18:28:53] <alex_joni> imagine one.. what you are explaining is not making any sense
[18:29:12] <SWPadnos> ok, I'll explain this one step by step
[18:29:22] <alex_joni> ok
[18:29:33] <SWPadnos> start with an ini file, and add the following line to the AXIS_0 section:
[18:29:39] <SWPadnos> PID = pid.0
[18:29:39] <rayh> so this example finds a hal param in the ini and sets it to the value it finds in another ini variable.
[18:29:48] <SWPadnos> yes, mostly
[18:30:05] <SWPadnos> it allows you to specify what parameters to set, in the ini file
[18:30:13] <SWPadnos> (as one example)
[18:30:43] <SWPadnos> that step may have been the missing link in the example, actually ;)
[18:30:54] <alex_joni> right
[18:31:13] <SWPadnos> essentially, ini vars and environment vars are now usable anywhere in a halcmd command
[18:31:15] <rayh> * rayh is certainly missing the link or the missing link
[18:31:26] <SWPadnos> where's Lucy when you need her
[18:31:42] <rayh> So that the parport addy can be specified in the ini
[18:31:47] <SWPadnos> yes
[18:31:56] <SWPadnos> that's a bette rexample ;)
[18:32:27] <alex_joni> a very good rexample ;)
[18:32:44] <SWPadnos> loadrt parport cfg="[IO]ADDRESS" should work
[18:32:59] <rayh> Fantastic.
[18:33:00] <SWPadnos> I like rexamples, don't you?
[18:33:26] <SWPadnos> even better:
[18:33:49] <SWPadnos> loadrt pid num_chan="[TRAJ]AXES"
[18:33:55] <rayh> Now we've got to go fix up a whole bunch of configs.
[18:34:20] <rayh> That is getting close to just right.
[18:34:28] <SWPadnos> everything that was there still (should) work as before, so no change is necessary to function
[18:35:18] <rayh> how about loadrt blocks ddt=2*[TRAJ]AXES
[18:35:30] <SWPadnos> heh
[18:35:36] <SWPadnos> nope, no math yet ;)
[18:36:02] <alex_joni> SWPadnos: how about eval and env stuff?
[18:36:03] <jepler> Here's what I want: setp freqgen.0.velocity-scale 1/freqgen.0.max-frequency
[18:36:04] <rayh> curiosity killed the cat and probably the ....
[18:36:22] <jepler> (so that I can send a value from 0.0 to 1.0 in, and get a corresponding duty cycle out)
[18:36:39] <SWPadnos> yeah - that would be good
[18:36:57] <SWPadnos> alex_joni, no eval. I'm not using a shell to do the work (unfortunately)
[18:39:01] <SWPadnos> it would probably have been easier to make halcmd into a script that does all the command parsing, then feeds a sanitized command to halcmd_core
[18:39:19] <SWPadnos> (halcmd_core being what halcmd.c turn into)
[18:40:09] <alex_joni> solar eclypse coming up ;)
[18:40:13] <alex_joni> on the 29th
[18:40:14] <SWPadnos> cool
[18:40:26] <alex_joni> it'll only be 66% from here.. but that's ok too
[18:40:33] <rayh> small change of subject before I forget.
[18:40:36] <rayh> SWPadnos said "no, I didn't help with that part of it ;)" when I asked if if saved values to the source of the value.
[18:40:36] <alex_joni> * alex_joni needs a filter
[18:40:56] <rayh> small change of subject before I forget.
[18:41:09] <SWPadnos> that doesn't mean that it's done, only that what I did didn't get us sany closer to that goal
[18:41:15] <SWPadnos> s/sany/any/
[18:42:48] <rayh> Okay thanks. I was wondering if that was being considered as a halcmd ability.
[18:43:24] <rayh> alex I've used candles to smoke a glass and watch.
[18:43:27] <SWPadnos> there has been some thought put into how to get it done, but I think it can't be solved in halcmd only
[18:43:40] <rayh> Right.
[18:45:00] <alex_joni> rayh: that's pretty dangerous
[18:45:12] <SWPadnos> depends on how smoky you get it
[18:45:14] <alex_joni> I have some goggles for myself, was wonring for a filter for my camera
[18:45:26] <alex_joni> SWPadnos: leaving out a spot and it'll be very painfull
[18:45:30] <SWPadnos> yes
[18:45:42] <alex_joni> I know at least a couple of people went blind on hte last eclypse we had
[18:45:53] <alex_joni> used sunglasses and other crazy things
[18:46:06] <SWPadnos> that's not too smart
[18:46:34] <SWPadnos> I have a solar eclipse viewer - it's about an ND-15 filter ;)
[18:46:39] <alex_joni> ND?
[18:46:52] <SWPadnos> neutral density filter
[18:46:55] <SWPadnos> no coloring
[18:47:09] <SWPadnos> ND1 is one stop, I believe
[18:47:32] <alex_joni> wonder how that relats to DIN filters
[18:47:51] <SWPadnos> not sure. how do they specify how many stops the filter is?
[18:48:01] <alex_joni> they don't
[18:48:04] <SWPadnos> or is that the mounting style (diameter / thread pitch)
[18:48:16] <alex_joni> those are for welding (usually 9-13)
[18:48:21] <SWPadnos> ah
[18:49:20] <alex_joni> SWPadnos:
http://www.us.schott.com/special_applications/english/products/protection_glass/athermal_neu/product_range.html
[18:51:23] <SWPadnos> http://sunearth.gsfc.nasa.gov/eclipse/SEhelp/safety.html
[18:51:36] <SWPadnos> they say number 14 welder's glass is good
[18:51:57] <alex_joni> ok, I got plenty of those ;)
[18:52:29] <SWPadnos> you and the boys should all go downtown wearing your welders helmets ;)
[18:52:33] <alex_joni> lol
[18:52:39] <alex_joni> that should be fun to watch
[18:52:45] <alex_joni> although I hate helmets
[18:52:46] <SWPadnos> order coffee with straws, so you don't have to take them off ;)
[18:52:50] <alex_joni> especially the LCD ones
[18:52:52] <rayh> why dangerous?
[18:53:03] <SWPadnos> eyeball frying things, like UV
[18:53:19] <alex_joni> LCD helmets suck ;) I usually don't use them on my head, but I rather hold them in my hand
[18:53:32] <alex_joni> and when you tilt the LCD it loses the darkness
[18:53:39] <rayh> oops different topic. why is saving values to files dangerous.
[18:53:50] <SWPadnos> I think a bunch of guys in helmets strolling down to a coffee shop would be a sight to see
[18:54:05] <SWPadnos> kinda like "Sky Captain and the World of Tomorrow"
[18:54:36] <rayh> probably they would make the officials nervous and "quelling a riot" would be a topic of the evening news.
[18:54:47] <SWPadnos> heh
[18:55:01] <alex_joni> SWPadnos:
http://www.clixgalore.com/CatalogueImages/3351/0C7EBBE5-0A70-4B9D-853A-C51CD0C18835.gif <- like this?
[18:55:04] <SWPadnos> well, only the helmets, leave the torches at work
[18:55:11] <SWPadnos> heh
[18:55:54] <alex_joni> http://www.clixgalore.com/CatalogueImages/3351/2B822594-F79F-4861-8E41-08A8E1B909C1.gif
[18:58:16] <steve_stallings> steve_stallings is now known as steves_logging
[19:04:25] <alex_joni> SWPadnos: ever installed WinXP on a SATA drive?
[19:04:32] <SWPadnos> yes
[19:04:34] <SWPadnos> sadly
[19:04:39] <alex_joni> on a laptop?
[19:04:47] <SWPadnos> nope. XP64 pro on the dual opteron
[19:05:01] <alex_joni> ahh.. so you had a floppy to supply the driver
[19:05:12] <SWPadnos> yeah - very handy
[19:05:19] <alex_joni> a friend of mine tried on a laptop.. no floppy :)
[19:05:22] <SWPadnos> though XP should be fine with SATA, I think
[19:05:28] <SWPadnos> as long as it's SP2
[19:05:29] <alex_joni> nope, it's not
[19:05:34] <SWPadnos> is the disc SP2?
[19:05:36] <alex_joni> this might be older
[19:06:06] <alex_joni> using an USB floppy gives: "Error on line 1472 at booinit.c"
[19:06:08] <SWPadnos> well, maybe Vista will have innovative new technology that allows you to load drivers from something other than a floppy ;)
[19:06:10] <alex_joni> ROFLMAO
[19:07:15] <SWPadnos> I actually want's as annoyed with XP64 as I could have been, except for the driver issues
[19:07:20] <SWPadnos> wasn't
[19:09:58] <SWPadnos> ok. gotta run for a bit. back soon
[19:10:06] <SWPadnos> SWPadnos is now known as SWP_Away
[19:10:20] <alex_joni> ditto
[19:38:34] <cradek> http://timeguy.com/cradek-files/emc/threading.png
[19:38:44] <cradek> first virtual thread cut with emc2!
[19:40:42] <jepler> neat. what's the topmost signal?
[19:40:53] <cradek> velocity
[19:41:22] <jepler> then spindle feedback, then position?
[19:41:23] <cradek> the sawtooth is the spindle encoder (with a sine wave added in to make it wavy)
[19:41:29] <cradek> yes
[19:42:30] <SWP_Away> SWP_Away is now known as SWPadnos
[19:42:45] <jepler> neat
[19:42:54] <cradek> the spindle is turning at 1rps, threading at 4tpi, so as you can see it takes 4 seconds
[19:43:38] <SWPadnos> cool, man!
[19:43:47] <skunkworks> wow - nice work
[19:44:06] <skunkworks> might have to get our monarch cnc'ed now ;)
[19:44:19] <cradek> see how the position waits at 0 until the encoder resets (index pulse)
[19:44:52] <SWPadnos> rayh, I've just realized that my brain is sometimes totally nonfunctional
[19:45:28] <cradek> (the gcode is just back and forth moves to x.1/x0, the threading move is to x1)
[19:45:31] <jepler> is this done with a G84 canned cycle?
[19:45:49] <cradek> I haven't done any interp work
[19:45:51] <SWPadnos> rayh, looking for an example of variable replacement, it never occurred to me that the main reason for the feature was so that motion could be loaded from the ini, rather than the runscript ;)
[19:45:51] <jepler> oh
[19:46:03] <cradek> the gcode is just g0
[19:46:31] <jepler> http://www.linuxcnc.org/handbook/RS274NGC_3/RS274NGC_33a.html#1003436
[19:47:29] <cradek> jepler: will probably do g33 first
[19:47:53] <cradek> jepler: not entirely sure how it will work yet
[19:48:05] <jepler> What's g33? I don't see it in this document.
[19:48:18] <cradek> it's the thread command for a lathe
[19:48:31] <SWPadnos> take a look at Machinery's Handbook, if you want a selection of possible G-codes and formats
[19:48:52] <cradek> SWPadnos: I think mine's too old, it doesn't describe the format other than G33 cuts threads on a lathe
[19:49:00] <SWPadnos> I can look at mine in a minute
[19:49:14] <SWPadnos> I think there are several variations though (of course)
[19:49:17] <cradek> I'd like to know how a common commercial controller does it
[19:49:20] <cradek> of course
[19:53:18] <cradek> hey there is a g33 example in mine
[19:54:53] <cradek> and it works how I had pictured it: instead of feed in units/time, it's units/revolution
[19:54:58] <skunkworks> tubocnc has threading also - I could look also at our old cincinati malicron lathe manual
[19:55:04] <cradek> so for 16tpi you specify K.0625
[19:56:52] <jepler> clearly the g-code syntax shold be modified to allow you to write "16/K" instead.
[19:57:08] <cradek> clearly
[19:57:24] <cradek> otherwise how can you cut 9tpi accurately?
[20:03:58] <alex_joni> cradek: yay
[20:10:20] <SWPadnos> well, I think I've done the impossible again
[20:10:35] <SWPadnos> I can't find my copy of Machinery's Handbook - large print edition
[20:11:31] <alex_joni> check under the small one ;)
[20:12:05] <SWPadnos> heh. this is almost as bad as losing the MSC catalog
[20:14:04] <SWPadnos> woohoo - found it!
[20:14:17] <cradek> which edition? I have 25
[20:14:29] <SWPadnos> 27
[20:16:07] <SWPadnos> ok, here are their thread cutting codes, from the table of "G-Code Addresses"
[20:16:19] <SWPadnos> G33 = Thread cutting, constant lead
[20:16:31] <SWPadnos> G34 = Thread cutting, increasing lead
[20:16:44] <SWPadnos> G35 = Thread cutting, decreasing lead
[20:16:47] <skunkworks> machinery handbook has g-code examples in it? I guess I never looked. always used it for trig functions ;)
[20:17:51] <SWPadnos> there's another one that's interesting - G31-G31.4: external skip function, move an axis along a linear path until an external signal aborts the move
[20:18:09] <alex_joni> sounds lik probing
[20:18:21] <SWPadnos> could be used for that, sure
[20:18:50] <cradek> SWPadnos: I have that, but does yours show all the arguments to g33?
[20:18:59] <SWPadnos> there are specicific probe commands as well, for circle center + dia, for example
[20:18:59] <jepler> Is G33 a kind of move like G0 or G1?
[20:19:07] <SWPadnos> cradek, one sec
[20:19:32] <jepler> or is it a mode that affects G1?
[20:20:23] <SWPadnos> it's a separate move, I think
[20:20:24] <cradek> jepler: I think it's exactly like G1 but the feed is per rotation
[20:20:43] <SWPadnos> though it might make sense to go back to G0/G1 after it
[20:20:44] <cradek> jepler: there may be more to it (entry/exit moves?) that I don't know about
[20:20:47] <SWPadnos> mode, not move
[20:23:00] <skunkworks> http://www.dakeng.com/man/turbocnc.html#_Toc90515716
[20:23:28] <SWPadnos> there are examples, but the only format I'm seeing so far uses I or K in feed/revolution
[20:24:01] <jepler> http://www.welsoft.co.uk/machlathe/hs380.htm
[20:24:46] <jepler> (this uses G78 but also refers to G33)
[20:27:06] <skunkworks> http://www.dakeng.com/man/turbocnc.html#_Toc90515724
[20:27:08] <skunkworks> yehaa
[20:28:30] <cradek> man, I should have taken longer to do the motion part, so someone else would do the interp
[20:29:14] <SWPadnos> is the motion stuff controlled by spindle-feedback, or is it a separate pin? (or in HAL?)
[20:29:39] <alex_joni> HAL separate pin for spindle-feedback
[20:29:41] <jepler> cradek: just claim there are still bugs in it, and make alex do the interp. work again
[20:29:47] <cradek> haha
[20:29:52] <jepler> alex_joni: hi!
[20:29:53] <cradek> sure seems buggy still, now that you mention it
[20:29:55] <alex_joni> jepler: I can probably try to do that ;)
[20:30:01] <alex_joni> jepler: hi
[20:30:09] <alex_joni> and I don't mind beeing usefull :-P
[20:30:31] <alex_joni> once chris tells me what he needs, I'll start doing it
[20:31:05] <alex_joni> oh, and not something like "I need you to make it work" :)
[20:31:08] <cradek> that's sure a nice offer, I better figure out what I need
[20:31:44] <alex_joni> cradek: bet I know less about this than you (now that you started reading about it), but I bet we can sort it out
[20:31:46] <rayh> IMO the g78 is a brit equivalent code to g33
[20:31:48] <SWPadnos> one thing they mention, but don't give any examples of, is multiple lead threads
[20:32:10] <alex_joni> G76 Multi-pass threading ?
[20:32:13] <cradek> SWPadnos: I think you have to figure it out yourself (start the cut out a bit, in the right place)
[20:32:24] <cradek> SWPadnos: you mean multiple starts?
[20:32:31] <jepler> this article seems to say that G76 is a canned cycle for G33 moves.
http://www.rose-training.com/tandp/jun03.htm
[20:32:39] <SWPadnos> cradek, yes, multiple starts
[20:33:10] <jepler> just don't add too many G-codes or my quick reference won't fit on a sheet anymore
[20:33:22] <cradek> SWPadnos: yeah I think you just figure it out, say you have 4 starts per inch, you begin the second one at -.25"
[20:34:26] <skunkworks> Jepler: I printed your sheet out - but now how to I click on the sheet to get the examples?
[20:34:34] <cradek> alex_joni: G33 should decompose into START_SPEED_FEED_SYNCH() STRAIGHT_FEED() STOP_FEED_SPEED_SYNC()
[20:34:36] <SWPadnos> that can work, if you have a lot of extra space to cut off at the starting end
[20:34:40] <cradek> alex_joni: I think
[20:34:48] <alex_joni> * alex_joni looks
[20:35:06] <cradek> alex_joni: START_SPEED_FEED_SYNCH() should take an argument which is the userunits/revolution (comes from the G33 K word)
[20:35:41] <alex_joni> does CVS work over there?
[20:35:43] <jepler> does the choice of I/J/K depend on the selected plane?
[20:35:45] <rayh> Mits 500 here lists the g33 z1 q1 e1 or f1
[20:35:53] <rayh> where z is thread length
[20:35:54] <alex_joni> oh wait, it's working here too
[20:35:55] <jepler> i.e., plane 17 == K
[20:35:57] <cradek> jepler: I don't know...
[20:35:58] <rayh> q is shift angle
[20:36:07] <cradek> jepler: I was hoping we would support arbitrary planes
[20:36:12] <rayh> and e or f is thread lead
[20:36:24] <cradek> rayh: what is shift angle? the 29 degrees for multiple passes?
[20:37:16] <SWPadnos> 180 degrees for 2-starts, etc, I'd say
[20:37:34] <rayh> yep.
[20:37:36] <cradek> rayh: machinery handbook says g33 is one pass
[20:38:01] <cradek> this must be another one of these things were we can do whatever we please
[20:38:02] <SWPadnos> there's a separate section that talks about the issues with multiple passes
[20:38:33] <SWPadnos> (offsetting the cut in both X ans Z because the cutter is angled, for example)
[20:38:35] <rayh> No I think we need to conform to what cam programs spit out.
[20:38:39] <cradek> SWPadnos: right, g98?
[20:38:59] <SWPadnos> no, G33
[20:39:08] <cradek> arg, my book is too old
[20:39:25] <cradek> rayh: can you work on a spec and put it on the wiki?
[20:39:27] <SWPadnos> in my book, it's about 16 pages after the table
[20:39:44] <rayh> I can start it but that is about all.
[20:39:54] <rayh> Only have the one book handy.
[20:39:55] <cradek> rayh: alex and I don't know squat about what real controllers have, you do
[20:39:56] <SWPadnos> it's a separate heading called "Thread Cutting"
[20:40:26] <cradek> rayh: it would still be nice to have it available for comment
[20:40:29] <alex_joni> cradek: you nailed it there ;)
[20:40:39] <cradek> alex_joni: no offense meant, of course
[20:41:17] <cradek> alex_joni: let's concentrate on the simplest case first, sync/feed/unsync like I said above
[20:41:53] <rayh> You bet.
[20:41:57] <SWPadnos> how hard would it be to make that function take two parameters: the speed and the axis to synch to?
[20:42:24] <SWPadnos> (with a special case for spindle, I guess)
[20:42:25] <cradek> SWPadnos: I think it should allow you to make any move once synced
[20:42:42] <cradek> SWPadnos: we already have coordinated motion with controlled axes
[20:42:44] <alex_joni> cradek: seems paul (when he did the G33 stuff) added an #ifdef LATHE
[20:42:59] <alex_joni> so that needs to gt compiled in for G33 to work
[20:43:05] <cradek> alex_joni: take that crap out
[20:43:27] <cradek> alex_joni: if I want to thread on my mill, I darn well should be able to
[20:43:33] <alex_joni> when LATHE is defined CANNED_CYCLES are taken out
[20:43:41] <SWPadnos> heh
[20:44:19] <alex_joni> cradek: he also took out A,B,C from various commands
[20:44:25] <cradek> argh
[20:44:30] <alex_joni> ARC_FEED(end_x, end_y, center_x, center_y, turn, end_z,
[20:44:30] <alex_joni> #ifndef LATHE
[20:44:30] <alex_joni> AA_end, BB_end, CC_end);
[20:44:30] <alex_joni> #else
[20:44:30] <alex_joni> 0, 0, 0);
[20:44:32] <alex_joni> #endif
[20:44:53] <cradek> I say rip that out
[20:45:07] <alex_joni> probably assumed ABC don't exist on lathes
[20:45:11] <cradek> if I want a rotary table on my lathe, why not? I could attach the cutter to it or something.
[20:45:21] <cradek> who knows
[20:45:28] <cradek> well Y doesn't exist on (most) lathes either
[20:45:53] <SWPadnos> you could rotate the cutter, for different profiles
[20:46:01] <alex_joni> SWPadnos: agred
[20:46:01] <cradek> sure
[20:46:03] <alex_joni> agreed
[20:46:24] <SWPadnos> not that it needs to be synched though
[20:46:47] <cradek> if we later find we need to limit the interp if in lathe mode, that'll have to go in the ini and not require a recompile.
[20:46:52] <alex_joni> this isn't for synched stuff.. but for all stuff
[20:47:10] <alex_joni> cradek: ok, I'll ripp all that out now
[20:47:15] <cradek> yay
[20:47:20] <alex_joni> and if needed I'll put it back ;)
[20:47:24] <alex_joni> but I doubt it
[20:47:26] <cradek> do you think you see what to do for g33?
[20:47:48] <alex_joni> yeah.. only one place to do the magic
[20:48:04] <cradek> ok
[20:48:20] <alex_joni> should I add those calls too?
[20:48:27] <cradek> calls?
[20:48:37] <alex_joni> to the FOO_SYNCH_FUNCTIONS()
[20:48:58] <cradek> I wonder if we should branch, or just thunder on and branch later if we need it
[20:49:13] <alex_joni> so far we're not breaking anyting
[20:49:16] <cradek> I actually don't think we'll have it broken for long
[20:49:16] <alex_joni> anything
[20:49:26] <cradek> I haven't checked in anything yet...
[20:49:48] <alex_joni> ok, I'll do the LATHE stuff now..
[20:49:53] <alex_joni> will probably be a while
[20:49:55] <cradek> ok
[20:50:11] <cradek> you'll have to add EMC_TRAJ_SET_SYNC_FOO_WHATEVER messages
[20:50:38] <cradek> for the interp_list, and then get them in motion, right?
[20:51:01] <alex_joni> yeah, if that's missing (didn't look that far)
[20:51:17] <cradek> then in motion we'll call tpSetSomeSyncThingies(feed rate)
[20:51:17] <alex_joni> grep -r -e LATHE * | wc -l
[20:51:20] <alex_joni> 107
[20:51:30] <cradek> arrgh!
[20:51:37] <alex_joni> will take a bit
[20:51:50] <SWPadnos> that's in lathe_fork? (or BDI4 ...)
[20:51:58] <cradek> no, it's in head
[20:52:00] <alex_joni> no, that's in emc2 head
[20:52:07] <SWPadnos> wow
[20:52:16] <alex_joni> paul merged lathe stuff a while ago
[20:52:45] <SWPadnos> I only get 103
[20:52:58] <alex_joni> so.. how about canned cycles & lathe?
[20:53:01] <SWPadnos> oh, not recursive above rs274ngc
[20:53:12] <alex_joni> SWPadnos: probably I'm counting include/interp_internal.hh too
[20:53:40] <cradek> maybe we should think for a minute more before you rip out 107 things
[20:53:52] <SWPadnos> or some lines like "foo isn't a file you bonehead"
[20:54:02] <alex_joni> ok, lets think
[20:54:09] <SWPadnos> whirr whirr
[20:54:34] <alex_joni> zzzzzzzzz<DANG>..... something broke
[20:54:45] <SWPadnos> sniff sniff - is that smoke?
[20:54:56] <alex_joni> vaporized
[20:55:05] <alex_joni> cradek: isn't that what CVS is for?
[20:55:16] <alex_joni> people that don't think? :D
[20:55:29] <SWPadnos> no, it's for people who don't remember
[20:56:00] <rayh> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Lathe_Code
[20:56:15] <cradek> something like g81 doesn't really make sense for a lathe.
[20:56:15] <rayh> just a start at an outline
[20:56:31] <alex_joni> rayh: what do you think about XYZABC on a lathe?
[20:56:56] <cradek> I don't see why we have to disallow it, though.
[20:56:56] <alex_joni> should it be reduced to XYZ like it's now, or does XYZABC actually make sense on some systems?
[20:57:00] <jepler> cradek: so don't write it when on a lathe
[20:57:08] <Roguish> hello guys. not to complicate matters, but would you like screen shots of the Mastercam 'lathe thread parameters'?
[20:57:09] <cradek> jepler: I think that's also my approach
[20:57:10] <jepler> er, yeah, what you just said
[20:57:42] <alex_joni> Roguish: sure, any source of information is ok
[20:57:43] <SWPadnos> Roguish, if it won't ruffle any copyright lawyer's feathers. sure ;)
[20:58:11] <rayh> Wanna upload those and link them to the new lathe page.
[20:58:20] <alex_joni> cradek: I'll remove the ABC limitations for now, those are the most of them
[20:58:31] <alex_joni> we'll worry about G80+ later.. ok?
[20:58:34] <cradek> alex_joni: ok, I don't see any reason to have that
[20:58:35] <cradek> ok
[20:58:56] <Roguish> i can send you some simple jpg files of the input dialogs. 3 total, 'toolpath parameter', 'thread shape parameters', and 'thread cut parameters'
[20:59:23] <SWPadnos> how about the code it spits out?
[21:00:21] <Roguish> no copywrite infringment, they are just screen dumps.. i have never used this part of mastercam, so i'll have to play with it awhile before any output
[21:00:28] <SWPadnos> ok
[21:00:50] <Roguish> but i will try later today. gotta rtfm for a bit.
[21:01:08] <Roguish> who would like the screen dumps?
[21:01:29] <cradek> Roguish: upload them to the wiki: wiki.linuxcnc.org, click Upload
[21:01:38] <rayh> Give em to someone with a faster connection than mine.
[21:04:44] <rayh> SWPadnos, Can you put into that page the essence of the Machinery Handbook definitions.
[21:05:02] <SWPadnos> jepler or cradek (or anyone else): to effectively comment out a section of a bash script, I should be able to use something like "cat <<COMMENT > /dev/null" before, and "COMMENT" after the block, right?
[21:05:07] <SWPadnos> rayh, sure. I can do that
[21:05:22] <SWPadnos> but they don't list formats, only the code numbers
[21:05:26] <cradek> SWPadnos: just put # in front of the lines
[21:05:33] <SWPadnos> there are a lot of lines
[21:05:38] <jepler> I'd do the same as cradek
[21:05:45] <jepler> Use the block-modify command in your editor
[21:05:46] <cradek> heh, first get a better editor, then put # in front of the lines
[21:05:46] <SWPadnos> the entire section of the runscript that loads motion
[21:05:53] <SWPadnos> :P
[21:05:56] <jepler> in vim, it would be <move to start> v <move to end> :s/^/#/
[21:06:11] <cradek> in emacs use M-x prefix-region #
[21:07:02] <SWPadnos> do you not need the ^ in the replacement text?
[21:07:07] <cradek> no
[21:07:12] <SWPadnos> (or \n or something)
[21:07:20] <cradek> that means "replace beginning of line with #"
[21:07:27] <jepler> ^ means "match at the beginning of the line"
[21:07:45] <jepler> it doesn't match any characters itself, so when you "replace" it with # the effect is inserting #
[21:07:54] <SWPadnos> I know - forgot that it means "match the 0-length string at after the beginning of the line"
[21:08:06] <SWPadnos> kate does it just fine - thanks
[21:08:11] <jepler> If you wanted to comment all lines beginning with "m", it would be s/^m/#m/
[21:08:17] <SWPadnos> right
[21:08:21] <jepler> oh, you have someone there who's able to use vim for you?
[21:08:28] <jepler> </smartass>
[21:08:29] <cradek> haha
[21:08:31] <SWPadnos> yes, she's very pretty ;)
[21:08:43] <cradek> uh, girls can't use vim, can they?
[21:08:48] <jepler> cradek: Ingrid does
[21:08:50] <SWPadnos> my girls can
[21:08:57] <cradek> shows what I know
[21:09:01] <Roguish> ok, just uploaded the pictures. not too big, about 50k each.
[21:09:01] <SWPadnos> actually, my wife would probably die trying to get out of vim
[21:09:08] <jepler> SWPadnos: Alt-F4 works
[21:09:36] <SWPadnos> heh - she'd need to know that one too ;)
[21:09:55] <SWPadnos> (she does on Windows, but might not think it would work on Linux)
[21:10:09] <rayh> Roguish, Do you have the urls for them?
[21:10:46] <SWPadnos> hmmm - making the ini load motion is a little harder - it needs math, or to have the *_PERIODs set in nanoseconds
[21:10:55] <Roguish> what? of the uploads? how would i get that?
[21:11:04] <SWPadnos> where did you put them?
[21:11:08] <cradek> SWPadnos: are you going to break my configs again?
[21:11:11] <SWPadnos> yes
[21:11:16] <SWPadnos> optionally, of course
[21:11:26] <jepler> optionally broken?
[21:11:31] <SWPadnos> jmk will rip out the sruff from the runscript, and eliminate the option ;)
[21:11:40] <SWPadnos> stuff, too
[21:11:46] <cradek> ok, just wondered...
[21:11:59] <Roguish> in what ever the default upload place is.
[21:12:05] <alex_joni> cradek:
http://wiki.linuxcnc.org/uploads/
[21:12:26] <cradek> I think rayh was asking so he could link them into the wiki page
[21:12:49] <Roguish> ya, that should be it. i gotta run meet a carpet cleaner. i will try to get some g code out of mastercam later today. ciao.
[21:13:37] <rayh> Thanks
[21:14:08] <alex_joni> rayh: upload:tool_path_parameters.jpg should work I think
[21:15:34] <alex_joni> cradek: one #ifdef LATHE is left, the one about G80+
[21:15:42] <alex_joni> the others are gone
[21:15:56] <cradek> yay
[21:16:08] <alex_joni> checking in now
[21:16:23] <alex_joni> oh, forgot to compile :(
[21:18:00] <alex_joni> ok, compiles cleanly
[21:20:17] <alex_joni> it's even running
[21:21:14] <alex_joni> cradek: got 5 mins before I leave?
[21:21:18] <cradek> sure
[21:21:43] <alex_joni> * alex_joni is looking for a NML message
[21:22:03] <alex_joni> it should be EMC_TRAJ_foo imho
[21:22:48] <alex_joni> da
[21:23:02] <alex_joni> darn even CIA is slow today
[21:23:54] <SWPadnos> hmmm - well, that won't work
[21:24:04] <alex_joni> SWPadnos: what won't ?
[21:24:07] <cradek> EMC_TRAJ_SYNCHRONIZE
[21:24:16] <alex_joni> cradek: yes, something like that
[21:24:22] <SWPadnos> the runscript runs all HALFILEs before it runs any HALCMDs
[21:24:25] <cradek> double feed_per_rev;
[21:24:55] <cradek> 0 means unsynced?
[21:25:00] <cradek> or should there be an unsync message too?
[21:25:12] <alex_joni> I wouldn't want to clobber with messages
[21:25:30] <cradek> ?
[21:25:35] <alex_joni> better have an byte synch; (0=unsynched, 1=synched)
[21:25:46] <alex_joni> if you are worried about feed_per_rev==0
[21:25:53] <cradek> ok
[21:25:59] <alex_joni> cradek: there are far too many NML messages already
[21:26:00] <cradek> well that would be a stupid synchronization
[21:26:03] <SWPadnos> damn. never save a new copy of the emc script while emc is running
[21:26:06] <alex_joni> indeed :)
[21:26:09] <cradek> ok just do one message then
[21:26:24] <alex_joni> one messag, double feed_per_rv;
[21:26:29] <cradek> rev
[21:26:33] <alex_joni> AAARGH
[21:26:37] <cradek> ??
[21:26:43] <alex_joni> my 'e' key again
[21:26:44] <cradek> oh, your e key again
[21:26:48] <cradek> haha
[21:27:06] <alex_joni> 'messag' and 'feed_per_rv'
[21:27:23] <alex_joni> damn .. it does work ok, but it depends on the pressing point
[21:27:37] <alex_joni> if I push it a bit sideways it won't work anymore
[21:28:10] <alex_joni> cradek: you know that adding a new NML message will probably mean AXIS will need to get fixed too...
[21:28:18] <cradek> that's fine
[21:28:24] <cradek> that's what TESTING is for
[21:28:33] <alex_joni> * alex_joni starts doing that
[21:28:54] <cradek> you also have to make an EMCMOT cmd_code, right?
[21:29:04] <alex_joni> yes, but that's a bit later
[21:29:11] <cradek> ok
[21:29:12] <alex_joni> I also need to do canon
[21:29:16] <cradek> going for a snack
[21:29:18] <alex_joni> and the task stuff first
[21:34:47] <SWPadnos> ok, motion now loads from a hal file just fine, and could work from the ini if the HALCMD and HALFILE execution order were reversed (or they were done in file order)
[21:35:13] <SWPadnos> except that the PERIOD vars need to be in ns, not seconds
[21:36:31] <SWPadnos> here's what the line looks like in my new-style univstep_load file:
[21:36:42] <SWPadnos> loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD_NS servo_period_nsec=[EMCMOT]SERVO_PERIOD_NS traj_period_nsec=[EMCMOT]TRAJ_PERIOD_NS key=[EMCMOT]SHMEM_KEY
[21:38:35] <alex_joni> doesn't look that bad
[21:39:09] <SWPadnos> heh. yes it does ;)
[21:39:30] <rayh> just got a call telling me about a problem with reset or m2
[21:39:44] <cradek> what version?
[21:39:53] <alex_joni> what's G84 again?
[21:39:56] <rayh> ubuntu from a week ago.
[21:40:07] <rayh> I see the same thing here.
[21:40:30] <cradek> uh-oh, what is it?
[21:40:30] <rayh> In tkemc the listing of feedrate changed to metric.
[21:40:52] <cradek> with inch user units?
[21:42:54] <cradek> I get it too, if I MDI m2
[21:43:06] <cradek> stepper_inch TESTING-2006-03-12
[21:44:21] <cradek> it doesn't even require m2
[21:44:30] <cradek> in MDI: g1x1 / x.5
[21:44:43] <SWPadnos> just F1 / M2
[21:44:51] <SWPadnos> or F10 M2, for better precision ;)
[21:45:04] <SWPadnos> (on separate lines, of course)
[21:45:06] <cradek> but it doesn't actually speed up
[21:45:09] <rayh> Let me look at the ini
[21:45:10] <cradek> it's just reported wrong
[21:45:38] <alex_joni> * alex_joni wonders who might be responsible ..
[21:45:51] <cradek> * cradek points at alex
[21:45:59] <rayh> Okay. It was fixed in emc by a code in the general section of the ini.
[21:46:02] <alex_joni> yeah, I bet you do
[21:46:07] <rayh> That does not seem to work here though.
[21:46:20] <cradek> rayh: explain
[21:46:27] <SWPadnos> you mean DEFAULT_UNITS?
[21:46:42] <rayh> In emc(1) we could place a variable in the ini file
[21:47:16] <rayh> RS274NGC_STARTUP_CODE = G20
[21:47:39] <rayh> And that would make the interpreter default/reset to inch units.
[21:48:35] <cradek> I don't think there's a problem with defaults here, it defaults to the right units, but it later changes
[21:49:11] <SWPadnos> using the startup code, you get the square of the problem
[21:49:32] <SWPadnos> ie, if you have F10 (inch), and issue M2, then you get the displayed number F254, as expected
[21:49:44] <SWPadnos> only it changes to F6452 if you issue G21
[21:50:20] <SWPadnos> whereas before it would correctly go back to F10 if you did G21 / G20
[21:50:40] <cradek> man I hate these units problems
[21:53:32] <alex_joni> SWPadnos: any idea since when?
[21:55:47] <SWPadnos> nope
[21:56:26] <SWPadnos> is it emcTaskPlanInit that gets called on M2 or reset?
[21:56:47] <alex_joni> this is not M2 related
[21:56:50] <alex_joni> try this:
[21:56:54] <alex_joni> G1X1F10
[21:56:57] <alex_joni> X0
[21:57:46] <SWPadnos> indeed
[21:57:57] <alex_joni> and it does not appear on stepper_mm
[21:58:24] <alex_joni> only when switching from mm to inch (G20 & G21)
[21:58:31] <alex_joni> something is backwards here
[21:58:41] <SWPadnos> what if you add RS274NGC_STARTUP_CODE = G20
[21:58:41] <cradek> in mm, user units and internal units are the same
[21:59:32] <SWPadnos> jepler (or cradek), axis should use a float format for the F word
[21:59:39] <SWPadnos> like 1 decimal place or more
[22:02:55] <alex_joni> cradek: does it show in AXIS too?
[22:03:06] <cradek> alex_joni: yes
[22:03:37] <alex_joni> do you remember where the feedrate comes from?
[22:03:41] <alex_joni> EMC_STAT?
[22:04:45] <cradek> I think so, but I don't see it in emctop
[22:06:00] <cradek> stat.settings[1]
[22:06:22] <alex_joni> settings[] sounds like interp
[22:06:25] <cradek> and it is wrong in the stat buffer
[22:08:14] <cradek> I think it's stat.task.activeSettings[1]
[22:08:16] <alex_joni> emcStatus->task.activeSettings[1] ?
[22:08:22] <cradek> yes
[22:08:35] <alex_joni> sprintf(string, "F%.0f ", emcStatus->task.activeSettings[1]);
[22:10:15] <jepler> fix committed to axis
[22:10:19] <jepler> (to show one decimal place)
[22:15:00] <alex_joni> ok, think I found it
[22:16:23] <alex_joni> argh, not fully..
[22:16:38] <alex_joni> it does work better, but not when switching G20/G21
[22:30:21] <jepler> if I'm in inches, set F10, then change to metric, isn't the correct feedrate F254?
[22:30:33] <jepler> (since I'd have to type F254 into the interpreter to set the same feed rate)
[22:30:37] <alex_joni> jepler: yes, and that doesn't work
[22:30:44] <alex_joni> :(
[22:30:53] <jepler> oh -- I thought that's what it was doing
[22:30:58] <alex_joni> it works somehow reversed
[22:31:06] <alex_joni> when you go from inch to mm it stays 10
[22:31:16] <alex_joni> but when switching back to inch it shows 254
[22:31:20] <jepler> hmm
[22:31:27] <alex_joni> at least over here
[22:33:13] <alex_joni> typing M2 makes it show the right value though
[22:35:12] <jepler> yeah I'm seeing the same behavior here
[22:39:01] <alex_joni> ok, think I start to understand it
[22:39:12] <alex_joni> try pushing G21 twice when you change units
[22:39:17] <alex_joni> and then G20 twice
[22:39:57] <alex_joni> it seems that when the stuff gets asked it's not converted yet, but it gets converted shortly afterwards
[22:52:26] <alex_joni> jepler, cradek: any of you still there?
[22:52:30] <jepler> I'm here
[22:52:48] <alex_joni> http://cvs.sourceforge.net/viewcvs.py/emc/emc2/src/emc/task/emccanon.cc?r1=1.34&r2=1.35
[22:53:31] <alex_joni> I think that's responsible for this
[22:53:53] <alex_joni> currentLinearFeedRate is not in EXT units, but internal (mm)
[22:54:40] <alex_joni> I already commited a fix for that, but the problem is that lengthUnits (another internal param) which gets used for TO_PROG_LEN() isn't updated when it should
[23:02:31] <alex_joni> jepler: do you remember what NML gets sent on MDI input?
[23:04:09] <jepler> I can check
[23:04:41] <jepler> EMC_TASK_PLAN_EXECUTE ?
[23:05:08] <SWPadnos> yep
[23:05:13] <alex_joni> yeah..
[23:12:22] <alex_joni> oh, damn this is fscked
[23:12:57] <alex_joni> I wonder how it worked...
[23:25:27] <alex_joni> hmm.. I think I start to have a picture of what's wrong
[23:25:33] <alex_joni> anyone interested?
[23:30:04] <alex_joni> well, I'll say either way ;)
[23:30:23] <alex_joni> the GUI's get the feed value out of a STAT NML message
[23:30:46] <alex_joni> the problem is that the NML STAT message gets sent right away as a reply to the command
[23:31:58] <alex_joni> so when a command to change units is received (G20 || G21) a reply is sent imediately with the old feedrate in it. only after that the unit changing gets done, and the correct feed rate is calculated.
[23:32:35] <alex_joni> so any subsequent EXEC command will trigger the display change (as the new STAT NML message will hold the correct value)
[23:33:33] <cradek> alex_joni: did we recently break this?
[23:33:43] <alex_joni> cradek: yes & no
[23:33:55] <alex_joni> fixing one problem revealed this one
[23:34:29] <alex_joni> http://cvs.sourceforge.net/viewcvs.py/emc/emc2/src/emc/task/emccanon.cc?r1=1.34&r2=1.35 <- that's the change I suspect of beeing responsible
[23:35:13] <cradek> yuck
[23:36:39] <alex_joni> yes, double yuck
[23:37:03] <alex_joni> the old one is imo very wrong
[23:37:12] <alex_joni> and the new one is not quite correct either :(
[23:37:28] <alex_joni> well, it is correct, it just doesn't display what it should on the GUI
[23:39:09] <alex_joni> darn.. maybe in the morning with a clear head..
[23:39:13] <alex_joni> * alex_joni goes to bed
[23:39:45] <alex_joni> cradek: want to hunt on this bug?
[23:39:57] <alex_joni> I could provide some insight before going away..
[23:40:56] <rayh> I've just about got the start of a lathe code page.
[23:42:49] <alex_joni> rayh: I fixed partly the bug you've seen
[23:42:56] <alex_joni> but it's harder than I expected
[23:43:31] <rayh> Great. I'll check out and do some testing.
[23:44:00] <rayh> I know that units have given lots of folk fits.
[23:44:30] <rayh> I sure appreciate the work of all you guys.
[23:44:37] <alex_joni> right now it works as it should, but it displays it wrong just after the G20/G21 switch
[23:44:51] <alex_joni> if you enter a new command then it will display the right value
[23:45:31] <rayh> Okay. That'll help. I'll get to the guy that called with that info.
[23:46:18] <alex_joni> I think it's still a bit wrong in the TESTING
[23:46:21] <alex_joni> I only changed HEAD
[23:46:48] <rayh> mp
[23:48:47] <rayh> np
[23:48:53] <rayh> that's better.
[23:50:50] <alex_joni> got to figure out how come it used to work :-?
[23:57:58] <rayh> That may be nearly impossible.
