Back
[02:42:09] <cradek> yay
[02:42:21] <cradek> grumbly mechanical problem on jr is fixed
[02:42:27] <cradek> wheeee
[02:57:53] <cradek> I turned up the accel on X,Y to 60 - it is FAST
[02:58:32] <cradek> or maybe it's 80, I don't remember
[02:58:32] <cradek> it doesn't quite sounds stable at 100
[02:58:32] <cradek> sound
[03:00:18] <cradek> velocity 7.5 ips / 60 ips2 = 1/8 sec to full speed
[07:21:03] <alex_joni> cool
[07:46:41] <micges_work> hello
[07:48:28] <alex_joni> hi
[12:51:05] <jepler> cradek: cool
[16:58:31] <cradek> hm, I saw a bad behavior - running after TnM6G43 with TLO not applied - trying to figure out if it's my changes
[17:06:28] <micges> cradek: can you describe some more?
[17:06:53] <cradek> let me troubleshoot more before I bother anyone with it
[17:07:02] <cradek> it's probably a random_toolchange bug
[17:07:13] <micges> I think I've catched this behavior some time ago
[17:07:23] <micges> but ok
[17:22:32] <cradek> yeah it was just my bug - false alarm
[17:22:45] <micges> oh
[18:05:48] <CIA-8> EMC: 03cradek 07random_toolchange * r38914a3f7b2f 10/ (108 files in 36 dirs): Merge branch 'master' into random_toolchange
[18:05:56] <CIA-8> EMC: 03cradek 07random_toolchange * r415a0b937031 10/nc_files/arcspiral.ngc: for testing TLO
[18:05:57] <CIA-8> EMC: 03cradek 07random_toolchange * rd78a0f310bd3 10/src/emc/rs274ngc/interp_convert.cc: fix getting the wrong TLO when M6 and G43 were in the same block
[18:06:43] <cradek> oh good, maybe I got that right
[18:07:10] <micges> cradek: how did you do merge without flooding ?
[18:07:27] <cradek> I fixed the logger script
[18:07:44] <micges> cool
[18:08:24] <cradek> well maybe not, I bet it won't show a cherry pick from master to a branch now
[18:08:58] <cradek> I guess I don't know what it SHOULD do so I'm having trouble writing it
[18:09:09] <cradek> I bet this is fine
[18:09:42] <micges> if you say so
[18:43:30] <micges> today I discovered something strange: I have hal module that sending commands to halui, commands rate is about 5 per second HALUI create and send proper NML commandd, if while sending this commands from hal to halui I hit Escape in Axis, then Task_abort NML command sended by c.abort() thought the same(I think) NML channel is lost, but by design it shouldn't be queued or buffered?
[18:46:44] <CIA-8> EMC: 03cmorley 07master * r34fb6c2f2b84 10/src/emc/usr_intf/pncconf/pncconf-help/ (help-axisconfig.txt help-axismotor.txt): Add axismotor / axisconfig help pages
[18:46:54] <CIA-8> EMC: 03cmorley 07master * rdeee0e9cc770 10/src/emc/usr_intf/pncconf/pncconf.py: Fix typo in mesa firmware SVST8_4iM2 data
[19:52:36] <christel> [Global Notice] Hi all, one of our american hubs appear to be having some issues presently, we're looking into it and hopefully will have things back to normal shortly. It may be slightly noisy should we need to re-hub
[20:08:10] <christel> [Global Notice] Hi all, re-hubbing nearing completion, I will also need to move services to a different location, this means NickServ, ChanServ and other *Serv's will go down for a few minutes. Apologies for the inconvenience and thank you for using freenode.
[20:40:48] <aystarik> I'm trying to see the XYZA program with Z and Y near zero, and initially it shows as thin line along X. If I then touch off Z to be 10 mm higher, program redraws itself as a barrel... Is it a bug in AXIS or something is wrong with my setup?
[21:22:44] <micges> aystarik: can you pastebin.ca your config?
[21:22:51] <micges> ini + hal
[21:33:49] <aystarik> http://pastebin.ca/1557716
[21:34:30] <aystarik> http://pastebin.ca/1557717
[21:35:52] <micges> did you changed anything ? they seems tyo me like standard sim configs
[21:36:17] <aystarik> I've added A and W axis to axis_mm config
[21:36:59] <micges> there is no such things in configs files you pasted
[21:40:06] <aystarik> http://pastebin.ca/1557724
[21:40:47] <aystarik> http://pastebin.ca/1557725
[21:40:56] <micges> thats better
[21:41:21] <aystarik> I've changed to master branch, and all the changes were left in v2_3_branch. :)
[21:41:53] <micges> ok so AXIS_4 must be changed to AXIS_8 first in ini
[21:42:14] <alex_joni> GEOMETRY = XYAZ
[21:43:08] <micges> shouldn't be GEOMETRY = XYZA ?
[21:43:26] <alex_joni> depends on the machine
[21:43:41] <micges> ok
[21:43:50] <alex_joni> but a machine where A is before Z the program should look like aystarik described earlier
[21:44:04] <aystarik> I've tried XAYZ, but this is the same
[21:44:28] <alex_joni> aystarik: maybe you should describe your A axis
[21:44:47] <alex_joni> is it something that moves the part?
[21:44:54] <alex_joni> or mounted on the spindle head?
[21:44:57] <aystarik> If I have knee mill with A parallel to X, what GEOMETRY will be right?
[21:46:04] <alex_joni> I think XYZA
[21:50:47] <aystarik> alex, is there any way to show cylinder engraving program as a cylinder, rather than a line? G54 is set up on a surface.
[21:58:05] <aystarik> XYZA does not work. If I remember correctly, XAYZ is the right, as it is basically order of transformations applied to the trajectory point. There is no sence to rotate a point, you must do some linear transformation after to have an effect (like offset Z or Y)
[22:01:58] <cradek> touching off Z should change the effective radius of the program
[22:02:09] <cradek> and that sounds like that is what you are describing
[22:03:12] <cradek> setting Z0 near A's rotation gives a small radius. Changing offsets so Z0 is further from A's center of rotation gives a larger radius for the same program
[22:05:12] <aystarik> how does it work exactly? what is the point of rotation for A?
[22:05:35] <aystarik> is it machine 0?
[22:06:02] <cradek> you should set up homing so unoffset Z0, Y0 puts the reference tool (no tool length offset) at the center of rotation of A
[22:06:13] <cradek> then no matter how you use offsets, the preview will show correctly
[22:06:54] <cradek> this is the same way you configure a lathe so unoffset X0 puts the reference tool at the center of rotation
[22:08:33] <aystarik> sorry, I've lost you... my homes are at machine 0. Do I need to change it to be at A rotation ?
[22:08:57] <cradek> yes I think so
[22:09:51] <aystarik> this is not very convinient, as rotary table is optional and not mounted permanently.
[22:10:26] <cradek> if you have T slots, maybe you could key it so it mounts in the same place every time?
[22:10:59] <cradek> or you could have two emc configs
[22:11:07] <cradek> or you could go without the A preview
[22:12:02] <aystarik> it's engraving, so everyone is fond of being able to preview the work
[22:14:08] <micges> good night all
[23:00:34] <danielfalck> I have a rs274 interperter question regarding arcs:
[23:00:49] <danielfalck> I'm using the rs274 int standalone
[23:01:01] <danielfalck> and I am looking at the format that it spits out arc
[23:01:22] <danielfalck> and I notice that the 'center' or 'axis' as it's called is on an outside corner
[23:01:31] <danielfalck> instead of the center of the arc
[23:01:40] <danielfalck> has anyone ever noticed that before?
[23:01:59] <danielfalck> and if that's the case, how is it processed later on?
[23:02:51] <danielfalck> by the way, I'm using Mark Pictor's version from rs274ngc.googlecode.com
[23:03:15] <danielfalck> which - I think- is very similar to the emc rs274 interpreter
[23:03:56] <danielfalck> the reason I'm into this, is I'm running it on Mac OS X and playing with it-nothing critical
[23:04:10] <danielfalck> no machines to crash :)
[23:06:00] <jepler> well -- we know even less about code that's not in emc2 than we know about code that is in emc2
[23:06:20] <danielfalck> makes for a challenge :)
[23:06:39] <danielfalck> but, I think it's an older version
[23:06:59] <jepler> emc's standalone interpreter prints something like this
[23:06:59] <jepler> N..... ARC_FEED(0.0000, 4.2000, 0.0000, 4.0000, -1, 0.0000, 0.0000, 0.0000, 0.0000)
[23:07:20] <danielfalck> it's the second pair of numbers that I'm curious about
[23:07:28] <danielfalck> 0.0000, 4.0000
[23:07:42] <danielfalck> what was your g code leading up to that output?
[23:07:54] <jepler> N..... STRAIGHT_FEED(-0.2000, 4.0000, 0.0000, 0.0000, 0.0000, 0.0000)
[23:08:53] <danielfalck> g2 then?
[23:09:38] <jepler> http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=tests/interp/inverse-time-with-comp/inverse.ngc;h=085a996d959cf75096a67ba7e6b63c6c93f88b3a;hb=HEAD (gcode)
http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=tests/interp/inverse-time-with-comp/expected;h=f11b64133cfb00d0e5a7797e2dbf354ccbcb60c5;hb=HEAD (output)
[23:11:20] <jepler> *center_x = (current_x + i_number);
[23:11:20] <jepler> *center_y = (current_y + j_number);
[23:11:43] <jepler> the way I read the source, I expect those numbers to represent the center of the arc in absolute computers
[23:11:47] <jepler> coordinates
[23:13:09] <jepler> now I'm having trouble finding the numbers I expect in that line I pasted :-/
[23:13:14] <jepler> they should be 0,4.5 I think
[23:13:17] <jepler> bbiab
[23:14:39] <danielfalck> I'll paste a little bit of the code I'm scratching my head about
[23:14:41] <danielfalck> http://pastebin.ca/1557802
[23:15:30] <danielfalck> when I did that G02, I expected the center to be at x.75 y.25
[23:15:53] <danielfalck> but I read it as 1.0000, 0.0000
[23:16:08] <danielfalck> I'm just curious is that is what you would run into too
[23:17:04] <danielfalck> I can write a routine to convert to something that I can use on my mac, but I figure it's already been done somewhere
[23:17:27] <jepler> I can't "see" r-format arcs in my head very well
[23:19:19] <danielfalck> I could have used I 0, J .25 too
[23:20:04] <jepler> I think that the shown center (1,0) is .25 from the start (.75,0) and from the end (1,.25)
[23:20:45] <danielfalck> ah, I found it- using i 0, j.25 works like I would expect
[23:21:15] <danielfalck> so, it's my 'seeing' the arcs in R format :)
[23:22:05] <danielfalck> I'm planning on writing a routine to import Gcode into my CAD program at work
[23:22:21] <danielfalck> the rs274 stuff came to my rescue
[23:23:31] <danielfalck> how are things going with emc development these days?
[23:23:32] <jepler> for R-format arcs there is always an ambiguity. If you write r-.25 you get the one you wanted.
[23:23:41] <danielfalck> ok, thanks
[23:23:44] <jepler> somewhere there's a picture showing this ..
[23:24:11] <jepler> oh it's a bit slow .. micges is working on some interesting stuff for non-trivkins machines, and chris is working on stuff to make his toolchanger (rotary carousel) work better
[23:24:16] <jepler> I haven't been doing much stuff myself
[23:24:49] <jepler> "The R number is the radius. A positive radius indicates that the arc turns through less than 180 degrees, while a negative radius indicates a turn of more than 180 degrees."
[23:24:52] <jepler> http://linuxcnc.org/docs/html/gcode_main.html#r1_4_3
[23:24:55] <jepler> haven't found the picture yet
[23:25:12] <danielfalck> thanks
[23:26:46] <jepler> I know it's on the two-sided gcode reference card we gave away 3 years ago at cnc workshop, but I can't find it in our source or our website :(
[23:26:56] <jepler> (the front side was the gcode.html one-page reference)
[23:27:17] <jepler> anyway, good luck with your converter .. dinnertime here
[23:27:23] <danielfalck> well, I know where to look (in the c++ code) anyway
[23:27:26] <danielfalck> thanks