Back
[01:24:11] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[02:05:40] <A-L-P-H-A> emc 2.1 released?
[02:11:38] <cradek> it's ready but we're debating how exactly to release it
[02:12:39] <cradek> we could make it appear in the update manager just as any other new version, or we could require the user to do something to choose to switch from 2.0 to 2.1
[02:12:58] <cradek> (this is an issue mostly because a few little things need to be changed in any customized configurations)
[03:28:53] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/nist-lathe/nist-lathe.hal: fix lathe spindle sync signals
[03:28:53] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/sim/lathe.hal: fix lathe spindle sync signals
[03:28:53] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/lathe-pluto/lathe-pluto.hal: fix lathe spindle sync signals
[03:28:53] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/max/max.hal: fix lathe spindle sync signals
[03:34:58] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/lathe-pluto/lathe-pluto.hal: backport: fix lathe spindle sync signals
[03:34:58] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/max/max.hal: backport: fix lathe spindle sync signals
[03:34:58] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/nist-lathe/nist-lathe.hal: backport: fix lathe spindle sync signals
[03:34:58] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/sim/lathe.hal: backport: fix lathe spindle sync signals
[03:40:41] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/nist-lathe/nist-lathe.hal: remove inaccurate comments
[03:41:18] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/nist-lathe/nist-lathe.hal: remove inaccurate comments
[04:07:57] <CIA-8> 03jepler 07TRUNK * 10emc2/src/hal/utils/halcmd.c: fix 'net arrow' bug
[04:14:35] <CIA-8> 03jepler 07v2_1_branch * 10emc2/src/hal/utils/halcmd.c: merge rev 1.113: fix 'net arrow' bug
[04:32:31] <ve7it> ve7it is now known as LawrenceG
[05:09:17] <Jymmm> Jymmm is now known as Jymmmmm
[05:53:22] <A-L-P-H-A> heh.
http://www.i-am-bored.com/bored_link.cfm?link_id=21690
[05:55:51] <A-L-P-H-A> hahaha.
http://www.i-am-bored.com/bored_link.cfm?link_id=21676
[06:04:16] <K`zan> That one had to have been shot in seattle :-/.
[06:07:43] <ejholmgren> not that anyone wants to know this ...
[06:08:00] <ejholmgren> but I just found the old video of the time the basement of our rental house backed up with sewage
[06:08:14] <ejholmgren> and poo was floating around in it
[06:08:20] <ejholmgren> sounds like youtube time to me :)
[06:08:54] <K`zan> Had that happen in two apartments I;ve lived in - will no longer live in an apartmet except on the top floor - shit does indeed flow downhill...
[06:29:12] <fenn> so do machine tools, unfortunately
[06:37:53] <ds3> announcing the self levitating Vertical knee mill...
[06:46:05] <ds3> would anyone by chance know SPICE?
[06:46:59] <fenn> try in ##electronics
[06:47:16] <ds3> thanks
[06:47:23] <fenn> but that question gets asked a lot and seldom garners a response
[06:47:33] <fenn> better to ask a specific question
[06:47:49] <ds3> I just want to see if someone knows what does it mean when spice says thereis negative current through a diode
[06:47:51] <ds3> I'll try them
[06:48:12] <fenn> charge recombination maybe
[06:48:36] <ds3> Oh... the complicated stuff :/
[06:48:50] <ds3> =)
[06:49:01] <fenn> that's why you're using spice in the first place
[06:49:31] <ds3> I just want to see if I can get a laser diode driver to work with a 1MHz pulse rate
[06:50:01] <fenn> 0.o
[06:50:06] <fenn> is that all?
[06:50:12] <ds3> yeah
[06:50:26] <ds3> unless you have a pointer for a pulsed laser diode driver ? =)
[06:50:51] <fenn> i know that laser diodes will die if the drive exceeds the rated current for like 1 picosecond
[06:51:13] <fenn> so that makes them fiddly and expensive to design
[06:51:52] <ds3> according to SPICE, Idiode never exceeds Imax, but it does go negative even though Vdiode is never negative :/
[06:58:59] <fenn> inductance somewhere
[06:59:17] <fenn> oh, no that would change the voltage too
[06:59:34] <fenn> sorry, dunno
[07:01:19] <ds3> heh... it is a puzzle.
[07:04:06] <ds3> hmmmm I have no chance of seeing it if I build the circuit :(
[07:30:59] <K`zan> gn all
[07:50:34] <fenn> arrrrrgh
[07:50:43] <fenn> joomla killed all my changes, mercilessly
[07:51:00] <fenn> evil evil thing!
[07:53:28] <fenn> waaah
[09:45:59] <alex_joni> logger_emc: bookmark
[09:45:59] <alex_joni> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2007-01-28.txt
[09:46:11] <Martin_Lundstrom> good morning alex_joni
[09:55:58] <alex_joni> morning Martin
[09:56:51] <alex_joni> cradek: how did you install the upgrade package? did you use dpkg -i ./emc2-foo.deb? if so, I noticed that doesn't work ok for updating. But creating a local repository (as I described on the wiki page) makes it update without problems.
[09:57:04] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emc2.1.0
[09:57:58] <alex_joni> you can even update using the update manager after you set the repo up. I think dpkg sucks at pulling in dependencies, and apt does the right job
[09:59:56] <Martin_Lundstrom> alex_joni, any fun stuff at work lateley?
[10:01:19] <alex_joni> hmm.. depends on your version of fun :)
[10:01:44] <alex_joni> got an old bot working again
[10:01:53] <alex_joni> 1988 old :)
[10:01:57] <Martin_Lundstrom> cool
[10:02:14] <Martin_Lundstrom> what is the use?
[10:02:32] <alex_joni> welding .. it's all I do at work :)
[10:02:59] <Martin_Lundstrom> ok
[10:03:21] <Martin_Lundstrom> Is it going to be used at one of your customers?
[10:04:11] <alex_joni> this one is at a university
[10:04:59] <Martin_Lundstrom> inteesting
[10:11:19] <alex_joni> it can be :)
[10:14:56] <lerneaen_hydra> 'morning all
[10:17:09] <alex_joni> morning LH
[10:24:07] <Martin_Lundstrom> morning lerneaen_hydra
[10:29:39] <lerneaen_hydra> anything fun happening?
[10:30:18] <alex_joni> * alex_joni goes to make some sushi
[10:30:27] <lerneaen_hydra> umai!
[10:30:31] <alex_joni> nori
[10:30:47] <Martin_Lundstrom> alex_joni, send me some when your done, plz
[10:31:57] <fenn> DCC RECV MAKI
[10:32:14] <Martin_Lundstrom> lol
[10:33:36] <alex_joni> :)
[10:33:59] <fenn> http://www.catb.org/~esr/writings/no-sushi/
[10:35:10] <Martin_Lundstrom> apt-get -install alex_jonis_sushi /dev/myMouth
[10:36:25] <alex_joni> Climbing Mount Fuji,
[10:36:25] <alex_joni> Cherry blossoms in the wind,
[10:36:26] <alex_joni> I see a Coke stand.
[10:36:28] <alex_joni> loool
[10:36:51] <Martin_Lundstrom> todays poet, alex_joni
[10:37:29] <alex_joni> * alex_joni plays to read that
[10:37:36] <alex_joni> Martin_Lundstrom: it was from fenn's link
[10:37:43] <Martin_Lundstrom> ok
[10:37:51] <alex_joni> fenn: got my comments on the licensing?
[10:37:59] <fenn> yeah
[10:38:20] <alex_joni> hope they made some sense :)
[10:38:35] <fenn> basically, you audited everything but forgot to write it all down :)
[10:38:45] <alex_joni> 2-3 times :)
[10:39:32] <fenn> i coulda swore the emc front page said "we are making the transition to GPL"
[10:39:46] <alex_joni> it said a few years ago :)
[10:39:53] <fenn> no this was yesterday
[10:40:09] <alex_joni> hmm.. you had a very old cache hit?
[10:40:09] <fenn> i logged in to fix it and that's when i asked if it was ok to do so in irc
[10:40:09] <alex_joni> :D
[10:40:28] <alex_joni> I didn't touch the fron page..
[10:40:44] <alex_joni> Last Updated ( Sunday, 01 October 2006 )
[10:40:49] <fenn> * fenn thinks joomla is possessed with evil voodoo spirits
[10:40:52] <alex_joni> but I bet that was picture related
[10:41:03] <alex_joni> fenn: :P
[10:41:15] <fenn> i poked around at the about page today
[10:41:24] <alex_joni> fenn: care for some nice german tunes?
[10:41:28] <fenn> sure
[10:42:14] <alex_joni> seems good (the about page)
[10:43:31] <alex_joni> hmm.. seems I need to upload them.. will take a while
[10:47:38] <Martin_Lundstrom> alex_joni, is the industry in Romania growing?
[10:47:55] <Martin_Lundstrom> at what rate, do you have any clue?
[10:55:13] <alex_joni> 27.pi%
[10:55:35] <alex_joni> Martin_Lundstrom: no idea :)
[10:55:41] <alex_joni> but it is growing steadily
[10:56:09] <Martin_Lundstrom> ok, but people is getting it better or?
[10:56:27] <alex_joni> yup.. for 16 years now
[10:56:38] <alex_joni> but we went about 50 in the wrong direction
[10:56:43] <alex_joni> so it'll be a while :)
[10:57:12] <alex_joni> imo mentality is the biggest issue.. and we still nees 1-2 generations to pass for that to change
[10:57:16] <Martin_Lundstrom> I think it is too slow
[10:57:38] <alex_joni> it can't go faster
[10:57:46] <alex_joni> people won't accept it
[10:58:24] <Martin_Lundstrom> would more external monetary help, speed up the process you think?
[10:58:32] <awallin> hi, anyoen awake yet?
[10:58:40] <Martin_Lundstrom> hello
[10:58:42] <awallin> anyone
[10:58:46] <alex_joni> Martin_Lundstrom: money always helps
[10:58:47] <alex_joni> hi anders
[10:58:55] <alex_joni> bbl
[10:59:10] <awallin> I messed around with the python+opengl stuff yesterday, but nothing really nice to show yet
[10:59:34] <awallin> I did make a mind-map to get a bit organized:
http://imagebin.org/7046
[10:59:49] <awallin> anonimasu, Dallur, did you hear that, go check out the image and see what you think
[10:59:52] <fenn> heh nice blobbies
[11:00:18] <Martin_Lundstrom> blender has alot of open gl python stuff
[11:02:17] <awallin> I need to get the hierarchy of classes set up properly... then I expect progress will be much more rapid when the basic framework is there
[11:02:36] <awallin> now I worked with raw OpenGL, since VTK documentation is so sparse
[11:02:52] <Martin_Lundstrom> sounds hardcore :)
[11:03:40] <fenn> cam software will be mostly about data structures and algorithms anyway
[11:04:03] <fenn> it would be nice to not have to duplicate effort though for the cad system
[11:04:13] <awallin> yes, but so far I got some help from Julia Todd/freesteel, who is eager to help with the algorithm part
[11:04:26] <fenn> yeah i talked to him earlier but it didnt go anywhere
[11:04:33] <awallin> som most of the cam part is handled, as long as there is a working UI around
[11:04:48] <fenn> feel free to assign me a chunk if you think i can handle it
[11:05:00] <awallin> well, I want to make it go somewhere now
[11:05:16] <awallin> what would you say that your strengths are?
[11:05:22] <fenn> lots of free time :)
[11:05:29] <awallin> (I'm not a professional programmer by any means)
[11:05:34] <awallin> oh, wow, that's rare
[11:05:38] <fenn> i just revised my sourceforge profile today
[11:06:14] <Martin_Lundstrom> fenn: are you not selfemployd?
[11:06:34] <awallin> so right now my choices are: wxPython for GUI toolkit and OpenGL for viewport, can you live with that?
[11:06:37] <fenn> awallin:
http://sourceforge.net/people/viewprofile.php?user_id=97658
[11:06:46] <awallin> I'm on WinXP, but it should work under Linux also
[11:07:27] <fenn> yeah i would have chosen wxpython too, but i guess python/opengl support is wishy-washy?
[11:07:51] <fenn> maybe we can just steal jepler's minigl library
[11:08:01] <awallin> I've had no problems yet
[11:08:13] <awallin> I use the glCanvas widget from wxpython
[11:08:23] <awallin> and pyOpengl
[11:08:54] <awallin> anyway, one of the architectural design problems is how to separate geometry from how geometry is drawn(which might change)
[11:10:06] <awallin> I guess I'm just having a hard time grasping how the components of this system communicate with eachother
[11:10:31] <fenn> well if you have a relational geometry system you are probably going to use implicit geometry (primitives, csg) rather than a mesh
[11:10:37] <awallin> I'm sure I could write the geometry class fairly easily. But how does the UI communicate with it, how does the viewport draw the geometry
[11:10:56] <awallin> fenn: yes
[11:11:29] <awallin> there's something called the command pattern, maybe that's what I need?
[11:11:34] <fenn> command pattern?
[11:11:44] <awallin> or some kind of central "controller" through which everything goes
[11:11:44] <fenn> model/view/controller?
[11:12:07] <awallin> http://en.wikipedia.org/wiki/Command_pattern
[11:12:16] <fenn> must confess i never really understood what that stuff meant
[11:13:01] <awallin> just how objects talk to eachother and how you build a good class hierarchy
[11:13:59] <fenn> how about we make something simple, see how it goes, and then write it correctly the second time :D
[11:16:04] <awallin> are you more interested in CAD, or CAM?
[11:17:29] <fenn> i want a full system.. dunno which will be more useful to start with :\
[11:17:42] <awallin> just drawing two kinds of objects would be needed at first: STL surfaces, and Lines
[11:18:03] <awallin> if we want to start with the toolpath generation
[11:18:23] <fenn> cam seems like a simpler target
[11:18:56] <fenn> just input configuration and output
[11:19:08] <awallin> input would be an STL file
[11:19:30] <lerneaen_hydra> IMO CAM seems like a more applicable target to begin with, as there are lots of (OSS) apps that can generate models
[11:19:30] <awallin> then the toolpaths are generated, they will all be Line objects (segment after segment after segment)
[11:19:56] <awallin> then the toolpath may be output in some suitable format (maybe filtered first)
[11:20:07] <awallin> do you have time/energy to look at this now?
[11:20:21] <fenn> yes, i may go to bed in a couple hours
[11:21:02] <awallin> ok, I will put what I have on my website
[11:21:15] <awallin> beware that I broke it yesterday so it doesn't do anything useful
[11:21:27] <awallin> I'll add comments before I post it so you might make sense of it
[11:22:15] <fenn> should we set up some kind of cvs or darcs or something?
[11:22:36] <awallin> yes probably, but the project needs a good kickstart first
[11:22:56] <fenn> it gets out of hand quickly
[11:23:09] <awallin> a core group needs to come up with the basic architecture for the system, and the architecture needs to be good from the start
[11:24:18] <awallin> oh, and we need a name to set up cvs on sourceforge... naming is really hard
[11:24:21] <awallin> :)
[11:24:35] <fenn> i'm pretty anti-sourceforge lately
[11:24:44] <fenn> but whatever
[11:24:57] <awallin> are there other free places where this could be hosted?
[11:25:07] <fenn> savannah, berlios.de
[11:26:01] <awallin> I'm sorry now that I look at the code it's a complete mess... I'd like to clean it up before showing it so it will not be before evening (in 10h where I am)
[11:26:02] <fenn> oh, someone is ddos'ing berlios right now :(
[11:26:25] <fenn> ok i'll wait til tomorrow then
[11:27:01] <awallin> if you think savannah is OK, I might setup a project there
[11:27:21] <awallin> do you have experience with setting up a prject on savannah
[11:27:40] <fenn> no
[11:28:16] <fenn> hrm. "The review we do can be long and tedious for both the submitter and the reviewer."
[11:28:39] <awallin> yah...
[11:28:52] <awallin> I wonder if it could be hosted on linuxcnc.org
[11:29:39] <awallin> "SlaveCAM" ?
[11:30:09] <fenn> back when i was going to use brlcad libraries i was going to call it "cam-o-blammo"
[11:30:25] <awallin> that's a bit long
[11:32:14] <awallin> I think I'm going to ask the guys about hosting this kind of project on linuxcnc.org - that would be the easiest
[11:32:15] <fenn> i seem to have forgotten all of the potential names
[11:32:20] <fenn> yes it would
[11:32:52] <fenn> it could be thought of as a .stl filter for axis
[11:33:05] <fenn> or something
[11:33:16] <lerneaen_hydra> emcam? ;)
[11:33:19] <lerneaen_hydra> or maybe emCAM
[11:33:34] <awallin> yes, but I would not consider integration with emc at this point, I don't mind having the toolpath generation in a separate app
[11:33:47] <lerneaen_hydra> if tight emc integration is what you're going for
[11:33:51] <lerneaen_hydra> ah, right
[11:34:12] <fenn> its really easy to make a filter for axis
[11:34:23] <fenn> just a python script that prints gcode
[11:34:34] <awallin> and, if we are going to use wxpython on pyopengl+glut then the dependencies are different from emc
[11:34:53] <awallin> and, I'd like for it to be cross-platform, i.e. run on windows and linux (+mac?)
[11:35:22] <fenn> yeah and that's not a bad way to go for emc's gui either
[11:35:26] <lerneaen_hydra> how's cross-platform capability wrt opengl, wxpython and the like?
[11:35:42] <awallin> wxpython shoudl be really good
[11:35:45] <fenn> lerneaen_hydra: that's the point of wxpython
[11:35:51] <lerneaen_hydra> ooh, nice
[11:35:54] <fenn> it calls gtk or win32
[11:35:57] <fenn> i think
[11:36:01] <awallin> opengl might be harder (require some tricks)
[11:36:04] <lerneaen_hydra> so essentially it's only the other deps that can break
[11:36:26] <awallin> and, the CAM stuff from Julian is currently only in a dll file, which works under windows
[11:36:39] <lerneaen_hydra> no sourcecode?
[11:36:53] <awallin> It's written in C or C++ and then compiled, and somehow mangled with SWIG so that the functions are callable from python
[11:36:57] <fenn> what is he releasing anyway?
[11:37:01] <awallin> lerneaen_hydra: no, not yet
[11:37:11] <fenn> surely not the cash cow adaptive clearing algorithm
[11:37:18] <lerneaen_hydra> awallin; think you can get it?
[11:37:52] <awallin> fenn: what I have now is a z-slicing algorithm, take an STL file and imagine a plane cut's it at some Z-value. it will output the contour where the plane cut it (offset by the tool radius/diameter)
[11:38:14] <fenn> but as he said, most cam algorithms are basically commodities so it wouldnt be a disadvantage to open source them
[11:38:41] <awallin> lerneaen_hydra: I think Julian has a positive attitude to this, but he said releasing the source for everything right now is not possible
[11:39:09] <lerneaen_hydra> hmm, I see, NDA's?
[11:39:09] <fenn> waterline seems like pretty standard geometry
[11:39:15] <fenn> == z slicing
[11:39:16] <awallin> but those two guys are pro's on the CAM stuff so we definitely need their help, wether it's ready C-code, or just advice on how to do things
[11:39:44] <awallin> lerneaen_hydra: it's their own code, but they might have licensed it to cimco + others
[11:39:53] <lerneaen_hydra> waterlining seems to be very easy to implement
[11:40:00] <lerneaen_hydra> ah, ok
[11:40:05] <lerneaen_hydra> difficulty ensues
[11:40:24] <awallin> reading their blog, it seems that many people want their source code...
[11:40:36] <fenn> yep
[11:40:47] <awallin> anyway, our program should be able to work with an algorithm from anyone
[11:41:34] <fenn> i dont think that basic stuff like waterline and constant stepover will be hard to write from scratch
[11:41:37] <awallin> but I think if we get something going, the freesteel guys will contribute.
[11:41:53] <awallin> yes
[11:42:22] <awallin> fenn: so, if you want to start with something, learn how to interface between C and python, using swig (that's what julian used=
[11:42:26] <fenn> its the full 3d and HSM stuff that's hard
[11:42:48] <fenn> ok
[11:43:03] <awallin> I know very little about how to write a C program that's callable from python
[11:43:52] <fenn> look at gdepth
[11:44:00] <awallin> jepler should be a big help with the C<->Python stuff
[11:44:50] <awallin> what about jeplers gdepth?
[11:45:11] <fenn> actually we can probably use a lot of gdepth for doing constant stepover
[11:45:30] <awallin> ??
[11:45:49] <fenn> well, basically you subtract the depth of cut until you get to the surface you want right?
[11:46:25] <awallin> yes, there's a thing about this on freesteel, finding the contact point btw the cutter and a triangle
[11:46:29] <fenn> take the maximum z value of the surface under the tool, and that's your tool's Z height
[11:46:55] <awallin> that might be an algorithm to start with also: cutter shapes(cylinder, ball, bullnose) and find the contact with a triangle
[11:46:58] <fenn> the contact point stuff is more useful for pencil milling
[11:48:14] <awallin> as you said, I think the basic cam algorithms will appear pretty quickly once we have a framework to work with
[11:48:32] <fenn> so, what have you written so far?
[11:48:51] <awallin> a wxpython frame which has a glcanvas inside it
[11:49:00] <fenn> ok
[11:49:09] <awallin> using simple commands I can draw stuff inside the glcanvas
[11:49:25] <awallin> using STLtools from Julian I can import an ascii or binary STL file and display it
[11:49:36] <fenn> commands like GL_TRIANGLES?
[11:49:39] <awallin> I can rotate and zoom with the mouse, panning is a bit crap
[11:49:44] <awallin> yes, gl_triangles
[11:50:01] <awallin> this is in "direct" mode (if I remember the terminology) not using a display list (yet)
[11:50:56] <awallin> then I can call Julian's zslice and get a list of points that lie on the zslice contour. but I haven't drawn these yet
[11:51:16] <awallin> because I wanted to write the architecture right from the beginning
[11:51:52] <awallin> another approach would be to do a simple program that does model to toolpath, as you suggested before
[11:52:15] <awallin> but I'm confident that the cam algorithms work, so I wanted to work on the UI stuff first
[11:53:23] <fenn> it looks like dallur wants to write a cad library first and work on the actual program later :D
[11:53:47] <awallin> yes, he started on something like that, the geometry tree in my mindmap
[11:55:08] <awallin> I need to go now, but I'll be back later. As I said earlier, if you are interested, a small example of how a C-program can be called from python using swig would be useful
[11:55:10] <fenn> i dont understand the bead/ring/magnet
[11:56:05] <fenn> a snake is like a 1d magnet?
[11:56:10] <fenn> er.. something like that
[11:56:40] <fenn> nevermind
[11:57:30] <awallin> http://aerohydro.com/products/rg/rg.htm
[11:58:02] <awallin> a bead is a point that lies on a curve
[11:58:03] <fenn> how can you patent a conceptual framework!?
[11:58:07] <awallin> like beads on a string
[11:58:15] <awallin> fenn: in the USA you can patent almost anything...
[11:58:28] <awallin> fortunately not everyone lives in the USA
[11:58:41] <awallin> a ring is a bead on a snake
[11:58:49] <awallin> a magnet is a point on a surface
[11:58:57] <awallin> a snake is a curve on a surface
[11:59:47] <awallin> anyway, this relational geometry would be for the CAD part of the program. CAM will work with points, lines and STL surfaces
[11:59:49] <fenn> i dont see any need for a distinction
[11:59:54] <fenn> right
[12:00:22] <awallin> well, a bead would be defined as Bead(myLine, t)
[12:00:40] <fenn> shouldnt it be the other way around?
[12:00:48] <awallin> where myLine is a reference to the line it lies on, and t is a parameter from 0 to 1 which says where along the line the bead lies
[12:01:06] <awallin> the Line is supported by two points Line(startPoint, endPoint)
[12:01:26] <awallin> and the bead is supported by the line Bead(Line, t)
[12:01:45] <awallin> a simple surface is made from two lines Surface(Line,Line)
[12:02:16] <awallin> a magnet: Magnet(Surface, u, v) u,v= [0,1] are coordinates within the parametric surface
[12:02:32] <awallin> I really need to go now, catch you later
[12:02:36] <fenn> ok bye
[12:37:07] <Rugludallur> heeeelooo
[12:42:29] <Martin_Lundstrom> elo
[12:42:41] <Martin_Lundstrom> How is your table?
[12:59:02] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[13:20:24] <alex_joni> hi guys
[13:22:52] <lerneaen_hydra> Rugludallur; why do you switch names between Rugludallur and Dallur so often?
[13:23:12] <lerneaen_hydra> or are you not the same person O.o
[13:25:24] <alex_joni> two personalities :)
[13:27:00] <lerneaen_hydra> ah, ok
[13:35:38] <alex_joni> they sometimes claim to inhabit two different bodies, but I wouldn't bet on it
[14:02:05] <lerneaen_hydra> does anyone know of an app to go from a heightmap to a dxf?
[14:03:07] <alex_joni> ``My wish for peace and harmony among all who work for freedom -- whether in software or elsewhere.''
[14:04:23] <cradek> lerneaen_hydra: to what in a dxf?
[14:04:59] <lerneaen_hydra> a 3d-contour
[14:05:29] <lerneaen_hydra> stl would work too I guess
[14:05:41] <cradek> triangle mesh?
[14:05:43] <lerneaen_hydra> yeah
[14:06:12] <lerneaen_hydra> I was hoping that by just throwing enough memory/disk space at it the aliasing won't be too nasty
[14:06:20] <alex_joni> this is some great reading (thanks fenn) :
http://www.catb.org/~esr/writings/no-sushi/
[14:06:27] <cradek> you have a grid? wouldn't be very hard to translate but it's two triangles per grid point
[14:06:44] <lerneaen_hydra> yeah, I have a bitmap/whatever format image
[14:07:04] <lerneaen_hydra> and I want to make an STL/DXF based on it
[14:07:15] <lerneaen_hydra> (err, heightmap)
[14:07:52] <alex_joni> "Kyoto's pizza (a Japanese imitation of an American imitation of Italian food) turns out to feature toppings like squid, eggplant, and pear. Very weird."
[14:08:50] <lerneaen_hydra> heh, in sweden there's tons of so called kebab pizza
[14:10:21] <lerneaen_hydra> cradek; any ideas?
[14:11:49] <cradek> http://timeguy.com/cradek-files/stl-to-dxf/stl-to-dxf.py
[14:12:05] <cradek> here is a very basic program that shows how to generate a DXF of 3DFACE entities
[14:12:23] <cradek> instead of starting with STL you could read the image
[14:12:53] <lerneaen_hydra> * lerneaen_hydra can't code
[14:12:57] <lerneaen_hydra> not yet at least
[14:13:17] <cradek> nothing like a project to get you started
[14:13:46] <lerneaen_hydra> that's true ;)
[14:13:51] <cradek> http://timeguy.com/cradek-files/image-to-gcode/image-to-gcode.py
[14:14:02] <cradek> this reads an image and accesses the pixels directly
[14:14:15] <cradek> you just have to massage the two together :-)
[14:14:44] <cradek> do you understand conceptually what the triangles are that you would output?
[14:14:51] <lerneaen_hydra> yeah
[14:15:12] <lerneaen_hydra> at least I have one possible model of it in my head
[14:15:34] <cradek> I'm imagining a grid like a crossword puzzle, with diagonals drawn one way through each square
[14:15:52] <lerneaen_hydra> oh, ok, so four triangles per pixel
[14:15:52] <cradek> your height map is one height for each intersection
[14:16:07] <cradek> no, just two
[14:16:25] <lerneaen_hydra> hmm, that would also work
[14:16:28] <lerneaen_hydra> less data
[14:16:28] <cradek> well to be more clear, two per "square"
[14:17:01] <lerneaen_hydra> why wouldn't square = pixel?
[14:17:16] <cradek> ignoring the boundaries, it is one pixel per square
[14:17:33] <lerneaen_hydra> ack, boundaries too
[14:17:40] <lerneaen_hydra> I wonder what I'll do about them
[14:17:54] <cradek> stop generating triangles when you get to them :-)
[14:18:26] <lerneaen_hydra> I was thinking more like if my cam app will throw a hissy fit if I try to import a shell
[14:18:48] <cradek> oh you think it should be closed?
[14:18:57] <lerneaen_hydra> I'm not sure ATN
[14:18:58] <lerneaen_hydra> *ATM
[14:19:44] <cradek> it would be only a little harder to close it - you would make triangles "down" from the edges, and then a big pair of triangles to make a square on the bottom
[14:20:19] <lerneaen_hydra> yeah
[14:20:19] <cradek> the lower surface should be a bit lower than the lowest data point
[14:20:24] <lerneaen_hydra> exactly
[14:20:46] <cradek> actually, dxf lets you do quads, which makes this whole thing easier
[14:21:16] <cradek> I'm not sure if they're required to be planar - if so you better use triangles instead for the map (but you can still use quads for the side/bottom)
[14:21:24] <lerneaen_hydra> quads?
[14:21:30] <lerneaen_hydra> oh, squares?
[14:21:33] <cradek> a four-sided triangle
[14:21:42] <lerneaen_hydra> isn't that an oxymoron?
[14:21:50] <cradek> I think a 3DFACE can have 3 or 4 vertex
[14:25:55] <lerneaen_hydra> hmm, it turns out my 3d app can do this, although it's more than slightly convulted
[14:30:17] <lerneaen_hydra> sometime I'll probably try to connect the two together
[14:42:45] <rcsu> hi *
[14:43:18] <rcsu> installing you ubuntu/emc with a resolution of 640x480 is really crappy
[14:43:35] <rcsu> you cant see the buttons of the installer
[14:49:24] <cradek> rcsu: hi, you might mention that on the #ubuntu channel, and maybe ask how to file a bug report so they can fix it in later versions
[14:49:55] <rcsu> hi cradek
[14:50:01] <cradek> hi
[14:50:02] <rcsu> yea, should really do it
[14:50:26] <cradek> I've seen others say that too, so they should know about it
[14:50:59] <cradek> is 640x480 a limitation of your monitor? EMC might not work very well unless you have 800x600 or more
[14:52:14] <rcsu> no, my monitor can drive 1280x1024
[14:52:32] <rcsu> * rcsu is installing now
[14:55:14] <cradek> there's an option on the initial menu to pick the vesa video driver - don't remember what it's called - but you might try booting with that
[14:55:44] <cradek> you may have a problem with your particular video card - again, maybe asking in #ubuntu would help
[15:27:08] <Vq^> alex_joni: thanks for the M-code tip
[15:41:31] <awallin> hi all
[15:42:15] <rayh> Hi anders
[15:42:45] <awallin> lots of interest in cad/cam lately
[15:44:04] <awallin> was discussing this with fenn, and we came to the conclusion that it would be nice if a cvs repo for cad/cam could be set up
[15:44:39] <awallin> I wonder if there is room/bandwidth for that on linuxcnc.org?
[15:45:15] <rayh> Should be. But a whole cad/cam system is a big project.
[15:45:49] <awallin> sure, need to start small. ability to import stl files and export basic toolpaths would be v.0.1
[15:46:47] <rayh> So not CAD, just CAM?
[15:47:21] <awallin> yes, I think cam would be the more interesting part to start with.
[15:47:27] <rayh> Hi Dan. awallin just brought up one of your favorite subjects.
[15:47:33] <awallin> there are very few open source cam programs
[15:47:37] <DanielFalck> rayh, hi
[15:47:46] <DanielFalck> awallin, hi
[15:47:54] <awallin> hi DanielFalck
[15:48:01] <DanielFalck> that's true
[15:48:24] <DanielFalck> there are lots of little bits and pieces though
[15:48:37] <rayh> awallin: Dan is the original owner of linuxcnc.org
[15:48:56] <awallin> ah, I didn't know that.
[15:49:23] <DanielFalck> rayh, currently on my ubuntu dapper machines, I am using Qemu
[15:49:31] <DanielFalck> to run win98 cadcam
[15:49:34] <DanielFalck> and it works fine
[15:49:42] <DanielFalck> but, it's not ideal
[15:49:54] <rayh> he paid for the name and steve_stallings served the site.
[15:50:04] <DanielFalck> so, I have rhino3d, vectorcam, and autocad running
[15:50:19] <rayh> Someone was saying qemu was darn slow.
[15:50:41] <DanielFalck> not too bad for me, I got a darn fast machine :)
[15:50:50] <rayh> have you tried vector
[15:51:04] <rayh> sorry I wasn't reading right.
[15:51:36] <DanielFalck> I have a 1gig AMD processor in the garage and a 3 gig Intel here in the house
[15:51:43] <awallin> who would I talk to to set up a new cvs thing?
[15:51:48] <DanielFalck> connected with ethernet
[15:52:04] <rayh> awallin: How do you see us developing the material and tool cutting database for CAM.
[15:52:39] <DanielFalck> awallin, have you checked this out?
[15:52:40] <DanielFalck> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?Cam
[15:52:46] <awallin> rayh: you mean a database of material hardnes, and a tool database with suggested feeds/speeds?
[15:53:13] <rayh> right.
[15:53:29] <awallin> DanielFalck: yes, I've looked at most of the links, but nothing is really close to an opensource version of mastercam of surfcam or similar
[15:53:47] <DanielFalck> awallin, that's true
[15:53:59] <awallin> rayh: I guess these databases would be built up slowly as people with real machines and experience contribute material and tool parameters
[15:54:20] <DanielFalck> awallin, you are using python now right?
[15:55:10] <awallin> DanielFalck: yes, with wxpython for gui, and opengl for graphics. and the idea is to write cpu-intensive stuff in either c or c++ and call those from python
[15:55:25] <DanielFalck> cool
[15:55:45] <tomp> aside: in tkinter with Ubuntu/gnome, if the cursor is replaced by self.config(cursor="watch"), it doesnt use the stock tcltk watch, instead the gnome animated busy cursor
[15:56:31] <DanielFalck> awallin, my idea would be to start with a good editor (master gui thing) that calls other scripts to create geometry/subroutines
[15:56:47] <DanielFalck> have the text editor be the heart of the program
[15:57:16] <DanielFalck> then have an opengl window called from it
[15:57:26] <awallin> ok... I'm not sure it should be a text editor, but scripting a la rhino/autocad is good
[15:58:06] <DanielFalck> awallin, I kind of like the way ray and the guys did it with the tcl/tk program called 'cp'
[15:58:18] <DanielFalck> conversational programming
[15:58:40] <DanielFalck> but take it a step further
[15:59:02] <DanielFalck> add a way of harnessing mark pictor's surfacing routine
[15:59:12] <DanielFalck> and add the Aptos stuff....
[15:59:26] <jtr_> ?msg nickserv identify SnPa51n2
[15:59:32] <DanielFalck> and the true type font stuff that Chris or Jeff did
[15:59:34] <jtr_> oops
[16:00:02] <DanielFalck> be right back...
[16:02:00] <awallin> I guess it depends on your typical machining job. for 2D or 2.5D conversational might be ok, but for 3D moulds I don't see it as very helpful
[16:02:14] <DanielFalck> back
[16:02:38] <DanielFalck> aptos and mark's stuff is 3d
[16:03:22] <DanielFalck> what I'm saying is, don't limit yourself to thinking you have to start a 3d project from scratch
[16:03:58] <DanielFalck> there are already plenty of those that you might be able to harness
[16:04:37] <DanielFalck> but most of them don't start with the machine tool in mind
[16:04:44] <DanielFalck> and I think that's a mistake
[16:05:03] <DanielFalck> the g-code is where the rubber hits the road
[16:05:27] <rayh> The machining process is why I asked about speeds and feeds. To me that is the core of a good CAM.
[16:05:36] <DanielFalck> yes
[16:05:58] <DanielFalck> a good feed/speed calculator would be simple to do and very useful
[16:06:01] <rayh> The geometry stuff is not trivial but it is certainly a lot more available that speeds and feeds.
[16:06:48] <DanielFalck> I have a simple bolt hole circle calculator that I did in python
[16:07:03] <DanielFalck> and I think I've seen a cradek/jeppler version too
[16:07:30] <DanielFalck> calling up something like that and a feed/speed calc would be useful
[16:07:31] <DanielFalck> to start
[16:08:14] <DanielFalck> varkon is another good geometry engine that could be harnessed for our purposes too
[16:08:32] <DanielFalck> it can do anything from simple 2d drawing to surfacing
[16:08:50] <DanielFalck> and it has a scripting langauge built in
[16:08:54] <rayh> Gotta run guys. IMO it would be possible to start an additional module in the cvs.linuxcnc.org. Ask the board for something official.
[16:09:06] <awallin> there's always the question if learning a new (possibly complicated) system is as slow as making your own...
[16:09:12] <DanielFalck> see you later ray!
[16:09:24] <DanielFalck> true
[16:10:10] <DanielFalck> but, if there was a master program like emc2 that could be built upon to accept other people's scripts...
[16:10:34] <DanielFalck> that could be written in C/C++, python, tcl/tk....
[16:11:30] <awallin> yes, it needs to be modular so new developers can learn how one part of the system works quickly, and contribute to that part
[16:11:47] <DanielFalck> definitely modular
[16:13:58] <DanielFalck> ls
[16:14:01] <DanielFalck> oops
[16:15:15] <fenn> trying to dig through some poorly conceived mess that you didnt write is much harder than writing your own poorly conceived mess :D
[16:15:48] <awallin> that's probably true
[16:17:00] <fenn> swig is easy enough.. basically you include the header file, run swig, compile, and link
[16:17:24] <awallin> you tried it?
[16:17:36] <fenn> it generates 20 pages of garbage that somehow connects the C code to the python shell
[16:18:00] <fenn> bits of which i can recognize from _gdepth.c
[16:18:13] <fenn> i guess python modules start with _
[16:18:52] <awallin> so it wasn't that hard to get running? I might try swig later
[16:18:57] <fenn> no it's super easy
[16:19:21] <awallin> did you try passing some data btw python and C?
[16:19:53] <fenn> gcc -fpic -c example.c example_wrap.c -I/usr/include/python2.4/ ; ld -shared example.o example_wrap.o -o _example.so
[16:20:11] <fenn> swig generates example_wrap.c from example.i
[16:20:21] <fenn> which basically just has the headers in it
[16:21:14] <awallin> ok
[16:26:16] <DanielFalck> awallin, can I try and dcc a small program to you? very small.
[16:26:38] <awallin> yes, but I'm not sure dcc works on my machine... try it
[16:26:44] <DanielFalck> ok
[16:27:36] <awallin> "waiting for transfer to begin"
[16:27:47] <awallin> it might be a firewall thing in my end?
[16:27:56] <DanielFalck> might be on my end.
[16:28:08] <awallin> can you pastebin it?
[16:28:11] <DanielFalck> how about a pastebin?
[16:28:18] <DanielFalck> where should I put it?
[16:28:38] <fenn> pastebin.ca
[16:28:42] <DanielFalck> ok thanks
[16:30:27] <DanielFalck> http://www.pastebin.ca/331152
[16:30:59] <DanielFalck> it just sends output to screen
[16:31:23] <DanielFalck> or clipboard
[16:32:09] <awallin> yep, it works
[16:33:50] <DanielFalck> I had it set up as a macro in 'nedit' and I could paste the output to my text
[16:34:09] <DanielFalck> did it just for fun
[16:35:15] <awallin> anyone experienced with opengl?
[16:36:29] <DanielFalck> Twingy, jepler, and cradek are
[16:36:55] <awallin> I don't know twingy
[16:37:07] <lerneaen_hydra> twingy?
[16:37:17] <fenn> * fenn vaguely remembers poking around with opengl ten years ago
[16:40:29] <DanielFalck> Twingy wrote a CAM program :
http://gcam.js.cx/index.php/Main_Page
[16:40:59] <DanielFalck> and he was a developer for BRLcad
[17:01:47] <Twingy> hi
[17:02:21] <awallin> hi Twingy, we were talking about opensource cam programs
[17:04:07] <Twingy> ah
[17:06:16] <awallin> can you tell us what gcam can do?
[17:09:41] <Twingy> make stuff using sketches and bolt holes
[17:09:49] <Twingy> you extrude stuff
[17:11:31] <awallin> are you the only developer working on it? or is there a cvs repo somewhere?
[17:19:02] <Twingy> I'm the only developer
[17:19:21] <awallin> this is not going very fast
[17:19:37] <Twingy> it's all relative :)
[17:21:22] <lerneaen_hydra> Twingy; so essentially 2.5d only?
[17:22:03] <Twingy> right, it's geared for 3-axis mill's and 4th axis stuff later on
[17:22:18] <lerneaen_hydra> oh, ok
[17:23:10] <Twingy> it's primarily geared toward people that have a small home made or inexpensive COTS mill that they want to use to design stuff using free software
[17:27:50] <fenn> hmm you dont even need the .i file in some cases
[18:00:07] <awallin> going now, but I'll be back later
[18:11:10] <anonimasu> damn
[18:11:12] <anonimasu> he left..
[18:11:18] <anonimasu> I saw the mindmap
[18:40:24] <Roguish_> Roguish_ is now known as Roguish
[18:43:03] <slundell> I frequently get null pointer errors and the like in mythbackend. I suspect it might be connected to the dvb card. It seems from the backtraces that its dvb_core that bugs out. is it fixable?
[18:43:14] <slundell> Sorry, wrong channel...
[18:43:20] <alex_joni> :)
[18:43:47] <slundell> could be worse :)
[18:44:31] <alex_joni> tmi :P
[19:00:49] <tomp> python renders a 3d wireframe from .obj format
http://www.3dartist.com/WP/python/tkinter3d.htm
[19:05:22] <anonimasu> hm
[19:05:29] <anonimasu> I've fried a stepper driver today
[19:05:31] <anonimasu> :)
[19:05:41] <anonimasu> shit happens.
[19:05:53] <jmkasunich> what kind of driver?
[19:05:57] <anonimasu> a gecko.
[19:06:00] <jmkasunich> bummer
[19:06:02] <anonimasu> stepper driver..
[19:06:03] <jmkasunich> how?
[19:06:14] <jmkasunich> * jmkasunich takes notes of what not to do
[19:06:19] <anonimasu> not remembering to set the current limit.
[19:06:38] <anonimasu> the stepper probably melted toghter and the output transistor blew..
[19:06:51] <anonimasu> along with the .50Ohm resistor.. and the trace on the board..
[19:07:41] <jmkasunich> so really, you fried a stepper motor, and the gecko was just an innocent casualty
[19:07:55] <anonimasu> hm, it was my own fault for not setting he current limit..
[19:08:04] <lerneaen_hydra> how is the current limiter set?
[19:08:12] <anonimasu> a auxilary resistor..
[19:08:14] <alex_joni> lerneaen_hydra: you wire a resistor
[19:08:27] <anonimasu> well, I have a g340 and another servo
[19:08:30] <anonimasu> with a broken encoder..
[19:08:50] <lerneaen_hydra> err, I was thinking more like jumpers, flashing a program etc
[19:09:03] <lerneaen_hydra> anonimasu; err, you forgot to connect the resistor?
[19:09:08] <anonimasu> lerneaen_hydra:
[19:09:10] <anonimasu> yeah..
[19:09:11] <lerneaen_hydra> ah
[19:09:16] <anonimasu> I were going to before I ran this test..
[19:09:17] <lerneaen_hydra> *not* nice
[19:09:23] <anonimasu> but I were going to try contouring a part..
[19:09:28] <anonimasu> with some more Z axis movement..
[19:09:45] <anonimasu> I found my psu issue
[19:09:59] <anonimasu> my rectifier is way too puny..
[19:10:42] <anonimasu> ^_^
[19:10:49] <anonimasu> lerneaen_hydra: well, I were pissed the first 30 minutes..
[19:11:20] <anonimasu> as I've avoided Z movement before I've never had that much current going through the stepper.
[19:11:25] <lerneaen_hydra> ah, ok
[19:11:27] <anonimasu> and my psu has been dipping..
[19:11:38] <anonimasu> so, now that I had excess power.. :)
[19:11:39] <anonimasu> boom
[19:11:50] <lerneaen_hydra> you must have been very lucky before
[19:12:07] <anonimasu> lerneaen_hydra: well, I thinkt the psu has saved me
[19:12:10] <lerneaen_hydra> to have exactly enough power not to burn the motor yet still enough to drive
[19:12:26] <anonimasu> yep
[19:12:37] <anonimasu> though it's a good reason to move to a servo for that axis..
[19:12:43] <lerneaen_hydra> haha
[19:12:43] <anonimasu> I just need to make/machine a gearbox..
[19:12:50] <anonimasu> beltbox..
[19:13:08] <anonimasu> or a bigger gear.. as the servo has higher rpm and lower torque..
[19:13:39] <anonimasu> images will be online later this week :)
[19:13:48] <anonimasu> of the victim.
[19:15:08] <Roguish_> Roguish_ is now known as Roguish
[19:15:25] <anonimasu> brb
[19:16:31] <anonimasu> though it sucks to be without machine for now
[19:41:57] <CIA-8> 03cradek 07v2_1_branch * 10emc2/configs/stepper-xyza/stepper_xyza.hal: don't display halscope by default
[19:42:06] <anonimasu> :)
[19:43:30] <CIA-8> 03cradek 07TRUNK * 10emc2/configs/stepper-xyza/stepper_xyza.hal: don't display halscope by default
[19:49:44] <anonimasu> hey awallin
[19:49:49] <anonimasu> your diagram looks nice
[19:50:16] <awallin> hi anonimasu
[19:50:28] <awallin> now only the implementation remains :)
[19:50:53] <awallin> I'm reading a bit on design patterns to get some sensible architecture for gui-opengl-model
[19:53:13] <awallin> I figured it's a good idea to get the basics down right the first time. That means it will probably take some time before I have any toolpaths to show....
[19:53:40] <awallin> but if the basic architecture is sound, it should be easy to extend into a full-featured cad/cam program
[19:54:46] <awallin> although Julian T wants to see cam algorithms integrated with emc. I don't quite see how this is going to happen... Julian: "No point in having yet another stand-alone CAM system that does all the usual"
[19:56:27] <DanielFalck> how about for shops with Fanuc controls that are converting their computers over to Linux?
[19:57:25] <awallin> integrating CAM functionality in the controller (emc) is a much larger topic. I would be happy if we could create an open source standalone cam program.
[19:58:25] <robin_sz> stand alone seems a much better plan to me
[19:59:00] <robin_sz> programming in the back office, run the program on the shop floor
[19:59:38] <DanielFalck> that's the right way to do it- to keep the machine running while programming
[19:59:43] <robin_sz> exactly
[19:59:53] <awallin> julian mentioned that toolpaths could be adjusted in real-time based on feedback from the machine, for example the step-over could be reduced if the cutting forces are too high
[19:59:57] <DanielFalck> programming at the machine wastes too much time
[20:00:05] <robin_sz> we are always about 3 days ahead of our laser in programing
[20:00:06] <awallin> but that's pretty advanced stuff
[20:00:26] <awallin> that's good to hear from you, I imagine you are 'industrial' cnc users?
[20:00:35] <DanielFalck> what does Julian T do? is he a CAM programmer with a commercial product?
[20:00:36] <robin_sz> yes
[20:00:39] <DanielFalck> yes
[20:00:46] <DanielFalck> at work and home too...
[20:01:21] <robin_sz> let me give yo an example from real life
[20:01:33] <robin_sz> a friend has a Haas Mini Mill
[20:01:47] <robin_sz> learnt to program it online on the machine console
[20:01:50] <awallin> DanielFalck: Julian is one of the guys behind the freesteel blog:
http://www.freesteel.co.uk/wpblog/ pretty interesting reading mostly - if you have time to go through it all
[20:01:53] <robin_sz> has no offline programming
[20:02:06] <robin_sz> this forked fine in year one
[20:02:14] <robin_sz> he wrote stuff and ran it ..
[20:02:17] <robin_sz> blah ..
[20:02:20] <robin_sz> now , hes got busier
[20:02:23] <robin_sz> a lot busier
[20:02:36] <robin_sz> he has stuff he wants to program and the machine is running
[20:02:51] <robin_sz> he has downtime when it shoudl be workingm because hes writing the next part ...
[20:03:20] <anonimasu> robin_sz: that's kind of odd, even ancient controls allow you to do it while running
[20:03:28] <robin_sz> he'd like to take time out to learn an offline package ... but hes too busy waiting for gaps in the machine time to program up the next part
[20:03:45] <awallin> yep, I understand this argument.
[20:03:56] <robin_sz> he tends to write a bit, air-cut it, write a bit more .. .
[20:04:08] <awallin> so at least in this channel people agree that an opensource cam package would be nice?
[20:04:13] <robin_sz> sure
[20:04:20] <DanielFalck> programming at the control is pretty inconvenient too. Lots of chances for 'fatfingering' and crashing.
[20:04:20] <anonimasu> well, I'm sure 90% of all users agree
[20:04:26] <DanielFalck> I do
[20:04:47] <robin_sz> laser is my main interest
[20:04:54] <robin_sz> and plasma to a lesser extent
[20:04:57] <DanielFalck> milling and turning is mine
[20:05:07] <anonimasu> also, the issue of programming at the control is that it's hard to do complex shapes easily..
[20:05:12] <awallin> robin_sz: mine too, but I do micromanipulation at the nanoscale with lasers...
[20:05:40] <robin_sz> awallin, Ithink mylasers might be a bit too big for you :)
[20:05:46] <awallin> I would be interested first in 3-axis milling. later turning
[20:06:22] <awallin> robin_sz: 4W CW at 1064nm is the most power I've worked with. We have a 10 W CO2 in the lab, and some new 30W diode thing at 808nm also but I haven't worked with those
[20:06:35] <robin_sz> awallin, 800W Yag and a 1700W CO2
[20:06:36] <CIA-8> 03jepler 07TRUNK * 10emc2/src/emc/motion/control.c: make only one pop-up appear when the "real-time delay" is encountered
[20:06:39] <DanielFalck> another thing to think about in the debate is file control. If things come from a server, there is more control over quality/rev level etc...
[20:07:06] <DanielFalck> if you have a bunch of guys programming at the control in a large shop- it's very bad
[20:07:13] <awallin> robin_sz: oh... nice. But I bet the beam-quality and pointing stability etc is not really research grade
[20:07:49] <robin_sz> the YAG is pretty good, but fibre delivered so spot size is not super small
[20:08:25] <robin_sz> but it does pierce 10mm steel plate in about 0.6 seconds :)
[20:09:48] <awallin> robin_sz: you should post some laser-cutting videos on youtube sometime! are your machines controlled by emc?
[20:09:52] <robin_sz> a little known fact is that molten steel is extremely transmissive to 1nm light ... it produces a waveguide effect, delivering energy deep into the work .. so pierce times are quicker than co2
[20:09:55] <robin_sz> heh, no
[20:10:03] <Guest659> Could anyone point in the right direction,i need to know how to compensate for different diameter tools in emc and dont know how?
[20:10:36] <awallin> Guest659: have you entered the tool diameters into the tool table?
[20:10:41] <cradek> you define your tools in the tool table, then use G41/G42
[20:10:44] <Guest659> yep
[20:10:56] <cradek> http://www.linuxcnc.org/handbook/RS274NGC_3/RS274NGC_38a.html#999268
[20:11:00] <Guest659> but i might seems stupid but what next
[20:11:11] <cradek> ^^ radius compensation mode instructions
[20:11:19] <Guest659> ok thanks
[20:11:24] <jepler> or see chapter 20 of
http://linuxcnc.org/docs/2.1/EMC2_User_Manual.pdf
[20:11:35] <jepler> page 160
[20:12:04] <cradek> heh
[20:12:13] <cradek> no time to chat I guess!
[20:17:57] <anonimasu> robin_sz: awake?
[20:20:37] <CIA-8> 03jepler 07v2_1_branch * 10emc2/src/emc/motion/control.c: merge rev 1.87: fix unexpected delay pop-up
[20:21:45] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/docs/src/config/emc2hal.lyx: fix docs to match code - jog wheels are now done in realtime, not halui
[20:21:54] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/docs/src/gui/halui.lyx: fix docs to match code - jog wheels are now done in realtime, not halui
[20:27:08] <CIA-8> 03jepler 07v2_1_branch * 10emc2/debian/ (emc2-dev.files emc2.files.in rules.in): to decrease the mani package size, get rid of the HAL manual (everything in it was repeated) and move the developer manual to the -dev package.
[20:27:14] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/docs/src/config/emc2hal.lyx: index-enable is IO, not OUT
[20:30:31] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/docs/src/config/emc2hal.lyx: fix docs to match code, jog wheels are now done in realtime, not halui
[20:30:31] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/docs/src/gui/halui.lyx: fix docs to match code, jog wheels are now done in realtime, not halui
[20:31:11] <CIA-8> 03jepler 07v2_1_branch * 10emc2/src/Makefile.modinc.in: -fPIC is necessary on some systems (x86-64) to compile external components
[20:33:31] <CIA-8> 03jepler 07TRUNK * 10emc2/src/Makefile.modinc.in: merge rev 1.6.4.2: -fPIC; also, provide LIBDIR which is needed to build non-rt components standalone
[21:03:11] <ds3> Hmmmm are the commits suggesting I can just hook up a quadrature encoder on the parallel port directly and EMC can decode it?
[21:03:52] <lerneaen_hydra> yes, you can do that in 2.1.x
[21:04:13] <lerneaen_hydra> you don't need to run head to do that
[21:05:16] <jmkasunich> you could do that in 2.0
[21:05:25] <ds3> ah
[21:05:31] <lerneaen_hydra> jogwheels in 2.0?
[21:05:37] <jmkasunich> there are speed limits of course, software can't count as fast as hardware
[21:05:45] <jmkasunich> no, not jogwheels
[21:05:59] <ds3> so there isn't much of a reason to build a PICboard to convert a quad encoder to a USB HID device for a jog wheel?
[21:06:06] <jmkasunich> you asked if you could hook up and encoder and emc could decode it, which 2.0 can do
[21:06:31] <cradek> ds3: that would make it much harder to use with EMC2
[21:06:30] <jmkasunich> using the decoded value for jogging is a newer addition
[21:06:33] <lerneaen_hydra> the docs said jogwheel though ;)
[21:06:36] <ds3> gotcha
[21:06:56] <ds3> cradek: how so? I'd have the PIC emulate a keyboard, like left and right arrow keys
[21:07:18] <cradek> I use a jogwheel hooked directly to the parallel port and it works perfectly
[21:07:30] <jmkasunich> jogging with the wheel direct into emc is going to be _much_ smoother and more responsive than faking keystrokes
[21:08:02] <ds3> the idea of building that was before I decided to go EMC and fake keystokes works in more controls
[21:08:10] <cradek> and the arrow keys can't move the machine .001 without changing to incremental mode
[21:08:41] <cradek> pretending you're a user pressing keys is just not going to work well.
[21:09:03] <ds3> is there a recommended number of steps per rev for use with a jog wheel?
[21:09:14] <cradek> whatever you want
[21:09:28] <lerneaen_hydra> I only have 16 and it works quite well
[21:09:33] <cradek> and it's not steps per rev, it's distance per click/rev
[21:09:34] <ds3> had planned to gut a mouse and use the scroll wheel
[21:09:47] <lerneaen_hydra> I have 0.05mm/step and can reach 400mm/min without problems
[21:09:51] <cradek> oh I see what you mean
[21:10:03] <cradek> a real jogwheel usually has 100 for obvious reasons
[21:10:23] <ds3> unless I am looking in the wrong place, digikey encoders are like $20 a peice and I can get a mouse for a lot less
[21:10:23] <lerneaen_hydra> IMO if you have 100steps/rev then you really need detents
[21:10:31] <cradek> yes you do
[21:10:48] <cradek> brb
[21:11:00] <ds3> right, I've used the wheels on a commericial control; just didn't know how well it'd work if I deviated
[21:11:00] <lerneaen_hydra> btw, wasn't someone making a servo-as-detented-jogwheel thing?
[21:11:18] <lerneaen_hydra> how many steps/rev does a mouse have? 50-100-ish?
[21:11:33] <ds3> think the datasheet said 16
[21:11:39] <jmkasunich> you mean on the scrool wheel of a mouse?
[21:11:40] <jmkasunich> or the ball?
[21:12:36] <lerneaen_hydra> that few?
[21:12:48] <anonimasu> fenn was talking about it
[21:12:48] <lerneaen_hydra> from the mice I've looked inside they've seemed to have lots more
[21:12:57] <anonimasu> lerneaen_hydra: you need torque feedback.. for that..
[21:13:15] <jmkasunich> my mouse scrollwheel is detented, 20 detents per rev
[21:13:26] <ds3> this is in the $1 mouse I disassembled
[21:13:57] <ds3> bought it cuz a MiniDin-5 (?) connector + cable costed more then $1
[21:14:33] <lerneaen_hydra> jmkasunich; oh, scrollwheel, right
[21:14:47] <lerneaen_hydra> I was thinking ball-mouse ball encoders
[21:15:09] <lerneaen_hydra> anonimasu; why not just a nice big encoder on the servo?
[21:15:18] <jmkasunich> those are gonna be higher, maybe 64 or 100 counts/rev
[21:15:23] <jmkasunich> but no detent
[21:15:25] <lerneaen_hydra> yeah, that's what I was thinking
[21:15:28] <lerneaen_hydra> right
[21:15:47] <ds3> there is a guy that used a stepper for an encoder
[21:15:53] <ds3> natural detents
[21:16:19] <anonimasu> hm
[21:16:20] <lerneaen_hydra> stepper for encoder?, hmm, you'd need an integrator to get a constant signal, right?
[21:16:22] <jepler> I fiddled with a "virtual detent servo" but it really felt kinda crappy
[21:16:28] <anonimasu> my melted stepper dosent have natural dents..
[21:16:34] <lerneaen_hydra> or can you send a current through and check the position?
[21:16:37] <anonimasu> jepler: hm, I have a servo that will do that..
[21:16:37] <ds3> http://www.webx.dk/oz2cpu/20m/encoder.htm
[21:16:43] <jepler> (PID forces the commanded position towards a "detent", but weakly)
[21:16:44] <lerneaen_hydra> jepler; what's crappy?
[21:16:51] <jepler> lerneaen_hydra: it just didn't feel very pleasant to use
[21:17:38] <lerneaen_hydra> hmm, that's too bad
[21:17:43] <lerneaen_hydra> was it 1:1 or geared
[21:19:50] <lerneaen_hydra> anonimasu; what's the swedish word for tacky?
[21:20:19] <lerneaen_hydra> the type of tacky thats corny and 2nd-hand-flea-market-esque
[21:21:45] <anonimasu> "myrorna?"
[21:22:12] <lerneaen_hydra> huh?
[21:22:24] <anonimasu> lerneaen_hydra: that's the place you are thinking off..
[21:22:28] <lerneaen_hydra> place?
[21:22:31] <anonimasu> just kidding
[21:22:44] <lerneaen_hydra> I'm thinking of an adjective :/
[21:23:05] <anonimasu> I have no idea..
[21:23:16] <anonimasu> that
[21:23:19] <anonimasu> that's not a word I use often..
[21:23:19] <lerneaen_hydra> hmm, ok
[21:23:28] <lerneaen_hydra> do you know what word I mean?
[21:23:29] <lerneaen_hydra> err
[21:23:31] <lerneaen_hydra> which word
[21:24:01] <anonimasu> no
[21:26:36] <anonimasu> * anonimasu is crying over the burnt stepper
[21:28:13] <lerneaen_hydra> was the stepper worth more than the gecko?
[21:30:39] <anonimasu> about the same
[21:30:54] <anonimasu> the gecko died too.
[21:32:25] <lerneaen_hydra> fixable?
[21:32:37] <anonimasu> defenitely not.
[21:32:41] <anonimasu> there's a hole in the pcb..
[21:32:44] <anonimasu> most spectacular..
[21:33:48] <anonimasu> one of the output transistors exploded.
[21:33:57] <anonimasu> and took the .50 ohm resistor with it..
[21:34:00] <anonimasu> through the board..
[21:34:09] <lerneaen_hydra> ah
[21:34:11] <lerneaen_hydra> t3h nasty
[21:34:44] <anonimasu> no big deal..
[21:34:58] <anonimasu> im not machineless for long..
[21:35:10] <anonimasu> going to order a new encoder for my spare servo..
[21:35:16] <anonimasu> and machine a beltbox..
[21:36:04] <anonimasu> still it feels shitty
[21:37:25] <anonimasu> :)
[21:37:35] <anonimasu> and I did some cool 3d contouring at the time also
[21:37:37] <jmkasunich> anonimasu: take a picture
[21:37:56] <anonimasu> jmkasunich: tomorrow
[21:38:00] <jmkasunich> I'll put it on my blog under magic smoke escape
[21:38:03] <anonimasu> jmkasunich: I cant get pictures out of anything tonight
[21:38:16] <anonimasu> jmkasunich: yeah, SET A CURRENT LIMIT RESISTOR ON YOUR GECKO!
[21:38:18] <anonimasu> ""
[21:38:19] <anonimasu> :D
[21:38:54] <jmkasunich> yep
[21:38:58] <lerneaen_hydra> hmm, does that mean that you're completely SOL if you get a short between the stepper output terminals?
[21:38:59] <jmkasunich> no rush
[21:39:20] <anonimasu> lerneaen_hydra: yes.. completely
[21:39:26] <anonimasu> _BOOM_
[21:39:39] <lerneaen_hydra> :/
[21:39:53] <jmkasunich> more like POP!
[21:40:07] <jmkasunich> TO-220 transistors aren't big enough to BOOM
[21:40:09] <anonimasu> hehe
[21:40:13] <anonimasu> jmkasunich: I
[21:40:28] <anonimasu> I'm just exaggerating.. :)
[21:40:33] <anonimasu> it felt like boom
[21:40:33] <anonimasu> :D
[21:40:34] <jmkasunich> heh
[21:40:46] <jmkasunich> we had a BOOM in the lab friday
[21:41:06] <jmkasunich> IGBTs in a 300HP drive went
[21:41:14] <lerneaen_hydra> jmkasunich; the cap you had that blew, that must have been a shit-your-pants boom if you were next to it, right?
[21:41:22] <jmkasunich> I bet
[21:41:29] <anonimasu> out teacher blew a cap at physics once..
[21:41:30] <anonimasu> a small one..
[21:41:34] <jmkasunich> I wasn't around for that one, I think it happened in the field
[21:41:43] <jmkasunich> the one on friday sure made me jump
[21:41:56] <jmkasunich> I was 10-15 feet way minding my own business
[21:41:58] <lerneaen_hydra> jmkasunich; oh, too bad ;)
[21:42:02] <anonimasu> atleast I found the psu trouble
[21:42:06] <lerneaen_hydra> oh
[21:42:08] <lerneaen_hydra> damn
[21:42:17] <anonimasu> and I increased my accel for X/Y to 600
[21:42:17] <lerneaen_hydra> IGBT's?
[21:42:37] <jepler> power transistors
[21:42:44] <lerneaen_hydra> oh
[21:42:45] <jepler> for big boys
[21:42:47] <anonimasu> :D
[21:42:53] <lerneaen_hydra> for real men
[21:42:56] <jepler> yes that too
[21:43:20] <lerneaen_hydra> hmm, real men use purely mechanical control, or better yet, only musclepower
[21:43:34] <lerneaen_hydra> possibly horses/donkeys
[21:43:42] <anonimasu> 300hp :D
[21:43:47] <anonimasu> that would be quite a feat..
[21:43:53] <anonimasu> expensive horsepower..
[21:44:03] <lerneaen_hydra> 300 horses all turning a rotating whatchamacallit
[21:44:12] <anonimasu> yep
[21:44:19] <anonimasu> imagine how much they must eat
[21:44:49] <anonimasu> how manu units/s is one G?
[21:45:39] <anonimasu> 9.81 m/s2
[21:45:44] <anonimasu> im slow as hell.
[21:46:21] <anonimasu> :/
[21:46:27] <lerneaen_hydra> oh, that type of G
[21:46:31] <lerneaen_hydra> depends on where you are though ;)
[21:46:42] <anonimasu> well, machine acceleration
[21:47:11] <anonimasu> I wonder how much I can crank up the accel for my servo axes..
[21:47:12] <lerneaen_hydra> IIRC it's 9.82 in sweden/europe/up north and 9.81 in the US
[21:48:20] <anonimasu> hm..
[21:48:47] <anonimasu> I wonder if my machine would throw the table away if I set my accel to 9820
[21:49:16] <lerneaen_hydra> well the servo drive must have a max_current
[21:49:31] <lerneaen_hydra> and as current controls torque controls accel
[21:49:46] <anonimasu> hm, yeah I know
[21:50:02] <anonimasu> I'm pondering if it'd work..
[21:50:13] <anonimasu> :D
[21:50:24] <lerneaen_hydra> I wonder what emc will do if it assigns an accel it can't acheive
[21:50:36] <anonimasu> hm, my geckos will fault..
[21:50:43] <anonimasu> that's what will happen..
[21:50:49] <lerneaen_hydra> ? wasn't this a servo you were driving?
[21:50:56] <anonimasu> yeah, with g340's..
[21:51:03] <lerneaen_hydra> ho
[21:51:04] <lerneaen_hydra> *oh
[21:51:23] <lerneaen_hydra> that's another matter
[21:51:35] <anonimasu> I think my issue is gearing/table weight
[21:52:22] <anonimasu> though I dont need 1G
[21:52:42] <anonimasu> I'll own a machine that will do HSM loops someday.
[21:53:19] <anonimasu> :D
[21:54:40] <lerneaen_hydra> what's hsm?
[21:54:43] <lerneaen_hydra> 4000mm/min+?
[21:54:45] <anonimasu> nah..
[21:54:54] <anonimasu> ever seen thoose little loops?
[21:55:06] <anonimasu> wait
[21:56:40] <anonimasu> I cant find a video..
[21:58:11] <lerneaen_hydra> oh
[21:58:10] <lerneaen_hydra> ok
[21:58:17] <anonimasu> http://video.google.com/videoplay?docid=-923619711177709820&q=5+axis
[21:58:16] <anonimasu> there
[21:58:23] <anonimasu> at the end when machining the T
[21:58:36] <anonimasu> 3:39
[21:58:46] <anonimasu> but that's a bad example..
[21:59:37] <anonimasu> emuge had a better video
[22:00:03] <lerneaen_hydra> so small machining in general?
[22:00:51] <anonimasu> no
[22:00:56] <anonimasu> very tiny movement..
[22:01:00] <anonimasu> with very high accel..
[22:01:02] <lerneaen_hydra> oh
[22:01:05] <lerneaen_hydra> I see
[22:01:14] <lerneaen_hydra> yeah it seemed to be somewhat trochoidal
[22:01:16] <anonimasu> yeah..
[22:01:19] <anonimasu> that's the name..
[22:01:29] <anonimasu> but there's hsm loops on direction changes also
[22:01:43] <lerneaen_hydra> ah, ok
[22:01:54] <lerneaen_hydra> shouldn't it be called ham and not hsm?
[22:02:08] <anonimasu> heh
[22:02:11] <anonimasu> http://www.emuge.com/news_events/imts06_videos.html
[22:02:13] <anonimasu> ham?
[22:02:19] <lerneaen_hydra> high accel machining
[22:02:34] <anonimasu> they use it for really hard stuff..
[22:04:05] <Rugludallur> LH: for your question earlier, Rugldallur == @home Dallur == @work
[22:04:18] <lerneaen_hydra> Rugludallur; aha, ok
[22:04:20] <lerneaen_hydra> nice
[22:04:52] <Rugludallur> LH: been working on the table on day, hoping to upload some pictures tonight :)
[22:05:01] <lerneaen_hydra> ooh
[22:05:02] <Rugludallur> err all day
[22:06:25] <Rugludallur> but I fried my laser diode last night so I am unable to fine-adjust the sides
[22:06:47] <Rugludallur> memo to self: don't mix up the negative/positive leads for diodes :P
[22:07:16] <lerneaen_hydra> ack
[22:12:17] <CIA-8> 03cradek 07v2_1_branch * 10emc2/debian/changelog: 2.1.0 release
[22:12:57] <CIA-8> 03cradek 07v2_1_branch * 10emc2/VERSION: 2.1.0 release
[22:15:13] <Rugludallur> uhh ohhh
[22:15:23] <lerneaen_hydra> ooh!
[22:15:26] <lerneaen_hydra> yay!
[22:17:39] <Rugludallur> http://rugludallur.com/fileadmin/user_upload/100_5427.jpg
[22:18:05] <Rugludallur> that one is from today, the whole things looks loads better after galvanizing
[22:18:11] <cradek> wow, that's quite a thing
[22:18:21] <alex_joni> all hail 2.1.0
[22:18:33] <alex_joni> cradek: remember to put pre-2.1.1 into Version
[22:18:43] <cradek> right
[22:18:54] <cradek> I've done this a few times :-)
[22:18:55] <alex_joni> this is a happy moment
[22:19:00] <cradek> yes
[22:19:02] <alex_joni> cradek: I know :)
[22:19:20] <Rugludallur> * Rugludallur raises a glass to everyone
[22:20:45] <awallin> Rugludallur: have any pics of parts that you have cut?
[22:21:39] <Rugludallur> awallin: not many, I did very little cutting before tearing everything to pieces to have it coated
[22:22:05] <awallin> ok so you just got it assembled after coating?
[22:22:21] <Rugludallur> awallin: still assembling, need another week or two
[22:22:44] <Rugludallur> awallin: assembling the whole thing takes 80 hours or so :P
[22:23:29] <awallin> ok
[22:24:02] <Rugludallur> awallin: im encoding some videos right now, I will post link when I have uploaded
[22:24:31] <awallin> great, I hope to do some videos too once our mill upgrade is done... that migth take a month or two
[22:25:14] <Rugludallur> awallin: if a photo says a thousand words then a video says a million :D
[22:37:23] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/common/ (core_sim.hal core_stepper.hal): don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:37:23] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/dallur-thc/ (dallur-classicladder.hal dallur-core_stepper.hal): don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:37:24] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/demo_mazak/demo_mazak.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:37:25] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/hexapod-sim/core_sim_6.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:37:27] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/lathe-pluto/lathe-pluto.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:37:30] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/demo_step_cl/classicladder.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:37:33] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/max/max.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:37:38] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/nist-lathe/nist-lathe.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:37:41] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/ppmc/ppmc_load.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:37:55] <jmkasunich> get out your wading boots, its flooding
[22:38:17] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/demo_sim_cl/classicladder.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:38:17] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/stepper-xyza/stepper_xyza.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:38:20] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/sim/ (servo_sim.hal tripodsim.hal): don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:38:21] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/univpwm/univpwm_load.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:38:26] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/configs/univstep/univstep_load.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:50:18] <jmkasunich> here it comes again!
[22:50:33] <jmkasunich> oops
[22:51:51] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/demo_sim_cl/classicladder.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:51:51] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/hexapod-sim/core_sim_6.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:51:54] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/lathe-pluto/lathe-pluto.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:51:55] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/nist-lathe/nist-lathe.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:51:54] <jmkasunich> run away, run away!
[22:51:58] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/dallur-thc/ (dallur-classicladder.hal dallur-core_stepper.hal): don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:52:01] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/ppmc/ppmc_load.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:52:04] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/sim/ (servo_sim.hal tripodsim.hal): don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:52:07] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/stepper-xyza/stepper_xyza.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:52:08] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/common/ (core_sim.hal core_stepper.hal): don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:52:19] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/max/max.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:52:19] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/demo_step_cl/classicladder.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:52:19] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/univstep/univstep_load.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:52:22] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/univpwm/univpwm_load.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:52:27] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/configs/demo_mazak/demo_mazak.hal: don't need to load scope_rt or halscope by default, they can now be loaded from the GUI menus
[22:53:10] <lerneaen_hydra> * lerneaen_hydra drowns
[23:01:42] <lerneaen_hydra> 'night all
[23:01:48] <anonimasu> night
[23:13:55] <CIA-8> 03cradek 07v2_1_branch * 10emc2/VERSION: bump after release
[23:15:41] <alex_joni> guess that makes it official :D
[23:16:10] <jmkasunich> woo-hoo!
[23:16:38] <cradek> uploading...
[23:16:47] <alex_joni> * alex_joni lends cradek some extra bandwidth
[23:17:07] <cradek> I could use it!
[23:17:05] <jmkasunich> dapper packages at the moment?
[23:17:19] <cradek> both systems
[23:17:30] <alex_joni> I notice the beta packages are gone
[23:17:44] <jmkasunich> will those who installed the alpha or beta pkgs get auto-upgrades to the real thing?
[23:17:51] <cradek> yes
[23:18:05] <jmkasunich> ok, then I'll leave the laptop running a bit longer
[23:18:23] <alex_joni> jmkasunich: 2.1.0~foo < 2.1.0
[23:18:40] <alex_joni> 2.1.0-foo > 2.1.0
[23:18:41] <alex_joni> :D
[23:19:05] <jmkasunich> you're so clever
[23:19:31] <alex_joni> not me :D
[23:28:44] <cradek> EMC 2.1.0 is released!
[23:29:29] <cradek> cradek has changed the topic to: Welcome! EMC (Enhanced Machine Controller) is a linux-based CNC control. | Latest release: EMC 2.1.0 |
http://www.linuxcnc.org |
http://wiki.linuxcnc.org
[23:29:44] <alex_joni> darn.. too slow :D
[23:29:52] <jepler> HOORAY!
[23:30:18] <alex_joni> * alex_joni thanks all that worked for this release
[23:30:51] <cradek> now I have to run :-)
[23:30:53] <cradek> bbl
