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