Back
[01:05:24] <cradek_> a pull just now gave me reasonable results
[01:40:39] <cradek_> cradek_ is now known as cradek
[04:55:13] <psha> good morning all
[15:04:09] <micges> cradek: around?
[15:18:10] <psha> micges: may you help me with tkinter?
[15:41:40] <micges> what is your problem?
[15:42:09] <cradek> micges: off and on
[15:43:13] <psha> i'm trying to embed gtk app into tk
[15:43:53] <psha> tk docs say that i need to create frame and then just get it's XID
[15:44:03] <micges> cradek: I have problem with cutter radius compensation
[15:44:08] <psha> and then pass it to doughter app
[15:44:22] <psha> at least mplayer inside axis is working fine )
[15:44:47] <psha> but i'm impossible to figure out whit gtk apps fail to embed :(
[15:45:27] <psha> at least it seem now that problem is on gtk side...
[15:46:07] <micges> psha: for me using gtk and tk at the same time never works
[15:46:30] <psha> with xembed?
[15:48:43] <micges> no idea
[15:49:19] <psha> at least i may embed it into touchy...
[15:49:45] <micges> cradek:
http://imagebin.ca/view/ixNY48.html
[15:50:29] <micges> cradek: question is: is it intended that last move is not shortened by D value ?
[15:51:21] <micges> cradek: or is it intended to user to add lead out move after comp if off?
[15:55:09] <cradek> looking
[15:56:08] <cradek> you should move away from the work before turning off cutter comp
[15:56:52] <cradek> the only time it makes sense to shorten that move to Y80 is if the next move will be a left turn. it is wrong for ccomp to assume this and wrong for you to expect it
[15:57:37] <cradek> the move immediately after turning ccomp ON and OFF both should be carefully considered and part of the path you program
[15:59:54] <cradek> does that answer help?
[15:59:59] <micges> looking
[16:01:36] <micges> http://imagebin.ca/view/Hr65raOQ.html
[16:02:51] <cradek> yes now you made another inside corner with line 11
[16:03:18] <cradek> what are you trying to do exactly? I think I don't understand what you are asking me
[16:04:05] <micges> I'm trying to cut rectangle in some metal sheet using ccomp
[16:04:33] <micges> I'm trying do determine how to use ccomp with my gcode generator
[16:05:55] <cradek> normally to cut inside a pocket you'd plunge in the center somewhere, G42, tangent arc to get against the edge you want to keep, cut around, tangent arc away from the edge to get back into the center, then go up, then G40
[16:06:51] <cradek> cutting exactly a square is tough because there when you program 4 lines you only define 3 corners
[16:07:42] <cradek> to make 4 corners where you want you must control at least 5 moves
[16:08:12] <micges> thanks I'll try
[16:08:32] <cradek> maybe you need to use tangent arcs at the entry/exit corner if you want to make an offset rectangle starting at a corner
[16:09:26] <micges> it's plasma cutter, there can't be exit move
[16:09:59] <cradek> can you start at the center of a side instead of a corner? then you can make your rectangle with 5 moves and define all 4 corners
[16:10:42] <micges> yes I'm trying it now
[16:14:56] <micges> it works, thanks
http://imagebin.ca/view/rH07HD.html
[16:15:39] <micges> now I must figure it out to use arc as entry move, and that's it
[16:15:44] <cradek> looks like it does not cut the full rectangle
[16:16:04] <cradek> yes a quarter circle tangent arc on line 6 will fix it
[16:17:51] <cradek> line 4: g0 x70 y80, line 6: g3 x50 y100 i-20 j0
[16:19:10] <cradek> (untested!)
[16:20:20] <micges> http://imagebin.ca/img/73Xf2PBT.png
[16:20:51] <cradek> perfect!
[16:20:54] <micges> when entry move is line it doesn't cut full rectangle
[16:20:57] <micges> now it ia
[16:20:59] <micges> is
[16:21:09] <cradek> yes because the entry move goes into a concave corner
[16:21:26] <cradek> if you entered convexly (is that a word?) you'd get the corner cut
[16:21:54] <cradek> see here:
http://linuxcnc.org/docs/2.4/html/gcode_tool_compensation.html#r1_3_1_2
[16:22:02] <micges> hmm
[16:22:17] <cradek> I think the tangent arc is the best way to enter for your situation
[16:22:20] <micges> when I've started ccomp it doesn't seems so compilcated :)
[16:22:35] <cradek> you can make it much smaller - as long as the radius is greater than the tool radius
[16:22:57] <micges> ok
[16:23:58] <cradek> is this for kerf compensation?
[16:24:53] <cradek> I bet every control needs different entry/exit programming :-/
[16:25:56] <micges> kerf? width of cutter row?
[16:26:55] <cradek> yes sorry, kerf is amount of material lost when cutting, like width of a saw blade
[16:27:17] <micges> yes it's for it
[16:27:54] <cradek> neat - saw someone else doing that for plasma too - I forget who it was
[16:28:34] <micges> I have postporcessor that is doing it , but it wans't 100% working correctly
[16:29:08] <micges> so I'm trying to use emc's , it's much more well tested
[16:29:17] <cradek> :-)
[16:29:27] <micges> maybe John Thornton?
[16:29:29] <cradek> emc is pretty good at it now :-)
[20:57:12] <jepler> prompted by micges's recent commit, let me suggest
http://emergent.unpy.net/files/sandbox/0001-Get-rid-of-predefined-return-value-strings.patch
[21:02:22] <psha> jepler: only replaces NCE_.* -> _("...") and includes changed from rs274_return.h -> interp_return?
[21:04:01] <cradek> @@ -1419,7 +1419,7 @@ is slightly funny
[21:05:01] <cradek> do you know about how many errors were previously generated at more than one place?
[21:05:34] <cradek> I am slightly worried that the messages will proliferate after this change
[21:08:12] <jepler> cradek: yes, it probably will. but it would also have prevented the bug fixed at 7c729112
[21:09:05] <cradek> yeah
[21:13:51] <psha> jepler: sorry to bother you but any chance for review? )
[21:20:15] <cradek> psha: thanks so much for working on that hard stuff
[21:20:31] <cradek> fixing probing in subroutines would be really great
[21:23:31] <psha> And while here are so many devs
[21:23:56] <psha> While patching halui I've added halui_size.h file that must be regenerated from halui.cc
[21:24:16] <psha> But something goes wrong and sometimes build fail
[21:24:52] <psha> I've not digged in build system so maybe i make something wrong
[21:25:07] <cradek> how does it fail?
[21:25:33] <psha> silently :)
[21:26:08] <psha> g++ -Wl,-rpath-link,../lib -o ../bin/usrmot -Wall -g -I. -I/usr/realtime-2.6.32-122-rtai/include -DULAPI -D_GNU_SOURCE -Os -DLOCALE_DIR=\"/usr/share/locale\" -DPACKAGE=\"emc2\" objects/emc/usr_intf/usrmot.o objects/emc/motion/usrmotintf.o objects/emc/motion/emcmotglb.o objects/emc/motion/emcmotutil.o objects/emc/motion/dbuf.o objects/emc/motion/stashf.o ../lib/libemc.a ../lib/libnml.so.0 ../lib/libemchal.so.0 ../lib/libemcini.so.0
[21:26:14] <cradek> oh you have made a circular dependency haven't you?
[21:26:15] <psha> make[1]: Leaving directory `/tmp/tmp.XP65Uf81bp/rbld.IU7m3K/debian/src/src'
[21:26:17] <psha> make: *** [build-stamp] Error 2
[21:26:39] <cradek> a is generated from b, and b includes a?
[21:26:46] <psha> no
[21:26:56] <psha> b from a, c from a and b
[21:27:22] <psha> +emc/usr_intf/halui_size.h: emc/usr_intf/halui.awk emc/usr_intf/halui.cc
[21:27:23] <psha> +awk -f $^ > $@
[21:27:30] <cradek> halui_size.h depends on halui.cc
[21:27:35] <psha> http://thread.gmane.org/gmane.linux.distributions.emc.devel/3553
[21:27:40] <psha> Hm
[21:27:41] <psha> really
[21:27:54] <psha> Forgot of generated deps
[21:29:21] <psha> May use stamp file instead...
[21:29:41] <cradek> I'm having trouble thinking of the right way to do it
[21:29:56] <psha> so stamp generated from a, a depends on b and everything breaks since there is no rule to build b
[21:30:29] <psha> There is another way to fix it
[21:30:34] <psha> Just include generated file
[21:30:36] <psha> )
[21:31:11] <psha> I suspect that make fails because there is no halui_size.h file on stage of generating deps
[21:31:34] <cradek> I think the fundamental problem is that you are causing a file that has both handwritten and (via inclusion) autogenerated code in it
[21:31:35] <psha> I'll try tommorrow to add empty/full _size.h file and look what happens
[21:32:11] <psha> So I'll generate C file
[21:32:20] <psha> And then just link it with halui.o
[21:32:45] <cradek> yes if you have some kind of description that generates both c and h, the c can include the h
[21:32:54] <cradek> ... I think
[21:33:09] <psha> h is needed for sizeof()
[21:33:27] <cradek> I don't understand the patch or the problem it fixes - I need to read it a few more times
[21:33:29] <psha> it's possible to generate C and place const int with list size there
[21:34:12] <psha> problem is that while halui processes some pins other may change their state
[21:34:21] <psha> so it lead to incosistency
[21:35:14] <psha> example is in first message
[21:35:20] <psha> http://thread.gmane.org/gmane.linux.distributions.emc.devel/3552
[21:35:45] <cradek> right
[21:35:57] <cradek> (side comment: why not use home-all)
[21:36:14] <psha> home all is only available when homin sequence is set
[21:36:18] <cradek> I am a little surprised that the messages are not lost at the nml level when you generate lots at once
[21:36:25] <psha> and when you have no homing sequence it's useless
[21:36:44] <cradek> sure, that's by design...?
[21:37:00] <psha> think so
[21:37:16] <psha> but it seem that it's not implemented everywhere
[21:37:21] <cradek> what do you mean?
[21:37:38] <psha> wait a bit
[21:37:42] <cradek> ok
[21:38:10] <psha> http://linuxcnc.org/docs/2.2/html/config_ini_homing.html
[21:38:27] <psha> Docs says that you need feedback from hardware to implement homing sequence
[21:38:38] <cradek> nah
[21:38:39] <psha> not implement but run
[21:38:47] <psha> wrong?
[21:39:23] <cradek> 0.1.2 having "sequence" in title is misleading
[21:39:38] <cradek> 0.1.3.8 HOME_SEQUENCE is what we're talking about
[21:40:13] <cradek> more current:
http://linuxcnc.org/docs/html/config_ini_homing.html
[21:40:19] <psha> o
[21:40:21] <psha> stupid me :(
[21:40:33] <psha> thanks :)
[21:41:04] <cradek> each joint can have its own choice of the homing behaviors under 0.1.2
[21:41:26] <cradek> you can do them in any order (or together) defined by HOME_SEQUENCE 0.1.3.9
[21:41:48] <cradek> not stupid - complicated and slightly confusing
[21:42:27] <psha> yea, word 'sequence' is used too often in that chapter :)
[21:42:32] <cradek> yes
[21:42:35] <psha> so it confused it
[21:43:09] <psha> hm
[21:43:22] <psha> have to sleep...
[21:43:37] <psha> typing something wierd :)
[21:44:02] <cradek> goodnight, and thanks for your work
[21:44:03] <psha> at least i've found why it was not possible to embed GTK application into axis :D
[21:44:13] <psha> bb
