why in emc canon two position structures are used (EmcPose and CANON_POSITION)? Is it some leftover?
micges_work: probably so
EmcPose is preffered I suppose?
EMC: 03micges 07tlo_all_axes * rad1e85bafb89 10/src/emc/ (4 files in 4 dirs): TLO in emccanon internally use EmcPose structure
EMC: 03micges 07tlo_all_axes * re252184275a6 10/src/emc/ (5 files in 4 dirs): Make interpreter and canon handle nine axis tool length offset
EMC: 03micges 07tlo_all_axes * r59e57c0dfe0a 10/src/emc/rs274ngc/ (5 files): In interpreter use EmcPose to hold TLO values instead of single variables
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
micges_work: your change to the G43.1 error handling is probably wrong. It looks like you allow J which I doubt you intend
+ offset.a /= 25.4; offset.b /= 25.4; offset.c /= 25.4;
this is clearly wrong
EMC: 03micges 07tlo_all_axes * r7e7ac9fa6448 10/src/emc/ (8 files in 3 dirs): Extend task and motion to handle nine axis TLO
jepler: j is caught earlier in interp
and second bug I study in a few hours
going home, bbl
jepler: why 'offset.a /= 25.4' is wrong in gcodemodule?
jepler: ignore last question, I understand (a,b,c are in degrees)
EMC: 03micges 07tlo_all_axes * ra3637d6db6dc 10/src/emc/rs274ngc/gcodemodule.cc: This is clearly wrong
why would you only be using 25.4 - shouldn't it be more acurite than that?
1 international inch = 25.4 mm (wikipedia)
heh - ok. never mind.
for some odd reason I thought it was 25.4something.
don't know: I'm in mm ;)
skunkworks_: it's the mm->in conversion that is not a nice exact value, but a repeating fraction starting 0.039370079
that is what I am thinking about.. .03937 is what I always used..
it's not a bad approximation -- only about 1/8" error over 1 mile
I can live with that.
would a expresscard -> lpt card work with a laptop
* boon__ missed a question mark there
i borrowed one , and it doesnt map to the 0x378
the device shows up in /dev/usblp0
oh well , too bad :( , thanks
EMC: 03micges 07tlo_all_axes * r3a1d64a4b3c9 10/src/emc/ (12 files in 6 dirs): Remove code for supporting TLO_IS_ALONG_W option
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)?
that this could somehow work*
expresscard has both USB and PCIe connections, so another expresscard LPT port could work
sorry, all of EMC2's supported hardware is PCI card or parallel port (or ISA card).
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
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.
Oh , I see , thanks again.
Right, a PCIE express card LPT is likely to work, dont know if such beasts exist however
cradek: got moment for tlo consultation?
Theres also an awkward and expensive way to do it with our stuff (assuming latency is OK)
ExpressCard --> PCIE cable --> 4I73 --> 4I65 or 4I68
hmm , I guess I'm better off selling the laptop and buying a 2nd-hand pc
well thanks alot for your extensive help,bye for now.
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?
and now it is unable to set frontangle and backangle from G10 L1 gcode, it is intentional?
another one: why there are two SET_TOOL_TABLE_ENTRY functions?
micges: orientation 0 is a mill tool, and it was on purpose that it is a mistake for them to have an X offset
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
why x offset for mill tool is mistake?
with the changes you are considering (any offset is available for any tool) it is no longer a mistake
what is your plan for the tool table?
I am coding this becouse I need x and y offset for mill tool thats why I'm asking
I think it is a good idea to allow any offset for any tool
I have started on it a few times and I meant to finish it soon - glad you are doing it
I was hoping to hear from you about tool table
yes I have an idea
each line is like T1 P2 X1.2 Z2.3 ...
tool, pocket, any needed axes
T1 P2 Z1.1 ;one inch long end mill
... Qn FANGnn BANGnnn ?
T2 P3 X1.2 Z2.3 D0.0625 Q3 ;lathe tool T2 in pocket 3 with X,Z offsets, radius 1/32, orientation 3
I think they should be one letter like gcode
; starts a comment
it would be very interesting if they could take all the same letters/arguments as G10 L1
how practical do you think that is?
you have 12 letters for a tool so if they will be the same that will be easier :)
but in G10 L1 you cannot specify pocket
or could you??
I think I can
I will help you test when you are done :-)
seems like it is very very complicated
must study some of your tool changer changes
jepler and I have talked about the tool table just being gcode lines (G10 L1 ...)
you would read the tool table by interpreting it
then it is an automatic feature that you can put the tool table in the part program
you would need to move tool table handling out of iotask and put it fully in the interpreter to accomplish this
cradek: I think I know enough now, thanks
welcome, good luck with it
it is complicated :-)
EMC: 03micges 07tlo_all_axes * r3c7d40b90609 10/src/emc/rs274ngc/interp_convert.cc: Use whole EmcPose struct copy
EMC: 03micges 07tlo_all_axes * rb37bd232ec63 10/src/emc/ (17 files in 7 dirs): Store TLO internally in CANON_TOOL_TABLE as EmcPose
EMC: 03micges 07tlo_all_axes * rc2ec26d7bbf5 10/configs/common/emc.nml: Increase buffer size to hold larger status structure
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
I built packages and installed on a computer, and then had to create that file manually.
so a normal user could run it that is... or is there another way to do this?
no, the rtai package should set up udev rules for its drivers
in fact that's what the hardy rtai package we built does
$ dpkg -L rtai-modules-2.6.24-16-rtai | grep rtai.rules
not sure why you'd do it with postinst, rather than putting the rules file directly in the deb, either
ah, I see. I built my rtai packages too.
why? because I don't know what I'm doing :)
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
mkdir -p debian/tmp/etc/udev/rules.d
$(MAKE) install DESTDIR=`pwd`/debian/tmp
and why you may not have learned that it even has the ability to create the rules file
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.
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.
that's good to hear
anybody here who looked into the o-word/g38 probing bug problem before? I have some 'finding' but unsure how to fix
what is your finding?
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
can somebody tell me under which conditions and where emcTaskPlanSynch() should be called?
sorry, I don't know the answer, I hope you figure it out
hm.. well, Ken is also looking into it