Back
[00:07:51] <KimK> cradek: still around? BTW, I couldn't wait, I re-gitted(?) and re-cloned, and things are lots better now, although I would have liked to know what I did wrong and how to fix it. But on the bright side, I'm almost done with 7 of the 8 commits I wanted to get out tonight, so that's a good thing. Anyway, I have a Q on lathes for you:
[00:12:15] <KimK> In the lathe tool table, is it true that D can only be specified in absolute value? I know some CAM programs program the path and then expect you to set the D=0 if the tool is the exact size told to the CAM program. Then plus or *minus* is possible if the tool is a little small. So, negative tool diameters on a lathe: valid or not? (It's for the doc edits.)
[01:31:30] <cradek> negative D is fine
[01:31:40] <cradek> glad you got your git back in order... it's finicky.
[01:48:21] <Al_Smt> hey I got some changes I would like someone to look for tkemc.tcl I can get git to format a patch thats not the whole file
[01:48:26] <Al_Smt> http://pastebin.ca/1923023
[01:50:14] <Al_Smt> you have to use COORDINATES = X Y Z 0 0 0 0 0 W in the ini file
[01:50:59] <Al_Smt> and it will make tkemc.tcl display only the axis you want
[01:52:25] <Al_Smt> I also made it so it will use the ini to display the MACHINE = yours
[01:54:47] <Al_Smt> I can't get git to format*
[02:25:22] <Al_Smt> use this one instead
http://pastebin.ca/1923044 I cut something out of the other one
[03:30:15] <cradek> Al_Smt: can you say more? I don't understand what that COORDINATES setting would do.
[03:31:15] <Al_Smt> in the ini file you can chose the axis
[03:33:18] <cradek> sorry, I still don't understand what you mean
[03:33:36] <Al_Smt> in [TRAJ] section if you use 0 for a axis instead of a letter it will make tkemc just show the axis you want
[03:34:00] <Al_Smt> with the patch!
[03:34:27] <cradek> I thought tkemc already just shows the axes that are defined - am I wrong?
[03:34:53] <cradek> have you tried git master? it looks like you've modified an older version, since when I plug that file in, I get lots of changes that I don't think are related
[03:35:01] <Al_Smt> yes but if you want W you have to show them all
[03:35:26] <cradek> oh I see - I didn't know that
[03:35:47] <Al_Smt> can I use yahoo to mail a patch?
[03:36:01] <cradek> sorry I don't know anything about yahoo
[03:36:12] <Al_Smt> i'll try it
[03:37:46] <cradek> it looks like the git master version of tkemc is very close to working:
http://timeguy.com/cradek-files/emc/Screenshot-TkEMC.png
[03:38:21] <cradek> looks like it already knows how to skip undefined axes. Maybe you could fix this version instead?
[03:39:00] <cradek> I'm afraid if you base your changes on a version older than git master, we won't be able to incorporate the changes
[03:40:28] <Al_Smt> yes I made it so it only shows the axis you want not all 9
[03:43:45] <Al_Smt> cradek,
http://imagebin.org/110912
[03:45:15] <cradek> http://timeguy.com/cradek-files/emc/0001-Fix-tkemc-to-only-show-appropriate-coordinates.patch
[03:45:31] <cradek> Al_Smt: ^ this change to git master makes it work properly when I test an XYZW configuration
[03:46:15] <cradek> can you try it? It is compatible with the ways the other GUIs define skipped axes
[03:46:20] <cradek> AXES = 9
[03:46:21] <cradek> COORDINATES = X Y Z W
[03:46:29] <Al_Smt> wish I knew it was getting fixed
[03:46:32] <Al_Smt> ok
[03:46:42] <cradek> well I just did it
[03:46:51] <cradek> it was 99% correct already in git-master
[03:47:16] <Al_Smt> there is also a fix for displaying the MACHINE = in the ini
[03:48:34] <cradek> cool, I can easily add that
[03:49:04] <cradek> do you want to make a git patch with just that change, so you get credit for authorship, or do you want me to just copy those lines?
[03:49:26] <Al_Smt> copy those lines
[03:49:31] <Al_Smt> thanks
[03:49:36] <cradek> ok
[03:55:48] <cradek> hm, it doesn't work right
[03:56:22] <cradek> I've got lines for X Y Z W. when I click W and home, it sends EMC_AXIS_HOME 3, when it should be 8
[03:56:58] <cradek> W turns green but it's not W that is homed
[03:58:56] <cradek> if you want to finish getting it to work, you could apply these patches to your git master and then apply your fixes on top:
http://timeguy.com/cradek-files/emc/tkemc-patches.mbox
[03:59:55] <Al_Smt> yes it wont load here either
[04:01:03] <cradek> to get this integrated, you'll have to do your work against git master, and change tkemc so it's compatible with the COORDINATES and AXES settings as described here:
http://linuxcnc.org/docs/2.4/html/config_ini_config.html#sub:[TRAJ]-section
[04:01:28] <cradek> I appreciate you working on it - it would be great to get tkemc updated to handle skipped axes correctly.
[04:02:54] <Al_Smt> i made so if you use 0 instead of a letter it works and axis doesn't seem to mind it either
[04:04:10] <Al_Smt> i mailed to the developers list from yahoo we'll see if it gets there
[04:05:34] <Al_Smt> ya it made it
[04:22:38] <Al_Smt> good night
[09:32:24] <alex_joni> git pull
[09:32:34] <alex_joni> remote: Counting objects: 5582, done.
[09:32:38] <alex_joni> (that's a lot ;)
[11:56:51] <CIA-5> EMC: 03jthornton 07v2.4_branch * r0d8e9fb674be 10/docs/README: Fixed minor typos in docs/README
[12:12:48] <CIA-5> EMC: 03jthornton 07v2.4_branch * r0b39415845f4 10/docs/src/README: Fixed minor typos in docs/src/README
[12:12:48] <CIA-5> EMC: 03jthornton 07v2.4_branch * r62bf001f471c 10/docs/src/config/ini_homing.lyx: Fixed minor typos in docs/src/config/ini_homing.lyx
[13:45:07] <Al_Smt> cradek, if I change the if statement from a "0" to " " space it will act like axis does "tkemc.tcl"
[14:18:16] <cradek> Al_Smt: I'd be happy to review a new patch against git-master that's compatible with
http://linuxcnc.org/docs/2.4/html/config_ini_config.html#sub:[TRAJ]-section
[14:18:47] <jepler> looks like the docs got porked again by that latest push
[14:18:53] <jepler> * jepler shakes his fist at lyx
[14:21:28] <Al_Smt> i'll remail a copy now its going to start with 0002 on the developers list
[14:21:44] <cradek> ok
[14:50:42] <Al_Smt> cradek, matbe I should mail the whole file I'm having trouble with my git never has work right on this machine
[14:51:00] <Al_Smt> maybe ^
[14:51:22] <cradek> the patch you sent to the list seems to have unrelated changes in it. is it based on git-master? if you need help using git, maybe someone here can help
[14:53:01] <cradek> also, I don't understand the part where you changed it to use a larger font if there are more than three axes. That seems like opposite what you'd want.
[14:53:04] <cradek> +set axisnum $axiscount+1
[14:53:17] <cradek> also I'm pretty sure this line ^^ does not do what you want
[14:54:33] <Al_Smt> i used that to control the font size
[14:59:47] <Al_Smt> less than or equal to 3 axis for font
[15:00:41] <cradek> yes I can read what it says, but I'm saying it doesn't make sense. If there are less than or equal to three axes, make the font small, otherwise make it big? that is opposite the old logic which used a smaller font if there were many axes. The change does not make sense.
[15:01:06] <Al_Smt> no it work the opposite
[15:02:57] <Al_Smt> the old way you have to use 9axis to show xyw and it would show small font
[15:03:03] <SWPadnos> you changed "if $numaxes > 6" to "if $axiscount <= 3", that clearly changes the sense of the conditional
[15:04:16] <Al_Smt> small font for three axis's
[15:04:41] <SWPadnos> yes, and large for >3 axes
[15:04:48] <SWPadnos> which seems backwards
[15:05:18] <Al_Smt> because numaxes comes from the ini coordinates spec
[15:06:46] <SWPadnos> regardless of whether the number of axes is calculated or read from the ini file, the comparison has been changed
[15:07:50] <Al_Smt> why would you want small font for less than 4 axis's
[15:07:51] <SWPadnos> also, as cradek has pointed out, your code doesn't actually calculate the number of axes correctly
[15:08:07] <SWPadnos> please read what I'm writing
[15:08:31] <SWPadnos> your code will choose a large font for more than 3 axes and a small font for 3 or fewer axes
[15:09:06] <Al_Smt> not here doesn't
[15:09:07] <SWPadnos> I would not want a small font unless there are too many axes to display correctly, which is the opposite of what the code actually does
[15:09:20] <Al_Smt> try it
[15:09:31] <SWPadnos> that's because you have an error in the calculation of the number of axes
[15:09:41] <SWPadnos> or the patch is incomplete
[15:10:08] <SWPadnos> your code will never set axiscount to anything other than 1
[15:10:26] <SWPadnos> and axisnum will be 2, if any axes are specified in the COORDINATES string
[15:10:53] <SWPadnos> so the comparison if $axiscount <= 3 will always be true, regardless of the number of axes specified
[15:11:43] <Al_Smt> if you look at the if statement it gets incr at set axisnum $axiscount+1
[15:11:52] <SWPadnos> axisnum is not axiscount
[15:12:17] <SWPadnos> you have the equivalent of "a = b+1"
[15:12:22] <SWPadnos> b is never changed
[15:14:01] <Al_Smt> but axiscount get incr for every if statement witch is true
[15:14:25] <SWPadnos> I don't think so. at least not in the code I see in the patch
[15:15:37] <Al_Smt> you are right
[15:15:59] <SWPadnos> hmmm. it seems you can't just add in tcl
[15:17:35] <SWPadnos> you may need something like set a [expr {$a + 1}]
[15:19:58] <tom3p> are arrays possible in .comp files?
[15:20:39] <SWPadnos> the braces aren't needed, set b [expr $a+1] works
[15:31:17] <cradek> incr a
[15:38:22] <Al_Smt> i'll try that
[15:43:30] <jepler> tom3p: arrays of pins and parameters are possible, though the syntax to refer to items in the arrays is different than in C (using (), not []). There's an example in the docs:
http://linuxcnc.org/docs/html/hal_comp.html#r1_13_5
[15:49:17] <Al_Smt> yes thats better incr a works
[15:52:29] <Al_Smt> how do i git master
[15:53:32] <Al_Smt> is it the same as branch?
[15:57:08] <tom3p> jepler, thanks, looking for data arrays, will hack example you gave
[15:58:58] <jepler> for per-instance data, you want a 'variable' declaration in the top section: variable int foo[32];
[15:59:55] <tom3p> can i resize such an array or do i size it for worst case?
[16:00:12] <tom3p> (havent got the hack up yet)
[16:00:15] <SWPadnos> you can't resize C arrays
[16:00:50] <jepler> you have to size it for the worst case
[16:01:13] <jepler> for 'variable []' you use [] for subscripting like in C, not () as for pin/parameter arrays
[16:01:47] <jepler> untested (beyond compile-tested) example of variable array:
http://emergent.unpy.net/files/sandbox/delay4.comp
[16:05:03] <tom3p> thanks, i used bresenham's integer line and circle to create path data, then wanted to index thru them ( a mini traj planner for sink edm )
[16:05:43] <skunkworks> I know this works static double RATIO[16]={.0310168, .0350028, .0397274, .0444520, .0804513, .0901584, .1025972, .1146178, .2073476, .2322251, .2640781, .2955130, .5356125, .5998969, .6817628, .7662554};
[16:07:36] <tom3p> skunkworks, thanks
[16:08:17] <jepler> that will make the data shared between all instances, which may or may not be what you want
[16:08:29] <jepler> in skunkworks's case there's only a single gear changer so it's fine
[16:08:42] <skunkworks> right
[16:08:50] <skunkworks> I get a headache thinking about that
[16:10:35] <SWPadnos> tom3p, how did you deal with the fact that bresenhams methods don't give constant-rate results?
[16:10:37] <SWPadnos> or did you>
[16:10:39] <SWPadnos> ?
[16:11:55] <tom3p> SWPadnos, happens on demand, there is no feedrate. When the process is ready for a step fwd it moves fwd in the array. when it need to retreat it move OFF PATH away from stock.
[16:12:13] <SWPadnos> ah, okj
[16:12:14] <SWPadnos> -j
[16:12:32] <tom3p> (or are you talking about the swr root of 2 angle move versus the single acis move ?)
[16:13:00] <SWPadnos> yeah - the effective feed rate changes whenever there's a "step" on the minor axis
[16:13:26] <tom3p> yeh we had to build a circuit on the old agie step wedms ( agie did not me )
[16:15:36] <tom3p> i think i best look at stream rather than array, getting the next position on demand was more difficult than just calculating all the possiblilties, but more sensible in memory use
[16:17:18] <SWPadnos> you're probably better off using "analog" computation. Bresenham was really meant for machines that couldn't deal with floating point math very well, which isn't a real issue on any near-modern CPU
[16:18:15] <SWPadnos> unless you're working with exceedingly small units (like 1 step/encoder count), you will also end up with a worse approximation of the intended path
[16:18:39] <SWPadnos> since the algorithm specifically waits until there is enough error for a step to be taken on the minor axis
[16:18:55] <SWPadnos> (rather than just moving proportionally the whole time)
[16:19:01] <tom3p> yes 1 step = 1 count, and bresenham is within 1/2 count of true path
[16:19:26] <SWPadnos> ok, in that case it shouldn't be any worse than the "continuous" path
[19:42:55] <Al_Smt> cradek,
http://pastebin.ca/1923555 patch for tkemc
[19:57:13] <cradek> Al_Smt: sweet! that looks like it works. thanks for making it a git patch.
[19:57:58] <cradek> weird - do the relative/machine/actual/commanded/joint/world radiobuttons work right for you?
[19:58:59] <Al_Smt> i believe so
[20:00:54] <Al_Smt> thank you
[20:02:15] <cradek> http://timeguy.com/cradek-files/emc/Screenshot-EMC-HAL-SIM-AXIS.png
[20:02:27] <cradek> this is how it looks for me - no indication which ones are checked
[20:08:45] <Al_Smt> ya mine are little diamond shape also
[20:10:15] <cradek> bizarre - but it's not your changes that did it - no big deal, that will wait for another day
[20:11:04] <cradek> it's probably a problem on lucid
[20:11:08] <Al_Smt> ok
[20:11:29] <CIA-5> EMC: 03cradek 07master * r4b9ca0270a9a 10/tcl/tkemc.tcl: make tkemc display only axis needed & show MACHINE from ini
[20:11:46] <CIA-5> EMC: 03cradek 07master * r87f95107927b 10/tcl/tkemc.tcl: remove unused/mistaken code
[20:12:08] <cradek> Al_Smt: thanks!
[20:12:39] <Al_Smt> glad help and thank you for all you do
[20:14:40] <andypugh> Does it still use 0 or is it now on "missing"? I ask only out of curiosity, I don't actually use tkemc
[20:15:02] <cradek> it works with the documented format for those lines
[20:16:46] <andypugh> OK, stored away in case anyone ever asks. :-)
[20:29:51] <jepler> cradek: it's a tk8.4 vs tk8.5 difference. In 8.4, the whole diamond gets filled with -selectcolor when selected and -background when not selected
[20:30:08] <jepler> in 8.5 the circle gets filled with -selectcolor and when selected a dot in the middle is filled with -foreground
[20:30:23] <jepler> emc sets -selectcolor and -foreground to white, so you get a white dot on a white background
[20:31:11] <cradek> jepler: so taking out the extraneous color specifications would make it work everywhere?
[20:38:50] <jepler> http://emergent.unpy.net/files/sandbox/0001-tkemc-fix-radiobutton-appearance.patch
[20:39:03] <jepler> particularly worth testing on 8.04 (where I think the checkbuttons are still diamonds)
[21:00:50] <alex_joni> mozmck: guess you read the latest message on the rtai mailing list
[21:01:05] <alex_joni> new patches for 2.6.23 and 24
[21:01:26] <alex_joni> err.. 32 and 34
[21:28:19] <Al_Smt> jepler, that radio button patch looks like works on 8.04
[22:08:52] <jepler> al_smt: thanks for testing
