#emc | Logs for 2007-06-08

Back
[00:05:47] <cradek> mdynac: do you still want me to bring my tape reader to workshop?
[00:06:03] <a-l-p-h-a_> ooooooooooooooh
[00:06:05] <a-l-p-h-a_> fest?
[00:06:29] <cradek> yeah fest starts this weekend
[00:06:46] <mdynac> no don't bother...cause i don't think i will make it this year....
[00:08:34] <cradek> mdynac: darn!
[00:08:58] <mdynac> sorry, maybe next year.....
[00:31:46] <a-l-p-h-a_> cradek, who's going?
[00:33:27] <cradek> wihttp://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMC_Fest_2007
[00:33:30] <cradek> err
[00:33:31] <cradek> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMC_Fest_2007
[00:33:50] <cradek> at least these folks are going for the emc part
[00:33:56] <cradek> hard to say who else will be there
[00:34:20] <cradek> skunkworks said he is going
[00:39:02] <a-l-p-h-a_> I'd honestly love to go... but work, money > cnc at this time.
[00:39:14] <a-l-p-h-a_> maybe next time I'll schd my vaca to go.
[00:39:29] <toastydeath> beeeep
[00:39:52] <a-l-p-h-a_> wju
[00:40:03] <a-l-p-h-a_> why's #emc-devel listed twice in the wiki? (section 6
[00:40:04] <a-l-p-h-a_> )
[00:45:02] <toastydeath> IT BEARS REPEATING
[00:49:43] <CIA-2> 03cradek 07v2_1_branch * 10emc2/VERSION: release 2.1.6
[00:49:43] <CIA-2> 03cradek 07v2_1_branch * 10emc2/debian/changelog: release 2.1.6
[01:23:58] <CIA-2> 03cradek 07v2_1_branch * 10emc2/VERSION: bump after release
[01:23:59] <cradek> cradek has changed the topic to: Welcome! EMC (Enhanced Machine Controller) is a linux-based opensource CNC control. | Latest release: EMC 2.1.6 | http://www.linuxcnc.org | http://wiki.linuxcnc.org
[01:24:03] <cradek> EMC 2.1.6 is released
[01:32:58] <The_Ball> woho
[01:33:14] <mdynac> kewl
[01:33:25] <The_Ball> is there a official changelog?
[01:34:03] <cradek> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/debian/changelog?rev=1.7.6.59;only_with_tag=v2_1_branch
[01:34:22] <cradek> very few changes. 2.1 is very stable now
[01:42:57] <The_Ball> very nice
[01:53:06] <Ziegler> been released for apt yet?
[01:55:54] <cradek> yes
[02:43:24] <maddash> hm, is there a reason why hal doesn't utilize usb ports?
[02:43:46] <cradek> usb is packetized so it's not realtime
[02:44:01] <cradek> hal_input will talk to many usb devices in nonrealtime though
[02:44:10] <cradek> (joysticks, gamepads, etc)
[02:47:05] <JymmmmEMC> cradek: does it support the newest debain/ubuntu kernel crap? 2.18 iirc?
[02:47:22] <maddash> JymmmmEMC: what kernel crap?
[02:47:45] <JymmmmEMC> 2.18 iirc?
[02:47:58] <jmkasunich> but what particular 2.18 crap are you looking for?
[02:48:12] <maddash> what's '2.18'?
[02:48:20] <JymmmmEMC> apt-get install emc on debian 4/ubuntu 7
[02:48:26] <jmkasunich> the kernel we ship in the live CD is 2.6.15-magma
[02:48:57] <jmkasunich> JymmmmEMC: you need a realtime patched kernel to run EMC (unless you run sim mode, suitable for playing with the GUIs but not running a machine)
[02:49:24] <jmkasunich> our live CD has a patched kernel, and we have realtime kernel packages for ubuntu 5.10 and 6.06
[02:49:48] <jmkasunich> later ubuntus or other distros you need to build the kernel yourself
[02:49:49] <JymmmmEMC> I dont like ubuntu becasue it installs everything under the sun,
[02:50:11] <JymmmmEMC> the wiki says dpkg dont like some kernel thingy
[02:50:34] <jmkasunich> somehow I doubt the wiki says "thingy"
[02:50:48] <JymmmmEMC> no sound card, but were gonna install audio and video players anyway.
[02:51:20] <jmkasunich> JymmmmEMC: you could do a server install of dapper, then add whatever else you want
[02:51:25] <cradek> JymmmmEMC: I don't understand your question yet, can you ask it again please
[02:51:33] <jmkasunich> our kernel package will happily replace the kernel in a dapper server install
[02:51:45] <JymmmmEMC> dapper is the older kernel isn't it?
[02:51:51] <JymmmmEMC> debian 3.xx ???
[02:52:01] <jmkasunich> dapper is a version of ubuntu
[02:52:05] <cradek> dapper uses a 2.6.15 kernel
[02:52:06] <jmkasunich> 6.06 to be precise
[02:52:25] <jmkasunich> why do you keep talking about debian... debian is debian, ubuntu is ubuntu
[02:52:39] <JymmmmEMC> Honestly, I just want to be able to apt get install emc under debian 4.
[02:52:53] <cradek> that probably won't work.
[02:53:00] <maddash> JymmmmEMC: is there a reason you can't compile it?
[02:53:13] <cradek> but you can compile the needed stuff. there are even instrutions on the wiki.
[02:53:13] <cradek> c
[02:53:30] <JymmmmEMC> That's where I read the kernel issue thing.
[02:53:39] <jepler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2#Debian_Sarge http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2#Debian_Etch http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2#Debian_Etch_compile_RTAI
[02:53:51] <maddash> jepler: my sentiments exactly.
[02:54:10] <jmkasunich> go, ye JymmmmEMC, and seek enlightenment amongs the pages of yon wiki
[02:54:12] <jepler> emc2 should work with a wide range of kernel versions
[02:54:30] <JymmmmEMC> jmkasunich: I dont do compile/cvs
[02:54:31] <cradek> should and does...
[02:54:38] <jepler> of course it receives the most testing on Ubuntu 6.06
[02:54:46] <jmkasunich> JymmmmEMC: zat so?
[02:54:52] <maddash> hm, I'm just itching to write a hal driver, but i've yet to figure out what it should do...
[02:54:57] <jmkasunich> we don't make binary packages for every distro under the sun
[02:55:01] <JymmmmEMC> jmkasunich: Yep, we just dont get along too well.
[02:55:05] <cradek> JymmmmEMC: then are you just complaining and you don't want a solution?
[02:55:18] <cradek> if so, I'll go on to doing something else
[02:55:19] <JymmmmEMC> cradek: I'm ntot coml=plaing at all, just asking.
[02:55:38] <JymmmmEMC> I'll just wait till I can apt-get
[02:55:46] <cradek> if you want to use the binary packages I put in the apt repo, you should use ubuntu dapper
[02:55:49] <jmkasunich> thats liable to be a long wait
[02:55:53] <cradek> (or breezy)
[02:56:05] <jepler> goodnight guys
[02:56:13] <JymmmmEMC> nite jeff
[02:56:15] <jmkasunich> night jeff
[02:56:15] <cradek> night
[02:58:16] <JymmmmEMC> jmkasunich: Thingy ----> FIX: Debian team decided to release Debian Etch with 2.6.18 kernel. Therefore, linux-source-2.6.17 and linux-patch-debian-2.6.17 packages are removed from repository. But there is no RTAI hal patch for 2.6.18 kernel. So, we need to use 2.6.17 packages.
[02:59:28] <maddash> I'm trying to implement several interruptible delays (of varying length) in parallel. signaling a SIGALRM wouldn't work, because there's only one of them per module. is there a solution to this besides splitting my code across several modules?
[02:59:35] <JymmmmEMC> jmkasunich: that be the technical term btw =)
[03:01:03] <cradek> maddash: can you write in terms of select instead of blocking+alarm?
[03:04:32] <maddash> cradek: by "blocking," do you mean the issuing a call to 'sleep()'? b/c i noticed that esleep() uses select(), which would make select blocking as well. otherwise, I'd have to say that I know nothing about select().
[03:05:07] <cradek> yes sleep is blocking
[03:05:40] <cradek> why are you sleeping?
[03:06:46] <cradek> select is: wait until some of this set of file descriptors are readable or writable, or (optionally) a timeout happens
[03:06:59] <cradek> esleep uses just the timeout apparently
[03:07:38] <maddash> i don't think I'm sleeping. right now, i can only implement one delay at a time, and I do this by creating an itimerval struct and passing it to setitimer (which in turn calls the SIGALRM function after a delay).
[03:08:29] <cradek> ok why are you delaying?
[03:08:42] <cradek> I'm trying to understand your goal, not your implementation
[03:11:20] <maddash> don't laugh. i want to attach a set of LEDs as indicators for the state of my CNC. there aren't a lot of output pins available on the parport, so i'm reducing the # of LEDs I need by giving each of them several states (blinking, steady, etc.)
[03:11:43] <cradek> ok
[03:15:07] <cradek> one thing that comes to mind: say you want one to blink twice a second and one three times a second. you could delay 1/6th second, and on every second wakeup toggle one, and on every third wakeup, trigger the other. (This is how emc's realtime works!)
[03:17:25] <maddash> but emc doesn't have to implement realtime delays...
[03:18:34] <cradek> it does exactly the same thing you're asking about. it says "call me again when the next [period] comes around"
[03:19:16] <cradek> I have to run, goodnight
[03:19:22] <maddash> night.
[03:19:45] <jmkasunich> maddash: you were saying earlier that you wanted to write a HAL component but didn't know what to make it do
[03:19:50] <jmkasunich> write a blinker component
[03:19:52] <toastydeath> DANCE
[03:20:14] <maddash> write a dancing blinking component?
[03:20:21] <jmkasunich> just blinking
[03:20:31] <jmkasunich> we'll let toasty do the dancing
[03:20:44] <toastydeath> awwww yeah
[03:20:55] <toastydeath> anyone have digital mics
[03:20:55] <jmkasunich> two params, ontime, and offtime, and two pins, enable and out
[03:21:19] <jmkasunich> when enable is true, out toggles using the times
[03:21:30] <maddash> jmkasunich: but hal components always exist in single instances, right? so a blinker component would be a trivial hal_skeleton with the appropriate sigalrm...
[03:21:37] <jmkasunich> no
[03:21:43] <jmkasunich> no sigs
[03:21:48] <jmkasunich> hal is inherently realtime
[03:22:00] <jmkasunich> you don't need no steenkin sigs
[03:22:08] <jmkasunich> if enable {
[03:22:11] <maddash> fine, s/sigalrm/hal_create_thread/
[03:22:22] <jmkasunich> components don't create threads
[03:22:40] <jmkasunich> they just supply some code (which can be quite simple) that runs in a thread
[03:23:47] <maddash> 'steenkin'? springsteen kinematics? heh.
[03:23:57] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/components/oneshot.comp?rev=1.4
[03:27:13] <maddash> holy crap, you're actually burning the cpu by incrementing a counter each cycle?
[03:27:30] <jmkasunich> each millisecond, or however often the thread runs
[03:27:40] <maddash> also, that data.timer would not be consistent across machines...
[03:27:50] <jmkasunich> why not?
[03:28:23] <SWPadnos> note this: pin in float width=0 "Pulse width in seconds";
[03:29:35] <maddash> jmkasunich: because faster cpus would decrement data.timer faster
[03:29:55] <maddash> SWPadnos: isn't that just a calibrating value?
[03:30:02] <jmkasunich> maddash: no they would not
[03:30:07] <SWPadnos> no they won't - the function is called at the thread rate on all machines that HAL runs on
[03:30:16] <jmkasunich> what part of "periodic thread" are you missing?
[03:30:33] <SWPadnos> and the period is passed in to the hAL functions, so they know how many nanoseconds elapse between runs
[03:31:04] <jmkasunich> "halcmd loadrt threads name1=foo period1=1000000" will give you a hard realtime thread that runs once per millisecond on any machine
[03:31:19] <SWPadnos> (that HAL runs on ...)
[03:31:20] <maddash> so you're basically using a hal_create_thread like I mentioned before?
[03:31:27] <jmkasunich> right - any machine with a realtime kernel
[03:31:43] <jmkasunich> yes, and no
[03:31:57] <SWPadnos> maddash, the thread is created once, and each component in the thread runs at that rate from then on
[03:31:57] <jmkasunich> yes, when you set up your overall system, you create a thread
[03:32:11] <jmkasunich> no, the component doesn't call create_thread,
[03:32:35] <jmkasunich> that loadrt line creates the thread, then you can do something like:
[03:32:43] <jmkasunich> loadrt one-shot count=2
[03:32:46] <jmkasunich> that gives you two oneshots
[03:32:50] <jmkasunich> then
[03:32:59] <maddash> jmkasunich: sorry for not being clear before. to me, creating a thread with halcmd is identical to calling hal_create_thread (except halcmd would create_thread, not the component).
[03:32:59] <jmkasunich> addf one-shot.0 foo
[03:33:05] <jmkasunich> addf one-shot.1 foo
[03:33:10] <jmkasunich> that adds both oneshots to the thread
[03:33:33] <jmkasunich> right, but you should never call create-thread from a component
[03:33:57] <jmkasunich> well, never is a bit strong, but certainly not from a general purpose component like a led blinker
[03:34:24] <maddash> still, isn't it a waste of cpu cycles to decrement a counter on your fastest thread?
[03:34:29] <jmkasunich> emc's realtime module (the main motion controller, component "motmod") creates threads that are used by every other module that is loaded as part of an EMC configuration
[03:34:35] <SWPadnos> that depends on your aims
[03:34:45] <maddash> jmkasunich: basethread and servothread?
[03:35:15] <SWPadnos> if you need to have the lightest possible CPU load from blinking the LEDs, then yes, it's counterproductive to use a fast thread for slow blinking
[03:35:15] <jmkasunich> if you want to blink a light a couple times a second, using basethread is wastefull, servothread is a little bit so, since it runs every millisecond
[03:35:28] <maddash> SWPadnos: why not create a seperate thread that loops once during the desired period?
[03:35:43] <jmkasunich> because that way lies madness
[03:35:48] <SWPadnos> you could have a 10ms thread or even a 100ms thread for 0.01 or 0.1-second resolution, respectively
[03:36:28] <jmkasunich> you could certainly have slower threads, but the number of cycles you save by updating a timer 10 times/sec instead of 1000 is dust in the wind
[03:36:39] <jmkasunich> the overhead of managing more threads is probably more than that
[03:37:06] <SWPadnos> consider this: the kernel sits there with an interrupt running at HZ hertz (often 1000 on recent kernels). in that interrupt, it looks at all the running threads to see if anything needs doing, and in several places, there are counters that get incremented;/decremented every time
[03:37:20] <SWPadnos> (like page use counters, timers of various sorts ...)
[03:37:33] <SWPadnos> but it isn't like that overhead really slows down a computer all that much
[03:38:11] <SWPadnos> and internally, there's a counter that goes "well, we've run the fast thread 1600 times, it's time to fire off the slow thread again"
[03:38:46] <SWPadnos> you do save all the thread call overhead though, since the thread is only processed once, but that is trivial
[03:41:53] <maddash> SWPadnos: so it's better to have multiple threads instead of multiple counters on one super fast thread?
[03:42:46] <SWPadnos> "better" depends on many things
[03:43:12] <jmkasunich> in general, you want to minimize the number of threads to avoid complexity and risks of things like non-atomic updates of data that is written from one thread and read in another
[03:43:33] <jmkasunich> hal does a lot to protect against that, but if you abuse it with one thread per component, you WILL get bit in the ass sooner or later
[03:43:48] <SWPadnos> if your only concern is for saving some CPU cycles, (and maintenance and determinism aren't important), then many threads are optimal
[03:43:57] <jmkasunich> true
[03:44:17] <jmkasunich> and if we were programming microcontrollers instead of pentiums, we might do things differently
[03:44:24] <toastydeath> it's all about the pentiums baby
[03:44:30] <SWPadnos> but CPU cycles are getting cheaper, and maintenance and unpredictability go up in cost over time, so ...
[03:45:08] <jmkasunich> EMC uses two threads - one for the really fast stuff like makeing step pulses, which needs the finest possible time resolution
[03:45:14] <jmkasunich> and one for everything else
[03:45:21] <maddash> servothread?
[03:45:31] <jmkasunich> yes, base is the fast one, servo is the slow one
[03:45:58] <SWPadnos> you could say that the userspace stuff is in some slow threads (100ms period), but since their execution isn't managed in any RT sort of way, it's not quite accurate
[03:46:08] <jmkasunich> if you had something that had to do a LARGE amount of work every 0.1 seconds, then it would make sense to create a 0.1 second thread and add your code to it
[03:46:29] <jmkasunich> but for things like blinking lights, the overhead of calling it every 1mS is unmeasurable
[03:46:46] <maddash> how large is LARGE?
[03:46:47] <SWPadnos> plus, it gives you more accurate blink times :)
[03:46:54] <maddash> SWPadnos: :)
[03:47:08] <SWPadnos> maddash, what kind of CPU are you targeting? (and at what speed)
[03:47:09] <jmkasunich> if its gonna take a millisecond to execute, you don't want to run it in a millsecond thread
[03:47:35] <jmkasunich> but even a 400MHz P3 can execute 400,000 instructions in a millisecond
[03:47:50] <SWPadnos> if you need more than 70% or so of a thread period to do something, then you need a slower thread (for the most part)
[03:47:55] <jmkasunich> (I know, its actually less because of memory bandwidth, but my point is - its a lot)
[03:48:23] <jmkasunich> the light blinking thing - that code probably takes about 50 nano-seconds to run
[03:48:41] <jmkasunich> well, maybe a couple hundred nano-seconds on a 400MHz P3
[03:49:01] <maddash> SWPadnos: heh. celeron d 2ghz.
[03:49:29] <jmkasunich> so running it 1000 times a second gets you up to a couple hundred micro-seconds per second, or 0.02% of the CPU
[03:50:04] <jmkasunich> 0.005% on the 2GHz machine ;-)
[03:50:20] <SWPadnos> ok, so the thread to count up blinky time is maybe 1000 cycles (due to cache crap mostly), giving a whopping 1Mcycles or 0.05% of the CPU
[03:50:52] <maddash> jmkasunich: so in general, i'd want the thread cycle to be far greater than the execution time of each cycle?
[03:51:22] <jmkasunich> yeah, or more accuratlely, you want the run time of the code to be comfortabley less than the period at which you are running it
[03:51:36] <jmkasunich> if you as the CPU to run 2mS of code every 1mS, you're gonna have a problem
[03:51:37] <SWPadnos> I think there's some paper that proves you can't guarantee determinism if you go over 69.<mumble>% of the thread period
[03:51:59] <jmkasunich> if you ask it to run 2uS of code every 1mS, you are using 0.2% of it, no prob at all
[03:52:14] <SWPadnos> so figure 2/3 of the thread being used for code execution, and you'll be safe
[03:52:26] <SWPadnos> (the rest is overhead and idle time)
[03:52:52] <jmkasunich> idle = background = your IRC client, brower, text editor, the EMC GUI, all the non-realtime stuff
[03:53:00] <jmkasunich> that runs when the realtime stuff isn't running
[03:53:25] <jmkasunich> and to be honest, I'd aim for less than 50% RT loading, not 2/3
[03:53:28] <SWPadnos> yeah. for EMC it should probably be a higher margin
[03:53:49] <jmkasunich> but again, for simple HAL componets, you are talking 10ths of a percent or less
[03:54:08] <SWPadnos> my assumption is that there would be other things going on during the blinking ;)
[03:54:25] <jmkasunich> right
[03:54:43] <jmkasunich> but I'm making the point that the incremental load of the blinker is tiny
[03:54:53] <SWPadnos> yep
[03:55:12] <maddash> jmkasunich: on a side note -- i notice that your code often decrements a counter instead of incrementing it -- is there a reason for that?
[03:55:35] <jmkasunich> habit
[03:55:59] <jmkasunich> in assembly and in hardware its easier to detect zero or underflow than it is to detect reaching a specific value
[03:56:13] <jmkasunich> I'm not writing assembly anymore, but habits are habits
[03:56:31] <jmkasunich> there are also some interesting cases when the time changes midstream
[03:56:52] <jmkasunich> say you have a period of 100, and at some point, somebody changes it to 50
[03:57:20] <SWPadnos> actually, count up is better in that case (or at least equivalent)
[03:57:22] <jmkasunich> if you load 100, then count down to zero, the load value can change at any time, the counter is unaffected, when it gets to zero, you reload with 50 and go on
[03:57:51] <jmkasunich> if you were counting up towards 100, and had reached 75, when somebody changes the target to 50, you might just keep counting
[03:58:01] <jmkasunich> (if you are testing for == instead of >=)
[03:58:05] <SWPadnos> it depends on whether you want "glitch-free" timing, or if you want the output to update immediately if the new target is already passed
[03:58:11] <jmkasunich> right
[03:58:27] <jmkasunich> and again, my hardware background is showing
[03:58:32] <SWPadnos> heh
[03:58:37] <jmkasunich> in hardware, >= is much more expensive than ==
[03:58:40] <SWPadnos> == is much easier to test for than >= in hardware
[03:58:43] <jmkasunich> and == 0 is even cheaper
[03:58:58] <SWPadnos> ayeah, a bazillion-input AND gate
[03:59:28] <jmkasunich> >= is expensive and slow, because you have a carry that needs to propogate
[03:59:35] <maddash> yeah, but -= is slower than +=
[03:59:36] <jmkasunich> == and ==0 are both parallel
[03:59:47] <SWPadnos> -= is often faster
[03:59:48] <jmkasunich> no its not
[04:00:02] <SWPadnos> comparisons are done as subtraction, without storing the result
[04:00:04] <maddash> yes. subtraction is more costly then addition on the x86 platform.
[04:00:09] <SWPadnos> that's often quite optimized
[04:00:12] <jmkasunich> -= is often implemnted as += -1
[04:00:38] <SWPadnos> I believe they're both 1 cycle in modern x86 chips
[04:00:41] <maddash> and -=12345?
[04:00:46] <jmkasunich> maddash: I'm very sure that on any recent (Pentium 1 and later), + and - are both one cycle
[04:00:47] <SWPadnos> += -12345
[04:00:50] <jmkasunich> what he said
[04:01:11] <SWPadnos> even floating point add/sub is only 3 cycles
[04:01:33] <jmkasunich> anyway, as I said, its habit
[04:01:33] <SWPadnos> (and multiply was pretty close to that, IIRC)
[04:02:16] <jmkasunich> on modern CPUs, the time needed to fetch the instruction and the data is probably 10x longer than the time needed to do the math anyway
[04:03:01] <SWPadnos> actually, you and I found that when we were testing very fast threads
[04:03:09] <jmkasunich> yep
[04:03:29] <SWPadnos> the execution time went down when we got the period fast enough to keep the function/data in cache
[04:03:34] <jmkasunich> as you make the thread faster and faster (run more often) you get to a point where it actually executes faster
[04:03:36] <SWPadnos> by a factor of 10, IIRC
[04:03:46] <jmkasunich> because you are running it again before it gets flushed out of the cache by background code
[04:03:53] <jmkasunich> heh
[04:04:01] <JymmmmEMC> rasberrys
[04:04:07] <jmkasunich> there's an echo in here
[04:04:24] <SWPadnos> what, I can't hear you - there's an echo in here
[04:04:35] <jmkasunich> I just did a little test of "oneshot"
[04:04:37] <maddash> and what point is that?
[04:04:48] <SWPadnos> when it gets faster?
[04:05:19] <SWPadnos> that'll depend on the size of the thread function(s), what other tasks are running, the size of the cache ...
[04:05:29] <jmkasunich> I have two of them in a 1mS thread... the first one averages about 1300 clocks, and the second only about 500-600
[04:05:29] <SWPadnos> you need to test for every configuration, I imagine
[04:05:59] <SWPadnos> hmmm. operating on the same data?
[04:06:03] <jmkasunich> this on a 1.6GHz machine, so both of them together are just barely over 1uS, or 0.1% of the CPU
[04:06:23] <jmkasunich> no, two oneshots, using two sets of HAL pins,e tc
[04:06:33] <jmkasunich> thats just the code caching effect, not data caching
[04:06:36] <SWPadnos> ah. try sticking one func in the same thread twice instead
[04:06:40] <SWPadnos> (curious)
[04:06:44] <jmkasunich> HAL won't let you do that
[04:06:48] <SWPadnos> why not?
[04:06:59] <jmkasunich> because
[04:07:05] <SWPadnos> oh
[04:07:06] <SWPadnos> thanks
[04:07:27] <jmkasunich> in general its not a good idea - if you run a comp twice in one thread, it will have a badly distorted idea of passing time, for one thing
[04:07:45] <SWPadnos> sure - it'll run twice as fast
[04:07:58] <jmkasunich> I believe the export_function() API in hal lets you say that a function is re-entrant, then HAL will let you addf it twice
[04:08:11] <SWPadnos> but it can also potentially give you a scope-able trace of actual exectuion time (distorted of course)
[04:08:12] <jmkasunich> but I know of no functions today that use that
[04:08:44] <jmkasunich> oh, because the 2nd write to function.time is the one that you'll see?
[04:08:48] <maddash> can't you run twice with the "reinstantiate" flag?
[04:08:58] <jmkasunich> what reinstantiate flag?
[04:09:11] <SWPadnos> no, because you have to add an addiutional physical output call to the thread
[04:09:32] <SWPadnos> hmmm. re-entrancy would be needed to add a single function to multiple threads, not to the same thread (if the term is being used in the "standard" way)
[04:09:34] <jmkasunich> oh, you mean a real scope watching the hardware
[04:09:39] <SWPadnos> yes
[04:09:41] <maddash> reentrant* http://www.linuxcnc.org/docs/html/man/man3/hal_export_funct.3hal.html
[04:09:58] <jmkasunich> SWPadnos: hal doesn't make the distinction between multiple threads and multiple instances in the same thread
[04:10:05] <SWPadnos> actually, scope.sample would be something that could be useful multiple times in a single thread
[04:10:07] <SWPadnos> oh
[04:10:08] <maddash> SWPadnos: oh, I see.
[04:10:51] <jmkasunich> SWPadnos: I'm pretty sure that there is no "normal" use for multiple invocations of a function in one thread
[04:11:08] <maddash> i'm really interested in finding out this point where the threads keep everything inside the cache
[04:11:12] <jmkasunich> and preventing it in HAL catches a class of typos that otherwise would result in head-scratching
[04:11:31] <jmkasunich> maddash: you can test that pretty easily
[04:11:32] <SWPadnos> maddash, look at the *.time numbers in hal
[04:11:49] <SWPadnos> decrease the fast thread period until the .time drops significantly
[04:12:20] <SWPadnos> (of course, you'll need to stop HAL each time, so I'd make a script)
[04:12:43] <jmkasunich> if you are running two instances of whatever component, the 2nd on should start out quite a bit faster than the first one
[04:12:52] <maddash> sorry, where am I supposed to find this *.time thing?
[04:12:57] <jmkasunich> when the first one drops into the same neighborhood, you know its staying in cache
[04:13:02] <jmkasunich> show param
[04:13:37] <SWPadnos> there will be one for each function
[04:13:39] <jmkasunich> here's what I did to test:
[04:13:51] <jmkasunich> loadrt oneshot count=2
[04:13:52] <jmkasunich> loadrt threads name1=foo period1=1000000
[04:14:00] <jmkasunich> addf oneshot.0 foo
[04:14:01] <jmkasunich> addf oneshot.1 foo
[04:14:02] <jmkasunich> start
[04:14:07] <jmkasunich> show param
[04:14:24] <jmkasunich> result of show param:
[04:14:26] <jmkasunich> 4 bit RW FALSE oneshot.0.falling
[04:14:27] <jmkasunich> 4 bit RW TRUE oneshot.0.retriggerable
[04:14:27] <jmkasunich> 4 bit RW TRUE oneshot.0.rising
[04:14:27] <jmkasunich> 4 s32 RO 524 oneshot.0.time
[04:14:28] <jmkasunich> 4 s32 RW 27575 oneshot.0.tmax
[04:14:29] <jmkasunich> 4 bit RW FALSE oneshot.1.falling
[04:14:31] <jmkasunich> 4 bit RW TRUE oneshot.1.retriggerable
[04:14:34] <jmkasunich> 4 bit RW TRUE oneshot.1.rising
[04:14:38] <jmkasunich> 4 s32 RO 472 oneshot.1.time
[04:14:40] <jmkasunich> 4 s32 RW 16455 oneshot.1.tmax
[04:14:52] <SWPadnos> I bet you can now do "show param *time"
[04:15:11] <jmkasunich> oh, look at that
[04:15:17] <jmkasunich> I didn't know that feature was in there
[04:15:25] <jmkasunich> dunno if its in 2.1.x
[04:15:31] <SWPadnos> came in with the readline stuff, I think
[04:15:38] <SWPadnos> up-arrow, tab-completion ...
[04:15:46] <jmkasunich> 4 bit RW FALSE oneshot.0.falling
[04:15:48] <jmkasunich> 4 bit RW TRUE oneshot.0.retriggerable
[04:15:48] <jmkasunich> 4 bit RW TRUE oneshot.0.rising
[04:15:48] <jmkasunich> 4 s32 RO 524 oneshot.0.time
[04:15:48] <jmkasunich> 4 s32 RW 27575 oneshot.0.tmax
[04:15:48] <jmkasunich> 4 bit RW FALSE oneshot.1.falling
[04:15:48] <jmkasunich> 4 bit RW TRUE oneshot.1.retriggerable
[04:15:51] <jmkasunich> 4 bit RW TRUE oneshot.1.rising
[04:15:52] <jmkasunich> 4 s32 RO 472 oneshot.1.time
[04:15:55] <jmkasunich> 4 s32 RW 16455 oneshot.1.tmax
[04:15:56] <jmkasunich> oops
[04:15:58] <jmkasunich> 4 s32 RO 1434 oneshot.0.time
[04:16:00] <jmkasunich> 4 s32 RO 622 oneshot.1.time
[04:16:02] <jmkasunich> meant to paste the short one
[04:16:08] <jmkasunich> note that the first run takes longer
[04:16:08] <SWPadnos> yay :)
[04:17:21] <jmkasunich> you can also do "show thread" and see the total time for the thread
[04:17:33] <jmkasunich> halcmd: show thread
[04:17:31] <jmkasunich> Realtime Threads:
[04:17:31] <jmkasunich> Period FP Name ( Time, Max-Time )
[04:17:31] <jmkasunich> 999849 YES foo ( 2139, 16829 )
[04:24:38] <maddash> good night, guys
[04:24:43] <jmkasunich> goodnight
[04:25:29] <SWPadnos> oh yeah. I was thinking of sleeping some day :)
[04:25:43] <jmkasunich> same here
[04:25:57] <jmkasunich> I actually wanted to sleep sooner, wasn't paying attention to the time
[04:26:02] <jmkasunich> oh, before you go
[04:26:04] <SWPadnos> heh - me either
[04:26:06] <SWPadnos> yah
[08:08:44] <JymmmmEMC> SWPadnos: sleep when your dead
[08:27:05] <hcseb> Hi folks, I'm trying to add a couple of G codes to EMC for a couple of specific features of my machine.
[08:27:27] <hcseb> Can anyone tell me where I add those G-codes?
[08:27:51] <alex_joni> hcseb: hi
[08:27:59] <alex_joni> what kind of G-codes?
[08:28:11] <hcseb> Well, we have a machine with a flame cutter.
[08:28:38] <alex_joni> ok, go on ;)
[08:28:51] <hcseb> So it'll be "ignite torch", "switch on cutting O2" and "stop torch"
[08:28:53] <alex_joni> I'm only asking because it depends on the extent on the changes
[08:29:45] <hcseb> The torch moves with the Y axis
[08:29:52] <hcseb> Also, I have various clamps to control with G codes
[08:30:04] <hcseb> A material clamp, an in-feed clamp and an out-feed clamp
[08:30:06] <alex_joni> aren't some simple M-codes enough for the ignite torch, switch on cutting, etc?
[08:30:25] <alex_joni> you can use user-defined M-codes : M101, M102 etc
[08:30:43] <hcseb> Possibly - I haven't got quite as far as determining the differnece
[08:30:52] <alex_joni> hcseb: those are basicly bit typed signals.. right?
[08:30:53] <hcseb> between G and M and O, that is.
[08:30:59] <alex_joni> hcseb: semantics :D
[08:31:01] <hcseb> Yes they're all bit type signals
[08:31:15] <alex_joni> hcseb: so M101 P0 to turn off
[08:31:17] <alex_joni> M101 P1 to turn on
[08:31:43] <alex_joni> M1xx are added automatically if EMC finds an executable with that name
[08:31:51] <alex_joni> for example a simple script
[08:31:51] <hcseb> There'll have to be HAL components to control them, as, for example, you don't want to turn the cutting O2 on unless there is a flame present
[08:32:10] <alex_joni> hcseb: right, that's probably best done with classicladder
[08:32:12] <hcseb> Where would this executable go?
[08:32:16] <alex_joni> are you familiar with PLCs?
[08:32:21] <alex_joni> hcseb: in the programs folder
[08:32:31] <alex_joni> by default there are 2 examples there
[08:32:51] <hcseb> I'm not familiar with PLCs; would prefer to code HAL modules
[08:33:01] <hcseb> I like the HAL
[08:33:05] <alex_joni> hcseb: that's ok too, if you're ok with that
[08:33:09] <alex_joni> great
[08:33:29] <alex_joni> hcseb: the M101 script would be something like: halcmd setp whater.pin TRUE
[08:34:09] <alex_joni> or maybe: halcmd setp whatever.pin $P
[08:34:14] <hcseb> I'll look at the examples. However, the old Siemens CNC which we are replacing had its own codes for doing these things, and because there are thousands of scripts written with these codes, I would ideally like to replicate them
[08:34:32] <alex_joni> hcseb: then you need to change the interpreter
[08:35:04] <hcseb> Ok; can you tell me where in the source that is? Is it src/emc/rs274ngc?
[08:35:11] <alex_joni> I can walk you through some parts if you have the sources open
[08:35:28] <alex_joni> yes, src/emc/rs274ngc
[08:35:52] <hcseb> Yes, I have the soruce code, and am in that dir
[08:36:22] <alex_joni> ok.. I might "feel" sluggish
[08:36:30] <alex_joni> but I also have to cover a bit of other work here ;)
[08:36:33] <alex_joni> * alex_joni is at work currently
[08:36:34] <hcseb> ok ;)
[08:36:37] <alex_joni> so .. be patient :P
[08:36:50] <alex_joni> look at interp_array
[08:37:05] <hcseb> Well, that'll work out - it always takes longer to read source than to guide someone through it ;)
[08:37:07] <alex_joni> there are several groups
[08:37:22] <alex_joni> group 0,1,2,3,5,6,7,8,10,12,13
[08:37:55] <alex_joni> first you need to figure out in which group your g-code fits
[08:38:21] <hcseb> Ok
[08:38:37] <alex_joni> then you need to add the group number to that big array
[08:38:49] <alex_joni> well to one of the big arrays (one is for G-codes one for M-codes)
[08:38:59] <alex_joni> usually/traditionally G-codes are for movement specific stuff
[08:39:11] <alex_joni> and M-code for miscelaneous aka IO, tool, etc
[08:39:20] <hcseb> Ok, these'll be M codes then.
[08:39:35] <alex_joni> hcseb: probably you want to use the codes and numbers from your old control
[08:39:45] <hcseb> Apart from, possibly, move flame, which may have its own code, even though it moves with the Y axis
[08:40:06] <hcseb> alex_joni: Yes, that's the plan. Hopefully they won't conflict with anything.
[08:40:28] <alex_joni> if they conflict, you can see that in this tables
[08:40:33] <hcseb> *nod*
[08:40:41] <alex_joni> the _ems[] is a straightforward array
[08:40:50] <alex_joni> M0..M199
[08:41:01] <alex_joni> where M100..M199 are user defined and shouldn't be hardcoded
[08:41:34] <alex_joni> the _gees[] array is a bit more complicated, that the numbers are all multiplied by 10
[08:41:58] <alex_joni> that is done to be able to use G-codes like G59.2
[08:42:08] <alex_joni> which actually corresponds to 592 in that table
[08:42:24] <alex_joni> following so far?
[08:42:51] <hcseb> Hang on there - thought you said you'd be sluggish! :)
[08:43:17] <hcseb> I've got to pause a minute to swap my monitor - this one is unreadable.
[08:43:21] <alex_joni> ok
[08:43:39] <hcseb> Hopefully I should stay logged in, assuming my Nomachine NX connection suspends and resumes properly...
[08:43:41] <hcseb> brb
[08:44:36] <hcseb> I've saved what you typed anyway. brb
[08:48:57] <hcseb> Ok, back
[08:49:16] <hcseb> Now I can read the text easily in my text editor :)
[08:51:19] <hcseb> ok, I follow
[08:51:51] <hcseb> What does the content of each location in the _ems and _gees arrays mean?
[08:51:51] <alex_joni> jas
[08:51:58] <alex_joni> it's the group the code belongs to
[08:52:05] <hcseb> *nod* ok
[08:52:25] <hcseb> -1 meaning no group?
[08:52:38] <alex_joni> yeah, actually meaning not a valid code
[08:52:53] <hcseb> So free to be implemented?
[08:53:00] <alex_joni> yup
[08:53:09] <hcseb> Great
[08:55:00] <hcseb> Then how do I bind a code, with its group to an action or script?
[08:55:16] <alex_joni> ok, next we look at interp_convert
[08:55:51] <alex_joni> search for convert_g()
[08:56:05] <hcseb> giot it
[08:57:20] <hcseb> Then I look at whichever of the conver_xxxxx functions matches the command I am implementing
[08:57:45] <alex_joni> yup
[08:58:13] <alex_joni> and ask if you still have questions ;)
[08:58:30] <hcseb> Ok. I think that's pretty clear now. Many thanks for your help!
[08:58:46] <alex_joni> basicly you will be calling commands from tha canonical interface
[08:59:04] <alex_joni> look at src/emc/nm-Intf/canon.hh
[08:59:48] <hcseb> iirc, a block of codes is basically a lnie of codes, or it a block a single code, possibly witha parameter?
[09:01:17] <alex_joni> yup
[09:01:22] <alex_joni> the later
[09:01:25] <hcseb> *nod*
[09:01:30] <alex_joni> a parameter or more
[09:02:41] <hcseb> I reckon I'm going to have to hack canon.hh and friends to run our 8 axis driller
[09:20:54] <hcseb> alex_joni: Where are you located? In Europe?
[09:26:10] <hcseb> Hmm, M51 to M53 conflict. In EMC they are used for feed, spindle speed and adaptive feed override
[09:27:21] <hcseb> On the Siemens CNC and the Peddinghaus FDB600, they're "Drill spindle 1 at 1500 rpm", "Drill spindle 1 at 3000 rpm". Actually I don't think M53 is used on the FDB now I look
[09:28:55] <hcseb> Yes it is.. M53 is "Mark spindle 1"
[09:39:04] <alex_joni> hcseb: no issues in changing them to suit yourself ;)
[09:39:18] <alex_joni> hcseb: I'm located in eastern europe (timisoara, romania)
[09:41:27] <hcseb> I'm going to change them to suit our machines. I'll use ifdefs to make the changes commitable.
[09:42:05] <hcseb> alex_joni: I'm in Sheffield, UK; the UK's Steel City
[09:46:10] <alex_joni> nice
[09:46:19] <alex_joni> there are other people from the UK involved in emc
[09:46:42] <hcseb> I have come across Paul Corner already
[09:49:13] <alex_joni> right
[09:49:25] <alex_joni> unfortunately he drifted away from the emc project
[09:51:06] <hcseb> I got the impression that there had been some disagreements.. A shame.
[09:51:20] <alex_joni> yup
[09:51:49] <alex_joni> otoh, he's working on an alternative now
[09:51:58] <alex_joni> so for the end-user it's not that bad ;)
[09:52:22] <hcseb> The Unirii Square looks beautiful!
[09:52:31] <alex_joni> yeah, it is nice
[09:52:37] <hcseb> Sheffield is an ugly city
[09:52:45] <archivist> just a bit
[09:53:01] <hcseb> But there is some good pseudo countryside close by
[09:53:33] <archivist> * archivist pfrefers seing the industrial stuff anyway
[09:53:40] <alex_joni> hcseb: there's pics on my blog if you care ;)
[09:54:00] <alex_joni> http://juve.ro
[09:56:12] <archivist> hceb is hillsfoot forge still running in sheffield
[09:57:16] <hcseb> archivist: Not sure
[09:57:56] <archivist> went a few years ago to see steam hammers in action (driven by air though)
[09:58:02] <hcseb> No one in the office here knows either
[09:58:37] <hcseb> Are you sure about the name?
[09:59:28] <archivist> that could be the factory name rather than company
[10:00:13] <archivist> probably nearly 10 years ago
[10:01:23] <hcseb> Perhaps you mean: http://www.hillfoot.com/
[10:04:34] <archivist> hmm flash but yes hillfoot forge got to change box to see site
[10:15:47] <archivist> that place was well worth the effort to go and see
[10:16:13] <hcseb> I'm sure
[10:16:43] <hcseb> I'm working in a steel fabrication shop - making the components of building structures
[10:17:29] <archivist> smaller stuff here clockmakers
[10:23:23] <alex_joni> archivist: you're also from the UK?
[10:23:35] <archivist> yes
[10:23:41] <|Bo^Dick|> |Bo^Dick| is now known as Bo^Dick
[10:23:52] <archivist> east midlands burton on trent
[10:25:11] <alex_joni> I must admit (shamefully) that that doesn't mean much to me :/
[10:25:35] <alex_joni> ok, looked it up ;)
[10:25:43] <alex_joni> http://en.wikipedia.org/wiki/Burton_upon_Trent
[10:25:56] <alex_joni> "The town is currently home to five brewers"
[10:25:59] <alex_joni> sounds nice ;)
[10:26:09] <archivist> yup where the beer comes from
[10:31:30] <hcseb> Hmm, there is no obvious group for my clamping commands in _ems...
[10:31:43] <hcseb> Any suggestions?
[10:33:58] <hcseb> There only appear to be groups 4 to 10 for _ems[] so I could create group 3 for clamping M codes
[10:43:23] <anonimasu> hi
[10:52:39] <robin_z> meep?
[10:53:04] <robin_z> Burton on Trent .. the ancestral home of ....
[10:53:08] <robin_z> Marmite!
[10:53:28] <anonimasu> hey
[10:53:32] <anonimasu> robin_z: what's up?
[10:53:32] <robin_z> dood
[10:53:38] <anonimasu> except for the sky..
[10:53:46] <robin_z> $matey has been playing with his new mill
[10:54:09] <robin_z> got the tool change and spindle running
[10:54:17] <robin_z> just need some CAT40 tool holders now
[10:54:35] <anonimasu> nice
[10:54:54] <robin_z> 6000 rpm and smooth as silk
[10:56:53] <anonimasu> nice
[10:56:54] <anonimasu> :)
[10:56:56] <alex_joni> hcseb: yeah, you can probably add a new group
[10:57:07] <alex_joni> but that means adding a bit more code
[10:57:36] <anonimasu> hey alex ltns
[10:57:45] <archivist> robin_sz, yes the town "pong" is bovril/marmite as well as beer
[10:58:36] <robin_z> archivist, yeah I know ... im in the midlands too
[10:58:48] <archivist> ok
[10:59:26] <alex_joni> anonimasu: ltns?
[10:59:51] <anonimasu> long time no see
[11:06:13] <anonimasu> :)
[11:20:19] <alex_joni> indeed
[11:20:22] <alex_joni> :P
[12:10:44] <skunkwokrs> skunkwokrs is now known as skunkworks
[12:24:02] <hcseb> Looks like the definitions of the emc M/G commands such as FLOOD_ON() and SET_MOTION_CONTROL_MODE() are in gcodemodule.cc
[12:24:38] <hcseb> This states at the start of the file that it's part of the AXIS front end
[12:25:58] <hcseb> I'm not totally clear what the link with Python is here - Is this coded in such a way that it can be incorporated into the Python program that is AXIS?
[12:26:26] <hcseb> And what about tkemc? That's the front end I am planning on using
[12:27:57] <jepler> hcseb: look again
[12:28:11] <jepler> there are several functions with the name FLOOD_ON in the emc2 source directory
[12:28:35] <jepler> AXIS uses gcodemodule to produce a preview plot from the gcode
[12:28:38] <hcseb> Oh, hang on - I didn't search quite right
[12:28:51] <hcseb> *nod* ok
[12:28:51] <jepler> FLOOD_ONemc/rs274ngc/gcodemodule.cc/^void FLOOD_ON() {}$/;"f
[12:28:51] <jepler> FLOOD_ONemc/sai/saicanon.cc/^void FLOOD_ON()$/;"f
[12:28:51] <jepler> FLOOD_ONemc/task/emccanon.cc/^void FLOOD_ON()$/;"f
[12:29:09] <hcseb> I did notice it was a no-op
[12:29:46] <jepler> the copy you're looking for is probably the one in emccanon.cc
[12:30:41] <jepler> (those lines I pasted above are from the "tags" file produced by "make tags"; certain editors such as emacs and vim can use tags files to go to the definition of functions)
[12:32:14] <hcseb> jepler: emccanon.cc looks like the right file
[12:44:12] <hcseb> How does EMC communicate with the HAL? Does it use rtai shared memory?
[12:45:34] <skunkworks> jepler: http://www.cnczone.com/forums/showthread.php?t=22101&page=18
[12:47:09] <jepler> hcseb: the userspace portions of emc (including the gui, task, and io) communicate using NML messages. Task communicates with the realtime portion of emc (motion) using RTAPI shared memory, which probably uses RTAI shared memory on your system.
[12:47:27] <jepler> hcseb: io and motion export HAL pins
[12:48:35] <hcseb> Right - io and motion are hal components. Is task a hal component also?
[12:48:43] <jepler> no, I don't think task is a HAL component
[12:48:45] <alex_joni> hcseb: no, task is not a hal component
[12:48:49] <hcseb> No - task is a userspace part
[12:48:53] <alex_joni> task talks only NML stuff
[12:48:56] <hcseb> as jepler said
[12:49:01] <alex_joni> io is a userspace component
[12:49:07] <alex_joni> but it does export hal pins
[12:49:17] <alex_joni> so userspace/realtime is not a real boundary for HAL
[12:49:22] <hcseb> I see
[12:49:26] <hcseb> That's useful to know
[12:49:37] <alex_joni> but NML/HAL are completely different things
[12:49:54] <hcseb> Hang on - what does NML stand for?
[12:49:55] <alex_joni> NML is a message library, where the components that talk to each other can be on different PCs
[12:49:57] <jepler> you'd probably have io create the pins related to the tool clamp--right now io also generates the HAL signals for toolchange operations.
[12:50:03] <alex_joni> neutral message language
[12:50:24] <hcseb> alex_joni: thanks
[12:50:27] <alex_joni> hcseb: components that talk NML are: GUI, task, iocontroller, motion interface
[12:50:42] <jepler> NML sends messages (such as "jog +1 inch in X axis" or "begin running the g-code program"). No part of NML is real time.
[12:50:42] <alex_joni> actually motion interface is part of task
[12:51:15] <alex_joni> hcseb: starting from these facts, one can for example run more than one GUI
[12:51:24] <alex_joni> even on different computers
[12:51:32] <jepler> HAL sends values (such as "the position of the X axis motor should be 1.0 inches" at the present moment) and some parts of HAL are real time so that the position of each motor can be controlled accurately over time
[12:51:55] <hcseb> Right. Indeed, I already have 2 guis runnign with our machine - one is tkemc and the other is a pyvcp that I built up for testing
[12:52:43] <hcseb> Which component reads, and then executes the RS274 codes? Is that task?
[12:53:59] <alex_joni> hcseb: yes, sorta
[12:54:19] <alex_joni> the interpreter is a component by it's own (rs274ngc folder) but it gets linked into task
[12:54:30] <alex_joni> and it gets run by task n-times / second
[12:56:33] <hcseb> What I'm trying to get at is this: When the interpreter comes across my M code M22, I need to switch a HAL pin (actually 2 HAL pins) high to activate the clamps.
[12:57:11] <alex_joni> well.. it works like this
[12:57:23] <anonimasu> ^_^
[12:57:26] <cradek> there's already support for motion-synchronized digital outputs
[12:57:29] <alex_joni> GUY sends NML message to run g-code
[12:57:34] <hcseb> But which component actually carries that out? And how, programmatically, do I achieve the equivalend of halcmd setp sig 1
[12:57:44] <cradek> so you wouldn't *have* to change anything except your gcode
[12:57:53] <alex_joni> task receives that NML and runs the interp
[12:58:06] <alex_joni> interp reads the file and sets up a queue with CANON calls
[12:58:25] <alex_joni> (calls for LINEAR_FEED(), calls for DIO() etc)
[12:58:32] <alex_joni> depending on your g-code
[12:58:49] <alex_joni> then task reads the queue and dispatches those CANON calls to either motion or IO
[12:59:02] <alex_joni> the IO stuff gets sent as NML messages to the iocontroller
[12:59:10] <alex_joni> and the iocontroller sets/resets HAL pins
[12:59:26] <alex_joni> the stuff that goes to motion gets sent through SHM to the motion controller
[12:59:47] <alex_joni> which does it's magic and in the end sets/resets/changes other HAL pins
[13:00:28] <alex_joni> hcseb: that's just an overview picture..
[13:00:50] <alex_joni> but as cradek said.. it might be easier to write a converter program which replaces M22 with M40P1 M40P2
[13:01:27] <hcseb> alex_joni: That's very helpful thanks!
[13:01:32] <cradek> (if you use the AXIS gui, you could do that translation automatically with a simple input filter)
[13:02:24] <alex_joni> that's actually M62,63,64 and 65
[13:03:20] <hcseb> group 5 = {m62,m63,m64,m65} - turn I/O point on/off
[13:03:34] <alex_joni> hcseb: right
[13:03:44] <alex_joni> iirc you have 10 IOs available
[13:03:57] <jepler> I thought it was a smaller number like 4
[13:04:04] <alex_joni> jepler: hmm..
[13:04:35] <hcseb> An I/O point being any digital i/o line on your machine?
[13:04:49] <hcseb> Why 4 mcodes there?
[13:05:33] <jepler> in theory there are two different kinds of digital I/O: synchronized to motion, and not synchronized to motion
[13:05:41] <jepler> in practice I think you only want one kind
[13:05:52] <jepler> for each type there's one code to set the pin to TRUE and one code to set it to FALSE
[13:06:04] <jepler> I a mm pretty sure this is in the gcode manual..
[13:06:27] <hcseb> I'll just look
[13:08:22] <hcseb> Yes. There it is in the User manual. What does it mean to turn on/off synched with motion?
[13:08:37] <alex_joni> that means it will be turned on when the motion starts
[13:08:56] <alex_joni> sets a DIO pin
[13:08:57] <alex_joni> this message goes to task, then to motion which sets the DIO
[13:08:57] <alex_joni> when the first motion starts.
[13:08:57] <alex_joni> The pin gets set with value 1 at the begin of motion, and stays 1 at the end of motion
[13:09:04] <hcseb> Ok - like the next programmed motion block in the rs274 codes?
[13:09:40] <hcseb> I think I need to retain the maximum flexibility over the clamping
[13:10:00] <alex_joni> jepler: it seems your memory is better than mine
[13:10:06] <alex_joni> suit your needs) */
[13:10:06] <alex_joni> #define EMCMOT_MAX_DIO 4
[13:10:21] <alex_joni> * number of motion synched DIO's supported (increase this value to
[13:10:21] <alex_joni> suit your needs) */
[13:10:26] <hcseb> Plus it'll be useful to get to know the emc internals, because I will certainly need to hack it to get our TDK1000 machine to work.
[13:11:00] <anonimasu> hcseb: then it should be motion synchronized..
[13:18:00] <CIA-2> 03alex_joni 07TRUNK * 10emc2/src/po/es_axis.po: Spanish translation by Medardo Torres
[13:18:22] <alex_joni> bbl
[13:18:32] <hcseb> Bye alex_joni
[13:25:31] <hcseb> anonimasu: Why is that?
[13:28:03] <anonimasu> hcseb: would suck to have your clamps get losened in the middle of a program run
[13:28:54] <hcseb> This is true.
[13:29:59] <anonimasu> if you have them synchronized with motion the machine needs to be where you commanded before executing the line
[13:31:06] <hcseb> Right. But my main concern is to reproduce the behaviour of the old Sinumerik CNC. Note that there are independed in-feed and out-feed clamps on this machine
[13:31:25] <hcseb> s/independed/independent
[13:32:03] <anonimasu> is this feedrate clamps?
[13:32:29] <hcseb> material clamps - this is a plate steel driller/flame cutter
[13:32:36] <anonimasu> yeah..
[13:32:53] <anonimasu> in_feed/out_feed dosent make sense to me
[13:33:14] <hcseb> the plate goes in the infeed side, the hold-down clamp clamps it down and the in-feed clamp comes down to bring the in-feed X position encoder into contact wit hthe matieral
[13:34:10] <hcseb> The material then gets processed into the machine, the drills are drilled, then the now drilled plate gets progressed through the out-feed clamp, which clamps down prior to the plate being cut off
[13:34:28] <hcseb> So, it's quite specific to this machine.
[13:34:30] <anonimasu> well, that
[13:34:34] <anonimasu> that's still motion synchronized :)
[13:35:26] <hcseb> It is still motion synchronized, you're right. But I'm happy to trust the program writer to not lift the clamps in the middle of the program
[13:38:21] <jmkasunich> hcseb: theres something not being explicitly mentioned about motion sync'ed I/O
[13:38:48] <jmkasunich> there is a motion queue in EMC, to allow the non-realtime interpreter to work ahead of the hard realtime motion controller
[13:39:02] <cradek> whoah, it's jmk
[13:39:09] <jmkasunich> non-synced I/O might (would) get executed when interpreted
[13:39:19] <jmkasunich> not good if there are several moves in the queue and one in process
[13:39:22] <anonimasu> jmkasunich: you put what i thought in words ;)
[13:39:30] <cradek> jmkasunich: I don't think it works that way
[13:39:36] <jmkasunich> synced I/O is placed in the queue and executed in sequence
[13:39:46] <cradek> jmkasunich: I think they all drain the queue
[13:39:49] <anonimasu> actually if you stick a custom "M" command into the dir.. it executes when it's being told to..
[13:40:09] <anonimasu> I did that with the torch on on my oxyfuel table..
[13:40:20] <jmkasunich> ok, then what IS the difference between synced and non-synced I/O?
[13:40:57] <cradek> I think one was intended to be queued with the motions, so motion doesn't have to stop/drain to run it at the right time -- this isn't in there yet
[13:41:29] <skunkworks> someone took today off... :)
[13:41:30] <anonimasu> cradek: ah
[13:41:33] <jmkasunich> someone did
[13:41:34] <cradek> currently, I think they all cause a queue drain and execute at the right time
[13:41:38] <anonimasu> skunkworks: damn you ;)
[13:41:58] <skunkworks> anonimasu: not me. ;)
[13:42:02] <jmkasunich> actually I took 6 days off - 10 if you count weekends ;-)
[13:42:30] <skunkworks> but your going to have to start driving today ;)
[13:42:33] <jmkasunich> CNC workshop is next week, today is "cut the grass, visit HGR surplus, load the truck, do errands, pack, etc"
[13:42:41] <jmkasunich> driving tomorrow
[13:43:21] <cradek> jmkasunich: what time do you think you'll get there?
[13:43:28] <jmkasunich> depends on what time I leave ;-)
[13:43:34] <jmkasunich> and its too early to decide that
[13:44:05] <jmkasunich> IF i get everything loaded tonight, and go to sleep at a reasonable hour, I might leave around 9am and arrive 6pm-ish
[13:44:24] <jmkasunich> if I don't I might leave at noon and arrive at 9pm
[13:44:32] <skunkworks> how accurite would this proccess be for machining telescope mirrors? (I wonder)
[13:44:33] <skunkworks> http://www.cnczone.com/forums/showthread.php?p=306481#post306481
[13:45:11] <cradek> I'm hoping for 'daylight' arrival but that's all I care
[13:47:07] <jmkasunich> my 3 hour window is about 2/3 daylight I think
[13:47:59] <jmkasunich> cradek: regarding the synced I/O thing, I can't think of a reason why I/O should NOT be queued
[13:49:01] <lerman_> lerman_ is now known as lerman
[13:49:46] <anonimasu> jmkasunich: agreed
[13:53:49] <hcseb> Thanks for all the comments folks.
[13:54:06] <jmkasunich> * jmkasunich puts "review synced I/O" on the CNC workshop to-do list
[13:56:56] <hcseb> If I'm happy to change my g and m codes, then the easiest way to do all this is going to be user defined M codes. I don't think I have any G codes to add to EMC.
[13:57:35] <hcseb> I had a chat with the machine owner and he is happy to change the scripts and programs to replace M22 with M122 M23 with M123 etc.
[13:57:58] <hcseb> That way I can just call halcmd lines in scripts
[13:58:18] <jmkasunich> that seems the simplest way
[13:58:32] <hcseb> Yes, but somehow not as fun ;)
[13:59:00] <jmkasunich> custom M codes accept parameters as well: M123 P3.5 for example (don't know if thats needed or not)
[13:59:38] <hcseb> I don't think so - these are very simple command - e.g M80 is gas and oxygon on and M82 is gas and oxygen off.
[13:59:47] <hcseb> No parameters at all
[13:59:50] <jmkasunich> ok
[14:01:05] <jmkasunich> is there any feedback? is it M80 "turn the bits on and carry on immediately", or "turn the bits on and wait for flow to be detected" ?
[14:04:21] <cradek> jmkasunich: yeah, doing IO at readahead time is surely useless
[14:06:06] <jmkasunich> so the real distinction is between "flush the queue, wait for motion to stop, execute this I/O command, resume motion" and "execute this I/O command instantly between the move that precedes it and the one that follows it, without stopping" (to be precise, that would be at the midpoint of the blend between the two moves)
[14:06:40] <cradek> that's my understanding, but it's a distinction we probably don't need
[14:07:07] <cradek> if you need pauses, use G4 - if you need exact stop, use G61 or whatever it is
[14:07:15] <jmkasunich> right
[14:07:20] <jmkasunich> actually, I/O is a misnomer
[14:07:24] <cradek> right
[14:07:25] <cradek> it's O
[14:07:26] <jmkasunich> we are talking about "O" only
[14:07:41] <cradek> and it should support analog "O" too, but it doesn't
[14:07:49] <jmkasunich> that can be fixed I think
[14:07:52] <cradek> sure
[14:08:22] <cradek> M5x Px Qd.dddd
[14:08:41] <jmkasunich> cradek: changing the subject - I'm gonna update the wiki for 2.1.6 - the changes come from debian/changelog, right?
[14:08:46] <cradek> yes
[14:08:56] <cradek> I didn't even send the email I usually do
[14:09:13] <cradek> there were only a few changes
[14:09:24] <cradek> I'll go do that
[14:10:28] <hcseb> jmkasunich: The M80 command does need some feedback, because if you get no FLAME signal, then you need to switch off the gas
[14:10:54] <hcseb> So I probably need a little torch hal component.
[14:11:03] <cradek> that sounds easy to do with ladder
[14:11:07] <jmkasunich> and I assume you want to stop the g-code execution and yell for the operator, right?
[14:11:34] <hcseb> Yes, but be able to re-light the torch and continue on from where we left off
[14:11:41] <jmkasunich> the logic is easy, in either ladder or a custom HAL comp
[14:11:58] <hcseb> <- prefers hal component
[14:12:03] <jmkasunich> If your custom M code doesn't return until the torch is lit, I think the g-code will simply stop
[14:12:17] <jmkasunich> I'm more familiar with the low level end of things though, HAL and motion
[14:12:33] <hcseb> Yes, but the flame might go out half way through cutting
[14:12:33] <jmkasunich> trust cradek and alex and others more than me for higher level stuff
[14:12:37] <jmkasunich> ah
[14:12:43] <hcseb> *nod(
[14:12:44] <jmkasunich> there is a HAL pin for feed-hold
[14:13:03] <jmkasunich> you could have your torch comp yank on that if the fire goes out
[14:13:59] <jmkasunich> and alert the user thru a pyvcp indicator
[14:14:07] <hcseb> I agree with cradek btw - if your machine needs to specifically pause, then allow the programmer to put the right pause in with G4
[14:14:23] <hcseb> Would G04 be interpreted as G4?
[14:14:26] <cradek> yes
[14:14:35] <jmkasunich> then the operator can use a pyvcp button to tell your comp that the torch has been re-lit, and it will release feedhold
[14:14:47] <hcseb> jmk: Sounds good.
[14:15:06] <cradek> any whitespace, leading zeroes, leading +/- are allowed by the emc interpreter
[14:15:13] <hcseb> I found pyvcp pretty easy to use to set up a "do anything" control panel, by the way
[14:15:24] <hcseb> cradek: Great
[14:15:40] <jmkasunich> pyvcp is much nicer than the original vcp
[14:15:42] <jepler> even crazy things like G[2*2] are accepted
[14:15:54] <jepler> and for some number of zeros, so is G4.000001
[14:16:03] <jepler> but don't write any of those things, ever -- okay?
[14:16:06] <cradek> haha
[14:16:09] <hcseb> jmk: Apart from the unfortunate ugliness of the toolkit
[14:16:14] <skunkworks> ;)
[14:17:04] <jmkasunich> well, my original halvcp used the GTK widgets, which aren't exactly beautiful either
[14:17:09] <jmkasunich> and it had a much smaller set of widgets
[14:17:15] <cradek> no widgets are beautiful
[14:17:32] <cradek> fortunately there's no need for beauty either
[14:17:59] <hcseb> GTK ones are pretty clean looking in my opinion. However, I'm not sure how easy it would be to create the dials and what have you that you can get with pyvcp
[14:18:12] <jmkasunich> small matter of programming
[14:18:33] <jmkasunich> but I'm not a GUI programmer, I tend to slog thru the bare minumum and then go back to low level stuff
[14:18:52] <jmkasunich> others (I think it was anonimasu actually) started pyvcp and made it much more complete
[14:18:53] <hcseb> I do a fair amount of gui programming with GTK
[14:19:14] <hcseb> But haven't had to deviate from the standard set of GTK widgets
[14:19:22] <jmkasunich> if you want to play with a GTK based version of vcp, its in the source tree
[14:19:41] <hcseb> I'd prefer to create a gtkvcp which read the same xml file as pyvcp
[14:19:55] <hcseb> Because that is a good scheme
[14:20:05] <jmkasunich> yeah
[14:20:24] <hcseb> But that's a secondary thing at the moemnt - I still need to get our machine working!
[14:20:29] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/user_comps/vcp/
[14:20:44] <jmkasunich> if you care to look at it, or use parts of the code
[14:20:47] <hcseb> Waiting on some logic chips to come from TI before I can test the X encoders :(
[14:20:59] <jmkasunich> line receivers or such?
[14:21:05] <hcseb> *nod*
[14:21:24] <hcseb> Old TTL things, which have 5 to 10 day lead times
[14:25:40] <skunkworks> jmkasunich: have you run across speed controls that use step and direction input? (mach uses them)
[14:25:53] <jmkasunich> no
[14:25:59] <jmkasunich> but I'm hardly an expert on speed controls
[14:26:27] <jmkasunich> if you mean motor drives (industrial style), then step-dir is unheard of
[14:26:48] <hcseb> What's PROGRAM_PREFIX for the ubuntu install of EMC2? That is, where do I place my M123 executable?
[14:26:49] <jmkasunich> control is by analog input, or by some form of networking
[14:27:18] <jepler> hcseb: PROGRAM_PREFIX is specified in the .ini file
[14:27:28] <jepler> hcseb: it can be whatever you like
[14:27:37] <hcseb> Oh, right, thanks jepler
[14:28:04] <jmkasunich> I think the sample configs use the nc_files directory
[14:28:27] <jmkasunich> find found these:
[14:28:28] <jmkasunich> ./nc_files/M101
[14:28:28] <jmkasunich> ./nc_files/M102.c
[14:28:56] <skunkworks> jmkasunich: http://www.cnczone.com/forums/showpost.php?p=306119&postcount=11
[14:29:12] <skunkworks> I need to find some info - seems like it could be done with emc.
[14:29:32] <jepler> he can't mean 500MHz
[14:29:54] <jmkasunich> I think he means he has a 500MHz pc
[14:30:08] <jepler> oh that makes a bit more sense
[14:30:36] <jmkasunich> skunkworks: if the spindle drive just needs a stream of step pulses at some constant frequency, then EMC can do that easily
[14:31:02] <jmkasunich> freqgen (old) or stepgen in velocity mode (new) accepts a velocity instead of a position, and generates steps
[14:31:14] <jepler> 20*25400 / minute is under 9kHz.. doesn't sound too taxing
[14:31:18] <jmkasunich> I dunno offhand which is in 2.1.x
[14:31:25] <jepler> jmkasunich: freqgen for 2.1.x
[14:31:37] <jmkasunich> jepler: thanks
[14:31:41] <jepler> stepgen velocity mode is only in TRUNK, so users will get it in 2.2.
[14:32:40] <skunkworks> I will see if I can find some more info on these step and dir spindle drivers. (seems odd)
[14:32:43] <skunkworks> :)
[14:32:48] <skunkworks> but whatever works
[14:33:12] <jmkasunich> handy if you want to do rigid tapping or indexing or spindle-orient
[14:33:50] <archivist> step and dir for indexed milling on a turning machine
[14:33:54] <skunkworks> No - I don't think it works that way.
[14:34:12] <skunkworks> I think it uses the step and direction just for speed and direction.
[14:34:25] <skunkworks> It acutally runs a dc motor.. or such
[14:35:05] <jmkasunich> oh, no encoder or anything....
[14:36:00] <skunkworks> http://www.campbelldesigns.com/spindle%20speed%20control%20doc.pdf
[14:36:03] <skunkworks> like this
[14:36:03] <cradek> like step/dir to run a stepper motor that turns the speed knob, but with no knob
[14:36:10] <cradek> or stepper motor
[14:36:31] <cradek> (sounds like an odd hack to me)
[14:36:39] <jmkasunich> what cradek is describing would have "homing" issues I would think
[14:36:45] <cradek> yep
[14:36:49] <skunkworks> another machism
[14:37:53] <skunkworks> bbiab
[14:38:46] <jmkasunich> from reading that doc, I think the board is a step-frequency to voltage converter
[14:39:13] <jmkasunich> cradek described a step-count to voltage converter
[14:40:35] <cradek> I didn't really understand the doc - it's a bit short of real information
[14:43:56] <hcseb> Do you return -1 on error for a user defined M code?
[14:45:33] <cradek> I'm not sure the return code is checked - check the source to be sure I guess
[14:45:40] <hcseb> OK
[15:20:28] <x3rox> Can somebody tell me how important Realtime extensions to the kernel are? I would like to run a little stepper driven 3-axes mill, but I actually prefer SuSE Linux.
[15:22:31] <x3rox> Nobody here?
[15:23:01] <archivist> well you dont want a movement to be delayed by a separate application as the machine is moving in real time
[15:23:33] <archivist> and have some patience in irc
[15:23:44] <archivist> its not real time
[15:24:08] <x3rox> archivist: Sorry for my impatience. Begg yor pardon.
[15:24:39] <skunkworks> it is important - expecially with steppers. You need a pulse train that is 'perfect' or close to it or the steppers will stall
[15:26:08] <x3rox> Oh, I see. Is it difficult to add RealTime to openSuSE 10.2? (I do not like Ubuntu, especially with Gnome desktop, and I nowhere read about kubuntu...)
[15:27:11] <skunkworks> I think you can run kubuntu just fine with emc.. Using the dapper ubuntu. (but others will have to confirm that )
[15:28:12] <x3rox> But Ubuntu is the only one which is favorized?
[15:31:09] <x3rox> Ok ... I will try it with Ubuntu first. :-/
[15:32:14] <skunkworks> yes - because dapper is lts - long term support
[15:34:45] <x3rox> skunkworks: Could you, please, help me to choose which soft I will need? I currently do not have my own mill, but I want to prepare because I am expecting one in next time.
[15:35:20] <x3rox> I actually want to draw in AutoCAD (at the first time) and then mill in 2.5D.
[15:37:26] <skunkworks> I have used ace conveter http://www.dakeng.com/ace.html that takes dxf and converts to gcode
[15:38:06] <skunkworks> http://timeguy.com/cradek/autocad has a autolisp routine also.
[15:38:29] <x3rox> I also read about an autolisp module for that. Any experiences with that?
[15:38:39] <skunkworks> not personally
[15:40:29] <x3rox> This ACE converter sounds good but appears to run on the Windows side. Is something available for Linux, too? (I want to get away from Win as quick as possible. It's hard enough to run AutoCAD in a virtual machine...)
[15:42:06] <skunkworks> I am not farmiliar with anything on the linux side. But I would think cradeks realize would work within acad in the virtual machine.
[15:45:36] <The_Ball> hey skunkworks how's it going, finally got the servos going by emc control
[15:45:44] <x3rox> I was just browsing through the ACE manual and wondered that they don _not_ recommend polylines and do recommend Acad12 DXF files. How to tell that AutoCAD R14? I normally use polylines to keep moving paths together. And this is not allowed?
[15:52:33] <x3rox> skunkworks: Does the Ubuntu ISO contain some software for visualizing a CNC mill? (to see how it would work on the screen)?
[15:53:08] <skunkworks> EMC2 has the axis interface - this has a preview of the cutter path
[15:53:20] <skunkworks> The_Ball: cool - how is it running?
[15:53:54] <skunkworks> x3rox: http://www.electronicsam.com/images/KandT/axisubuntu.pn
[15:53:55] <skunkworks> like this
[15:54:25] <The_Ball> um, extremely? it scared me a bit, did some calculations, it's capable of 300+ipm, but the screw starts vibrating/slapping at about 100ipm
[15:54:43] <skunkworks> yee haw. ;)
[15:54:57] <The_Ball> the whole floor vibrates, hehe
[15:55:08] <skunkworks> video?
[15:55:43] <x3rox> skunkworks: Today I found an email from the mailing list about a new release 2.1.6. Is this one already in the downloadable ISO, or must I wait?
[15:56:21] <skunkworks> You can download the iso - then you can do an update to get the latest version of emc.
[15:56:27] <x3rox> skunkworks: The above link results in a blank white screen.
[15:56:43] <skunkworks> thru the update manager in ubuntu
[15:57:12] <skunkworks> http://www.electronicsam.com/images/KandT/axisubuntu.png
[15:57:14] <skunkworks> sorrry
[15:58:00] <anonimasu> hm
[15:58:02] <anonimasu> * anonimasu is happy
[15:58:12] <anonimasu> im finally able to machine some parts for myself :D
[15:58:23] <skunkworks> anonimasu: yay :)
[15:58:27] <anonimasu> a mounting bracket for my home sensor
[15:58:33] <anonimasu> (im at work playing with the big mill)
[15:58:41] <anonimasu> brb
[15:59:07] <x3rox> I am so afraid to run into troubles... :-| (I will get a damaged VX92 mill. Electronics totally dead. But as far as I know, steppers are really hard to kill. Do you know this mill from Gravotech?)
[16:01:20] <x3rox> picture is here: http://www.hantsch.co.at/_temp/VX92.bmp
[16:01:39] <The_Ball> skunkworks, i will make a video tomorrow when i get the x axis mounted as well, here's a picture of the second servo mounted: http://wigen.net/servo.jpg
[16:01:54] <The_Ball> it's a piece of 100x100x3 box steel
[16:02:37] <The_Ball> solid as a rock, but i haven't got a flexible coupling yet, so i used some flexible pvc tubing, which it almost tore to shreads
[16:03:00] <x3rox> My plan is to build my own driver board and insert it into this mill, then control it with EMC. Should be fine for milling enclosures and so?
[16:04:27] <skunkworks> The_Ball: very nice.
[16:05:03] <skunkworks> x3rox: I would think so.
[16:05:23] <x3rox> The_Ball: Is this mill for hobby or commercial usage?
[16:05:30] <The_Ball> x3rox, steppers are hard to kill, only thing is to much current can burn the windings. are you sure they are steppers and not servos?
[16:06:25] <x3rox> I asked the technicians, they said this machine has steppers, but it is long long ago that they saw one...
[16:06:25] <The_Ball> x3rox, hobby use, but if i can make some niche parts i which i can combine hobby with business i will do that
[16:06:38] <skunkworks> you could look at this driver. cradek has had good luck. http://timeguy.com/cradek/cnc/stepper-drivers
[16:06:48] <cradek> I think those aren't steppers
[16:08:06] <x3rox> cradek: You mean the VX92 doesn't have steppers?
[16:08:26] <cradek> err, are you talking about this? http://wigen.net/servo.jpg
[16:08:34] <cradek> sorry I'm probably not keeping up
[16:09:32] <jepler> x3rox: to install emc2 updates, use the ubuntu update manager. http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?InstallingUpdates
[16:09:32] <x3rox> No. What I attempt to do is 10 times smaller... See link above. www.hantch.co.at/...
[16:10:08] <cradek> ah whoops
[16:10:29] <cradek> I can't view your bmp
[16:10:49] <x3rox> cradek: http://www.hantsch.co.at/_temp/VX92.bmp ?
[16:11:23] <cradek> http://timeguy.com/cradek-files/emc/proprietary-image-format.png
[16:12:19] <The_Ball> skunkworks, is http://www.electronicsam.com/ your site?
[16:12:31] <skunkworks> yes
[16:12:45] <The_Ball> what kind of machine is this? http://www.electronicsam.com/images/KandT/zaxis.JPG
[16:12:58] <The_Ball> looks awsome
[16:14:27] <jepler> cradek: wfm. http://emergent.unpy.net/files/sandbox/VX92-1.bmp.jpg
[16:14:28] <skunkworks> Thanks - works pretty good
[16:14:56] <x3rox> cradek: Whow. -- I love Windoze... (one mailed the picture to me from his Windoze). I converted it now into PNG. Try this http://www.hantsch.co.at/_temp/VX92.png
[16:15:06] <x3rox> Wait a bit!
[16:15:07] <cradek> aha, thanks guys
[16:16:33] <The_Ball> skunkworks, what kind of accuracy do you get from that big machine?
[16:16:49] <skunkworks> * skunkworks was too slow
[16:17:06] <skunkworks> which big machine? the horizontal mill?
[16:17:19] <The_Ball> the one in the zaxis image
[16:18:18] <skunkworks> ah - it as been close enough for what it has been used for. I would say for light stuff it is +/- .001
[16:18:24] <skunkworks> inch
[16:18:44] <anonimasu> :/
[16:18:56] <The_Ball> do you use it for plugs and stuff like that?
[16:18:56] <archivist> Acad has broken dxf sometimeskinda good for chains?
[16:19:17] <anonimasu> my part turned out good
[16:19:25] <anonimasu> though I forgot to make 2 nice chamfers on it :)
[16:19:33] <archivist> kinda good for chains?
[16:20:00] <anonimasu> bbl..
[16:20:02] <anonimasu> going home
[16:20:03] <x3rox> cradek: Ok, meanwhile you already got it (and I stored it now, too). What do you think about this mill?
[16:20:52] <skunkworks> archivist?
[16:21:11] <cradek> it's hard to tell anything from the picture... in fact I don't quite see how it moves
[16:21:30] <archivist> I sort of expected a chain to add some error
[16:22:04] <skunkworks> I guess I don't understand what you mean by chain.
[16:22:12] <skunkworks> oh - chain
[16:22:22] <cradek> chain!
[16:22:25] <skunkworks> my chain?
[16:22:36] <archivist> in tyes
[16:22:41] <archivist> yes
[16:22:48] <cradek> I think he's talking about the part of it that looks chain-like
[16:23:01] <x3rox> cradek: Bridge is static. Z-axis moves left/right on the bridge, while the workpiece moves in 90° to the bridge. Shall have a working area of ~350x400 mm.
[16:24:00] <cradek> ok, I didn't guess it was that big
[16:24:25] <cradek> I bet it's steppers
[16:24:28] <cradek> what are you going to cut with it?
[16:24:40] <skunkworks> Z seems to be the most accruite (plus it is the most geared down 'plus' it uses gravity and inti-backlash ;))
[16:25:38] <The_Ball> yeah, i need to do some serious anti backlash work on my mill. i want to mill some pcb's (mcb..)
[16:25:39] <robin_sz> meep?
[16:25:50] <x3rox> cradek: Yes. They said so. I want to primarily cut plastc cases, PCB boards, maybe "soft metal".
[16:26:01] <cradek> nice
[16:26:07] <cradek> do you know what kind of screws it has?
[16:26:41] <x3rox> cradek: Trapec spindles.
[16:27:14] <robin_sz> trapec?
[16:27:23] <robin_sz> trapezoidal ...??
[16:27:35] <cradek> I don't know that word either
[16:27:35] <x3rox> cradek: Yes. Thats the right word.
[16:27:55] <cradek> sounds like acme
[16:28:04] <x3rox> ?
[16:28:04] <robin_sz> trapezoidal is not acme
[16:28:11] <cradek> wonder if it has any kind of backlash compensation
[16:28:15] <robin_sz> acme is square cut
[16:28:31] <robin_sz> trapezoidal is like a normal screw thread
[16:29:38] <x3rox> Don't know. I only can hope that it hasn't worked too much in its life... But it has a resution of 0.015mm, so this should be fine even with backlash. (Hope there is a way to adjust it.)
[16:29:52] <robin_sz> hah
[16:30:58] <x3rox> trapezodial is almost square cut, but with slightly angled sides. Like this: _/^\_/^\_
[16:31:14] <robin_sz> "a resolution of 0.15mm" ... doesn't actually mean anything .. it jusrt means " the steppers need 66.7 steps to move one mm" .. nothing more
[16:31:37] <robin_sz> yeah, like a normal screw thread
[16:31:53] <x3rox> Yes. But if I get 0.035 including backlash, I am happy. This is what cheap mills often have a snew.
[16:32:22] <robin_sz> * robin_sz guesses .5mm as more likely
[16:32:57] <The_Ball> x3rox, there is no correlation between resolution and backlash
[16:33:14] <robin_sz> quite
[16:34:11] <x3rox> robin_sz: Possibly a little bit finer. I can tell you when I have the machine in hands. I will carefully test backlash and look for adjusting possibilities. Is this machine (including the spindle and spindle motor, steppers,...) ok for ~ 1000,-- Euros?
[16:34:42] <archivist> * archivist is amused by accuracy==resolution idiots
[16:35:19] <x3rox> archivist: I know what is meant.
[16:35:36] <archivist> you do but there are some
[16:35:44] <x3rox> :D
[16:35:44] <robin_sz> x3rox, 1000 euros .. cheap enough I guess .. just expect it to be flimsy .. I know what they are normally used for
[16:36:09] <x3rox> what means filmsy?
[16:36:21] <robin_sz> not rigid
[16:37:04] <x3rox> Yes. But I do not want to cut steel.
[16:37:36] <robin_sz> basically, they are normally used for making name badges in 3 layer plastic
[16:38:13] <The_Ball> oh that reminds me, i have to find a way to get a hold of layered plastic
[16:38:29] <robin_sz> any signmakers supplies
[16:39:04] <x3rox> Exactly. I think about cutting plastic enclosures for my self built electronics, PCBs and such things, so this will not need much different cutting forces?
[16:39:16] <robin_sz> should be ok
[16:40:09] <x3rox> I know, stronger would be possibly be better, but this also costs much more.
[16:40:33] <robin_sz> 1000 euros would build a better one
[16:40:53] <robin_sz> but .. prebuilt, thats a fair price for what it is
[16:41:09] <x3rox> robin_sz: Including all 3 axes steppers + spindle + spindle motor?
[16:41:18] <robin_sz> sure
[16:41:30] <The_Ball> robin_sz, im trying to ebay for that plastic, do you know a "official" name for it?
[16:41:35] <x3rox> For how much?
[16:41:49] <robin_sz> 1000 euros would build a better one
[16:42:03] <x3rox> Where is your location?
[16:42:08] <robin_sz> eu
[16:42:40] <x3rox> could you be a little bit more precise? Maybe I please you to make me one? ;-)
[16:43:02] <robin_sz> UK, and no thanks ..
[16:43:06] <x3rox> =D
[16:43:24] <x3rox> Hah -- I knew your answer before you wrote it.
[16:43:25] <robin_sz> YOU could build a better one for 1000 euros in parts + your time for free
[16:43:45] <x3rox> I know. It's a horrible work.
[16:44:02] <x3rox> Therefore I prefer this used mechanics.
[16:44:09] <robin_sz> I could build a better one for 1000 euros in parts + my time for £35/hr
[16:44:35] <robin_sz> for a uused prebuilt machien, 1000 eur seems a good price for what it is
[16:44:44] <The_Ball> robin_sz, a x2 with conversion kit ready to go would be under 1000 euro i think
[16:45:11] <robin_sz> x2?
[16:45:21] <The_Ball> the taig x2 mini mill
[16:45:38] <robin_sz> thats MUCH smaller than this
[16:45:48] <The_Ball> oh
[16:46:00] <x3rox> Yes. For all ready cut aluminium profiles I got an offer for 800 euros. Plus spindles, plus steppers,... Wel, this will not finish for less than 1500,-- I guess.
[16:46:59] <robin_sz> http://www.quacky.co.uk/~robin/beaver.jpg
[16:47:05] <robin_sz> ^^ thats what you want :)
[16:47:14] <x3rox> cradek: Your breakout board is only for buffering the parallel port, right?
[16:47:25] <The_Ball> we all want beaver, oh wait
[16:48:00] <archivist> that beaver needs a shave
[16:48:05] <The_Ball> why is the head resting on wood blocks?
[16:48:08] <x3rox> robin_sz: Oh, what a nice toy! I'm afraid it will break through the floor...
[16:48:30] <robin_sz> The_Ball, the counterbalance is pneumatic ... it tends to drop down overnight
[16:49:04] <robin_sz> 18 station auto toolchange too ... $mate just bought it ...
[16:49:15] <robin_sz> 20hp spindle too
[16:49:18] <skunkworks> emc retrofit? ;)
[16:49:31] <The_Ball> ohhhhh, nice, so what's the plan with it?
[16:49:32] <robin_sz> nah, fully working Fanuc controller on it
[16:49:44] <robin_sz> The_Ball, making stuff
[16:50:12] <The_Ball> really, that's my plan as well
[16:50:38] <The_Ball> but my question was about emc, you wouldn't replace the fanuc i guess heeh
[16:50:40] <robin_sz> the Beaver stuff is very well built, loads more metal in it than the modern Haas machines
[16:51:08] <x3rox> cradek: Do you also have a schematic + board for stepper driver up to 2A?
[16:52:07] <robin_sz> x3rox, surely, that little mill has the stepper drives in it already?
[16:52:43] <The_Ball> robin_sz, he said above it's all fried
[16:52:58] <robin_sz> ahh, then 1000 euro is a bit on the expensive side
[16:53:00] <x3rox> It has - so I was told - a totally dead board.
[16:53:03] <robin_sz> new boards, new motors ...
[16:53:27] <x3rox> Oh no, I don't take it if the steppers are dead. Believe me.
[16:54:09] <robin_sz> well, I assumed it was all working for 1000 euro
[16:54:20] <robin_sz> non working ... 500 would be a fair price, maybe less
[16:55:01] <x3rox> I also think - therefore I asked - that 1000 is a little bit too much.
[16:55:12] <robin_sz> yeah
[16:55:14] <robin_sz> 800 maximun
[16:55:25] <robin_sz> 500 fair price
[16:55:28] <robin_sz> 400 bargain
[16:55:39] <robin_sz> 1000 if it was working
[16:56:13] <x3rox> 1000 if it was - or - if it _IS_ working?
[16:56:21] <robin_sz> is
[16:56:45] <robin_sz> 3 gecko drives will cost ... 400 euro
[16:56:48] <x3rox> Would help me nothing, because this machine is a closed system with no PC interface).
[16:57:02] <x3rox> But I will try to get it cheaper.
[16:57:20] <x3rox> what is a gecko drive?
[16:57:25] <robin_sz> ahh.
[16:57:31] <robin_sz> www.geckodrive.com
[16:57:45] <robin_sz> the best little stepper drive you can buy
[16:58:32] <x3rox> What do they cost? I don't thing I will need more then 2 Amperes?
[16:59:15] <x3rox> Oh! not very cheap?
[16:59:34] <skunkworks> ;) you really do get what you pay for... from what I hear.
[16:59:43] <x3rox> They work with direction/step interfacing?
[16:59:48] <skunkworks> yes
[16:59:49] <The_Ball> get the machine for 600 and you get the for "free" ;)
[17:00:29] <x3rox> Sounds good. Must see what I get the machine for.
[17:01:09] <x3rox> Which one would you take= G201 or G202, or ...
[17:01:25] <The_Ball> and you'll need to buy/build a power supply and maybe a parallel breakout board
[17:02:40] <x3rox> I hope that the power supply will have survived. If a mill has a transformer, the most expensive part will be there.
[17:02:50] <x3rox> ... of the power supply!
[17:04:23] <x3rox> About gecko drive: G201 does really 10-microsteps? Whow.
[17:08:09] <x3rox> Only for understanding: A stepper can be held at any microstep position, too, or is microstepping only for reducing noise and turning softer, while a stop is only possible after a full step is completed?
[17:13:09] <archivist> more smoothness, accuracy and holding torque drop off a bit on the in between steps
[17:15:25] <x3rox> So only if I use an pulse+direction driver I can do half-/quarter-/...steps, while the other stepper-driver (steptype=2) does only full steps. Right?
[17:23:53] <skunkworks> JymmmmEMC: did you end up gett ing the 750's?
[17:26:25] <JymmmmEMC> skunkworks: I emailed the guy asking if he'll give a NON-DOA guarntee. He said he bought them off ebay and has no way of testing them, so I said forget it.
[17:27:21] <skunkworks> aee
[17:27:22] <skunkworks> aww
[17:28:14] <JymmmmEMC> skunkworks: $250 for possible junk is not my cup of tea.
[17:28:25] <skunkworks> understood
[17:28:38] <JymmmmEMC> skunkworks: and why didn't he use them for himself is a bigger question.
[17:29:59] <skunkworks> probably going servo ;)
[17:30:30] <JymmmmEMC> maybe, but I think if you were going to sell it, you would have at least said that too.
[17:39:08] <The_Ball> night
[17:43:30] <lewin1> lewin1 is now known as lewing
[17:53:26] <anonimasu> hi
[17:53:41] <JymmmmEMC> hola
[17:53:52] <Skullworks-PGAB> yawn
[17:54:44] <anonimasu> what's up?
[17:54:47] <anonimasu> im playing guitar..
[17:55:02] <anonimasu> pondering machining a fork to lock the tremolo of this stupid guitar..
[17:55:14] <JymmmmEMC> Oh, THAT"S wy the dawgs are howling!
[17:55:26] <JymmmmEMC> Arooooooooooooooooooooooooooooooooooooooooooooooooooooo
[17:55:35] <Skullworks-PGAB> * Skullworks-PGAB can only play with the seek button on the CD player...
[17:55:57] <archivist> * archivist is glad irc is silent
[17:56:03] <anonimasu> heh
[17:56:06] <anonimasu> thanks
[17:56:44] <JymmmmEMC> archivist: no doubt
[17:57:31] <Skullworks-PGAB> maybe those other channels will keep you busy.
[17:58:23] <anonimasu> the problem with this guitar is that it loses the tuning after a while
[17:58:36] <JymmmmEMC> Arooooooooooooooooooooooooooooooooooooooooooooooooooooo
[17:59:46] <anonimasu> JymmmmEMC: I guess you are fucked when buying on ebay if you want guarantee.
[17:59:47] <anonimasu> :)
[18:00:25] <anonimasu> now all i have left is to machine a hole in the sensor mount..
[18:00:31] <anonimasu> machine/drill/tap
[18:00:33] <JymmmmEMC> anonimasu: Not really. Most things I buy they do offer a NON-DOA if nothign else.
[18:00:58] <anonimasu> why dont you just buy geckos?
[18:01:28] <anonimasu> I know we've been there before, but you'll be waiting forever ;)
[18:01:28] <JymmmmEMC> anonimasu: I probably will, but if I can save $300, why not.
[18:01:39] <anonimasu> certainly that's a good idea
[18:02:20] <Skullworks-PGAB> yeah price is the big barrier
[18:02:23] <JymmmmEMC> anonimasu: I'm still building out the PS and assoc circuity, so I have time before I'll need the drives.
[18:02:24] <anonimasu> aluminium is a mess when you have too little cooling.
[18:02:29] <anonimasu> :/
[18:03:07] <Skullworks-PGAB> those V203 suck the cash right out of your wallet
[18:03:09] <JymmmmEMC> Actually, I'm going to buy some aluminum plate today to mount everything on. Will look for 1/2" chunkc too
[18:03:27] <anonimasu> :)
[18:03:32] <anonimasu> I need to order that kind of stuff soon
[18:03:34] <anonimasu> im all out of plate
[18:03:56] <JymmmmEMC> Metal supermarket has a scarp bin area, I might get lucky.
[18:04:00] <anonimasu> :)
[18:04:13] <archivist> who runs cnczone.com I found a bum link
[18:04:28] <Skullworks-PGAB> another project - I'm building a furnace to melt down the AL scrap to pour my own tooling plates...
[18:05:03] <JymmmmEMC> I went in once to get a piece of precision ground steel. I told them I only needed 6", he cut it and when I asked how much, he said have a nice day.
[18:05:13] <anonimasu> :)
[18:05:40] <anonimasu> that's what we do for small stuff at work..
[18:06:01] <anonimasu> we usually ask customers to bring some cookies sometime..
[18:06:06] <JymmmmEMC> My machine is all al, I needed it so I could mount the DTI on
[18:07:36] <anonimasu> I need to make a new ballscrew mount for my Y axis..
[18:08:16] <JymmmmEMC> got chip brush?
[18:08:22] <anonimasu> yes
[18:08:32] <anonimasu> I have a vaccum..
[18:08:35] <anonimasu> too ;)
[18:08:37] <JymmmmEMC> long story, but use it!
[18:08:50] <anonimasu> heh, been machining aluminium?
[18:09:26] <JymmmmEMC> No, the fsckers I bought MY machine from like to forget to clear chips and machine not at right angles.
[18:09:37] <anonimasu> ah
[18:09:41] <anonimasu> idiots.
[18:09:56] <JymmmmEMC> I have four sets of mounts for my machine
[18:10:03] <anonimasu> :/
[18:10:13] <JymmmmEMC> only one set is straight.
[18:10:49] <anonimasu> I regret making this mount so simple..
[18:10:52] <anonimasu> I could have made it much cooler ;D
[18:11:00] <anonimasu> it's just a L with a slot..
[18:11:00] <JymmmmEMC> threaded?
[18:11:12] <anonimasu> ah the one i made today
[18:11:13] <anonimasu> that is
[18:11:16] <JymmmmEMC> oh, not 1/3" thick?
[18:11:16] <anonimasu> a home switch mount..
[18:11:18] <JymmmmEMC> 1/2"
[18:11:23] <anonimasu> 10mm thick..
[18:11:50] <JymmmmEMC> ew
[18:11:50] <anonimasu> with the bottom edged chamfered..
[18:11:55] <anonimasu> ew?
[18:12:06] <JymmmmEMC> oh switch mount, I thought you meant ballscrew
[18:12:10] <anonimasu> heh
[18:12:27] <JymmmmEMC> long adj slots I hope?
[18:12:43] <anonimasu> no just because i didnt have the CC for the holes..
[18:13:03] <JymmmmEMC> CC == Credit Card ?
[18:13:14] <anonimasu> Center to Center
[18:13:20] <JymmmmEMC> $29.95 per hole is all we ask =)
[18:13:21] <JymmmmEMC> ah
[18:13:36] <anonimasu> so I just made a long stupid slot that took 10 minutes to machine
[18:13:53] <anonimasu> 0.5 mm passes.
[18:14:07] <anonimasu> because I broke the cooling hoose at the big mill at work :)
[18:14:17] <JymmmmEMC> DOH!
[18:14:44] <anonimasu> not a big deal.. just less mess..
[18:14:57] <anonimasu> * anonimasu is scared of aluminium getting hot
[18:15:22] <skunkworks> you should be more scared of magnesium getting hot...
[18:15:45] <anonimasu> I dont machine magnesium
[18:16:11] <anonimasu> but yeah
[18:16:14] <JymmmmEMC> "remember kids.... Whenever you have magnesium on fire, ad LOTS AND LOTS of water!!!!" (and run like hell)
[18:16:18] <anonimasu> hot alu kills tooling.
[18:16:22] <anonimasu> HEH
[18:16:23] <anonimasu> yeah
[18:16:27] <anonimasu> I'd use sand.
[18:16:34] <JymmmmEMC> graphite
[18:16:45] <anonimasu> water + magnesium rocks :D
[18:16:55] <JymmmmEMC> KaBOOM!
[18:17:17] <anonimasu> yep
[18:17:34] <JymmmmEMC> The only magnesium I have is kept in my knife =)
[18:17:59] <anonimasu> knife?
[18:18:05] <skunkworks> with 1 water-proof match?
[18:18:05] <anonimasu> like magnesium flare?
[18:18:38] <JymmmmEMC> 10" stright blade knife in the handle (magnesium match)
[18:18:45] <anonimasu> ah
[18:19:02] <anonimasu> im building a knife one of theese days
[18:19:17] <anonimasu> building/machining
[18:21:22] <JymmmmEMC> We got off work eons agao and wanted to hit the beach. We grabbed a bunch of pallets for firewood and threw them off the cliff. They didn't break apart. One guy had one of those "rambo" knifes and we were able to make enough kindling. Ever since, I've kept one of those cheapies around for that reason. Has a nice "saw" on the back end of it too.
[18:21:47] <anonimasu> hehe
[18:21:47] <anonimasu> I have one like that
[18:23:41] <JymmmmEMC> http://www.harborfreightusa.com/usa/itemdisplay/displayItem.do?itemid=90714&CategoryName=&SubCategoryName=
[18:23:45] <JymmmmEMC> err 8"
[18:24:41] <JymmmmEMC> $10 is cheap enoug if you break it, you don't care.
[18:25:03] <ds2> do those heat guns overheat if you lower the output with a light dimmer type of controller (TRIAC-DIAC, sine wave chopping)?
[18:25:34] <JymmmmEMC> ds2: does your have a hi/lo setting?
[18:25:43] <JymmmmEMC> which usually changes the fan speed
[18:26:19] <ds2> JymmmmEMC: I don't have it yet but the $9 one at HF is tempting so I am looking for guesses... heard some stuff use the air for cooling
[18:27:17] <JymmmmEMC> ds2: Honestly, I'm avoiding ALL HF tools, their electronics seems to be pretty good, but avoid the power tools. Hit capital fleamarket instead.
[18:28:11] <JymmmmEMC> The IR thermometer and the OBD II code reader are both great! I've returned oh so many power tools though.
[18:28:57] <ds2> JymmmEMC: I just need a 100-200W heater so if I can find one for $9, I'll take it
[18:29:09] <Skullworks-PGAB> yeah there little trim router is a bad joke
[18:29:17] <JymmmmEMC> ds2: what for?
[18:29:40] <JymmmmEMC> Skullworks-PGAB: I bought one, and it started melting the outter casing with no load or tool
[18:29:42] <Skullworks-PGAB> the lower bearing is held in plastic - the bearing heats up and the plastci melts
[18:30:10] <JymmmmEMC> Skullworks-PGAB: you know the clear plastic stand? It started melting itself to the orange plastic.
[18:30:30] <Skullworks-PGAB> the motor winding and bearings are good - but they need a proper metal housing
[18:31:40] <JymmmmEMC> ds2: This one? http://www.harborfreight.com/cpi/ctaf/displayitem.taf?Itemnumber=35776 IIRC I looked at it (for a spare), I wasn't impressed with it.
[18:32:27] <Skullworks-PGAB> I was thinking about using it to drive an O-ring belt to drive a mini spindle about 1:4 (6000rpm) - but your right - even under no load will melt in a few minutes.
[18:32:38] <JymmmmEMC> ds2: felt WAY TOO CHEAP for a heat gun.
[18:33:47] <JymmmmEMC> Skullworks-PGAB: That's when I said fsck it, and bought the best router sears had (it's a rebranded Bosch) but sears is open 7 days a week and bought a instant exchange warranty for 2yrs for an extra $34
[18:33:51] <Skullworks-PGAB> I have that heat gun... I use it to pre-heat my car in winter
[18:34:34] <Skullworks-PGAB> yup - those walk in exchange policy is why sears still gets my biz
[18:34:47] <JymmmmEMC> Then I hit the Bosch service cneter and bought a 3/8" collet for it that Sears doens't even offer =)
[18:35:22] <JymmmmEMC> It's the ONLY reason I buy from sears.
[18:35:43] <ds2> yes, that one
[18:36:16] <JymmmmEMC> But whatever you do, SAVE THOSE RECEIPTS!!!!!!!!!!!!!!!!!!!!! AND NEVER NEVER NVER buy a goft from sears for someone.
[18:36:21] <Skullworks-PGAB> Auto and tool dept is only part of store I go.
[18:36:22] <JymmmmEMC> gift
[18:37:25] <JymmmmEMC> We did buy a frig from Sears outlet though. their on-site sears is pretty damn good.
[18:37:36] <JymmmmEMC> on-site service
[18:37:58] <Skullworks-PGAB> They had the tires I needed in stock - and at a better price - and the nation wide warranty coverage just sweetened the pot.
[18:38:37] <JymmmmEMC> Skullworks-PGAB: Keep the receipts. They dont transmit your info to the other stores if you ever need the tires repaired/replaced.
[18:38:56] <Skullworks-PGAB> yep
[18:40:00] <JymmmmEMC> ds2: what are you using the heat gun for?
[18:40:33] <ds2> Jymmmm: heating plastics...
[18:40:33] <JymmmmEMC> ds2: Hey, do you have a mid-tower case by chance? No power supply or guts needed (just all metal)????
[18:40:54] <ds2> JymmmEMC: how high is a mid tower per your definition?
[18:41:06] <JymmmmEMC> about knee high or so
[18:41:12] <Skullworks-PGAB> damn the price for these has almost doubled in the last 9 months http://www.harborfreight.com/cpi/ctaf/displayitem.taf?Itemnumber=46004
[18:41:13] <ds2> yes I do
[18:41:36] <JymmmmEMC> ds2: how much you want for it?
[18:42:04] <ds2> trade or make an offer
[18:42:16] <JymmmmEMC> ds2: what you wnat to trade for?
[18:42:24] <Skullworks-PGAB> jym - you anywhere near the "geeks"?
[18:42:36] <JymmmmEMC> Skullworks-PGAB: which geeks? LOL
[18:42:43] <ds2> JymmmmEMC: my interest are too wide to generate a concise list
[18:43:08] <JymmmmEMC> ds2: I got a slightly used ball of duct tape =)
[18:43:57] <Skullworks-PGAB> http://www.geeks.com/details.asp?invtid=CMM375X&cat=CLR&cpc=CLR
[18:44:40] <ds2> Jymmm: you can have it if you willing to wait til at least next week when I am not so busy AND willing to accept one other case for disposal
[18:44:43] <Skullworks-PGAB> scroll down to the "up to $9.99 section
[18:44:56] <JymmmmEMC> Skullworks-PGAB: No, they're in San Diego area, I'm in San Francisco area
[18:45:10] <maddash> if my steppers are running in the opposite direction they should be (ie, emc's internal orientation of an axis is opposite how it actually is in reality), what's the correct way of fixing this? i'm asking because the only solution i can think of is "setp [Xdir pin]-invert 1," and it seems a bit of a hack.
[18:45:34] <JymmmmEMC> maddash: reverse any two wires iirc
[18:45:35] <anonimasu> maddash: set your scale to -
[18:45:36] <anonimasu> :)
[18:45:37] <anonimasu> input_scale
[18:46:07] <maddash> anonimasu: input_scale can be <0?
[18:46:15] <Skullworks-PGAB> its a one big strip city lining the coast - the Friscodiego grande
[18:46:20] <anonimasu> yes
[18:46:25] <JymmmmEMC> ds2: define "next week" as today is my Sunday =)
[18:46:31] <jepler> madyes
[18:46:36] <jepler> maddash: yes
[18:46:42] <anonimasu> maddash: that's how you fix it :)
[18:46:47] <ds2> JymmmEMC: after 12JUN2007
[18:46:56] <JymmmmEMC> ds2: k
[18:47:35] <maddash> anonimasu, jepler: heh, cool, thanks.
[18:47:39] <JymmmmEMC> ds2: what kind of plastic are you trying to melt? Sheet bending or a glob of plastic into a liquid state?
[18:47:43] <ds2> cool... I get to get rid of more junk
[18:47:49] <Skullworks-PGAB> mad: or swap a pair of winding wires at the driver...
[18:49:04] <ds2> JymmmmEMC: not sure what kind... going for a liquid, extrudable state
[18:49:17] <anonimasu> nice
[18:49:29] <JymmmmEMC> This isn't a bad deal.... http://www.geeks.com/pix/2007/GPSGEEK.html
[18:49:49] <JymmmmEMC> ds2: you going for mold making of sorts?
[18:49:51] <anonimasu> ds2: what kind of plastic?
[18:50:09] <ds2> JymmmEMC: something like that, assuming I don't die from the fumes
[18:50:37] <JymmmmEMC> ds2: what plastic? PP? PE? PVC? HDPE?
[18:51:14] <ds2> JymmmEMC: probally PET or some kind of PE
[18:51:28] <ds2> no PVC, heard that is very bad if I over heat
[18:51:45] <JymmmmEMC> ds2: PET/PETE Are NOT easy to melt, you have to have GOOD temp control
[18:52:02] <anonimasu> * anonimasu nods
[18:52:27] <ds2> JymmmEMC: oh. then I'll stay with PE
[18:52:33] <JymmmmEMC> ds2: Same thing.
[18:52:39] <anonimasu> it's pretty much universal..
[18:52:40] <ds2> anonimasu: I donno is the best answer
[18:52:50] <ds2> JymmmEMC: okay... then what would YOU recommend? =)
[18:52:51] <anonimasu> plastics arent all that _nice_
[18:52:55] <JymmmmEMC> ds2: NiChrome
[18:53:09] <ds2> JymmmEMC: as far as plastic
[18:53:32] <anonimasu> ds2: PET.. I guess
[18:53:47] <JymmmmEMC> ds2: Really doens't matter which themoform you use, all require GOOD (GREAT?) temp control
[18:53:54] <anonimasu> what kind of heater do you need?
[18:54:26] <anonimasu> ouch
[18:54:29] <anonimasu> 260 deg melting point
[18:54:31] <JymmmmEMC> PET needs around 400F, PVC/PE around 340F
[18:54:33] <ds2> anonimasu: donno.. was thinking of heat gun aimed at the chamber
[18:54:41] <anonimasu> http://en.wikipedia.org/wiki/Polyethylene_terephthalate
[18:54:50] <anonimasu> ouch
[18:55:09] <JymmmmEMC> anonimasu: thats to melt and make goooey, but not hot enough to to be useful
[18:55:40] <ds2> JymmmEMC: what do you mean by good temp control? I was thinking of a feedback system to maintain within 10-20F
[18:55:57] <JymmmmEMC> ds2: try more like within +- 4 deg
[18:56:03] <ds2> only problem is I am using a metal chamber and NiChrome is generally not insulated so...
[18:56:17] <JymmmmEMC> you can go from good to crucnhy within a few degrees
[18:56:36] <anonimasu> hm, I'd go for a heater.. with a outer and inner coil..
[18:56:50] <ds2> crunchy is okay. releasing toxic fumes is not:/
[18:57:02] <anonimasu> and to get the whole chamber equally hot..
[18:57:11] <JymmmmEMC> ds2: ALL plastic release HCL for 20+ years
[18:57:11] <ds2> anonimasu: I was going to use some cheap soldering irons but they don'thave enough wattage for the cheap irons
[18:57:32] <ds2> JymmmEMC: HCl is not that toxic.... HCN is what I am worried about
[18:57:40] <JymmmmEMC> ds2: wanna bet?
[18:57:58] <ds2> JymmmEMC: I been exposed and I haven't croaked
[18:58:09] <JymmmmEMC> ds2: that doens't mean it's not toxic.
[18:58:23] <JymmmmEMC> havne' tyou seen the 6 legged frogs yet?
[18:58:31] <ds2> JymmmEMC: anything is toxic given enough
[18:58:34] <anonimasu> heh
[18:58:37] <ds2> JymmmEMC: your stomache has HCl in there
[18:58:45] <anonimasu> I cant find any hobbist doing anything in PET
[18:58:46] <JymmmmEMC> ds2: Hey, me just maching plastic is pretty nasty.
[18:58:59] <ds2> so the body has SOME tolerance for HCl
[18:59:16] <JymmmmEMC> anonimasu: I'm trying my hand at PET, but my heater isn't hot enough.
[18:59:26] <Skullworks-PGAB> use water with dishsoap - the plastic should cut real nice.
[18:59:40] <ds2> anonimasu: PE and PET seems to be the easiest plastics to get in small amounts
[18:59:43] <JymmmmEMC> Skullworks-PGAB: Cuts great as it is, just stinks
[18:59:50] <anonimasu> ds2: plastic bottles..
[19:00:13] <ds2> JymmmEMC: the alternative is HCN which IS toxic in much lower quantities
[19:00:29] <ds2> anonimasu: yep. that's where I am getting it... most of those are either PE or PET
[19:00:46] <anonimasu> yeah, but most plastics are a pain.. so why dont go for that ?
[19:00:49] <ds2> JymmmEMC: where did you find the tolerance range for the temperature?
[19:01:36] <JymmmmEMC> ds2: MFG's datasheets and speaking with the engineers
[19:01:55] <anonimasu> you need a really fancy heater for that..
[19:01:57] <ds2> JymmmmEMC: have you looked into hotmelt glue?
[19:02:06] <anonimasu> that's toy stuff.
[19:02:31] <ds2> yes, but hotmelt glue is cheap, easy to find, and apparently pretty tolerance of a wide temperature range
[19:02:32] <JymmmmEMC> ds2: Yes, I have shitloads and works pretty good. I have a industrial glue gun.
[19:02:47] <ds2> JymmmEMC: for molding or ?
[19:02:54] <anonimasu> still it's not like PFTE..
[19:02:56] <JymmmmEMC> ds2: the highest wattage you can get.
[19:03:21] <JymmmmEMC> ds2: Yes, but remember that if you are mold making, that it WILL shrink
[19:03:30] <ds2> JymmmmEMC: I was thinking of doing a tiny extrusion head for a 3D RP system
[19:03:40] <JymmmmEMC> RP?
[19:03:55] <ds2> JymmmmEMC: dimensional control is the least of my worries. functionality first then I'll worry about size
[19:04:00] <ds2> Rapid Prototyping
[19:04:10] <ds2> stereo lith, 3D printing, etc
[19:04:46] <Skullworks-PGAB> that seems to be all the rage at the moment
[19:04:47] <JymmmmEMC> There are many types of "hot glue" checmistry if you look.
[19:05:07] <ds2> yep. all I want to know is what is in the really cheap ones
[19:05:18] <JymmmmEMC> walmart is the cheapest
[19:05:32] <ds2> Skullworks-PGAB: I was interested in it since 91 so... :P
[19:05:41] <ds2> but what is the walmart ones made of
[19:06:01] <JymmmmEMC> ds2: http://www.hotstik.com/store/pc/home.asp
[19:06:45] <ds2> JymmmEMC: and which one is closest to the wally world ones?
[19:07:05] <JymmmmEMC> ds2: what are you wanting to REALLY know?
[19:07:40] <ds2> JymmmEMC: strength (will my pile topple over), temperature it wants for free flow
[19:08:08] <JymmmmEMC> these: http://www.hotstik.com/store/pc/HS-102-General-Purpose-Clear-Glue-Sticks-Per-Lb-6p36.htm
[19:08:21] <JymmmmEMC> are the closest to walmart
[19:08:51] <JymmmmEMC> you are going to want to balance between working time and viscosity
[19:09:09] <ds2> *nod*
[19:09:20] <ds2> I just want some numbers so I can start in the ballpark
[19:09:56] <JymmmmEMC> look at the chemisties of the different ones they have. I can give you a couple of sticks of the other stuff I have so you can play with.
[19:11:10] <JymmmmEMC> I have some of the packing glue sticks as well. strong bond then the walmart stuff.
[19:11:18] <JymmmmEMC> stronger
[19:11:39] <JymmmmEMC> but need a hi-temp glue gun
[19:12:30] <JymmmmEMC> hell, I have glue-in-the-dark glue sticks even =)
[19:12:34] <ds2> I'm just extruding it so bonding may not be a good thing for me
[19:12:50] <JymmmmEMC> these are harder too
[19:13:01] <ds2> I see.
[19:13:41] <JymmmmEMC> But the offer of the free glue sticks ends in 4 hours =)
[19:13:51] <ds2> JymmmEMC: have you seen the gingery mini injection machines?
[19:14:11] <JymmmmEMC> no, plastic injection scares the shit out of me =)
[19:14:13] <ds2> JymmmEMC: I don't have that much time to do experiment so but thanks anyways
[19:14:21] <JymmmmEMC> LOL
[19:14:27] <ds2> JymmmEMC: those are hand operated
[19:15:31] <JymmmmEMC> Experiment on your own time! I meant giving you the sticks todo with what you want and an incentive to pickup the case today so I know what size aluminum plate I need to buy today.
[19:15:47] <ds2> I know what you were trying to do
[19:16:16] <ds2> part of the problem is I need to go under a mound to get it out =/
[19:16:20] <JymmmmEMC> lol
[19:16:28] <JymmmmEMC> Got Back Hoe?
[19:16:42] <ds2> a bobcat would be VERY handy ;)
[19:18:37] <JymmmmEMC> If you plan on doing something like a hot feed system, you might wnat to use an electric charcoal heater in a tank, then a feesystem with it's own heater.
[19:18:59] <JymmmmEMC> then you could add the dimmer temp control and go from there.
[19:19:15] <JymmmmEMC> but using hot air, I doubt will do what you want.
[19:19:30] <ds2> that's much much bigger then what I want
[19:19:32] <JymmmmEMC> hell even a MAAP gas torch is pretty sad.
[19:19:55] <ds2> all I want to deal with is the size of one of those 1/2" glue stick
[19:19:59] <ds2> but in PE or PET
[19:20:05] <JymmmmEMC> That's what I'm talking about.
[19:20:21] <JymmmmEMC> you can buy hot nelt glue in pellet form
[19:20:53] <ds2> in less then a pallet (or sack) size?
[19:21:06] <JymmmmEMC> sure
[19:21:11] <ds2> oh
[19:21:16] <JymmmmEMC> comes in 25# boxes iirc
[19:21:33] <ds2> PE/PET is more rigid and nontacky when hardened
[19:21:42] <JymmmmEMC> http://www.hotstik.com/store/pc/Graco-Thermoflow-T5-Hot-Melt-System-Complete-Preconfigured-13p65.htm
[19:22:00] <JymmmmEMC> you add pellets to that as the tank get lows
[19:22:16] <JymmmmEMC> but it takes about 30 minutes or so to get the tank liquid
[19:22:22] <ds2> Hmmm
[19:22:27] <JymmmmEMC> AND GAWD HELP YOU IF IT SPLASHES!!!!
[19:23:02] <ds2> should be fine if I have on the leather welding gear + face shield
[19:23:13] <JymmmmEMC> murphy's law
[19:23:27] <ds2> I figure it is no worse then doing foundry stuff
[19:23:37] <JymmmmEMC> =)
[19:23:55] <JymmmmEMC> http://www.hotstik.com/store/pc/viewContent.asp?idpage=2
[19:24:22] <ds2> i stil prefer PE/PET if I can do it
[19:24:32] <JymmmmEMC> http://minneapolis.craigslist.org/art/345427223.html
[19:24:45] <ds2> shred old bottles, put in a chamber (1/2" drill out on some bar stock) and melt it there
[19:25:16] <anonimasu> agreed
[19:25:33] <JymmmmEMC> Hey those bottles are now $0.10/ea =)
[19:25:34] <ds2> anonimasu: have you seen the design in the gingery books?
[19:25:56] <ds2> JymmmEMC: it'll be worth more then I get from the recycler after I pay for gas
[19:26:11] <JymmmmEMC> ds2: =)
[19:26:38] <JymmmmEMC> Ok, I'm off to get some 1/8" alum plate
[19:26:47] <ds2> think that's considered sheet
[19:27:09] <JymmmmEMC> eh, whatever they have in the scrap pile (if possible)
[19:27:27] <JymmmmEMC> if not, then I'll have them cut me some
[19:27:34] <ds2> for sheet goods, try the store up in the east bay
[19:27:45] <JymmmmEMC> which?
[19:27:51] <ds2> metal supermarkets
[19:28:00] <ds2> the east bay branch tends to have more sheet goods
[19:28:05] <JymmmmEMC> Yeah, in SC. That's where I'm going.
[19:28:18] <JymmmmEMC> lafette and Central Expw
[19:28:18] <ds2> the SC stores tends to not have as much sheet goods
[19:28:37] <JymmmmEMC> ah
[19:44:39] <maddash> i think there's a bug in control.c
[19:44:42] <maddash> :
[19:47:28] <maddash> i have two axes (x & y) with homing_sequence =0 for both of them. sometimes, if I issue a homing_all (ie, homingmsg.axis=-1) repeatedly, one of the axes would move non-stop in its latch_vel phase (until I hit estop or the steppers jam [i don't have limit switches for the other end currently]).
[19:48:20] <maddash> however, if i give x & y two different homing_sequence values, this problem does not occur.
[19:50:22] <maddash> some clues:
[19:50:38] <jepler> maddash: in command.c, the assignment to homingSequenceState should probably only occur if the current state is HOME_SEQUENCE_IDLE
[19:50:57] <jepler> i.e., you can't start a new homing sequence while an old homing sequence is in progress
[19:51:21] <jepler> maddash: please let me know if that fixes the problem you're seeing
[19:51:45] <maddash> jepler: how do you mean? the homing configuration doc allows simultaneous homing of more than one axes...
[19:52:26] <jepler> maddash: yes, and it should stay that way with this change
[19:54:01] <jepler> emcmotStatus->homingSequenceState controls the sequencing of homing multiple axes when you home all. joint->home_state controls the sequencing of the homing moves for a particular axis
[19:54:57] <maddash> hmm, homingSequenceState is referenced only once in command.c:
[19:54:58] <maddash> if(joint_num == -1) {
[19:54:58] <maddash> emcmotStatus->homingSequenceState = HOME_SEQUENCE_START;
[19:54:58] <maddash> break;
[19:54:58] <maddash> }
[19:55:19] <jepler> maybe if you look in other nearby files you will find some more uses of homingSequenceState
[19:55:23] <maddash> jepler: so should I tack the HOMING_SEQ_IDLE check there?
[19:55:28] <maddash> ah, ok.
[19:55:40] <jepler> but yes that's the place where I was suggesting to test whether the state is HOME_SEQUENCE_IDLE
[20:02:15] <maddash> okay, homingSeqState is only referenced in command.c (once), control.c (several times) and declared in motion.c . i've only added the idle check to command.c, now I'm going to try it out. brb.
[20:03:47] <jepler> the homing sequence state machine is supposed to work something like this: http://emergent.unpy.net/files/sandbox/hss.png
[20:04:13] <jepler> except that it can currently transition from *any* state to HOME_SEQUENCE_START when you EMCMOT_HOME(-1)
[20:04:18] <jepler> that's what I think the bug is
[20:14:12] <alex_joni> anyone from france in here?
[20:14:26] <jepler> the homing sequence state machine is supposed to work something like this: http://emergent.unpy.net/files/sandbox/hss.png
[20:14:28] <jepler> except that it can currently transition from *any* state to HOME_SEQUENCE_START when you EMCMOT_HOME(-1)
[20:14:33] <jepler> that's what I think the bug is
[20:14:35] <jepler> maddash: ^^^
[20:15:16] <maddash> jepler: thanks. just to let you know, simply tacking on the HOMING_SEQ_IDLE to command.c (line 1144 of emc 2.1.5's file) didn't work...
[20:18:41] <jepler> maddash: fwiw I've been trying to make this happen on the 'sim' configuration with simulated home switches, but I haven't seen the behavior yet.
[20:19:21] <jepler> maddash: the bug may lie in the state machine for homing a single axis, but nothing jumps out at me as being wrong there.
[20:20:48] <jepler> maddash: a halscope trace of homingSequenceState, joints[n].home_state and the home switch states might be helpful to someone else in troubleshooting this, assuming you can figure out how to add those as scopeable HAL parameters
[20:21:04] <maddash> jepler: is it appropriate for "case emcmot_home:" to always issue "joint->home_state = HOME_START;" (1157)?
[20:21:31] <maddash> halscope sounds like a good idea.
[20:22:15] <jepler> maddash: I don't know, but if you're always using joint_num == -1 you would not ever be hitting that line of code
[20:22:58] <jepler> jmkasunich: do you think that it's OK or wrong to set joint->home_state = HOME_START; in case EMCMOT_HOME: regardless of the joint's current home state?
[20:23:41] <jepler> bbl
[20:25:17] <maddash> ditto.
[20:26:02] <jmkasunich> jepler: maybe not.... should probably only go to START from IDLE
[20:45:49] <CIA-2> 03jepler 07TRUNK * 10emc2/src/emc/motion/command.c:
[20:45:48] <CIA-2> only permit a homing sequence to be started when the homing sequence is idle
[20:45:48] <CIA-2> only permit a joint to be homed when joint and homing sequence are idle
[20:56:45] <CIA-2> 03jepler 07TRUNK * 10emc2/docs/src/code/hss.dot: diagram of the "home sequence" state machine
[20:58:06] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[21:23:53] <maddash> how do I print debug messages from inside control.c? rtapi_print doesn't output anything to my terminal
[21:24:42] <alex_joni> maddash: rtapi_print gets printed to the kernel log
[21:24:53] <alex_joni> dmesg or taik /var/log/messages
[21:24:55] <alex_joni> to see that
[21:35:36] <maddash> what about kern.log?
[21:35:47] <maddash> alex_joni: ^^
[21:37:02] <alex_joni> dunno
[21:37:42] <alex_joni> * alex_joni heads to bed
[21:37:47] <alex_joni> good night all
[21:59:52] <maddash> jepler: i think the problem is caused by the joints->home_state instead of emcmotStatus->homingSeqState, because the sequence of states (idle, start, startwait, etc) is correct
[22:22:23] <robin_sz> meep?
[22:22:37] <robin_sz> * robin_sz plays with google street view
[22:26:47] <maddash> ooooooooooohhhhhhhh