#emc | Logs for 2005-12-11

Back
[00:00:09] <Jymmm> just seems odd
[00:00:14] <cradek> what are you talking about?
[00:00:35] <Jymmm> cradek http://timeguy.com/cradek-files/emc/ferror.png
[00:01:13] <cradek> no, it ferrors when I release the jog key
[00:01:15] <cradek> that was just luck
[00:01:24] <Jymmm> you sure?
[00:01:30] <cradek> entirely sure
[00:01:34] <Jymmm> k
[00:02:05] <alex_joni> cradek: so long jogs don't ferror?
[00:02:12] <cradek> alex_joni: no, only when I release
[00:02:21] <Jymmm> deaccl
[00:02:21] <alex_joni> damn that's odd..
[00:02:25] <CIA-12> 03fenn * 10emc2/configs/emc.ini: min_ferror was set to 0 for some reason, reverted to .010
[00:02:30] <cradek> halscope shows there is no cumulative following error
[00:02:39] <Jymmm> cradek steppers?
[00:02:43] <cradek> yes
[00:03:06] <cradek> fenn: does that fix it?
[00:03:13] <fenn> works for me
[00:04:22] <alex_joni> cradek: do G0 and G1 work?
[00:04:34] <cradek> alex_joni: didn't get that far because I couldn't jog to home
[00:04:39] <Jacky^> http://cgi.ebay.it/SEXY-FETISH-PERIZOMA-UOMO-CANE-x-natale-o-celibato_W0QQitemZ5644373523QQcategoryZ324QQrdZ1QQcmdZViewItem
[00:04:42] <cradek> alex_joni: I put in fenn's fix already
[00:04:43] <Jacky^> bauahhahaha :D
[00:04:45] <cradek> testing again
[00:04:54] <alex_joni> what fix?
[00:05:04] <alex_joni> you didn't have that in the ini..
[00:05:23] <cradek> oops, I lied about that being my ini then
[00:05:29] <cradek> cvs must have merged in that change
[00:05:35] <alex_joni> :P
[00:05:39] <cradek> I still get my following errors after fenn's fix
[00:05:46] <fenn> hmmmmm
[00:06:03] <cradek> ugh
[00:06:11] <alex_joni> probably had some of the core_stepper.hal stuff merged in
[00:06:16] <cradek> I think emc is rewriting the ini with that 0
[00:06:30] <alex_joni> excuse me?
[00:06:42] <cradek> testing again
[00:07:17] <cradek> forget it
[00:07:19] <Jymmm> alex_joni: Self-replicating code, impressive.
[00:07:24] <cradek> I have no idea what I did wrong
[00:08:00] <Jymmm> cradek : woke up?
[00:08:00] <alex_joni> btw, the ini jmk submited didn't have a 0 ferror in it
[00:08:00] <cradek> mine's working again
[00:08:00] <alex_joni> fenn: not sure what you fixed..
[00:08:11] <fenn> what?
[00:08:14] <fenn> i just checked it out
[00:08:17] <alex_joni> MIN_LIMIT = -2.0
[00:08:17] <alex_joni> MAX_LIMIT = 4.0
[00:08:17] <alex_joni> ! FERROR = 0.050
[00:08:17] <alex_joni> MIN_FERROR = 0.010
[00:08:17] <alex_joni> HOME_OFFSET = 0.0
[00:08:18] <alex_joni> --- 201,205 ----
[00:08:20] <alex_joni> MIN_LIMIT = -2.0
[00:08:22] <alex_joni> MAX_LIMIT = 4.0
[00:08:24] <alex_joni> ! FERROR = 1.000
[00:08:26] <alex_joni> MIN_FERROR = 0.010
[00:08:28] <alex_joni> HOME_OFFSET = 0.0
[00:08:30] <alex_joni> that's the commit log
[00:08:49] <alex_joni> and my emc.ini (before your change) is reading 0.050
[00:08:54] <alex_joni> just got it out of CVS
[00:09:03] <cradek> well I got MIN_FERROR=0 somehow
[00:09:09] <SWPadnos_> that's a pretty huge default FERROR!
[00:09:15] <cradek> CURSE the webcvs delay
[00:09:34] <fenn> i didnt do anything to FERROR, only MIN_FERROR
[00:09:47] <alex_joni> well.. seems you commited ferror ;)
[00:09:50] <SWPadnos_> that commit log shows FERROR changed from 0.050 to 1.000
[00:09:58] <cradek> you're right
[00:10:03] <Jacky^> damn it ! this is better with the penguin too!http://cgi.ebay.it/ws/eBayISAPI.dll?ViewItem&item=5451580256&ssPageName=MERC_VI_ReBay_Pr4_PcY_BID_IT
[00:10:05] <cradek> I wonder where my 0 came from
[00:10:13] <alex_joni> * alex_joni points to fenn
[00:10:14] <alex_joni> :D
[00:10:24] <fenn> hey where did _my_ zero come from then
[00:10:39] <alex_joni> * alex_joni points to cradek
[00:10:43] <alex_joni> fight it out
[00:10:48] <cradek> * cradek points to Jymmm
[00:10:57] <SWPadnos_> emc does write values to the ini file - look at OUTPUT_SCALE
[00:11:00] <cradek> I have nfc what happened
[00:11:07] <alex_joni> oh fer fsck sake.. stop pasting that sh*t Jacky^
[00:11:20] <Jacky^> haahaauahuh
[00:11:35] <Jacky^> ok
[00:11:46] <SWPadnos_> try this: edit the ini file so that min_ferror is 'MIN_FERROR = 0.050" - include all the spaces
[00:11:57] <SWPadnos_> run emc,then exit, and see if the spaces are gone
[00:12:17] <SWPadnos_> that'll tell you that emc is rewriting the value
[00:16:20] <wb9mjn> Hi All....Got the analog isolator, and put it on the machine today...so now it has spindle speed control from the PC...
[00:17:21] <alex_joni> does anyone have anything against removing the IO_BASE_ADDRESS for the second parport from the ini?
[00:17:25] <alex_joni> it's not used anyways..
[00:17:46] <alex_joni> SPINDLE_ON/OFF_WAIT don't do anything either..
[00:17:51] <wb9mjn> Is that the address used by bridgeport I/O ?
[00:17:52] <petev> remove them
[00:17:58] <fenn> kill!
[00:18:05] <petev> the INI is cluttered with enough junk that's not used
[00:18:16] <wb9mjn> Well,,, it spindle Reverse/Forward really do not do anything...
[00:18:21] <alex_joni> hmm.. have a better idea.. I'll leave it as it is
[00:18:29] <alex_joni> wb9mjn: how do you mean that?
[00:18:29] <wb9mjn> Spindle On/Off sure does....!
[00:18:51] <petev> not unless the HAL grabs it from ini
[00:18:55] <Jacky^> is the second parport 0x278 by default ?
[00:18:57] <wb9mjn> Spindle forward and reverse is controlled by the analog voltage in allot of implementations...
[00:19:00] <alex_joni> petev: I'll start working on subdirs for configs today.. lateron
[00:19:07] <alex_joni> and I'll start from scratch with an ini
[00:19:17] <alex_joni> wb9mjn: right
[00:19:18] <wb9mjn> +10 volts is full forward, and -10 full reverse...
[00:19:27] <alex_joni> you can do that in hal
[00:19:35] <Jacky^> I removed in order to use 0x278 adress ad first parport and it worked fine
[00:19:52] <wb9mjn> So, Spindle Forward/Reverse is more for old-fashioned drives with Relay reversers...
[00:20:11] <alex_joni> wb9mjn: yes it is, but you can run that with emc2 too
[00:20:18] <wb9mjn> Wherease Spindle on/off is more for newer drives with computer style enable inputs...
[00:20:19] <SWPadnos_> actually, you can lose all the XXX_INDEX and XXX_POLARITY from the bottom of the ini file as well
[00:20:23] <alex_joni> so you'll have to chose the kind of spindle control you have
[00:20:31] <wb9mjn> I use EMC 1 here....
[00:20:41] <SWPadnos_> oh - well then you can't ;)
[00:20:45] <alex_joni> wb9mjn: too bad for you ;)
[00:20:46] <alex_joni> :P
[00:20:56] <alex_joni> kidding..
[00:21:33] <wb9mjn> A four quadrant drive does not need the forward/reverse...
[00:21:52] <wb9mjn> As a negative voltage will cause it to apply torque in reverse...
[00:22:14] <alex_joni> that's why io in emc2 has a LOT of ways to drive a spindle
[00:22:40] <CIA-12> 03alex_joni * 10emc2/configs/emc.ini: reverted fenn's change to ferror, as it was unintended.
[00:25:51] <pc_op`> pc_op` is now known as pc_op
[00:26:03] <fenn> i'm pretty confused about this whole ferror thing
[00:26:07] <fenn> cvs diff shows no difference
[00:26:18] <alex_joni> cvs diff is stupid..
[00:26:25] <alex_joni> had the same problem here too
[00:33:15] <Jymmm> Unless... it was something else that caused the problem
[00:35:29] <Jacky^> ls *avi
[00:35:32] <Jacky^> ops
[00:35:50] <Jymmm> Jacky^: Updating your porn collection huh?
[00:35:57] <Jacky^> ugh
[00:36:01] <fenn> apt-get install pr0n
[00:36:12] <Jacky^> nah .. was looking for the latest video from iraq :/
[00:36:28] <Jymmm> Jacky^ when you find it... rm -rf *
[00:36:43] <Jacky^> Jymmm: yeah ..
[00:36:46] <petev> * petev is away: eating
[00:37:45] <Jacky^> the video show italian militars killing peoples..
[00:37:56] <Jymmm> exactly
[00:38:00] <Jacky^> when aout mission woulde be a 'piece mission'
[00:38:05] <CIA-12> 03alex_joni * 10emc2/configs/emc.ini: cleaned up, removed unneeded IO pins & polarities, added +/- comments reflecting what a user typically needs to change. revert if the changes are bad :)
[00:38:08] <Jymmm> Jacky^ what, you want to watch a beheading video too?
[00:38:13] <Jacky^> at the lest, they called so ..
[00:38:22] <Jacky^> Jymmm: no, thanks
[00:38:38] <Jacky^> im interesting in understand better I can this war
[00:38:49] <les_w> I watched your video
[00:39:02] <Jymmm> Jacky^: This or any other war.... there is never any understanding it.
[00:39:05] <Jacky^> les_w: the audio is rilevant, not the video
[00:39:09] <alex_joni> fenn, cradek: wanna take a look at the emc.ini I commited?
[00:39:14] <Jacky^> but is italian :(
[00:39:26] <Jacky^> i dounbt you hav understand all
[00:39:27] <les_w> yeah could not understand of course
[00:39:28] <alex_joni> yeah.. who can understand italians..
[00:39:39] <les_w> other italians!
[00:39:43] <alex_joni> they have some weird thinking :)
[00:39:45] <alex_joni> :P
[00:39:48] <alex_joni> kidding..
[00:39:55] <Jymmm> les_w: Nope, not other Italians either.
[00:40:50] <Jacky^> wonder why the video comes out now ..
[00:41:11] <les_w> Well you missed the k4ts singing concert the other night, and it sounded good whether I could understand it or not. ;)
[00:41:17] <Jacky^> were near to next election too
[00:41:30] <Jacky^> hehehe
[00:41:31] <jmk_eating> jmk_eating is now known as jmkasunich
[00:41:38] <alex_joni> wb john
[00:41:43] <fenn> alex_joni: if i cant trust cvs diff, how do i know wtf is actually in the cvs?
[00:41:52] <alex_joni> you cvs up :P
[00:41:59] <alex_joni> I never had problems with cvs diff..
[00:42:03] <alex_joni> until tonight
[00:42:55] <fenn> jmk : i still get following errors if i turn default accel back up to 20, with your fix
[00:43:55] <jmkasunich> with STEPGEN_MAXACCEL = 21?
[00:43:59] <fenn> yea
[00:44:15] <fenn> alex turned FERROR back down to .05
[00:44:19] <fenn> not sure what value you were testing with
[00:44:23] <jmkasunich> and with your core_stepper.hal getting its accel from STEPGEN_MAXACCEL, not from MAX_VELOCITY?
[00:44:38] <alex_joni> jmk was using .05
[00:44:40] <fenn> er, um, i dunno lemme check
[00:45:22] <alex_joni> jmk: changed a bit the emc.ini, say if you don't like..
[00:45:55] <jmkasunich> reading the commit msg right now
[00:45:55] <fenn> jmk yes it uses stepgen_maxaccel
[00:46:14] <jmkasunich> fenn: stand by
[00:46:22] <fenn> roger that
[00:46:52] <Jymmm> Oh man.... Richard Prior died today
[00:47:35] <rayh> "we bad, we bad"
[00:49:00] <Jymmm> heh
[00:49:03] <alex_joni> Jymmm: who's that?
[00:49:15] <jmkasunich> I comedian
[00:49:22] <jmkasunich> A comedian
[00:49:24] <Jymmm> alex_joni what jmkasunich said
[00:49:41] <alex_joni> that's Pryor
[00:49:48] <jmkasunich> best known for catching himself on fire while free-basing cocaine
[00:50:14] <alex_joni> http://www.richardpryor.com/
[00:50:21] <Jymmm> http://www.newsday.com/entertainment/la-me-pryor11dec11,0,6659469.story?coll=ny-region-apnewyork&track=mostemailedlink
[00:51:37] <alex_joni> too bad..
[00:52:28] <les_w> rayh, did you look at dave's circle gnuplots?
[00:53:23] <Jymmm> alex_joni: In his act he'd talk about setting himself on fire.... but he really did too.
[00:53:46] <alex_joni> heh.. remeber seeing him once or twice
[00:53:53] <alex_joni> remember even
[00:54:20] <les_w> ah another new word
[00:54:30] <alex_joni> remeber?
[00:54:33] <les_w> what canwe use that for?
[00:54:38] <Jacky^> :P
[00:54:42] <les_w> haha
[00:55:01] <alex_joni> I know it was used for something..
[00:55:06] <alex_joni> just can't remeber what for..
[00:55:15] <Jymmm> remeber = memory retentive rubber
[00:55:22] <les_w> I make up words in patent claim texts
[00:55:35] <alex_joni> ooh nice ;)
[00:55:47] <fenn> then you have to trademark them
[00:55:52] <alex_joni> what if someone puts a patent on a new word?
[00:55:53] <les_w> why not? it new stuff. Needs new words.
[00:56:14] <Jymmm> les_w then they can't ref the new word... lol
[00:56:25] <les_w> Gets published in the congressional record too.
[00:56:34] <les_w> haha
[00:56:45] <Jymmm> then you can TM the new word based upon the patent ref.
[00:56:50] <alex_joni> jmkasunich: how does that ini look?
[00:58:50] <fenn> alex_joni: look good to me.. all that stuff is in hal now
[00:59:02] <jmkasunich> pretty good so far
[01:00:06] <petev> * petev is back
[01:00:27] <les_w> thank god! :)
[01:00:49] <alex_joni> les_w: what?
[01:01:16] <les_w> petev is back!!!
[01:01:18] <alex_joni> fenn: somehow it will get configured a bit nicer, didn't figure out how.. (yet)
[01:11:41] <les_w> I just had to send a congratulatory post back to this guy that made a wooden cnc router:
[01:11:47] <les_w> http://engraving.majosoft.com/html/wooden_hobby_cnc_engraving_mac.HTM
[01:12:37] <Jacky^> yeah nice..
[01:13:03] <Jacky^> to be honest Ive seen many cheap machine in cnczone gallery too
[01:13:04] <les_w> good website. good marketing skills. Very clever.
[01:13:14] <Jacky^> yes, good
[01:16:11] <Jacky^> uhm.. but slow
[01:16:27] <Jacky^> width = 72mm height = 100 mm. Engraving time 6 and a half hours.
[01:16:39] <Jacky^> & hours are a lot
[01:16:47] <Jacky^> 6
[01:18:08] <les_w> well, later you will have something fast
[01:18:12] <les_w> very fast
[01:18:20] <Jacky^> :-)
[01:18:54] <Jacky^> I think i cant get the job in the url you pasted in about 2 hours
[01:19:01] <Jacky^> with my actual cnc
[01:19:14] <les_w> that is good
[01:19:17] <Jacky^> about 28 inches/min
[01:19:30] <Jacky^> one pass only
[01:20:08] <Jacky^> I think he will have the same issue I had burning the bits at that speed
[01:20:43] <les_w> yes...must use slow spindle rpm to keep chip load up
[01:20:47] <Jacky^> but its a cool machine for hobbist use
[01:20:51] <Jacky^> very nice
[01:20:55] <les_w> yeah
[01:24:48] <les_w> Dave sent me an email and he can't get above 33 blocks/sec....somethings wrong...
[01:25:37] <anonimasu> hmm
[01:25:59] <anonimasu> 6 hours is awfully slow
[01:26:00] <anonimasu> :/
[01:27:13] <les_w> well, I was talking to jyymm earlier...he just about talked me into costing up a hobby cnc router. I'll look at it tommorow.
[01:27:36] <anonimasu> les_w: paint robot?
[01:27:37] <les_w> I'm used to designing industrial machines...but let's see what hapens
[01:27:53] <les_w> no just a 3 axis hobby router
[01:28:04] <anonimasu> les_w: yeah, but shouldnt you be finishing that alaso?
[01:28:05] <anonimasu> also?
[01:28:13] <les_w> I have never designed a hooby tool
[01:28:25] <Jymmm> les_w how about a Booby Tool ?
[01:28:43] <anonimasu> les_w: nice challenge :)
[01:29:43] <les_w> 51 min left
[01:29:50] <les_w> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=7568393590&ru=http://search.ebay.com:80/7568393590QQfviZ1
[01:30:10] <les_w> all those bids are schills though I think
[01:30:24] <anonimasu> yeah
[01:30:28] <anonimasu> like 80%
[01:30:39] <anonimasu> that machine is expensive :)
[01:30:55] <les_w> could I blow that design away?
[01:30:59] <les_w> let's see.
[01:32:39] <wb9mjn> Beware!!! Deepgroove is who i got the D+M 6 from !
[01:34:47] <wb9mjn> My experience with him is that he was less than contientious with the description of the item, and after the sale/payment less than forthcoming when his mistake (or what have you)
[01:35:03] <wb9mjn> was indesputably identified to him...
[01:35:29] <les_w> well yeah. from the ad copy syntax and the obvious scills the guy seems a boob
[01:35:43] <les_w> schills
[01:36:28] <les_w> 52 bids hahaha
[01:49:48] <fenn> les i'm telling you it's all in how pretty it looks
[01:49:57] <Jacky^> hey fenn
[01:50:03] <Jacky^> what about the cam idea ?
[01:50:04] <fenn> if the engineering is perfect but it looks like crap nobody will buy it
[01:50:30] <fenn> Jacky^: thanks for the reminder.. i need to write that guy back
[01:50:52] <Jacky^> hehe :) im like crontab
[01:50:54] <wb9mjn> The problem is as a customer you get really pissed when it looks pretty, but does not work !
[01:51:19] <wb9mjn> Because then you know the people you are dealing with pulled a fast one and wont make good !
[01:55:49] <Jacky^> oh .. this is really a crap :http://www.ciakilledlennon.blogspot.com/
[01:56:06] <Jacky^> 100% false
[01:57:14] <Jacky^> a pic of this guy appear on a news yestarday in many IT website's
[01:58:03] <Jacky^> looks like a big crap
[02:10:50] <fenn> cradek/jepler do you know why the view in axis goes blank if you zoom out too far?
[02:11:09] <cradek> yes
[02:11:23] <cradek> oh, why? not really
[02:11:27] <cradek> "don't do that"
[02:11:31] <fenn> damn
[02:11:55] <alex_joni> how much out?
[02:12:05] <cradek> probably something about clip planes or the limited z buffer bits
[02:12:09] <cradek> alex_joni: a lot
[02:12:34] <alex_joni> like.. next room?
[02:12:50] <Jacky^> :D
[02:13:01] <cradek> to where the whole view is only a few pixels across
[02:13:23] <SWPadnos_> actually, it seems to happen when the view is 10-20 inches across for me
[02:13:40] <cradek> you mean pixels?
[02:13:51] <SWPadnos_> I did dsome testing with G0X10, and when I zoomed out to see the whole move, the line disappeared
[02:14:04] <SWPadnos_> not screen inches, scaled model inches
[02:14:04] <cradek> hmm
[02:14:07] <cradek> that doesn't sound right then
[02:14:17] <cradek> is your ini inch?
[02:14:24] <SWPadnos_> the line thickness amy go below some threshold in the GL package
[02:14:27] <SWPadnos_> yes
[02:14:48] <SWPadnos_> I'll check that again though
[02:14:57] <fenn> this file is only like 65 inches across (i forgot to put it into mm)
[02:15:57] <fenn> another thing, the whole X display freezes up for about 30 seconds when loading a 25k line gcode file
[02:16:57] <fenn> it sure looks cool when its done though
[02:17:11] <cradek> fenn: it's generating some huge display lists
[02:17:27] <cradek> fenn: with Mesa in the x-server it may cause it to pause
[02:17:44] <cradek> so that probably can't be fixed
[02:17:51] <cradek> however, I get a nice progress bar and no freeze
[02:17:58] <cradek> maybe our X servers are different
[02:18:12] <fenn> probably.. i'm using xorg
[02:18:16] <fenn> bdi is xf86 right?
[02:18:21] <cradek> no idea
[02:18:24] <cradek> my machine is xfree86
[02:18:27] <Jacky^> cradek: are the actual free libs supporting 3D accell. ?
[02:18:45] <fenn> Jacky^: yes, but not for nvidia
[02:18:48] <cradek> Jacky^: a few I think
[02:18:55] <Jacky^> may Ati ?
[02:18:59] <SWPadnos_> ok - roughly 58 inches of total width is the limit, one more mouse wheel roll, and the line disappears
[02:19:00] <cradek> mine is XFree86 4.3.0
[02:19:10] <cradek> yes there are some ATI
[02:19:45] <SWPadnos_> there are free, but not open source, drivers for Nvidia
[02:19:52] <SWPadnos_> they work quite well
[02:19:59] <cradek> no, not with realtime
[02:20:06] <cradek> they don't work at all
[02:20:25] <SWPadnos_> does ATI have RT 3D libraries?
[02:20:41] <SWPadnos_> or is it because you can use GATOS or something and recompile?
[02:20:42] <cradek> I think some ATI cards have OSS support in new xorgs
[02:20:48] <SWPadnos_> ok
[02:20:51] <cradek> I don't know the details
[02:20:55] <cradek> my hardware and software is all too old
[02:21:08] <cradek> for AXIS software rendering is 100% just fine
[02:21:26] <SWPadnos_> maybe I'll see if the adeos / RTAI 64 bit SMP stuff works, and also see if the NVidia driver works at the same time ;)
[02:21:36] <cradek> yikes
[02:21:40] <SWPadnos_> but not tonight
[02:21:43] <cradek> sounds interesting but a pain in the neck
[02:22:24] <SWPadnos_> yep
[02:23:05] <SWPadnos_> it is interesting to note that the line disappears at a particular zoom, reagrdless of the window size
[02:23:08] <fenn> how hard would it be to highlight multiple lines of gcode at once?
[02:23:37] <cradek> fenn: possible
[02:23:49] <Jacky^> Video cards hacking seems to be the black beast of free software :/
[02:24:03] <SWPadnos_> (my bet is that it's conceptually easy, but would require an array of booleans to tell if each line is selected, rather than a single "current line" number)
[02:24:10] <fenn> Jacky^: that, and installing onto old laptops
[02:24:36] <fenn> swp i was just a list of line numbers
[02:24:36] <SWPadnos_> possibly a range would work, if you can lose separate multi-select
[02:24:53] <cradek> yeah, a range would not be too hard
[02:25:04] <SWPadnos_> a list can also work
[02:26:49] <les_w> congo the cat is sleeping here in the office on a MSC catalog
[02:26:58] <les_w> looks silly
[02:27:34] <Jacky^> fenn: i was thinking ad some game for linux like quakeIII interfacing video card with fast performance
[02:30:01] <fenn> jacky as long as it uses opengl there should be nothing unusual
[02:32:20] <cradek> haha "congo"
[02:32:36] <Jacky^> ?
[02:34:32] <Jacky^> congo bongo ?
[02:35:56] <cradek> congo is the name of les's cat and I think it's a funny/cute cat name
[02:36:08] <Jacky^> oh cool :)
[02:36:39] <Jacky^> wow http://www.live-id.org/j64/
[02:36:47] <Jacky^> nostalgy website lol
[02:37:17] <alex_joni> mama was queen of the congo..
[02:38:30] <alex_joni> King of the bongo, king of the bongo bong
[02:39:01] <Jacky^> uhm
[02:39:08] <Jacky^> whats the right sintax ?
[02:39:16] <alex_joni> syntax
[02:39:25] <Jacky^> tried :
[02:39:32] <Jacky^> 1 print hello
[02:39:37] <Jacky^> 2 goto 1
[02:39:39] <Jacky^> run
[02:39:44] <alex_joni> basic?
[02:39:50] <Jacky^> ?syntax error in 1
[02:39:53] <Jacky^> :)
[02:39:55] <Jacky^> yeah
[02:40:03] <alex_joni> needs quotes I think
[02:40:04] <cradek> print "hello"
[02:40:13] <alex_joni> yup
[02:40:16] <cradek> and it should be print "Hello World"
[02:40:38] <Jacky^> wooow wok :P
[02:40:44] <Jacky^> work *
[02:40:49] <alex_joni> although.. it's been 11 years since my last basic program
[02:40:51] <cradek> what does?
[02:40:55] <alex_joni> hello
[02:40:56] <alex_joni> hello
[02:40:57] <alex_joni> hello
[02:40:57] <alex_joni> hello
[02:40:57] <alex_joni> hello
[02:40:58] <alex_joni> hello
[02:40:58] <alex_joni> hello
[02:40:59] <alex_joni> hello
[02:41:01] <alex_joni> ..
[02:41:16] <alex_joni> [04:40] <alex_joni> hello
[02:41:17] <cradek> who's writing basic (and why??)
[02:41:31] <alex_joni> Jacky^ is, and you're helping
[02:41:32] <Jacky^> cradek: http://www.live-id.org/j64/
[02:41:34] <Jacky^> hehe
[02:41:34] <fenn> go to bed alex
[02:41:46] <Jacky^> tring to remember ..
[02:42:00] <cradek> aha, a rectangle that says "Click here to download plugin"
[02:42:01] <Jacky^> cat stop the program now :/
[02:42:03] <Jacky^> lol
[02:42:12] <cradek> Jacky^: hit the RUNSTOP key
[02:42:13] <Jacky^> yeah, you need java
[02:42:37] <alex_joni> cradek: you need java to emulate a commodore 64 that runs basic
[02:42:38] <alex_joni> not that easy as you'd say :P
[02:42:41] <Jacky^> runstop in ibm keyboard ? :(
[02:42:42] <cradek> Jacky^: failing that, hold down RUNSTOP and smack RESTORE
[02:42:52] <cradek> you can't just press RESTORE, you have to smack it, I don't know why
[02:43:13] <cradek> did any of you guys have one of these nightmarish computers?
[02:43:25] <Jacky^> yes Ive it
[02:43:35] <Jacky^> i also have a commodore vic 20
[02:43:40] <cradek> I think mine is in a box 3m from me
[02:43:52] <Jacky^> and maybe a sinclair ZX spectrum somewhere
[02:43:56] <Jacky^> :)
[02:44:33] <cradek> I used to modem on my C64 and black&white tube (valve) TV
[02:44:41] <Jacky^> wow
[02:45:01] <cradek> it was a terrible display for a computer but it kept my basement bedroom warm
[02:45:07] <Jacky^> wow here are the program ready to run too http://www.dreamfabric.com/c64/
[02:45:09] <Jacky^> cool
[02:45:20] <Jacky^> java is required
[02:45:38] <Jacky^> cradek: nice :)
[02:46:09] <cradek> later I got a PC Jr. and after that ... AN XT!
[02:46:21] <Jacky^> :D
[02:46:21] <cradek> the XT kicked butt
[02:46:35] <cradek> it had ... a HARD DRIVE
[02:49:46] <SWPadnos_> woohoo -ST-506 interfaces ROCKed!!
[02:49:48] <Jacky^> cool , I never used hard drive beforse 386 series
[02:50:04] <cradek> I had a "hard card" in my XT
[02:50:05] <alex_joni> darn.. can't find that page :/
[02:50:15] <cradek> it was a hard drive that fit in a full-length ISA slot
[02:50:17] <alex_joni> seen a guy once that built an PC out of 74xx chips
[02:50:23] <alex_joni> CPU was 4 boards,
[02:50:25] <SWPadnos_> I had a 30M drive in college, but with the magic of an RLL controller, it was a whopping 50MB!!!
[02:50:28] <alex_joni> solid state disk, etc
[02:50:36] <cradek> alex_joni: 74LS I hope, otherwise it would take quite a power supply
[02:50:47] <alex_joni> yeah.. some 30MHz iirc
[02:50:54] <cradek> wow, that's fast
[02:50:58] <alex_joni> he even had a network card and surfed the net with it
[02:51:09] <cradek> nah, I'm starting to not believe this
[02:51:13] <SWPadnos_> I'd love to see how fast a PC you could make in a modern FPGA
[02:51:32] <SWPadnos_> using a fast 8086 implementation
[02:51:55] <SWPadnos_> I think they were only in the 10k gate range (+/- a factor of 2 or so)
[02:52:14] <alex_joni> cradek: that's why I hate not finding the link
[02:52:30] <cradek> alex_joni: I'm finally testing my FO changes
[02:52:40] <alex_joni> and?
[02:52:55] <cradek> seems right so far
[02:53:20] <alex_joni> nice
[02:53:54] <cradek> I've always had my max FO at 100%
[02:53:57] <cradek> it will be nice to be able to use it now
[02:55:23] <cradek> yep, I think it works right
[02:55:32] <cradek> (testing arcs)
[02:55:40] <cradek> whee
[02:58:02] <Jacky^> well, its raining good time to sleep :P night all
[02:58:09] <cradek> goodnight
[02:58:17] <Jacky^> Jacky^ is now known as Jacky^afk
[03:21:00] <skunkworks> think I have flunked steppers. I have not been able to test emc2 much as my z axis is not cooperating. I seem to be gaining steps. yes gaining steps. randomly. the pusle train to the stepper driver looks good. two different stepper drives both do the same thing.
[03:22:20] <cradek> skunkworks: do you know why only Z?
[03:22:28] <skunkworks> not yet
[03:22:33] <skunkworks> gave up today.
[03:22:51] <skunkworks> x and y seem to reposition perfectly.
[03:23:05] <skunkworks> something stupid I am sure
[03:23:38] <cradek> badly-working steppers can be very frustrating
[03:26:15] <SWPadnos_> skunkworks: are you measuring more travel than emc thinks it has output, or is emc outputting longer travels than you ask for?
[03:26:58] <SWPadnos_> (ie, for example if you command a 10 inch move, does emc say 10.000, but a dial indicator tells you 10.02, or does the emc display show 10.02)
[03:27:35] <skunkworks> It isn't emc as I was having the same problem the other day and when I switched out to turbo cnc it did the same thing.
[03:27:49] <SWPadnos_> ok (phew :) )
[03:27:49] <jmkasunich> maybe electrical noise
[03:28:07] <skunkworks> at this point I had the stepper off the machine and was counting rotation - should be 10 rotation per inch.
[03:28:08] <jmkasunich> noise from the motor leads gets back into the inputs and is treated as a step
[03:28:28] <jmkasunich> how many extra steps are you getting?
[03:28:34] <cradek> skunkworks: that sounds like a good way to separate electrical from mechanical problems
[03:28:52] <skunkworks> could be although on the scope the pulse train seemed good - Using a scope
[03:28:55] <skunkworks> it is randome
[03:29:01] <skunkworks> not consistant
[03:29:10] <cradek> you see noise on the pulse train?
[03:29:23] <cradek> oh I misread
[03:29:34] <jmkasunich> how many steps per rev do you have? IIRC, you have 20000 per inch, is that true? if so, thats 2000 per rev
[03:29:37] <skunkworks> no - I see a nice pulse train.
[03:29:41] <skunkworks> I now have 10000
[03:29:49] <jmkasunich> ok, so 1000 per rev
[03:30:03] <SWPadnos_> and you're using 5x microstepping (now - was 10)?
[03:30:06] <jmkasunich> you have something attached to the stepper shaft so you can count revs?
[03:30:10] <cradek> maybe put a mark or pointer on the motor shaft next
[03:30:19] <cradek> ha, yeah what he says
[03:30:24] <skunkworks> just a flywheel with a mark
[03:30:40] <skunkworks> it is easy to spot that it is off
[03:30:58] <cradek> so the motor shaft rotation is the part that's off?
[03:31:05] <skunkworks> right
[03:31:06] <jmkasunich> at 1000 steps per rev, you must be missing or gaining a lot of steps if you can easily see it
[03:31:15] <skunkworks> right
[03:31:20] <cradek> skunkworks: does it SOUND right?
[03:31:27] <skunkworks> that is my thought
[03:31:30] <jmkasunich> you command a 0.1" move (one turn) and it screws up?
[03:32:23] <SWPadnos_> skunkworks: what stepper drives are you using?
[03:32:32] <skunkworks> yes - it screws up. and no it does not sound right. the motor will rock and then I will know that it is off
[03:32:58] <cradek> rock?
[03:32:58] <skunkworks> I tried at a compumotor s6 and now I am using a oem650
[03:33:22] <jmkasunich> are all your motors the same?
[03:33:31] <alex_joni> sounds like lost steps
[03:33:35] <jmkasunich> same type motor, not same problem...
[03:33:37] <alex_joni> as in too much speed
[03:33:44] <skunkworks> no - my x and y are german - don't remember the brand
[03:33:46] <jmkasunich> alex: go to sleep
[03:33:58] <alex_joni> yeah.. you wish
[03:34:16] <skunkworks> I also tried two different stepper motors
[03:37:40] <skunkworks> alex - yes my problem - not emc dependant
[03:40:11] <cradek> skunkworks: so it is ahead, not behind, when it goes wrong?
[03:41:24] <jmkasunich> two possibilities: 1) you are actually gaining steps (noise or something) or 2) the motor is skipping a step during decel
[03:41:40] <skunkworks> seems to be - although I know that doesn not make sense. - it definatly wasn't loosing a whole turn but the mark was bulding
[03:41:56] <jmkasunich> ?
[03:42:01] <jmkasunich> the mark was what?
[03:42:09] <skunkworks> mark was gaining.
[03:42:11] <skunkworks> sorry
[03:42:14] <jmkasunich> heh
[03:42:24] <SWPadnos_> what stepper driver are you using?
[03:42:31] <jmkasunich> how much does it gain?
[03:42:43] <jmkasunich> 1001 questions....
[03:42:52] <SWPadnos_> each ;)
[03:43:01] <cradek> are they bipolar or unipolar?
[03:43:02] <skunkworks> right now compumotor oem650 have tried an compumotor s6
[03:43:06] <skunkworks> bipolar
[03:43:44] <jmkasunich> SWP: he answered that question before, that's cheating... you gotta think up new ones
[03:43:51] <SWPadnos_> ok - the S6 is the driver (sorry - I'm not familiar with the compumotor stuff)
[03:43:55] <jmkasunich> (the model that is)
[03:43:58] <cradek> it does seem like it might be noise
[03:44:12] <SWPadnos_> how is the multiplier (microstepping) set?
[03:44:14] <cradek> skunkworks: you are using step/dir right?
[03:44:29] <skunkworks> could be the breakout board is home made - yes step and direction
[03:44:49] <jmkasunich> you could try dropping the max accel and max velocity by half
[03:45:04] <jmkasunich> if it still happens, you know its not because you are acceling too fast and skipping steps
[03:45:10] <skunkworks> I have - I had the accelleration set to .1 - still a problem
[03:45:15] <SWPadnos_> he said that TurboCNC also failed the same way
[03:45:23] <SWPadnos_> (you gotta think up new questions ;) )
[03:45:25] <cradek> jmkasunich: but it's ahead - that never happens
[03:45:25] <skunkworks> right
[03:45:44] <jmkasunich> its gotta be noise or something then
[03:45:48] <SWPadnos_> so - how is the microstep multiplier set on this drive?
[03:45:48] <cradek> yes, seems like
[03:45:59] <skunkworks> never had this problem before. - odd
[03:46:10] <jmkasunich> cradek: if you skipped a step while in decel, you'd wind up ahead
[03:46:32] <skunkworks> jmk - never thought about that.
[03:46:33] <SWPadnos_> not in decel, but in reverse
[03:46:40] <cradek> jmkasunich: maybe so...
[03:47:01] <jmkasunich> but he's already tested multiple accel values, so that isn't it
[03:47:05] <SWPadnos_> no - if the motor ever misses a step, it will end up behind - decel doesn't reverse direction
[03:47:11] <cradek> mine just stall if anything goes wrong
[03:47:27] <skunkworks> .1 accellerats really slow ;)
[03:47:31] <jmkasunich> swp: consider a stepper hooked to a big flywheel
[03:47:40] <jmkasunich> accel slowly till all is spinning
[03:47:47] <jmkasunich> then stop the step pulses
[03:47:47] <SWPadnos_> that's not the bench scenario though
[03:47:52] <SWPadnos_> sure
[03:47:54] <jmkasunich> I betcha it will be ahead
[03:48:06] <SWPadnos_> yep - in that case, I'd agree
[03:48:48] <jmkasunich> so for some value of decel, the motor can skip a step (actually four full steps) and wind up ahead
[03:49:09] <jmkasunich> although you'd be more likely to screw up on accel first
[03:49:21] <cradek> yeah, since it's symmetrical
[03:49:26] <SWPadnos_> ok - I see the failure mode now (thanks), but I'd doubt that as the cause when the motor is on the bench
[03:49:28] <cradek> but none of this is his problem
[03:49:33] <jmkasunich> right
[03:49:48] <cradek> skunkworks: are the snubber diodes in the drive or external?
[03:49:51] <jmkasunich> but drifting off topic is what we do best ;-)
[03:50:02] <cradek> jmkasunich: that reminds me of a funny story
[03:50:10] <jmkasunich> do tell....
[03:50:19] <cradek> jmkasunich: that was a joke (not funny I guess)
[03:50:24] <skunkworks> pulled the motor off the machine hooked it directly to the drive. changed the period to increase the "on" time (drives need 200us minimum - I was running 300us - changed it to 500us)
[03:50:29] <jmkasunich> I know it was a joke
[03:50:33] <jmkasunich> I was playing along
[03:50:38] <cradek> oh, sorry, I'm slow
[03:50:44] <alex_joni> what story?
[03:50:45] <alex_joni> :P
[03:50:49] <skunkworks> snubbers are in the drive
[03:50:55] <jmkasunich> alex: go to sleep
[03:50:55] <SWPadnos_> alex_joni: go to sleep
[03:50:56] <cradek> alex => slower
[03:51:00] <cradek> no kidding
[03:51:07] <cradek> 6am? may as well stay up now
[03:51:11] <alex_joni> alex goes slowly to sleep
[03:51:17] <alex_joni> nah.. want to do some coding today
[03:51:35] <jmkasunich> sleep from now till noon, then code
[03:51:36] <SWPadnos_> oh - in that case, have some more coffee
[03:51:41] <alex_joni> screw up emc2, as I took care of emc1 yesterday ;)
[03:52:07] <cradek> jmkasunich: did I tell you I fixed the feed override > 100% problem?
[03:52:22] <jmkasunich> no, howd'ja do that?
[03:52:32] <cradek> the way I proposed the other night
[03:52:43] <alex_joni> send both speeds down
[03:52:44] <cradek> SET_VEL has two numbers, requested at 100% and max possible
[03:52:53] <jmkasunich> ah, ok
[03:52:55] <alex_joni> and don't increase over the second
[03:53:16] <jmkasunich> .... ok, now I remember seeing the commit message, you added a second argument to those functions
[03:53:21] <jmkasunich> cool
[03:53:40] <cradek> so now you can set your FO at 999% and it will go your max machine speed always
[03:53:46] <cradek> very nice feature
[03:54:19] <alex_joni> yup
[03:54:32] <alex_joni> jmkasunich: remember feed adaptation?
[03:54:48] <alex_joni> you looked at that when we looked at the FO bug
[03:54:55] <alex_joni> if you have one axis way slower
[03:54:56] <jmkasunich> if you say so
[03:55:02] <alex_joni> emc slows down the whole move
[03:55:11] <alex_joni> guess where that gets done..
[03:55:12] <jmkasunich> oh, right
[03:55:18] <jmkasunich> dunno
[03:55:22] <alex_joni> emccanon
[03:55:24] <cradek> I know!
[03:55:33] <alex_joni> cradek: of course you know :P
[03:55:45] <cradek> pick me! pick me!
[03:55:59] <alex_joni> jmkasunich: so it's not TP afterall
[03:56:09] <alex_joni> tp is plain stupid in emc2 ;)
[03:56:15] <alex_joni> not plain stupid..
[03:56:21] <alex_joni> simple..
[03:56:34] <jmkasunich> as it should be
[03:57:05] <alex_joni> yup
[03:57:14] <alex_joni> but a bit more advanced might still be ok
[03:58:45] <skunkworks> I thought roltek would be back this weekend. I was told he might get a kick out of my k&T.
[03:59:39] <alex_joni> oohhh.. look at the time.. gotta go
[03:59:42] <alex_joni> night all
[03:59:44] <alex_joni> ;)
[03:59:50] <jmkasunich> night alex
[03:59:51] <skunkworks> night alex
[04:00:26] <jtr_> skunkworks: have you tried swapping the step and direction leads to another axis?
[04:00:59] <skunkworks> did that a few days ago. just ran out of time tonight.
[04:02:07] <jtr_> might help isolate between motor/drive and breakout board.
[04:02:32] <skunkworks> what we had thought solved it a day ago was changing to the oem650 - thought that we must not have been driving the s6 hard enough. but now the 650 is doing the same thing.
[04:03:03] <cradek> skunkworks: I don't know if I asked before - are the snubber diodes in the drive or external?
[04:03:32] <skunkworks> jtr - I don't know. Both drives have opto-isolated inputs.
[04:03:39] <skunkworks> snubbers are internal
[04:04:02] <cradek> skunkworks: oh ok, I was just thinking a bad one could cause havoc
[04:05:08] <jepler> One ingredient of its meaning is certainly Ajax, which I can still only just bear to use without scare quotes. Basically, what "Ajax" means is "Javascript now works." -- Paul Graham
[04:06:31] <skunkworks> http://www.parkermotion.com/manuals/OEM/OEM350-650.pdf
[04:06:36] <jmkasunich> jepler: huh?
[04:06:45] <SWPadnos_> interesting - compumotor says that you need a 40-60% duty cycle on the step pulse input
[04:06:51] <SWPadnos_> (on the S6)
[04:06:59] <jmkasunich> well that ain't gonna work
[04:07:03] <SWPadnos_> nope
[04:07:07] <SWPadnos_> only at full speed
[04:07:21] <skunkworks> the 650 requires a 200us pulse
[04:07:31] <jmkasunich> wow, that is long too
[04:07:40] <SWPadnos_> 200 ns, and also 40-60% duty cycle
[04:07:53] <jepler> sorry, that paste wasn't very relevant to #emc.
[04:08:00] <jmkasunich> did you change your stepgen pulse-width parameter to get the 200uS?
[04:08:21] <SWPadnos_> it's not microseconds - the manual says nanoseconds
[04:08:56] <SWPadnos_> and 6.5-15 mA, though that shouldn't be a problem
[04:08:57] <skunkworks> well then it isn't a problem. I think I am too tired.
[04:09:20] <SWPadnos_> what's the configuration of your breakout board?
[04:09:41] <jtr_> night all - just got last call... Good luck with this one
[04:09:47] <SWPadnos_> do you have isolation, buffers, etc, or is it just a set of terminals?
[04:09:50] <skunkworks> crap - it has been a year since I built it - I don't remember.
[04:09:55] <SWPadnos_> heh
[04:10:00] <skunkworks> it is buffers ttl if I remember right
[04:10:12] <SWPadnos_> ok.
[04:10:14] <jtr_> jtr_ is now known as jtr_away
[04:10:14] <skunkworks> open collector
[04:10:27] <SWPadnos_> hmm - so they pull to ground
[04:11:00] <skunkworks> right
[04:11:10] <SWPadnos_> and you have the + for both step and direction connected to +5V
[04:11:18] <skunkworks> right
[04:11:25] <SWPadnos_> (they're not internally connected)
[04:11:53] <jmkasunich> SWP: where in the manual did you find the pulse width info?
[04:12:23] <SWPadnos_> chapter 3, page 26 (18 in the PDF)
[04:12:38] <SWPadnos_> but not from the first google hit ;)
[04:12:51] <SWPadnos_> http://parkermotion.com/manuals/s-sx/s/S_chp3_h.pdf
[04:13:52] <skunkworks> right - two inputs totally isolated - I have the 2 positives hooked togather to + and the -'s hooked to each buffer ouput. (they may be inverters) what ever it took to get in-out the same. If that made sense
[04:14:08] <SWPadnos_> ok - tomorrow, you should try the motor test with several different microstep settings, including 200 steps per revolution (all resolution switches on)
[04:14:57] <jmkasunich> 2mS setup time on the direction inputs, that seems really high
[04:15:03] <SWPadnos_> I had thought at first that the microstep settings might be flakey, so that sometimes it would move further (thinking it was in a lower resolution mode)
[04:15:45] <SWPadnos_> they do talk about indexers all the time, maybe the drive isn't meant for this type of use?
[04:16:35] <skunkworks> the oem650 can come with or without the indexer.
[04:16:58] <SWPadnos_> right, but if the drive is meant to operate an indexer, there would be way fewer direction changes
[04:17:28] <SWPadnos_> I also note that there's a "zero phase input" - I'm assuming that that is an index pulse
[04:17:47] <SWPadnos_> but it may be some kind of expected feedback per rev of the shaft
[04:18:01] <skunkworks> I am pretty sure it is something stupid. we have played with these drives before with no issues.
[04:18:25] <SWPadnos_> ok - zero phase has nothing to do with my thought - nevermind
[04:18:35] <SWPadnos_> (just had to look at hte next page :) )
[04:19:20] <SWPadnos_> hmmm - I see 2 ms direction setup time - was that 25 ms a typo jmk?
[04:19:34] <SWPadnos_> nevermind -it was an eyeball problem here
[04:19:40] <SWPadnos_> maybe I should go to sleep as well
[04:20:18] <skunkworks> http://www.electronicsam.com/video/MVC-341W.MPG
[04:20:19] <jmkasunich> 2mS is still very ling
[04:20:27] <SWPadnos_> and that could explain it as well
[04:20:48] <skunkworks> this was done with the oem650's
[04:20:53] <skunkworks> no issues
[04:21:09] <SWPadnos_> unless the reversal time is set correctly, any backlash (or correction of overshoot) would cause forward pulses for a little while
[04:21:55] <skunkworks> right - but turbocnc allows you to set a axis revers pause in ms. No effect.
[04:22:01] <SWPadnos_> ok
[04:22:09] <SWPadnos_> maybe the driver is screwed ;)
[04:22:15] <SWPadnos_> but you tried others
[04:22:19] <skunkworks> 3 act the same way
[04:22:29] <SWPadnos_> and only with this motor?
[04:22:37] <skunkworks> 2 s6 and one oem650
[04:22:48] <skunkworks> tried 2 differnt style steppers
[04:22:52] <skunkworks> also
[04:23:01] <SWPadnos_> did you set the current for each motor?
[04:23:03] <skunkworks> I just might be f&cked ;)
[04:23:06] <skunkworks> right
[04:23:28] <SWPadnos_> there are like 182 current settings, it seems
[04:24:00] <skunkworks> one is set with dip switches - the other is set with a resister
[04:24:12] <SWPadnos_> wait a second - did you try all six combinations of 3 drives and 2 motors?
[04:24:22] <jmkasunich> I think I've asked this one several times, don't think you've answered.... how much "too far" does it go? half a rev, 1/10 of a rev, 4 full steps, 1 micro-step? and how many revs are you asking it to turn? 1 rev (0.1"), or more than one?
[04:24:26] <SWPadnos_> (and then both with turbocnc and emc?
[04:24:42] <fenn> how many permutations can we come up with?
[04:24:47] <skunkworks> ;)
[04:24:48] <jmkasunich> too many
[04:24:51] <SWPadnos_> 12 so far
[04:25:06] <SWPadnos_> unless you throw an external pulse generator and emc1 into the mix
[04:25:25] <skunkworks> we have tried quite a few. don't know how many differnt combos we have tried.
[04:26:23] <skunkworks> we have tried quite a few. don't know how many differnt combos we have tried.
[04:26:31] <skunkworks> as far as shaft error - it was random - from a few degrees to 1/4 rotation . now as far as the 1/4 rotation is concerned - I am not really sure if that was a gain or a loss.
[04:27:35] <jmkasunich> a few degrees is a least a couple full steps.... 1/4 turn is 50 full steps, or 250micro steps... this isn't some minor thing
[04:27:50] <jmkasunich> how far are you asking it to turn? 1 rev, 10 revs?
[04:27:50] <skunkworks> right
[04:28:11] <skunkworks> most of the time we where doing inches - 10 turns
[04:28:24] <skunkworks> nothing smaller than that
[04:31:43] <jmkasunich> if you've swapped the motors, the drives, and even the pulse sources (EMC/TurboCNC), what does that leave?
[04:31:55] <jmkasunich> the parport cable, the breakout board, and the wiring.....
[04:32:05] <jmkasunich> check for loose connections, bad solder joints, etc
[04:32:20] <SWPadnos_> operator error ;)
[04:32:25] <skunkworks> ;)
[04:33:02] <jmkasunich> did you try moving the step and dir wires for that amp to a differnet channel (from Z to X for instance)?
[04:33:11] <skunkworks> when we figure it out I will let you guys know. Like I say it is probably something stupid.
[04:33:17] <jmkasunich> ok
[04:33:21] <jmkasunich> good luck
[04:33:22] <skunkworks> yes - we did change
[04:33:33] <jmkasunich> and still had the problem?
[04:33:52] <skunkworks> from z to x - that was when we figured it was the drive - same effect
[04:34:17] <jmkasunich> ok, that rules out a defective channel in the breakout board, and most likely rules out cable problems too
[04:34:21] <SWPadnos_> is this basically new equipment, or surplus eBay-ish stuff?
[04:34:29] <skunkworks> surplus
[04:34:50] <jmkasunich> its odd that multiple units would be broken the same way, but not out of the question
[04:34:51] <SWPadnos_> ok - you may have a motor with a bad winding, and be destroying drives (if they're not protected from that)
[04:35:05] <skunkworks> can't afford new. - break out board was home made - actually have 2 of them made maybe I will change them out for shits and gigles
[04:35:27] <jmkasunich> you say you've had success with these amps before?
[04:35:30] <skunkworks> swp - that is scary. didn't think of that.
[04:35:46] <skunkworks> http://www.electronicsam.com/video/MVC-341W.MPG
[04:35:58] <skunkworks> yes - this is the first time we have had problems
[04:36:02] <jmkasunich> cant view video here, can I have a clue?
[04:37:06] <skunkworks> just some steppers on a small vise - that was done with 2 oem650
[04:37:19] <jmkasunich> what software?
[04:37:35] <skunkworks> turbocnc at the time
[04:37:43] <jmkasunich> can you go back to that setup and test these amps?
[04:37:50] <skunkworks> we have
[04:37:55] <jmkasunich> and they work?
[04:38:55] <skunkworks> I guess I mean we have used turbocnc on the current setup with the same results with z
[04:39:07] <jmkasunich> ;
[04:39:09] <skunkworks> the old vise setup is long gone
[04:39:09] <jmkasunich> oops
[04:39:59] <jmkasunich> well your problem is one of two things - either your current setup is somehow differnet than the setup that worked (pulse lengths, wiring, breakout board, anything) or the amps are different (busted)
[04:40:20] <jmkasunich> might be stating the obvious, but keep that in mind
[04:40:25] <jmkasunich> try to find the difference
[04:40:42] <jmkasunich> if you can make everything else the same, then the difference must be the amps
[04:41:31] <skunkworks> oh well. tomarrow is a new day and maybe I will figure out what i did stupid. Like I said I think I have an extra buffer board also to try.
[04:41:41] <jmkasunich> ok
[04:41:42] <skunkworks> thanks for all your help
[04:41:50] <jmkasunich> good night, and good luck
[04:41:53] <skunkworks> it is nice having a sounding board
[04:42:08] <SWPadnos_> night
[04:42:13] <skunkworks> night
[05:00:17] <jmkasunich> SWPadnos_ thanks for the halcmd -R, I just needed it
[05:01:09] <jmkasunich> I meant to do "while true ; do bin/halcmd show pin ; sleep 1 ; done", but I forgot the sleep
[05:01:31] <jmkasunich> which means when I hit ctrl-C, there is a very good chance halcmd has the mutex
[05:02:18] <fenn> jmk why is the mutex all over the hal code?
[05:02:33] <fenn> shouldnt it be in some sort of read or write function?
[05:02:37] <jmkasunich> because it manipulates data that is in shared memory
[05:02:55] <jmkasunich> what code are you talking about? hal_lib, or halcmd?
[05:03:02] <fenn> well, i've only really looked at halcmd
[05:03:08] <jmkasunich> hal_lib is the read and write functions you want
[05:03:14] <SWPadnos_> heh - oops ;)
[05:03:25] <fenn> why is there any mutex stuff in halcmd then?
[05:03:27] <jmkasunich> but the hal_lib API doesn't cover all the things that halcmd needs to do, so it does many things directly
[05:03:42] <jmkasunich> I agree that it shouldn't be there, the API needs to be extended
[05:03:57] <jmkasunich> that is on the to-do list, along with about a thousand other things
[05:04:07] <SWPadnos_> what's the granularity of the nutex(es)
[05:04:08] <SWPadnos_> ?
[05:04:13] <SWPadnos_> mutex
[05:04:27] <jmkasunich> usually very short, except when halcmd is doing a show command
[05:04:45] <jmkasunich> it has to hold the mutex while it traverses the entire list, and prints it
[05:05:08] <jmkasunich> so it holds the mutex during printf calls and everything... very sloppy, I know
[05:05:08] <SWPadnos_> I mean - how much data is protected byt the mutex - or is there one for "all HAL structures"?
[05:05:19] <jmkasunich> all HAL metadata
[05:05:33] <jmkasunich> its all so interlinked you can't split it anyway
[05:06:06] <jmkasunich> pins are linked into a list, also linked to the components that own them (in their own list) and to signals they are connected to....
[05:06:21] <SWPadnos_> I assume it's only a block on writes though
[05:06:28] <jmkasunich> no, any access
[05:06:33] <SWPadnos_> no - I guess not, in that scenario
[05:06:40] <jmkasunich> I didn't want to get too elaborate
[05:07:09] <jmkasunich> if you are reading to traverse a list, you could allow somebody else to read, but you can't allow somebody to add or delete a list entry
[05:07:34] <SWPadnos_> right, and if you're writing, then don't let anyone read either
[05:07:39] <jmkasunich> until halcmd came along, no code ever held the mutex for more than a couple microseconds
[05:07:45] <jmkasunich> so it was a non-issue
[05:07:50] <SWPadnos_> yep
[05:08:05] <SWPadnos_> this could be a problem for Ray
[05:08:17] <jmkasunich> why?
[05:08:25] <fenn> the watch halcmd show stuff?
[05:08:32] <SWPadnos_> he wants a "watch window" on selected pins / signals
[05:08:39] <jmkasunich> watch only does it once every 2 seconds
[05:08:52] <SWPadnos_> that'll be settable I imagine
[05:09:12] <SWPadnos_> ok - is there a RT portion of halcmd?
[05:09:20] <jmkasunich> no
[05:09:39] <SWPadnos_> so if halcmd gets suspended while doing a show, and it has the lock, you have RT problems
[05:09:48] <fenn> then you get to reboot - yay!
[05:09:50] <SWPadnos_> (another task executes)
[05:09:54] <jmkasunich> no
[05:10:02] <jmkasunich> no RT code ever asks for the mutex
[05:10:07] <jmkasunich> only init code
[05:10:28] <SWPadnos_> right - the mutex is only on themetadata, not the data
[05:10:32] <jmkasunich> right
[05:10:41] <SWPadnos_> ok - phew
[05:10:51] <SWPadnos_> (of course you would have had to think of that already)
[05:11:12] <jmkasunich> halcmd has a signal handler that catches ctrl-C, and is supposed to avoid such nastyness
[05:11:18] <jmkasunich> I wonder why it didn't work
[05:12:03] <SWPadnos_> how long does halcmd take to get pin data (roughly)?
[05:12:32] <SWPadnos_> I think I benchmarked it as about 1/2 the time to spawn a process with bash
[05:12:33] <jmkasunich> what command? one pins worth of data, or show pin (which shows all of them)
[05:12:47] <SWPadnos_> whatever you were doing when you needed -R
[05:12:53] <jmkasunich> heh, show pin
[05:13:02] <SWPadnos_> with no param?
[05:13:11] <jmkasunich> no filter, show all pins
[05:13:19] <jmkasunich> and I have a lot, ppmc driver is loaded
[05:13:40] <jmkasunich> 6mS
[05:13:42] <SWPadnos_> ok - that's probably still only 3 ms or so in halcmd, plus 8 ms for the process spawn (on my celeron 500)
[05:13:53] <SWPadnos_> have you checked spawn times?
[05:13:57] <jmkasunich> no
[05:14:39] <SWPadnos_> do that - time for i in `seq 1 1000' do ; /bin/echo hello > /dev/null ; done
[05:14:48] <SWPadnos_> (but you knew that - I think you told me that line)
[05:16:11] <jmkasunich> 1.616s, so 1.6mS to spawn
[05:16:20] <SWPadnos_> damn - that's fast
[05:16:31] <SWPadnos_> where's the typo on that line - it isn't working here
[05:16:43] <jmkasunich> ; do, not do ;
[05:16:48] <SWPadnos_> backquote
[05:16:52] <jmkasunich> that too
[05:17:18] <SWPadnos_> ok - phew :0
[05:17:36] <SWPadnos_> 1.235 ms here, but I have no idea what halcmd would be
[05:17:57] <SWPadnos_> anyway - the relative time was much different on my machine - maybe I was only doing one pin in my test
[05:17:58] <jmkasunich> 50mS to do 10 iterations of halcmd show pin >/dev/null
[05:18:41] <jmkasunich> did 100 iterations... works out to 1.6mS to spawn, 3.0mS to do the show
[05:18:44] <SWPadnos_> anyway - moot point. I just realized that halcmd had to be running at the time, or the mutex wouldn't have been held
[05:18:58] <jmkasunich> not entirely moot
[05:19:14] <SWPadnos_> unless you wre fscking with halcmd again ;)
[05:19:27] <jmkasunich> the relative times affect the odds of my ctrl-C hitting when halcmd is holding the mutex, vs when bash is spawning
[05:20:09] <jmkasunich> ok, now I'm fscking with halcmd
[05:20:16] <jmkasunich> added printfs in the signal handler
[05:20:35] <SWPadnos_> heh
[05:20:55] <jmkasunich> hmmm,
[05:21:11] <jmkasunich> "got a signal, hal_flag is CLEAR, exiting now"
[05:21:11] <SWPadnos_> not getting called or something?
[05:21:18] <jmkasunich> but it didn't, it hung
[05:21:26] <SWPadnos_> interesting
[05:21:40] <SWPadnos_> do you have to do an RTAI_exit() or something?
[05:22:02] <SWPadnos_> clean up memory sallocs or references with RTAI, etc?
[05:22:05] <SWPadnos_> allocs
[05:22:05] <jmkasunich> after it says "exiting now" it calls hal_exit(), then _exit()
[05:22:11] <SWPadnos_> ok
[05:22:33] <SWPadnos_> and hal_exit unconditionally drops the mutex?
[05:22:36] <jmkasunich> hal_exit() waits on the mutex, but if the flag was clear, who is holding the mutex
[05:25:15] <jmkasunich> hal_flag must not be getting set properly
[05:25:25] <SWPadnos_> it's only set once, before parse_cmd
[05:25:35] <SWPadnos_> and only cleared after parse_cmd
[05:26:14] <jmkasunich> exactly, and halcmd should only ever take the mutex inside parse_cmd
[05:26:57] <SWPadnos_> I wonder if the signal handler has access to data?
[05:27:32] <jmkasunich> it has to
[05:27:41] <jmkasunich> otherwise it can't do anything
[05:28:02] <SWPadnos_> true, but is it actually doing anything?
[05:28:13] <SWPadnos_> it didn't exit
[05:28:24] <SWPadnos_> (or it didn't hal_exit(comp_id)
[05:28:25] <jmkasunich> I put three printfs in the handler
[05:28:32] <jmkasunich> on at entry
[05:28:39] <jmkasunich> and one on each branch of the if/else
[05:28:57] <jmkasunich> I'll add more, after the hal_exit, etc
[05:29:09] <SWPadnos_> put in an extra var, initialized to something like 47, then print that in the handler
[05:30:00] <jmkasunich> next make
[05:30:05] <SWPadnos_> ok
[05:30:21] <SWPadnos_> your machine is an athlon 2000-ish, right?
[05:30:30] <jmkasunich> sempron 2800
[05:30:35] <SWPadnos_> ok - that's not bad
[05:30:40] <jmkasunich> I think about 1.6GHz actual clock
[05:30:58] <jmkasunich> sempron is AMD's version of the celeron I think?
[05:31:02] <SWPadnos_> just curious - the spawn times on my Opteron arent that much faster (also 1.6 GHz clock)
[05:31:17] <SWPadnos_> kinda - lower cache Athlon XP
[05:35:46] <jmkasunich> I'm stupid
[05:36:01] <SWP_Away> excellent!! problem solved ;)
[05:36:13] <jmkasunich> parse_cmd is called from two places - once in the loop (where we've been looking,and where it is protected)
[05:36:20] <CIA-12> 03paul_c * 10emc2-auto/wiki/ (14 files in 8 dirs): "Auto update wiki from a cron job. Sun Dec 11 05:30:01 GMT 2005 "
[05:36:24] <jmkasunich> the other is where it is called for a single command on the command line
[05:36:31] <jmkasunich> which is the case here
[05:36:37] <SWPadnos_> ah - and the flag isn't set the other time
[05:36:45] <SWPadnos_> the more common case, even
[05:36:54] <jmkasunich> not really
[05:37:19] <jmkasunich> unless you wrap the single command case in a bash loop
[05:37:49] <SWPadnos_> true - the other one is called repeatedly when reading a .hal file - OK.
[05:38:09] <SWPadnos_> * SWPadnos_ forgot that interactive mode and .hal mode are the same code
[05:40:08] <jmkasunich> ok, what this means is that a ctrl-C during a HAL cmd (like show pin) is ignored until the end of the command
[05:40:19] <SWPadnos_> yes, while the flag is on
[05:40:23] <jmkasunich> of course in single command mode, it would exit then anyway
[05:40:28] <SWPadnos_> right
[05:40:35] <jmkasunich> but the command is un-interruptable
[05:40:46] <SWPadnos_> unfortunately, it can't do anything else though
[05:41:19] <SWPadnos_> it may be in the middle of changing a signal or something
[05:41:37] <jmkasunich> so if I start my infinite loop of halcmd show pin, instead of hanging on ctrl-C most of the time, it will ignore it most of the time
[05:41:56] <SWPadnos_> it will ignore it, until it finishes the current run
[05:42:09] <jmkasunich> in this case, the looping is being done by bash
[05:42:10] <SWPadnos_> in theory
[05:42:24] <jmkasunich> halcmd handles the signal, and exits (which it was gonna do anyway)
[05:42:26] <SWPadnos_> ah - so it'll never stop
[05:42:48] <SWPadnos_> you would need the infinite loop script to check the exit status
[05:43:11] <jmkasunich> or hit the ctrl-C while bash is doing its thing
[05:43:21] <SWPadnos_> yep - getting lucky works too
[05:43:43] <jmkasunich> hmm, its not luck
[05:43:54] <jmkasunich> while true ; do sleep 1 ; echo hi ; done
[05:44:11] <SWPadnos_> is sleep an internal or an external?
[05:44:13] <jmkasunich> what are the odds of me hitting ctrl-C while anything other than sleep is active?
[05:44:18] <jmkasunich> dunno
[05:44:30] <SWPadnos_> I see a /bin/sleep
[05:44:51] <jmkasunich> and man sleep works, for bash internalls it usually doesn't
[05:45:07] <jmkasunich> anyway, that works fine, the ctrl-C interrupts the sleep and the loop
[05:45:12] <SWPadnos_> ok
[05:46:14] <jmkasunich> however, in spite of wrapping both calls to parse_cmd, it still hangs
[05:46:27] <jmkasunich> it says the flag is clear and hangs in hal_exit
[05:46:36] <jmkasunich> gonna try your variable test
[05:46:51] <SWPadnos_> ok - just a wild idea there
[05:48:01] <jmkasunich> nope, foo = 56
[05:48:08] <jmkasunich> (that was set at startup)
[05:48:10] <SWPadnos_> ok
[05:48:59] <SWPadnos_> you know - you may need to exit with a nonzero value to get the script to stop
[05:49:11] <SWPadnos_> maybe set done=2 in the sig handler
[05:49:29] <SWPadnos_> and exit(1) if it's 2, or exit(0) if done==1
[05:50:08] <jmkasunich> I want to get to the bottom of the flag thing first
[05:50:25] <SWPadnos_> the mutex thing
[05:50:26] <jmkasunich> (I know for a fact it is hanging in hal_exit, and never reaching _exit()
[05:50:48] <SWPadnos_> ah - and that only happens if the mutex is held by a different process?
[05:51:08] <jmkasunich> there aren't any other processes
[05:51:11] <jmkasunich> just this one
[05:51:25] <SWPadnos_> ok
[05:51:33] <jmkasunich> and this one shouldn't be holding the mutex unless the flag is set
[05:51:52] <jmkasunich> ok, somebody is fscking with the flag
[05:52:06] <jmkasunich> I set the initial value of the flag to 23
[05:52:13] <jmkasunich> in the handler it is zero
[05:52:22] <SWPadnos_> the hal_flag?
[05:52:25] <jmkasunich> yes
[05:52:41] <SWPadnos_> how are you running halcmd?
[05:53:06] <jmkasunich> while true ; do bin/halcmd show pin ; done
[05:53:17] <SWPadnos_> ok
[05:55:25] <jmkasunich> dumbass
[05:55:33] <SWPadnos_> heh - again?
[05:55:49] <jmkasunich> I copied the set flag/call parse/clear flag code from the other place to this place
[05:56:07] <jmkasunich> but didn't remove the original call (right after the clear flag)
[05:56:08] <SWPadnos_> ah - so it's 1 then 0 around the call
[05:56:20] <jmkasunich> its 1, call, 0, call again
[05:56:31] <jmkasunich> and in the loop, I didn't notice the double output
[05:56:44] <SWPadnos_> oh - oops
[05:57:14] <SWPadnos_> maybe parse_cmd should set and clear the flag?
[05:57:34] <jmkasunich> perhaps
[05:57:55] <jmkasunich> I have a printf'ed version here, want to check a few things first
[05:58:05] <SWPadnos_> there's only one return in the function - it would be easy
[05:58:43] <jmkasunich> well thats fscking weird
[05:58:55] <SWPadnos_> dumbass
[05:59:02] <SWPadnos_> oops - I mean, what's weird?
[05:59:03] <jmkasunich> the second call is still in there, all I did was add some printfs... and now it never hangs
[05:59:11] <SWPadnos_> racy
[05:59:42] <SWPadnos_> printf or rtapi_print?
[05:59:48] <jmkasunich> printf
[05:59:53] <SWPadnos_> hm
[06:03:59] <jmkasunich> you know, it really annoys me that Paul went sedding thru the code adding a comment to every single #if 0....
[06:04:17] <SWPadnos_> the \fixmes ?
[06:04:25] <jmkasunich> /*! \todo Another #if 0 */
[06:04:39] <SWPadnos_> ah - I think that's for the doxygen reports
[06:04:41] <jmkasunich> in this case, it was some test code that I if zeroed out
[06:04:52] <jmkasunich> it doesn't need to be in a doxygen report
[06:05:12] <SWPadnos_> I thikn you can get a list of todos with that notation (nicely formatted)
[06:05:20] <SWPadnos_> not sure though
[06:05:32] <jmkasunich> and all they will say is "Another #if 0"
[06:05:35] <jmkasunich> nothing usefull
[06:05:38] <SWPadnos_> true
[06:05:59] <SWPadnos_> nothing kate or kdevelop can't tell you
[06:10:54] <jmkasunich> dammit... I put the flag set and clear inside parse_cmd
[06:11:01] <jmkasunich> and I still managed to get it to hang
[06:11:10] <SWPadnos_> hmmm
[06:11:22] <SWPadnos_> and you searched to be sure that it isn't anywhere else?
[06:11:50] <jmkasunich> yep
[06:11:54] <jmkasunich> (double checking now)
[06:12:29] <jmkasunich> heh, found a typo, but that makes it even stranger
[06:12:36] <SWPadnos_> heh
[06:12:47] <jmkasunich> hal_flag exists 4 places,
[06:12:51] <jmkasunich> delcalred and inited to 0
[06:12:56] <SWPadnos_> and you did remove the init to 23?
[06:12:58] <jmkasunich> checked in the sig handler
[06:13:01] <SWPadnos_> ok
[06:13:07] <jmkasunich> set to 1 at the start of parse
[06:13:17] <jmkasunich> set to 1 (typo) at the end of parse
[06:13:21] <SWPadnos_> heh
[06:14:22] <jmkasunich> ok, added a print of its value in the sig handler
[06:14:45] <jmkasunich> and the init and both assignments now set it to unique non-zero values
[06:14:51] <jmkasunich> lets see which one prints...
[06:16:15] <jmkasunich> no failures... changing the init value back to zero
[06:16:51] <SWPadnos_> hm - so if it's nonzero all the time, it works?
[06:17:09] <jmkasunich> yeah
[06:17:31] <jmkasunich> halcmd just ignores the ctrl-C, you can only stop the loop if you hit it during the spawn
[06:18:08] <SWPadnos_> just for the heck of it, have halcmd print the comp_id just after hal_init
[06:20:30] <jmkasunich> it has to be positive, else the if right after the hal_init call would shut it down
[06:20:37] <SWPadnos_> true
[06:21:17] <jmkasunich> a ctrl-C right in the middle of hal_init() might be able to do screwy things
[06:21:29] <jmkasunich> no, I take that back
[06:21:44] <jmkasunich> because comp_id doesn't get set until the end
[06:21:58] <SWPadnos_> but it's not >0 until after hal_init finishes
[06:22:04] <SWPadnos_> it's initialized to -1
[06:22:05] <jmkasunich> hal_init() does hold the mutex...
[06:22:29] <SWPadnos_> so maybe you should set the flag around hal_init as well
[06:23:10] <jmkasunich> comp_id is initted to -1
[06:23:19] <SWPadnos_> and printf will help you to not hit the hal_init call
[06:23:59] <SWPadnos_> right - so if hal_init is executing, then the mutex may be held, but the hal_exit is never called, so you have a problem
[06:24:00] <jmkasunich> a ctrl-C during hal_init mught result in the signal handler being invoked while hal_init has the mutex, but comp_id would still be -1, so it wouldn't call hal_exit
[06:24:10] <SWPadnos_> right ;)
[06:24:14] <jmkasunich> yeah, what you said
[06:24:25] <jmkasunich> but thats not the same problem
[06:24:40] <SWPadnos_> what problem are you trying to track down?
[06:24:44] <jmkasunich> that would result in the program exiting, but the mutex held, it would hang on the next init call
[06:25:23] <jmkasunich> anything bad when you hit ctrl-C
[06:25:26] <jmkasunich> and I guess that counds
[06:25:29] <jmkasunich> counts
[06:25:49] <SWPadnos_> yep - it should be protected by the flag - anything that might grab the mutex
[06:29:16] <jmkasunich> setting the flag before the final hal_exit too...
[06:29:25] <SWPadnos_> indeed
[06:29:47] <SWPadnos_> and try the done=2 thing in the handler as well - it may help in breaking the shell loop
[06:30:09] <jmkasunich> actually, done = 1 is fine
[06:30:29] <SWPadnos_> no, because the main loop can also set done=1 if you type quit, right?
[06:30:40] <jmkasunich> right...
[06:31:07] <SWPadnos_> so, you want to return a nonzero value if ctrl-C was hit, but 0 if done was typed
[06:31:17] <SWPadnos_> s/done/quit/
[06:31:43] <jmkasunich> I can increment errorcount
[06:31:54] <SWPadnos_> sure - that'll work also
[06:32:15] <jmkasunich> once I make errorcount global anyway...
[06:32:36] <SWPadnos_> heh
[06:33:28] <SWPadnos_> actually, the only things that set done are the sig handler and a tokenizer error, so you could use that anyway (quit or exit just break)
[06:35:54] <jmkasunich> should rename done to "error_exit" or something
[06:37:28] <SWPadnos_> maybe - but then again, errorcount is what really decides if it's an error
[06:37:47] <SWPadnos_> exit and quit should just set done=1
[06:37:49] <jmkasunich> errorcount counts em, but in -k mode, it keeps going
[06:38:17] <SWPadnos_> yep - the done flag still needs to be set
[06:38:41] <SWPadnos_> also, the while loop for file mode should depend on done, so you get an automatic break if done=-1
[06:38:44] <SWPadnos_> also, the while loop for file mode should depend on done, so you get an automatic break if done=-1==1, that was
[06:38:52] <SWPadnos_> damn
[06:38:56] <SWPadnos_> if done == 1, I meant
[06:39:29] <jmkasunich> I hate long ugly conditionals in a while
[06:39:36] <jmkasunich> the fgets is bad enough
[06:39:42] <SWPadnos_> heh
[06:40:23] <SWPadnos_> c'mon - what's a pair of parens, an or, and a !done - it's not that bad ;)
[06:43:36] <jmkasunich> I need another test after the switch, cause if I get a bad state, it would still call parse_cmd
[06:44:06] <SWPadnos_> true - if (!done) parse_cmd();
[06:44:21] <jmkasunich> if ( done ) break;
[06:44:28] <SWPadnos_> or that
[06:44:31] <jmkasunich> right after the switch
[06:45:05] <jmkasunich> ok, have a test at the top of the loop, after the switch, and after the parse cmd
[06:45:57] <SWPadnos_> it seems that you should only need it just after the tokenizer loop / switch
[06:46:20] <SWPadnos_> the only thing you may get is an extra prompt printed
[06:47:20] <jmkasunich> if I get a tokenizer error, I probably want to break out of that loop too...
[06:47:28] <SWPadnos_> true
[06:47:38] <jmkasunich> hell, I'm making this too hard...
[06:47:57] <jmkasunich> the tokenizer error can directly call hal_exit, then return(1)
[06:49:02] <jmkasunich> there, tokenizer error never sets done, just shuts down right then and there
[06:49:30] <SWPadnos_> that's good, unless you ever change the exit procedure
[06:49:45] <SWPadnos_> there should be only one exit path, in the ideal case
[06:50:47] <jmkasunich> when I'm in a function and have an error, I like to do return(errorcode) right there
[06:50:57] <jmkasunich> main() is a function just like any other
[06:51:16] <SWPadnos_> that's good for a function that just returns a number, but for a program that does locking, it's not the best method
[06:51:47] <jmkasunich> dammit, where is a goto when you want one
[06:51:58] <jmkasunich> goto (end of function where exit code is)
[06:52:07] <SWPadnos_> just put in a label, and voils, goto
[06:52:10] <SWPadnos_> viola
[06:52:14] <jmkasunich> I want to be able to bust out of nested loops, switches, etc
[06:52:16] <SWPadnos_> voila
[06:52:23] <SWPadnos_> yep - that's what goto is for
[06:52:38] <SWPadnos_> people frown on it, but it's heavily used in the kernel
[06:53:18] <jmkasunich> label is just "name:", right?
[06:53:23] <SWPadnos_> yep
[06:53:24] <jmkasunich> you can tell I use it a lot....
[06:53:31] <SWPadnos_> main_done:
[06:53:44] <Jymmm> GOTO? in kernel code?
[06:53:55] <SWPadnos_> I don't think it works across functions though (which is good)
[06:54:00] <SWPadnos_> zillions of them
[06:54:07] <Jymmm> c/c++ ?
[06:54:16] <SWPadnos_> C only in kernel
[06:54:24] <SWPadnos_> they'll shoot you if you mention C++
[06:54:35] <Jymmm> oh wtf, I've seen everything now.... the shame of it all.
[06:54:37] <SWPadnos_> and assembly, of course
[06:54:51] <Jymmm> GOTO, not JMP... right?
[06:55:13] <SWPadnos_> they use it to unroll parts of a driver init, for example, when some error is encountered
[06:55:24] <Jymmm> that's just so wrong
[06:55:28] <SWPadnos_> else they'd have memory leaks all over the place
[06:55:50] <SWPadnos_> no - it's the correct use of the concept - not everything can be broken down into nice little functions
[06:56:03] <SWPadnos_> that you can correctly recover from etc, etc
[06:56:06] <Jymmm> the hell it can't. lazy bastards!
[06:56:12] <SWPadnos_> bullshit
[06:56:22] <jmkasunich> Jymmm: you know not of what you speak
[06:56:34] <SWPadnos_> it would be possible, but at such a cost in performance, it's not even funny
[06:56:54] <Jymmm> "not everything can be broken down into nice little functions" Yeah? and why not?
[06:57:13] <jmkasunich> there is a place for C++, and for instance on "no gotos", but the kernel isn't it
[06:57:26] <SWPadnos_> ok - I misspoke - it's not always the best choice to bereak everything down into little functions
[06:57:46] <SWPadnos_> and C++ has a goto, it's called try / catch
[06:58:22] <jmkasunich> yeah, except instead of executing 1 instruction, it executes ????
[06:58:59] <jmkasunich> if you can answer that within an order of magnitude, my hat's off to you...
[06:59:03] <Jymmm> jmkasunich: I'm not speaking of shitt switch/case statements at all, more "ternary like" than GOTO's
[06:59:04] <SWPadnos_> oh - C++ isn't as inefficient as you think
[06:59:27] <Jymmm> * Jymmm prefers C, oop is icky =)
[06:59:44] <SWPadnos_> in fact, HAL would be much easier to implement (sans the kernel parts) in C++
[06:59:59] <SWPadnos_> all of the type stuff that you do manually now would be handled for you, and pretty well, too
[07:00:04] <jmkasunich> get back you fiend!
[07:00:15] <SWPadnos_> oops, I mean, C++ and oop are icky ;)
[07:00:20] <jmkasunich> heh
[07:00:25] <jmkasunich> I do oop in C
[07:00:30] <jmkasunich> sometimes
[07:00:30] <Jymmm> ?
[07:00:37] <Jymmm> yeah?
[07:00:40] <SWPadnos_> I know - that's why it's so hard to follow ;)
[07:00:47] <jmkasunich> what, my code?
[07:00:54] <SWPadnos_> I do oop in assembly
[07:01:15] <SWPadnos_> no, the code is pretty clean
[07:01:38] <jmkasunich> then what is hard to follow?
[07:01:55] <SWPadnos_> but there are a bunch of those "is this input or output", "do I use a double derefrence or a single", etc in there
[07:02:09] <jmkasunich> ah
[07:02:32] <SWPadnos_> also, the issue with bulk pin export would be easy in C++, but it's nearly impossible in C
[07:03:48] <Jymmm> jmkasunich probably writes c code like this 'Hello World' example --> http://remus.rutgers.edu/~rhoads/Obfuscated_C/hello_world.c
[07:03:58] <jmkasunich> no
[07:04:08] <SWPadnos_> heh - not quite
[07:04:13] <Jymmm> lol
[07:04:14] <SWPadnos_> that would be the xml version ;)
[07:04:42] <Jymmm> SWP_Away: If it was the XML version, I'd still take it easily over XML itself.
[07:04:50] <SWPadnos_> heh
[07:05:36] <Jymmm> There is only two instances that I would accept the usage of XML personally.
[07:05:44] <SWPadnos_> death and taxes?
[07:06:03] <Jymmm> lol, no
[07:07:16] <Jymmm> 1) A server communicating with a shipping carrier live. and 2) SVG (but because I have absolutely no choice )
[07:07:49] <SWPadnos_> OK - so a data transport and a no choice scenario.
[07:08:13] <Jymmm> SWP_Away (and that's what XML was originally for.... transport, not storage.)
[07:08:22] <SWPadnos_> yep -I know.
[07:08:30] <SWPadnos_> (we don't need to go into it again ;) )
[07:09:01] <fenn> * fenn hands jymmm a lollipop
[07:09:07] <jmkasunich> hmmm, even tho I'm returning failure, the loop keeps going
[07:09:20] <SWPadnos_> hmmm
[07:09:30] <jmkasunich> of course it does.... bash doesn't look at exit conditions in a loop...
[07:09:49] <jmkasunich> only the while condition
[07:09:51] <SWPadnos_> then why does a sleep loop break?
[07:10:04] <Jymmm> fenn: Hey... this thing isn't tequilia flavored!
[07:10:07] <jmkasunich> it somehow knows the sleep ended with a sigint
[07:10:22] <SWPadnos_> ok -I guess we all don't know how then ;)
[07:10:43] <jmkasunich> heh.... I could use the done flag to generate a sigint outside the critical region
[07:11:03] <jmkasunich> with the flag clear, the handler would exit
[07:11:04] <SWPadnos_> kill -9 me :)
[07:11:50] <SWPadnos_> you may be up for a while -you should also go through the loadusr / loadrt / unloadrt fork stuff for this kind of thing ...
[07:12:13] <jmkasunich> not tonight
[07:12:25] <SWPadnos_> heh
[07:12:43] <Jymmm> Have you guys seen this? http://www.tern.com/g_motionc21.htm
[07:12:45] <jmkasunich> I do disconnect from HAL before the fork, and reconnect after
[07:13:51] <SWPadnos_> no hal_flags around those hal_init calls though
[07:14:06] <Jymmm> 4axis controlelr
[07:14:07] <jmkasunich> don't need them, they're "inside" parse_cmd
[07:14:08] <SWPadnos_> Jymmm: I may have seen that at the Tern booth at ESC
[07:14:17] <SWPadnos_> ah - right
[07:14:38] <Jymmm> SWPadnos_: looks promising (if I'm reading correctly)
[07:15:44] <SWPadnos_> fairly expensive, but in the same class as MotenC and STG, I guess
[07:16:22] <Jymmm> 4 axis mot ctrl with 80+ I?O, 32 optos and 8 SSR
[07:16:51] <SWPadnos_> and not a standard but, and communications over RS232, unles syou buy their 586 board to go along with it
[07:16:56] <SWPadnos_> s/but/bus/
[07:17:24] <Jymmm> ah, bummer.
[07:18:13] <SWPadnos_> unfortunately, a lot of these things aren't really that useful to emc - all you really need is some hardware that acts like an analog servo
[07:18:26] <SWPadnos_> be it a PWM, pulse generator, or a DAC
[07:18:55] <Jymmm> 3MHz pulse and direction signals for driving steppers
[07:19:11] <SWPadnos_> useless without drives that can go that fast ...
[07:19:37] <Jymmm> what geckos can't?
[07:19:45] <SWPadnos_> 250 KHz max internal rate
[07:19:52] <SWPadnos_> after the pulse multiplier, if there is one
[07:20:00] <Jymmm> hell, that' sbetter than 7khz, that's for sure.
[07:20:23] <SWPadnos_> for servos, you'd probably have to spend $1000 for an encoder that can go above 300 KHz
[07:20:30] <SWPadnos_> if you can find one
[07:22:39] <Jymmm> heh, they probably swapped I/O to make the bus special
[07:23:32] <SWPadnos_> possibly - it looks pretty PC/104-ish, but they don't mention it
[07:24:06] <Jymmm> and amd cpu, so it can't be THAT special (like Transmeta)
[07:24:29] <SWPadnos_> right - and the 5x86 have terrible interrupt controllers, unless they've fixed them lately
[07:25:16] <SWPadnos_> yep - it's the Elan SC520 - the exact chip I tried
[07:26:42] <Jymmm> "Those Bastards! The killed Kenny!"
[07:26:47] <Jymmm> y
[07:27:00] <CIA-12> 03jmkasunich * 10emc2/src/hal/utils/halcmd.c: improved halcmd handling of ctrl-C (prevent shutdown while it holds the HAL mutex)
[07:27:22] <jmkasunich> and on that note, I'm going to sleep
[07:27:26] <SWPadnos_> night
[07:27:36] <SWPadnos_> sounds like a good plan, actually
[07:27:41] <SWPadnos_> see you guys later
[07:27:47] <Jymmm> g'night folks!
[07:27:53] <jmkasunich> jmkasunich is now known as jmk_sleep
[10:44:52] <anonimasu> morning
[11:49:43] <vq> vq is now known as ValarQ
[12:04:59] <rayh> ValarQ: What's happening with the halgui?
[12:07:40] <ValarQ> rayh: not much lately
[12:08:50] <rayh> What do you think now of making it the way you planned.
[12:12:22] <ValarQ> i think i will keep the one component is one block style
[12:13:00] <ValarQ> but i might choose to hide all out-pins and instead only show the signal
[12:13:45] <ValarQ> that will require a separate dialog for adding signals, but i believe that is simpler
[12:15:06] <rayh> Showing that much stuff is difficult.
[12:15:25] <rayh> I have been playing with a show and configure thing in Tcl/Tk.
[12:15:39] <rayh> Don't know any python so can't help much.
[12:16:28] <rayh> robin_sz: Hi.
[12:16:59] <ValarQ> rayh: http://python.org/doc/2.4.2/tut/tut.html
[12:17:01] <ValarQ> rayh: ;)
[12:17:15] <robin_sz> hi
[12:17:30] <rayh> Yea right. At my age that's like looking at classical greek
[12:17:48] <ValarQ> heh
[12:18:00] <robin_sz> I never liked python ... all that syntax reliant on formatting
[12:18:13] <rayh> You working still with the Swiss, robin?
[12:18:19] <robin_sz> on and off
[12:18:20] <anonimasu> morning
[12:18:21] <anonimasu> :)
[12:18:26] <ValarQ> anonimasu: g'day :)
[12:19:17] <rayh> * rayh gets goes for a pot of coffee. brb
[12:19:31] <anonimasu> hello
[12:19:32] <anonimasu> what's up?
[12:19:38] <anonimasu> * anonimasu is working on a webpage right now
[12:19:48] <anonimasu> gotten any progress on the TP?
[12:20:16] <robin_sz> * robin_sz slaps anonimasu
[12:20:49] <robin_sz> gotten? GOTTEN? ... you are turning american ;)
[12:21:47] <anonimasu> I AM SO SORRY!
[12:22:08] <anonimasu> Have you got any progress done on the TP?
[12:22:14] <anonimasu> ^_^
[12:22:26] <robin_sz> * robin_sz pats anonimasu on the head :)
[12:23:02] <robin_sz> I forget, is TP the task or trajectory planner this week?
[12:25:00] <robin_sz> I thought the trajectory planner was pretty much fixed and les_w was about to install his 10hp spindle to take advantage of the new found performance??
[12:25:07] <robin_sz> or did more bugs surface?
[12:45:34] <rayh> There is still some heavy discussion of path definition and passing.
[12:59:34] <les_w> hi ray and robin. A math error was found that improved the path a lot
[12:59:41] <les_w> But there are still issues
[13:00:00] <les_w> but the issues are not from bugs
[13:00:49] <les_w> One was servo rate...but we have a demonstration of 125 microseconds for 3 axes with the vital card
[13:01:08] <les_w> that is plenty fast...so no problem
[13:01:38] <les_w> The other issues is tp/tc inability to velocity adapt
[13:01:49] <les_w> it was not designed to
[13:02:22] <les_w> so we have to be careful not to give emc unrealizable motion commands
[13:02:46] <les_w> most controls slow down until unrealizable commands are realizable
[13:02:54] <rayh> les_w: I don't quite understand the velocity adapt issue. could you elaborate how scale is unable to handle this?
[13:02:56] <les_w> tp/tc cannot do this
[13:03:20] <les_w> hi ray. We it was from my talk with fred.
[13:04:00] <les_w> He just said that tp/tc was not designed to handle no cruise phase segments
[13:04:30] <les_w> so if commands are attempted, the queue will drain.
[13:04:59] <les_w> machine then waits until it fills again
[13:05:03] <les_w> and resumes
[13:05:36] <les_w> Now, it's not a problem as long as unrealizable motions are filtered out
[13:05:43] <robin_sz> oh
[13:05:55] <robin_sz> thats not good
[13:06:21] <robin_sz> I can think of many 3d surfaces where you might not have a cruise pahse
[13:06:44] <les_w> Well, Fred says it is a simplistic planner and should be dumped
[13:06:53] <les_w> fine if he will write another!
[13:07:57] <robin_sz> its not that the motions are unrealizeable
[13:08:16] <robin_sz> they are ... its just the way we handle them i guess
[13:08:33] <robin_sz> this must have been solved in many ways before now
[13:08:37] <les_w> I asked about modifying the code but he said that would be impossible as he coded it
[13:08:48] <les_w> Sure it was
[13:09:30] <anonimasu> hehe
[13:09:59] <les_w> And the segmentqueue flopped because it was a bit too ambitious and complicated
[13:10:11] <robin_sz> mmm ...
[13:10:11] <les_w> and Fred did not understand the code
[13:10:19] <anonimasu> didnt he write it?
[13:10:35] <robin_sz> the ideas behind segmement queue seemed right, from what i could understand
[13:10:47] <rayh> I guess that I wasn't thinking of velocity adapt as something we would want to do with feedrate override or current from a edm or such rather than something that happens with we try to command emc to do something out of it's abilities.
[13:10:52] <robin_sz> it was the crazy code world it tied to live in that killed it
[13:11:07] <les_w> What fred asked for are some good papers on the subject. If he understands the algo, he says he can code up a new planner.
[13:11:25] <robin_sz> interesting
[13:11:56] <les_w> Well realistically it appears that the only person in the world that can understand Fred's code is Fred.
[13:12:40] <rayh> I thought that was true of C from most folk anyway.
[13:12:48] <les_w> heh
[13:13:17] <robin_sz> well, thats why we have a coding standard I guess .. to help smooth the edges
[13:13:52] <les_w> Well some of my code is hard to follow too I guess
[13:14:16] <les_w> but emc has so many glovbal variables and functions
[13:14:27] <robin_sz> well, yeah
[13:14:28] <les_w> called from who knows where
[13:14:33] <robin_sz> * robin_sz nods
[13:14:47] <robin_sz> globals are one of the worst afflictions in emc
[13:15:01] <robin_sz> sigh
[13:15:39] <les_w> Just having dinner and some beers with Fred makes one understand.
[13:16:00] <robin_sz> it does?
[13:16:26] <les_w> He is so damn smart he writes stuff that way just as mental exercise
[13:16:32] <les_w> you know?
[13:16:45] <robin_sz> mmmm ...
[13:17:26] <les_w> He can keep impossibly complex interwoven structures in his head
[13:17:27] <robin_sz> writing it the hard way is not the best way. makes it harder for you, harder for those that come along behind
[13:17:34] <rayh> I don't quite agree with the no globals thing.
[13:17:53] <robin_sz> well, not no globals
[13:17:57] <robin_sz> just one or two
[13:18:11] <les_w> globals have their place sure
[13:18:24] <robin_sz> more than say, 5 in a 5000 line program is a sign of the wrong sort of approach
[13:18:36] <robin_sz> like $debugMode = 1;
[13:18:42] <anonimasu> hm not nescessarily..
[13:18:51] <rayh> They'd never have gotten the mars rovers out of the priority inversion if the globals hadn't been available.
[13:19:06] <les_w> hmm
[13:20:00] <robin_sz> * robin_sz isnt sure
[13:20:23] <anonimasu> heh
[13:21:13] <robin_sz> one or two globals isnt a sin, using them by default for all variables is
[13:21:52] <les_w> looking at some cutting data dave e. emailed
[13:22:30] <robin_sz> tight scoping of variables and providing accessor methods that "do the right thing" makes more sense .. but we've done this argument a million times already
[13:24:13] <rayh> I don't see a real problem with variables bounded if we have adequate access to them as needed.
[13:24:14] <les_w> yeah
[13:24:31] <les_w> Dave's data is not making sense to me
[13:24:46] <robin_sz> hey les_w, does your machine run at the moment?
[13:24:59] <les_w> what units are the time axis scale in gnuplot?
[13:28:01] <robin_sz> years?
[13:30:31] <les_w> haha
[13:31:10] <les_w> some problem with Dave's setup....things get nasty above about 32 ipm
[13:31:38] <les_w> let me check his traj time
[13:31:39] <robin_sz> is he running EMC?
[13:31:39] <rayh> I thought he said that he was running about 150 ipm
[13:31:56] <rayh> for at least some of the tests.
[13:32:10] <les_w> yeah he ran at 128
[13:32:21] <robin_sz> I'd like to move my 3 axis router off the old DOS software onto something else,
[13:32:31] <robin_sz> to get better motion smoothing
[13:32:40] <robin_sz> on complex 3D surfaces
[13:33:05] <les_w> ok the pictures without an s are quarter degree so 230 points per inch
[13:33:23] <robin_sz> bet we run 200 to 300 ipm ...
[13:33:33] <les_w> and his traj time is 100 per second
[13:34:04] <robin_sz> so it chokes?
[13:34:06] <les_w> ok so max he could go is 30 ips or so
[13:34:16] <les_w> before it chokes yeah
[13:34:36] <les_w> ok he just has to long a trajectory period.
[13:35:31] <les_w> Now if that were a motenc card running at 125 microsecond as we have seen, traj could be 500 microseconds (also as demonstrated)
[13:35:50] <robin_sz> so .. what happens if a path running on that machine has a lot of say, 20 points per inch moves .. and a few 1000 point per inch sections?
[13:36:08] <les_w> so 2000 block reads per second and performance would be much better
[13:36:48] <les_w> It's all servo rate...which determines traj rate since there is no velocity adapt
[13:37:22] <les_w> I think very high servo rates would give good performance even with the existing tp
[13:37:42] <robin_sz> again, what would happen if in that block were a few (say less than 10) very fine moves clsoe together .. ??
[13:37:56] <les_w> points must never come along faster than the traj rate
[13:38:14] <les_w> it would stutter violently
[13:38:24] <robin_sz> well, thats of no use as far as I can see
[13:38:56] <les_w> it's not good....but the higher the rates, the less chance of that happening
[13:39:22] <robin_sz> for 3D work, you often get small sections with lots of small moves, usually due to errors in the scan etc
[13:39:30] <les_w> right
[13:39:37] <robin_sz> you dont really care if the motion just smooths over them
[13:39:47] <robin_sz> not following them exactly ...
[13:40:12] <les_w> other option I mentioned to Fred was to just put a snippet in to throw out points if too close
[13:40:21] <robin_sz> ideal
[13:40:42] <les_w> He didn't like the idea so much...was more of a " throw the whole thing out" ilk
[13:41:15] <les_w> but still, that might be very easy
[13:41:27] <robin_sz> for 3D contouring work, stuttering is not an option
[13:41:31] <les_w> and yes, cam programs do dumb stuff like that
[13:41:35] <les_w> all the time
[13:41:40] <robin_sz> * robin_sz nods
[13:42:19] <robin_sz> ah well
[13:42:26] <robin_sz> how much is the motenc card now?
[13:42:52] <les_w> 550 for the light ang 800 or something for the 8 axis
[13:43:03] <robin_sz> coo. still expensive
[13:43:08] <les_w> yeah
[13:43:31] <les_w> but if it really can do 125 microseconds...that is right up there with modern controls
[13:43:48] <robin_sz> well, that part is yeah
[13:44:34] <robin_sz> can emc cope with running a 125 us servo loop and similarly quick traj loops ?
[13:44:49] <robin_sz> traj planning I meant
[13:45:54] <les_w> traj plan is RT and is an integer multiple of servo time. It can be 1:! or higher. the more the ratio, the more cubic subinterpolation you get.
[13:46:22] <les_w> needs to be 4:1 or so to get decent smoothing
[13:46:43] <les_w> so that would give 2000 blocks per second
[13:47:02] <les_w> which I would also consider modern performance levels
[13:48:31] <rayh> m5i20 is about $200 also pci also fpga but field progrmmable
[13:48:45] <les_w> I cannot do that with the isa STG though. Only with the motenc, and I suspect only with an old p3 or K6.
[13:49:19] <les_w> We have already seen some evidence of older proCessors running faster
[13:49:26] <alex_joni> morning
[13:49:29] <les_w> but Not much testing on that
[13:49:33] <les_w> morning
[13:49:44] <alex_joni> what's up les?
[13:49:56] <les_w> motenc on 2.8 P4? who knows
[13:50:22] <les_w> not much alex. Just a cold windy morning.
[13:50:44] <alex_joni> I'd chose a dual xeon, if I had the money ;)
[13:50:45] <les_w> And no dry firewood.
[13:51:17] <les_w> I do wish someone could throw a motenc in a new box
[13:51:28] <les_w> perhaps Abdul has
[13:51:48] <les_w> With that 20 kHz servo rate ad copy on his site
[13:51:58] <les_w> ought to call him.
[13:52:57] <les_w> oh ther m5i20 looks neat too
[13:53:07] <les_w> especially the price!
[13:54:25] <rayh> What did you want to do with a motenc and a new box?
[13:55:11] <les_w> check max servo rate
[13:55:22] <les_w> might actually be slower than an old box
[13:56:01] <rayh> We were running a lite on the Mazak, 800 via.
[13:56:07] <les_w> night not...would like to know
[13:56:41] <les_w> 800 mhz via chipset?
[13:56:50] <rayh> Would you need motors and encoders attached to do that test
[13:57:04] <rayh> 800 via processor.
[13:57:25] <les_w> I think so
[13:57:42] <les_w> might fool it with zero moves
[13:57:51] <les_w> zero length moves
[13:57:56] <rayh> but you want an intel proc and I run amd.
[13:58:13] <les_w> I run amd too
[13:58:32] <les_w> eiher one really
[13:59:17] <rayh> Well right now the amd64 has a m5i20 in it but I could switch.
[14:00:00] <les_w> I don't know if modern chip achitectures slow down hard RT threads or not
[14:00:11] <les_w> would be great if you could ray
[14:00:36] <les_w> btw m5i20 running emc?
[14:00:57] <alex_joni> m5i20 is supported by emc2
[14:01:26] <les_w> would like to know max rates on that too
[14:01:28] <lerman> Hey guys -- I have a problem. My mail to the developers list is being rejected with:
[14:01:30] <lerman> <[email protected]>:
[14:01:31] <lerman> 66.35.250.206 does not like recipient.
[14:01:33] <lerman> Remote host said: 550-Verification failed for <[email protected]>
[14:01:34] <lerman> 550-Called: 65.75.16.216
[14:01:37] <lerman> 550-Sent: RCPT TO:<[email protected]>
[14:01:38] <lerman> 550-Response: 550 5.7.1 <[email protected]>... Relaying denied
[14:01:40] <lerman> 550 Sender verify failed
[14:01:41] <lerman> Giving up on 66.35.250.206.
[14:01:43] <lerman> Any ideas. As far as I can tell, nothing has changed on my end.
[14:02:21] <lerman> I tried resubscribing to the list, but got the message I was already subscribed.
[14:02:36] <les_w> no clue Ken
[14:02:47] <les_w> should one of us try a test post?
[14:03:11] <lerman> That would tell us something.
[14:03:19] <les_w> ok
[14:04:13] <les_w> done
[14:04:46] <les_w> takes a little while.
[14:05:32] <les_w> post worked ken
[14:05:54] <les_w> unfortunately for you
[14:06:05] <lerman> I haven't seen it. The last message I saw on the list was from les "Re: might I humbly suggest..."
[14:06:24] <les_w> poped right up for me.
[14:06:24] <alex_joni> it came through over here
[14:06:24] <alex_joni> but it takes a while
[14:06:50] <alex_joni> lerman: what's your current ip?
[14:06:52] <lerman> Les: would you send me a message to: Kenneth.Lerman AT se-ltd.com
[14:06:59] <alex_joni> different than se-ltd.com?
[14:07:01] <les_w> ok
[14:07:31] <alex_joni> lerman: can you try something?
[14:07:46] <lerman> Sure... -- it depends.
[14:07:46] <alex_joni> this is what I would do:
[14:08:13] <alex_joni> 1. open 'telnet lists.sourceforge.net 25'
[14:08:30] <alex_joni> 2. enter the EXACT data I tell you, you won't be able to fix it ;)
[14:08:47] <alex_joni> mail-from:<[email protected]>
[14:09:00] <alex_joni> rcpt-to:<[email protected]>
[14:09:20] <alex_joni> by now you should have some info if it's ok or not..
[14:09:36] <lerman> NG already. Got 500 unrecognized command to the mail-from:...
[14:09:54] <alex_joni> oops.. been a while
[14:09:57] <alex_joni> start with:
[14:10:02] <les_w> sent ken
[14:10:07] <alex_joni> helo mail.sourceforge.net
[14:10:53] <lerman> The helo returned:
[14:10:54] <lerman> 250 mail.sourceforge.net Hello 24-151-6-168.static.nwtn.ct.charter.com [24.151.6.168]
[14:11:05] <lerman> which seems correct.
[14:11:08] <alex_joni> right
[14:11:10] <alex_joni> now:
[14:11:21] <alex_joni> mail from:<[email protected]>
[14:11:28] <alex_joni> without the -
[14:12:57] <lerman> I cut and pasted and it seems to hang.
[14:12:59] <lerman> mail from:<[email protected]>
[14:13:01] <lerman> above is what I pasted -- it's still hung
[14:13:14] <alex_joni> strange..
[14:15:32] <lerman> still hung... and no mail from les, yet.
[14:16:13] <lerman> Hmmm. Just sent email to a friend and got the same rejection message. My mail system seems hosed.
[14:16:14] <alex_joni> sent you one myself now
[14:16:53] <alex_joni> it came back.. seems your provider has something misconfigured
[14:16:54] <alex_joni> [email protected]
[14:16:54] <alex_joni> SMTP error from remote mail server after RCPT TO:<[email protected]>:
[14:16:54] <alex_joni> host gaboon.gaboon.com [65.75.16.216]: 550 5.7.1 <[email protected]>... Relaying denied
[14:18:26] <lerman> Gaboon is a secondary that should not really been in use. I'm not surprised that it is configured wrong. Seems my primary is hosed.
[14:19:26] <lerman> I'm off for now. I'll get back to you when things are fixed. Thanks -- Ken
[14:19:41] <alex_joni> np
[14:21:43] <rayh> rayh is now known as rayh_away
[14:31:33] <les_w> hey I have one question....
[14:32:28] <alex_joni> shoot les
[14:32:52] <les_w> axis CYCLE_TIME. do the times add for each axis or are they all run at the slowest time?
[14:33:13] <alex_joni> I think slowest
[14:33:24] <alex_joni> yet another of those stupid configs ,)
[14:33:24] <les_w> I think so to
[14:33:48] <les_w> the Rt thread does all axes each period I think
[14:33:53] <alex_joni> yup
[14:34:02] <les_w> which is what I want to hear...
[14:34:47] <les_w> so....125 microseconds for 3 axes....is damn good actually.
[14:35:16] <les_w> Beats Galil's new accelera series
[14:35:20] <les_w> good.
[14:35:36] <alex_joni> I think it can go faster
[14:35:51] <les_w> possibly...unknown
[14:36:18] <alex_joni> probably possibly
[14:36:32] <les_w> Some are reluctant to test the limit perhaps...lockups might trash the file system
[14:36:54] <les_w> But first the gui goes
[14:37:24] <les_w> if careful one can stop there and exit the program ok
[14:37:47] <alex_joni> yeah.. I usually go till the gui is sluggish
[14:37:51] <alex_joni> then a bit back
[14:37:56] <alex_joni> so I can still use it ok
[14:37:59] <les_w> yeah exactly
[14:38:40] <les_w> thanks. Well breakfast for me. biab.
[14:38:42] <alex_joni> ok.. doing some coding now
[14:41:25] <CIA-12> 03alex_joni * 10emc2/scripts/ (emc.in install.run.in): renamed install.run.in to emc.in
[14:44:51] <lerman> Well, I'm now getting mail, the test alex_joni suggested gives (what should I enter next):
[14:44:53] <lerman> [haito](lerman)$ telnet lists.sourceforge.net 25
[14:44:54] <lerman> Trying 66.35.250.206...
[14:44:56] <lerman> Connected to lists.sourceforge.net (66.35.250.206).
[14:44:58] <lerman> Escape character is '^]'.
[14:44:59] <lerman> 220 mail.sourceforge.net ESMTP Exim 4.44 Sun, 11 Dec 2005 06:43:36 -0800 sc8-sf-mx2.sourceforge.net
[14:45:01] <lerman> helo mail.sourceforge.net
[14:45:02] <lerman> 250 mail.sourceforge.net Hello 24-151-6-168.static.nwtn.ct.charter.com [24.151.6.168]
[14:45:04] <lerman> mail from:<[email protected]>
[14:45:06] <lerman> 250 OK
[14:45:24] <alex_joni> that's good
[14:46:11] <lerman> What should I enter next to continue the test?
[14:46:43] <alex_joni> rcpt to:<[email protected]>
[14:47:18] <alex_joni> data: sorry about this, I got to test the email
[14:47:21] <alex_joni> .
[14:47:24] <alex_joni> that will send an email to the list if all is ok ;)
[14:47:29] <CIA-12> 03alex_joni * 10emc2/src/ (Makefile configure configure.in): modified to use the new emc runscript, previously install.run
[14:47:59] <lerman> 250 Accepted
[14:48:36] <alex_joni> ok.. seems like it went through
[14:49:49] <lerman> Well, I did:
[14:49:51] <lerman> the data line and the line with just the dot and it is just hanging.
[14:50:10] <alex_joni> it'll run through mailman, and might take a while..
[14:50:32] <alex_joni> you sure the telnet isn't closed already?
[14:51:19] <lerman> Doesn't seem to be closed -- no new prompt.
[14:51:29] <alex_joni> ok
[14:57:13] <okalleo> okalleo is now known as chinamill
[14:59:23] <lerman> Tried this again with the word data on a line by itself -- no colon. Seems to have accepted the message:
[14:59:24] <lerman> rcpt to:<[email protected]>
[14:59:26] <lerman> 250 Accepted
[14:59:27] <lerman> data
[14:59:29] <lerman> 354 Enter message, ending with "." on a line by itself
[14:59:31] <lerman> Sorry about this -- gotta test the email.
[14:59:33] <lerman> .
[14:59:34] <lerman> 250 OK id=1ElSdm-0002Ns-Qa
[14:59:36] <lerman> quit
[14:59:37] <lerman> 221 mail.sourceforge.net closing connection
[14:59:39] <lerman> Connection closed by foreign host.
[15:00:27] <lerman> Well, the message got somewhere: -- I just received mail that it was being held for moderation.
[15:01:13] <alex_joni> want me to delete it?
[15:01:24] <alex_joni> or let it through?
[15:03:17] <lerman> Try letting it through. I'm still failing -- tried sending another and got:
[15:03:18] <alex_joni> We're Sorry.
[15:03:18] <alex_joni> The SourceForge.net Website is currently down for maintenance.
[15:03:18] <alex_joni> We will be back shortly
[15:03:18] <lerman> This is a permanent error; I've given up. Sorry it didn't work out.
[15:03:20] <lerman> <[email protected]>:
[15:03:22] <lerman> 66.35.250.206 does not like recipient.
[15:03:24] <lerman> Remote host said: 550-Verification failed for <[email protected]>
[15:03:25] <lerman> 550-Previous (cached) callout verification failure
[15:03:27] <lerman> 550 Sender verify failed
[15:03:29] <lerman> Giving up on 66.35.250.206.
[15:03:30] <lerman> Not clear what that means -- and the fact that it is cached seems to imply that even if it is fixed, I'll have a problem until the cache is flushed or times out or whatever.
[15:03:40] <alex_joni> yeah.. sounds like that..
[15:05:18] <alex_joni> seems the sourceforge site is going through some maintenance
[15:05:24] <alex_joni> I suggest trying again lateron
[15:05:31] <alex_joni> I rejected your test email
[15:05:39] <alex_joni> by getting there it proved that it worked
[15:05:46] <alex_joni> no need to clutter up the list with it ;)
[15:05:50] <alex_joni> hope you don't mind..
[15:06:23] <lerman> Don't mind at all -- I hate clutter as much as the next guy. I'll try again later.
[15:06:45] <lerman> I rebooted my firewall and at least I'm getting email again.
[15:06:54] <alex_joni> ok.. gotta leave for a while
[15:06:59] <alex_joni> hope it works out for you
[15:06:59] <lerman> But I hate not being able to answwer it.
[15:07:12] <lerman> thanks for your help.
[15:07:15] <alex_joni> np
[15:07:21] <alex_joni> that's what we are for :P
[15:07:41] <alex_joni> later
[16:04:14] <rayh_away> Hi dave-e les had some questions about the scale on your stuff.
[16:04:25] <rayh_away> gotta run guys.
[16:10:03] <dave-e> ray..scale is what ever logging gives me.
[16:10:09] <dave-e> the volts are real
[16:10:31] <dave-e> who knows what the position axis is
[16:12:04] <les_w> hi dave
[16:12:33] <les_w> I guess you saw my email...numbers seem to work out
[16:12:57] <Jacky^> morning :)
[16:13:03] <les_w> morning jacky
[16:13:13] <Jacky^> storm and black out all day here :/
[16:13:19] <les_w> really
[16:13:29] <Jacky^> bad wheater
[16:13:42] <les_w> We often have blackouts here
[16:13:56] <les_w> but I have an emergency generator
[16:14:05] <les_w> just got it
[16:14:22] <dave-e> les..it would be nice to get better performance but mostly from a theoretical standpoint.
[16:14:39] <dave-e> I'd really like to know where the bottleneck is.
[16:14:47] <les_w> more practicality for routers though
[16:15:02] <dave-e> indeed
[16:15:07] <les_w> so you had the same with faster traj times?
[16:15:21] <dave-e> or plasma or anything that really needs the speed
[16:15:27] <les_w> yeah
[16:16:13] <dave-e> I stepped 0.001, 0.0005, 0.00025 and tried 0.000125 where the machine froze
[16:16:53] <les_w> Since Fred told me that emc cannot velocity adapt, the key to good performance is just plain old fast servo rates...because servo rates control the minimum traj rate
[16:16:57] <dave-e> not certain where my traj was...may have been at 1;1 not 10:1
[16:17:52] <les_w> well it's a fixed number...if you didn't change it the max blocks per second won't change with just a servo rate change
[16:17:53] <dave-e> so I should have tried 0.00025 and 0.0025 [traj]
[16:17:56] <lerman> Hey-- my email to the lists is working again. Thanks for the help alex_joni.
[16:18:26] <les_w> great ken.
[16:18:52] <lerman> So, now les_w can see my response to his posting. :-)
[16:18:56] <dave-e> I'm still slowly working on gettng a motenc up on a smaller machine
[16:19:07] <les_w> STG seems incapable of fast rates, but it's good to know the motenc can go very fast
[16:19:09] <dave-e> but it is going slowly
[16:19:25] <dave-e> indeed it will go fast...
[16:19:35] <dave-e> what is the clock on your cpu?
[16:19:45] <les_w> reading ken's response...got it
[16:20:19] <dave-e> I'm 550 or 600 on a P3
[16:21:08] <les_w> ok
[16:21:23] <les_w> ought to do 200 microseconds or so
[16:21:53] <dave-e> maybe I can give it a shot later in the day.
[16:22:12] <les_w> ken, read your post. Yeah my decription was a little concise.;)
[16:22:30] <dave-e> gotta bring in the bobcat and clean out this place before Xmas...family coming
[16:22:32] <les_w> I just felt we need to have some common definitions though
[16:23:31] <dave-e> gotta run
[16:23:34] <les_w> and yes tp specifies position and all of it's derivatives
[16:23:42] <les_w> later dave
[16:23:54] <lerman> Yes, we need the definitions -- but I'd rather see them up on the wiki. It's fine to hash them out by email (or here), but my view is that if it doesn't make it to the wiki, it will be lost (or just hard to find in the list archive).
[16:24:06] <les_w> I just basically used the definitions as they are used in my old college text
[16:24:25] <les_w> agreed on the wiki
[16:25:15] <lerman> What did you study in college that you came across TP. (That was toilet paper in my days.)
[16:25:37] <les_w> I personally split my thinking into "what can we do now" vs What can be done with time"
[16:25:41] <les_w> robotics
[16:25:59] <les_w> i'm an aero...we do robotics.
[16:26:15] <les_w> like autopilots!
[16:26:30] <lerman> Hell, when I was in college, aero had been invented -- but I'm not sure about robots.
[16:26:42] <Jacky^_> lerman: wow :d
[16:26:59] <les_w> haha
[16:27:33] <les_w> I was at florida...close to the cape. Had some nasa funding
[16:27:58] <les_w> lots of german rocket scientists to teach me my math too.
[16:28:00] <les_w> heh
[16:28:11] <les_w> all very old
[16:28:23] <Jacky^_> there was an interesting progect about autopilot on sourcegorge
[16:28:29] <Jacky^_> http://autopilot.sourceforge.net/
[16:28:32] <lerman> Do you still know how to goose step?
[16:28:38] <les_w> really?
[16:28:42] <Jacky^_> but it seem not available for me..
[16:28:45] <les_w> haha
[16:28:55] <Jacky^_> I get Warning: mysql_connect(): Can't connect to MySQL server on 'mysql.sourceforge.net' (111) in bla bla bla..
[16:29:01] <les_w> oh sf is down right now
[16:29:13] <Jacky^_> i tried week ago too
[16:29:17] <Jacky^_> same issue
[16:29:21] <les_w> hmm
[16:29:44] <Jacky^_> also with different browser :(
[16:30:40] <Jacky^_> it may is available here: http://freshmeat.net/projects/uav/
[16:30:40] <les_w> the autopilots on the small planes I fly are crude devices
[16:31:01] <les_w> just some limit switches on attitude gyros
[16:31:22] <lerman> Back to Macfarlane -- I'm convinced that we could use the paper as the basis for an improved TP with little risk and large payoff. I'd shoot for a trivkins implementation as a first cut.
[16:31:39] <Jacky^_> yeah the tarball seem available
[16:32:57] <les_w> lerman yes. it seems to be one of the best performance/complexity tradeoffs
[16:33:26] <les_w> segmentqueue was just too complex....with diminishing returns for all that complexity
[16:33:33] <Jacky^_> Jacky^_ is now known as Jacky^
[16:33:55] <lerman> I'm not familiar with segmentqueue -- neither the history nor the functionality
[16:34:41] <les_w> complicated....7 years off an on work.....totally disfunctional.
[16:35:34] <les_w> Now the main issue I see as an observer...not a programmer....is that
[16:36:00] <les_w> Only Fred proctor can change Fred proctor's motion code
[16:36:10] <les_w> I would like that to not be so...
[16:36:44] <SWPadnos_> that's partly a Fred Proctor thing
[16:36:49] <les_w> sure
[16:37:18] <SWPadnos_> the code looks like a bunch of math and conditionals, with little to no descrition of the reasoning behind them
[16:37:29] <les_w> yup
[16:37:30] <SWPadnos_> description
[16:38:00] <SWPadnos_> (not that I'm incluied to delve too deeply into the derivations etc :) )
[16:38:04] <SWPadnos_> inclined
[16:38:18] <les_w> If one wanted to sugically remove the tp to replace it....I can't really see where it is and isn't
[16:38:20] <SWPadnos_> (nor am I inclined to type correctly before I've had my first pot of coffee)
[16:38:25] <les_w> seems spread all over
[16:38:54] <SWPadnos_> I think it's pretty much limited to tp.* and tc.*, but I'm not sure
[16:39:09] <SWPadnos_> of course, that doesn't tell us the *interface* the replacement would have to match
[16:39:12] <les_w> and cubic.c
[16:39:30] <SWPadnos_> right - and cubic
[16:39:52] <lerman> I just googled sonja macfarlane and found her web page, email address, and anouther short paper:
[16:39:54] <lerman> http://www.mech.ubc.ca/~sonja/Macfarlane_ICRA.pdf
[16:39:56] <lerman> Haven't read it yet, but it might be a good introduction to the longer paper.
[16:39:57] <SWPadnos_> I guess most anything in the motion sucdir is fair game
[16:40:06] <SWPadnos_> subdir
[16:40:20] <les_w> ideally it would be a box with inputs from cannonicals...and ouputs to the pid controller.
[16:40:24] <Jacky^> http://www.boltontech.org.uk/loonycycle.htm
[16:40:32] <Jacky^> hehe :P
[16:40:47] <SWPadnos_> les_w: that would be ideal
[16:40:53] <lerman> Well, not quite... outputs to hal (which includes the pid controller).
[16:41:13] <les_w> yes hal
[16:41:49] <les_w> without hal the task would prob be insurmountable ...except for fred perhaps
[16:42:21] <lerman> Sounds like insurmountable -- even for Fred.
[16:42:49] <les_w> might be. That is really old code. He has forgotten a bunch.
[16:43:42] <les_w> So practically speaking hal is probably the only hope
[16:44:05] <SWPadnos_> at least it places a clear boundary on one side of the TP
[16:44:11] <SWPadnos_> and a clear interface
[16:44:59] <les_w> The only thing I might consider for emc1 is a requested segment rate test
[16:45:24] <les_w> because cam systems are dumb and invariably put close together points
[16:45:38] <les_w> often un needed
[16:46:02] <les_w> you could test that right from the cannonicals
[16:46:12] <les_w> and chopem if needed
[16:47:04] <SWPadnos_> actually, there are a couple of numbers that can be calculated from the ini settings, and used in the CAM program (if they allow it)
[16:47:06] <lerman> Macfarlane provides point deletion if they are within the 'tightness' of other points.
[16:47:49] <lerman> Gotta go -- I'm a volunteer EMT and they need me.
[16:47:59] <SWPadnos_> nevermind - I need the coffee to sink in a little more
[16:48:02] <les_w> cam programs are dumb though. Even $15,000 ones. Their ouputs can be post filtered though.
[16:48:04] <SWPadnos_> good luck
[16:48:22] <anonimasu> hm, could you run a cam generated path through a filter to produce splines?
[16:48:56] <les_w> sure. A TP can be deterministic, so you can do it at anytime
[16:49:23] <les_w> I was surprised I did not get a comment or two about FF also being deterministic
[16:49:40] <les_w> hoping to get beat up a little on that one
[16:50:12] <les_w> haha
[16:51:22] <skunkworks> we have a piece of software at work that converts illistrator files to dxf. instead of the normal short line segments it fits arcs to follow the shape. you can tell it how far you want to deviate from the original file. I don't remember the name and I don't remember if other files can be input to it. I am sure it is only 2d.
[16:51:51] <skunkworks> it helped us on our laser for smoother cuts.
[16:53:19] <les_w> I have used such programs
[16:54:04] <les_w> Before our fix last summer it made a mess, because emc pretty much did exact stop only on arcs
[16:54:16] <les_w> now it would work better
[16:54:33] <skunkworks> interesting
[16:54:56] <les_w> however, arc fitting has infinite jerk...
[16:55:18] <les_w> but does lessen the number of points at least
[16:56:12] <skunkworks> right - don't understand "infinate jerk" though
[16:56:43] <les_w> oh ok. it's simply when acceleration is not continuous
[16:56:52] <skunkworks> ah
[16:57:46] <les_w> in a trapezoidal planner accel only comes in spurts. Off and on.
[16:58:11] <les_w> In a cubic it's a ramp, but the ramp has to have a corner somewhere.
[16:59:55] <les_w> Fifth is the lowest order where you can specify position, velocity, accel, and jerk at each point symetrically.
[17:00:08] <cradek> that's why macfarlane uses sines, so it's differentiable forever?
[17:00:17] <les_w> exactly
[17:01:43] <les_w> Of course the sine is a truncated Mclauren series in math libraries...but plenty of precision.
[17:02:37] <cradek> seems like you don't need all that many derivatives before it doesn't matter much anymore
[17:02:55] <les_w> right
[17:03:01] <les_w> need at least 4
[17:03:23] <cradek> after jerk, my conceptual grasp goes away fast
[17:03:45] <les_w> thump or something haha
[17:04:10] <SWPadnos_> Snap, someone said
[17:04:17] <cradek> twitch
[17:04:23] <les_w> oh snap ok
[17:04:37] <les_w> I can't really imagine that physically
[17:04:40] <les_w> trying...
[17:05:53] <les_w> let's see...jerk is how hard your haed gets banged in a car crash...snap is uh...the had banging rate?
[17:05:59] <les_w> head
[17:06:27] <les_w> no not quite...hmmm
[17:06:32] <les_w> oh well
[17:07:04] <alex_joni> snap out of it, jerk
[17:07:10] <alex_joni> lol
[17:07:13] <alex_joni> kidding .. ;)
[17:07:27] <les_w> ah...jerk is the RATE you press the gas pedal in a car
[17:07:43] <les_w> snap is the acceleration of your foot on the pedal!!
[17:07:49] <les_w> hahaha
[17:07:54] <les_w> got it now
[17:08:01] <anonimasu> how can that be infinite?
[17:08:01] <SWPadnos_> and snap is what happens when you slam the gas pedal in a Veyron
[17:08:03] <les_w> I'll snap out of it.
[17:08:04] <anonimasu> ^_^
[17:08:06] <cradek> 11:03:21 < cradek> after jerk, my conceptual grasp goes away fast
[17:08:16] <anonimasu> heh
[17:08:20] <anonimasu> cradek: be more gentle
[17:09:02] <les_w> only if a force instantly stops can jerk be infinite
[17:09:33] <alex_joni> there is no physical force that can stop instantly
[17:09:48] <les_w> I think you are right
[17:09:59] <les_w> but some can stop awfully fast.
[17:10:01] <alex_joni> so it's more a theoretical term
[17:10:05] <les_w> right
[17:10:09] <alex_joni> yes, and jerk is very high
[17:10:13] <alex_joni> but not infinite
[17:10:17] <les_w> right
[17:10:28] <alex_joni> it might be considered infinite compared to normal values though
[17:10:38] <SWPadnos_> yeah - and I'm not sure you can control the next higher order anyway
[17:10:55] <SWPadnos_> accel is proportional to torque, once you accout for load
[17:11:00] <alex_joni> SWPadnos_: depends on how you do the controling
[17:11:00] <SWPadnos_> account
[17:11:06] <alex_joni> or what the forces are you use
[17:11:16] <alex_joni> if it's some motion, then probably not
[17:11:27] <les_w> yes, for all practical purposes if you suddenly unhooked a motor lead it would be not much different .
[17:11:48] <alex_joni> maybe some very slow motion, and the moments the forces change are very small compared to the whole motion
[17:11:58] <SWPadnos_> you can control jerk, since that's the rate of change of current in the motor
[17:12:12] <les_w> right
[17:12:20] <alex_joni> isn
[17:12:25] <alex_joni> isn't that accel?
[17:12:31] <alex_joni> the rate of change of current?
[17:12:40] <SWPadnos_> I'm not sure it buys you anything to control the rate that you change the current change rate
[17:12:47] <les_w> generally current is accel
[17:12:54] <SWPadnos_> no - accel should be proportional to current fora given load
[17:12:58] <alex_joni> fixed current is velocity
[17:13:06] <SWPadnos_> no - fixed voltage is velocity
[17:13:14] <SWPadnos_> current changes velocity
[17:13:19] <SWPadnos_> so it's accel
[17:13:20] <alex_joni> fixed voltage assumes fixed current
[17:13:24] <les_w> hmm the reactive back emf of a motor would be related to jerk
[17:13:30] <les_w> l di/dt?
[17:13:33] <SWPadnos_> assuming a resistor driver, yeah ;)
[17:13:44] <alex_joni> you have a resistor (the motor)
[17:13:52] <alex_joni> doesn't matter how you drive it
[17:14:15] <SWPadnos_> the motor is an inductor as well, and that's more signifficant et speed
[17:14:28] <les_w> and even a capacitor
[17:14:40] <les_w> look at the system function
[17:14:41] <SWPadnos_> also the flywheel effect
[17:15:47] <les_w> YEAH IMAGINE A Dc motor vs a large capacitor
[17:15:53] <les_w> oops
[17:16:22] <les_w> "charges up" emf as it winds up...
[17:16:36] <les_w> holds the charge...
[17:16:47] <les_w> and can discharge into a load
[17:16:59] <les_w> 1/s stuff for sure!
[17:18:26] <les_w> Have system functions for motors in a book somewhere...polynomial of s in both numerator and denominator
[17:20:06] <les_w> So neat....inductive kick in a servo will never get above a certain value if it is used for a jerk limited path
[17:20:31] <SWPadnos_> what about steppers
[17:20:33] <SWPadnos_> ?
[17:20:37] <les_w> hmm
[17:21:20] <les_w> I think same...just with a sine force function superimposed
[17:21:58] <SWPadnos_> I suppose that the control side of the driver sees basically the same thing
[17:22:42] <les_w> I just think of steppers as multiphase ac synchronous motors often run with square wave power
[17:23:01] <SWPadnos_> uh - yeah, me too ;)
[17:23:05] <les_w> haha
[17:27:28] <lerman> I'm back.
[17:28:27] <les_w> reminds me...I was to cost up a HOBBY market small cnc router for an exercise
[17:28:41] <les_w> and see if I get me too performance or not
[17:29:00] <SWPadnos_> skreek engrish, les
[17:29:24] <les_w> "me too"
[17:29:59] <les_w> ie If I design a hobby machine will it be like the myriads out there?
[17:30:20] <les_w> just another fish in the pond?
[17:30:30] <SWPadnos_> right - or will it actually be better?
[17:30:59] <les_w> yeah. I don't know either. Never thought about it. I design commercial machines.
[17:31:17] <les_w> good exercise
[17:32:19] <SWPadnos_> heh
[17:33:17] <SWPadnos_> actually, putting some engineering knowledge into the design of a small system should give you a better machine for the same manufacturing cost (or, a 30% better machine for 10% more cost ...)
[17:33:37] <SWPadnos_> but it probably wouldn't pay back the engineering effort any time soon
[17:33:58] <les_w> I am just trying to decide what "better" means in that market
[17:34:40] <les_w> how do you out sherline a sherline or out taig a taig
[17:34:43] <les_w> heh
[17:35:03] <lerman> Gee, not that small, I hope.
[17:35:32] <les_w> One thing I note...as far as the hobby cnc routers...many are very poor designs
[17:35:55] <les_w> a few are good
[17:36:39] <les_w> hmmm microstepping hybrid servo?
[17:37:07] <les_w> acme leadscrew with moglice like bearing?
[17:37:35] <SWPadnos_> what's the wearability of Moglice (and how expensive is it compared to steel)?
[17:37:57] <lerman> I'd be interested in a small industrial quality machine. Tool changer, threading, etc
[17:38:01] <SWPadnos_> durability
[17:38:30] <lerman> My understanding is that Moglice is quite durable.
[17:38:38] <les_w> Well, we have our own. Phylly resins. It's expensive like moglice. I can mix my own (different) compound.
[17:39:07] <lerman> How expensive is Moglice? How much do you need for a small machine?
[17:39:27] <SWPadnos_> true - I seem to remember people repairing midsize machine ways with it
[17:39:49] <les_w> forgot but ridiculous price. like $10 a gram or something.
[17:40:29] <les_w> moly disulfide and colloidal teflon in an amine cured epoxy binder
[17:40:42] <les_w> Perhaps a dash of graphite...
[17:40:53] <les_w> ?
[17:40:55] <lerman> Salt and pepper to taste....
[17:40:59] <les_w> yup
[17:41:23] <les_w> I use moly filled nylon a lot...it's cheap
[17:42:18] <les_w> And...having developed conductive coatings, I have two Astra three roll mills!
[17:42:39] <SWPadnos_> EMI coatings as well?
[17:42:55] <les_w> I have developed coatings with teflon for switch contacts
[17:42:56] <lerman> Are the heaters for defrosting mirrors?
[17:43:17] <les_w> I developed all the coatings for my heaters yes
[17:43:32] <les_w> yes defrostinf /demisting
[17:44:10] <les_w> that uses a special positive temperature coefficient ink.
[17:44:42] <lerman> Could it be applied to the outside of a glass jar to keep the jar warm?
[17:45:11] <les_w> It took me and my engineers about a year to perfect that ink.
[17:45:16] <les_w> lerman: yes
[17:45:48] <SWPadnos_> can you say "hot coffee"?
[17:46:31] <SWPadnos_> oops - forget I said that (while I sneak off to the patent office ;) )
[17:46:37] <les_w> Japanese have printed simple graphite ink on paper vending cartons for food for decades
[17:46:52] <SWPadnos_> damn - we're always behind
[17:46:57] <les_w> i can give other uses
[17:47:04] <les_w> used in cars of course
[17:47:14] <les_w> and planes
[17:47:20] <les_w> foot warmers
[17:47:30] <les_w> microwave succeptors
[17:47:46] <les_w> portable infrared targets
[17:48:01] <SWPadnos_> how hot can these "inks" get?
[17:48:15] <lerman> The positive temp coefficient is a big plus for heaters because they can be self regulating.
[17:48:36] <les_w> veries. my lowest is designed to turn on at just below body temperature.
[17:48:45] <les_w> highest is about 150c
[17:49:18] <les_w> yes....if ice is on one spot...only that spot powers up
[17:49:37] <les_w> oh also refrigerator defrosters
[17:50:04] <tomp> morning all!
[17:50:10] <les_w> duct heaters...print on plastic sheet, roll up in a spiral
[17:50:17] <lerman> How high a power density can you get? (Watt's per sq inch or whatever.)
[17:50:32] <lerman> Watt's -> Watts.
[17:50:44] <SWPadnos_> no relation
[17:50:47] <les_w> depends on substrate
[17:50:52] <les_w> .5 to 10
[17:50:56] <les_w> usually
[17:51:03] <les_w> car stuff is 2
[17:51:18] <alex_joni> morning tomp
[17:51:23] <les_w> morning tomp
[17:51:26] <les_w> haha
[17:51:56] <lerman> alex: welcome back -- my email is fixed -- thanks.
[17:52:07] <alex_joni> lerman: seen your mail to the dev list
[17:57:22] <lerman> Just sent email to Macfarlane asking if she can make additional info (eg. source code) available.
[17:57:51] <les_w> oh great
[17:58:14] <les_w> Paul sure poured over that paper a long time.
[17:59:25] <les_w> Is she still in an academic environment?
[18:00:29] <lerman> I used the email address she had on the website: http://www.mech.ubc.ca/~sonja/. We'll see if it bounces or if I get a reply.
[18:01:40] <lerman> or neither.
[18:01:45] <les_w> I ask because if she is, given appropriate paper fodder and she might do some work on it
[18:02:10] <lerman> I figured that's why you asked. What did Paul have to say about it?
[18:03:00] <les_w> He read it for days. He asked what the math meant. I tried to teach that. He seemed to understand it well.
[18:04:00] <les_w> very well.
[18:04:06] <dmess> was the math correct??
[18:04:28] <les_w> I can find no fault with it.
[18:04:48] <SWPadnos_> is the math practical?
[18:04:51] <dmess> enuf said
[18:04:54] <SWPadnos_> (for use on a computer)
[18:04:56] <lerman> Ahhh. Does that mean that YOU follow the math? I got lost / zoned out when it came to the quarternions. I was a pure math major, so we didn't deal with stuff like Laplace transforms or quarternions -- except in passing as specific types of more general stuff.
[18:05:29] <lerman> Macfarlane actually implemented and ran the stuff, but I believe it was with a DSP.
[18:05:31] <SWPadnos_> uh-oh -so you're saying that the equation is the answer for you?
[18:05:36] <les_w> I think so. You always want to avoid numerical methods in such calculations
[18:05:47] <les_w> Paul quaternioned his head off.
[18:06:35] <les_w> I do laplace stuff a lot...quaternions seldom
[18:07:10] <lerman> Fortunately, I believe that stuff was in the joint space or orientation part of the paper. So it could be ignored for the purposes of a trivkins only implementation. -- (For now, that is.)
[18:07:38] <chinamill> * chinamill is away: eat
[18:08:32] <les_w> yes. inverse kinematics...now that can be hairy. Lots of jacobeans. Often no closed form solution. Poles and zeros.
[18:09:04] <dmess> and alot of anf if ors
[18:09:20] <les_w> heh
[18:09:41] <lerman> Weren't the jacobeans a french political group?
[18:09:51] <les_w> haha
[18:10:09] <les_w> yes they had a platform of partial differentials.
[18:10:12] <lerman> And we won't mention the poles.
[18:10:41] <les_w> hahaha
[18:11:25] <lerman> Macfarlane is no longer listed in the student directory I looked at.
[18:11:51] <les_w> Her sponsoring professor....
[18:12:04] <les_w> co wrote a couple of those tp papers...
[18:12:05] <lerman> But the email hasn't bounced, so that's good news.
[18:12:26] <lerman> Well, that's a next step.
[18:12:30] <les_w> yeah
[18:13:53] <lerman> I should go out to the shop and get to work. I have to see if I can thread the end of a 5/8 inch brass rod to take a 1/4" NPT fitting.
[18:14:59] <les_w> i'll cost up a hobby machine then!
[18:15:37] <lerman> I'm away....
[18:37:45] <alex_joni_> alex_joni_ is now known as alex_joni
[18:39:51] <jmk_sleep> jmk_sleep is now known as jmkasunich
[19:22:39] <CIA-12> 03alex_joni * 10emc2/scripts/emc.in: cleaned up the runscript, added comments to various sections
[19:23:30] <jmkasunich> well that sucks
[19:24:25] <skunkworks> sorry roltek?
[20:27:46] <picnet> No robin or paul whats happened?
[20:28:17] <jmkasunich> picnet: you've been away for while haven't you?
[20:28:18] <cradek> neither of them is around much lately
[20:28:45] <picnet> Actuall
[20:28:52] <Jymmm> I killed them both and ate their liver with with a nice chianti and fava beans
[20:29:03] <picnet> Y about 1 year plus ;)
[20:29:27] <picnet> Yummy
[20:29:58] <Jymmm> too bad I hate liver and wine
[20:48:38] <Jymmm> has anyone carved redwood? If so, how did it turn out?
[20:49:10] <SWPadnos_> red
[20:49:47] <Jymmm> SWPadnos_: You want help with the verbage don't ya?!
[20:50:09] <SWPadnos_> oops, uh - wrong forum ;)
[20:50:28] <Jymmm> SWPadnos_ btw... you forgot to mention encoder included with your board in your posting
[20:50:53] <SWPadnos_> true enough (though I did say that it could be cheaper with a less expensive one)
[20:51:48] <Jymmm> SWPadnos_: I really think ppl want something quick and dirty. Just a simple alternative to powering up the controller.
[20:52:23] <Jymmm> we're talking two chips here.
[20:52:31] <SWPadnos_> this isn't it - if I'm to not lose money on it, I either need about 50 orders, or it needs to sell for almost as much as a G-Rex
[20:52:37] <SWPadnos_> (for more than one axis)
[20:53:35] <Jymmm> SWPadnos_ Simplify the design (yes I know you already had boards made and all), but what I'm talking about is two chips and a single header
[20:54:25] <Jymmm> not a fancy header either, let them have a breakout board
[20:54:38] <Jymmm> not a fancy header either, let them buy a breakout board ( I mena)
[20:55:18] <Jymmm> you could just sell the PCB, the PCB+components (as a kit) , or fully assembled
[20:56:33] <SWPadnos_> yeah - get rid of the switcher (replace with a linear reg), use headers instead of terminal blocks, etc.
[20:57:08] <SWPadnos_> and probably get rid of the LEDs as well - the driver is $6
[20:57:23] <SWPadnos_> (though they are cool)
[20:57:35] <Jymmm> could use a invertor to drive them
[20:58:21] <SWPadnos_> I don't want to have multiple fast interrupts happening
[20:58:36] <Jymmm> SWPadnos_: KISS
[20:58:40] <SWPadnos_> "manually" driving the LED matrix wouldn't be the best thing
[20:59:01] <Jymmm> ok scratch the LED, and just use a pot
[20:59:30] <Jymmm> we are talking 555 and logic chip, but a tad more fancy than that.
[20:59:36] <SWPadnos_> yep - the user probably doesn't care what the actual speed is, if they're right there on the knob
[20:59:59] <Jymmm> you could even do a hi/lo speed button too
[21:00:11] <Jymmm> but KISS
[21:00:18] <SWPadnos_> no - you probably want some sort of accel/decel, especially for reversals
[21:00:37] <Jymmm> what atmel are you using?
[21:00:55] <SWPadnos_> it acan be super simple, and $5, but if it isn't significantly better than a 555, then there's no reason not to get a 555 instead
[21:01:07] <SWPadnos_> that one is the ATMega162, I thikn
[21:01:19] <SWPadnos_> it has 3 independent PWMs, with two outputs each
[21:01:32] <Jymmm> SWPadnos_ That's what I'm trying to say.... ppl would be happy with 555 if they didn't have to wire it themselves.
[21:02:01] <SWPadnos_> ok - then you should make a 555 kit ;)
[21:02:02] <Jymmm> but you could use a 2400 instead
[21:02:04] <SWPadnos_> I'm a pro!
[21:02:51] <SWPadnos_> no - a software pulse train would be bad, it has to be PWM (and I think the 2400 doesn't have the more advanced PWM, with programmable pulse rates)
[21:03:31] <Jymmm> what makes you think you need a PERFECT pulse train? This is a completely manual operation, not an arc or anything.
[21:04:13] <Jymmm> "I just want to hit a switch and make it go 'that way' without having to crank a knob 50K times"
[21:04:54] <SWPadnos_> as long as it's slow, it should be fine, but when you go faster, especially with steppers (even worse under load), a ragged pulse train will stall the motors
[21:05:16] <Jymmm> 2400 can work to 10MHz iirc ?
[21:05:23] <SWPadnos_> and if it sounds funny (which a 555 wouldn't), then it's a perception problem
[21:05:28] <SWPadnos_> 8, I think
[21:05:41] <Jymmm> ok, 8MHz, you only need 30Khz
[21:05:52] <SWPadnos_> but if you have a pot attached, you have to read the A/D.
[21:05:57] <Jymmm> and that's for all three running at the same time
[21:06:15] <Jymmm> pot is just speed (timing of step pulse)
[21:06:19] <SWPadnos_> that can be a manual operation, so itmight only deform the waveshape by a few microseconds
[21:06:31] <SWPadnos_> yes, and it has to be read constantly, to keep up with changes
[21:06:50] <Jymmm> huh?!
[21:06:51] <SWPadnos_> (every ms or two, then averaged to get rid of quantization noise)
[21:07:03] <SWPadnos_> spin the knob, the mottor goes faster, right?
[21:07:05] <Jymmm> why it's a manual toggle switch?
[21:07:28] <Jymmm> we're talking a pulce RC circuit here
[21:07:31] <Jymmm> sumple
[21:07:34] <Jymmm> simple
[21:07:34] <SWPadnos_> hi/lo only?
[21:07:47] <SWPadnos_> then how do you configure the max pulse rate?
[21:07:51] <Jymmm> no, 0 to whatever.
[21:07:58] <SWPadnos_> ok - a knob then?
[21:08:02] <k4ts> hello
[21:08:06] <SWPadnos_> hi
[21:08:31] <Jymmm> yeah, just a pot. for the MAX level, could use another resister or jumpers and bitwise it into the uC
[21:08:58] <SWPadnos_> what?
[21:09:21] <Jymmm> SWP_Away: But, why do you need to "set" a max level... just dont turn the knob that far.
[21:09:21] <SWPadnos_> that made no sense to me
[21:10:01] <Jymmm> SWP_Away you dont turn the volume on your stereo to it's MAX level do you?
[21:10:03] <SWPadnos_> but what if you do - the thing can output 100k pps, and your machine stops at 20
[21:10:23] <Jymmm> SWP_Away ok, it stops, it's not going to damamge the steppers, just stall them.
[21:10:30] <SWPadnos_> the active range is only 50 degrees of rotation
[21:10:40] <SWPadnos_> unless it's driving servos (G340)
[21:10:51] <SWPadnos_> it'll more likely fault the gecko
[21:10:55] <SWPadnos_> (or whatever)
[21:11:03] <SWPadnos_> then you have to have all the reset stuff
[21:11:06] <k4ts> Jacky^ hello
[21:11:22] <Jymmm> SWP_Away, look... this is a manual operation, correct?
[21:11:25] <SWPadnos_> (I think it's best to have a limiter in there, even if it's a resistor on the board)
[21:11:43] <SWPadnos_> yes
[21:11:45] <Jymmm> SWP_Away ok, so put one inline with the pot.
[21:12:05] <SWPadnos_> sure
[21:12:09] <Jymmm> or have a 2nd pcb pot to set max level
[21:12:14] <Jymmm> whatever.
[21:12:19] <SWPadnos_> all I'm saying is that "simple to use" does not mean "simple to design"
[21:12:27] <SWPadnos_> or "simple to build"
[21:12:37] <Jymmm> but all you are doign is having a Fwd/rev switch and a speed control. that's it.
[21:12:57] <SWPadnos_> ys, but it needs to work for 1000 different machine configs (somehow)
[21:13:15] <Jymmm> SWP_Away: step/dir. that's it. it's that simple
[21:13:17] <SWPadnos_> and you don't want to break anything
[21:13:24] <SWPadnos_> there needs to be an estop input still
[21:13:27] <SWPadnos_> etc.
[21:13:38] <SWPadnos_> you don't want people getting hurt
[21:13:44] <Jymmm> SWP_Away no estop. Just turn the switch off
[21:13:53] <SWPadnos_> no! absolutely not
[21:14:09] <Jymmm> look, no pulse triain, no movement.
[21:14:20] <SWPadnos_> there's still a big dangerous machine there, and I sure as hell won't make something that can try to make it kill you
[21:14:48] <Jymmm> this is a kit, if you want to intergrate estop circuitry, that's fine.
[21:15:08] <SWPadnos_> I think it's a good idea to make a simple to use unit, but it can't be as simple in construction as you're suggesting
[21:15:12] <Jymmm> but what is it going to do? kill the 5vdc logic power?
[21:15:19] <SWPadnos_> it doesn't need to be as complex as my current unit either though
[21:15:42] <SWPadnos_> it's just another input that has to be maintained for this thing to output pulses, that's all
[21:15:47] <Jymmm> your ESTOp can be as simple as those toggle switch covers
[21:16:07] <Jymmm> but that's not part of the design, that's part of the ext controls.
[21:16:12] <SWPadnos_> in fact, that can be used by the CNC to take over the drivers
[21:16:50] <SWPadnos_> sure - you'd wire this to the estop chain, so the mushroom switch / limit switches turns thi off as well
[21:17:20] <Jymmm> that's a relay somewhere else that kills pwr to this box.
[21:17:33] <SWPadnos_> could be, in which case, I'd be happy ;)
[21:17:35] <Jymmm> again, not part of the design itself.
[21:17:52] <Jymmm> KEEP IT SIMPLE STUPID. I can't say that enough.
[21:18:00] <SWPadnos_> yes, you can
[21:18:04] <SWPadnos_> :)
[21:18:37] <Jymmm> SWPadnos_ you've made this fancy thing, but some just want the duct tape and bailing wire.
[21:18:55] <Jymmm> that's all I'm trying to say.
[21:18:58] <SWPadnos_> that's OK, but I don't want to be the duct tape supplier
[21:19:27] <SWPadnos_> I prefer to make prototypes that look like finished products, rather than products that look (or work) like prototypes
[21:19:30] <Jymmm> then supply the bailing wire
[21:19:40] <SWPadnos_> heh
[21:19:59] <Jymmm> seriously, your overcomplicating this aspect of it.
[21:20:10] <Jymmm> go for both sides of the coin
[21:20:36] <SWPadnos_> it's just me, I have to concentrate on the things that bring in the most cash with the least effort
[21:20:54] <Jymmm> I would love a lil simple box with a FWD-OFF-REV switch and a pot to jog my machien once in a while.
[21:20:57] <SWPadnos_> making 100 of something, then answering the 200 questions, all for $5 profiut each, isn't good for me
[21:21:37] <Jymmm> Right, so go for the $25 kit and a forum
[21:21:45] <SWPadnos_> I need to make 10 of something, and answer only 30 questions, but make $50 each ;)
[21:21:47] <Jymmm> or $10 PCB and a forum
[21:21:58] <SWPadnos_> could be done, and I may.
[21:22:04] <SWPadnos_> if so, I'll send you the first one
[21:22:38] <Jymmm> you'll need to write docs than a layman cna understand (or that's what I would do)
[21:22:50] <SWPadnos_> yes
[21:22:50] <Jymmm> That's sorta my style of writing whitepapers.
[21:23:00] <SWPadnos_> all part of the design process (or supposedto be at any rate)
[21:24:13] <Jymmm> the most difficult thing I can think of is the "bypass" of manual/auto mode
[21:24:25] <SWPadnos_> yes
[21:25:24] <Jymmm> andything tri-state like that out there?
[21:25:40] <SWPadnos_> actually, it depends on the step inputs
[21:25:54] <SWPadnos_> if you don't pull low on the geckos, then you're effectively out of circuit
[21:25:57] <Jymmm> OH could use logic gates... that would be sneaky
[21:26:07] <Jymmm> if they're fast enough that is
[21:26:26] <SWPadnos_> logic is fast, but actually more expensive than microprocessors these days
[21:26:29] <k4ts> byeeeeeee
[21:27:08] <Jymmm> well, cheaper than a mechanical switch
[21:28:09] <SWPadnos_> you still need the mechanical switch to decide whether or not to tristate
[21:32:45] <SWPadnos_> also realize that a depowered CNC may not allow anything else to control the drivers
[21:35:10] <Jymmm> well, I'm thinking: PC <---> Manualbox <----> geckos/xylotex
[21:35:46] <SWPadnos_> yep
[21:37:34] <Jymmm> so that eliminates that issue, not it's a matter of an A/B (logic) switch.
[21:37:40] <Jymmm> s/not/now/
[21:38:44] <Jymmm> Hmmm. a QPDT (Center off) might do it.
[21:57:08] <jmkasunich> jmkasunich is now known as jmk_hiding
[21:58:13] <CIA-12> 03alex_joni * 10emc2/scripts/emc.in: fixed some typo's on the ini-finding mechanism
[21:59:40] <alex_joni> alex_joni is now known as alex_joni_away
[22:10:23] <skunkworks> rolteck?
[22:10:43] <skunkworks> roltek?
[22:26:39] <alex_joni_away> alex_joni_away is now known as alex_joni
[22:31:55] <skunkworks> skunkworks is now known as skunkworks_brb
[22:35:32] <CIA-12> 03alex_joni * 10emc2/tcl/ (TkEmc tkemc.tcl): moved the location of default TkTemc. you can still have one in your own dir
[22:37:07] <CIA-12> 03alex_joni * 10emc2/configs/TkEmc: moved TkEmc to emc2/tcl, users can still have on in their own configs dir e.g. configs/foo/TkEmc
[22:40:54] <CIA-12> 03alex_joni * 10emc2/configs/common/ (6 files): moved to emc2/configs/common, was in topdir initially
[23:06:26] <A-L-P-H-A> ohoh check these out... http://www.infofreako.com/jad/enpitsu-e.html
[23:06:37] <A-L-P-H-A> now, I want my axis to be fully operational now hahah
[23:08:42] <CIA-12> 03alex_joni * 10emc2/configs/stg/ (stg_io.hal stg_motion.hal): moved stg hal files to configs/stg
[23:10:07] <CIA-12> 03alex_joni * 10emc2/configs/ (stg_io.hal stg_motion.hal): moved stg hal files to configs/stg
[23:12:57] <CIA-12> 03alex_joni * 10emc2/configs/ (6 files): moved to configs/common
[23:29:50] <CIA-12> 03alex_joni * 10emc2/configs/sim/ (sim.ini sim.tbl simulated_limits.hal sim.var): moved to configs/sim
[23:32:41] <CIA-12> 03alex_joni * 10emc2/configs/ (sim.ini simulated_limits.hal): moved to configs/sim
[23:34:13] <skunkworks_brb> skunkworks_brb is now known as skunkworks
[23:37:12] <lerman> A-L-P-H-A: why are you wasting our time with this cr... Holy Shit. Thanks for the pointer. Yup -- does make one want to add a 4th axis.
[23:40:38] <CIA-12> 03alex_joni * 10emc2/configs/ (ppmc_io.hal ppmc_motion.hal): moved to the proper subdir
[23:42:00] <cradek> arrgh, why did I cvs up??
[23:45:51] <alex_joni> cradek: wait a bit..
[23:46:42] <CIA-12> 03alex_joni * 10emc2/configs/demo_mazak/ (demo_mazak.clp demo_mazak.hal demo_mazak.ini): moved mazak stuff to configs/demo_mazak
[23:48:57] <CIA-12> 03alex_joni * 10emc2/configs/ (mazak_rf.clp mazak_rf.hal mazak_rf.ini): moved mazak stuff to configs/demo_mazak
[23:50:41] <CIA-12> 03alex_joni * 10emc2/configs/ (step_cl.clp step_cl.hal step_cl.ini classicladder.hal): moved to configs/demo_step_cl
[23:59:42] <CIA-12> 03alex_joni * 10emc2/configs/demo_step_cl/ (6 files): moved to configs/demo_step_cl