Back
[00:00:44] <mschuhmacher> I also found anotherthing
[00:01:11] <mschuhmacher> in the tk-mini
[00:01:36] <mschuhmacher> when you jog an axis
[00:02:10] <mschuhmacher> and you press 2 keys at the same time
[00:02:20] <mschuhmacher> 45 degree
[00:02:52] <rayh> The plan for both tkemc and mini were that we would agree not to do what you said.
[00:03:29] <mschuhmacher> when you release both keys only one axis stops
[00:03:33] <cradek> rayh: I think alex fixed that in tkemc a while back...
[00:03:40] <rayh> A careful review of the backwards 11 bit serial code from a keyboard makes machine control iffy at all much less getting the end of press commands connected to the correct press.
[00:04:13] <cradek> mschuhmacher: did you try the same thing in tkemc and/or AXIS?
[00:04:19] <mschuhmacher> #yes
[00:04:37] <rayh> I understand that was done. I still stand by the belief that no two keys on an ordinary keybard should be pressed at the same time. The expected behavior is not always the case.
[00:04:44] <mschuhmacher> in axis and tkemc it is OK
[00:05:10] <rayh> expected might be replaced with desired.
[00:05:24] <jepler> mschuhmacher: if you can fix it we will be happy to incorporate the fix
[00:11:07] <CIA-6> 03jepler 07TRUNK * 10emc2/src/hal/components/pid.c: mschuhmacher reports that these fields were not initialized, and I can't find any guarantee that the memory is otherwise zero'd out
[00:12:47] <K`zan> Anyone in the pacific time zone here? If so what time do you have?
[00:13:02] <toastydeath> time.gov
[00:13:10] <cradek> it's 17:12 pacific
[00:14:18] <K`zan> Damn, NOTHING updated right here. Thanks!
[00:14:23] <mschuhmacher> 01:14
[00:14:48] <CIA-6> 03cradek 07TRUNK * 10emc2/src/emc/sai/driver.cc: add support for lathe-format tool table in sai
[00:27:53] <mschuhmacher> its late I´m going home bye :-o
[00:27:59] <jepler> good night mschuhmacher
[00:28:27] <mschuhmacher> I already tried to fix this keyboard bug
[00:28:56] <mschuhmacher> maybe I can fix it
[00:29:15] <cradek> that would be nice
[00:48:05] <CIA-6> 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: fix getting back on the path after turning off comp in lathe mode
[00:48:42] <CIA-6> 03cradek 07TRUNK * 10emc2/tests/ccomp/lathe-comp/ (expected test.ngc test.sh test.tbl test.var): simple lathe tool shape comensation test
[00:49:46] <CIA-6> 03jepler 07TRUNK * 10emc2/src/hal/components/stepgen.c: make sure phase pins are created for step type 2 and above
[00:50:08] <CIA-6> 03cradek 07v2_1_branch * 10emc2/src/emc/rs274ngc/interp_convert.cc: fix getting back on the path after turning off comp in lathe mode
[00:50:54] <CIA-6> 03jepler 07v2_1_branch * 10emc2/src/hal/components/stepgen.c: merge rev 1.51: make sure phase pins are created for step type 2 and above
[01:10:01] <DavidMTL> Not sure if this would even be doable but does EMC support automaticaly slowing down servo motors when it detects the encoders are lagging commanded motion?
[01:10:53] <SWPadnos> no, it does the opposite
[01:11:09] <DavidMTL> I know the opposite is normal nehavior
[01:11:11] <SWPadnos> that's what PID does - it tells the servos to push a little harder when they start lagging
[01:11:40] <DavidMTL> but is it possible to set a point where it gives up and starts slowing feed rate
[01:11:50] <SWPadnos> you can do it that way if you want, but I'm willing to bet that the tuning is very difficult
[01:12:05] <SWPadnos> well, I've thought about the problem, and yes, it's possible
[01:12:25] <cradek> you could reduce feed as following error goes up, using the adaptive feed in HAL
[01:12:42] <SWPadnos> heh - that's a simple way ;)
[01:12:51] <cradek> but it seems like fixing the gcode or machine limits would be better :-)
[01:13:20] <cradek> you could also reduce feed if PID output saturates (for some measure of saturates)
[01:13:37] <cradek> because when that happens you know you're getting farther and farther behind
[01:13:40] <SWPadnos> the more complex way is to use an integrator in HAL that integrates requested acceleration and velocity
[01:14:10] <SWPadnos> you do this separately for each axis (and spindle load, if you have a sensor), and use that output to reduce feedrate, using the adaptive feed input
[01:14:22] <cradek> I guess the answer is: yes you have all the tools to do things like this if you want
[01:14:38] <SWPadnos> the controlling channel would be the axis (or spindle) with the highest detected load
[01:14:42] <DavidMTL> ok , thanks, I will read about those
[01:14:46] <SWPadnos> (using some min/max block to determine that)
[01:15:33] <SWPadnos> hmmm. that FERROR-based thing could actually cut down on the "stepgen too slow" problem ...
[01:16:20] <cradek> nah, it's just a misconfiguration that should be fixed, advanced hackery will just make it worse
[01:16:30] <SWPadnos> heh - true :)
[01:16:45] <SWPadnos> at least it would appear to work
[01:17:01] <cradek> crappily?
[01:17:10] <SWPadnos> slowly
[01:17:20] <cradek> twitchily?
[01:17:29] <cradek> * cradek makes up new words
[01:17:29] <SWPadnos> "why does it go only 10 ipm when I want 50 ipm?
[01:24:47] <DavidMTL> one last question I didn't find an answer by searching linuxcnc.org. Is there a way to input a spline move in EMC
[01:27:32] <cradek> not today, but quite likely you will be able to cut splines in 2.2
[01:28:01] <cradek> (some preliminary work on that front is done)
[01:28:05] <DavidMTL> what woul dbe the method to input them?
[01:28:18] <DavidMTL> in Gcode?
[01:28:20] <cradek> yes
[01:28:25] <DavidMTL> cool
[01:28:38] <cradek> that's one of the reasons it's not in there yet - it's not clear how best to enhance gcode to support splines
[01:28:47] <toastydeath> ..splines?
[01:29:05] <LawrenceG> cradek: I just updated to 2.1.2.... is the image to gcode filter only in trunk or should it work in 2.1.2?
[01:29:15] <toastydeath> oh, the curve spline
[01:29:56] <cradek> LawrenceG: it's in 2.1
[01:30:14] <cradek> LawrenceG: try running sim/axis and loading torus.png
[01:30:18] <LawrenceG> cradek: when I open the torus.png... it tries to open it as gcode
[01:30:36] <cradek> you have to set up the filter in your ini. see sim/axis.ini
[01:30:54] <LawrenceG> cradek: thanks looking...
[01:31:21] <cradek> [FILTER]
[01:31:22] <cradek> PROGRAM_EXTENSION = .png,.gif,.jpg Grayscale Depth Image
[01:31:26] <cradek> png = image-to-gcode
[01:31:26] <cradek> gif = image-to-gcode
[01:31:26] <cradek> jpg = image-to-gcode
[01:33:41] <toastydeath> if you guys have spline moves, you're most of the way to high speed machining
[01:34:06] <toastydeath> a+
[01:34:24] <SWPadnos> what do you think the cutoff for calling something "HSM" is?
[01:34:33] <SWPadnos> minimum speed, that is
[01:34:49] <toastydeath> 6000 sfm
[01:35:00] <toastydeath> is a pretty common number thrown around
[01:35:07] <toastydeath> there's no real set standard.
[01:35:09] <cradek> 1 ips seems fairly high speed on my lathe
[01:35:23] <cradek> * cradek <- small-time
[01:35:40] <toastydeath> the surface speed is what defines hsm, rather than specific spindle speed or feed rates
[01:35:55] <SWPadnos> that would be "FHSM" or "AHSM": "fairly high speed machining" or "apparently high speed machining" ;)
[01:36:00] <toastydeath> lol
[01:36:21] <cradek> AHSM acceptably high speed machining
[01:36:39] <toastydeath> hahahahah
[01:36:51] <SWPadnos> sire, but spindle speed is generally the main determinant of surface speed, and required feedrate is dependent on spindle
[01:36:57] <SWPadnos> *sure
[01:37:16] <toastydeath> you have to have a machine that has the spindle to move it at a good clip, yes
[01:37:30] <toastydeath> but you also have to have a good feed system to keep up with it
[01:37:49] <toastydeath> and, your machine must know how to accelerate and decelerate to move the part accurately
[01:38:19] <SWPadnos> the reason I ask is because in many cases, EMC can push feeds very high. the problem comes in when someone uses pathological moves, like a series of 0.001" moves at a programmed feedrate of 1000 IPM or something
[01:38:22] <toastydeath> machines that cut at high speeds without lookahead/nurbs "drift" corners
[01:38:52] <toastydeath> the controller aspect of HSM has to do with managing table accel/decel
[01:39:08] <toastydeath> and keeping the cutter on the toolpath without deviating
[01:39:11] <SWPadnos> I think the limitation right now is that EMC can only handle one segment per task cycle, but you can increase the cycle rate to several KHz on faster computers
[01:39:52] <toastydeath> crank it up to 450 IPM on the mill
[01:39:57] <SWPadnos> you can't go around a corner without deviating in either position or feedrate
[01:40:01] <SWPadnos> it's not physically possible
[01:40:07] <toastydeath> you can, they do it
[01:40:14] <cradek> sure, all you need is infinite acceleration
[01:40:22] <toastydeath> machines are handling 4-5 g's of force
[01:40:33] <toastydeath> on big blocks of steel
[01:40:36] <cradek> 5g is not infinite, but close
[01:40:48] <SWPadnos> ok, so there's some tight tolerance they're holding, but they're not staaying on the exact path
[01:40:59] <toastydeath> to be specific, you're not staying on the path ever
[01:41:01] <SWPadnos> heh
[01:41:04] <toastydeath> even in straight lines.
[01:41:20] <toastydeath> the idea is to make curves as accurate as your straight lines are.
[01:41:38] <cradek> wow, 5g is 2000 inch/sec^2
[01:41:49] <toastydeath> yep
[01:41:54] <toastydeath> big damn motors
[01:41:59] <toastydeath> big screws, too
[01:42:06] <cradek> I suppose so
[01:42:28] <SWPadnos> well, of course you need the right motors and drives
[01:42:34] <toastydeath> most HSM machines are limited at about 2g
[01:42:36] <toastydeath> at whatever the table load is
[01:42:44] <SWPadnos> I suspect that EMC can keep up, with the caveat about blocks/cycle
[01:42:55] <toastydeath> it's easy to test
[01:43:10] <toastydeath> straight line at 450, do a semicircle, continue with line
[01:43:22] <toastydeath> measure the groove's deviation
[01:43:30] <toastydeath> you'd have to do two passes to get an "accurate" wall
[01:43:30] <cradek> do you know what servo update rate is typical?
[01:43:32] <toastydeath> no clue
[01:43:53] <cradek> on PC hardware, a few kHz is all you're going to get
[01:44:05] <toastydeath> most commercial controllers have 3-4 processors
[01:44:31] <SWPadnos> I know Les had his machine (with an ISA card) up to 2 KHz, and was very interested in (Anders?) getting his up to 8 KHz
[01:44:31] <cradek> if that's the important number, EMC is limited by running on commodity hardware
[01:44:45] <cradek> SWPadnos: oh, that's more than I expected, interesting
[01:44:54] <SWPadnos> that was the servo rate, I'm not sure if they had task running at that rate
[01:44:59] <cradek> Les has a K6-??? with ISA STG
[01:45:16] <cradek> iirc
[01:45:18] <SWPadnos> and that was 1-2 years ago - since that's mostly dependent on CPU speed (I think), it could probably be a lot faster
[01:45:22] <SWPadnos> yep, something like that
[01:45:28] <cradek> haven't seen him for a while, he's probably making parts
[01:45:35] <SWPadnos> heh - bastid!
[01:46:29] <toastydeath> i'm pretty sure update speed is not the issue
[01:46:44] <toastydeath> but rather lookahead and mathmatical management of the curve you're machining
[01:46:46] <cradek> it must be, for path following
[01:46:53] <toastydeath> nein
[01:46:58] <cradek> ok, it's only one factor, but an important one
[01:47:00] <LawrenceG> cradek: Thankyou works a treat now.... I now have a donut mold to machine!
[01:47:27] <cradek> LawrenceG: yay
[01:47:39] <LawrenceG> ummmm dooonuts
[01:48:10] <cradek> toastydeath: I guess at 450inch/min, 1kHz is every .008 inch
[01:48:35] <cradek> an update every .001 or faster would be nice, but maybe not entirely needed
[01:48:49] <toastydeath> you'd want it more than that
[01:48:56] <toastydeath> but again, drift is not an update issue
[01:49:10] <toastydeath> but fundimentally a mathematical one
[01:49:28] <toastydeath> but i don't know any of the things involved in how to caluculate a curve for HSM
[01:49:30] <cradek> I'm sure it is - if you aren't calculating error and updating the servo power, how do you stay on the path?
[01:49:56] <toastydeath> PURE LUCK
[01:49:58] <cradek> especially for a non-straight path that has centripetal accel
[01:50:03] <cradek> haha
[01:50:11] <toastydeath> or the classic shop response "trig it out"
[01:50:32] <toastydeath> 450 ipm is pretty awesome to watch in stainless steel
[01:51:40] <toastydeath> i really should read up on it more
[01:51:49] <toastydeath> to see if i can find any of the controller details
[01:51:55] <SWPadnos> http://www.datrondynamics.com/velociraptor.htm
[01:52:01] <cradek> secrets closely guarded, I'm sure
[01:52:13] <petev> that control is NT based
[01:52:21] <SWPadnos> yes, I know :(
[01:52:23] <petev> the gantry is real light weight
[01:52:47] <toastydeath> i would not want to do any serious machining on that, though
[01:53:13] <toastydeath> but that would probably rock for very small parts
[01:53:15] <petev> spindle speed control is an option and no rigid tapping
[01:53:25] <petev> it's really for face/name plate industry
[01:53:56] <SWPadnos> sure - their videos show 2.5d-ish stuff mostly
[01:54:19] <SWPadnos> though the sample part on their homepage is a little more 3D-ish
[01:54:34] <toastydeath> the sample homepage part is totally 2.75d
[01:54:44] <SWPadnos> oops - the one on the linked page
[01:54:53] <SWPadnos> yeah, it's not like a mouse contour or anything
[01:54:59] <toastydeath> i was totally just making stuff up
[01:55:03] <toastydeath> it's okay.
[01:57:13] <SWPadnos> petev, I should have an EMC computer with Mesa card in it later today
[01:57:19] <petev> nice
[01:57:31] <petev> cradek, are you going to do any work towards HSM?
[01:57:37] <SWPadnos> hmmm. I could live dangerously and stick two cards in ...
[01:57:40] <petev> I have some ideas for the algorithms
[01:57:58] <cradek> petev: please be my guest
[01:58:15] <toastydeath> is.. is anyone interested in working on basic lathe functions =((
[01:58:23] <petev> I think it's similar to driving and not out running your headlights
[01:58:30] <petev> one algo would be as follows
[01:58:41] <SWPadnos> petev, devel channel?
[01:58:49] <petev> ok
[01:58:56] <toastydeath> oh noes you guys are leaving me =(
[01:59:07] <SWPadnos> heh
[01:59:31] <cradek> toastydeath: we have 'basic' lathe functions... the next thing I want to do is mill rigid tapping
[01:59:34] <SWPadnos> algorithm discussion is more of a devel thing. feel free to join #emc-devel if you like
[01:59:54] <cradek> and in june (cnc workshop) I'll have a machine to test that on
[02:00:40] <toastydeath> i was informed that EMC doesn't know how to handle lathe toolchange
[02:01:00] <toastydeath> by one of the folks in here
[02:01:25] <cradek> I believe he was wrong then
[02:01:34] <cradek> unless he means something non-obvious
[02:02:03] <toastydeath> T0101
[02:02:07] <cradek> emc2 supports 9 tool orientations with X/Z offsets
[02:02:37] <cradek> in emc you would say T01
[02:03:00] <toastydeath> but why
[02:03:17] <toastydeath> isn't that a pretty huge deviation from the industry
[02:03:31] <toastydeath> not that you're trying to BE "the industry" mind you
[02:04:16] <cradek> toastydeath: I don't know commercial controllers and since they're all different, there's little point in trying to be compatible with them - my goal is to allow people to use EMC and a lathe to make parts
[02:04:42] <toastydeath> the reason i bring it up is that "T####" is identical across commerical lathe controllers
[02:05:07] <toastydeath> not that i have any real c/c++ ability to contribute
[02:05:20] <cradek> that limits your tools to 99 right?
[02:05:31] <toastydeath> it does
[02:05:42] <toastydeath> which would be an amazingly large tool turret
[02:05:47] <cradek> sure :-)
[02:05:57] <cradek> when are the two numbers different?
[02:06:07] <toastydeath> using a different offset for the same tool
[02:06:08] <cradek> I'm trying to understand the functionality
[02:06:26] <toastydeath> G40-G42 on the lathe doesn't take any parameters
[02:07:02] <cradek> those default to the loaded tool in emc too
[02:07:11] <bytecolor> you can use different offsets on lathe tools to, for instance control the width of a groove, or for taper, or for two tools mounted in the same station, but eh...
[02:07:27] <toastydeath> roughing/finishing on the mill
[02:07:57] <cradek> ok, in emc as-is, you could do that with two tool table entries (orientation and angles would be the same)
[02:07:58] <toastydeath> it's not exactly "useful" but it was part of the very first set of g-codes
[02:08:18] <toastydeath> and so everybody who puts out a commercial controller covers that first standard
[02:08:37] <toastydeath> well, as per the CNC g-codes, it wasn't part of NC (clearly)
[02:09:16] <bytecolor> okuma actully supports T###### on a lathe
[02:09:36] <toastydeath> yeah, some folks go insane
[02:09:46] <toastydeath> and support six and eight digit T words
[02:09:55] <toastydeath> er
[02:09:57] <toastydeath> yes.
[02:09:58] <toastydeath> that was correct.
[02:11:11] <bytecolor> I personally think H and R words are redundant on mills... for length and radius comp
[02:11:35] <bytecolor> they are useful _sometimes_ but, eh
[02:11:37] <toastydeath> if i had any skill at programming, i would probably try to write an abstraction between g/m codes and the counterpart
[02:11:43] <cradek> bytecolor: H and D? (I do too)
[02:12:00] <toastydeath> in the controller itself
[02:12:01] <bytecolor> er D, yes cradek <smacks self> :)
[02:12:36] <cradek> in emc, D is optional but H is required, which always strikes me as odd
[02:12:48] <cradek> or the other way around - I forget
[02:13:06] <bytecolor> cradek, nod on a mazak you can set those up to be implied in the code
[02:13:23] <toastydeath> i think this is a good reason to have a g-code preprocessor
[02:13:37] <bytecolor> so you only call T1 (dont need an M6 either if no carousel)
[02:13:39] <toastydeath> so that you can add functions to the controller and map them to different G-codes using different words
[02:14:20] <toastydeath> so that you could emulate, say, Haas, where D and H are mandatory, or you could emulate Mazak, where they're implied
[02:15:39] <toastydeath> load a config at startup, and go
[02:16:07] <toastydeath> that way, you can use programs from other machines without modification
[02:17:26] <toastydeath> and in that same vein, it would be neat to see a controller with pluggable machine functions
[02:17:58] <bytecolor> the source is available, start coding! :)
[02:18:03] <toastydeath> yeah, i wish
[02:18:34] <toastydeath> the most complicated thing i've ever written in c/c++ was a program that printed out a calendar
[02:18:56] <bytecolor> cal on unix
[02:18:57] <toastydeath> and it didn't work too well
[02:19:03] <toastydeath> nah, it literally printed it
[02:19:20] <toastydeath> on like, the printer
[02:19:51] <bytecolor> ah
[02:19:59] <toastydeath> it was for a computer science class.
[02:20:03] <toastydeath> CUTTING EDGE, EH
[02:22:55] <jepler> hi jmkasunich!
[02:24:17] <jmkasunich> hi
[02:24:31] <jmkasunich> no, hal_malloc doesn't zero memory
[02:24:46] <jmkasunich> plain C malloc doesn't zero memory does it?
[02:24:56] <cradek> no
[02:24:57] <jepler> no, there's a different call (alloca) that does return zero'd memory
[02:25:03] <jepler> er, calloc
[02:25:07] <jepler> alloca is something else entirely
[02:25:07] <jmkasunich> ok - thats what I thought
[02:25:23] <jmkasunich> I forgot the init code when I added FF2
[02:25:26] <jepler> so the change I made to pid should be backported
[02:25:29] <jmkasunich> good catch
[02:25:40] <jmkasunich> yeah
[02:26:08] <jepler> I'll do that now
[02:26:57] <CIA-6> 03jepler 07v2_1_branch * 10emc2/src/hal/components/pid.c: merge rev 1.30: zero out new fields in the pid structure
[02:49:34] <SWPadnos> a-l-p-h-a, yes, I think that's basically what he said
[02:59:50] <CIA-6> 03jepler 07TRUNK * 10emc2/docs/src/hal/comp.lyx: document experimental 'personality' feature
[03:06:11] <a-l-p-h-a> SWPadnos, I always seem to typing int he wrong window
[06:03:36] <ds3> hey.... I suggested the change last month.... (jepler's CONFIG_PROC_FS checkin earlier today)
[06:21:22] <K`zan> Night all.
[07:03:55] <Jymmm> Jymmm is now known as Red70sShow
[07:03:55] <Red70sShow> Red70sShow is now known as Jymmm
[12:19:02] <skunkworks> cradek:
http://www.electronicsam.com/images/KandT/dedi1.JPG
[12:19:10] <skunkworks> http://www.electronicsam.com/images/KandT/dedi.JPG
[12:32:10] <jepler> ds3: sorry I missed/ignored your suggestion.
[13:11:48] <cradek> skunkworks: those letters did turn out nice
[13:13:04] <cradek> (I'm not sure the font is reverential, but that's just a personal preference)
[13:13:31] <skunkworks> Yah - I didn't pick it ;)
[13:18:36] <cradek> skunkworks:
http://www.theonion.com/content/index/4308
[13:19:03] <cradek> err
http://www.theonion.com/content/from_print/wrong_font_chosen_for
[13:20:30] <skunkworks> ok - that made more sense ;)
[13:21:04] <skunkworks> it was lithograph font that was used
[13:22:54] <cradek> is this right off the machine, or did you do some finish work?
[13:23:04] <cradek> the quadrants of the Os are nice and round
[13:23:46] <skunkworks> I had de-burred it - but other than that.
[13:24:09] <skunkworks> the thing has spring loaded nuts - it does pretty good
[13:26:35] <skunkworks> cradek: you where talking about 'nice' yesterday in regards to the que. Is there a wiki somewhere?
[13:27:26] <cradek> nope, it'll be in the next release - do you want to try it early? it's just a one line change you could make
[13:28:07] <skunkworks> No - I was wondering more of what it involved. Just a bit intrigued
[13:28:22] <skunkworks> not that I would understand it ;)
[13:28:50] <skunkworks> * skunkworks will be moving for the next 6 months it seems like
[13:29:18] <cradek> nice is a way in unix to give more priority to some program than another (like telling one to be NICE to the rest)
[13:29:58] <cradek> I told AXIS to be `nice' to milltask, which is the thing that runs the interpreter and feeds moves to realtime
[13:30:07] <skunkworks> ah - ok - I thought it was some sort of algerithem to get the info thru.
[13:30:21] <skunkworks> algerithem? ;)
[13:30:37] <cradek> I do know what you mean...
[13:31:02] <cradek> on my slow machine, AXIS was being a hog and not letting milltask do its work - and that fixed it right up
[13:31:23] <cradek> maybe it'll fix your stuttering too
[13:31:27] <skunkworks> which I assume what was happing on my 600. but when I get a chance I will try it.
[13:31:45] <cradek> yep I think it'll fix yours
[13:31:47] <skunkworks> Cii;
[13:31:50] <skunkworks> cool
[13:32:34] <cradek> after I did that, the interpreter could feed about 1000 lines of gcode a second to motion on my PII-400
[13:32:55] <skunkworks> nice.
[13:33:07] <cradek> before that, it was sometimes more like 50
[13:33:28] <skunkworks> it could be - It would run smooth for a bit than it would chunk
[13:33:43] <cradek> that's what I had too
[13:34:08] <skunkworks> damn - again.. Nice work.
[13:59:27] <anonimasu> I just made 40 parts..
[14:01:31] <anonimasu> thanks emc ^_^
[14:01:58] <jepler> whee
[14:04:20] <anonimasu> actually I've made more parts then 43+0
[14:04:21] <anonimasu> 40
[14:04:24] <anonimasu> maybe 05
[14:04:26] <anonimasu> 50..
[14:04:33] <anonimasu> but different ones
[14:10:22] <CIA-6> 03jepler 07TRUNK * 10emc2/src/hal/drivers/pluto_servo.comp: fix pin numbering in documentation
[14:45:12] <CIA-6> 03jepler 07TRUNK * 10emc2/src/po/fr_axis.po: new translation from Christian Hanganu and R. Labahn
[14:45:43] <CIA-6> 03jepler 07TRUNK * 10emc2/debian/emc2.files.in: new french translation
[14:49:27] <CIA-6> 03jepler 07v2_1_branch * 10emc2/debian/ (changelog emc2.files.in): merge from TRUNK: french translation of AXIS
[14:49:28] <CIA-6> 03jepler 07v2_1_branch * 10emc2/src/po/fr_axis.po: merge from TRUNK: french translation of AXIS
[15:01:02] <cradek> yay
[15:50:56] <SWPadnos> oh now this is great
[15:51:02] <jepler> SWPadnos: ??
[15:51:10] <SWPadnos> Windows Explorer has decided to freeze (again)
[15:51:14] <jepler> oh
[15:51:18] <jepler> maybe you should upgrade to fista
[15:51:32] <SWPadnos> I wanted to run a program so I figured I'd use task manager to do it
[15:51:43] <SWPadnos> clicked run, then browse ...
[15:51:52] <SWPadnos> which uses explorer to look for the file to run ...
[15:51:57] <SWPadnos> sigh
[15:52:35] <SWPadnos> at least I was able to run another copy of task manager to kill off the first one
[15:52:58] <SWPadnos> I should upgrade to "kill everyone that makes good software for Windows only"
[16:20:01] <CIA-6> 03cradek 07TRUNK * 10emc2/src/emc/sai/saicanon.cc: remove debug output
[16:20:23] <SWPadnos> I must admit, shuffle mode in WinAmp can yield some odd song combinations
[16:22:24] <SWPadnos> the transition from "Diary" by Bread to "Drumbone" by Blue Man Group is particularly harsh
[16:23:00] <cradek> I like dairy on bread
[16:23:08] <SWPadnos> me too. maybe I should have some :)
[16:24:35] <SWPadnos> heh - and on to "I'm A Mother" by the Pretenders
[16:30:43] <skunkworks> my music listening days seem to have ended. I mostly listen to wisconsin public radio.
[16:37:23] <skunkworks> and sometimes minnesota public radio
[16:45:03] <SWPadnos> I pretty much listen to public radio as well
[16:45:10] <SWPadnos> except that I don't have a tuner in my office
[16:47:48] <a-l-p-h-a> SWPadnos, working on anything super cool lately?
[16:47:54] <SWPadnos> nope
[16:48:02] <SWPadnos> working on nothing lately :(
[16:48:19] <a-l-p-h-a> SWPadnos, check out www.last.fm and google for somafm.
[16:48:26] <a-l-p-h-a> very mellow music, which I think you may like.
[16:48:30] <a-l-p-h-a> if you say you're not a hippie.
[16:49:04] <SWPadnos> I'm pretty sure I'm too young to be a hippie
[16:49:30] <a-l-p-h-a> http://somafm.com/
[16:49:56] <SWPadnos> cool. I'll check it out
[16:51:31] <a-l-p-h-a> gonna pick up some screws. fun shit. :)
[16:51:33] <a-l-p-h-a> ciao
[16:51:49] <SWPadnos> heh - have fun :)
[17:04:15] <tomp> learn python with puzzles
http://pythonchallenge.com/
[17:09:45] <plattschnauze> could anybody tell me where to write the loadusr -W hal_input .... hal,ini ???
[17:11:21] <skunkworks> hal file
[17:11:58] <plattschnauze> (to get my joypad buttons for halui inputs)
[17:12:14] <plattschnauze> sektion ?
[17:13:04] <plattschnauze> and many thanks , I will try
[17:14:12] <skunkworks> jepler:
http://www.cnczone.com/forums/showthread.php?p=271930#post271930
[17:14:15] <skunkworks> :)
[17:14:25] <tomp> plattschnauze:
http://pastebin.ca/396270 example loadusr
[17:15:56] <plattschnauze> alex told me yesterday how to , but i have some holes in my head sometimes
[17:16:13] <skunkworks> join the club ;)
[17:16:40] <tomp> plattschnauze: the gui (xml) to accompany previous
http://pastebin.ca/396274
[17:22:11] <plattschnauze> answer at starting cant find programm hal_input ????
[17:23:43] <tomp> plattschnauze: i just ran it to make sure it was viable. works ok . copy both files to ~/emc2-head & execute 'scripts/halrun pp1b1led9robust.hal' (your name may vary )
[17:23:59] <skunkworks> plattschnauze: what version of emc are you running?
[17:24:57] <plattschnauze> i have to look but i think 2-1-1
[17:27:27] <skunkworks> I don't 'think' hal_input is part of 2.1.1.
[17:27:52] <skunkworks> iirc it is a pretty new hal componant
[17:29:07] <tomp> plattschnauze: these files do not mention 'hal_input'. i was running 2.2 pre cvs head, i dont know the influences/dependencies of different versions, but this code ran on last few updates.
[17:30:16] <tomp> plattschnauze: rather than concern with the code running. look at the use of 'loadusr' and apply it to your scripts
[17:31:35] <plattschnauze> my version is also 2.2 pre
[17:34:46] <tomp> plattschnauze: did the reference to 'hal_input' come from your scripts? i think so, jepler's page says it's for input events... i have no knowledge of it.
http://axis.unpy.net/
[17:35:28] <tomp> plattscnauze: tho i want to work with xemet's usb joystick soon
[17:36:43] <cncjunior> hello
[17:36:57] <skunkworks> Hello
[17:37:17] <tomp> plattschnauze: got .../src/hal/user_comps/hal_input.py ? got .../docs/man/man1/hal_input.1 ? maybe you just dont have the files
[17:37:49] <plattschnauze> i have a saitek P880 , im not shure how to find out the names of the switches etc.
[17:39:11] <cncjunior> i override feed rate from an outside signal through parport but the step is 10 % and i want 1 % . how to scale to this ?
[17:44:09] <tomp> plattschnauze: i have no experience, but it looks like you can see the pins with 'hal_cmd show pin input'. if you dont have the man pages... see
http://linuxcnc.org/docs/devel/html/man/man1/hal_input.1.html
[17:48:11] <cncjunior> it works fine on emc 2.1.1 but only on steps of 10% from axis speed.
[17:48:22] <tomp> cncjunior: i dont see a standard configuration that has feedrate override connected to parallel port. is this something you wrote?
[17:49:21] <cncjunior> i asked here and alex_joni answerd to me.
[17:49:28] <tomp> ok
[17:50:00] <a-l-p-h-a> you all missed me right? :)
[17:50:15] <tomp> cncjunior: he's gone right now
[17:50:23] <cncjunior> i want to modify feed rate more gentle
[17:50:46] <plattschnauze> where can i get the files ??
[17:51:33] <pier_port> pier_port is now known as pierp
[17:51:42] <tomp> plattschnauze: mine came with 2007 03 13 cvs update.
[17:52:08] <cncjunior> thank you tomp
[17:52:19] <plattschnauze> do i have to run sudo apt get etc... ??
[17:53:05] <plattschnauze> i think i dont get updates automaticly
[17:54:50] <tomp> plattschnauze: i always rename my current 'run-in-place' directory, then follow the instructions for a brand new install from cvs byt using these notes:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC starting at 3.2 near " or to get the development cvs head version,"
[17:57:13] <tomp> plattschnauze: after i'm happy with the new installation, and after i have copied over my custom files, i can delete the old directory
[17:59:13] <tomp> plattschnauze: did you >ever< checkout from cvs? if not, then start at the beginning of 3.1
[18:00:36] <plattschnauze> im quit a stupid in linux , learning every day, while try to get my robot run as i like
[18:01:23] <plattschnauze> with many help of alex , and finding out new problems every day
[18:01:40] <tomp> plattschnauze: if you are at all close to getting a robot to run with emc, you are more like a master ;)
[18:02:32] <plattschnauze> it runs already with some problems in speed and following errors
[18:03:11] <tomp> nice: how many axis? what style? (puma/scara/pick-n-place)?
[18:03:38] <plattschnauze> errors on original pumakins are already terminated
[18:04:30] <plattschnauze> 6 axis 6R industrial robot style
[18:05:04] <tomp> length of reach? (like ABB / Motoman, yes )
[18:07:00] <xemet> hi
[18:07:12] <tomp> xemet: hello
[18:07:23] <plattschnauze> around 100 cm (all selfbuild )
[18:07:36] <skunkworks> plattschnauze: pictures?
[18:08:27] <plattschnauze> on cnc-ecke.de ---emc
[18:09:30] <plattschnauze> (peters)
[18:09:53] <xemet> I've the updated files for axis italian translation it_axis.po it.po it.msg it_rs274_err.po
[18:10:43] <xemet> (it_po should be not for axis but for tkemc)
[18:10:49] <tomp> ah, heidenhain 426 taste-cnc
[18:11:08] <xemet> where should I send them?
[18:11:17] <xemet> jepler: are you there?
[18:11:41] <plattschnauze> my greatest wish / problem at this time is how to teach / save found positions in a file for future use
[18:12:21] <plattschnauze> its ugly to write them on a paper !!
[18:12:46] <SWPadnos> plattschnauze, you should be able to write a simple HAL component in Python that has a bit input ("capture") and several float inputs (the joint positions), which writes to a file when the capture bit is triggered
[18:13:50] <tomp> plattschnauze: at any time you can ask hal to tell you the encoder value of the 6 joints. i dont know how to write them to a file, but moving to an encoder value on a 6D robot is not simple sometimes.
[18:14:04] <jepler> xemet: you can e-mail them to me
[18:14:55] <tomp> sometimes you should move one joint before another... but i suppose you can eliminate that by simplifying the motions that are recorded
[18:15:19] <xemet> jepler: theese are form my teacher, I still haven't tried them. He says that he compiled them and everything worked except for the it_rs274_err.po
[18:15:20] <plattschnauze> im not a programmer, i just try everything , my motors are steppers
[18:15:26] <SWPadnos> heh
[18:15:35] <SWPadnos> step 1: learn to program
[18:15:40] <SWPadnos> step 2: ???
[18:15:45] <SWPadnos> step 3: Profit!
[18:15:45] <xemet> jepler: have you any idea why it doesn't work?
[18:16:44] <xemet> jepler: it_rs274_err.po compiled (file .mo created), but error messages are still in english
[18:17:08] <jepler> xemet: this has been filed as a bug, I don't know if anyone has tried to fix it:
http://sourceforge.net/tracker/index.php?func=detail&aid=1650938&group_id=6744&atid=106744
[18:17:43] <xemet> jepler: oh, ok. Now I email files to you so that they could be included in the next release
[18:17:54] <plattschnauze> i just can program sps, and some VB or basic , python i have loaded but not tryed
[18:18:26] <tomp> plattschnauze: did you write CNC-Hilfe ? what programming language? the guys at #cam are looking for gui front end for thier apt-360
http://fenn.dyndns.org/apt360
[18:21:20] <plattschnauze> first i dont write anything you could know, second my english is bad , third my origin ist programming SPS or DDC for Heat/buildingcontrol
[18:21:43] <xemet> jepler: I've sent the files to you.
[18:25:33] <jepler> xemet: OK, I'll probably commit them sometime in the next day or so -- if I don't, please remind me
[18:26:31] <xemet> jepler ok, thank you
[18:28:57] <plattschnauze> maybe someone could help me , to get a teaching file, saving the position for the 6 axis every time a button is switched ?
[18:31:25] <plattschnauze> i have just tryed now for about 2 month with alex , to get the pumakins run, and finaly my robot should do some work. if i have to learn phyton first, etc. i will run out off time totaly
[18:35:58] <plattschnauze> tomorrow i will try to get the hal-input or a new version, il be back then , Thanks for help , by
[18:38:04] <tomp> plattschnauze: damn, hes gone.... you may be able to use the 'probing'
http://www.linuxcnc.org/docs/html/gcode/main/. your button could act like the probe and capture the positions in #5061-#5066... still looking at how to communicate that info to a file and how to wire your trigger
[18:38:49] <SWPadnos> tomp, it seems that would be easy with encoders, but he mentioned steppers, so I'm not sure how he's getting position at all
[18:38:52] <tomp> oh the file i/o is done A comment of the form (PROBEOPEN filename.txt) will open filename.txt and store the coordinate of each successful straight probe in it. The file must be closed with (PROBECLOSE)
[18:39:14] <tomp> SWPadnos: doesnt he have 'fake' encoders?
[18:39:31] <SWPadnos> oh - is he using probe commands? I thought he'd want to "teach" by moving the arm by hand
[18:40:05] <tomp> yeh, i thought he could take advantage of probe by simulating the probe closure by his switch
[18:40:15] <alex_joni_away> alex_joni_away is now known as alex_joni
[18:40:18] <tomp> and wherever he was, that was recorded
[18:40:32] <tomp> aka 'teach'
[18:40:45] <SWPadnos> but there's no faked feedback with steppers unless emc commands the motion
[18:41:15] <SWPadnos> so you'd have to jog around to the point you want, then enter a probe command, then move the last little bit
[18:41:24] <tomp> right, i dont think he needs encoders, the value in #5061-5066 would just be position
[18:41:26] <SWPadnos> actually, the probe command would move the last little bit
[18:41:48] <SWPadnos> that's only true if you move ny jogging, not if you move by grabbing the arm ;)
[18:41:52] <SWPadnos> s/ny/by/
[18:42:25] <tomp> move 'last little bit'? i dont think motion is needed before the probe is 'triggered' , dunno
[18:42:35] <SWPadnos> yes, it is
[18:42:46] <SWPadnos> I think it's an error if PROBE_INPUT is active when a probe command is started
[18:47:11] <tomp> i was thinking start probe with PROBE_INPUT >in<active, but i see #5061-5066 may only work on axis under control of emc, not jogged joints. maybe he's already started some idea with alex.
[18:48:02] <SWPadnos> right - the internal position vars are only valid (with steppers) when emc commands the movement
[18:48:11] <SWPadnos> unless you also have encoders
[18:48:19] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/sai/driver.cc: make sai more useful from the commandline
[18:49:05] <CIA-6> 03jepler 07TRUNK * 10emc2/tests/ccomp/mill-line-arc-entry/test.sh: use sai commandline arguments instead of a 'here document'
[18:50:29] <CIA-6> 03jepler 07TRUNK * 10emc2/scripts/runtests: if the current directory contains a 'test.sh', run it by default
[19:03:22] <cncjunior> Hello !
[19:03:32] <cradek> hi
[19:14:54] <skunkworks> the door bell in the 'new' house is a bell/buzzer style. pretty cool (old)
[19:16:35] <skunkworks> someone came to the door while we where there and pushed the door bell - we both looked at each other clueless until we figured out it was the doorbell
[19:18:21] <cradek> there it goes again, and here we sit without opposable thumbs
[19:19:44] <tomp> beverly hillbillies: "granny: i dont know what that noise is, but every time we hear it, there's somebody at the front door" ( it was a standard joke on that show )
[19:19:55] <skunkworks> ;)
[19:20:35] <skunkworks> it is definatly a keeper. just sounds cool.
[19:23:07] <skunkworks> and probably why it looks like it was moved to the basement stairwell. ;)
[19:23:41] <cradek> people come to your door? don't you have a moat?
[19:24:43] <skunkworks> just the mississippi ;)
[19:25:44] <cncjunior> how can i implement a real time function for feed and spindel override ?
[19:41:45] <cradek> there is an 'adaptive feed' input in HAL that gives real-time feed override
[19:42:21] <cradek> since spindle speed is output to HAL, you can manipulate it there however you like
[20:18:59] <alex_joni> nigth all
[20:19:05] <skunkworks> night alex
[20:42:26] <CIA-6> 03jepler 07TRUNK * 10emc2/src/po/ (it.po it_rs274_err.po it_axis.po): italian translation improvements from Manfredi Leto
[20:46:02] <CIA-6> 03jepler 07v2_1_branch * 10emc2/debian/ (changelog emc2.files.in): italian translation improvements from Manfredi Leto
[20:46:03] <CIA-6> 03jepler 07v2_1_branch * 10emc2/src/po/ (it.po it_rs274_err.po it_axis.po): italian translation improvements from Manfredi Leto
[20:48:29] <CIA-6> 03jepler 07v2_1_branch * 10emc2/debian/emc2.files.in: include all italian translation files in package
[20:49:03] <CIA-6> 03jepler 07TRUNK * 10emc2/debian/emc2.files.in: include italian translation in package
[21:52:45] <jepler> mschuhmacher: thanks for finding that problem with 'pid.c'. jmkasunich confirmed later that it was a real bug.
[21:53:01] <mschuhmacher> :-)
[21:57:08] <mschuhmacher> I consider to buy 2 motenc cards for my BAZ
[21:59:15] <jepler> I'm not familiar with the motenc cards -- I've only done small, parallel-port-connected stuff
[22:11:10] <roltek> hi guys
[22:11:42] <roltek> can anybody tell me why a m30 does not rewind program
[22:12:29] <roltek> and if it does not now can it be fixed
[22:13:08] <jepler> your program is not a paper tape. What can "rewind" possibly mean?
[22:13:45] <roltek> after program is run it should never sit on last line
[22:14:13] <roltek> it should always be at first line on startup
[22:14:37] <roltek> before start button is hit
[22:17:49] <jepler> The documentation says this: 'No more lines of code in an RS274/NGC file will be executed after the M2 or M30 command is executed. Pressing cycle start will start the program back at the beginning of the file.'
[22:17:58] <jepler> is that not what M30 does for you?
[22:18:45] <roltek> the code is wrong and there is not a machine that works that way
[22:20:31] <jepler> I put 'M30' at the end of one of my .ngc files. The program runs to M30 (which is the last line of the file) and when I press the "start" button again it starts from line 1
[22:21:16] <roltek> that is not how a machine works in real world
[22:23:01] <jepler> can you please try to tell me using different words what you think M30 should do?
[22:24:32] <roltek> when m30 is in program at end program should clear itself and be sitting on 1st line of program
[22:24:57] <roltek> when you hit start button it will start from there
[22:25:19] <jepler> you mean that the contents of line 1 should appear in the program listing part of the display?
[22:25:40] <jepler> rather than the contents of the last few lines?
[22:25:47] <roltek> yes
[22:26:22] <roltek> the first few lines or how evermany lines you are showing
[22:27:28] <jepler> I see
[22:28:59] <jepler> in AXIS you can scroll freely to any line of the program you wish
[22:29:28] <jepler> I see that tkemc leaves you at the bottom with no apparent way to get back to the top...
[22:30:32] <roltek> if your running parts in auto say 500 are you going to waste time scrolling or are you just going to hit cycle start
[22:31:11] <jepler> In both tkemc and axis, pressing the "start" button starts at line 1
[22:31:51] <roltek> true but is not there
[22:31:58] <roltek> it is on last line
[22:32:47] <roltek> that way operator nows part is finished
[22:39:23] <roltek> see you later guys thanks for listening jepler
[22:40:23] <jepler> roltek: glad to listen -- not sure I understood though
[22:44:17] <roltek> not time to eat yet
[22:45:24] <roltek> when you call a open a program up it shows 1st couple of lines
[22:45:29] <roltek> correct
[22:45:53] <jepler> yes.
[22:46:52] <roltek> when you finish a program and part is done it should show the 1st couple of lines before you hit cycle start agin
[22:47:02] <roltek> again
[22:47:27] <jepler> I guess it doesn't bother me that it shows some other lines -- after all, I know what the button will do, and I remember what the program is
[22:48:21] <roltek> just explaining proper way a cnc control should work
[22:49:49] <roltek> what if you are running 4 machines at a time do you remember last lines of code from all of them
[22:51:04] <roltek> sas fact is there are machine operaters that can not read g-code
[22:51:35] <roltek> hit cycle start,check parts and change offsets
[22:53:55] <roltek> super ready see ya
[22:54:20] <jepler> see you
[23:13:13] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: after using 'run from line', task would consume 100% cpu
