Back
[00:30:48] <MarkusBec> MarkusBec is now known as MarkusBec_away
[01:29:37] <SWPadnos> see :)
[01:30:09] <JanisCNC> ok i see...
[01:30:42] <JanisCNC> allright... so lets move on.
[01:30:59] <SWPadnos> so, do you have the XML file being loaded by AXIS, or as a separate window?
[01:31:10] <JanisCNC> loaded by axis
[01:31:29] <SWPadnos> in that case, you shouldn't need to manually load pyvcp
[01:31:30] <JanisCNC> defined in the ini?
[01:31:43] <SWPadnos> either way would be in the ini
[01:32:01] <JanisCNC> ok the ini loads the xml
[01:32:43] <SWPadnos> you should only need to make connections in your POSTGUI_HALFILE, since the parport driver should already be loaded, and the panel should already be added to the AXIS screen
[01:33:09] <JanisCNC> only the "net" command`?
[01:33:29] <SWPadnos> I don't know what the pin names will be though (loading as part of AXIS), so maybe comment out the net commands also and find the names with halcmd
[01:33:36] <SWPadnos> yes, you should only need the net commands
[01:35:32] <JanisCNC> now he don't knows "btn01"
[01:36:06] <SWPadnos> so you can see the panel in AXIS?
[01:36:22] <JanisCNC> he doesn't even load axis...
[01:36:38] <JanisCNC> he gives an error
[01:36:44] <SWPadnos> what error?
[01:37:31] <mozmck> heh, probably three pages with one relevant line near the bottom or close to the top :)
[01:37:45] <jepler> comment out the problem line (or all the lines in your postgui_halfile), run, and use halcmd interactively (or the gui tool 'show hal configuration') to find out what the corrected line is.
[01:37:51] <JanisCNC> custom_postgui.hal:3: pin 'ptest.btn01' does not exist...
[01:38:29] <SWPadnos> yes, as jepler said, and I also said, comment out all the net lines (actually everything) in the POSTGUI_HALFILE, then start EMC
[01:38:30] <JanisCNC> ok.. mom
[01:39:10] <JanisCNC> ah allright pyvcp.btn01
[01:39:49] <SWPadnos> I guess you don't get a choice of "base name" when you stick the panel in AXIS
[01:41:08] <JanisCNC> mom
[01:42:45] <JanisCNC> isn't this the "base name"? pyvcp.btn01
[01:42:59] <SWPadnos> pyvcp is what I was calling the base name
[01:43:10] <SWPadnos> if you add another button, it will be pyvcp.btn02
[01:43:24] <JanisCNC> ok
[01:44:17] <SWPadnos> rather than ptest, which is what you would get loading it the way you had it (pyvcp -c ptest ... )
[01:45:37] <JanisCNC> yeah!
[01:45:46] <JanisCNC> ok.. mom hardware testing
[01:46:35] <JanisCNC> scotty beam me up! ^^ it takes function!! thanks!
[01:46:43] <SWPadnos> excellent
[01:47:43] <JanisCNC> that makes it a lot more simple to do more in pyvcp ^^
[01:47:53] <JanisCNC> a lot easier
[01:48:13] <JanisCNC> thanks again!
[01:48:16] <SWPadnos> sure
[01:49:39] <JanisCNC> ok next question: how do i make a switch out of the button?
[01:49:48] <SWPadnos> no idea
[01:50:37] <JanisCNC> ok ^^
[01:50:54] <JanisCNC> then I'll have to set checkbuttons
[01:56:11] <JanisCNC> but now that the problem is solved i can go to sleep... 4 o clock in the morning here in germany.. thanks and bye!
[02:57:49] <tomp> tomp is now known as tom3p
[02:59:28] <tom3p> pretty cool widgets from freshmeat
http://tegesoft.com/products/gics
[08:14:05] <pjm> good morning
[08:15:20] <archivist> good moaning
[08:16:16] <Valen> morning? damn you guys are behind the times
[08:17:12] <pjm> LOL
[08:17:14] <archivist> time starts in England we are right!
[08:17:25] <pjm> exactly! we invented it didnt we?
[08:17:30] <archivist> yup
[08:17:36] <pjm> i thought as much
[08:17:42] <archivist> does annoy the french
[08:17:47] <pjm> great!
[08:17:57] <Valen> time starts at some upstart place west of NZ that decided they were GMT +14 just so they can be first at stuff
[08:18:56] <pjm> that was probably done on purpose by the brits when we 'own3d' them (au and nz)
[08:19:56] <archivist> * archivist points Valen at the term GMT :)
[08:20:20] <Valen> thats the "middle" though
[08:20:30] <Valen> we are in front of that by 10 hours atm
[08:20:32] <Valen> 11 soon
[08:20:45] <archivist> we are the centre of the world
[08:21:13] <Valen> we are at the fashonable outer edge
[08:24:39] <pjm> archivist LOL re the centre of the world, but u are correct of course
[08:25:32] <archivist> * archivist restores the British Empire to its former glory
[08:25:40] <pjm> yay!
[08:25:58] <pjm> yeah i think the UK was foolish to give all our bits of the 'empire' back
[08:26:06] <pjm> we need to strike back
[08:26:23] <archivist> send some more convicts to .au
[08:26:37] <Valen> sorry we are full
[08:28:30] <pjm> hahhh
[08:28:51] <pjm> archivist that was particularly politically correct, well done!
[08:30:07] <archivist> we do have a history of convict export, we even export to Libya now
[08:30:16] <pjm> tee hee
[08:30:32] <Valen> doesn't seem to actually have done much in terms of reducing criminality there
[08:31:01] <archivist> I cam back from Libya in 1965 not long before the current nutter took power
[08:32:09] <MarkusBec_away> MarkusBec_away is now known as MarkusBec
[09:55:03] <piasdom> g'mornin all
[12:53:21] <ilya> Lead-in moves by g41 are located at exactly wrong sides of the contour. The change of directions of arcs, at least first arcs at the start of the contour, helps, but it's a double work. Am I right to think it's a default EMC2 behaviour?
[13:04:13] <ilya> It looks like there are problems when I add tool diameter compensation to the g-code produced by some program. Lead-in moves are exactly at wrong sides of the contour!
[13:08:51] <alex_joni> are you sure you mean G41?
[13:09:01] <alex_joni> maybe it's G42
[13:22:57] <ilya> alex_joni: when i try g42, contour is cut from the wrong side.
[13:24:55] <ilya> I wanted to create programs without compensations, and programer would use g43.1 h- and g41 d-
[13:27:51] <ilya> And e.g. clockwise mean g42 but lead-in happens at the left to the circle and the detail is cut.
[13:32:12] <ilya> So I had to know the diameter of the tool when I create the program.
[13:32:36] <ilya> Standard ISO output <>Linux Enhanced Machine Controller ??
[13:38:29] <skunkworks_> it is not cw or ccw - it is if you are going compinsate 'left' or 'right' of the path when 'walking' down the cutter path.
[13:40:30] <ilya> lead-in moves are programmed in EMC2 and are at wrong sides -> I have to create g-code for different diameters of the tools to be vegan and sane, or drink coffee, bread and dairy and read boring manuals.
[13:49:52] <ilya> the problem could be, circles are started ad lef, not at right, and lead-in moves are always at left in EMC2
[14:00:38] <ilya> Is there any default behaviour for lead-in moves to be at left to the contour? Otherwise, are they alwas at the right (g42) or left (g41) side of the contour.
[14:01:37] <fenn> bread doesn't help you read manuals does it?
[14:01:54] <fenn> coffee might
[14:02:11] <fenn> afaik coffee is vegan. might cause insanity though
[14:05:11] <ilya> fenn: you know whta I mean. After an hour of attempts, I just create programs with compensations, and machine operator can not use "g10 l1 ..."
[14:05:27] <ilya> fenn: insanity? oh yeah, it can
[14:07:39] <fenn> you've looked at nc_files/comp* right?
[14:14:17] <ilya> left! No, not yet.
[14:15:57] <ilya> fenn: compensations comes as lead-in moves at left to the contour in .cnc files from HeeksCNC.
[14:16:57] <fenn> HeeksCNC is probably wrong then
[14:17:39] <ilya> At winter, they come in a white dress, / At spring, they come in a blue dress, / At summer, they come in a green dress, / At autumn, they come in a gold dress
[14:17:43] <fenn> i noticed it always gouges a pocket on lead-in moves unless you manually pick the start and end point
[14:18:14] <fenn> what season is it in russia?
[14:18:18] <ilya> fenn: you are a though man to talk to about cam! :)
[14:18:42] <ilya> fenn: it's russian song about the love, which comes in various dresses
[14:27:57] <f^x_> f^x_ is now known as f^x
[15:09:51] <kanzure> wtf
[15:10:32] <ilya> kanzure: I'm fine, thanks; and you?
[15:10:45] <kanzure> just confused
[15:10:51] <fenn> kanzure: quick, what is lim(f^x) as f->x_
[15:11:06] <kanzure> x_ is what?
[15:11:19] <fenn> x.xxxxxx..
[15:11:53] <ilya> =x^x
[15:11:58] <ilya> x in power of x
[15:14:13] <EbiDK|AWAY> http://www.furaffinity.net/full/2515242/ 1:1 scale GUNDAM
[15:15:36] <ilya> fenn: you can derive the value from the variable under lim | and solve it
[15:18:35] <ilya> fenn: Do you solve some maths for university?
[15:20:45] <fenn> ilya: just making fun of kanzure, who is doing calculus homework right now
[15:21:30] <ilya> fenn: oh, okey.
[15:29:57] <ilya> but the creation of g-code for contours, with some known values for tool diameters and length offsets works just fine in HeeksCNC
[15:30:13] <ilya> fenn: What time of the day is there where you are?
[15:32:09] <ilya> morning at work?
[15:32:59] <fenn> don't ask me, i'm on mars time
[15:38:50] <ilya> on mars time? Which time is it now then?
[15:39:13] <ilya> fenn: or some work in the morning? :)
[15:46:14] <alex_joni> ilya: /ctcp user time
[15:47:19] <ilya> alex_joni: it's for server. I'm in Russia and my servers are in the U.S. and everywhere.
[15:48:29] <ilya> 11:47:48 -04:00 -- and it's mifnight +7
[15:53:29] <edison> i had a problem with emc - it doesn't seem to take g70/71, had to replace with g20/g21 - is there a reason? (ubuntu emc2 live cd)
[15:55:50] <jepler> edison: yes, emc uses g20/g21 to define units.
[15:56:24] <jepler> emc doesn't claim compatability with any other control's dialect of gcode
[15:57:20] <edison> i'm new to this so i kind of wondered why a known program like siemens nx cam outputs g7x by default (instead of g2x)
[15:57:31] <edison> s/known/well known, much used/
[15:57:32] <edison> :)
[15:57:52] <jepler> because some other control probably expects g70/g71 to define units
[15:58:08] <jepler> gcode is about as standard as BASIC was in the 80s -- almost not at all
[15:58:40] <edison> i see, well at least g0/g1/g2/g3 usually kindda works :)
[15:59:02] <jepler> usually programs for creating gcode have a "postprocessor" aka "post" which is used to make the output compatible with a specific dialect of gcode
[15:59:18] <ilya> jepler: really? I mean, really there are lots of differences?
[15:59:40] <edison> is it a known "problem" that some cam systems dont use g2/g3 but instead interpolate manually? on my emc2 setup the path will be much faster if the cam outputs g2/g3
[16:00:38] <edison> because there seems to be some inherent per-gcode-line delay in emc (or am i missing something)
[16:01:00] <ilya> edison: E.g. HeeksCNC offers to save G-code as /Standard ISO Output/ or /Linux Enhanced Machine Controller/, and as a few of other formats.
[16:01:18] <SWPadnos_> EMC will limit the speed of motion such that the machine can always be brought to a stop by the end of the current or next block
[16:01:27] <edison> ilya: yes, i understand. i helped my friend define an emc2 "postprocessor" for siemens nx
[16:01:30] <SWPadnos_> without violating acceleration constraints
[16:01:37] <edison> (and it works with arcs/circles, yey :)
[16:02:09] <SWPadnos_> so if you only output 0.001 inch segments, then EMC will never move the machine so fast that it can't decelerate to a stop in 0.001
[16:02:14] <SWPadnos_> inc
[16:02:16] <SWPadnos_> h
[16:02:29] <jepler> edison: by default (in G64 mode) emc plans each movement so that it touches each specified movement in at least one spot, and can stop by the end of each movement.
[16:02:51] <edison> that should explain why a list of small moves is much slower than proper g2/g3 then, thanks
[16:02:54] <ilya> SWPadnos_: Would G64.1 P- mode help?
[16:02:57] <jepler> if the segments are short enough (this also depends on your machine's acceleration) then yes, emc may not meet your requested feed rate
[16:03:31] <jepler> having smarter cam helps, but if you are stuck with dumb cam then you can use the "naive cam detector" G64 P- which internally combines movements that are within a tolerance of being a straight line
[16:03:37] <SWPadnos_> ilya, I think it can in some cases, because it will coalesce multiple collinear or nearly collinear segmengs into one
[16:04:03] <jepler> I am pretty sure you mean g64, not g64.1
[16:04:33] <ilya> SWPadnos_: although, it wouldn't try to move without stops?
[16:05:30] <edison> while you experts are here, what's the current state of the art open source cam? which accepts cad formats with proper curves and circles..
[16:07:59] <ilya> edison: HeeksCNC, DXF2GCODE
[16:08:24] <edison> tried both, i never got the heekscnc "adaptive roughing" to work
[16:08:36] <edison> do you have success with it?
[16:08:56] <ilya> I couldn't use adaptive roughing, also :(
[16:09:00] <edison> :(
[16:09:08] <edison> i noticed there was much svn activity though
[16:09:50] <edison> but i was depressed to see that the python scripts seemed to segfault in the c++ library.. libactp or something (which implements the actual algorithm?)
[16:10:57] <ilya> yes,
http://code.google.com/p/libactp/
[16:11:30] <archivist> edison, good bug reports are needed
[16:11:33] <ilya> edison: fenn or someone here said adaptive roughing is for high-sped machines and small depths of cutting.
[16:12:49] <edison> ilya: suits me nice, since i dont know what high-speed is :)
[16:12:54] <ilya> few codes for pocketing in sequense could replace adaptive roughing
[16:13:39] <ilya> edison: simply fast moves with small amount of material machined. Helps to not heat up the detail.
[16:14:40] <ilya> there's "starting/ending depth' and 'step' for pocketing. But it's for 2.5D
[16:14:52] <ilya> edison: Thomas?
[16:17:25] <ilya> (I think he's a former president of the USA.)
[16:18:18] <edison> i'm doing aluminium at 1200mm/min feed rate, .15mm depth of cut right now.. making a bracket for my new spindle motor :)
[16:20:43] <ilya> what is a tool diameter?
[16:21:04] <edison> 6mm
[16:21:42] <ilya> you're at work :)
[16:22:20] <edison> home :) got my first stepping xyz table a week ago!
[16:22:25] <edison> but yes, its fun!!
[16:23:24] <ilya> What a machine? Of a table-size?
[16:26:23] <edison> ~35x20x6cm
[17:00:40] <ily1> ily1 is now known as ilya_
[17:04:57] <ilya_> edison: How much did it cost, this macchining centre, to you?
[17:34:39] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[18:01:16] <Guest650> anyone have emc2 working on ubuntu 9.04?
[18:02:24] <ilya_> only as a simulator of machining
[18:03:03] <Guest650> running pretty stable as a sim on 9.04 for you?
[18:05:56] <ilya_> yes, read 5.5 of Installing EMC2
[18:06:05] <ilya_> I worked in Kubuntu 9.04
[18:06:54] <ilya_> install also "python-xml"; and "python-numeric" or similar for the /image-to-gcode/ program
[18:07:32] <ilya_> Guest650: read wiki-pages. I would help you, but I have no free data traffic left.
[18:07:44] <Guest650> no worries, i appreciate the heads up
[18:07:46] <Guest650> thanks ilya
[18:08:22] <ilya_> "Installing EMC2 in simulator mode to Ubuntu or Kubuntu 9.04." is the header somewhere in 5.5 chapter of "Installing EMC2"
[18:08:43] <ilya_> "python-xml" is for a Lathe
[18:10:00] <Guest650> are you a machinist ilya?
[18:16:00] <ilya_> no, i 'm only starting to working with cnc. cad>cam>gcode
[18:19:09] <Guest650> werd
[18:20:51] <ilya_> "weird"?
[18:22:07] <Guest650> word .. , e.g i see
[18:22:51] <ilya_> I see no the word .. :)
[18:35:59] <piasdom> Guess650:i don't think EMC2 works in 9.04 yet
[18:36:25] <SWPadnos> it works, but it's not trivial to set up
[18:36:38] <piasdom> Guess650: can you use ubuntu 8.04 ?
[18:36:39] <SWPadnos> you have to xompile a realtime kernel and EMC2 to make it happen
[18:36:50] <SWPadnos> compile
[18:37:59] <piasdom> SWPadnos: ny idea if or when they may upgrade EMC2 to 9.04 ?
[18:38:15] <SWPadnos> I suspect it will happen when 10.04 comes out :)
[18:38:22] <SWPadnos> since 10.04 will be an LTS release
[18:38:28] <piasdom> hahhahaha
[18:39:03] <piasdom> they're may 10.04 as we speak(type) ?
[18:39:27] <piasdom> i don't keep up with all the releases
[18:40:02] <SWPadnos> 10.04 willbe released in April of 2010 (hence the 10 and 04)
[18:40:14] <SWPadnos> 9.10 will be this october (10 / 2009)
[18:40:26] <piasdom> THAT"S how they do that :) ?
[18:40:29] <SWPadnos> yep
[18:40:34] <piasdom> i get it now
[18:40:39] <piasdom> thanks
[18:41:07] <SWPadnos> it's possible that there will be a new RTAI kernel + EMC2 packages before then, but I don't advise holding your breath
[18:42:00] <piasdom> that would be cool, mine works great now(thanks to ya'll),so i'll breathe
[18:42:38] <ilya_> SWPadnos: Why do not offer patched kernels?
[18:43:07] <SWPadnos> we don't maintain RTAI, we only distribute an RTAI kernel because it makes installation of EMC2 easier
[18:43:09] <piasdom> i guess Guess650 left
[18:43:13] <SWPadnos> you can get RTAI from anyone you like
[18:44:45] <ilya_> SWPadnos: It has patches for usual kernel...
[18:45:03] <SWPadnos> your point?
[18:46:23] <ilya_> My? Offer patched with RTAI kernels for Ubuntu 9.04 for various platforms. For newbies like me.
[18:47:07] <SWPadnos> we don't have the manpower to make nre RTAI kernels all the time. making them work on a lot of machines (as opposed to just my test machine or something) is not easy
[18:51:22] <ilya_> SWPadnos: Why many machines are needed? Couldn't it be x86/amd64bit?
[18:51:51] <SWPadnos> I don't mean architectures, I mean different PC designs
[18:52:34] <SWPadnos> making something that works on a Core2, an Athlon,, P3, P4, P2, and whatever else, with the variations in chipsets and peripherals, is the problem
[18:53:07] <ilya_> designs? Patches differ with only architectures, I thought.
[18:53:38] <SWPadnos> building reliable RT kernels seems to depend on the phase of the moon, among other things
[18:54:30] <ilya_> SWPadnos: why not patch kernels and offer patched kernels to compile
[18:55:02] <SWPadnos> that's no better than telling you to go get the patches yourself
[18:55:11] <SWPadnos> getting the patches and patching the kernel is not a problem
[18:55:20] <SWPadnos> coming up with a viable configuration is the problem
[18:55:25] <ilya_> Last time, I couldn't patch kernel. There were no needed kernel for set of RTAI patches
[18:56:20] <ilya_> and LTS-releases of Ubuntu Linux make you precomplie one reliable kernel?
[18:57:04] <archivist_attic> lts is just sensible!
[18:57:25] <ilya_> sensible for your feelings?
[18:57:51] <ilya_> I would help if I could do anything useful in programming.
[18:58:03] <archivist_attic> no, rebuilding machines is a pain dont need to do it every week
[18:58:26] <acemi> rtai patches are only for the vanilla kernel, not for the kernel which come with ubuntu
[18:58:53] <ilya_> vanilla? ice-cream?
[18:59:05] <archivist_attic> as volunteers the work should be the minimum necessary
[18:59:15] <ilya_> acemi: you say with mystries and tales!
[18:59:23] <acemi> the kernel which is distributed by Linus
[18:59:47] <ilya_> ubuntu has another kernel, from debian, right?
[18:59:59] <acemi> mostly
[19:00:19] <ilya_> Mostly right... What's left then?
[19:01:02] <ilya_> Debian has a better support for drivers, hasn't it?
[19:01:13] <acemi> no
[19:01:32] <acemi> ubuntu and debian have no big difference
[19:01:48] <ilya_> acemi: ubuntu kernels change more often then official linux kernels?
[19:02:00] <ilya_> *are changed
[19:02:36] <acemi> debian and ubuntu kernel is not vanilla kernel
[19:02:57] <acemi> it's patched by maintainer of the dist.
[19:03:42] <ilya_> acemi: And for ubuntu, I'm taking a vanilla kernel to patch with RTAI and compile it?
[19:04:15] <acemi> if you configure it corectly, it works
[19:05:05] <ilya_> all the options? One manual told I should leave default options.
[19:05:31] <acemi> there are some critical options
[19:05:44] <acemi> for ex. acpi, hpet etc
[19:05:51] <ilya_> which are defined by the patch?
[19:06:07] <ilya_> they're configured by the patch
[19:06:10] <acemi> no
[19:07:14] <ilya_> OK
[19:07:39] <ilya_> I wil be ready to read something when compile kernel.
[19:08:31] <acemi> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Debian_Lenny_Compile_RTAI#Configuring_kernel
[19:08:56] <ilya_> What does AXIS manual toolchange window is for?
[19:10:03] <ilya_> acemi: I read this page, but last time I did it, RTAI had no patch for kernel version I had, and I hadn't downloaded another kernel. Following to this page, everything is easy.
[19:10:53] <acemi> you can use any kernel, no need to use the same kernel with your distro
[19:11:25] <acemi> mostly a newer one is better
[19:11:39] <ilya_> acemi: I know, I just had one from marth's issue of xakep.ru
[19:11:47] <micges> OT: you can test first working vec2ngc cam (very good dxf support, output gcode for emc): source are at: 'svn co
https://vec2ngc.svn.sourceforge.net/svnroot/vec2ngc vec2ngc'
[19:12:06] <ilya_> acemi: You're the man to ask at :)
[19:22:13] <ilya_> micges: contours, or also pocketing and zigzag?
[19:23:56] <micges> simply 3d milling for now
[19:24:21] <ilya_> 3d milling of upper surface?
[19:25:16] <ilya_> Can I use wget -r
https://vec2ngc.svn.sourceforge.net/svnroot to get the source code?
[19:26:52] <micges> now you can download latest tgz from
https://sourceforge.net/projects/vec2ngc/
[19:28:49] <ilya_> micges: I will do it, I hopefully think, tomorrow.
[19:38:42] <ilya_> micges: Saying about the adaptive roughing in HeeksCNC: for 3D objects with no many slopes, it is possible to use pocketing with many steps down and assign higher feedrates. And then, after all, change a tool if you want and add a ZigZag.
[19:43:34] <ilya_> cradek: today, g92.1 cancels g92 x- offset. I spent few hours last day trying it on a lathe with no effect.
[19:52:03] <ilya_> * ilya_ has his pocket money, he's well-fed
[19:53:43] <skunkworks_> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CoordinateSystems
[19:59:02] <ilya_> skunkworks exactly a "Coordinate Systems"? g92 and g92.- are not enough?
[20:01:16] <ilya_> It's strange. As I said once in a while, HeeksCNC let no non-integer numbers for a tool diameter and for steps down. Therefore, pocketing should be in an "O<programme1> sub" and should be called each time you se an offset with g92 z-.
[20:02:42] <ilya_> * ilya_ is reading file:///home/hornygirl/emc-version1/docs/html/gcode_coordinates.html