Back
[06:31:10] <skunkworks> https://groups.google.com/forum/#!topic/machinekit/QiJWnNu4J3Q
[06:33:03] <skunkworks> good morning
[06:33:13] <jthornton> morning
[09:31:26] <stustev> Having determined (I think) rs274ngc is the directory to work in to implement my 5 axis cutter diameter compensation routine is there a flow chart somewhere showing information flow through these files? thanks
[09:33:11] <cradek> not really a flowchart, but you might start with reading the comments in interp_convert.cc, I bet you'll especially want to concentrate on convert_straight, convert_straight_comp1, convert_straight_comp2
[09:39:04] <cradek> from memory, comp1 is responsible for the entry move, comp2 is subsequent compensated moves
[09:39:30] <cradek> where straight means lines, not arcs
[09:46:26] <stustev> will start there - thanks - I will need to handle exit moves - will that be apparent (for some people) by reading file?
[09:47:36] <cradek> yes (from memory again) I bet you'll spot that in convert_straight
[09:50:05] <stustev> at first glance I see CANON_PLANE_XY and XZ but no YZ
[09:51:38] <skunkworks> cutter comp only works in xy (or xz on lathe)
[09:51:55] <skunkworks> currently ;)
[09:51:59] <stustev> YZ seems to be handled on line 72 and 108 but CANON_PLANE_XZ is there instead of CANON_PLANE_YZ
[09:52:23] <stustev> ok - so mills do not have YZ plane?
[09:52:56] <stustev> In my CAD/CAM world the planes are XY, YZ and ZX.
[09:53:45] <stustev> nitpicking maybe - maybe stupid questions -
[09:54:05] <cradek> I agree with skunkworks - the code does not handle comp in YZ at all
[09:54:52] <cradek> you can see the explicit error the first line of convert_cutter_compensation_on
[09:56:17] <stustev> line 72 and 73 - and line 108 and 109 imply to me they intend to handle the YZ plane - I will look farther - thanks
[09:56:44] <cradek> I don't see what you're seeing - maybe we have different versions checked out
[09:56:58] <cradek> I see only XY and XZ handled in those functions
[10:08:42] <stustev> I see x=x, y=y, z=z and x=y, y=z, z=x and x=z, y=x, z=y in the setup assignments. I haven't read any farther except for the location you suggested.
[10:09:07] <cradek> weird
[10:09:10] <cradek> what branch are you on?
[10:09:43] <cradek> even in master I don't see that
[10:10:34] <cradek> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/rs274ngc/interp_convert.cc;h=1bf912a2c7d3d0ac6c2a15c5524923134d1c8e1e;hb=8927d3f0e8dbe4b1bb22b391983cdbd8501a20d5#l37
[10:13:36] <stustev> I have the 2.8pre downloaded and compiled on this box but it doesn't run as the OS is Mint :( - I will check it on the box that runs 2.8pre
[10:18:16] <stustev> lines 49, 50, 51 and 67, 68, 69 and 85, 86, 87 respectively x=x, y=y, z=z
[10:18:58] <cradek> yep
[10:22:15] <stustev> lines 54, 55, 56 and 91, 92, 93 respectively x=z, y=x z=y
[10:23:09] <stustev> lines 104, 105, 106 are also x=x, y=y, z=z
[10:24:30] <stustev> lines 73, 74, 75 and 109, 100, 111 respectively x=y, y=z z=x
[10:25:31] <stustev> Now, it has been 10 years since I created my kinematics to correct the geometry on the cinci so I need to study this a little bit to believe I am reading this correct.
[10:26:11] <stustev> I am just seeing something I feel is not consistent. Maybe it will get better later :)
[10:26:27] <cradek> I still do not see what you think is YZ plane
[10:26:43] <cradek> do you see that two of those functions are "get" and two are "set"? they are inverse operations
[10:27:23] <cradek> get has x<-z and then set has z<-x
[10:27:50] <stustev> ok will look
[10:33:35] <stustev> I would think the inverse of Z into *x would be z into x? is that not the inverse?
[10:34:04] <stustev> x into z
[10:34:08] <stustev> duh
[10:39:46] <stustev> line 55 in get shows z into x but line 73 in set shows y into x - it doesn't look correct to me - I don't know if it works as I have not tried to run it
[10:40:38] <cradek> get has x<-z and set has x<-z
[10:40:43] <cradek> arrgh
[10:40:51] <cradek> I meant: get has x<-z and set has z<-x
[10:40:52] <stustev> ditto
[10:41:31] <cradek> get has y<-x and set has x<-y
[10:41:40] <cradek> they are inverses
[10:42:28] <cradek> (don't know why that's so hard to type)
[10:42:40] <stustev> ok now I see what you are saying
[10:43:53] <stustev> need to read ssslllooowwweeerrr
[10:44:55] <stustev> happy now - many thanks
[10:45:03] <cradek> welcome :-)
[10:48:53] <stustev> Would it be possible to visit Lincoln some evening and sit down over supper with a gentleman or two to discuss my lack of knowledge?
[10:52:18] <cradek> I'd like to see you, but I don't know if my help in person vs here would justify the travel
[10:52:44] <cradek> I don't have most of this in my head, I am looking at the code with you
[10:53:24] <cradek> maybe I can continue helping you get started and we might want to meet in person later
[10:54:57] <cradek> (also I'm not quite well yet)
[12:02:25] <stustev> sounds good - we will keep on like this - as long as you can put up with the questions :)
[13:28:15] <KimK_laptop> skunkworks , skunkworks_ : Missing components emailed.
[13:28:39] <skunkworks> KimK_laptop, COOL - thanks
[13:47:26] <Roguish> cradek: there is a thing in vismach called 'HUD' do you know what it is / does? any clue? not documented very well.
[13:47:40] <cradek> sorry nope
[13:48:56] <Roguish> ok, thanks for the quick reply.
[13:49:55] <Roguish> alex_jon1: there is a thing in vismach called 'HUD' do you know what it is / does? any rememberance? (you being the author and all....)
[13:50:30] <cradek> perhaps a study of the code would tell you?
[13:51:07] <seb_kuzminsky> Roguish:
http://linuxcnc.org/docs/2.7/html/gui/vismach.html#_other_functions
[13:51:18] <seb_kuzminsky> myhud = Hud()
[13:51:18] <seb_kuzminsky> Creates a heads-up display in the Vismach GUI to display such items as axis positions.
[13:52:03] <seb_kuzminsky> heh, "I have no idea what this does, but it seems to be important for tool tip visualization.
[13:52:12] <seb_kuzminsky> we have the best docs, everyone agrees
[13:54:59] <Roguish> seb_kuzminsky: thanks. i am not in any way bagging on the docs. just trying to see what it does.
[13:55:16] <Roguish> i just added that to my script and now it fails.
[13:56:22] <seb_kuzminsky> bummer
[13:56:22] <Roguish> i've been looking at the source, and since i'm not very good at reading code, I can't really tell what's going on in it.
[13:57:24] <Roguish> how would i format a grep command to find 'hud' in the sim examples?
[13:57:29] <seb_kuzminsky> my grep-fu tells me that these are the files in src/ that mention hud:
[13:57:44] <seb_kuzminsky> hal/user_comps/vismach/hexagui.py
[13:57:44] <seb_kuzminsky> hal/user_comps/vismach/xyzac-trt-gui.py
[13:57:44] <seb_kuzminsky> hal/user_comps/vismach/xyzbc-trt-gui.py
[13:58:01] <seb_kuzminsky> maybe those examples help?
[13:58:11] <Roguish> i will check, thanks.
[13:58:26] <seb_kuzminsky> err, and this one:
[13:58:32] <seb_kuzminsky> emc/usr_intf/axis/scripts/tracking-test.py
[13:59:01] <seb_kuzminsky> yeah, the axis oen looks helpful
[14:55:38] <JT-Shop> Roguish: grep -irl 'term' *
[14:59:22] <Roguish> JT-Shop: yeah, got it. been through everything I can find, even the source.
[15:01:34] <Roguish> looking at vismach.py, lines around 672. just not good enough with reading python.
[15:01:37] <dgarr> Roguish: try $ pydoc vismach
[15:05:01] <Roguish> just thinking it would be cool to have a DRO in the HUD.
[15:14:10] <JT-Shop> dang pydoc is cool
[17:23:07] <Roguish> Hey all. is there a way to get a tool diameter from the tool table using HAL?
[17:35:13] <JT-Shop> halui
[17:35:29] <JT-Shop> hmm don't see diameter
[17:36:39] <seb_kuzminsky> yeah, halui exports the current tool number and all 9 axes of tool length, but not diameter
[17:36:44] <seb_kuzminsky> that seems like an omission
[17:37:04] <seb_kuzminsky> Roguish: a patch would be gratefully accepted :-)
[17:38:23] <Roguish> seb_kuzminsky: I sorely wish I could program that. where/what file is the best to look at?
[17:39:13] <Roguish> I really must get around a some sort of programming class or something.....
[17:39:29] <seb_kuzminsky> halui is in src/emc/usr_intf/halui.cc
[17:40:06] <seb_kuzminsky> it talks to the linuxcnc motion controller via our venerable NML mechanism
[17:40:28] <seb_kuzminsky> unfortunately for you and me and all of us, NML exposes tool length offsets but not tool diameter... :-(
[17:40:43] <Roguish> venerable? now you're talking my language. any Fortran in there?
[17:41:05] <seb_kuzminsky> so getting that info to halui will involve a whole bunch of related changes, to Task, NML, and Halui
[17:41:11] <seb_kuzminsky> no Fortran, sorry :-)
[17:41:17] <seb_kuzminsky> it's all very old C
[17:44:25] <Roguish> nml.cc by Fred Proctor....
[17:46:13] <andypugh> Roguish: It is C++ written by people who only really knew FORTRAN. I call it FORTRAN++ :-)
[17:46:53] <Roguish> just don't drop the box of cards........it's really bad.
[17:49:00] <andypugh> seb_kuzminsky: motion also exports the tool offsets (not sure why halui repeats them?)
[17:54:32] <seb_kuzminsky> andypugh: oh yeah, good point
[17:54:45] <seb_kuzminsky> unfortunately motion also does not know the tool diameter
[17:55:14] <andypugh> How does it do diameter comp?
[17:55:58] <seb_kuzminsky> i think interp does all that
[17:56:23] <seb_kuzminsky> motion is post-canon, i think cutter comp is pre-canon (ie, inside interp)
[17:57:13] <seb_kuzminsky> oh wait a minute, the full tool table is in the iostat struct, which is in the status struct
[17:57:16] <seb_kuzminsky> hmm...
[18:00:28] <seb_kuzminsky> or is iostat not in stat? i get so confused
[18:01:10] <stustev> seb_kuzminsky: at least I don't feel so alone now
[18:01:30] <Tom_L> it's a hard code project to follow
[18:02:21] <andypugh> It’s all the numerous layers of abstraction, makes it very hard to folllow things through.
[18:02:48] <Tom_L> is that by design or design flaw?
[18:03:32] <andypugh> The layers are part of the design, to make it all very flexible. But it’s flexibility that was never really used.
[18:03:55] <Tom_L> i can see having the layers
[18:04:00] <andypugh> The whole NML / RCS was (I think) designed so that the whole system could be distributed.
[18:08:05] <Tom_L> is the bulk of it python or a mix of python, c or C++ and maybe other?
[18:10:53] <Roguish> AXIS uses the tool diameter to draw its cute little tool..... where/how does AXIS get the diameter???
[18:11:22] <seb_kuzminsky> Roguish: good point
[18:11:34] <seb_kuzminsky> it turns out it *is* in the status struct, buried a couple of layers deep
[18:11:47] <Roguish> yeah, i may be slow.... but i'm not toooooo dumb.
[18:12:10] <Roguish> where is the status struct?
[18:12:17] <Roguish> filename?
[18:13:31] <seb_kuzminsky> it's mostly in src/emc/nml_intf/*.hh
[18:19:11] <andypugh> Tom_L: The vast majority is C++, with quite a lot of C for the kernel and realtime parts.
[18:19:59] <andypugh> I think I have probably written orders of magnitude more C than Python for the project.
[18:23:37] <KGB-linuxcnc> 03Sebastian Kuzminsky 05halui-tool-diameter c76c691 06linuxcnc 10docs/man/man1/halui.1 10src/emc/usr_intf/halui.cc halui: add a hal pin with the current tool diameter * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c76c691
[18:23:42] <seb_kuzminsky> Roguish: try that branch out
[18:25:37] <Roguish> did you add a new 'FIELD(hal....) in the tool section? near line 90
[18:26:18] <seb_kuzminsky> Roguish: yeah. Here's what i did:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=c76c69194a15c3f78e47a62919a58c6b8f16542a
[18:26:44] <Roguish> thanks. i'll take it as coding lessson.
[18:27:30] <seb_kuzminsky> you're welcome :-)
[18:27:52] <andypugh> seb_kuzminsky: While you have it open, you don’t feel like making the tool table into a database do you :-)
[18:27:53] <Roguish> what's all that stuff at line 2138?
[18:28:13] <seb_kuzminsky> the trickiest part, like andypugh said, is untangling all the layers of structs and message-passing
[18:28:28] <seb_kuzminsky> andypugh: :-)
[18:29:07] <Roguish> are you calling this 'spagetti' ?
[18:29:16] <seb_kuzminsky> Roguish: that part examines the status structure (emcStatus), and digs out the part of that struct that came from IO (which manages tools), and finds the diameter of the currently loaded tool
[18:29:53] <seb_kuzminsky> it has spaghetti-nature, but also does not have spaghetti nature
[18:30:01] <Roguish> ok, i'll try that branch. might take a while. gotta pull and compile, right?
[18:30:22] <andypugh> seb_kuzminsky: How expensive is it to cycle through the table? Would it make sense to only update when the tool changes?
[18:30:38] <Roguish> I drink a lot of wine with my spaghetti !!!
[18:30:49] <seb_kuzminsky> Roguish: pull & compile, yeah, or wait for the buildbot to build it
[18:31:00] <seb_kuzminsky> as long as you're not on Jessie armhf ;-)
[18:31:13] <Roguish> no, wheezy.
[18:31:23] <seb_kuzminsky> andypugh: that would be more efficient, for sure
[18:31:48] <seb_kuzminsky> but halui is a non-realtime program, so i dont really care about performance there that much
[18:32:09] <andypugh> seb_kuzminsky: He seemed to be assuming that PCW was a developer, and that his lack of impressed-ness with ARM was project policy.
[18:32:52] <seb_kuzminsky> oh, and you'd have to be careful to handle it when someone changes the diameter of the current tool, and can tool change pockets without changing tool number? i dont know
[18:33:00] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jethornton opened issue #229: 2.8 Conversion Script Bug 02
https://github.com/LinuxCNC/linuxcnc/issues/229
[18:33:03] <andypugh> Hmm, so the halui versions of the offsets are lower-quality than the motion ones?
[18:33:14] <seb_kuzminsky> the dumb algorithm i wrote avoids some of those kinds of bugs
[18:33:37] <seb_kuzminsky> halui has higher latency than motion, but otherwise it's the same
[18:34:10] <seb_kuzminsky> it also has access to the emcStatus struct, and the IO Status struct within it, which motion does not have
[18:34:36] <seb_kuzminsky> in order for motion to know the tool diameter you'd have to pass it in from Task somewhere, i guess in the same place where it passes tlo
[18:34:48] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15andypugh commented on issue #229: What should the script guess as the new value? I think I might have considered this and not found an answer. 02
https://github.com/LinuxCNC/linuxcnc/issues/229#issuecomment-278185903
[18:34:59] <Roguish> this tool stuff doesn't really need to be very fast. it's on par with simple PLC type stuff.
[18:35:32] <JT-Shop> I'd guess pick the highest velocity and use that
[18:36:06] <JT-Shop> or ask the user what they want
[18:36:08] <seb_kuzminsky> there's a set_offset message from Task to Motion, but it has tlo only, no diameter
[18:36:35] <seb_kuzminsky> well i'm off, see you all later
[18:36:43] <JT-Shop> later
[18:36:46] <Roguish> tool changes are pretty darn slow.
[18:36:54] <Roguish> seb_kuzminsky: THANKS.
[18:37:07] <Roguish> andypugh: you also.
[18:37:23] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jethornton commented on issue #229: You could pick the highest one or ask the user what they want. 02
https://github.com/LinuxCNC/linuxcnc/issues/229#issuecomment-278186412
[18:41:34] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jethornton opened issue #230: MAX_LINEAR_VELOCITY missing does not show an error 02
https://github.com/LinuxCNC/linuxcnc/issues/230
[18:42:35] * JT-Shop heads inside
[18:45:53] <linuxcnc-build_> build #2901 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/2901 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[18:55:10] <linuxcnc-build_> build #4752 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4752 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[18:59:01] <seb_kuzminsky> well that's timely - more arm flakiness in the buildbot
[19:05:27] <pcw_mesa> Its a shame the AMD Arm seems to be stillborn
[19:07:43] <seb_kuzminsky> yeah, that looked really nice for a while there, about a year ago
[19:09:21] <Roguish> seb_kuzminsky: all compiled. IT WORKS. got a halui.tool.diameter pin. and changes with tool change.
[19:09:32] <Roguish> roll that baby into master.
[19:30:33] <Tom_L> may i ask what the purpose of having a pin for tool diameter is?
[19:30:37] <Tom_L> lathe app?
[19:53:02] <Roguish> vismach
[19:53:14] <Roguish> graphics
[20:22:27] <seb_kuzminsky> Roguish: ok great, i'll merge it
[20:24:24] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master c76c691 06linuxcnc 10docs/man/man1/halui.1 10src/emc/usr_intf/halui.cc halui: add a hal pin with the current tool diameter * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c76c691
[20:24:24] <KGB-linuxcnc> 05halui-tool-diameter c76c691 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c76c691
[20:30:29] <dgarr> seb_kuzminsky: i asked but didn't see an answer, will you consider merging the aux_gladevcp_apps to 2.7 before the next release?
[20:30:31] <dgarr> http://www.panix.com/~dgarrett/stuff/nativecam_deb.txt
[20:48:33] <seb_kuzminsky> i saw your message
[20:48:45] <seb_kuzminsky> i'll look at it tonight
[20:52:00] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/external_offsets be648ec 06linuxcnc 10(23 files in 9 dirs) External Axis Offset hal pins (v30) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=be648ec
[20:52:01] <dgarr> thanks
[20:53:08] <jepler> I wish that W. Martinjak and I could get along
[20:53:25] <jepler> sigh
[20:54:47] <dgarr> seb_kuzminsky: btw, it is easy to test the aux_gladevcp_apps branch with the trial deb pointed to in the file that i posted
[22:12:04] <linuxcnc-build_> build #3947 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/3947 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[22:23:44] <dgarr> linuxcnc-build_: force build --branch=dgarr/external_offsets 0000.checkin
[22:23:50] <linuxcnc-build_> The build has been queued, I'll give a shout when it starts
[22:56:57] <linuxcnc-build_> build #4754 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4754 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[22:56:58] <linuxcnc-build_> build forced [ETA 1h04m12s]
[22:56:58] <linuxcnc-build_> I'll give a shout when the build finishes
[23:59:49] <linuxcnc-build_> Hey! build 0000.checkin #4755 is complete: Success [3build successful]
[23:59:49] <linuxcnc-build_> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4755