Back
[13:02:44] <micges_work> hello
[13:03:47] <micges_work> why in emc canon two position structures are used (EmcPose and CANON_POSITION)? Is it some leftover?
[13:13:52] <alex_joni> micges_work: probably so
[13:15:08] <micges_work> EmcPose is preffered I suppose?
[14:55:45] <CIA-40> EMC: 03micges 07tlo_all_axes * rad1e85bafb89 10/src/emc/ (4 files in 4 dirs): TLO in emccanon internally use EmcPose structure
[14:55:46] <CIA-40> EMC: 03micges 07tlo_all_axes * re252184275a6 10/src/emc/ (5 files in 4 dirs): Make interpreter and canon handle nine axis tool length offset
[14:55:47] <CIA-40> EMC: 03micges 07tlo_all_axes * r59e57c0dfe0a 10/src/emc/rs274ngc/ (5 files): In interpreter use EmcPose to hold TLO values instead of single variables
[14:55:53] <CIA-40> EMC: 03micges 07tlo_all_axes * r0a057c0818d4 10/src/emc/rs274ngc/ (interp_convert.cc interp_internal.cc): Change TLO gcode from G43.1 In Kn to G43.1 Xn ... Wn to allow changing all axes
[15:07:08] <jepler> micges_work: your change to the G43.1 error handling is probably wrong. It looks like you allow J which I doubt you intend
[15:07:50] <jepler> + offset.a /= 25.4; offset.b /= 25.4; offset.c /= 25.4;
[15:07:52] <jepler> this is clearly wrong
[15:08:03] <jepler> (in gcodemodule.cc)
[15:08:04] <CIA-40> EMC: 03micges 07tlo_all_axes * r7e7ac9fa6448 10/src/emc/ (8 files in 3 dirs): Extend task and motion to handle nine axis TLO
[15:08:36] <micges_work> jepler: j is caught earlier in interp
[15:09:21] <micges_work> and second bug I study in a few hours
[15:09:29] <micges_work> going home, bbl
[16:33:27] <micges> jepler: why 'offset.a /= 25.4' is wrong in gcodemodule?
[16:34:25] <micges> jepler: ignore last question, I understand (a,b,c are in degrees)
[16:41:12] <jepler> exactly
[16:42:23] <CIA-40> EMC: 03micges 07tlo_all_axes * ra3637d6db6dc 10/src/emc/rs274ngc/gcodemodule.cc: This is clearly wrong
[16:42:56] <skunkworks_> why would you only be using 25.4 - shouldn't it be more acurite than that?
[16:44:55] <micges> 1 international inch = 25.4 mm (wikipedia)
[16:48:45] <skunkworks_> heh - ok. never mind.
[16:51:04] <skunkworks_> for some odd reason I thought it was 25.4something.
[16:51:59] <micges> don't know: I'm in mm ;)
[16:54:02] <jepler> skunkworks_: it's the mm->in conversion that is not a nice exact value, but a repeating fraction starting 0.039370079
[16:58:29] <skunkworks_> that is what I am thinking about.. .03937 is what I always used..
[17:10:27] <jepler> it's not a bad approximation -- only about 1/8" error over 1 mile
[17:11:23] <skunkworks_> I can live with that.
[17:18:11] <micges> cradek: around?
[17:52:53] <boon__> Hi
[17:53:06] <cradek> hi boon__
[17:53:37] <boon__> would a expresscard -> lpt card work with a laptop
[17:53:49] <boon__> * boon__ missed a question mark there
[17:54:24] <boon__> i borrowed one , and it doesnt map to the 0x378
[17:55:04] <boon__> the device shows up in /dev/usblp0
[17:55:11] <cradek> nope
[17:55:37] <boon__> oh well , too bad :( , thanks
[17:55:49] <cradek> welcome
[17:58:33] <CIA-40> EMC: 03micges 07tlo_all_axes * r3a1d64a4b3c9 10/src/emc/ (12 files in 6 dirs): Remove code for supporting TLO_IS_ALONG_W option
[18:03:35] <boon__> sorry , but its still bugging me , it's just that I have to buy another computer because this doesnt work , there really is no way that could somehow(no matter how bad/weird/backwards is it)?
[18:03:57] <boon__> that this could somehow work*
[18:04:24] <SWPadnos> expresscard has both USB and PCIe connections, so another expresscard LPT port could work
[18:04:34] <cradek> sorry, all of EMC2's supported hardware is PCI card or parallel port (or ISA card).
[18:04:54] <SWPadnos> but I don't know how you'd be able to find out without buying and testing them until you find one that doesn't get listed as a USB port
[18:05:18] <cradek> before bothering to buy any hardware, check the latency test results. Your laptop may not work acceptably for realtime, totally aside from the interface problems.
[18:05:54] <boon__> Oh , I see , thanks again.
[18:09:49] <pcw_home> Right, a PCIE express card LPT is likely to work, dont know if such beasts exist however
[18:11:48] <micges> cradek: got moment for tlo consultation?
[18:12:33] <pcw_home> Theres also an awkward and expensive way to do it with our stuff (assuming latency is OK)
[18:12:35] <pcw_home> ExpressCard --> PCIE cable --> 4I73 --> 4I65 or 4I68
[18:15:14] <boon__> hmm , I guess I'm better off selling the laptop and buying a 2nd-hand pc
[18:15:35] <boon__> well thanks alot for your extensive help,bye for now.
[18:42:57] <micges> In G10 L1 gcode there is condition: 'CHKS((block->x_flag && !settings->tool_table[pocket].orientation), "Cannot have an X tool offset with orientation 0");', is it correct?
[18:43:44] <micges> and now it is unable to set frontangle and backangle from G10 L1 gcode, it is intentional?
[18:45:14] <micges> another one: why there are two SET_TOOL_TABLE_ENTRY functions?
[19:18:48] <cradek> micges: orientation 0 is a mill tool, and it was on purpose that it is a mistake for them to have an X offset
[19:19:37] <cradek> you are right that there is no way to set the angles (or comment) of a tool with G10 L1. It's not intentional that it is impossible -- more like just unimplemented
[19:20:51] <micges> why x offset for mill tool is mistake?
[19:21:42] <cradek> with the changes you are considering (any offset is available for any tool) it is no longer a mistake
[19:22:12] <micges> I see
[19:22:40] <cradek> what is your plan for the tool table?
[19:23:00] <micges> I am coding this becouse I need x and y offset for mill tool thats why I'm asking
[19:23:09] <cradek> I understand
[19:23:22] <cradek> I think it is a good idea to allow any offset for any tool
[19:23:40] <cradek> I have started on it a few times and I meant to finish it soon - glad you are doing it
[19:23:42] <micges> I was hoping to hear from you about tool table
[19:23:54] <cradek> yes I have an idea
[19:24:14] <cradek> each line is like T1 P2 X1.2 Z2.3 ...
[19:24:37] <cradek> tool, pocket, any needed axes
[19:25:21] <cradek> T1 P2 Z1.1 ;one inch long end mill
[19:25:56] <micges> ... Qn FANGnn BANGnnn ?
[19:26:19] <cradek> T2 P3 X1.2 Z2.3 D0.0625 Q3 ;lathe tool T2 in pocket 3 with X,Z offsets, radius 1/32, orientation 3
[19:26:29] <cradek> F,B probably
[19:26:35] <cradek> I think they should be one letter like gcode
[19:26:41] <cradek> ; starts a comment
[19:26:41] <micges> I see
[19:27:07] <cradek> it would be very interesting if they could take all the same letters/arguments as G10 L1
[19:27:15] <cradek> how practical do you think that is?
[19:27:16] <micges> they can
[19:27:44] <micges> you have 12 letters for a tool so if they will be the same that will be easier :)
[19:28:04] <cradek> yes
[19:28:11] <cradek> but in G10 L1 you cannot specify pocket
[19:28:28] <cradek> or could you??
[19:28:46] <micges> I think I can
[19:28:58] <cradek> I will help you test when you are done :-)
[19:29:06] <cradek> seems like it is very very complicated
[19:29:17] <micges> must study some of your tool changer changes
[19:29:55] <cradek> jepler and I have talked about the tool table just being gcode lines (G10 L1 ...)
[19:30:02] <cradek> you would read the tool table by interpreting it
[19:30:22] <cradek> then it is an automatic feature that you can put the tool table in the part program
[19:30:56] <cradek> you would need to move tool table handling out of iotask and put it fully in the interpreter to accomplish this
[19:35:48] <micges> cradek: I think I know enough now, thanks
[19:35:59] <cradek> welcome, good luck with it
[19:36:04] <cradek> it is complicated :-)
[20:47:29] <LawrenceG> \
[21:09:57] <CIA-40> EMC: 03micges 07tlo_all_axes * r3c7d40b90609 10/src/emc/rs274ngc/interp_convert.cc: Use whole EmcPose struct copy
[21:09:57] <CIA-40> EMC: 03micges 07tlo_all_axes * rb37bd232ec63 10/src/emc/ (17 files in 7 dirs): Store TLO internally in CANON_TOOL_TABLE as EmcPose
[21:11:23] <CIA-40> EMC: 03micges 07tlo_all_axes * rc2ec26d7bbf5 10/configs/common/emc.nml: Increase buffer size to hold larger status structure
[21:14:17] <mozmck> Shouldn't the emc2.postinst file create the udev rtai.rules files as per this link:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Debian_Lenny_Compile_RTAI#Udev
[21:14:54] <mozmck> I built packages and installed on a computer, and then had to create that file manually.
[21:15:27] <mozmck> so a normal user could run it that is... or is there another way to do this?
[21:27:19] <jepler> no, the rtai package should set up udev rules for its drivers
[21:28:00] <jepler> in fact that's what the hardy rtai package we built does
[21:28:00] <jepler> $ dpkg -L rtai-modules-2.6.24-16-rtai | grep rtai.rules
[21:28:00] <jepler> /etc/udev/rules.d/99-rtai.rules
[21:28:26] <jepler> not sure why you'd do it with postinst, rather than putting the rules file directly in the deb, either
[21:28:31] <jepler> I'm ...
[21:29:04] <mozmck> ah, I see. I built my rtai packages too.
[21:29:28] <mozmck> why? because I don't know what I'm doing :)
[21:39:31] <jepler> it looks like the 'install' target of rtai creates the /etc/udev/rules.d/99-rtai.rules file, but only if there's already an /etc/udev/rules.d directory. that's probably why the debian/rules we wrote for our rtai package has
[21:39:35] <jepler> mkdir -p debian/tmp/etc/udev/rules.d
[21:39:38] <jepler> $(MAKE) install DESTDIR=`pwd`/debian/tmp
[21:39:53] <jepler> and why you may not have learned that it even has the ability to create the rules file
[21:40:53] <mozmck> ah, I see. I didn't have your debian/rules I don't think. I pulled the one mentioned on the page I linked above.
[21:42:33] <mozmck> I'm gradually learning how this all works I think. I got my kernel to run on the one machine with intel onboard graphics now, but the latencies are bad.
[21:44:55] <jepler> that's good to hear
[21:45:59] <jepler> bbl
[23:00:44] <mhaberler> anybody here who looked into the o-word/g38 probing bug problem before? I have some 'finding' but unsure how to fix
[23:00:57] <cradek> what is your finding?
[23:01:18] <mhaberler> it looks like an emcTaskPlanSynch() is missing in the o-word sub case so motion and milltask lose track of each other's position after the probe, which is why the move isnt issued which is described in the bug report
[23:01:20] <mhaberler> can somebody tell me under which conditions and where emcTaskPlanSynch() should be called?
[23:01:48] <cradek> eek
[23:02:51] <cradek> sorry, I don't know the answer, I hope you figure it out
[23:03:16] <mhaberler> hm.. well, Ken is also looking into it
[23:03:23] <cradek> great