#emc | Logs for 2006-08-15

Back
[02:05:10] <CIA-12> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/axis.py:
[02:05:10] <CIA-12> fix error 'Unknown operation name starting with e' when offseting an axis
[02:05:10] <CIA-12> that was at .00001 or closer to the machine origin (but not exactly on it)
[02:29:00] <jepler> (%s switches into exponential notation at that point)
[02:31:15] <cradek> wow that's an obscure one
[02:37:33] <SWPadnos> should the print be removed?
[02:43:09] <CIA-12> 03cradek 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: remove debug output
[02:45:21] <SWPadnos> I guess so
[02:46:06] <cradek> :-)
[02:46:56] <Jymmm> Hello Gents!
[02:47:07] <SWPadnos> hey - what about me?
[02:47:40] <Jymmm> * Jymmm sighs *
[02:47:52] <Jymmm> SWPadnos Hello you bumb!
[02:47:59] <Jymmm> -b
[02:48:03] <SWPadnos> thanks
[02:48:06] <Jymmm> =)
[02:48:11] <cradek> I bet he's never been called that before
[02:48:21] <Jymmm> cradek $10 says he has =)
[02:48:31] <SWPadnos> nope - never been called a bumb beefooor
[02:48:55] <Jymmm> oh 'bumb'... well, you never know =)
[02:49:00] <Jymmm> maybe not to his face
[02:50:49] <Jymmm> http://www.rainforestcafe.com/
[02:53:04] <SWPadnos> http://www.chocolatebar.com/
[02:57:42] <Jymmm> Nice concept
[02:57:51] <SWPadnos> good chocolate bars, too
[02:58:00] <SWPadnos> hmmm - chocolate
[02:58:04] <SWPadnos> brb
[02:58:08] <Jymmm> I'm a dark chocolate kinda person
[02:58:36] <cradek> hmm chocolate
[03:00:10] <Jymmm> alex_joni: A present for when you wake up... http://arch.ced.berkeley.edu/kap/gallery/gallery.html
[03:05:32] <SWPadnos> www.equalexchange.com
[03:06:12] <SWPadnos> http://www.equalexchange.com/chocolate-bars
[03:07:27] <cradek> http://chocolove.com/ginger_dark.htm
[03:07:37] <cradek> this is my favorite chocolate bar
[03:07:46] <SWPadnos> I'm not a big fan of the ginger chocolate, but my wife loves it
[03:08:12] <SWPadnos> that exact one, in fact :)
[03:09:34] <cradek> I like chocolate that's good enough for one square to be a serving
[03:09:48] <Jymmm> cradek one 40lb square?
[03:09:53] <SWPadnos> yeah, and two squares is a controlled drug ;)
[03:10:38] <cradek> well, I'm gonna have to go see if I have some of that
[03:11:23] <cradek> yep
[03:12:59] <cradek> the kite photography is very cool
[03:13:26] <JymmmEMC> Yeah, thought alex would enjoy it.
[03:13:42] <JymmmEMC> Especially with that new camera he has.
[03:15:00] <JymmmEMC> how tweakable is AXIS gui?
[03:15:10] <JymmmEMC> for a non python person
[03:15:39] <cradek> give me an example of the type of tweak you're asking about
[03:16:02] <JymmmEMC> okey.... make the gcode window bigger
[03:16:12] <JymmmEMC> add/change controls
[03:17:10] <cradek> those kinds of things wouldn't be very easy for the amateur
[03:18:45] <JymmmEMC> hmmm, bummer
[03:19:32] <JymmmEMC> Is the SPACE_BAR bound to anything by chance?
[03:20:04] <cradek> not sure about auto mode - definitely in MDI mode it's used (to type spaces)
[03:20:46] <Guest245> hello?
[03:20:51] <cradek> hi guest
[03:20:59] <JymmmEMC> can key bindings be changed on a per-mode basis?
[03:21:05] <Guest245> hi!
[03:21:47] <cradek> Jymmm: sure, many keys are shortcuts in auto mode, but type themselves in mdi mode
[03:23:19] <JymmmEMC> cradek: Ok, cool. I want to bind some/many so I can use an external num_pad as a pseudo pendant.
[03:23:52] <cradek> does it just look like a keyboard?
[03:24:37] <cradek> if it has arrows you can already jog with it
[03:26:25] <Jymmm> fast and slow jogging?
[03:26:41] <Jymmm> pgup/pgdn being Z axis?
[03:26:51] <Jymmm> num_pad wise
[03:26:52] <cradek> you could change the jog speed if you can get it to send , and .
[03:27:39] <JymmmEMC> ok, cool.
[03:28:01] <JymmmEMC> really only need to speeds... normal and slow
[03:28:31] <JymmmEMC> Under Turbocnc, it was ALT+arrow for fast jog, and arrow alone for slow jog.
[03:29:03] <SWPadnos> do you get normal keycodes, or are they special (since they're not from the core input device)?
[03:29:48] <JymmmEMC> Under pythong it's like NUM_6 or something like that
[03:30:11] <SWPadnos> ok, so the secondary keyboard (keypad) is probably configured to send core events
[03:30:17] <JymmmEMC> or are you referring to it being external numpad?
[03:30:38] <SWPadnos> yeah -usually only the first pointer and keyboard are core input devices
[03:30:41] <JymmmEMC> Oh, yeha, the external numpad is 100% transparent
[03:30:50] <SWPadnos> but you can tell X that any device should send core events
[03:31:32] <JymmmEMC> I have no idea what you mean by "core events"
[03:31:48] <SWPadnos> "events from the core input devices" ;)
[03:31:56] <JymmmEMC> signal wise, internal and external send the same thing.
[03:32:39] <SWPadnos> I think that auxiliary pointers and keyboards aren't treated the same as "core" devices by default (X default anyway - most distros probably configure them as core devices)
[03:32:45] <SWPadnos> ok
[03:33:33] <JymmmEMC> PS/2 protocol allows you to dasiychain keyboards and mice
[03:34:00] <JymmmEMC> Thought not at the EXACT same time =)
[03:34:35] <SWPadnos> X allows more than one pointer, so you have to tell it that you want all the mice (trackpads, etc) to control the same pointer.
[03:34:49] <SWPadnos> I think the keyboards are configured similarly, but I'm not sure
[03:34:51] <JymmmEMC> Ah, ok. wasn't aware of that.
[03:35:15] <JymmmEMC> Maybe, I have no idea. The scancodes sent (I believe) ar ethe same be it internal or external.
[03:35:48] <JymmmEMC> I have two mice daisychained right now in X, both acting the same
[03:35:51] <SWPadnos> probably the case - but you may be able to change that, and have different speeds (or different functions) for the different keypads
[03:36:37] <JymmmEMC> Well, maybe if they are connected to the mobo differently, but being daisychained I seriously doubt it.
[03:37:17] <SWPadnos> ah - I didn't realize it was a PS/2 keypad. Connected like the old barcode scanners?
[03:37:23] <Guest245> I have a neby type question--has anyone experienced problems with shutsown after installing EMC? I installed Ubuntu 6.06 and shutdown worked fine, but after installing EMC it gets to the end of teh script and just sits there.
[03:37:45] <SWPadnos> emc shutdown, or shutting off the PC?
[03:37:50] <cradek> Guest245: that's normal - when it says it's done, just turn the machine off manually
[03:38:11] <JymmmEMC> SWPadnos: I have a IBM kybd that has a PS/2 socket on the back of it for another mouse. But usually ext numpad's also have a passthru connector as well.
[03:38:24] <cradek> Guest245: powering off is an ACPI (power management) feature and all power management has to be disabled to run realtime programs (EMC).
[03:38:41] <SWPadnos> JymmmEMC, I've goten so used to USB that I hardly think about PS/2 any more (for extra peripherals)
[03:38:59] <Guest245> Thnks cradec. Just hought there might be a script fix or something to remedy.
[03:39:13] <JymmmEMC> SWPadnos: I HATE USB for kybds, too much polling for my taste.
[03:40:13] <cradek> Guest245: nope, it's disabled on purpose, out of necessity, unfortunately
[03:40:16] <SWPadnos> JymmmEMC, It's not polled any more than if you have no keyboard attached - it's still 1 ms packets, with preset data slices for the attached peripherals
[03:41:19] <cradek> Guest245: the upside is it doesn't mean there's anything wrong - Linux is completely shut down at that stage, you just have to turn the hardware off (like the old days).
[03:41:32] <JymmmEMC> SWPadnos: I dont have any issues/problems with PS/2; and loosing kybd control is a pet peeve of mine.
[03:42:00] <JymmmEMC> screw the mouse, just dont muck wiht my kybd =)
[03:42:03] <SWPadnos> heh
[03:42:24] <JymmmEMC> Hell, I burned out the LED's on this one
[03:43:02] <JymmmEMC> (ok, I doubt the leds themselves, but the electronics that drive the leds)
[03:43:27] <JymmmEMC> but it has at least 100K hours on it, so it could be.
[03:43:47] <JymmmEMC> fuck, I need to get a life! LOL
[03:43:57] <JymmmEMC> 100K hours on a kybd...... eeeeeeesh
[03:45:09] <SWPadnos> that's only ~12 years continuous use :)
[03:48:52] <JymmmEMC> Yeah, it's about that old on THIS kybd, and I have the other one too
[03:57:33] <JymmmEMC> linear move 116 out of range
[03:57:40] <JymmmEMC> =(
[03:57:47] <SWPadnos> don't do that
[03:58:03] <JymmmEMC> I didn't do nuttin, it did it!
[03:58:13] <SWPadnos> yah, right
[03:58:35] <SWPadnos> fast jog?
[03:58:49] <JymmmEMC> Nope, just running one of my gcodes programs
[03:59:07] <JymmmEMC> that work under turbocnc just fine! =)
[03:59:12] <SWPadnos> what
[03:59:26] <cradek> that just means it'll move outside your limits
[03:59:29] <SWPadnos> what's the range of motion, and where was the commanded location?
[03:59:42] <JymmmEMC> I dont know, I'm just palying
[03:59:51] <JymmmEMC> with it
[03:59:57] <SWPadnos> then I'll repeat myself: don't do that :)
[04:00:11] <JymmmEMC> Hey, if I can break it anybody can!
[04:00:20] <SWPadnos> I'm not so sure ...
[04:00:26] <cradek> it's not like it's a bug or something
[04:00:35] <JymmmEMC> It worked under TurboCNC just fine =)
[04:00:41] <cradek> if you hit limits, your limits or your program are wrong
[04:01:09] <JymmmEMC> Nah, I haven't configured it yet for my machine; whatever the shipping defaults are is what it hit.
[04:01:13] <SWPadnos> see - EMC is too smart to let you screw yourself
[04:01:15] <SWPadnos> (that way)
[04:01:24] <JymmmEMC> where's the fun in that?!
[04:03:14] <JymmmEMC> black/dk grey) cone on a black background.... anyway to have those contrast a little better?
[04:04:16] <cradek> xgamma -gamma 1.5
[04:04:39] <JymmmEMC> from the console?
[04:04:53] <SWPadnos> yeah - use that snazzy keyboard you love so much :)
[04:05:02] <JymmmEMC> whee
[04:06:12] <JymmmEMC> Eeeeeew, icky. the WHOLE screen bleeded out.
[04:07:06] <cradek> try 1.3
[04:07:13] <JymmmEMC> anyway to change the cone color instead?
[04:08:04] <cradek> yeah, but I think it shouldn't be too dark unless your screen is funny somehow
[04:08:26] <cradek> there's a website that helps set screen gamma - let me see if I can find it
[04:09:01] <JymmmEMC> I keep the brightness set VERY low; or I get headaches.
[04:09:40] <JymmmEMC> If I crank it to like 60, they contrast.
[04:10:27] <cradek> http://radsite.lbl.gov/radiance/refer/Notes/gamma.html
[04:10:55] <cradek> "In most cases, you want to target a standard gamma value of 2.2 for the correct display of typical captured images"
[04:11:23] <cradek> have a look at that graph, my screen does seem to be around 2.2 like is recommended
[04:11:37] <JymmmEMC> looking...
[04:13:54] <cradek> I think the procedure is this: in a dark room set your brightness so a black screen shows dark (the "brightness" control would be better named "black level"), then set contrast comfortably, then adjust gamma
[04:14:23] <cradek> strangely enough, the contrast control would be better named "brightness"
[04:16:04] <JymmmEMC> Yeah, but I use this monitor on four computers and I keep the brightness VERY low or I get headaches. For me, I think it be better if I could just change the cone color instead.
[04:17:27] <cradek> sure, just trying to help because you'll probably have problems in other apps too
[04:17:38] <cradek> you can set the cone color with the Xresources - let me see if I can figure out how
[04:17:46] <JymmmEMC> k
[04:23:41] <cradek> nope I can't
[04:23:49] <cradek> ask jepler :-)
[04:23:56] <Jymmm> will do =)
[04:24:29] <Jymmm> I had a really strane thing happen the first time I tried Xforwarding...
[04:25:07] <Jymmm> I connected, ran emc in REAL TIME, then killed the remote client. emc box then rebooted itself
[04:26:24] <cradek> also if you use anti-aliased fonts (and especially subpixel rendering on lcds) you really want to set gamma right
[04:26:57] <cradek> Jymmm: could you reproduce that?
[04:27:35] <Jymmm> No, on the next time I tried it, I let it finish chips, and then closed it and it quit gracefully.
[04:57:56] <Jymmm> http://www.bertrand-soulier.com/2006/08/04/magicienne-nue/
[08:21:22] <EvertL> good morning guys
[08:21:45] <EvertL> a little food for thought on rtnet and emc2
[08:22:34] <EvertL> i got rtnet pretty much doing what i want through HAL, that is establishing real-time ethernet communication between two instances of emc2
[08:23:03] <EvertL> now i'm at a point where i'll try to integrate the two
[08:23:31] <EvertL> and i'm wondering what would be interesting for emc users
[08:24:11] <EvertL> so are there any thoughts on rtnet itegration for generic purpose?
[08:25:05] <alex_joni> hi EvertL
[08:25:17] <alex_joni> I think it would be nice to have some RTnet HAL driver
[08:25:38] <alex_joni> I imagine it like this: (might be far away from what you have :D)
[08:25:42] <EvertL> how do you see that
[08:25:49] <EvertL> alright, lets hear it :-)
[08:26:09] <alex_joni> when loading the driver you specify some input/output pins (a list for pins: name, type, direction)
[08:26:25] <alex_joni> of course this happens on both machines
[08:26:34] <alex_joni> and the pin names are named the same?
[08:26:52] <alex_joni> on both machines, so basicly anything you do locally to a pin, replicates on the remote machine
[08:26:57] <alex_joni> same the other way around
[08:27:12] <alex_joni> this would work like an invisible bridge between the 2 HAL's
[08:27:17] <EvertL> alright, that's do-able
[08:27:30] <alex_joni> how did you do it?
[08:27:36] <EvertL> should that run in the servo thread?
[08:27:49] <alex_joni> I think you should be able to addf it to the proper thread
[08:28:04] <EvertL> right now i'm only talking from one machine to the other, but pins can be exported in a matter of minutes
[08:28:11] <alex_joni> have 3 functions? (read-all, update-remote, write-all)
[08:28:17] <alex_joni> or something like that
[08:28:36] <EvertL> the thing is, the recieving side needs to be able to wait for a moment - a time-out
[08:28:37] <alex_joni> this is a kernel module.. right?
[08:29:00] <EvertL> i don't know if that's a good thing to do in a critical thread
[08:29:01] <EvertL> yes
[08:29:44] <alex_joni> that might be a small problem in parsing the pin list
[08:30:12] <alex_joni> but only a SMOP ;)
[08:30:25] <EvertL> the timeout is very small though, it basically depends on the thread period
[08:30:45] <alex_joni> I see.. what typical values did you see?
[08:30:52] <EvertL> SMOP? i'm very bad at these abbreviations :-)
[08:31:01] <alex_joni> Simple Matter Of Programming ;)
[08:31:25] <alex_joni> that means it can be done, just needs to get written (sometimes can expand drastically during the implementation phase..)
[08:32:33] <EvertL> :-) it should be too much of a problem. i need to do a good benchmark still, so i can't give exact numbers. right now i use a timeout of 50 millisec but that can be a lot less
[08:32:52] <EvertL> NOT too much of a problem :-)
[08:32:59] <alex_joni> 50 millisec? :)
[08:33:07] <EvertL> but the timeout depends basically on the speed of the thread
[08:33:11] <alex_joni> seems like a lot :D
[08:33:24] <alex_joni> * alex_joni is used to the base_thread (more like 10 usec :D)
[08:33:34] <EvertL> :-) i know
[08:33:36] <EvertL> but
[08:34:01] <EvertL> it can be probably in the region of that number, depending on the sending thread
[08:34:21] <EvertL> you do not want the sending thread to be able to send without the recieving thread being able to recieve
[08:34:34] <EvertL> iow, they need to synchronize
[08:35:07] <EvertL> as soon as the first, long time-out is done, the next will be in terms of usecs
[08:35:16] <EvertL> but that i haven't tested yet
[08:35:37] <EvertL> so i can't give exact numbers on that
[08:35:42] <EvertL> it's coming though
[08:36:01] <EvertL> does it still make sense?
[08:39:28] <EvertL> this is also why a seperate thread makes sense - if you use two unidentical threads on two machines the timeout will be big because the recieving thread tries to synchronize on the point where the sending thread sends a message
[08:47:46] <alex_joni> I can see that..
[08:48:00] <alex_joni> it doesn't hurt having another thread only for the RTnet stuff
[08:48:22] <alex_joni> at this point (not having seen the code) I'm good with whatever you say is best :D
[08:48:51] <EvertL> an other point - how would you like to see the rtnet interface ported to EMC, if at all?
[08:49:54] <EvertL> right now i have to start rtnet and start a modified realtime script
[08:51:33] <EvertL> it might be nicer to extend the rtapi interface with rtdm functionality (does RTLinux have that?) and have an EMC rtnet interface for rtnet specific functions
[08:51:55] <alex_joni> I don't think RTLinux has that
[08:53:20] <EvertL> that's a shame. so an rtnet module needs RTAI, a seperate install of rtnet and some manual tweaking for any rtnet HAL module to work
[08:53:48] <EvertL> IF the new versions will stay compatible with the current interfaces
[08:53:56] <EvertL> so many dependancies :(
[08:55:56] <EvertL> but alright, i will give this some thought and in the meanwhile finish up the module for generic use + i'll make some documentation
[08:57:54] <alex_joni> how active is the rtnet development?
[09:01:05] <alex_joni> I see they have releases every 1-2 months lately
[09:07:37] <EvertL> i does go fast - in the last couple of weeks a bunch of bugs have been found
[09:21:08] <alex_joni> it looks like RTnet can be easily distributed as a deb
[09:21:44] <alex_joni> well kinda 'easily'
[09:27:41] <alex_joni> interesting .. :)
[09:27:43] <alex_joni> bbl
[10:02:49] <alex_joni> EvertL: back
[10:03:23] <alex_joni> EvertL: once there's a hal_rtnet driver in emc2, I think we can figure out ./configure to detect and use an installed rtnet
[10:03:29] <alex_joni> also adapt the various parts needed
[10:06:34] <Bo^Dick> how much current could one expect an avr-programmer to draw, 15mA, 50mA or 500mA?
[10:14:52] <alex_joni> I think 50
[10:16:07] <alex_joni> 20-30
[10:16:20] <alex_joni> maybe even less.. this is a parport programmer?
[10:43:23] <Bo^Dick> yepp
[10:45:36] <alex_joni> 10-20 typical
[10:45:50] <alex_joni> but powered from the target device
[10:47:56] <jepler> there will be very little current on the I/O lines. but if you're trying to power the AVR from the parallel port, it may be much more. For instance, attiny25 active at 8MHz is 8mA while attiny32 active at 8MHz is 15mA.
[10:48:44] <jepler> I couldn't find anything to say whether the current when self-programming is higher, those values are from a "max" column, though.
[10:53:53] <alex_joni> I usually power it from the target board
[10:53:59] <alex_joni> as that needs to be powered anyway
[10:54:25] <jepler> yeah I agree that's the best
[10:54:55] <alex_joni> btw, I started an ethernut yesterday (AtMega128 + RTL8019AS)
[10:54:59] <alex_joni> worked great ;)
[10:54:59] <jepler> but if you start asking "how much current" you must be talking about powering the CPU from the port -- otherwise the currents are going to be tiny
[10:55:02] <jepler> cool
[10:55:16] <jepler> any project in mind?
[10:56:35] <alex_joni> jepler: yeah..
[10:56:52] <alex_joni> jepler: for work (registering when people are coming and leaving)
[10:57:03] <alex_joni> I have an RFID reader on my desk ;) (serial interface)
[10:58:42] <alex_joni> does anyone around here play pool?
[10:59:24] <alex_joni> http://www.engr.colostate.edu/~dga/pool/bd_articles/index.html
[11:05:06] <jepler> alex_joni: I see
[11:15:23] <alex_joni> jepler: nothing fancy, it will load some php pages through eth, and receive the card id's through serial, then an LCD for displaying some data (user name, date/time, status.. things like these)
[11:17:14] <CIA-12> 03jepler 07HEAD * 10emc2/src/hal/halmodule.cc:
[11:17:14] <CIA-12> permit subscript addressing (e.g., comp['a.b-c']) so that pins with
[11:17:14] <CIA-12> non-identifier characters can be used. len(comp) gives the number of
[11:17:14] <CIA-12> pins-and-parameters.
[11:21:41] <alex_joni> jepler: seen my conversation with EvertL ?
[11:23:58] <CIA-12> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/axis.py:
[11:23:58] <CIA-12> create a component 'axisui' with pins 'axisui.jog.x' etc instead of creating
[11:23:58] <CIA-12> signals. optionally execute [HAL]POSTGUI_HALFILE after creating these pins.
[11:23:58] <CIA-12> (Incompatible change for those who were using axisui.jog.x signals.)
[11:24:01] <jepler> alex_joni: yeah I did read some of it
[11:25:24] <jepler> my first intuition was that 'read' should not wait for a packet to arrive, but should read one if available. if it doesn't receive a packet in some number of periods, then maybe it should assert an 'error-out' signal.
[11:27:16] <CIA-12> 03jepler 07HEAD * 10emc2/configs/sim/axis.ini:
[11:27:16] <CIA-12> since python now creates pins, the 'core_axis' signal hack is no longer needed.
[11:27:16] <CIA-12> get rid of it.
[11:27:16] <CIA-12> "document" POSTGUI_HALFILE in axis.ini
[11:27:16] <CIA-12> 03jepler 07HEAD * 10emc2/src/Makefile:
[11:27:16] <CIA-12> since python now creates pins, the 'core_axis' signal hack is no longer needed.
[11:27:18] <CIA-12> get rid of it.
[11:27:20] <CIA-12> "document" POSTGUI_HALFILE in axis.ini
[11:28:40] <CIA-12> 03jepler 07HEAD * 10emc2/src/Makefile: axis is no longer a target, phony or not -- it's built by 'make python'
[11:29:05] <jepler> "make .PHONY" sure does something interesting
[11:29:21] <jepler> surely that should be treated as an error instaed
[11:29:22] <jepler> instead
[14:52:27] <harty> cradek to course a thread and the slower i go the courser it gets
[14:53:29] <cradek> ok that's interesting
[14:53:38] <cradek> you know how to use halscope right?
[14:53:44] <harty> the gcode yep
[14:53:49] <harty> sort of
[14:54:07] <cradek> put a halscope on your spindle-pos signal and turn on the spindle
[14:54:21] <cradek> it should ramp up from 0 to 1.0 then drop back to 0
[14:54:27] <cradek> like this: /|/|/|
[14:54:39] <cradek> with the peaks being at 1.0
[14:55:14] <harty> k will just duck out to the shed back in a sec
[14:55:44] <cradek> oh no remote debugging :-)
[15:01:09] <harty> trouble with scope missing a setting wont log for longer than a sec or so
[15:01:49] <cradek> try using the servo thread instead of the base thread, or picking fewer channels (2) on the initial window
[15:02:08] <cradek> you can get 20-40? secs that way
[15:02:36] <SWPadnos> I think it's ~16k samples total, so 2 channels is 8 seconds in the servo thread
[15:02:54] <cradek> oh ok, seems longer when you're waiting for it
[15:02:58] <SWPadnos> heh
[15:03:16] <SWPadnos> you can also sample every Nth period
[15:03:54] <cradek> does that work now? I thought jmk said it was broken
[15:04:04] <SWPadnos> could be - I just remember the option being there :)
[15:04:38] <harty> yep that works
[15:05:53] <harty> getting a saw tooth looking patern
[15:06:10] <cradek> is it clean? what's the value at the peak?
[15:06:28] <Jymmm> The U.S. Government is officially withdrawing DES as an encryption standard
[15:07:03] <harty> yep looks good
[15:07:13] <SWPadnos> so they're saying that "Data Encryption Standard" isn't an encryption standard? ;)
[15:07:18] <harty> i think is one
[15:08:22] <cradek> heh, how sure are you?
[15:08:35] <harty> is there a scale for the grid
[15:08:37] <alex_joni> harty: vary the speed, and see if it looks the same
[15:08:49] <cradek> yes it's the slider on the right
[15:09:02] <cradek> it shows the value per division
[15:09:02] <Lerneaen_Hydra> 'lo
[15:10:23] <harty> scale 1/div the out put is 4 devisions verticaly and 3 horisontaly
[15:10:35] <harty> cant spell either:-)
[15:11:07] <cradek> ok your scale is wrong by a factor of 4
[15:11:07] <SWPadnos> aren't there "cursors" in halscope now?
[15:11:09] <cradek> brb
[15:14:36] <harty> cradek: in the setp encoder.0.position-scale ?
[15:16:50] <cradek> yes multiply that number by four
[15:16:59] <cradek> how many lines on your encoder?
[15:17:16] <harty> its got 1000ppr written on it
[15:17:40] <cradek> so you had 1000 in encoder.0.position-scale?
[15:17:44] <harty> which is what i have in the position scale
[15:17:48] <cradek> ok you probably need 4000
[15:18:06] <harty> k will try that
[15:18:46] <cradek> with so many pulses your spindle speed will be very restricted
[15:19:21] <harty> i have a 100ppr one also i can fit up
[15:19:37] <cradek> at what rpm do you want to thread?
[15:20:11] <cradek> 100 line (400 transition) is a very good choice for this application
[15:20:15] <harty> don't realy care at the moment just tinkering with cnc lathe stuff at the moment
[15:20:44] <cradek> at 4000 transition you will probably be limited to a couple hundred rpm
[15:21:30] <harty> so g33 z-1 k.05 should give me 20tpi at 1 inch long correct ?
[15:21:38] <cradek> yes
[15:21:59] <harty> cool will go and try it out back soon
[15:22:03] <cradek> if g20 mode
[15:22:08] <harty> yep
[15:22:13] <cradek> ok keep your spindle speed way down
[15:22:24] <harty> will do
[15:23:42] <Jymmm> http://www.thedenverchannel.com/news/9559707/detail.html
[15:29:40] <alex_joni> Jymmm: thanks for that link btw
[15:30:21] <harty> cradek that fixed it thanks
[15:30:26] <cradek> slick
[15:30:31] <cradek> how is your encoder mounted?
[15:31:18] <harty> http://www.cnczone.com/gallery/showphoto.php/photo/3291/cat/500/ppuser/13813
[15:31:21] <cradek> if you mount that 100 line I think you should be able to thread at 1000rpm (if your Z axis can keep up)
[15:31:43] <cradek> You must be a registered user to view images!
[15:31:53] <cradek> argh
[15:32:01] <harty> its should not be too hard to change
[15:32:09] <Jymmm> someone vreate a generic login and share it with us =)
[15:32:24] <cradek> yeah does someone have a login there?
[15:32:36] <Jymmm> alex_joni: I know a few of you fly alot, so I thought you might be interested.
[15:33:35] <alex_joni> cradek: I'm registering now
[15:33:52] <cradek> bugmenot gave me trebby/qwerty
[15:34:58] <jepler> are the pulleys 1:1?
[15:34:59] <cradek> cool, I guess that's geared 1:1 right?
[15:35:10] <harty> yep
[15:35:42] <cradek> that's the funny drive belt
[15:35:52] <Jymmm> Hey! A new use for emc: http://www.hackaday.com/entry/1234000507073793/
[15:36:13] <harty> on the spindle
[15:36:17] <harty> ?
[15:36:27] <cradek> yeah some segmented thing?
[15:37:17] <harty> its so i don't have to take the spindle out to replace the belt you just turn the clip and she comes apart
[15:37:27] <jepler> those huge screw terminals are probably overkill for this application. http://senior.billings.k12.mt.us/robots/unlock/pix/IMG_5008.html
[15:37:27] <cradek> neat
[15:37:43] <cradek> I've been dreading replacing mine (it's stretching a bit)
[15:38:18] <harty> they don't hold as well a a vbelt but there not bad
[15:38:45] <harty> seem to run with less vibration to
[15:39:07] <cradek> are these steppers driving ballscrews directly?
[15:39:14] <jepler> well, now I see that emc2 is way too complicated: http://senior.billings.k12.mt.us/robots/unlock/software/unloc.txt (hm, why do they use a separate counter for the clockwise motion and the counterclockwise motion (x and y)?)
[15:40:18] <harty> yep 12tpi ballscrews 5 phase 500 spr steppers
[15:40:27] <cradek> oh I see X is geared down a bit
[15:40:36] <Jymmm> jepler =)
[15:41:04] <harty> a little only because i didn't have to pullys the same size
[15:41:24] <alex_joni> * alex_joni thinks this does work better: http://media.weblogsinc.com/common/videos/barb/hackaday/x04d_masterlock.avi
[15:41:26] <Jymmm> jepler: For SG Group II locks, you can buy the machine for around $4000
[15:42:06] <cradek> harty: what kind of speed do you get on Z?
[15:42:55] <harty> about 90ipm with no load and 70ipm loaded right up
[15:43:28] <cradek> nice, if you change the encoder I bet you can thread at 60ipm like my sherline
[15:45:12] <harty> cool will change it over its on my other lathe as a z axis dro bit low res for that so it should work out fine
[15:46:44] <cradek> are you running a cvs version of emc or version 2.0.3?
[15:46:56] <harty> 2.0.3
[15:47:12] <cradek> ok you won't have g76 then
[15:48:17] <harty> whats g76 give me
[15:48:59] <cradek> multipass threading, compound infeed, equal-area passes, etc
[15:49:33] <Jymmm> alex_joni: padlock shims have been around for a long time, thus whay I like American (brand) padlocks, you can't use a shim on them, they're not spring loaded.
[15:49:59] <cradek> also in cvs is tool shape compensation and XZ tool offsets for lathes
[15:50:59] <cradek> this will all be in 2.1.0
[15:51:15] <harty> cool might need to look at the cvs version off sets coud be handy imusing mastercam for gcode and that takes care of tool shape comp
[15:51:40] <harty> time frame for 2.1.0 and will it have css?
[15:52:36] <cradek> 2.1.0 will be this year sometime (goal is sep-oct), not sure about css yet.
[15:52:43] <cradek> do you have spindle speed control?
[15:53:23] <harty> not yet been looking for a cheep vfd on ebay
[15:54:04] <harty> can you get emc to display spindle rpm ?
[15:54:21] <alex_joni> harty: he can ;)
[15:54:29] <cradek> anything's possible :-)
[15:54:47] <alex_joni> harty: joke aside, there are some changes needed to be able to do that properly
[15:54:56] <alex_joni> but it should be done (and displayed by the GUI's)
[15:55:11] <cradek> displaying commanded rpm would be pretty easy
[15:55:16] <cradek> displaying feedback rpm is harder
[15:56:05] <harty> as feedback you mean actual machine rpm ?
[15:56:14] <cradek> yes as sensed by that encoder
[15:56:19] <harty> k
[15:57:02] <Jymmm> Friends dont let friends use AOL... http://plentyoffish.wordpress.com/2006/08/07/aol-search-data-shows-users-planning-to-commit-murder/
[15:57:58] <cradek> harty: did this lathe have change gears and you just removed it all?
[15:58:50] <harty> yep pretty basic ones though
[15:59:10] <cradek> it would make me happy to do that on my big lathe - I hate those gears
[15:59:42] <cradek> cnc is sure nice for threading
[15:59:57] <cradek> any ratio you want is just as easy as any other
[16:00:00] <Jymmm> cradek is there an alternative?
[16:00:12] <alex_joni> Jymmm: manual lathes have some sort of gearing
[16:00:14] <cradek> Jymmm: sure, a complicated series of gears
[16:00:17] <Jymmm> ah
[16:00:19] <alex_joni> mechanically coupling feed to spindle speed
[16:00:31] <cradek> Jymmm: often you chain together 4-5 of them to get the ratio you need for a certain thread
[16:00:32] <Jymmm> forgot about that =)
[16:00:40] <cradek> yeah it's pretty primitive isn't it
[16:00:46] <harty> on the big lathe i have a stepper setup for surfacing just so i don't have to run the back gears
[16:00:56] <Jymmm> No, just that I dont have nor have ever touched a lathe
[16:01:11] <Jymmm> just read about it on HF
[16:01:32] <cradek> Jymmm: then there's the 127 toothed gear to cut metric on an inch leadscrew or the other way around
[16:01:55] <Jymmm> cradek at least it's possible
[16:06:11] <harty> thanks for the help cradek its time for bed for me 2am here and i will let you know how the other encoder goes
[16:06:26] <cradek> you're welcome, goodnight
[16:06:32] <cradek> glad we found the problem so quickly
[16:06:33] <harty> night all
[16:06:41] <harty> for sure
[16:07:08] <alex_joni> australia .. nice :)
[16:09:46] <Jymmm> Going to Thailand and plan on using your credit card? http://www.theregister.co.uk/2006/08/04/thai_wiretap_scam/
[16:10:21] <alex_joni> oh.. that reminds me.. didn't read BOFH in a while
[16:10:29] <alex_joni> * alex_joni is busy for a bit
[16:21:06] <Jymmm> I like this idea... http://www.ex-parrot.com/peter/upside-down-ternet.html
[16:27:37] <alex_joni> fun
[16:27:53] <cradek> http://timeguy.com/cradek-files/emc/lathepart.jpg
[16:28:01] <cradek> this is nice (taken from harty's gallery)
[16:28:11] <cradek> it's a little hard to make that shape without cnc...
[16:34:19] <alex_joni> looks like a chair thingie
[16:35:17] <JymmmEMC> what does?
[16:36:33] <JymmmEMC> Is axis 0,1,2 ~= X,Y,Z ?
[16:37:32] <JymmmEMC> in the ini I mean
[16:37:34] <alex_joni> Jymmm: for trivkins yes
[16:37:45] <alex_joni> Jymmm: if your machine is conventional .. yes
[16:38:00] <JymmmEMC> a/me is NEVER conventional
[16:38:04] <alex_joni> Jymmm: that won't be true for hexapods, scara, puma robots.. etc
[16:38:10] <JymmmEMC> ah, ok
[16:39:11] <JymmmEMC> and acceleration is like 0 to 60 in a quarter mile; velocity being the fasts speed?
[16:41:05] <cradek> velocity is what your speedometer says
[16:41:20] <cradek> acceleration is the amount you feel being pushed back (or forward when braking) in your seat
[16:41:40] <JymmmEMC> Ok,I usually reverse the two.
[16:41:49] <JymmmEMC> at least in my brain that is =)
[16:45:05] <JymmmEMC> Um, there's no mention of COUNTS_PER_REV or REVS_PER_UNIT in the stepper_inch.ini
[16:45:11] <JymmmEMC> in the axis section
[16:45:21] <alex_joni> bbl
[16:45:24] <jepler> It's called INPUT_SCALE
[16:45:45] <jepler> for stepper systems it's steps per unit
[16:46:07] <JymmmEMC> I was just reading this: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?SectionsAxis
[16:47:19] <jepler> I see
[16:47:41] <JymmmEMC> near the bottom of that page.
[16:47:41] <jepler> I've never heard of COUNTS_PER_REV and REVS_PER_UNIT
[16:47:46] <jepler> I see them on that page, though
[16:47:50] <JymmmEMC> k
[16:48:39] <jepler> I searched the whole source tree of emc2 and I don't see any use of those items
[16:48:55] <jepler> same for at least one other: SHAFT_OFFSET
[16:49:03] <jepler> anybody know if these used to have a meaning (in emc1 or something)?
[16:49:37] <cradek> I think in emc1 there was a motor simulation
[16:49:48] <cradek> there was all sorts of stuff about torque/mass in the ini
[16:56:51] <JymmmEMC> So INPUT_SCALE = Steps_per_revolution * Leadscrew_Turns_per_inch * microstepping * gear_ratio
[16:58:09] <JymmmEMC> 16000
[16:58:17] <JymmmEMC> ?
[16:58:37] <jepler> yeah
[16:58:46] <jepler> ooh lunchtime
[16:58:53] <JymmmEMC> whats for lunch?
[16:59:03] <jepler> dunno yet
[16:59:12] <A-L-P-H-A> svn fails miserably.
[16:59:12] <JymmmEMC> OK! Saves me some then !
[17:05:42] <JymmmEMC> What's SVN?
[17:19:31] <A-L-P-H-A> Jymmm, you're not programming are you?
[17:20:02] <Jymmm> is that a variant of CVS
[17:21:03] <A-L-P-H-A> the successor.
[17:21:20] <A-L-P-H-A> the repository has me locked out of a folder.
[17:21:21] <A-L-P-H-A> odd
[17:21:23] <A-L-P-H-A> whatever.
[17:26:30] <alex_joni> back
[17:27:36] <alex_joni> jepler: never heard of SHAFT_OFFSET
[17:57:39] <JymmmEMC> In respect to the stepper ini, what is "USER UNITS" ?
[17:58:03] <cradek> the UNITS= specification
[17:58:11] <cradek> that's how you make your units inches or mm
[17:58:38] <JymmmEMC> In the user manual is says DEFAULT_VELOCITY in user units
[17:58:51] <cradek> vel is user units/sec
[17:59:13] <JymmmEMC> the defualt value in the sampel ini is 1.2
[17:59:22] <JymmmEMC> 1.2 ips ?
[17:59:27] <cradek> yes
[17:59:37] <JymmmEMC> really?!
[18:00:07] <JymmmEMC> oh, nm confused the two again
[18:00:10] <cradek> that's a perfectly nice velocity
[18:00:35] <JymmmEMC> velocity == speedometer, correct?
[18:00:42] <cradek> yes
[18:01:13] <JymmmEMC> oh wait ips, not ipm
[18:01:17] <cradek> brb
[18:01:19] <JymmmEMC> * JymmmEMC sighs
[18:01:53] <JymmmEMC> 1.2ips == 72ipm, that makes sense. lol
[18:02:10] <JymmmEMC> too many mental conversions goin on here =)
[18:03:04] <A-L-P-H-A> JymmmEMC, that's a problem with EMC, it's too freak'n difficult to setup... jepler had a config generator that worked semi decently.
[18:03:33] <etla> anyone good at Python ? specifically how modules are imported ?
[18:03:39] <A-L-P-H-A> I'm in heaven right now... as the peice of meat that was stuck in between my morals is gone... the pain is GONE!
[18:03:51] <A-L-P-H-A> etla, several, but not me.
[18:03:51] <jepler> A-L-P-H-A: do you mean "morals" or "molars"?
[18:03:56] <A-L-P-H-A> molars.
[18:03:57] <A-L-P-H-A> :)
[18:03:58] <A-L-P-H-A> hehe.
[18:04:10] <JymmmEMC> Well, even with the user manual, and the wiki, dont help matters any.
[18:04:12] <A-L-P-H-A> see... jepler knows all!
[18:04:18] <JymmmEMC> s/dont/didnt/
[18:04:18] <A-L-P-H-A> see... jepler he could even read my mind.
[18:04:33] <A-L-P-H-A> s/didnt/didn't/
[18:04:35] <A-L-P-H-A> :P
[18:04:51] <jepler> etla: the directories in sys.path are inspected from start to finish for the requested module. When it's a package ('import curses.panel') it's a bit more complicated.
[18:04:55] <JymmmEMC> A-L-P-H-A: grammar nazi
[18:05:16] <A-L-P-H-A> JymmmEMC, that's "Mr. Grammer Nazi" to you.
[18:05:21] <jepler> etla: The directories from PYTHONPATH are prepended to some directories that depend on the location of the python executable
[18:05:27] <JymmmEMC> jepler: I need to bug you when you have a sec.
[18:05:44] <jepler> etla: so, with all that in mind, do you have a problem you're trying to solve?
[18:05:48] <etla> jepler: I think the correct file is sitting in the directory Lib/site-packages/vtk/wx
[18:05:50] <jepler> JymmmEMC: go ahead
[18:06:12] <etla> jepler: but import doesnt find the file
[18:06:42] <jepler> etla: is /path/to/Lib/site-packages on your sys.path? python -c 'import sys; print sys.path'
[18:07:13] <JymmmEMC> jepler: : I talked to chris last night and he siggested I ask you. In axis, how do you change the color of the cone? DkGrey on Blk bg isn't contrasting enough for me. He suggested doin the gamma thing, but I keep the brightness VERY low or I get headaches.
[18:08:00] <etla> jepler: there is lib/site-packages/ but not the specific directory the file is in...
[18:08:15] <etla> how do I add that to sys.path parmanently ?
[18:08:41] <etla> and why does sys.path use double slashes \\ ?
[18:09:11] <jepler> JymmmEMC: that's hard-coded right now
[18:09:41] <jepler> etla: you're on Windows and '\\' is the way Python displays a string which contains a single backslash (backslash is a sort of escape character for strings)
[18:09:48] <JymmmEMC> jepler: compiled or something I could edit in a text editor?
[18:10:19] <jepler> etla: you can set the PYTHONPATH environment variable. If /path/to/Lib/site-packages/vtk needs to be in sys.path, then set PYTHONPATH=/path/to/Lib/site-packages/vtk
[18:11:02] <jepler> JymmmEMC: these two lines control the color of the cone in a more or less obscure way:
[18:11:05] <jepler> ./lib/python/rs274/OpenGLTk.py: glLightfv(GL_LIGHT0, GL_AMBIENT, (.4, .4, .4, 1))
[18:11:08] <jepler> ./lib/python/rs274/OpenGLTk.py: glLightfv(GL_LIGHT0, GL_DIFFUSE, (.6, .6, .6, 1))
[18:11:22] <JymmmEMC> jepler: the ,1 being the alpha channel?
[18:11:39] <jepler> you have the version with a transparent cone?
[18:12:10] <JymmmEMC> jepler: no idea, just say four digits in that code R, G, B, A is what I assumed
[18:12:18] <JymmmEMC> ssay/saw/
[18:12:27] <jepler> "1" corresponds to the alpha channel, but in the last packaged version of emc2-axis it's basically ignored
[18:12:42] <jepler> in the CVS version, it's still ignored, but an alpha value specified elsewhere is used instead
[18:12:52] <JymmmEMC> jepler: 0-15 being the colors available?
[18:13:33] <jepler> the other 3 values are red, green, and blue ranging from 0.0 to 1.0.
[18:13:53] <JymmmEMC> oh, didn't see the decimal point.
[18:15:11] <JymmmEMC> jepler: Thanks, I'll play with that once I finish editing the ini
[18:17:13] <etla> jepler: so now the import statement works, but I get TypeError: 'module' object is not callable
[18:22:38] <jepler> etla: well, they aren't.
[18:22:38] <jepler> >>> import sys
[18:22:38] <jepler> >>> sys()
[18:22:41] <jepler> TypeError: 'module' object is not callable
[18:22:53] <jepler> maybe you need to use a function or class from the module?
[18:23:28] <etla> but the .py file has the same name as the class... so I thought that is the name of the module also...
[18:24:55] <jepler> instance = modname.classname() # even if modname and classname are the same
[18:25:14] <etla> ok, that makes sense, let's try that...
[18:25:52] <etla> yeah, it worked !
[18:26:24] <etla> I just thought the unit test code should work if I copy/pasted it into a separate file and did the appropriate imports
[18:26:49] <etla> apparently not, the constructor needs to be modified also: xVTKRenderWindowInteractor.wxVTKRenderWindowInteractor(frame, -1)
[18:27:26] <etla> thanks jepler
[18:37:32] <alex_joni> argh.. this sux :(
[18:37:47] <alex_joni> when I register the ethernet device, the lcd stops working properly
[18:38:06] <alex_joni> and the other way around :/
[18:38:41] <etla> more acpi related problems ?
[18:38:56] <alex_joni> no, this is embedded (some micro+ethernet board)
[18:39:01] <alex_joni> www.ethernut.de
[18:40:06] <etla> what are you going to use it for ?
[18:40:30] <alex_joni> etla: some project (not emc related)
[18:41:01] <etla> clearly you've signed an nda ;)
[18:43:56] <CIA-12> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/extensions/minigl.c: add a blending constant
[18:44:33] <CIA-12> 03jepler 07HEAD * 10emc2/lib/python/propertywindow.py: remove str() so that unicode property strings work
[18:44:56] <alex_joni> etla: no, just wanting to get home faster (almost 10pm)
[18:45:27] <JymmmEMC> MIN_LIMIT = -2.0 is that machine travel limit?
[18:45:47] <cradek> yes for that axis
[18:45:48] <alex_joni> JymmmEMC: yeah
[18:46:01] <alex_joni> * alex_joni runs home
[18:46:06] <etla> cradek: are you sure it's not joint ? ;)
[18:49:23] <alex_joni> etla: in the ini it's called AXIS
[18:49:31] <alex_joni> although it should be joint :D
[18:50:11] <etla> more fun that way I guess
[18:50:32] <JymmmEMC> I've been accustom to (under TurboCNC) to set Z zero to top of material, and XY zero to bottom left corner. all relative, menaing I'll zero out to where the workpiece in mounted on the machine. Is there anything I need to do set in the ini to keep doing things this way?
[18:51:13] <etla> not really, just make sure the softlimits are larger or the same as your real working envelope
[18:52:57] <JymmmEMC> k
[18:53:26] <JymmmEMC> I guess I'll have to "calirbate the machien somehow, there are no limit/home switches on it.
[18:53:51] <etla> as long as you dont have very big steppers you should be ok
[18:54:10] <etla> they just buzz when you drive them to the limit and nothing brakes (hopefully)
[18:54:52] <JymmmEMC> Well, if I specifify soft limts and the steppers stall for whatever reason, then it could easily hit a softlimit
[18:55:27] <JymmmEMC> Many times I'm able to recover from a stall, as long as the controllers doens't muck me up.
[18:55:37] <etla> the idea is that softlimits will prevent a real crash. it is not possible from mdi or g-code to make the machine go outside the soft limits
[18:55:59] <JymmmEMC> etla: unless they stall
[18:56:27] <etla> well then you loose position and hopefully you have a reference position on the part or a fixture or something to back to...
[18:57:32] <JymmmEMC> Right, but if X stalled, and Y is at 12.54321 I still have Y at a known location, but if the controller mucks up and doens't let me change the position of X, I'm screwed.
[18:58:34] <JymmmEMC> or let me change what IT thinks it as that is =)
[18:58:52] <etla> during a g-code program, it's probably better to hit feedhold/pause. e-stop means you have to start the program from the beginning
[18:59:23] <JymmmEMC> sometimes that's not a bad thing =)
[18:59:43] <JymmmEMC> gives you an opportunity to see if you can recover or not
[19:00:10] <JymmmEMC> if it's cutting more than it should, you know you reset it wrong and just scrap it
[19:01:43] <etla> i gotta go, good night
[19:01:47] <JymmmEMC> G'Night
[19:02:31] <JymmmEMC> alex_joni: you home yet?
[19:04:54] <CIA-12> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: make tool appearance (lighting, color, alpha) configurable through the X resource database
[19:04:54] <CIA-12> 03jepler 07HEAD * 10emc2/lib/python/rs274/options.py: make tool appearance (lighting, color, alpha) configurable through the X resource database
[19:05:55] <jepler> JymmmEMC: "zero" (machine origin) the machine by eye -- just pick any convenient position and call it X=0 Y=0 Z=0. Then use offsets ("Touch Off" in axis) to put the offset origin in the right place for your g-code file.
[19:06:26] <jepler> JymmmEMC: that way you get the benefit of soft limits -- even without limit switches, conservative soft limits will stop you from moving an axis too far
[19:06:37] <JymmmEMC> jepler: Ah, ok.
[19:07:07] <JymmmEMC> I set XY to -0.5 and 24.5 so I "should" be safe there.
[19:09:02] <JymmmEMC> Now, I'm just trying to figure out Z. Since I use top of material as ZERO, and in the material as a negative value. What I shouls set the min/max limits for it to be. total z travel is 5 inches
[19:09:41] <cradek> I like to load the tool and place it near the table, and set that as home
[19:09:41] <JymmmEMC> sounds like -5 and 0
[19:09:50] <cradek> my negative limit is 0
[19:10:01] <cradek> that prevents an errant program from being able to cut the table
[19:10:48] <cradek> it doesn't give me a very useful positive limit, though
[19:10:51] <JymmmEMC> When I need to cutout a piece, it needs to go past the material and into the table
[19:11:06] <JymmmEMC> by like .01
[19:11:08] <JymmmEMC> "
[19:11:58] <cradek> oh you have an expendable table, that's different
[19:12:18] <JymmmEMC> Yeah, MDF with a grid of 400 holes
[19:12:20] <cradek> still you could set the neg limit to -.02 or so
[19:12:42] <JymmmEMC> Right, but I use the top of the material as Z zero
[19:13:00] <cradek> hang on a sec, you're confusing machine and offset coordinates
[19:13:06] <JymmmEMC> and a negative Z being IN the material.
[19:13:16] <JymmmEMC> probably =)
[19:13:30] <JymmmEMC> I'm still editing the ini atm.
[19:13:31] <cradek> limits are in machine coordinates, which do not change no matter what work is mounted where
[19:13:49] <cradek> you cut in an offset coordinate system that makes sense for the workpiece
[19:14:04] <JymmmEMC> right.
[19:14:26] <cradek> you can do everything in machine coordinates (sounds like what you did with turbo) but that gives you no protection
[19:14:38] <JymmmEMC> but in the ini file for min/max limits, should it be 0 5 or -5 0
[19:14:56] <cradek> if you think you're in metric but you're actually in inch when you program g0x100, you'll get a crash without limits
[19:15:11] <cradek> with limits, you just get "move out of range" error
[19:15:28] <cradek> you have to set up the limits however they make sense for you
[19:15:32] <JymmmEMC> no, no, I dont mind haveingthe soft limits, I'm just trying to determine their values.
[19:15:46] <cradek> locate where you want 0 to be, mark it somehow, and measure the travel on both sides of that position
[19:15:49] <JymmmEMC> Min_limit 0 or min_limit -5
[19:16:00] <cradek> it depends where 0 is
[19:16:27] <JymmmEMC> 0 being top of material
[19:16:44] <JymmmEMC> not top of table
[19:16:50] <cradek> no, machine 0
[19:16:57] <cradek> the home position
[19:17:23] <JymmmEMC> ah, ok
[19:17:32] <cradek> you have to decide where you want it
[19:17:41] <cradek> anywhere you can jog to and see easily, the same every time
[19:18:26] <JymmmEMC> Is "home" suppose to be a location where you want the axis to be like for loading/unloading or change tools as example?
[19:18:37] <cradek> it can be, but doesn't have to be
[19:19:38] <JymmmEMC> so I can have Z home be touching the tabletop or max top travel
[19:19:42] <cradek> your goal is just to pick a position for each axis that you can locate by jogging
[19:19:57] <cradek> sure you could use either of those
[19:20:14] <cradek> preferably not touching, "close to"
[19:21:43] <JymmmEMC> ok, so table top being 0, so set min to be 4.75 and max to be -.25 ?
[19:21:58] <JymmmEMC> or the other way around?
[19:22:00] <cradek> the other way, min should be less than max
[19:22:09] <JymmmEMC> k
[19:22:22] <cradek> if your full travel is 5, you'll want the limits to be a little less
[19:22:31] <JymmmEMC> right.
[19:22:52] <JymmmEMC> then set "home" to something like 2"
[19:24:43] <cradek> so where's Z=0?
[19:25:06] <JymmmEMC> Home in the ini I set to 2.0, now when I'm doing offsets, and tell it to "home" it'll still be 2" above the workpiece?
[19:25:28] <JymmmEMC> or absolute machien 2.0
[19:25:31] <cradek> argh I need to write a wiki page or something
[19:25:51] <cradek> wherever you can easily locate on your Z axis (mark it with a sharpie), call it Z=0
[19:25:55] <JymmmEMC> Z=0 would be top or table
[19:26:07] <JymmmEMC> of not or
[19:26:08] <cradek> set your two limits so you can't crash Z into anything
[19:26:19] <SWPadnos> I thikn it's more common to call the highest Z extent 0, and let the number go negative
[19:26:33] <JymmmEMC> Yeah, that I got when you said MACHINE zero, and not material zero
[19:26:33] <SWPadnos> so -5 (or whatever) woiuld be the table top
[19:27:41] <JymmmEMC> SWPadnos: I was sorta thinking that. as when I set zero to top of material, a negative move goes into the material
[19:27:43] <cradek> maybe, but it doesn't matter, 0 is wherever he wants the axis to be when he presses 'home' after starting emc
[19:28:10] <SWPadnos> right - top of table might hamper the placement of material to be machined :)
[19:28:19] <cradek> at the top is fine, you'd start emc, jog up to the top, press home, the Z coordinate changes to 0
[19:29:53] <cradek> then put in the tool, jog down to the top of the work, hit End (if using AXIS), hit return to accept the default 0.0 value, now your offset coordinate system is set right for cutting
[19:29:56] <JymmmEMC> MIN_LIMIT = -0.020
[19:29:57] <JymmmEMC> MAX_LIMIT = 4.5
[19:31:20] <JymmmEMC> ok, not a big deal. if it doesn't work with these values they way I want it, I'll change em.
[19:32:25] <JymmmEMC> =)
[19:32:53] <JymmmEMC> ok, now to try this out =)
[19:36:52] <JymmmEMC> Heh, I'm chicken to turn it on! LOL
[19:38:22] <SWPadnos> get a pulse rate monitor into the e-stop chain ;)
[19:40:24] <JymmmEMC> say what?
[19:41:58] <cradek> it would be really great if you could monitor that jump in your gut that happens when something is going wrong
[19:42:10] <JymmmEMC> lol
[19:44:30] <JymmmEMC> oh fsck.... following errors!!!!!!!!!!!!
[19:45:47] <JymmmEMC> argh! join 1 following error
[19:46:59] <JymmmEMC> I can't even jog 70ipm without a following error. Did I misconfigure soemething?
[19:47:18] <SWPadnos> stepgen_max_vel?
[19:47:25] <SWPadnos> (or is that gone now?)
[19:47:28] <JymmmEMC> 1.4
[19:47:42] <SWPadnos> and max_vel for the axis?
[19:47:51] <JymmmEMC> 1.2
[19:47:59] <SWPadnos> hmm
[19:48:08] <SWPadnos> what about stepgen_max_accel?
[19:48:11] <SWPadnos> (and axis max accel)
[19:48:16] <JymmmEMC> 21
[19:48:30] <JymmmEMC> 20
[19:48:32] <cradek> base period and input scale?
[19:48:37] <SWPadnos> what are the OUTPUT_SCALE and BASE_PERIOD
[19:48:39] <SWPadnos> right
[19:49:13] <JymmmEMC> base 50000,
[19:49:53] <JymmmEMC> input scale is 16000, output scale is 1.0 0.0
[19:50:09] <SWPadnos> you shouldn't even get to 70 IPM then
[19:50:16] <jepler> You have: 16000 * 2 * 1.2 / second
[19:50:16] <jepler> You want: microsecond
[19:50:16] <jepler> reciprocal conversion
[19:50:16] <jepler> * 26.041667
[19:50:37] <jepler> to achieve 16000 * 1.2 steps per second, you need a lower BASE_PERIOD, under 26.mumble microseconds
[19:51:01] <SWPadnos> what is the CPU speed and chipset of this machine?
[19:51:20] <JymmmEMC> Dell P3 600
[19:51:51] <JymmmEMC> rtai test gave me ovl_max of 17500
[19:51:57] <SWPadnos> ok. that should be capable of 20-25 uS base period
[19:52:24] <cradek> I run my P3 at 25
[19:52:41] <JymmmEMC> cradek: microstepping?
[19:52:46] <JymmmEMC> 8
[19:52:47] <SWPadnos> yep. I have a celeron 500 that's fine at 20, and I think I've had it down to 16 before
[19:52:48] <cradek> JymmmEMC: how many microsteps?
[19:52:57] <cradek> JymmmEMC: can you change it to 4?
[19:52:57] <JymmmEMC> cradek: 8
[19:53:08] <JymmmEMC> no, xylotex
[19:53:12] <cradek> crap
[19:53:19] <cradek> you'd be much happier at 4.
[19:53:30] <JymmmEMC> not with the stalling I wouldn't =)
[19:54:27] <JymmmEMC> ok, let me change the base period. Guess I need to shut down emc for that to take effect?
[19:54:37] <jepler> ye
[19:54:38] <jepler> s
[19:54:59] <SWPadnos> the same is true of all ini file settings, I believe
[19:55:17] <cradek> yep
[19:56:44] <JymmmEMC> I suspected, but had to ask =)
[19:57:30] <JymmmEMC> jog speed max value == max acceleration?
[19:58:01] <cradek> I think jogs always accel at the axis maxaccel
[19:59:38] <JymmmEMC> the highest speed it'll let me jog at is 72/ipm, I want to try increasing that.
[19:59:49] <SWPadnos> that's set by the 1.2 max_vel
[20:00:07] <SWPadnos> but if you want to go faster, you'll need an even smaller BASE_PERIOD
[20:00:16] <JymmmEMC> base 20000
[20:00:52] <SWPadnos> that'll help - you should be able to get 25k steps/sec with that
[20:01:28] <SWPadnos> (still only ~1.6 IPM at 16000 steps/inch)
[20:01:58] <JymmmEMC> 90ipm, 1.6ips
[20:02:12] <SWPadnos> 1.6 is too high - you should set it to 1.5
[20:02:20] <SWPadnos> 1.6 needs 25600 steps/sec :)
[20:02:28] <JymmmEMC> Damn, Jog Speed in axis is still at 72 in/min
[20:02:47] <cradek> you missed the [TRAJ] section then
[20:04:41] <JymmmEMC> ah, ty. What value to I need to change to have less increments?
[20:05:06] <cradek> I think that's not configurable
[20:06:59] <CIA-12> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/Submakefile:
[20:06:59] <CIA-12> start of an 'ini lint' program. So far, it only tries to detect that
[20:06:59] <CIA-12> BASE_PERIOD is too small for the number of steps per second
[20:07:00] <CIA-12> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/lintini.py:
[20:07:00] <CIA-12> start of an 'ini lint' program. So far, it only tries to detect that
[20:07:00] <CIA-12> BASE_PERIOD is too small for the number of steps per second
[20:07:11] <SWPadnos> heh
[20:08:14] <JymmmEMC> Well, I got 90ipm without issue (except Z - stalling)
[20:08:29] <JymmmEMC> will change Z values lower
[20:08:30] <jepler> ./bin/lintini configs/stepper/stepper_inch.ini
[20:08:30] <jepler> Appears to be a stepper configuration
[20:08:30] <jepler> Max Velocity 1.4 and scale 16000 require BASE_PERIOD below 22321
[20:08:30] <jepler> One problem found
[20:08:45] <cradek> cool
[20:08:57] <cradek> how about a stepgen headroom check too?
[20:09:17] <JymmmEMC> Lets try 1.8 =)
[20:10:58] <JymmmEMC> Is there a way I can create an desktop icon that bypasses the startup menu?
[20:11:27] <cradek> yes, you can specify the config on the commandline
[20:12:10] <jepler> so the desktop icon would execute: emc /path/to/your.ini
[20:12:20] <jepler> Max Velocity 1.2001 and scale 16000 require BASE_PERIOD below 26039
[20:12:21] <jepler> Less than 1% velocity headroom from 1.2 to 1.2001
[20:12:21] <jepler> Less than 1% acceleration headroom from 20 to 20.1
[20:12:21] <jepler> 3 problems found
[20:12:21] <JymmmEMC> ok
[20:12:49] <CIA-12> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/lintini.py: check for headroom
[20:14:24] <jepler> there doesn't seem to be a standard ini field for the setup and hold times of the step signal
[20:14:28] <jepler> so I'm just assuming 2 base periods
[20:16:20] <JymmmEMC> ok, it doesn't like 108ipm =)
[20:16:44] <JymmmEMC> hmmmm, lets change the BASE_PERIOD to 19000 =)
[20:16:57] <cradek> http://i2.photobucket.com/albums/y11/solcofn/29589143_411b52e557.jpg
[20:17:48] <Jymmm> ROTF!!!
[20:19:36] <jepler> L???
[20:22:08] <SWPadnos> just rolling, I guess
[20:22:34] <JymmmEMC> lol
[20:22:52] <JymmmEMC> ok, base @ 19500 I can get about 97ipm
[20:23:35] <JymmmEMC> Q: I have Z set to much lower in the ini, when I jog in AXIS, is it trying to jog at the same 97ipm rate?
[20:24:13] <cradek> the jog speed slider defaults to DEFAULT_VELOCITY but you can set it as high as MAX_VELOCITY
[20:24:42] <JymmmEMC> ok, let me lower Z in the ini and try again.
[20:26:34] <JymmmEMC> max velocity of the traj section, or of the axis section ?
[20:27:57] <JymmmEMC> ok, nm
[20:33:27] <JymmmEMC> ok, 97 ipm it is. I would if I cna lower the base period if I kill X and do xforwarding from the laptop?
[20:34:10] <SWPadnos> it may help, but then again, the network driver may introduce more jitter
[20:34:24] <SWPadnos> (they may have longer critical sections)
[20:34:24] <JymmmEMC> not to bention the encryption
[20:34:31] <JymmmEMC> mention
[20:34:44] <SWPadnos> indeed
[20:35:15] <cradek> don't make me do the bunny picture again
[20:35:48] <JymmmEMC> Robin mentioned something about opening on a remote machien xopen iirc, I tried but complained about a file
[20:36:19] <cradek> I like to run my machines slower than the absolute max and revel in how reliably everything works
[20:38:31] <Jymmm> Dont make me send the attack bunny after you now.... http://www.spcaec.com/images/content/photos/large_10815.jpg
[20:40:14] <SWPadnos> it's a ferocious beast
[20:42:23] <Jymmm> sniper bunny!!!!!!!!!!!!!
[20:42:59] <Jymmm> If I do remote the emc way, I would have to have the latest AXIS on the remote laptop, correct?
[20:43:44] <SWPadnos> it's a little bit of a PITA that way, because you need to have all G-code files in the exact same locations on both PCs
[20:43:57] <SWPadnos> it does work though
[20:44:10] <Jymmm> why on BOTH machine? just on the emc box
[20:44:26] <SWPadnos> incidentally, if you used TurboCNC, you might try keystick. I think it's been fixed for use with emc
[20:44:43] <jepler> SWPadnos: it's not in the emc 2.0.3 deb packages
[20:44:54] <SWPadnos> both machines, sicne the UI browses for the file on the local machine, and tells emc the absolute path via NML
[20:45:16] <SWPadnos> jepler, ok. I thought it was fixed up (by you?) a couple of months ago
[20:45:28] <jepler> SWPadnos: somebody else fixed it, I'm not sure why it's not in the debs
[20:45:36] <cradek> it's not in the 2.0 branch
[20:45:43] <jepler> that would explain it
[20:45:44] <cradek> neither is xemc
[20:45:56] <SWPadnos> ok then
[20:46:11] <SWPadnos> ok - alex fixed it
[20:46:15] <Jymmm> why not?
[20:46:33] <SWPadnos> err - not enough quality control testing?
[20:46:52] <Jymmm> horse poo poo
[20:47:01] <SWPadnos> (that sounds better than lazy programmers ;) )
[20:47:05] <jepler> Jymmm: because it wasn't done by the time we released 2.0, and we only fix bugs for 2.0.x. The new features wait for 2.1, whenever that's ready
[20:47:10] <cradek> you don't add features to a release branch
[20:47:15] <Jymmm> ah
[20:47:18] <SWPadnos> right - what they said.
[20:47:23] <SWPadnos> pthbthtbhthbtht
[20:47:33] <cradek> it's a matter of discipline, not laziness!
[20:47:39] <Jymmm> ha
[20:47:43] <SWPadnos> right - that's what I meant
[20:47:49] <cradek> haha
[20:48:00] <Jymmm> double horse poo poo
[20:48:08] <SWPadnos> ca ca
[20:48:19] <Jymmm> right - tha'ts what I meant
[20:48:22] <jepler> I always thought it was "ka ka"
[20:48:40] <SWPadnos> wakka wakka
[20:48:50] <JymmmEMC> ok, gonna try xfwd now...
[20:56:02] <Jymmm> Uh oh.... X eeor of failed request: GLXRenderRequest
[21:00:46] <Jymmm> wth?! I can start any other ini, but the one i created?!
[21:01:13] <Jymmm> well, let me test that theory
[21:01:14] <cradek> what's the X server you're trying to display to?
[21:01:49] <Jymmm> the old bdi I have on the laptop
[21:02:03] <cradek> it must have broken opengl
[21:02:17] <cradek> I bet you'll be able to run the other guis - but not axis
[21:02:24] <cradek> goodnight, I'm off
[21:02:29] <Jymmm> Night cradek
[21:04:19] <Jymmm> Weird, I was able to run sim axis yesterday. Musta been on ubuntu5 and not 6 though
[21:30:04] <mdynac> greetings from Cheeseland.....
[21:30:13] <Jymmm> the moon ?
[21:30:29] <mdynac> tis wisconsin
[21:30:43] <mdynac> close tho...
[21:30:51] <Jymmm> same diff... million miles away from everything =)
[21:30:58] <Jymmm> j/k =)
[21:31:01] <mdynac> ya
[21:31:12] <mdynac> hey dare
[21:31:35] <mdynac> just on vacation....thats why i'm up here to get away
[21:31:57] <Jymmm> Wait...
[21:32:17] <Jymmm> You went to Wisconsin voluntarily on your own accord for vacation?
[21:32:48] <mdynac> yes i did
[21:33:02] <Jymmm> I'm sorry, just in a mood today is all.
[21:33:05] <mdynac> i have property here
[21:33:09] <mdynac> np
[21:33:17] <Jymmm> Ah, ok that makes sense then.
[21:33:27] <mdynac> the cheeselanders are kinda fun folks....
[21:34:05] <Jymmm> I've never been there, so just playing around.
[21:34:32] <mdynac> i am way up here northwest of green bay
[21:34:45] <SWPadnos> near Iron County, MI?
[21:34:50] <mdynac> just got back from sailing
[21:34:57] <mdynac> nope
[21:35:05] <mdynac> crivitz
[21:35:21] <SWPadnos> ok. I probably drove through (or at least near) There a few weeks ago
[21:35:31] <mdynac> kewl
[21:35:36] <SWPadnos> (from Minneapolis to Crystal Falls, then down to Manitowoc)
[21:35:53] <mdynac> wow, kinda far from home huh?
[21:36:12] <SWPadnos> yep. but we have friends in Minn., and family in Manitowoc :)
[21:36:25] <mdynac> nice
[21:36:31] <SWPadnos> my wife went to school at UWEC
[21:36:46] <mdynac> eau claire, kewl
[21:37:00] <mdynac> my buddy went tola crosse
[21:37:13] <mdynac> party city
[21:37:30] <SWPadnos> heh -we drove through there as well :)
[21:37:40] <SWPadnos> (lots of driving to get to Minneapolis from Vermont)
[21:38:10] <mdynac> the northern route?
[21:38:35] <SWPadnos> nope - we took the wouthern route on the way out
[21:38:54] <SWPadnos> then the Manitowoc->Ludington ferry on the way back, stopping in Niagara Falls for a couple of days
[21:39:11] <mdynac> now that is nice
[21:39:26] <Jymmm> NIagra falls... step by step.... inch by inch....
[21:39:36] <mdynac> slowly i turn....
[21:39:51] <SWPadnos> yep. we splurged a little on the hotel room, so we had a tower room that overlooked the US falls, and we even saw a bit of the horshshoe falls next to the casino tower
[21:39:57] <Jymmm> oooops, it's been a long time since I saw that
[21:41:17] <mdynac> well i am happy to report that the adaptive feedrate works quite nicely, and i am about to install my setup on the old andrew ef330 edm machine next week.....
[21:41:39] <mdynac> finally replace that old pdp8\a
[21:41:46] <SWPadnos> heh
[21:42:00] <mdynac> as soon as i get home...
[21:42:21] <mdynac> next week
[21:42:46] <mdynac> i need one more function from the emc gurus
[21:43:31] <mdynac> anyone up for it?
[21:44:39] <mdynac> just to refresh your memory, i was at the fest working on the japax edm all week.....
[21:44:53] <SWPadnos> ok. what do you need?
[21:45:12] <SWPadnos> (not that I can do it for you right now, since I don't have a n emc dev machine running right now)
[21:46:08] <mdynac> no i am not expecting instant results...take your time....the machine needs to perform a "backup" function
[21:47:39] <mdynac> we discussed this at the fest
[21:49:40] <mdynac> but not in great detail
[21:51:44] <SWPadnos> right - ther ewas discussion of how far back it would need to go, what path it should take, etc.
[21:54:01] <mdynac> correct, it should be able to reverse direction in all axis for say .025(that could be variable also) and then continue on forward again without losing position...
[21:54:35] <SWPadnos> yeah. I think the problem was what to do if that spans multiple blocks of G-code
[21:55:59] <mdynac> that could be a problem
[21:56:30] <mdynac> in the real world it probably will do that occasionally....
[21:58:15] <mdynac> i think it was mr epler who had some thoughts on that....
[22:01:17] <cradek> a small fixed maximum distance to backup makes this possible, you just have to keep that much of the queue.
[22:01:59] <cradek> the only complexity is backing up through the same blended path, but for edm that hardly matters since you don't need blending at all
[22:02:49] <cradek> uh-oh, it sounds like I'm volunteering to write this...
[22:04:26] <cradek> mdynac: how do you communicate to the motion controller that you have to go backward? would the adaptive feed pin just go negative?
[22:04:27] <SWPadnos> I thikn the problem with EDM is that 0.025 could be a 10 minute move ;)
[22:04:57] <cradek> yes but still I bet it's only going to be "a few" segments
[22:06:02] <A-L-P-H-A> SWPadnos, that's the cost of precision. :)
[22:06:04] <cradek> do you want it to go backward pretty fast, or at the same snails pace?
[22:06:43] <A-L-P-H-A> cradek, you wouldn't want it to backwards at all... and most of the time wire EDM doesn't.
[22:07:06] <cradek> A-L-P-H-A: that's not what mdynac is saying...?
[22:07:15] <cradek> hello ray
[22:07:21] <A-L-P-H-A> cradek, the good/newer wire edm machines, just cut the wire, move to the next path, that was predrilled, and re-threads itself automatically, in seconds.
[22:07:31] <A-L-P-H-A> I'm not reading what mdynac...
[22:07:34] <A-L-P-H-A> typed
[22:07:39] <SWPadnos> that's not the only kind of EDM though
[22:07:47] <A-L-P-H-A> I'm just here to chime my 0.0000002cents worth in.
[22:08:33] <A-L-P-H-A> SWPadnos, true... there's sink edm, which just moves up and down, and retracts fast. causing the iso-tonic solution to stir, dilute the metal particles in that affected area
[22:08:46] <cradek> A-L-P-H-A: you and mdynac hash it out, I'll watch, since I don't know anything about edm.
[22:08:59] <SWPadnos> it sounds funny - that's about all I know ;)
[22:09:08] <A-L-P-H-A> * A-L-P-H-A attacks mdynac with edm wire from behind!
[22:09:16] <A-L-P-H-A> there, I killed him... now can we move on?
[22:09:17] <mdynac> .025 move would be a fixed rapid rate
[22:09:32] <mdynac> sorry a bit behind here
[22:09:35] <cradek> ah ok
[22:10:08] <cradek> so backward moves at rapid, then it's back to normal with adaptive feed forward?
[22:10:16] <mdynac> chmer wedm, the fastest rethreader on the market....
[22:10:21] <mdynac> yes
[22:10:38] <cradek> does it go backward until something happens, or the fixed dstance?
[22:10:39] <cradek> i
[22:10:47] <mdynac> till the short is cleared, if not just keeps going back and forth
[22:11:25] <mdynac> the same voltage as the adaptive feedrate is using.....
[22:11:28] <cradek> so if you back up the .025 and it's still shorted, is that an error condition where you would just abort?
[22:12:04] <mdynac> well it should never abort....
[22:12:20] <mdynac> it should be stuck in backup....
[22:12:35] <cradek> ok but it will back up the .025 and then stop (I guess)
[22:12:56] <mdynac> then move forward again, immediately
[22:13:14] <cradek> ok but if it's still shorted won't the adaptive feed be 0?
[22:14:01] <mdynac> true, but i must calibrate the whole system to never let it get to zero volst before a backup occurs....
[22:14:49] <SWPadnos> it seems that we have three or so issues with "unlimited reversals"
[22:15:05] <SWPadnos> 1) mirroring problems: G40 and G41 change sense when going in reverse
[22:15:44] <SWPadnos> 2) modal G-codes: these need to be unapplied before a reverse move starts (and other issues)
[22:15:58] <SWPadnos> 3) knowing prior G-code blocks
[22:16:12] <SWPadnos> (they essentially get thrown away once they're done)
[22:16:14] <cradek> uh-oh we just switched to talking about unlimited reversal
[22:16:33] <SWPadnos> I know - that's where you were theaded anyway - I just hit the turbo button ;)
[22:16:54] <SWPadnos> problem 4 is the TP code itself - it may not deal well with negative time increments
[22:17:07] <mdynac> it seems that the O/S running the machine now uses a subroutine to throw the machine into the backup routine....no more gcode is executed until the gap voltage rises
[22:17:23] <rayh> Hi guys.
[22:17:27] <SWPadnos> Hi Ray
[22:17:35] <cradek> to follow the same path you do kind of have to execute the gcode - backwards
[22:17:37] <mdynac> then it continues on the path until the next short occurs
[22:17:47] <SWPadnos> I have an ulterior motive - a jogwheel that lets me go back and forth through a program would need unlimited reversal :)
[22:17:49] <cradek> unless it just goes in a straight line backward...?
[22:17:53] <mdynac> hi ray!!
[22:18:15] <mdynac> the jogwheel is a great start
[22:18:45] <mdynac> no it follows the path back out
[22:19:23] <cradek> we'd need a layer with some kind of bidirectional representation of the gcode
[22:19:46] <rayh> IMO the interpreter need to keep a copy of the executing g-code file.
[22:20:13] <rayh> When written, one demand on the interpreter was fixed memory footprint.
[22:20:24] <rayh> for embedding.
[22:20:28] <SWPadnos> not so importnat these days, I think
[22:20:33] <cradek> today it doesn't have to be fixed, but it should probably have a maximum
[22:20:36] <rayh> Not at all.
[22:20:47] <SWPadnos> since a single chip can have 256k code space and 64k RAM, in addition to a 32-bit CPU
[22:20:48] <rayh> Sure a max is desirable.
[22:21:22] <rayh> I've seen g-code files that go out to 10-20 Meg
[22:21:29] <cradek> I wonder if we should rework CANON so it's fully specified - each call doesn't depend on previous calls
[22:21:41] <mdynac> rayh: wow
[22:21:56] <SWPadnos> files can help - save the inverse of every canonical command (or at some other level) in a "rin file" - replay the c"card stack" backwards if necessary
[22:22:32] <rayh> Sure any sort of procedure that allows a pointer to be moved up and down the stack.
[22:23:09] <SWPadnos> the trick is creating the stack itself - some commands have an inverse that needs things changed depending on mode
[22:23:11] <rayh> If it is the g-code stack and we reverse we would need to throw out the canon stack but that would not be
[22:23:14] <SWPadnos> like G40/G41
[22:23:17] <rayh> a big loss.
[22:24:02] <cradek> I think you would do the stack after things like g40/g41 are relevant
[22:24:19] <rayh> If we really implemented an interpreter with "current mode" as well as look ahead it would be nice.
[22:24:21] <SWPadnos> yeah - there is an advantage to using a "final motion" list
[22:24:24] <cradek> that stuff is really complicated (comp entry moves for example)
[22:25:12] <rayh> Yep. If it was easy ...
[22:25:15] <cradek> I'm looking at canon
[22:25:33] <cradek> consider USE_LENGTH_UNITS() - this is easy to time-invert
[22:25:40] <cradek> maybe at this stage they all are
[22:26:04] <cradek> SET_FEED_RATE(double rate)
[22:26:09] <cradek> old rate <--> new rate
[22:26:51] <cradek> * cradek looks at ARC_FEED and starts crying quietly
[22:26:56] <SWPadnos> heh
[22:27:00] <rayh> un huh
[22:27:32] <cradek> I think we really don't want to do this at the interp/gcode level.
[22:27:55] <SWPadnos> it's too bad the IJK are always relative
[22:28:21] <cradek> that's all gone before canon, it doesn't matter
[22:28:45] <SWPadnos> what parameters does ARC_FEED have?
[22:28:56] <cradek> void ARC_FEED(double first_end, double second_end,
[22:28:57] <cradek> double first_axis, double second_axis, int rotation,
[22:28:57] <cradek> double axis_end_point, double a, double b, double c)
[22:29:12] <SWPadnos> I see.
[22:29:19] <SWPadnos> what in hell do all those do?
[22:29:20] <cradek> first_end etc change axis depending on the active plane
[22:29:52] <cradek> http://www.isd.mel.nist.gov/personnel/kramer/pubs/RS274NGC_3.web/RS274NGC_34a.html#1000406
[22:29:52] <SWPadnos> and ABC are for the rotary axes, right
[22:30:22] <SWPadnos> ok - not a problem
[22:30:29] <cradek> heh
[22:30:52] <SWPadnos> well - conceptually at least ;)
[22:31:15] <mdynac> would it be easier to get backup working in only the x and y axis first?
[22:31:30] <cradek> note all of canon goes from the point specified in a previous call to the point specified in this new call
[22:31:46] <SWPadnos> the first/second axis values stay the same, and the previous position is used for first/second endpoint and axis_end_point
[22:32:25] <cradek> mdynac: it's probably no easier to do 2/3 of the axes
[22:32:38] <mdynac> k
[22:32:38] <SWPadnos> so you need to know the start position of the previous move (true for G1 as well), as well as the end position, and the move type
[22:33:17] <cradek> seems like the canon calls could generate their own inverses and queue them up.
[22:33:32] <SWPadnos> that would make sense, I think
[22:33:53] <SWPadnos> or at least generate a "move" struct and return a pointer
[22:33:57] <cradek> just ignore queue size problems I guess
[22:34:13] <SWPadnos> no sense doing all the work when axis pre-loads the file
[22:34:23] <SWPadnos> (or maybe it does make sense)
[22:34:26] <cradek> yes maybe some kind of fully-specified move struct
[22:34:43] <cradek> I don't follow
[22:34:53] <SWPadnos> one sec on that topic
[22:35:11] <SWPadnos> actually, I think you can send a struct to the various functions, with an "invert" parameter
[22:35:20] <SWPadnos> each move function should know how to invert its own moves
[22:35:33] <SWPadnos> ARC_FEED, STRAIGHT_FEED
[22:36:07] <SWPadnos> so you get a struct with at most 12 doubles (start and end for 6 axes), plus some control info
[22:36:27] <SWPadnos> send that to ARC_FEED, with a boolean for forward or backward motion
[22:37:02] <SWPadnos> on the subject of pre-load - axis already has the G-code executed once - it could then play back the canon calls directly :)
[22:37:53] <cradek> axis is sure going to be a help for debugging the reversed canon calls
[22:38:02] <rayh> I don't believe that making a GUI/HMI solution central to the process is the proper approach.
[22:38:28] <cradek> yeah I'm afraid I still don't follow exactly what you mean
[22:38:39] <SWPadnos> I agree, the thought came to me when I was thinking about not bothering to generate the move stack when axis does the preload
[22:38:41] <rayh> I did this with tickle for some tests here but I wouldn't want that code released into the wild.
[22:39:50] <SWPadnos> cradek, don't understand which?
[22:40:10] <cradek> about using axis, but forget it
[22:40:16] <SWPadnos> ok
[22:40:46] <cradek> it does seem like the canons can generate their inverses.
[22:41:06] <cradek> I've had enough trouble getting them to work forward all the time though.
[22:41:14] <SWPadnos> yep, so they should also be able to just execute a move forward or reverse
[22:41:16] <SWPadnos> heh
[22:41:39] <SWPadnos> I might argue that this would be incompatible with blending, but that doesn't help my "jog through the program" scenario
[22:41:51] <cradek> blending is a big problem.
[22:42:27] <cradek> pausing/resuming/stepping, feed override, adaptive feed ALL change the path
[22:42:49] <cradek> and at this canon level we know nothing about any of that.
[22:42:51] <SWPadnos> I wonder if a tolerance number can be put into the move struct, determined from the actual blended path
[22:43:00] <SWPadnos> yep
[22:43:51] <SWPadnos> hmmm - reversing at any speed faster than the forward speed would be an issue for sure
[22:44:14] <cradek> any different speed really.
[22:44:23] <cradek> I'm close to saying this is incompatible with blending.
[22:44:38] <cradek> and again the EDM guys are not going to care one bit.
[22:44:59] <SWPadnos> I'd go for that at first. if I really want to jog through programs, I should just write the code (damnit!)
[22:45:38] <Jymmm> For shits and giggles, I tried turbocnc on the new box and jogged the machien around.... SCAR-EEEEEEEEEEEEEEEEEEEE
[22:45:55] <SWPadnos> too fast, too choppy, what?
[22:46:19] <Jymmm> too damn fast!
[22:46:55] <Jymmm> dman thing is jerking the whole gorilla rack it's on!
[22:47:29] <Jymmm> I actually think it moved the whole machien about an inch one time
[22:47:55] <cradek> bbl
[22:47:55] <SWPadnos> how many steps/second can you get out of TCNC on this machine?
[22:48:00] <SWPadnos> see you cradek
[22:48:34] <Jymmm> SWPadnos 150ipm
[22:48:51] <Jymmm> still using the 16000
[22:48:52] <SWPadnos> 40k pps then?
[22:49:53] <Jymmm> They use hz/s for many things, so I realyl can't tell you
[22:50:12] <SWPadnos> Hz/s should be acceleration
[22:50:13] <Jymmm> I got velocity to 120000
[22:51:51] <Jymmm> I'll be happy with 40-60ipm and no scallop artifacts on the finished pieces
[22:52:22] <Jymmm> and of course.... no dman stalling
[22:53:09] <Jymmm> I wonder what I could get out of it if I used the highest geckos - the ones wiht the multiplier built in
[22:54:27] <SWPadnos> if that 120000 is Hz, then you won't get more than double the speed, since the Geckos are limited to a 250 KHz step rate
[22:54:45] <SWPadnos> if it's interrupts/sec, then you could get 4x the speed you have now
[22:58:38] <rayh> I don't quite understand the concept of rpm for a gecko running with a 250K pps signal.
[22:59:36] <SWPadnos> it would be a lot of RPM ;)
[22:59:57] <SWPadnos> like 7500
[23:01:18] <rayh> microstepping yields 2000 pulses per rev.
[23:01:34] <rayh> so a motor should be turning 7500 rpm.
[23:01:37] <SWPadnos> right 250000 / 2000 = 125 RPS, 60 * 125 should be 7500
[23:01:39] <SWPadnos> yep
[23:01:59] <SWPadnos> so you'd have near zero torque, but very high speed
[23:02:16] <SWPadnos> and probably a lot of lost steps :)
[23:04:45] <Jymmm> Well, it's too fast as it is. I wen tthru all this hoopla to help get rid of the artifacts and any stalling issues.
[23:05:22] <SWPadnos> the geckos may help because they eliminate mid-band resonance, not so much because they have a step multiplier
[23:25:19] <mdynac> welcome back mr padnos
[23:26:07] <SWPadnos> thanks - I didn't know I was gone until a few seconds ago :)
[23:26:27] <SWPadnos> it may be time to restart Mozilla soon
[23:26:42] <mdynac> using x-chat here
[23:26:58] <SWPadnos> using Windows here :(
[23:27:03] <mdynac> ong
[23:27:32] <SWPadnos> time for some nice ice cream, I think
[23:28:05] <mdynac> i just this box as a freebee, duall PII with scsi cd and hd....took w2k off and put slackware 10.2 on it,wow what a difference......
[23:28:07] <SWPadnos> hey mdynac - can you get "Ice Cream Shoppe" brand ice cream where you are?
[23:28:19] <mdynac> no sir....
[23:28:25] <SWPadnos> I have softtware that only runs on WinBlows, unfortunately
[23:28:36] <mdynac> i thought ben and jerry's was from up your way
[23:28:46] <SWPadnos> too bad - their Zanzibar chocolate is actually as good as or possibly beter than Ben & Jerry's
[23:29:05] <mdynac> kewl, maybe some day they will be everywhere
[23:29:09] <SWPadnos> it is (I used to get served by Ben and Jerry in their first ice cream shop :) )
[23:29:20] <mdynac> we just got a coldstone....
[23:30:00] <mdynac> phish food rocks.....
[23:30:13] <SWPadnos> http://www.chocolateshoppeicecream.com/flavor.cfm?flavorID=124
[23:30:20] <mdynac> thx
[23:30:46] <SWPadnos> I actually don't really go for the "weird" flavors, except for New York Super Fudge Chunk, or Heath Bar Crunch
[23:31:07] <mdynac> so how was the cuisine in galesburg il?
[23:31:13] <SWPadnos> Chocolate Shoppe - oops :)
[23:31:28] <SWPadnos> cuisine? I don't think they had any ;)
[23:31:44] <mdynac> meat and potatoes
[23:31:48] <SWPadnos> actually, we had a great dinner at ... some place I can't remember
[23:32:09] <mdynac> i c
[23:32:23] <SWPadnos> ah - Chez Willy's
[23:32:36] <SWPadnos> http://www.chezwillys.com/locations.asp
[23:33:17] <mdynac> never heard of it.....
[23:33:30] <mdynac> i live near chicago....
[23:33:34] <SWPadnos> they had great food
[23:33:39] <mdynac> kewl
[23:34:13] <SWPadnos> northwest of Green Bay isn't exactly close to Chicago ;)
[23:34:42] <SWPadnos> unless you fly
[23:35:27] <mdynac> drove up....about 5 hours with rest stops....
[23:35:44] <SWPadnos> yep - closer than VT, but not really "close" :)
[23:35:56] <mdynac> mostly state roads nice scenery.....
[23:36:13] <SWPadnos> yep - I-94 (?) is pretty good once you get out of Chicagoland
[23:36:35] <mdynac> i avoid it like the plague....
[23:36:39] <SWPadnos> and Wisconsin 20 or 8 (can't remember which) is very fast
[23:36:52] <mdynac> 20
[23:37:03] <mdynac> 43
[23:37:42] <SWPadnos> yep - 43 goes straight N-S through Kenosha, Milwaukee, Manitowoc, and Green Bay (and several others)
[23:37:49] <SWPadnos> that's the one, right?
[23:37:54] <mdynac> you can move thru cheesland on the back roads almost as fast as the i state
[23:37:58] <mdynac> yep
[23:38:48] <mdynac> i go up to Lake Geneva then zig zag
[23:39:30] <mdynac> then shoot up thru kettle morain state forest.....
[23:39:46] <mdynac> beautiful.....
[23:41:30] <SWPadnos> argh. I have to get back to this stupid fscking LabView development crap
[23:41:59] <mdynac> k, i gotta fire up the weber.....
[23:42:12] <SWPadnos> heh
[23:42:30] <mdynac> later.....bye
[23:44:06] <Jymmm> SWPadnos you just know where ALL the foods places are in the country!
[23:44:47] <mdynac> well i try.....food is good.....but the best will be at my place tonight.....
[23:45:23] <mdynac> Jymmm: were you at the fest?
[23:45:54] <Jymmm> mdynac "Yeah, I was the one with the beard!"
[23:46:04] <cradek> ha
[23:46:07] <Jymmm> mdynac: Nah, never made it =)
[23:46:09] <mdynac> well that really narrows it down
[23:46:30] <mdynac> too bad
[23:46:37] <mdynac> it was kewl
[23:47:35] <Jymmm> cradek: thought you might like that =)
[23:51:11] <mdynac> is that max cnc mill still available?
[23:52:39] <cradek> not sure - they sold something like it until recently, but I think I heard they finally went out of business
[23:52:57] <mdynac> too bad that is a nice platform.....
[23:53:02] <cradek> still have a website though
[23:53:07] <cradek> maybe I'm wrong
[23:53:16] <mdynac> k, will check it....
[23:53:32] <cradek> yeah it's a nice start, a little bigger than a sherline, and possibly cheaper too
[23:53:53] <mdynac> i didn't notice much slop in it.....
[23:54:02] <cradek> better still if you can get them to sell it to you cheaper without their crap controller and spindle motor
[23:54:16] <cradek> and software
[23:54:18] <cradek> heh
[23:54:39] <mdynac> don't need any of that stuff just the xyz screws
[23:55:13] <mdynac> i got motors steppers servos drives electronics up the yin yang here....
[23:55:57] <cradek> better to skip the screws too and get at least acmes
[23:56:16] <Jymmm> mdynac: I'll trade you 10 sticks of 10' 1/4-20 allthread for three servo motors, encoders and drives =)
[23:56:31] <mdynac> i have an old xy table off an old andrew edm but it weighs 600 lbs......kinda hard to carry around....
[23:56:56] <mdynac> suc ha deal....
[23:57:14] <Jymmm> cradek do you think opengl changed that much from debian ti ubuntu 6 ?
[23:57:20] <Jymmm> s/ti/to/
[23:57:21] <mdynac> i take it you are in the same boat?
[23:57:43] <Jymmm> mdynac opposite of you... I'm running xylotex and steppers
[23:57:51] <mdynac> ball screws
[23:58:06] <Jymmm> cheap thomson ones
[23:58:47] <mdynac> i'm running a motenc lite, copley analog servos driving pacific scientific servo motor tachs.....with emc
[23:58:56] <Jymmm> mdynac this is close to my machine... http://www.k2cnc.com/DuportalPro343Access/images/cnc3925c.jpg
[23:59:20] <mdynac> one sec...