#emc | Logs for 2007-03-11

Back
[00:14:53] <SWPadnos> so - anyone know why Windows XP (home) would suddenly decide to ignore keyboard input?
[00:15:15] <SWPadnos> across reboots, using "last known good" configuration, and with an external USB keyboard as well?
[00:15:40] <SWPadnos> (note that the keyboard functions well enough to select the last known good config, so it's physically functional)
[00:15:50] <cradek> y2.007k?
[00:15:54] <DanielFalck> part of Micro$oft's strategy to get you to upgrade to vista?
[00:16:05] <cradek> you know you're asking in the wrong place, right?
[00:16:20] <DanielFalck> what's XP anyway?
[00:16:39] <SWPadnos> of course - it's a rhetorical question - I jus spend an hour on the phone trying to help a friend figure it out
[00:16:54] <alex_joni> cradek: y2k7
[00:17:00] <SWPadnos> Xtreme Poop edition
[00:18:30] <cradek> Xtra-Price?
[00:39:31] <Rugludallur> hmm looks like steplen/stepspace parameters affect the maximum velocity (I get the error when I turn the machine on), do you guys think it's only the error or does setting steplen/stepspace to 2 each actually drop the maximum speed obtainable by 50% ?
[00:42:59] <alex_joni> if you set both to 2, then yes
[00:43:12] <alex_joni> if it's only 1 set at 2, then you get 66%
[00:43:56] <Rugludallur> alex_joni: ;) thanks, looks like I need to find a way around that then
[00:44:55] <jtr> alex_joni: you're supposed to be in bed, young man! ;-)
[00:45:33] <alex_joni> jtr: who says I'm not?
[00:45:51] <alex_joni> Rugludallur: any reason to do that? (stepper driver weirdness?)
[00:46:08] <alex_joni> Rugludallur: I don't suppose you can krank BASE_PERIOD down?
[00:46:21] <Rugludallur> alex_joni: got one driver on my z axis which requires larger steps
[00:46:36] <Rugludallur> alex_joni: If I lower base period that lowers my max speed for the other axis
[00:48:58] <alex_joni> I meant lower period, faster freq
[00:49:09] <alex_joni> increase speed
[00:49:22] <alex_joni> btw.. you know you can set steplen only for Z-axis.. right?
[00:49:34] <Rugludallur> alex_joni: I might be able to push it a bit, I'm at 15000 at the moment and I might get to about 12000
[00:50:11] <Rugludallur> alex_joni: Might be time to refresh the computer :D
[00:50:54] <alex_joni> just remember that newer isn't always better
[00:51:17] <alex_joni> my advice: get a LiveCD with you when you're shopping for a new PC ;)
[00:51:22] <Rugludallur> alex_joni: (just kidding), I'm sure I can find some way
[00:51:25] <alex_joni> run a latency test in the store :P
[00:51:41] <alex_joni> people usually look pretty weird at me when I do that
[00:51:41] <Rugludallur> alex_joni: bring an emc live cd along
[00:51:51] <alex_joni> Rugludallur: that's what I do ;)
[00:52:06] <jtr> alex_joni: s/in bed/asleep/ ;)
[00:52:21] <alex_joni> jtr: who says I'm not? ;-)
[00:52:31] <Rugludallur> alex_joni: do you know if RT will be treaded any time soon ?
[00:52:44] <alex_joni> this might be an AI programm trained with 3 years of IRC logs
[00:52:54] <alex_joni> Rugludallur: didn't get that..
[00:52:58] <alex_joni> treaded?
[00:53:04] <Rugludallur> alex_joni: err threaded
[00:53:34] <Rugludallur> alex_joni: would be neat to run multiple RT threads in parallel without impacting each other
[00:53:44] <alex_joni> well.. it is like that
[00:54:08] <alex_joni> except that there's a big bottleneck ;)
[00:54:13] <alex_joni> and that's the CPU and time granularity
[00:54:30] <alex_joni> which means at some point the threads would have to execute at the same time :)
[00:54:47] <alex_joni> but mostly they are not influenced by each other
[00:54:58] <alex_joni> (think base thread and servo thread)
[00:55:20] <Rugludallur> alex_joni: yeahh, but I was wondering if they can run on seperate cpu's
[00:55:36] <jtr> alex_joni: would jmk's new stepgen core allow the flexibility Rugludallur needs?
[00:57:42] <alex_joni> jtr: Rugludallur doesn't need flexibility
[00:57:50] <alex_joni> Rugludallur simply needs more cojones
[00:58:02] <Rugludallur> alex_joni: or reduce my microstepping :P
[00:58:15] <alex_joni> it's not a limitation on how stepgen works.. it's simply a timing issue
[00:58:37] <alex_joni> if you need to wait a certain time between steps, then you can't krank up the step frequency indefinately
[00:58:38] <jtr> I'm thinking it will allow finer adjustment of the timing parameters.
[00:58:53] <alex_joni> jtr: I seriously doubt that
[00:59:12] <alex_joni> you can output pulses (actually changes, for pulses you need 2 periods), once every BASE_PERIOD
[00:59:21] <alex_joni> so you either output a pulse, or not
[00:59:48] <alex_joni> if he needs to wait two base periods between pulses.. then there's not much another stepgen might do better
[00:59:48] <Rugludallur> alex_joni: Is there any reason why steplen/stepspace would need to affect the max velocity ?
[00:59:53] <alex_joni> Rugludallur: yes
[01:00:08] <alex_joni> steplen + stepspace = period
[01:00:28] <alex_joni> 1/period = frequency (aka ~ max velocity)
[01:00:44] <alex_joni> actually frequency / INPUT_SCALE
[01:01:03] <alex_joni> so it's something like this:
[01:01:24] <alex_joni> BASE_PERIOD * (steplen + stepspace) / INPUT_SCALE
[01:01:53] <alex_joni> 1 / ( BASE_PERIOD * (steplen + stepspace) * INPUT_SCALE )
[01:01:59] <alex_joni> * alex_joni is tired this late
[01:02:10] <alex_joni> Rugludallur: but you should get the idea :D
[01:02:14] <Rugludallur> alex_joni: I do
[01:02:37] <alex_joni> ideally steplen and stepspace are 1
[01:02:52] <alex_joni> that way you have the max pulse period = 2
[01:03:36] <alex_joni> you said you have 15000 for BASE_PERIOD?
[01:03:41] <Rugludallur> alex_joni: yes
[01:03:49] <alex_joni> steplen and stepspace?
[01:04:05] <Rugludallur> I was testing steplen 2 and stepspace 2
[01:04:22] <Rugludallur> alex_joni: the sad part is I only need steplen 2 and stepspace 2 for one axis
[01:04:24] <alex_joni> oh, that's quite much
[01:04:36] <alex_joni> Rugludallur: you can set it only for that axis then
[01:04:40] <alex_joni> and limit the speed on that one
[01:04:50] <Rugludallur> alex_joni: I did, but I still get the warning
[01:04:59] <alex_joni> on axis X & Y you get max 33.3 kHz pulses
[01:05:06] <alex_joni> what's your INPUT_SCALE's ?
[01:05:13] <Rugludallur> alex_joni 155.333
[01:05:18] <alex_joni> on all 3 ?
[01:05:28] <Rugludallur> alex_joni not Z, just Y and X
[01:05:51] <Rugludallur> alex_joni: ) have 6.5m with a resolution of 0.002mm :D
[01:05:53] <alex_joni> so X & Y are 214.592 units/sec max
[01:06:05] <alex_joni> I assume mm?
[01:06:11] <Rugludallur> alex_joni: yup
[01:06:19] <alex_joni> ok.. so roughly 200mm/sec
[01:06:24] <Rugludallur> alex_joni: I dn't run them much over 180 though
[01:06:41] <alex_joni> at 200mm/sec in the ini you shouldn't get a warning for X & Y
[01:06:45] <alex_joni> now lets look at Z
[01:06:58] <alex_joni> BASE_PERIOD is 0.000015 (in seconds)
[01:07:05] <alex_joni> steplen + stepspace = 4
[01:07:28] <alex_joni> 1/(base*4) = 16666 pulses / sec
[01:07:47] <alex_joni> is this also 155.333 pulses/mm ?
[01:08:08] <Rugludallur> alex_joni: I realized where you going with this and just fixed it :D
[01:08:12] <Rugludallur> (blush)
[01:08:20] <alex_joni> Rugludallur: no problem ;)
[01:08:27] <alex_joni> glad you got it
[01:08:31] <jtr> alex_joni: gotcha. I'm confusing steplen/stepspace with setup delays for the direction signal.
[01:08:55] <alex_joni> jtr: that's a different issue.. but also needed to be taken into account for
[01:09:42] <alex_joni> this might be interesting to read
[01:09:42] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TweakingSoftwareStepGeneration
[01:10:00] <Rugludallur> alex_joni: I have been reading it for the last hour :D
[01:10:21] <Rugludallur> alex_joni: or tweakin based on it
[01:10:30] <alex_joni> Rugludallur: when in doubt read #1.5
[01:10:40] <alex_joni> <rimshot> :P
[01:12:20] <jtr> Thanks. i also realized - it's still a software DDS - still CPU limited. Gotta run feed the cat.
[01:12:54] <alex_joni> jtr: the 5i20 based stepgen will be something else ;)
[01:14:45] <jtr> yep - looking forward to it. good night.
[01:15:30] <alex_joni> good night
[01:15:33] <alex_joni> * alex_joni runs to bed
[01:15:40] <alex_joni> Rugludallur: let me know how it works
[01:15:47] <alex_joni> (the whole machine I mean)
[01:15:56] <Rugludallur> alex_joni: I will, and I will make plenty of videos
[01:16:03] <alex_joni> that's great ;)
[01:16:14] <Rugludallur> alex_joni: I'm also testing jeplers gantrykins
[01:16:22] <alex_joni> maybe we can work a short technical description for www.linuxcnc.org
[01:16:22] <Rugludallur> alex_joni: but they seem to be broken atm
[01:16:30] <alex_joni> Rugludallur: broken how?
[01:16:36] <Rugludallur> alex_joni: hope to catch him tomorrow and tell him
[01:16:44] <alex_joni> * alex_joni might know
[01:16:49] <Rugludallur> alex_joni: No signal gets sent to slaved axis
[01:16:49] <alex_joni> I recently used them..
[01:16:55] <alex_joni> hmm.. that's odd
[01:17:02] <alex_joni> did you set them up right?
[01:17:07] <Rugludallur> alex_joni: I used a stepper config btw
[01:17:11] <Rugludallur> http://pastebin.ca/389646
[01:17:11] <Rugludallur> http://pastebin.ca/389648
[01:17:27] <Rugludallur> alex_joni: As far as I could tell from the documentation this is the right way
[01:17:41] <alex_joni> AXES = 3
[01:17:46] <alex_joni> you need 4 there
[01:17:51] <alex_joni> in [TRAJ]
[01:18:00] <alex_joni> otherwise motion will only enable 3 joints
[01:18:22] <Rugludallur> alex_joni: kk
[01:18:32] <Rugludallur> alex_joni and the HOEM/COORD to go with it
[01:18:53] <alex_joni> you can skip that .. but it can't hurt to make it nice
[01:19:11] <alex_joni> *blush* it's a real mess atm
[01:19:26] <alex_joni> programs that read the ini from all over the place
[01:19:53] <alex_joni> [TRAJ]HOME shouldn't be used in your case..
[01:20:10] <alex_joni> COORDINATES is only read by some GUIS to display the letters (I think tkemc is one of the few)
[01:20:33] <alex_joni> oooh.. do you need such a fast cycle_time ?
[01:20:34] <Rugludallur> alex_joni: I use tkemc :D
[01:20:42] <alex_joni> Rugludallur: ha
[01:21:01] <Rugludallur> alex_joni: because I run remote X session and gl stuff gets messed up
[01:21:14] <Rugludallur> alex_joni: I can reduce cycle time to 0.010
[01:21:34] <alex_joni> Rugludallur: I was just curious why you need such a fast cycle_time
[01:22:16] <Rugludallur> alex_joni: i honestly can't remember when I "upped" it
[01:22:48] <alex_joni> Rugludallur: n/m
[01:22:57] <alex_joni> let me know if the AXES=4 fixed it
[01:25:12] <Rugludallur> alex_joni: just did a hw test
[01:25:15] <Rugludallur> alex_joni: everything works :D
[01:25:25] <alex_joni> Rugludallur: yay
[01:25:28] <Rugludallur> alex_joni: the gantry ends sync up and all D:
[01:26:01] <Rugludallur> alex_joni: Now, I need to clean up the THC stuff, move it to this config and I am done
[01:26:16] <alex_joni> close to done
[01:26:20] <Rugludallur> alex_joni: btw, I made a seperate config I called stepper-gantry and a new thc config called plasma-tch
[01:26:24] <alex_joni> you need to document it really nicely..
[01:26:28] <alex_joni> then you are done
[01:26:29] <alex_joni> :P
[01:26:58] <Rugludallur> alex_joni: Do you think gantry kinematics will make it into emc anytime soon ?
[01:27:26] <Rugludallur> alex_joni: into cvs that is
[01:28:00] <Rugludallur> alex_joni: when that happens I can update the sample configs, remove the dallur one and add stepper-gantry and plasma-thc
[01:28:16] <alex_joni> Rugludallur: yeah, but probably it will be called something else
[01:28:56] <alex_joni> it's much more generic than gantrykins
[01:29:05] <alex_joni> it basicly allows for easy trivkins mapping
[01:29:27] <Rugludallur> alex_joni: hmm, the best analogy I can think off is "master-slave"
[01:29:48] <alex_joni> Rugludallur: you can also do simple mappings like : joint 0 is Y, joint 1 is A
[01:29:58] <alex_joni> not related to master-slave
[01:30:04] <Rugludallur> alex_joni: kk
[01:30:12] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?IniChanges
[01:31:01] <Rugludallur> alex_joni: so you might change the way trivkins are done today and inc. gantrykins into that ?
[01:31:20] <alex_joni> probably trivkins is ok for most machines
[01:31:35] <alex_joni> then there are some other trivkins machines that lack one or the other axis/joint
[01:31:36] <alex_joni> e.g. lathe
[01:31:52] <alex_joni> as it is now, you need to define the missing axis, but simply not use it
[01:32:17] <Rugludallur> alex_joni: I see, hmm I wish I had the time to motorise my lathe :D
[01:32:31] <alex_joni> Rugludallur: we're not going anywhere :P
[01:32:38] <Rugludallur> alex_joni: nahh but I need to go sailing
[01:32:47] <alex_joni> today?
[01:32:52] <Rugludallur> alex_joni: in 1 year
[01:32:53] <alex_joni> isn't it dark for that?
[01:32:56] <alex_joni> :-P
[01:33:08] <Rugludallur> alex_joni: I need to build the boat first, :D
[01:33:28] <alex_joni> any parts done yet?
[01:33:35] <Rugludallur> alex_joni: which has just become much easier thanks to the fact that I can sync up the two sides of the gantry on my plasma table
[01:33:50] <alex_joni> hmm.. seen a nice CNC once, for making sails
[01:34:08] <Rugludallur> alex_joni: ahh one of those things that lay down strands for carbon sails
[01:34:21] <alex_joni> yeah, that
[01:34:29] <Rugludallur> alex_joni: those are brilliant, they use the same machines for carbon fiber for the stealth jets
[01:35:43] <Rugludallur> alex_joni: enables you to individually place every fiber in a carbon structure based on a cad drawing, can't get much more detailed than that (or more strenght for weight)
[01:35:44] <alex_joni> I liked the harness for people that need to do some tweaks on the sails
[01:36:13] <alex_joni> they had a bag like a sleeping bag, or like the one on a glider..
[01:36:15] <Rugludallur> alex_joni: The bad part is that the sails only last for one race
[01:36:33] <alex_joni> Rugludallur: ouch.. then it gets quite pricey I imagine ;)
[01:36:37] <Rugludallur> alex_joni: Yeah, they look just like hang gliding harnesses
[01:36:47] <alex_joni> wonder if the fighter also lasts for one flight?
[01:36:49] <alex_joni> (lol)
[01:37:05] <Rugludallur> alex_joni: They don't know yet, but they promise to test fly one soon
[01:37:11] <alex_joni> ha
[01:37:20] <alex_joni> anyways.. what ind of boat will yours be?
[01:37:25] <Rugludallur> alex_joni: did you hear about the f22 raptor date line thingyu
[01:37:34] <alex_joni> competition? relaxing?
[01:37:44] <alex_joni> * alex_joni knows squat of boats..
[01:37:44] <Rugludallur> alex_joni: cruiser, liveaboard
[01:37:51] <alex_joni> oh cool
[01:37:59] <alex_joni> oh wait.. I have a rowboat
[01:38:01] <alex_joni> :P
[01:38:04] <Rugludallur> alex_joni: :D
[01:38:06] <alex_joni> not quite squat
[01:38:17] <Rugludallur> alex_joni: I just want to relax for a couple of years, get away from it all
[01:39:06] <Rugludallur> alex_joni: brb, going outside to the shop to smoke my celebration cigar (20 sec
[01:41:08] <CIA-6> 03jepler 07TRUNK * 10emc2/src/hal/user_comps/hal_input.py:
[01:41:08] <CIA-6> fix error if a -SUBSET was not specified:
[01:41:08] <CIA-6> NameError: name 'parts' is not defined
[01:41:19] <alex_joni> Rugludallur: that fast?
[01:41:22] <Rugludallur> Much better (im on the cnc controller machine now)
[01:41:27] <alex_joni> ahhh..
[01:41:31] <Rugludallur> alex_joni: I live in my shop
[01:41:40] <alex_joni> :-)
[01:41:43] <alex_joni> Rugludallur: http://dsplabs.utt.ro/~juve/poze/garana/IM000228.JPG
[01:42:12] <Rugludallur> alex_joni: nice :D
[01:42:33] <alex_joni> old photo..
[01:44:53] <Rugludallur> This is the z axis: http://dallur.com/typo3temp/pics/acdd160271.jpg
[01:45:25] <alex_joni> nice.. what torch is that?
[01:45:54] <Rugludallur> alex_joni: Thermal Dynamics PCM100 but it's highly modified
[01:46:08] <alex_joni> cool
[01:46:21] <alex_joni> I was studying a plasma last week
[01:46:23] <Rugludallur> alex_joni: actually it's about stock in that picture but I changed it quite a bit for the sensor
[01:46:27] <alex_joni> PO-S 70 from Kjellberg ;)
[01:46:37] <alex_joni> that's a *monster*
[01:46:39] <Rugludallur> alex_joni: I wish I could affor Kjellberg :D
[01:46:54] <alex_joni> the 70 stands for material thickness it cuts
[01:47:07] <Rugludallur> alex_joni: lol, my 100 stands for Amps :P
[01:47:17] <Rugludallur> alex_joni: only 25mm
[01:47:19] <alex_joni> I know.. that's the usual way to spec it
[01:47:25] <alex_joni> 70mm, 300A or so
[01:47:29] <jmkasunich> whats the big roll of wire in the pic?
[01:47:39] <alex_joni> Rugludallur: 450kg
[01:47:57] <Rugludallur> jmkasunich: shielded CAT5 wire, I used it for all limit/home signals and used RJ45 shielded connectors
[01:48:12] <jmkasunich> ok, you just happened to have the roll sitting on the machine table...
[01:48:21] <Jymmmm> Rugludallur shield rj45 ???
[01:48:24] <Rugludallur> jmkasunich: yup :D
[01:48:25] <Jymmmm> shielded
[01:48:43] <jmkasunich> that must be an EU thing
[01:48:45] <Rugludallur> Jymmmm: Yup, you can get shielded cat5 and cat6 cabling and rj45 plugs to go with it
[01:49:06] <Jymmmm> * Jymmmm has NEVER seen SHIELDED RJ45 connectors
[01:49:06] <Rugludallur> actually it's not just an EU thing, but I needed full shielding for everything and it's cheap
[01:49:24] <alex_joni> Jymmmm: never?
[01:49:32] <jmkasunich> I've mever seen nor heard pof shielded cat 5 over here
[01:49:40] <alex_joni> it's called STP
[01:50:00] <alex_joni> shielded twisted pair.. comes in Cat 5, etc
[01:50:03] <Rugludallur> wierd, it's not that hard to find here but it's not installed unless you really know what you are doing
[01:50:11] <alex_joni> there is also FTP
[01:50:34] <Rugludallur> if you hook up regular cables to shielded panels you essentially have a panel with dozens of mini antennas, not a good idea
[01:50:40] <alex_joni> FTP is foil shielded.. a bit worse than STP
[01:50:53] <alex_joni> I use FTP indoors usually
[01:51:04] <alex_joni> and STP for anything more prone to problems
[01:51:31] <petev> http://www.ramelectronics.net/html/cat5_cables-shld.html
[01:52:17] <Rugludallur> if you guys are looking for easy cabling for sensors it's about as good as it gets -> http://dallur.com/typo3temp/pics/e0a7596c4b.jpg
[01:52:57] <alex_joni> Jymmmm: never seen those connectors? the ones from petev's link?
[01:53:02] <Rugludallur> I don't know of any other system that's that compact and cheap
[01:53:22] <Jymmmm> alex_joni: Nope, but it doens't look like you get 100% shield coverage either.
[01:53:36] <Jymmmm> http://www.pacificcable.com/Picture_Page.asp?DataName=R45SLD
[01:54:00] <alex_joni> yes, the place where you crimp is plastic
[01:54:18] <alex_joni> Rugludallur: why not use regular rj45 sockets?
[01:55:22] <alex_joni> http://www.tlc-direct.co.uk/Images/Products/size_3/CM2181.JPG
[01:56:09] <Rugludallur> alex_joni: because I had to solider resistor and cross connect ,, converting from pnp to npn sensors and such
[01:56:35] <Jymmmm> back in 90
[01:56:48] <alex_joni> Rugludallur: oh, ok
[01:58:51] <Rugludallur> I also found great connectors for the motor cabling, now I can disconnect everything in 10 sec
[01:58:51] <Rugludallur> http://dallur.com/typo3temp/pics/997fdbc739.jpg
[01:59:56] <jtr> Are those Neutrik?
[02:00:13] <Rugludallur> jtr: yup
[02:00:33] <Rugludallur> jtr: not the cheapest ones but they work really well
[02:02:01] <alex_joni> Rugludallur: those are common on TIG welders (but with 3 pins only)
[02:03:39] <Rugludallur> alex_joni: I don't think I have seen em on TIG welders, but I when I build a "quick connect" system for my plasma cutter I used a 5pin one for the trigger and signals
[02:04:33] <Rugludallur> They also have a 4pin twist connector that is rated at 800v which I used for the HF connector
[02:04:39] <alex_joni> Rugludallur: on the signals from the torch usually
[02:05:09] <Rugludallur> err 5p (I didn't want to be able to connect anything the wrong way)
[02:05:54] <alex_joni> Rugludallur: I usually use Harting connectors
[02:06:04] <alex_joni> or ILME (same sh*t but italian brand)
[02:06:54] <alex_joni> http://www.ilme.de/produktdb/produkte/bilder/fcdf64.jpg
[02:07:19] <Rugludallur> alex_joni: those look pretty robust
[02:07:29] <alex_joni> Rugludallur: not quite cheap though
[02:07:42] <alex_joni> a complete connector (one side) is about 40-50 EUR
[02:07:47] <alex_joni> case + insert + pins
[02:07:51] <Rugludallur> alex_joni: eek
[02:08:04] <alex_joni> Rugludallur: but it will work in 10 years
[02:12:32] <Rugludallur> I still can't beleave that everything works now , after a year and half the table is done :D
[02:13:11] <cradek> Rugludallur: videos!!
[02:13:22] <CIA-6> 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: like angular, let the user specify the max jog speed of the linear axes
[02:13:32] <Rugludallur> cradek: I will make them tomorrow, now it's beer and cigar :D
[02:13:45] <cradek> neat, congratulations
[02:15:04] <CIA-6> 03cradek 07v2_1_branch * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: like angular, let the user specify the max jog speed of the linear axes
[02:16:05] <Rugludallur> hmm, 200mm per second isn't that fast but for plasma cutting it should be more than enough
[02:17:04] <CIA-6> 03cradek 07v2_1_branch * 10emc2/debian/changelog: improve mixed linear+angular gui
[02:18:30] <alex_joni> * alex_joni heads to bed
[02:18:31] <alex_joni> good night all
[02:18:36] <cradek> goodnight (again) alex
[02:18:39] <Rugludallur> night alex, and thanks for the help
[02:19:13] <alex_joni> Rugludallur: glad it works
[02:22:05] <Rugludallur> good night guys, im off to bed, thanks for the help
[02:40:55] <skullworks-PGAB> been digging in the Wiki
[02:41:24] <skullworks-PGAB> still lists the latest release as 2.1.0 on the main page
[02:43:13] <skullworks-PGAB> also - I agree with the canned cycles defined by an ini file, that would be handy to allow use of code posted for a different machine.
[02:51:04] <cradek> skullworks-PGAB: wiki fixed, thanks
[02:53:33] <skullworks-PGAB> np
[03:19:33] <CIA-6> 03petev 07TRUNK * 10emc2/src/emc/motion/usrmotintf.cc: -Cleaned up access to INI file.
[03:38:06] <CIA-6> 03cradek 07TRUNK * 10emc2/src/emc/motion/control.c:
[03:38:06] <CIA-6> turning a jogwheel during a keyboard jog should not increase the
[03:38:06] <CIA-6> velocity for the rest of the jog.
[04:14:00] <skullworks-PGAB> is there a simple method to limit the current available to an H-bridge - other thand a fastblow fuse?
[04:31:04] <CIA-6> 03cradek 07TRUNK * 10emc2/src/emc/motion/ (control.c command.c): fix another runaway due to interaction between jogwheel and jog messages
[04:33:22] <CIA-6> 03cradek 07v2_1_branch * 10emc2/src/emc/motion/ (command.c control.c): backport fixes of interaction between jog wheel and jog messages
[04:45:25] <CIA-6> 03cradek 07v2_1_branch * 10emc2/debian/changelog: another bug squashed
[05:23:47] <skullworks-PGAB> * skullworks-PGAB grumbles about having to reset all the pc clocks...
[05:24:16] <cradek> you and me both
[05:25:41] <skullworks-PGAB> I use XP to play games... Any serious work is still done in W2K or Linux.
[05:26:59] <skullworks-PGAB> M$ says XP sp2, W2003, or Vista get patched - otherwise your SOL
[05:28:54] <skullworks-PGAB> Atleast my EMC2 box gets a pass - it has a dead CMOS backup batt anyway.
[05:30:45] <SWPLinux> http://www.intelliadmin.com
[05:30:59] <SWPLinux> go to downloads, the first one in the free section is a Windows timezone patcher
[05:31:17] <SWPLinux> which works on Win2k (or at least appeared to for me)
[05:31:33] <cradek> there's no microsoft update?
[05:31:42] <SWPLinux> not for 2k, unless you have $4000 sitting around
[05:32:06] <cradek> oh, nice
[05:32:12] <cradek> I had heard that, but figured it was a microsoft-hating rumor
[05:32:15] <SWPLinux> but that's a steal - it covers your whole enterprise
[05:32:28] <SWPLinux> it is in part, but it's true
[05:32:45] <cradek> wonder what percentage of that $4000 goes to ... oh forget it
[05:32:47] <SWPLinux> they're only giving the patch to companies that have long term support contracts, and the minimum cost for that is $4k
[05:33:00] <SWPLinux> so it's not strictly a cost for the patch ...
[05:33:58] <cradek> it's nice to have control of my own computers.
[05:34:11] <SWPLinux> indeed
[05:34:20] <skullworks-PGAB> not sure I would want the M$ monkeys poking around on my corp network... I have friends who work help desk for M$ internal support - they tell me scary stories
[05:34:39] <SWPLinux> even without an official patch, you could still do the updates yourself - on Win or Lin
[05:34:54] <SWPLinux> they have a program called tzedit, which you can use to edit timezones
[05:35:08] <SWPLinux> or is that the Linux program? - I forgot
[05:35:22] <skullworks-PGAB> yeah - but I have to do each box... too many flavors to do a network push
[05:35:27] <cradek> I don't know, but I should probably figure it out pretty soon
[05:35:46] <SWPLinux> the intelliadmin program is very painless - one click
[05:35:59] <skullworks-PGAB> oooh
[05:36:01] <SWPLinux> for Linux systems, there's a timezone compiler I can't remember the name of
[05:38:49] <skullworks-PGAB> * skullworks-PGAB starts looking for a spare USB penn drive...
[05:40:10] <SWPLinux> don' t forget to check your cars, phones, VCRs, and a host of other things (time clocks/punch cards, printers, ...)
[05:40:27] <SWPLinux> and the all-important microwaves/coffee makers
[05:41:56] <skullworks-PGAB> VCR and Microwave have not had he correct time in years
[05:42:49] <skullworks-PGAB> but then the only time I watch TV is after I download a HDTV video torrent...
[06:02:01] <skullworks-PGAB> Oh yeah - its also the recommended date to change out any Smoke or CO detector batteries.
[06:02:42] <cradek> skullworks-PGAB: that's not going to work so well now that standard time only lasts 4 out of 12 months
[06:04:01] <skullworks-PGAB> true - and most devices now tap into wall current
[06:28:22] <jmkasunich> an up-to-date ubunty system should deal with the time change without much trouble, right?
[06:28:27] <SWPLinux> yep
[06:28:33] <SWPLinux> as of last week or so
[06:28:56] <jmkasunich> good
[06:29:05] <Twingy> I've got ubuntu installed now so I can test gcam on it now
[06:29:15] <jmkasunich> well, I saved the best for last... the "update_freq" function
[06:29:38] <jmkasunich> the "pretuned position loop" code is hairy
[06:31:01] <SWPLinux> Twingy: cool. is your system x86, x86_64, something else, SMP ...?
[06:31:23] <Twingy> it's a dell D420 subnotebook
[06:31:26] <Twingy> work compy
[06:31:32] <SWPLinux> ok
[06:31:35] <SWPLinux> what does that mean? ;)
[06:31:55] <Twingy> means I've got a dedicated linux box to test on now instead of just freebsd
[06:31:59] <SWPLinux> heh
[06:32:30] <jmkasunich> a notebook isn't a box
[06:32:39] <SWPLinux> you generally work on bigger iron - I'm assuming the code is (expected to be) 64-bit clean?
[06:36:43] <Twingy> it is
[06:36:54] <SWPLinux> cool
[06:37:15] <SWPLinux> does it take advantage of SMP/multicore?
[06:37:25] <Twingy> nah, no point yet
[06:37:37] <Twingy> my last project was all about high performance/smp
[06:37:46] <Twingy> building my realtime raytracer for the army
[06:37:55] <SWPLinux> very nice :)
[06:37:58] <Twingy> this one is just slow and pedantic
[06:38:24] <Twingy> minimal optimizations have been made thus far
[06:38:37] <Twingy> with the focus on features
[06:38:38] <SWPLinux> the folks at SolidWorks claim that there's no point in making a CAD program multithreaded, beyond separating the UI task from "processing"
[06:38:39] <Twingy> and stability
[06:38:45] <SWPLinux> ok by me
[06:39:11] <Twingy> so long as the interface doesn't encumber the ability to work from small to large scale it's ok by me
[06:39:44] <SWPLinux> right. I'm not sure I can think of any real improvements to be made with SMP - maybe calculating multiple tool passes simultaneously
[06:40:06] <Twingy> you could... but alot of that stuff happens in seconds
[06:40:17] <skullworks-PGAB> Solidworks on a laptop = Catia on a AS400
[06:40:18] <Twingy> and you usually only do it a few times
[06:40:24] <SWPLinux> right - I didn't say it would be a useful optimization ;)
[06:40:39] <Twingy> next release of gcam will have spur gears
[06:41:22] <SWPLinux> jmkasunich: you can check the timezone info by running zdump -v "America/New_York" | grep 2007
[06:41:42] <SWPLinux> you should see Mar 11 and Nov 4 as the changeover dates
[06:41:47] <jmkasunich> or I can wait another 19 minutes and see what happens
[06:41:53] <SWPLinux> crap
[06:42:51] <SWPLinux> Twingy: what's the underlying model engine like? (NURBS, parametric like parasolid, triangles ...)
[06:43:15] <Twingy> right now just lines and arcs
[06:43:22] <SWPLinux> ok - 2.5D?
[06:43:23] <Twingy> I wrote a NURBS modeler a while back called nurbana
[06:43:31] <Twingy> atm, yes 2.5D
[06:43:31] <SWPLinux> heh
[06:43:51] <Twingy> at some point I may throw beziers in b-splines in
[06:43:54] <skullworks-PGAB> I remember hearing about nurbana....
[06:44:04] <Twingy> I don't want it to get too complicated just yet
[06:44:21] <Twingy> needs to stay clean, intuitive, and ellegant
[06:44:39] <SWPLinux> a reasonable goal
[06:44:44] <Twingy> gcam is a walk in the park compared to previous projects
[06:45:07] <Twingy> not like I'm juggle quaternions and udp packet filters
[06:45:33] <SWPLinux> that's - err - good? :)
[06:45:38] <Twingy> jes
[06:45:57] <Twingy> means I can sit down, throw some code in and leave without a headache
[06:46:05] <Twingy> * Twingy crawls off to bed
[06:46:16] <SWPLinux> indeed. good night
[09:31:12] <K`zan> Night folks.
[12:41:14] <jlmjvm> Good Morning All
[12:41:42] <Martin_Lundstrom> Hello folks
[12:41:54] <jlmjvm> Hi
[12:42:31] <jlmjvm> martin:r u from france
[12:43:06] <Martin_Lundstrom> hmm, yes, I live there, but I am swedish
[12:43:12] <Martin_Lundstrom> and U?
[12:43:29] <jlmjvm> us,alabama
[12:44:31] <Rugludallur> Martin: All axis movement is working now with gantry homing and all, starting plasma work now :D
[12:44:39] <Martin_Lundstrom> is jlmjvm your permanebt nick?
[12:45:03] <Martin_Lundstrom> Rugludallur, nice, this will be interesting
[12:45:15] <jlmjvm> yes
[12:45:19] <Rugludallur> Martin: yup, I'm moving/making the ui in pyvcp this time around
[12:46:06] <Martin_Lundstrom> sounds promising
[12:47:17] <Martin_Lundstrom> if you want that breefing on my hack...
[12:47:29] <Rugludallur> Martin: I took a look at your code, M103/M105, that's instructions to move torch down to material and then pierce delay right ?
[12:48:44] <Martin_Lundstrom> kind of, with the help from the hacked HAL timedelay
[12:49:48] <Martin_Lundstrom> there is a fat if clause that will determin state and what to do
[12:50:16] <Martin_Lundstrom> in the hacked timedelay
[13:04:11] <Martin_Lundstrom> M103 to assist M3 and M105 to assist M5
[13:58:04] <Guest856> hello
[13:58:13] <Rugludallur> Is pyvcp labelframe broken atm ?
[13:58:24] <Rugludallur> hello Geust856 :D
[13:58:44] <Rugludallur> err Guest856 :D
[13:58:48] <Guest856> I am not an expert
[13:59:59] <tomp> Rugludallur: i havent updated in a while, what did you see happen?
[14:00:59] <Rugludallur> tomp: labelframes are not rendered from the looks of it
[14:01:16] <Rugludallur> tmop: Tried with the demo from the manual, blanco
[14:02:45] <Rugludallur> tomp: might actually depend on python versions and such, let me make sure everything is up to date before I start whining :P
[14:03:03] <tomp> Rugludallur: well I better clean up the panels I got and move up, pyvcp is my current focus again...
[14:04:52] <Rugludallur> tomp: I'm moving my stuff from vcp to pyvcp today, I will let you know if stumble upon any issues
[14:05:33] <tomp> Rugludallur: thanks, your stuff is always interesting
[14:06:13] <tomp> morning rayh
[14:23:51] <Rugludallur> tomp: same thing :/
[14:44:29] <tomp> Rugludallur: will look after reboot rqd by update. by for now
[15:40:34] <DanielFalck> rayh: good morning
[15:42:09] <rayh> Hi Dan. How's the family?
[15:42:56] <DanielFalck> doing good
[15:43:12] <DanielFalck> Ben is taller than me by an inch
[15:43:34] <DanielFalck> and taking martial arts classes too
[15:43:40] <rayh> I remember the feeling of my first son doing that.
[15:43:46] <DanielFalck> so I better watch out !
[15:43:49] <rayh> Time to stop the spankings.
[15:44:42] <DanielFalck> rayh: I want to set up the gantry for digitizing and have played with halvcp on this workstation
[15:45:04] <rayh> okay.
[15:45:13] <rayh> digitizing using probe?
[15:45:14] <DanielFalck> So, I need to bone up on the Hal stuff. Where should I start?
[15:45:32] <DanielFalck> I will make a probe with a simple switch at first
[15:45:46] <rayh> Sure. That will work.
[15:46:06] <rayh> Just make a grid array of probe points and save em.
[15:46:31] <rayh> Is that a stepper gantry?
[15:46:35] <DanielFalck> So, I'm looking for where to start in the documentation
[15:46:37] <DanielFalck> yes
[15:47:01] <DanielFalck> but I can change it to a servo/step machine pretty quickly
[15:47:21] <rayh> Right. In your case, I'd start by running emc2 using the stepper_inch config.
[15:47:28] <DanielFalck> ok
[15:47:52] <rayh> halshow will help you find your way into it.
[15:48:31] <rayh> I really recommend starting with the hal document, the hal sections of the user doc but with a running hal and halshow.
[15:48:50] <DanielFalck> how do I run halshow?
[15:48:50] <rayh> Hal is self documenting.
[15:49:04] <rayh> From tkemc script menu
[15:49:19] <DanielFalck> ok
[15:49:24] <rayh> axis has it under a menu also.
[15:49:52] <rayh> The halshow tree is pretty self explanitory.
[15:49:55] <DanielFalck> ok, found it under Axis
[15:50:16] <rayh> The tree refresh can be a bit slow.
[15:50:40] <rayh> I'd start by expanding pins
[15:50:48] <rayh> and looking at parport
[15:50:49] <DanielFalck> yes
[15:51:22] <rayh> You're familiar with parport pins so you can quickly grasp how HAL deals with one.
[15:51:30] <DanielFalck> yes, I see it now
[15:52:18] <DanielFalck> looks like pins 10,11,12,13,14,15 all have inputs
[15:52:37] <rayh> Right.
[15:52:51] <rayh> Notice the output pin 2.
[15:53:05] <rayh> 07 bit IN FALSE parport.0.pin-02-out <== Xdir
[15:53:32] <DanielFalck> yes
[15:53:44] <rayh> It's type bit, It is false right now. It's name is parport.0.pin-02.out
[15:53:55] <rayh> Notice the <==
[15:54:11] <rayh> That indicates a link from a signal names Xdir
[15:54:15] <DanielFalck> ok
[15:54:18] <rayh> To that pin.
[15:54:43] <rayh> You can look at signals in the tree, expand x and you'll see what is connected to Xdir.
[15:55:16] <DanielFalck> broachholder.com
[15:55:20] <DanielFalck> whoops
[15:55:39] <DanielFalck> <==stepgen.0.dir
[15:55:53] <rayh> Now suppose that you want to add an experimental signal.
[15:55:59] <DanielFalck> ok
[15:56:11] <rayh> Let's say an external estop button.
[15:56:42] <rayh> you can make a signal named extestop
[15:56:54] <rayh> using the little entry widget below the show tab.
[15:57:11] <rayh> type in newsig extestop bit
[15:57:32] <DanielFalck> while still in signals?
[15:57:34] <rayh> Now if you look under signals in the tree you'll see it there.
[15:57:49] <rayh> halshow is multitasking.
[15:58:05] <DanielFalck> ok, did it
[15:58:13] <rayh> the tree is a passive display that keeps querying the running hal.
[15:58:28] <DanielFalck> it put it under iocontrol
[15:58:30] <rayh> Now let's connect that new signal to a parport in pin.
[15:58:34] <DanielFalck> ok
[15:59:07] <rayh> the command is linksp extestop parport.0.pin-10-in
[15:59:40] <DanielFalck> did it
[15:59:47] <rayh> that is link signal to pin and the signal is extestop and the pin is parport.
[16:00:02] <DanielFalck> got <==parport.0.pin-10-in
[16:00:11] <rayh> Now if you have a breakout board, connect pin ten to a momentary and to ground.
[16:00:29] <rayh> and you can watch that pin change state as you press the momentary.
[16:00:30] <DanielFalck> cool
[16:00:41] <rayh> You've just done your first custom hal.
[16:00:51] <rayh> You can't save it from halshow
[16:00:57] <DanielFalck> I'm not in the shop at the moment, but I will try this today
[16:01:09] <DanielFalck> ok, how do you save it?
[16:01:26] <rayh> but you could add the list of commands you just executed to a .hal file and add it to the end of the list of .hal files to look at during startup.
[16:01:59] <rayh> You can even put dans.hal in the config and in the ini
[16:02:04] <DanielFalck> ok, from the text editor then
[16:02:08] <rayh> sure.
[16:02:41] <rayh> Now to use that external estop is a bit different task.
[16:03:04] <rayh> The way I'd do it is work from a config, demo_step_cl
[16:03:24] <rayh> because that config starts a stepper but adds classic ladder.
[16:03:38] <rayh> The first run of the ladder is estop
[16:04:12] <rayh> The first line of the estop run is internal (emc's estop)
[16:04:29] <rayh> The second run is an external estop.
[16:04:36] <rayh> line not run
[16:05:01] <rayh> If you edit the ladder so that the second line is connected rather than the first you have an external estop button.
[16:06:31] <DanielFalck> ok, now I'm there with demo_step_cl
[16:06:39] <DanielFalck> sorry I was slow getting there
[16:06:42] <rayh> np
[16:07:36] <rayh> You want to look at the "section display."
[16:07:48] <DanielFalck> I see it
[16:08:01] <rayh> Drag emc out of estop and you'll see the ladder show the path.
[16:08:13] <DanielFalck> Is it %|1 that I should connect?
[16:08:21] <DanielFalck> second rung
[16:09:16] <rayh> You can erase the line in front of %1O on the first line
[16:09:20] <rayh> using editor
[16:09:44] <rayh> and put a line in front of %I1
[16:10:15] <rayh> use modify on the window that editor pops up.
[16:10:25] <rayh> click erase
[16:10:44] <DanielFalck> delete current rung?
[16:10:54] <rayh> no.
[16:10:58] <DanielFalck> ok
[16:11:09] <DanielFalck> sorry, I behind on the cl stuff too
[16:11:13] <rayh> modify
[16:11:16] <rayh> no problem.
[16:11:25] <rayh> It took me days to get this far.
[16:12:11] <rayh> erase is the parallelogram to the right of the arrow on that editor screen.
[16:12:35] <rayh> you should see it after you press modify.
[16:12:52] <DanielFalck> so, modify, select the parallelogram, the delete?
[16:13:46] <rayh> Once the eraser is active, move the mouse pointer over the leftmost end of the line on the section display.
[16:14:00] <rayh> and click. the line should go away.
[16:14:06] <tomp> finally caught up with you guys, the parallogram is like a stack of papers , 2nd icon on widget palette
[16:14:17] <rayh> thanks tomp
[16:14:26] <tomp> ok teach!
[16:14:28] <DanielFalck> ok, got it now
[16:14:45] <DanielFalck> while still in 'modify' mode this works
[16:14:54] <rayh> yep
[16:15:07] <DanielFalck> ok, it's done
[16:15:15] <DanielFalck> disconnected anyway
[16:15:18] <rayh> modify also stops the ladder run so you'll see changes in emc
[16:15:37] <rayh> now click the horizontal line button or image in modify
[16:16:05] <rayh> move it to the left of the %I1 contact.
[16:16:13] <rayh> and click the mouse again.
[16:16:20] <DanielFalck> ok, connected
[16:16:24] <tomp> k
[16:17:21] <rayh> Now you'll see that you can not come out of estop.
[16:17:37] <DanielFalck> ah ha!
[16:17:42] <rayh> Now let's look at HAL again using halshow.
[16:17:59] <rayh> pins ->classicladder
[16:18:54] <DanielFalck> I'm running Tkemc here, I see Hal scope and Hal meter under tools
[16:19:00] <rayh> notice that pin 01 is connected to extestop
[16:19:07] <rayh> Right it's under scripts.
[16:19:23] <tomp> k
[16:19:25] <rayh> legacy error or confusion.
[16:19:49] <DanielFalck> ok I'm there
[16:20:23] <tomp> yep
[16:20:28] <rayh> now back to ladder and look for the ladder signal name for the coil pulled in rung 1
[16:20:46] <DanielFalck> %I1
[16:20:49] <rayh> you'll see it's Q0
[16:21:06] <DanielFalck> ok see it
[16:21:06] <rayh> the coil is the rightmost element of a rung.
[16:21:10] <tomp> yep
[16:22:40] <rayh> and back to halshow and we see that Q0 out zero is connected to iocontrol.0.emc-enable-in
[16:22:44] <rayh> That should be good.
[16:23:14] <rayh> Now the only thing we don't know from this is which parport pin %I1 is connected to.
[16:23:23] <rayh> How can we know this?
[16:23:29] <rayh> Test time.
[16:24:44] <rayh> ext-estop
[16:24:44] <rayh> MIN_FERROR = 0.002
[16:24:48] <rayh> oops.
[16:24:56] <rayh> more paste than I wanted.
[16:25:05] <rayh> ext-estop
[16:25:13] <rayh> is the signal we want to see.
[16:25:32] <DanielFalck> sorry, I had switched between Axis and Tkemc somewhere
[16:25:40] <rayh> sure.
[16:25:56] <rayh> demo_step_cl uses tkemc
[16:26:10] <rayh> You could change that in it's ini file.
[16:26:51] <rayh> halshow says signal ext-estop is connected like this.
[16:27:04] <rayh> bit TRUE ext-estop
[16:27:06] <rayh> ==> classicladder.0.in-01
[16:27:08] <rayh> <== parport.0.pin-10-in
[16:27:35] <tomp> k
[16:28:12] <rayh> I interpret this as saying parport.0.pin-10-in is connected to classicladder.0.in-01 using a signal named ext-estop.
[16:28:51] <rayh> so the state of pin 10 has taken the place of EMC's internal estop.
[16:29:24] <DanielFalck> I have a ERROR: duplicate signal 'extestop 'HAL:21: newsig failed
[16:29:35] <DanielFalck> sorry
[16:29:52] <rayh> brb looking for a parport cable
[16:30:19] <tomp> DanielFalck: you got hardware on the parport?
[16:30:37] <DanielFalck> no, this is my 'inside the house' workstation
[16:30:56] <DanielFalck> I have a boatload of boxes in the garage to play with though
[16:31:46] <tomp> i got a parport breakout, buttons & leds, it's handy to follow this with.
[16:33:43] <DanielFalck> ok, I see where we are now
[16:34:59] <DanielFalck> I had pressed return twice while setting up the newsig
[16:37:27] <DanielFalck> be right back
[16:37:50] <tomp> k
[16:39:33] <rayh> back -- got distracted
[16:40:32] <DanielFalck> I'm back
[16:41:28] <DanielFalck> rayh: after doing the modifications to HAL and classicladder, how do you save your changes?
[16:41:30] <rayh> With demo_step you don't need to create an estop signal. I did it for you in the hal file
[16:41:47] <DanielFalck> ok
[16:42:04] <DanielFalck> hence the duplicate error
[16:42:08] <rayh> The only easy way to save is to write out or copy and paste your commands in halshow to a hal file.
[16:42:31] <rayh> and then restart the configuration.
[16:42:52] <rayh> I think there is a way to reload hal but I've not used it.
[16:43:12] <rayh> Now I've got a momentary connected to pin 10 and ground.
[16:43:23] <DanielFalck> Ok, I see it in demo_step_cl.hal
[16:43:41] <tomp> pulled up?
[16:44:07] <rayh> Now back to halshow and click the watch tab
[16:44:23] <rayh> then click on the signal ext-estop
[16:44:35] <rayh> and press the momentary
[16:46:57] <rayh> the "led" should change from yellow to brown.
[16:47:43] <rayh> if it does, move to the ladder view.
[16:48:05] <DanielFalck> I'm running without a par port on this machine in the house
[16:48:14] <DanielFalck> continue on thought
[16:48:17] <DanielFalck> though
[16:48:18] <rayh> okay.
[16:48:49] <rayh> Here I had to click out of the editor in ladder so that my changed wire is put in there.
[16:49:06] <DanielFalck> I'm clicking on the little button in the Vars window to light up the ladder
[16:49:33] <tomp> rayh: exiting does some write?
[16:49:33] <rayh> Now I see the estop momentary affect the rung.
[16:50:49] <rayh> I'm seeing some kind of error here. The momentary signals limit switches as well.
[16:50:50] <anonimasu> hm
[16:52:05] <rayh> ah there it is.
[16:52:07] <rayh> 07 bit OUT FALSE parport.0.pin-10-in-not ==> limit-reached
[16:52:31] <rayh> so pin 10 is doing two things at once.
[16:52:56] <rayh> We could move estop to another pin or remove the limit-reached signal. I'll do that for this test.
[16:53:24] <DanielFalck> got the same error
[16:53:28] <rayh> delsig limit-reached
[16:53:27] <DanielFalck> in HAL
[16:53:42] <rayh> in the entry widget in halshow
[16:53:58] <DanielFalck> ok, that took it out
[16:54:25] <rayh> aha. Now the external button moves emc from an estopped condition to estop reset.
[16:54:39] <rayh> This setup will not turn emc's machine to on.
[16:55:09] <DanielFalck> that's alright though. The operator needs to intervene at this point
[16:55:17] <rayh> So the external button signals an estop but you will have to reset machine on.
[16:55:23] <rayh> You bet.
[16:55:34] <rayh> So that is todays HAL lesson.
[16:55:39] <DanielFalck> operator wakes up from day dream about new bike
[16:55:59] <DanielFalck> thank you Ray! I see how to get started now
[16:56:12] <tomp> thanks ray
[16:56:16] <rayh> With all those fancy titanium parts made in portland;)
[16:56:22] <DanielFalck> yes
[16:56:31] <rayh> Glad you guys followed along.
[16:56:45] <DanielFalck> rayh: I need to set up for digitizing some guitar bodies for Jim
[16:56:49] <rayh> HAL is really a fantastic ability.
[16:56:56] <rayh> Ah okay.
[16:57:04] <DanielFalck> I have the Microscribe arm for Rhino, but I really want to do it all open source
[16:57:08] <rayh> Did he get a router
[16:57:20] <rayh> Sure.
[16:57:21] <DanielFalck> no, he's still doing it all by hand
[16:57:26] <rayh> Okay.
[16:57:33] <DanielFalck> but, this is the first step toward CNC for him
[16:57:39] <DanielFalck> he's jobbing it out
[16:57:40] <rayh> Good.
[16:57:51] <rayh> are you probing z or xy?
[16:57:51] <DanielFalck> so, I'm doing the CAD for him
[16:58:12] <DanielFalck> I really just need to do the outside profile first
[16:58:17] <DanielFalck> then the Z depth stuff
[16:58:18] <rayh> Okay.
[16:58:46] <rayh> He does some pretty fancy curved front guitars, doesn't he?
[16:58:46] <DanielFalck> I checked out the gridprobe.ngc file in examples and it worked with one of the example configs
[16:58:57] <rayh> Great.
[16:59:03] <DanielFalck> most of them are carved tops
[16:59:16] <DanielFalck> but we are trying out some simpler stuff to get started
[16:59:19] <rayh> * rayh adds that to memory. I may not last long but it's there now.
[16:59:48] <rayh> top -- that's the word I was looking for.
[17:00:00] <rayh> Tell him hi from me next time you talk.
[17:00:05] <DanielFalck> ok, will do
[17:00:35] <DanielFalck> I will probably incorporate Varkon into the whole project at some point
[17:00:35] <rayh> One last HAL button thought.
[17:00:44] <DanielFalck> ok
[17:00:44] <rayh> Sure
[17:01:18] <rayh> If you start up halui when HAL starts you have access to lots of the signals we used in the tcl interfaces.
[17:01:35] <rayh> There is one important difference.
[17:01:52] <rayh> for example, program run.
[17:02:07] <rayh> It will work like cycle start the first time you press a button connected to it.
[17:02:25] <rayh> subsequent presses will raise an error message.
[17:02:33] <DanielFalck> really
[17:02:52] <jmkasunich> hey rayh
[17:02:57] <jmkasunich> ;-)
[17:03:01] <rayh> So to do this you'd need to run it through ladder and trap out presses if it's already working.
[17:03:07] <rayh> Hi jmk
[17:03:19] <jmkasunich> got a question about user/operator expectations
[17:03:30] <rayh> okay.
[17:03:46] <jmkasunich> if X is in the middle of a homing sequence, should the operator be allowed to jog Y or Z?
[17:04:24] <rayh> I wouldn't even try it on a machine.
[17:04:29] <DanielFalck> we can home X and Z at the same time on our lathes at work
[17:04:38] <alex_joni> DanielFalck: home 2 at once is easy
[17:04:42] <jmkasunich> homing multiples at once is not a prob
[17:04:43] <rayh> Most controls allow for home home home
[17:04:50] <tomp> like to avoid bumping something he sees while homing?
[17:05:02] <alex_joni> rayh: how about home X, and jog Z in the meantime?
[17:05:10] <DanielFalck> seems like we can do that on Wasino LG8s. I might be wrong though
[17:05:12] <jmkasunich> we basically have three sources for jog type motion - GUI jog commands, the jogwheel, and homing
[17:05:18] <rayh> that is a really scary thought.
[17:05:21] <DanielFalck> yea
[17:05:23] <jmkasunich> and we are trying to deal with some interactions
[17:05:37] <rayh> homing more than one creates a known set of moves.
[17:05:46] <DanielFalck> homing one at a time is better though
[17:05:50] <alex_joni> yeah, but tossing jogging in there leads to chaos
[17:06:08] <rayh> Yes it really does.
[17:06:09] <alex_joni> DanielFalck, rayh: homing one or more than one is already covered very well in emc2
[17:06:22] <jmkasunich> the reason this was never an issue before is that everybody thought like ray: thats scary, I'm not gonna do it
[17:06:24] <alex_joni> the problem is with another source (like a jogwheel) in the equation
[17:06:29] <rayh> Sets my teeth on edge just thinking about the possibility
[17:06:39] <jmkasunich> well, cradek is a good tester - he tried it to see what happened
[17:06:42] <jmkasunich> and it wasn't pretty
[17:06:47] <jmkasunich> so we need to fix it
[17:06:52] <alex_joni> rayh: so I guess your answer is _not_ to allow it ?
[17:06:56] <jmkasunich> one way would be to lock out all jogs if any axis is homing
[17:06:57] <DanielFalck> did he do it on his machine?
[17:07:05] <jmkasunich> yeah
[17:07:09] <alex_joni> DanielFalck: a brave guy
[17:07:11] <DanielFalck> I think it shouldn't be allowed
[17:07:13] <jmkasunich> its a sherline class machine
[17:07:19] <DanielFalck> not so bad then
[17:07:32] <rayh> Perhaps we need a trap in home routines that raises a message "I'm homing, dammit, wait your turn."
[17:07:37] <alex_joni> DanielFalck: I kinda agree it shouldn't be allowed
[17:07:55] <jmkasunich> tomp brought up the only case that might make me hesitate about locking it out
[17:07:59] <cradek> when the end of travel is ten seconds away, it doesn't take much bravery at all
[17:08:00] <roltek> hi guys you talking about homing axis all at once
[17:08:02] <jmkasunich> the "dodge an obstacle" case
[17:08:04] <DanielFalck> I could see a big crash on my mill with that one
[17:08:11] <tomp> if user cabt jog out of danger ( tool coming close to a clamp) what are the options? abort? estop?
[17:08:21] <alex_joni> roltek: no, we're talking about jogging (another axis) while homing one
[17:08:23] <DanielFalck> but if it's a large fast machine, it can be dicey
[17:08:29] <jmkasunich> but the operater is more likely to jog into an obstacle than away from one IMO
[17:08:30] <alex_joni> tomp: yeah, to both
[17:08:34] <tomp> k
[17:08:48] <roltek> very dangerous on big machines
[17:08:59] <alex_joni> roltek: the question is.. is it usually allowed?
[17:09:04] <alex_joni> even if dangerous?
[17:09:09] <roltek> no
[17:09:16] <jmkasunich> I'd suggest that if the operator sees an obstacle, he should hit estop, not try to drive around it
[17:09:22] <DanielFalck> I guess I was thinking about 'homing' two axis at once
[17:09:34] <rayh> If the operator pressed home while x was 20 inches away, I'd be inclined to tell him to abort, jog x and then restart the home routine.
[17:09:40] <alex_joni> jmkasunich: right.. in the time he figures out which way to go it's too late
[17:09:46] <jmkasunich> DanielFalck: we already have good sequencing for multi-axis homes
[17:09:49] <alex_joni> rayh: right, sounds sane
[17:10:07] <tomp> it occurs more with a full workspace, where visibility is limited and the machine was down. maybe allow jogging before home? or fake home? at least let him overrride speed
[17:10:08] <alex_joni> I think we all think jogging while homing shouldn't be allowed
[17:10:12] <jmkasunich> you can say in your config "don't home Z unless X is already homed" or "you can home X and Y at the same time, but not Z"
[17:10:20] <jmkasunich> and all kinds of other variations
[17:10:20] <alex_joni> tomp: jogging before home is allowed
[17:10:24] <roltek> big machines rapid at 3600 inches a min
[17:10:38] <tomp> k didnt know that
[17:10:55] <alex_joni> tomp: some people (with small machines) never home
[17:11:14] <alex_joni> you can tell emc2 to save the position on shutdown, and it'll use that the next time
[17:11:14] <DanielFalck> jogging, before home is good
[17:11:35] <DanielFalck> you might need to get the tool out of a bored hole
[17:11:36] <rayh> IMO the feature of saving position is really dangerous.
[17:12:10] <roltek> you should alwys be able to jog machine around before you home
[17:12:14] <rayh> Even if it is an attempt to match a mach feature.
[17:12:22] <alex_joni> rayh: you need to enable it for it to work
[17:12:31] <alex_joni> when I requested it, I had no idea mach had one
[17:12:48] <rayh> and then that night after the machine is shut down, the janitor spins a wheel.
[17:12:53] <alex_joni> anyways.. back to handling homing, jogging and jogwheel
[17:13:01] <rayh> oh that.
[17:13:17] <alex_joni> rayh: on big machines I would suppose you had brakes when off, and home switches :)
[17:13:33] <DanielFalck> rayh: thanks for the lesson. I'm off to see what I can do in the shop.
[17:13:34] <alex_joni> no need to use the position remember there..
[17:13:36] <jmkasunich> are we all in agreement that from the beginning of a possibly multi-axis homing sequence until the very end, all jogs (wheel and GUI) should be locked out?
[17:13:41] <rayh> Yes and you'd have real feedback and home stuff so saving would be worthless.
[17:13:56] <roltek> if you finish up the day after a tool change when the machine is at home you have to jog it off home and then home machine
[17:14:02] <rayh> I vote for jmkasunich last statement.
[17:14:06] <alex_joni> * alex_joni too
[17:14:11] <jmkasunich> lemme add something:
[17:14:16] <anonimasu> btw, about homing..
[17:14:19] <jmkasunich> are we all in agreement that from the beginning of a possibly multi-axis homing sequence until the very end, all jogs (wheel and GUI) on all axes should be locked out?
[17:14:21] <rayh> Except the abort button.
[17:14:26] <anonimasu> can you home Z first the X and then Y
[17:14:25] <anonimasu> `?
[17:14:42] <rayh> You should be able to anonimasu
[17:14:47] <jmkasunich> anonimasu you can set up all kinds of sequences in the ini file
[17:14:49] <jtr> supporse the operator does try to jog away from a crash? should you put up a message to use estop, or stop the homing process?
[17:14:51] <roltek> how can you jog machine with out jog wheel
[17:15:08] <jmkasunich> roltek: traditional jog commands
[17:15:14] <jmkasunich> keyboard arrows, jog buttons on the gui
[17:15:28] <roltek> real machinist don't use buttons
[17:15:31] <anonimasu> on the real mills you can still jog with the buttons before the homing sequence..
[17:15:44] <jmkasunich> for emc, jogwheel is new, the buttons have been around forever
[17:15:47] <anonimasu> but the jogwheel is locked out until your homed and activate it..
[17:15:58] <alex_joni> anonimasu: not before... during is the question
[17:16:13] <jmkasunich> why locked out before though?
[17:16:16] <rayh> lock out during homing sequences.
[17:16:17] <roltek> that might be but what way are you headed back in the past
[17:16:21] <rayh> Not locked out before.
[17:16:25] <anonimasu> well, you can still jog to the home switches.. manually
[17:16:26] <anonimasu> and still home..
[17:16:30] <jmkasunich> too many people talking at once
[17:16:42] <rayh> * rayh shuts up.
[17:17:01] <jmkasunich> roltek: we're not heading back in the past! EMC used to have jog buttons only, now it has wheels too - that moving forward
[17:17:09] <anonimasu> rayh: yeah while acutally in motion it's locked out..
[17:17:22] <alex_joni> anonimasu: the question was if it's allowed to jog while homing, guess the answer is not
[17:17:30] <roltek> then we have to make the wheels work all the time
[17:17:30] <anonimasu> alex_joni: depends..
[17:17:35] <anonimasu> alex_joni: you can do homing manually
[17:17:49] <jmkasunich> anonimasu I want to talk about why wheels might be locked out (by other controls) prior to homing - we don't do that
[17:17:49] <alex_joni> anonimasu: homing for me is an automatic sequence
[17:17:59] <anonimasu> alex_joni: like push the jog keys until it hits a switch..
[17:18:18] <anonimasu> alex_joni: well, if you push home it'll home..
[17:18:27] <jmkasunich> anonimasu why would you ever do that?
[17:18:30] <anonimasu> alex_joni: it's for avoiding clamps and stuff I think..
[17:18:38] <roltek> true but what do you do if your sitting on the switch
[17:18:53] <alex_joni> roltek: jog out, then home
[17:19:03] <jmkasunich> if you need to avoid stuff, you should jog until you are in the clear and near the switch, then hit home
[17:19:06] <roltek> with a hand wheel
[17:19:14] <anonimasu> roltek: you dont..
[17:19:22] <jmkasunich> wheel or buttons, I don't see any reason we'd enable one and not the other
[17:19:30] <roltek> i do every day
[17:19:42] <jmkasunich> anon says some machines enable the buttons and not the wheel at times, and I'm trying to understand why
[17:19:44] <anonimasu> roltek: well, your setup apparently allows for it to happen
[17:19:53] <anonimasu> jmkasunich: I think it's because handwheel is a toggled function..
[17:20:06] <anonimasu> jmkasunich: that's the only reason I think..
[17:20:19] <jmkasunich> they disable it to prevent a jog if somebody bumps it?
[17:20:48] <jmkasunich> thats reasonable, but it has nothing to do with whether you are homed or not, you might want to disable it later for the same reason
[17:20:54] <rayh> I tend to thing of a "handwheel mode" like manual or auto
[17:20:58] <anonimasu> yeah, but that's done after homing..
[17:21:03] <anonimasu> in the manual mode..
[17:21:07] <rayh> You have to go there before the handwheel is activated.
[17:21:12] <anonimasu> so you cant switch it on until you are homed..
[17:21:26] <jmkasunich> anonimasu I see no reason to prevent wheel mode when not homed
[17:21:30] <anonimasu> agreed
[17:21:47] <jmkasunich> so why are you saying "you can't switch it on unless homed"
[17:21:58] <rayh> I've watched roltek home his mill, He'll handwheel until he's near home position then press the home button for that axis.
[17:22:08] <roltek> handwheel should be in manuaul mode with a switch to tell it what axis it is in plus another switch for what increment
[17:22:22] <anonimasu> jmkasunich: that's how it works on a real control.., perhaps not how it should work in emc..
[17:22:32] <jmkasunich> roltek: thats how our wheels work now
[17:22:53] <roltek> great
[17:22:54] <jmkasunich> anonimasu you mean "thats how it works on a particular real control" roltek has a real control too, and it works different
[17:23:05] <anonimasu> well, the heidenhain's do it that way..
[17:23:33] <anonimasu> I guess you can toggle it to be default on somehow..
[17:23:42] <jmkasunich> unless you say so, we're gonna assume that when you say "a real control does XXX", you mean "EMC should also do XXX"
[17:23:54] <anonimasu> jmkasunich: that's a stupid statement.
[17:23:58] <rayh> one more reason for system wide configuration
[17:24:16] <tomp> the key word was 'manual mode' which is not exactly translatable to emc. in heidenhain, you vant get to manual mode till after homed
[17:24:17] <jmkasunich> anonimasu this is IRC, I can't tell what you are thinking when you make a statement
[17:24:39] <rayh> some integrators want it one way some another.
[17:24:39] <jmkasunich> tomp: that sheds some light on things
[17:24:53] <anonimasu> jmkasunich: I can only say "this is how my machine works", and well, then we can talk about how it should work..(how my machine does it may be wrong)
[17:25:07] <jmkasunich> emc has manual mode, that is the default when you start up
[17:25:16] <anonimasu> :)
[17:25:41] <jmkasunich> anonimasu agreed - but you didn't say anything about how it should work, so I was forced to assume
[17:25:49] <rayh> There is one thing about manual mode before home that is different than manual mode after home -- soft limits
[17:25:59] <anonimasu> yeah
[17:26:10] <jmkasunich> if you said "heid locks out jogs until after homing, and I think that sucks" then I'd know what you were thinking ;-)
[17:26:22] <anonimasu> it locks the joghweel.. not jog :)
[17:26:28] <rayh> A non-homed machine can be commanded past soft limits.
[17:26:33] <rayh> It has to be able to do this.
[17:26:44] <jmkasunich> right, because it has no clue where the soft limits are
[17:26:47] <rayh> In case it was shut down far away from home.
[17:26:58] <anonimasu> well when it hits a limit it'll be homed :)
[17:27:04] <alex_joni> rayh: only if it doesn't remember where it is (j/k)
[17:27:08] <anonimasu> again im only talking about my machine..
[17:27:19] <anonimasu> if you do jog it manually for some reason to a limit switch..
[17:27:35] <alex_joni> anonimasu: it knows when it hits a limit switch and homes the axis?
[17:27:37] <anonimasu> yeah
[17:27:38] <roltek> you can usaully jog it off
[17:27:47] <alex_joni> anonimasu: YUCK!!!!!
[17:27:53] <roltek> an alarm should come up
[17:28:01] <anonimasu> that's in the pre manual mode..
[17:28:12] <roltek> and you can only jog off not past
[17:28:19] <jmkasunich> "pre-manual mode" thats a new one for me ;-)
[17:28:24] <tomp> heid allows jog buttons before home, and respects limits switches (TNC 306 406 & 416 ) these limits are non fatal
[17:28:26] <alex_joni> anonimasu: nevermind the mode, but usually limit switches aren't as accurate as home switches
[17:28:29] <anonimasu> well, "homing mode"
[17:28:39] <anonimasu> you are in reduced speed also..
[17:28:46] <jmkasunich> lets see a show of hands - how many people think EMC should have a pre-manual mode ?
[17:28:48] <rayh> Right. Those abilities to limit jog direction are a thing on the motor drives not a command thing.
[17:28:53] <roltek> correct
[17:28:56] <rayh> yes
[17:29:15] <anonimasu> tomp: yeah
[17:29:31] <tomp> (reading what premanual might mean.... not getting it )
[17:29:41] <anonimasu> it's a mode where you have the jog keys working..
[17:29:48] <alex_joni> anonimasu: so you're saying that after it has hit an limit switch, it gets homed, and you don't need to home it anymore to switch to manual?
[17:29:50] <anonimasu> and a selection for homing X Y or Z
[17:29:52] <rayh> a manual mode before home?
[17:29:57] <anonimasu> yeah
[17:29:57] <jmkasunich> something tells me it would apply from power on until all axes have been homed
[17:30:06] <anonimasu> jmkasunich: that's right
[17:30:21] <alex_joni> anonimasu: so you're saying that after it has hit an limit switch, it gets homed, and you don't need to home it anymore to switch to manual?
[17:30:38] <jmkasunich> and in pre-manual mode, wheel jog is disabled, button jog is at a reduce rate, and the home buttons work, and thats it
[17:30:43] <anonimasu> yeah
[17:30:59] <anonimasu> but this is kind of awkward..
[17:31:00] <rayh> No I
[17:31:02] <rayh> d
[17:31:12] <anonimasu> the limit switches are small blocks where it detects the edge of..
[17:31:15] <rayh> allow for jogwheel or joystick in the pre homed condition.
[17:31:22] <roltek> very awkard
[17:31:23] <alex_joni> anonimasu: that kinda sux.. I assume these machines do homing based on index pulse?
[17:31:36] <alex_joni> then hitting a limit would be way worse in precision
[17:31:43] <anonimasu> alex_joni: yeah but it goes to the very end of each axis first..
[17:31:52] <anonimasu> it's a inductive sensor..
[17:31:55] <jmkasunich> rayh: so far, we're not even sure we want a pre-homed condition, I'm just trying to make sure we all understand what it is on anon's machine
[17:32:13] <rayh> I hear you.
[17:32:15] <anonimasu> alex_joni: it's linear scaled with index pulses..
[17:32:20] <anonimasu> scales..
[17:32:23] <jmkasunich> alex_joni: this silly "home on limit" thing is a bit of a digression I think
[17:32:25] <tomp> alex_joni: it is a 'near home ' switch, the actual mark is on the scale, not the switch
[17:32:26] <jmkasunich> we are NOT going to do that
[17:32:32] <anonimasu> it's probably the wrong thing to call it..
[17:32:48] <anonimasu> but they use the same sensor for homing then it back off to a index..
[17:33:05] <jmkasunich> we can do that too
[17:33:06] <jmkasunich> already
[17:33:13] <anonimasu> I know :)
[17:33:14] <tomp> yes, the sensor is 'near home' , it is not home proper
[17:33:24] <jmkasunich> but what has alex wondering is the idea of homing on any limit any time you hit it
[17:33:34] <anonimasu> ah
[17:33:36] <jmkasunich> rather than one limit (one end of travel) and only when doing a home command
[17:33:49] <alex_joni> jmkasunich: right
[17:34:02] <anonimasu> I "think" they use the other limit switch signal as limit..
[17:34:11] <alex_joni> I assume 3 switches on one axis (min-limit, max-limit and home)
[17:34:16] <alex_joni> and I don't expect them to work the same
[17:34:57] <alex_joni> anonimasu: so I guess they really use only 2, one is shared home and max-limit
[17:35:11] <tomp> the heid swittches are hardlimit- near-home hardlimit+
[17:35:20] <anonimasu> that's right
[17:35:38] <alex_joni> anonimasu: so jogging onto the hardlimit- doesn't 'home' the axis.. right?
[17:35:43] <jmkasunich> as long as the limit isn't going to trip the estop in hardware, you can use one limit as home in emc
[17:35:47] <anonimasu> you probably know more then I do.. I just see one inductive sensor :)
[17:35:56] <jmkasunich> ah, one sensor, two targets
[17:35:56] <anonimasu> alex_joni: thats right
[17:36:05] <anonimasu> yeah
[17:36:10] <alex_joni> anonimasu: that makes more sense
[17:36:22] <jmkasunich> so the machine doesn't know which end of the travel its at when the sensor trips
[17:36:25] <alex_joni> you can easily set it up in emc2 that way too
[17:36:40] <jmkasunich> ok, I think we've settled the limit/home switch thing
[17:36:44] <anonimasu> jmkasunich: you cant end up at a limit without jogging the machine
[17:36:46] <alex_joni> jmkasunich: I think it assumes based on the direction of travel
[17:36:49] <anonimasu> unless you put the lever on there..
[17:36:59] <jmkasunich> lets get back to jogbuttons/jogwheels/homing and what should be locked out when
[17:37:05] <alex_joni> right
[17:37:22] <anonimasu> alex_joni: the only way to get past a limit switch is for the linear encoder to die..
[17:37:23] <jmkasunich> we all agree that all jogs on all axes are locked out when any axis is homing
[17:37:45] <alex_joni> while
[17:38:01] <alex_joni> while any axis is homing (sounds a bit more clear to me)
[17:38:02] <jmkasunich> ?
[17:38:03] <jmkasunich> ok
[17:38:10] <jmkasunich> we all agree that all jogs on all axes are locked out while any axis is homing
[17:38:15] <jmkasunich> true?
[17:38:24] <tomp> yes for me
[17:38:26] <anonimasu> jmkasunich: you mean "in motion"
[17:38:29] <rayh> yep
[17:38:33] <anonimasu> agreed
[17:38:34] <jmkasunich> no, I mean "homing"
[17:38:41] <anonimasu> oh, then I dont..
[17:38:50] <jmkasunich> there are short pauses after hitting a switch, before backing off to find the index, etc
[17:38:56] <jmkasunich> don't want a jog in there either
[17:39:00] <anonimasu> no
[17:39:14] <anonimasu> before I push the "auto home" button I want to be able to jog
[17:39:21] <jmkasunich> homing starts when you hit the home button, and ends when the axis is homed
[17:39:26] <anonimasu> ok
[17:39:31] <anonimasu> if that's the case I agree
[17:39:32] <alex_joni> between those two there are a dozen states
[17:39:36] <jmkasunich> before you push the home button, you aren't homing, you are in manual
[17:39:40] <anonimasu> yeah
[17:40:07] <alex_joni> * alex_joni agrees with jmk's above statement too
[17:40:13] <anonimasu> I agree
[17:40:15] <jmkasunich> ain't communication fun...
[17:40:29] <alex_joni> good thing I started coding 20 minutes ago :P
[17:40:29] <roltek> and the jog or handwheel should work then
[17:40:37] <jmkasunich> I see what you were thinking - the heid comes up in "homing" mode, right?
[17:40:42] <anonimasu> yeah
[17:40:54] <anonimasu> you can only go to a home(limit) and the machine homes automatically or push auto to home it..
[17:41:14] <anonimasu> that's homing mode :)
[17:41:23] <jmkasunich> understood
[17:41:27] <rayh> Good jog steering that discusion guys.
[17:41:43] <anonimasu> btw, did you look at the tuxcnc stuff?(offtopic)
[17:42:04] <jmkasunich> emc comes up in manual, and you can push the home button to start a home sequence - the sequence ends with the axis in home position, and the machine is still in manual
[17:42:09] <roltek> rayh you in a better mood now
[17:42:18] <jmkasunich> during the sequence, we're going to lock out jogs
[17:42:23] <rayh> meaner'n hell
[17:42:32] <roltek> good
[17:42:38] <jmkasunich> now - what about mixing jog buttons and wheels?
[17:42:44] <rayh> You get figured out the motor problem, roltek
[17:42:57] <jmkasunich> if you are wheeling X, you should be able to button jog Y probably
[17:43:05] <roltek> not yet but will
[17:43:14] <rayh> good.
[17:43:15] <jmkasunich> if you are wheeling X, should you be able to button jog X? or vice versa?
[17:43:32] <tomp> no 2 drivers for 1 car
[17:43:36] <anonimasu> yeah
[17:43:46] <rayh> If you need, I can set up a parallel mesa system here. Take a while though.
[17:43:51] <anonimasu> but one thing needs to take precendence over the other
[17:44:03] <alex_joni> anonimasu: the first one active
[17:44:12] <alex_joni> after it finished the other one can work too
[17:44:24] <tomp> heid stops motion when 2 commoand go to 1 axis ( like x+ & x- siimultaneous )
[17:44:36] <jmkasunich> they cancel each other out
[17:44:40] <tomp> or x + and wheel
[17:44:41] <anonimasu> tomp: I've yet to try the jogwheel on motion :)
[17:44:51] <roltek> i had my jog wheel go out lately if you jog button also amchine goes down
[17:45:12] <jmkasunich> cradek fixed a couple nasty bugs that happened if you wheel and jog at the same time
[17:45:29] <jmkasunich> but we realised this morning that its bigger - like the jog X while homing Y thing
[17:46:16] <jmkasunich> so we want to figure out the "Right Thing" to do and then go in the -dev channel and figure out how to do it
[17:47:22] <tomp> i guess one controlER (button mdi wheel ) per axis is ok, and independant
[17:47:42] <tomp> never 2 controlERs per axis
[17:47:55] <jmkasunich> yeah
[17:48:06] <anonimasu> also, I think heid has the switch on the jog wheels because they ripple when you've got them activated.. and in manual..
[17:48:08] <jmkasunich> the trick is dealing with timing and race conditions - who gets there first
[17:48:30] <jmkasunich> most critical is not losing a "jog button release" message
[17:48:56] <anonimasu> jmkasunich: dosent that solve the issue?
[17:49:07] <a-l-p-h-a> when I was woking up... I had a dream. I had a dream...
[17:49:08] <anonimasu> jmkasunich: the wheel wont give data when not rotating..
[17:49:08] <jmkasunich> doesn't what solve the issue?
[17:49:18] <a-l-p-h-a> I had a dream that all my brothers and sisters, of all race and color...
[17:49:25] <a-l-p-h-a> or something to that effect...
[17:49:27] <anonimasu> while the button can stick the wheel cant..
[17:49:32] <jmkasunich> a-l-p-h-a: hush
[17:49:43] <a-l-p-h-a> anyways... I was thinking how do I calculate a nesting problem for bar stock.
[17:50:14] <jmkasunich> the bug that cradek found was: start button jog, then spin wheel and release button jog while wheel is turning - wheel jog causes button release message to be lost
[17:50:32] <jmkasunich> jog keeps going even after wheel stops
[17:50:46] <tomp> jmkasunich: wheel should have been ignored
[17:50:54] <jmkasunich> right
[17:50:58] <anonimasu> agreed
[17:51:10] <jmkasunich> I think we now know what it should do, we just gotta make it do that
[17:51:16] <jmkasunich> thanks guys
[17:51:16] <anonimasu> :)
[17:51:20] <tomp> thank you
[17:51:24] <anonimasu> jmkasunich: sorry about confusing you
[17:52:00] <tomp> i had a gui btn and a real button, a gui led and a real led.
[17:52:02] <tomp> i had no success getting >either< button to change >both< leds.
[17:52:09] <tomp> Some signals always got disconnected when a subsequent linkxx was executed.
[17:52:17] <tomp> So, I'm not clear on the rule set concerning assignment ( like how many elements on a net, and what happens when a previously used signal/pin is used again)
[17:53:10] <tomp> this was in pyvcp (doh!)
[17:53:26] <jmkasunich> tomp: only one thing can drive a signal
[17:53:51] <jmkasunich> so you can connect the real button and have it drive both leds, or you can connect the GUI one and have it drive both LEDs
[17:54:01] <jmkasunich> if you want both to drive the leds, you need some logic
[17:54:16] <jmkasunich> OR gate, AND gage, ladder rung
[17:54:17] <jmkasunich> your choice
[17:54:33] <jmkasunich> HAL has the gates already
[17:54:38] <tomp> ok, so i treid or2's and got the diconnected signals
[17:54:55] <jmkasunich> pastebin your "show sig"
[17:55:00] <tomp> i'll pastbin em
[17:55:27] <tomp> it'll be a while, i just re-upped cvs
[17:55:38] <tomp> thanks
[18:00:48] <tomp> it'll be a long while....
[18:33:34] <jepler> tomp:
[18:33:32] <jepler> # make sure you 'loadrt or count=1' and 'addf' the function!
[18:33:33] <jepler> net button1 vcp.button => or.0.in-0
[18:33:33] <jepler> net button2 hardware.button => or.0.in-1
[18:33:33] <jepler> net led or.0.out => vcp.led hardware.led
[18:35:17] <tomp> i did loadrt or2 count=2 and is there a funct for the the or2?
[18:36:28] <tomp> i got 'exported functs' 06 e0cfc180 e0f3a1b0 NO 0 or2.0 06 e0cfc180 e0f3a1c0 NO 0 or2.1
[18:37:08] <alex_joni> tomp: that's correct
[18:37:11] <tomp> but also some time params for the ors
[18:37:14] <jepler> yes, looks like the function to update or.0.out is 'or2.0'
[18:37:16] <alex_joni> the function is called or2.0 and or2.1
[18:37:33] <alex_joni> one for each OR2 gate
[18:38:00] <tomp> right, the functs are automaticly added, do i need to concern with the time params?
[18:39:23] <alex_joni> you need to add them to a thread
[18:39:30] <alex_joni> addf or2.0 servo-thread
[18:39:34] <alex_joni> addf or2.1 servo-thread
[18:40:03] <tomp> doh!
[18:40:12] <tomp> thanks alex!
[18:40:36] <jepler> the 'time' and 'tmax' parameters are informational, you usually don't need to pay any attention to them
[18:41:09] <tomp> jepler: thanks, just a screw loose on this side of the operator panel ;)
[18:54:50] <tomp> halcmd show --> http://pastebin.ca/390864 hal file -----> http://pastebin.ca/390867
[18:55:49] <tomp> tho hal shows pins and signals connected, the original pin ( no biblical reference ) will change state, but the connected pin will not
[18:57:17] <tomp> the gui xml http://pastebin.ca/390872
[19:56:50] <tomp> once i did what jepler said to do it worked fine. i never saw more than 3 elements in a net before
[20:09:10] <CIA-6> 03jmkasunich 07TRUNK * 10emc2/src/emc/motion/control.c: comment the behavior of do_homing_sequence() so us slow people can follow it
[20:12:50] <CIA-6> 03jmkasunich 07TRUNK * 10emc2/src/emc/motion/control.c: meaningless comment and format tweak
[20:15:27] <tomp> # the 'net' format requires a named signal, it must be 1st,
[20:15:37] <tomp> # and the ==> is not neccesary,
[20:15:46] <tomp> # everything after the 1st arg are pins that are shorted together
[20:15:52] <tomp> # the order of arg 2 thru n is not important
[20:17:08] <jmkasunich> tomp: yep
[20:17:27] <tomp> thanks, this is a nice app
[20:52:56] <xemet> hi
[20:53:24] <xemet> I don't succeed in using the manual tool change feature in AXIS
[20:53:44] <xemet> it works with the sim configuration available in the tree
[20:53:59] <jepler> that's all I've used it with either
[20:54:16] <xemet> I copied the axis_manualtoolchange.hal in the directiry where I've my configuration file
[20:54:26] <xemet> added it in my ini file
[20:54:28] <jepler> what behavior do you get?
[20:54:45] <xemet> added in my ini file the line with the tool change position
[20:54:46] <jepler> [EMCIO]
[20:54:49] <jepler> TOOL_CHANGE_POSITION = 0 0 2
[20:55:06] <xemet> added, at the end, after the tooltable file
[20:55:12] <jepler> did you add something like this to your ini as well, to specify the location to move to when changing tools?
[20:55:45] <xemet> yes, copied the line from the axis.ini in the sim directory and added it in my ini file
[20:56:17] <xemet> when I launch axis, the small windows about the manual tool change opens
[20:56:39] <xemet> but If I type M6 T1 in the MDI, nothing happens
[20:56:52] <xemet> if I type T1
[20:57:09] <xemet> and after, M6, it says that it needs tool Txx prepared
[20:57:21] <alex_joni> do you have the loopbacks?
[20:57:32] <alex_joni> xemet: you need 2 loopbacks for toolchanging to work
[20:57:45] <xemet> do you intend those in the axismanualtoolchange.hal
[20:57:44] <alex_joni> they are in manualtoolchange.hal
[20:57:57] <alex_joni> yeah, but usually in the normal halfile aswell
[20:58:07] <jepler> net hal_manualtoolchange.change iocontrol.0.tool-change => hal_manualtoolchange.change
[20:58:10] <xemet> I've added it in my directory and in my ini file
[20:58:10] <jepler> net hal_manualtoolchange.changed hal_manualtoolchange.changed => iocontrol.0.tool-changed
[20:58:13] <jepler> net hal_manualtoolchange.number iocontrol.0.tool-prep-number => hal_manualtoolchange.number
[20:58:13] <alex_joni> standard_pinout.hal
[20:58:16] <jepler> net iocontrol.0.tool-prepare iocontrol.0.tool-prepare => iocontrol.0.tool-prepared
[20:58:19] <jepler> these are the nets you should end up with
[20:59:24] <xemet> well, I think those are in the axis_manualtoolchange.hal file that is used in the sim configuration
[21:08:57] <xemet_> http://www.pastebin.ca/391023 .ini file
[21:09:41] <alex_joni> xemet_: lets see MiniMillpinout.hal
[21:09:51] <xemet_> http://www.pastebin.ca/391024 axis_manualtoolchange.hal
[21:10:45] <xemet_> http://www.pastebin.ca/391026 pinout
[21:10:51] <jepler> xemet_: show us the output of 'halcmd save netla | grep tool' to make sure the pins are hooked up as expected
[21:11:55] <CIA-6> 03alex_joni 07TRUNK * 10emc2/src/emc/motion/ (command.c control.c mot_priv.h motion.c motion.h): add free_tp_source to make a difference between jog, jogwheel and homing all driving the same free TP. this way one cannot jog while homing, but it should also catch any problems (runaway jogs and such)
[21:12:08] <xemet_> ok wait a moment
[21:12:38] <xemet_> I'm using the lates development version run in place, is it influent?
[21:13:43] <jepler> not that I know fo
[21:13:44] <jepler> of
[21:14:01] <danielbr> hello guys
[21:14:50] <xemet> hello
[21:16:54] <xemet_> jepler: sorry, where should I type the command you gave to me?
[21:17:19] <danielbr> i can't find some halui pin for "home all" when using axis and home sequence
[21:17:39] <danielbr> for do that i using classicladder
[21:17:49] <xemet_> daniel: I think that there is no pin for home all
[21:18:03] <xemet_> danile: I was searching for it too yesterday
[21:18:07] <jepler> xemet_: at the shell prompt
[21:18:21] <xemet_> jepler: without emc running?
[21:18:25] <jepler> witk it running
[21:18:59] <xemet_> ok
[21:19:34] <danielbr> a halui pin for home all will be great
[21:20:26] <xemet_> jpler: sorry, how I get the halcmd prompt while emc is running?
[21:20:53] <jepler> xemet_: many different ways. One is to just open another terminal
[21:21:25] <xemet> done...
[21:22:10] <CIA-6> 03cradek 07TRUNK * 10emc2/src/emc/motion/control.c: only update the target if it's safe for the jogwheel to take control
[21:23:45] <xemet_> http://www.pastebin.ca/391037 ...trying to get halcmd prompt
[21:24:01] <alex_joni> xemet_: bin/halcmd
[21:24:05] <alex_joni> not halcmd
[21:24:14] <xemet_> ok!
[21:24:52] <jepler> yes, when using run-in-place you have two choices: always use a path to the commands, or always use ". scripts/emc-environment" once per shell session
[21:25:09] <xemet_> understood
[21:25:09] <jepler> I always say "halcmd", not "bin/halcmd"
[21:25:30] <xemet_> ok , I was not thinking about the fact I was using the run in place
[21:27:29] <xemet_> http://www.pastebin.ca/391044 I think this is the output
[21:28:15] <jepler> 15:58:06 <jepler> net iocontrol.0.tool-prepare iocontrol.0.tool-prepare => iocontrol.0.tool-prepared
[21:28:24] <jepler> I don't see the "prepare" loopback
[21:28:54] <alex_joni> net hal_manualtoolchange.number iocontrol.0.tool-prep-number => hal_manualtoolchange.number
[21:29:12] <xemet_> I try to add it
[21:29:38] <xemet_> uhm...just for curiosity, why it works in the sim configuration?
[21:30:23] <alex_joni> xemet_: no, that was from your file
[21:31:15] <xemet_> hum...this line:
[21:31:17] <xemet_> linkpp hal_manualtoolchange.number iocontrol.0.tool-prep-number
[21:31:37] <xemet_> *is* in the axis_manualtoolchange.hal file
[21:32:15] <jepler> 16:28:16 <jepler> 15:58:06 <jepler> net iocontrol.0.tool-prepare iocontrol.0.tool-prepare => iocontrol.0.tool-prepared
[21:32:38] <jepler> alex_joni confused things by mentioning the tool-prep-number
[21:33:04] <xemet_> ah! yes sorry, now I see it
[21:33:14] <jepler> tool changing has two steps: preparing the tool (e.g., turning a tool carousel to the right position) and actually transferring it to the spindle
[21:33:31] <jepler> iocontrol.0.tool-prepare => iocontrol.0.tool-prepared makes the request to prepare the tool always finish right away
[21:33:51] <xemet_> of course
[21:34:32] <alex_joni> xemet_: the linkpp iocontrol.0.tool-prepare iocontrol.0.tool-prepared is usually in the standard_pinout.hal
[21:35:13] <xemet_> ah! now I understand...I copied the file axis_manualtoolchange, but don't cared about the pinout
[21:35:15] <danielbr> jepler: when will be possible emc2 use fixed rack for toll change?
[21:35:40] <jepler> danielbr: I don't know anyone who is planning to add that feature.
[21:35:56] <alex_joni> what's fixed rack for tool change?
[21:36:27] <alex_joni> a shelf with various positions for the individual tools?
[21:36:30] <CIA-6> 03cradek 07TRUNK * 10emc2/src/emc/motion/control.c: don't allow jogwheel while homing
[21:36:45] <danielbr> alex yes
[21:36:46] <tomp> tools in a solid row of position, chuck has to go grab them, tool id is alligned to position
[21:37:05] <xemet_> now it works! thank you
[21:37:15] <danielbr> this is very good for little machines
[21:37:19] <jepler> xemet_: yay
[21:37:19] <tomp> very inexpensive tool changer
[21:37:21] <alex_joni> danielbr: it might be possible to change emc2 to do so, but you need a bit of coding skills
[21:37:49] <alex_joni> as it is now, it's not supported
[21:37:48] <danielbr> i don't have these skills
[21:38:27] <alex_joni> danielbr: then I guess you might try to submit a feature request
[21:38:36] <alex_joni> and one day it might get added :)
[21:38:44] <xemet> about that, but currently you have a fixed position for toolchange using the manualtoolchange
[21:39:14] <tomp> if the ini file ToolChangePosition and ToolHolderClear could be written during the program executuion, then the tool prep for tool N would get the positions for tool n and transfer them to the variables ToolChangePosition & ToolHolderClear ( but they are not variables :(
[21:39:55] <xemet> to use this rack would be sufficient to have more tool change positions?
[21:40:29] <tomp> yes... the sacrifice is the machine tool must go fetch each one ( grab drop raise etc... )
[21:40:38] <alex_joni> xemet: yeah
[21:40:48] <tomp> slow but cheap
[21:41:05] <tomp> also sacrifice a bit of table space
[21:42:47] <xemet> is it so difficult to change the the code in order to specify one tool change position for every tool? for example in the tbl file?
[21:43:02] <alex_joni> xemet: not that dificult, only quite a bit of work
[21:43:18] <alex_joni> if you know your way around the code, then I guess less than a day
[21:43:21] <alex_joni> including testing
[21:43:36] <alex_joni> if you don't ... then it can be more than a week :D
[21:44:51] <xemet> yes...I can imagine...after working on the nurbs code
[21:46:00] <danielbr> xemet: io sono grato
[21:47:55] <xemet> daniel: sei italiano?
[21:48:01] <danielbr> brasiliano
[21:48:30] <xemet> daniel: beatiful!
[21:48:57] <alex_joni> xemet: have you ever seen him? :P
[21:49:04] <tomp> an interesting rack tool changer: it is concealed until wanted ( notice lid... the rack seems to pop up ) http://www.datrondynamics.com/options.htm#anchorATM
[21:49:45] <xemet> brasil is beatiful...
[21:49:49] <xemet> :P
[21:50:36] <danielbr> yes so much problems but beatiful
[21:52:38] <xemet> daniel: I'm from sicily...a lot of problems here too but beautiful
[21:53:07] <alex_joni> xemet: as long as you don't end up having horses heads in your bed it's perfect
[21:53:06] <alex_joni> :P
[21:53:17] <xemet> yes...
[21:53:31] <alex_joni> I know I enjoyed it a lot
[21:53:42] <alex_joni> Siracuse I mean
[21:55:18] <xemet> I know
[21:56:42] <danielbr> my descendance is 50% italian(veneto) 50% germany
[21:57:10] <xemet> at phone
[21:57:19] <xemet> I'm
[22:06:42] <alex_joni> danielbr: so you speak some german ?
[22:06:59] <danielbr> no alex
[22:07:37] <alex_joni> schade :)
[22:07:49] <alex_joni> * alex_joni heads to bed
[22:07:51] <alex_joni> good night all
[22:08:08] <tomp> nite alex
[22:08:12] <danielbr> good nigth
[22:08:30] <danielbr> bbl
[22:08:35] <xemet> night
[22:08:55] <danielbr> night
[22:12:34] <tomp> nite all
[22:12:41] <CIA-6> 03cradek 07v2_1_branch * 10emc2/src/emc/motion/ (motion.h motion.c mot_priv.h control.c command.c): backport free mode planner fixes
[22:21:10] <anonimasu> hmm, toolchanging is a mess..
[22:21:15] <anonimasu> mechanically
[22:23:48] <CIA-6> 03cradek 07v2_1_branch * 10emc2/debian/changelog: backport alex's more comprehensive fixes to free mode planning
[22:25:30] <robin_sz> http://www.quacky.co.uk/~robin/Bike/img001.jpeg
[22:25:32] <robin_sz> mmm shiny"
[22:25:45] <robin_sz> I spenmt half the afternoon polishing it :)
[22:53:05] <CIA-6> 03cradek 07TRUNK * 10emc2/src/emc/motion/control.c: fix race condition that allowed runaway
[22:53:31] <CIA-6> 03cradek 07v2_1_branch * 10emc2/src/emc/motion/control.c: fix race condition that allowed runaway
[22:58:13] <robin_sz> "ooooh, shes a little runaway .."
[23:15:44] <robin_sz> coo, Brad Delp is dead :(
[23:15:46] <robin_sz> ho hum
[23:16:07] <cradek> whozzat?
[23:16:46] <ejholmgren> a little young for that bike?
[23:17:22] <robin_sz> ejholmgren, who me?
[23:17:23] <robin_sz> young?
[23:17:44] <ejholmgren> kid looking out the doorway ;)
[23:17:48] <robin_sz> oh him :)
[23:18:12] <robin_sz> mmm ... hes been on it once :)
[23:18:24] <cradek> haha
[23:19:07] <robin_sz> you know .. Boston, great music ... but ...
[23:19:27] <robin_sz> well, when you see the video, you can;t help thiking you are watching Spinal Tap :)
[23:19:28] <robin_sz> http://www.youtube.com/watch?v=UFwIgbyrNhw
[23:19:59] <robin_sz> the drummer in the "caveman" outfit, the moustaches, the hair. the lycra bodysuits!
[23:20:12] <robin_sz> hilarious, but sounded good :)