Back
[00:02:01] <jmkasunich> troubleshooting a bad limit switch (or sensor) means you answer these questions (by testing and measuring things with meters, etc)
[00:02:08] <jmkasunich> 1) does the sensor work
[00:02:36] <jmkasunich> 2) is the sensor signal getting to the terminals of the PC (use a real electrical meter and measure the voltage - it should change when the sensor is triggered)
[00:02:46] <jmkasunich> 3) is the signal getting into HAL (use halmeter)
[00:02:56] <jmkasunich> 4) is the polarity of the sensor right (use halmeter)
[00:03:17] <jmkasunich> 5) is the signal getting through HAL to the motion controller (use halmeter on the motion controller pins)
[00:03:18] <jmkasunich> etc
[00:03:31] <jmkasunich> step by step, follow the signal from its source
[00:03:51] <bob> the change of "in-not" for "in", decided the problem pparently
[00:03:56] <jmkasunich> good
[00:04:06] <bob> tanks...
[00:05:31] <bob> plus a box of beer... :)
[00:11:53] <skunkworks> bob: your english is getting better :) (I have trouble with just one language)
[00:12:25] <skunkworks> never mind ;)
[00:14:41] <fenn> wow.. remember when computers were simple?
http://www.kare.com/images/portfolio_5.gif
[00:15:13] <fenn> * fenn wonders if anyone else here ever used a mac plus
[00:15:31] <tomp_> xerox-park
[00:15:54] <skunkworks> nope. never really a mac person. Didn't they copy microsofts interface? ;)
[00:16:23] <tomp_> macs got the user interface from xerox-park
[00:17:04] <tomp_> parc
[00:19:24] <fenn> all the mac stuff is sorta burned into my memory because i was like 4 years old and already hacking on the finder
[00:19:55] <fenn> back in the days before internet
[00:20:18] <tomp_> but not arpanet :)
[00:21:01] <ds3> finder? mac? Mmmmm res-edit... ;)
[00:21:09] <tomp_> the built in toolbox was nice, tho they wanted to program in pascal on the mac
[00:21:37] <tomp_> res-edit, yeh, fiddle with the resources w/o messing the code
[00:21:48] <fenn> ds3: did you ever install the "secret button" on the side that gets you into a command line?
[00:22:25] <ds3> fenn: wasn't "my" mac; was the schools but didn't some of them come with the programmer button? seem to recall the SE30's I was using had that button
[00:24:00] <fenn> there was a plastic piece that came with the computer and you had to slide it into a sort of slot on the side of the case
[00:24:19] <ds3> could be someone else before me did that
[01:15:19] <Jymmmm> G3's have a "programmers button" right next to the reset button on the front.
[01:26:09] <fenn> they also have an xterm, so it doesnt really matter
[01:43:46] <ds3> anyone tried the caelinux livedvd?
[01:53:54] <jepler> real arcspiral vs simulated:
http://axis.unpy.net/01169689661
[01:57:15] <Jymmmm> very cool
[01:59:58] <skunkworks> that is just neet
[02:00:04] <skunkworks> neat
[02:01:18] <jepler> thank you
[02:02:58] <skunkworks> http://www.electronicsam.com/images/KandT/cncworkshop/spiralarc.JPG
[02:03:07] <skunkworks> hot off the press
[02:05:26] <fenn> have you thought about doing an animation?
[02:06:47] <cradek> jepler: cool
[02:09:15] <skunkworks> fenn: good idea. that would be cool
[02:10:17] <cradek> with enough patience I suppose you could generate a picture for each line of gcode
[02:10:21] <fenn> i think it would be possible to do a live preview in axis, showing how much material was taken off for each pass with color coding or something
[02:11:45] <fenn> it wouldnt prevent the stupid mistakes, but it could prevent some preventable mistakes :D
[02:14:44] <jepler> fenn: in principle I think I can detect the volume of material removed every second or inch, as well as the greatest height of material removed
[02:14:53] <jepler> cradek and I talked about that today
[02:15:26] <fenn> yes and then color the triangles with the volume removed
[02:15:30] <cradek> I think per tooth is the interesting number, and you have enough information to know it
[02:15:33] <fenn> per unit time
[02:15:36] <fenn> or per tooth
[02:15:38] <fenn> or both
[02:16:02] <fenn> there's three color channels to play with after all
[02:16:05] <fenn> r g b
[02:17:35] <fenn> if you wrapped the Z map around a cylinder could this work as a lathe preview? or am i missing something important?
[02:19:11] <jepler> sure, it probably could
[02:22:18] <cradek> threads would be a little more complicated than normal
[02:23:15] <fenn> nah
[02:23:28] <fenn> x becomes z, z becomes y, c becomes x
[02:23:46] <fenn> oh
[02:23:55] <fenn> i still think that spindles should count as a rotary axis
[02:30:41] <ds3> if you can detect the volume of material removed, why not also compute the HP required to run the cut?
[02:32:28] <fenn> if axis plots feedback data from motion it should be able to get spindle position too
[02:33:21] <fenn> ds3: depends on materials, tool angles, lubrication, tool sharpness, etc..
[02:33:31] <fenn> you can make a lot of assumptions though
[02:33:46] <fenn> so there's no reason why not really
[02:36:17] <ds3> but an absolute min should be computeable
[02:36:31] <ds3> and if my spindle is less then that, I have no chance of making the cut
[02:36:43] <fenn> i'd be more interested in "will this snap off the tool"
[02:37:01] <fenn> and have it cowardly refuse to do the move if so :D
[02:37:08] <ds3> stalling a Haas minimill spindle leaves a strong impression =)
[02:37:56] <fenn> if you had a spindle position or speed sensor you could limit the cut rate to xx feed per rev
[02:38:11] <fenn> theoretically
[02:39:04] <ds3> but that isn't sufficient as DoC has a major effect along with the tool used
[02:40:17] <fenn> hmm
[02:40:29] <ds3> those corn cob ones really help when hogging
[02:40:42] <fenn> depth of cut requires a solid model of the stock, but feed per rev doesn't
[02:41:34] <ds3> ain't easy but just the volume of material remove can get a ball park HP figure
[02:42:09] <fenn> yeah you're talking about preventing programming errors, i'm takling bout realtime adaptive feed
[02:42:44] <ds3> closer to generating a sanity checklist
[02:44:19] <fenn> wonder if you can compare predicted spindle torque with measured spindle torque and detect a broken or worn tool
[02:44:32] <fenn> or other problems
[02:44:51] <ds3> should be able to do
[02:45:16] <SWPadnos> only if you have a load sensor, of course
[02:45:18] <ds3> or something primative like spindle motor drive current vs is material being cut or not
[02:45:44] <fenn> you could get the current from the drive maybe
[02:46:02] <SWPadnos> yep - that's one way
[02:46:14] <SWPadnos> if you can get that ...
[02:46:28] <ds3> easy enough to add one either half effect + AD or sense resistor or sense coil
[02:46:28] <fenn> or stick a hall sensor on the power rail :D
[02:47:08] <SWPadnos> heh
[02:47:14] <fenn> how come emc has no university engineering departments throwing talent and money at us?
[02:47:34] <SWPadnos> that's your job - go find some engineering department or university for funding!
[02:47:51] <fenn> they wont answer any of my email :(
[02:47:57] <SWPadnos> bastiges
[04:03:20] <Twingy> new gcam release tomorrow I think
[04:05:17] <cradek> Twingy: cool - did you decide to integrate that patch from jepler (for support of ubuntu)?
[04:05:40] <cradek> I haven't played with it yet but I saw some screenshots - it looks very promising
[04:06:16] <Twingy> It was a bit more complicated than the patch
[04:06:38] <Twingy> gcam still *requires* gtk 2.10 or higher
[04:06:46] <cradek> ok, I don't know the issues - but I did see him running it on ubuntu6
[04:06:54] <Twingy> I suppose I could add some fu to make it 2.8 compatible *grumble*
[04:08:17] <cradek> I sympathize with you but I'd also like for emc users to be able to run it easily
[04:08:22] <cradek> could one of us help you do whatever work is needed?
[04:10:10] <Twingy> it's really just 5 minutes to the build system and a #if
[04:10:57] <cradek> cool, we all appreciate it
[04:11:02] <Twingy> sure thing
[04:34:30] <tomp_> test panel for m5i20, work in progress, has spcl btns for pins of I/O type, built for .hal pins obtained from trunk's config dir for m5i20
http://imagebin.org/7000
[04:36:27] <tomp_> pyvcp_widgets.py with new checkbtns for pins of type i/o
[04:36:29] <tomp_> http://pastebin.ca/327678
[04:38:16] <tomp_> (prev was xml, here's the code)
http://pastebin.ca/327679
[05:23:44] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/docs/man/man9/threads.9: new man page
[05:25:31] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/debian/emc2.files.in: backport: new man page
[05:25:30] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/docs/man/man9/threads.9: backport: new man page
[05:25:36] <jmkasunich> goodnight
[06:06:25] <A-L-P-H-A> lerneaen_hydra?
[06:18:32] <A-L-P-H-A> buahahhahah.
http://www.shof.msrcsites.co.uk/durex.jpg
[06:22:53] <K`zan> Night all
[07:24:51] <alex_joni> morning
[07:49:30] <ds3> morning
[07:50:10] <ds3> is there a easy way to get EMC to step a stepper X steps and then run an external app/script?
[07:53:09] <fenn> g91 g1 x 42
[07:53:15] <fenn> M101
[07:53:23] <fenn> rename your script to M101 and put it in nc_files
[07:53:41] <fenn> where 42 is the distance you want to move
[08:08:11] <ds3> so the script can be say a /bin/sh script?
[08:10:37] <ds3> n/m found the sample file
[08:15:28] <ds3> nice...so I am all set to drive/test some tiny steppers with 4 transistors on the parallel port
[08:21:44] <A-L-P-H-A> hey
[08:22:03] <A-L-P-H-A> ds3? isolated optical switches too?? :D
[08:28:28] <A-L-P-H-A> ds3? does it spin? :)
[09:02:59] <ds3> no
[09:03:00] <anonimasu> hm
[09:03:20] <ds3> want to do try something and was thinking of the quickest way of doing it
[09:09:03] <Jymmm> ds3 explosives
[09:18:13] <paragon36> Morning...
[09:19:51] <A-L-P-H-A> sup?
[09:20:51] <paragon36> Not a lot just started work. How you doing?
[09:21:10] <A-L-P-H-A> are you trying to pick me up?
[09:21:38] <A-L-P-H-A> Joey from friends? "How U do'n?"
[09:21:46] <paragon36> LOL .....
[09:21:53] <paragon36> :-)
[09:35:50] <anonimasu> :)
[09:35:55] <anonimasu> what's up?
[09:36:01] <anonimasu> I've ordered new gears for my z
[10:33:35] <A-L-P-H-A> anonimasu, what kind?
[10:33:40] <A-L-P-H-A> how's it going to work?
[10:33:54] <A-L-P-H-A> are you moving the knee? or the head?
[11:05:16] <anonimasu> knee...
[11:05:24] <anonimasu> A-L-P-H-A: why wouldnt it work?
[11:05:25] <anonimasu> I need more accel that's all
[11:05:33] <anonimasu> and my stepper is just going 500rpm
[11:11:05] <anonimasu> looking at the graph I should be able to gear it 8:1 instad
[11:11:07] <anonimasu> instead
[11:15:06] <alex_joni> anonimasu: figured it out last night?
[11:15:18] <anonimasu> alex_joni: it worked, but not when I tried today..
[11:15:22] <anonimasu> alex_joni: I
[11:15:27] <anonimasu> I'm going too fast :)
[11:15:35] <anonimasu> with too much accel..
[11:15:42] <anonimasu> I need more gearing
[11:15:55] <anonimasu> the PID_MAX_VEL pushes the machine too far
[11:16:33] <anonimasu> im not entirely sure it works ..
[11:16:41] <anonimasu> it fscked up when trying some at lunch..
[11:16:46] <anonimasu> so I'll have a look when I get home
[11:17:10] <alex_joni> how about making PID_MAX_VEL equal MAX_VEL ?
[11:17:15] <alex_joni> or close :)
[11:17:23] <anonimasu> yeah, really close..
[11:17:27] <anonimasu> it's 7 and 8
[11:17:35] <alex_joni> closer
[11:17:38] <alex_joni> that's more than 12%
[11:17:43] <anonimasu> does it respect the accel's when catching up?
[11:17:45] <alex_joni> 7 and 7.1
[11:17:48] <alex_joni> yeah
[11:17:50] <anonimasu> hm odd..
[11:17:58] <alex_joni> you'll get ferrors if it can't keep up
[11:18:00] <anonimasu> yeah
[11:18:19] <anonimasu> I need gearing
[11:18:22] <anonimasu> my Z is so slow..
[11:18:29] <anonimasu> I need 1/3g or something
[11:18:38] <anonimasu> the other axes are fast enough..
[12:21:07] <erDiZz> hello everyone
[12:28:03] <A-L-P-H-A> hey
[12:41:10] <alex_joni> hi
[13:10:09] <Dallur> hey
[14:23:17] <betchin> Hi, is there a channel about cnc machines in general somewhere?
[14:26:38] <Dallur> not to my knowledge, but there is always cnczone forums
[14:28:03] <betchin> yea know about those, but just wondered if there was a irc channel connected to that
[14:28:52] <cradek> betchin: on irc, this is probably the closest you will find - we aren't picky about what people talk about here, since we have another channel just for EMC development
[14:29:51] <betchin> mmkay, good to know
[15:04:05] <anonimasu> hm, this channel is probably that
[15:04:10] <anonimasu> though emc angled :D
[15:05:17] <alex_joni> yeah, but people talk about Haas, Fanuc, Mazak once in a while..
[15:06:58] <Dallur> we also tend to talk about plenty of hardware :D
[15:09:16] <erDiZz> that's it. I'm here not because of emc, but cus there's not too much places...
[15:09:53] <alex_joni> there are no reasons not to use emc .. so we try to convert people that come in here:)
[15:10:30] <erDiZz> great. I'm working on another system, so :)
[15:11:15] <alex_joni> you shall see the light
[15:11:38] <erDiZz> alex_joni, why should I?
[15:11:39] <Dallur> alex_joni should have been a preacher
[15:12:14] <alex_joni> erDiZz: the main goal in life is to improve things, and emc does that :)
[15:12:36] <erDiZz> I'm trying to improve things as well
[15:12:41] <erDiZz> emc is not the only way
[15:13:19] <alex_joni> agreed, not the only way.. but the best one :D
[15:13:24] <alex_joni> erDiZz: just kidding..
[15:13:54] <erDiZz> alex_joni, np, I second that at the moment
[15:14:22] <alex_joni> erDiZz: :)
[15:14:46] <alex_joni> emc is getting better (has been getting better for the last 10? years)..
[15:15:27] <erDiZz> alex_joni, I was positng at emc mailing list about my project
[15:15:51] <alex_joni> erDiZz: XXYZ ?
[15:16:10] <erDiZz> it's mync.sourceforge.net
[15:16:31] <alex_joni> oh, you're the guy from russia :)
[15:16:38] <erDiZz> hi there :)
[15:16:40] <alex_joni> nice work :D
[15:16:48] <alex_joni> * alex_joni is not very far from you
[15:16:49] <erDiZz> in progress, though
[15:17:04] <alex_joni> geographically speaking
[15:17:08] <erDiZz> where?
[15:17:14] <alex_joni> romania
[15:17:19] <erDiZz> oh
[15:17:21] <erDiZz> pretty close
[15:17:28] <alex_joni> 1 TZ away
[15:22:24] <rayh> My mini-itx board just forgot it is supposed to boot up when power is applied.
[15:23:13] <Dallur> ray: bios battery dead ?
[15:23:42] <rayh> I guess that kills off the idea that I could get away with embedding it and not having a power on switch.
[15:24:08] <Dallur> rayh: Isn't it just a bios setting that got cleared ?
[15:24:49] <rayh> Yes.
[15:25:23] <rayh> But if I hide the PC in a box inside a control cabnet and this happens, the whole machine is dead.
[15:26:11] <Dallur> rayh: if it's an ATX motherboard you could always just short the pins permanently :D
[15:26:36] <Dallur> rah: it's the green wire, just pull it to ground permanently
[15:26:42] <alex_joni> hmm.. then you can't turn it off
[15:26:57] <alex_joni> or is it supposed to be always up?
[15:27:05] <rayh> I tried that and it shut the machine back down after a timeout.
[15:27:43] <Dallur> rayh: what you probably shorted was the "power button" pins on the motherboard, i'm not talking about those, im talking about the "power on" wires for the power supply
[15:28:43] <rayh> Isn't turning on and off power a bit drastic?
[15:28:51] <cradek> I sure miss the AT power supplies that had a big toggle switch
[15:29:40] <cradek> all that soft power switch stuff is a curse
[15:31:15] <rayh> Yes I do miss the really old stuff like the TRS-80's power switch.
[15:34:12] <cradek> you don't have to go back too far - before ATX virtually all PCs had real power switches
[15:34:48] <cradek> when the power goes off here at work, some random machines always require playing with both switches (front and back) before they'll come back on
[15:35:03] <cradek> (even if the BIOS is set to come on after power fail)
[15:36:59] <alex_joni> bbl
[15:37:05] <Dallur> when we get linuxbios on all machines it help us get out of this mess though
[15:49:48] <rayh> Wah! That was wierd. It was the mesa 5i20 holding it off.
[15:51:04] <rayh> Either that or the PCI riser card. Time for more testing.
[16:01:12] <cradek> maybe something has a power line shorted
[16:03:04] <ChrisSmol> at an old job we had a few dells where the power control circuit on the mobo somehow got fried
[16:07:21] <rayh> I really don't know what happened but it's back to life, including the mesa card.
[16:08:03] <rayh> Think it could be the fact that the mesa is just sitting in the slot. Gravity hold down.
[17:06:51] <alex_joni> Dallur: does linuxbios work Ok?
[17:10:11] <SWPadnos> depends on your chipset, from what I've read
[17:12:48] <alex_joni> interesting
[17:33:26] <jepler> I've been working on syntax highlighting in vim for .hal files. WIP:
http://emergent.unpy.net/files/sandbox/syntax-for-hal.png
[17:33:52] <SWPadnos> nice
[17:34:16] <SWPadnos> is the configuration an xml file like kate and gedit?
[17:35:30] <jepler> of course not
[17:35:33] <jepler> it's in a godawful scripting language
[17:35:46] <SWPadnos> heh
[17:36:12] <SWPadnos> I guess we need an XML1 <-> XML2 <-> godawful scripting language converter :)
[17:36:24] <SWPadnos> (since the XML formats for kate and gedit aren't the same, I think)
[17:36:56] <SWPadnos> 454.30
[17:37:00] <SWPadnos> ack
[17:37:41] <alex_joni> 908.60
[17:37:59] <SWPadnos> no. obviously that's way too high
[17:38:24] <alex_joni> 227.15
[17:38:44] <SWPadnos> probably a few samples from now
[17:42:19] <rayh> Hi Jeff. I got some highlighting running in gedit yesterday.
[17:49:59] <tomp_> where is 'net' cmd documented/talked about ? (replacement for linksp linkps linkpp )
[17:51:50] <rayh> The man page for halcmd.
[17:51:58] <tomp_> thanks
[17:52:03] <tomp_> (doh!)
[17:53:49] <rayh> np. Even the hal doc refers to it rather than explaining it.
[18:26:42] <alex_joni> friend
[18:26:49] <alex_joni> wat is folowing error?
[18:27:17] <SWPadnos> u r 2 n00b 2 no
[18:27:55] <alex_joni> how do I get axis out of "nan" position?
[18:28:16] <alex_joni> I searched the manual..
[18:28:34] <cradek> oh good grief, please stop
[18:28:41] <alex_joni> sorry :x
[18:29:09] <cradek> try homing again :-)
[18:29:32] <alex_joni> cradek: nope, won't work until I get the proper HOME position
[18:29:49] <alex_joni> SWPadnos: now you know why one of your clients dies when the other is ok
[18:31:55] <SWPadnos> your PUMA robot?
[18:31:59] <SWPadnos> is that what's doing it
[18:32:06] <alex_joni> no.. you're on different servers
[18:32:17] <SWPadnos> intelesting
[18:32:22] <alex_joni> :P
[18:33:25] <alex_joni> the math in there is awfull
[18:38:45] <tomp_> unregistered, hello
[18:49:36] <awallin> hi all, what's up?
[18:50:18] <alex_joni> * alex_joni is fighting some kins
[18:50:26] <Dallur> hey, not much, crunching on the objects, finished reading that paper on relational geometry
[18:51:08] <awallin> Dallur: I got some interesting bits of code for Z-slicing, i.e. input an STL model, and it will output a slice at a certain Z-level
[18:51:31] <awallin> if this can be visualized somehow in python I would probably have time to run some tests during the weekend
[18:52:20] <awallin> Dallur: did you look into drawing with vtk or pyopengl? or are you still using vpython
[18:52:39] <Dallur> awallin: at the moment im not drawing anything, just printing and doing automatic testing
[18:54:29] <awallin> ok.
[18:54:30] <Dallur> awallin: There are still plenty of methods which I have to implement before I get to the visualization, I still have not done any rotational stuff and input verifiction (automatic casting) is what I am working on
[18:55:30] <Dallur> awallin: so you can create a polyline object directly from a list of values, or you can pass a bunch of point objects or you can use the points from an existing curve (kinda crazy)
[18:56:03] <awallin> oh, ok.
[18:56:29] <Dallur> awallin: I changed all the terminology to match the stuff from that paper, except my primitive is still primitive
[18:57:13] <awallin> do remember that aerohydro has patents on these ideas, but maybe iceland doesn't do software patents!
[18:57:27] <Dallur> awallin: no software patents here :D so i'm fine
[18:57:49] <Dallur> awallin: in any case the part they seem to have patents on is all with surfaces and it's kinda dumb anyway
[18:58:54] <awallin> I will try to get some UI+rendering going during the weekend...
[18:59:04] <Dallur> awallin: what they do is enable you to create any object so that it is relational to another object (you can create a curve on a surface which then is bound to that surface)
[18:59:49] <tomp_> should linking a new signal to an existing pin break any previous connections to that pin? ( eg: linkpp fred ethel, newsig ricky, linksp ricky ethel causes the link fred ethel to dissappear)
[18:59:59] <Dallur> awallin: but an evern smarter way to deal with that issue is to split the surface into many surfaces and have them intersect with the curve, if you use the same point objects to define both it works even better
[19:00:47] <Dallur> awallin: then you just define a group to contain the surfaces and you can manipulate them as one entity
[19:01:16] <alex_joni> tomp_: yes
[19:01:25] <awallin> Dallur: maybe, but that involves a lot of re-calculation if the user decides to move the curve on the surface?
[19:01:25] <alex_joni> tomp_: that's how it's done
[19:02:05] <alex_joni> tomp_: otherwise you'd have more than one writer
[19:02:25] <cradek> I think it could sure be argued that it should throw an error instead
[19:02:34] <alex_joni> cradek: :D
[19:02:46] <Dallur> awallin: yes, during the modeling but you save a lot of calc. during rendering
[19:03:26] <Dallur> awallin: and the calculations aren't that intensive really because you still use the same objects to define the surfaces so changing the object in one surface changes it in the other
[19:04:32] <Dallur> brb, need more coffee
[19:08:01] <tomp_> alex_joni: then i dont understand a pin of type "IO", (from halcmd show pin 07 bit I/O FALSE m5i20.0.watchdog-reset)
[19:08:14] <alex_joni> IO is bidirectional
[19:08:33] <alex_joni> you can have a writer and an IO on the same signal
[19:08:39] <alex_joni> and a couple of readers
[19:08:50] <tomp_> but not 2 writers
[19:08:52] <tomp_> ?
[19:09:13] <alex_joni> nope
[19:09:22] <tomp_> thanks
[19:09:22] <SWPadnos> wait one: you can't have a writer and an IO on the same signal
[19:09:23] <alex_joni> you can have 2 IO's
[19:09:39] <alex_joni> SWPadnos: right.. two IO's :)
[19:09:58] <SWPadnos> any signal can have as many readers as you want, plus either one writer *or* as many IOs as you want
[19:14:35] <jepler> the rule against having an OUT and an I/O on the same signal has only recently been enforced
[19:15:18] <tomp_> then what is "O" about an IO pin? can it emit True or False?
[19:15:43] <alex_joni> input / output
[19:15:50] <alex_joni> aka bidirectional
[19:16:15] <tomp_> O makes it a writer
[19:16:46] <alex_joni> something like that
[19:17:00] <tomp_> then it cant be connected to another writer
[19:17:20] <tomp_> i need an example
[19:18:49] <tomp_> sorry, been poking at this for a bit & it was a catch 22 in my mind, please an example anyone, use of an IOpin tied to an input signal
[19:19:07] <jepler> among other things, I/O pins are used for the index pulse
[19:19:23] <jepler> the quadrature decoder has an I/O pin called 'index-enable'
[19:19:40] <tomp_> i think thats the specific use in the new m5i20 pyvcp panel...
[19:19:50] <tomp_> what i'm working on
[19:19:57] <jepler> when the index behavior is desired, another I/O pin on the signal sets the signal to TRUE. when the index pulse is seen by the quadrature decoder, the quadrature decoder sets the signal to FALSE
[19:20:09] <jepler> both pins read and write the signal
[19:20:14] <tomp_> right
[19:20:46] <tomp_> io connected to io
[19:21:41] <jepler> an IN pin will just see whatever value was last placed on the signal by one of the IO pins
[19:22:04] <SWPadnos> a writer is expected to refresh its outputs every cycle (whatever that cycle time is, like BASE_PERIOD or whatever)
[19:22:25] <SWPadnos> an IO isused for something like a handshake, where one component wants another to do something and signal when it's done
[19:22:44] <tomp_> yes, the halpin is in the update() method, run every 100ms
[19:23:43] <SWPadnos> for the encoders, the "reset on index" needs to be IO because motion wants to tell the driver "wait for an index pulse, reset your position to 0 when it's detected, and reset this pin to 0 when you've done that"
[19:25:41] <jepler> I doubt that scoping watchdog-reset or displaying it on a vcp will show anything useful -- if it's like the other watchdog I looked at (motenc?) it will always read 0 even if it is working properly (because it is reset to 0 every time the m5i20 function runs in its thread)
[19:28:08] <tomp_> i'm looking at the visual metaphor for an IO pin: could it be a button that set the IO pin, and looked depressed, but an external data src could release it ?
[19:28:26] <SWPadnos> sure
[19:28:54] <jepler> that was basically what I suggested the other day with butt-ons and butt-offs
[19:29:12] <tomp_> but it went wild blinky on me :)
[19:29:22] <SWPadnos> tomp_, it can also be a button that changes color to indicate the pin state, and only writes a value when depressed
[19:30:08] <SWPadnos> the value to write would be defined in the xml file, since most IO pins have one component that would write a 1 and another that would write 0
[19:30:18] <tomp_> the pic is on
http://imagebin.org/7000
[19:30:34] <SWPadnos> (ie, motion will only set the index_reset_enable to 1, and the encoder driver will only reset it to 0)
[19:31:20] <tomp_> the code & xml was posted last nite, obviously wrong, i get the idea, now have to find the difference between my code & what you said :)
[19:32:11] <jepler> unlike for OUT signals, you shouldn't write a value every 100ms
[19:32:15] <jepler> I think
[19:32:33] <SWPadnos> that's correct
[19:33:01] <SWPadnos> though you could possibly refresh as long as the button is held down (in the case where the button color indicates pin state rather than button position)
[19:33:31] <tomp_> too busy? i thought this was like a plc, maybe 20 or 40ms, or do you mean event driven instead of time driven
[19:34:27] <SWPadnos> it's not a matter of computing load, it's just not the right thing to do for an IO pin :)
[19:35:28] <SWPadnos> IO pins are likje tristate - they act like inputs (or like they're not there) until something internal to the component decides that it should write a value to the pin
[19:38:23] <tomp_> IO pin is a monitor with a flag , usually reports, sometimes alerts
[19:38:58] <SWPadnos> sure
[19:39:09] <tomp_> thanks
[19:39:14] <cradek> imagine you and I take turns at something by flipping a switch - when it's my turn you flip it up, when I'm done I flip it down
[19:39:26] <cradek> this only works if one of us isn't leaning on the switch all the time
[19:39:34] <SWPadnos> wow - nice analogy
[19:39:49] <alex_joni> * alex_joni puts a pin in your switch
[19:39:57] <tomp_> thus not good to update all the time
[19:40:09] <tomp_> walkie talkie
[19:40:14] <SWPadnos> yes. a writer is always leaning on the switch
[19:40:22] <SWPadnos> a reader just look at it
[19:40:24] <SWPadnos> looks
[19:40:59] <alex_joni> walkie talkie is also a nice analogy
[19:41:22] <tomp_> or skype :)
[19:41:35] <alex_joni> no, skype is duplex
[19:42:40] <tomp_> well, i get the idea from the swx flipping, thanks
[20:47:16] <SWPadnos> http://freaky.thehappening.org/src-images/computers-down.jpg
[20:47:41] <Dallur> lol
[20:52:25] <lerneaen_hydra> 'lo all
[20:56:28] <Dallur> awallin/anonimasu: if you want to check out the object model you can get it at
http://pastebin.ca/328473
[20:57:04] <Dallur> awallin: it has some sample calculations which I use to "regression test" which should give you an idea of what I am thinking
[21:03:52] <fjungclaus-away> fjungclaus-away is now known as fjungclaus
[21:09:10] <robin_sz> meep?
[21:09:50] <Dallur> hmmf, meep sounds like a sound made by a roadkill just before it became a roadkill
[21:10:05] <robin_sz> about right
[21:10:26] <robin_sz> its supposed to be the noise made by some small rodent, like hamster
[21:10:46] <Dallur> robin_sz: big eyes, big light, empty stare ........
[21:11:56] <robin_sz> youve met my wife then?
[21:11:58] <alex_joni> big splash?
[21:12:42] <Dallur> no comment
[21:12:56] <robin_sz> so ... this guy I know asked if he could borrow my pressbrake and operator for an hour or so
[21:13:58] <robin_sz> turns out they have made a special bending fixture for some company thats supposed to be making a bit for the Airbus amd these guys need to test the fixture ...
[21:14:20] <robin_sz> OK, no problem I said ... about a dozen of them turned up and stayed the entire afternoon
[21:14:55] <alex_joni> heh
[21:15:10] <robin_sz> ever heard of "rolla V tooling"?
[21:16:37] <robin_sz> http://www.rolla-v.com/video/video1.avi?SessionID=8c478ea9a6443d56210baba1d3f04f7d
[21:16:42] <robin_sz> liek that
[21:17:15] <robin_sz> nice technology
[21:17:25] <Dallur> hmm some silly codec I don't have :P
[21:17:41] <robin_sz> works ok on Debian and firefox
[21:18:13] <Dallur> robin_sz: failed on vnc/ubuntu and im to lazy to fix it
[21:19:55] <robin_sz> ok, imagine a press ... the upper tool is a normal 90 degree V
[21:20:05] <robin_sz> the lower tool is not a V
[21:20:48] <Dallur> so it makes a \_/ form ?
[21:20:50] <robin_sz> its two D shaped blocks of steel, in semi-circular grooves ... the D is pointing down so the flat bits are on top
[21:21:05] <robin_sz> umm mor like UU
[21:21:30] <alex_joni> that looks like a butt
[21:21:34] <robin_sz> the metal sits across the top .. as the press comes down ... it goes down in the middle and the blocks rotate
[21:21:51] <robin_sz> ends up as a V ...
[21:22:00] <Dallur> ahh
[21:22:18] <robin_sz> but .. there is no sliding action of the metal against the block liek normal presswork
[21:22:28] <robin_sz> it rotates and folows the metal , see?
[21:22:52] <robin_sz> think of it as a 180 degree V ending up as a 90 degree V
[21:24:59] <robin_sz> anyway ... I had a guessat how much a 400mm lenght of this stuff was ...
[21:25:06] <robin_sz> I guessed £800
[21:25:45] <robin_sz> I was a bit out :(
[21:26:05] <robin_sz> £2600
[21:37:08] <alex_joni> night all
[21:41:19] <Dallur> night alex
[22:57:33] <mtedad> hello, hello
[22:58:36] <mtedad> need more info on calibrating an axis?
[22:59:05] <mtedad> servo type.
[23:01:19] <SWPLinux> ok -what's the problem?
[23:05:25] <mtedad> i think ive got the raw cunts right. I call to move +1 inch an it does to within 2 tenths. when I MOVE BACK TO ZERO it say zero on the axis readout but my indicator shows at - 5 thou.
[23:05:36] <mtedad> countsthat is
[23:06:20] <fenn> :D
[23:06:45] <SWPLinux> sounds like backlash then
[23:07:09] <SWPLinux> is the raw_count value from the encoder at 0 (+/- 1)?
[23:07:46] <fenn> can you wiggle it back and forth and get a reading on the dial?
[23:07:55] <mtedad> encoder not at zero.
[23:09:28] <mtedad> wiggling against servo. there is some backlash.
[23:11:42] <mtedad> can back lash be comp out.
[23:12:08] <fenn> yes, but it can't be trusted really
[23:13:36] <Guest469> Guest469 is now known as skunkworks
[23:44:26] <fenn> pretty weird that someone went and made another rt linux cnc control
[23:47:48] <erDiZz> fenn, what's that weird in that?
[23:49:05] <fenn> oh you're still here
[23:49:51] <erDiZz> fenn, yep. it's only 2:49 MSK :)
[23:51:36] <fenn> erDiZz: i've thought about forking/rewriting emc before, but in the end there wasn't really any reason to do so
[23:51:45] <erDiZz> well
[23:51:55] <fenn> erDiZz: so i'm curious why you basically duplicated the same functionality
[23:52:37] <erDiZz> fenn, I wasn't really going to at the beginning
[23:53:04] <erDiZz> but it grown into something larger, so I eventually ended up developing a self-contained cnc system
[23:53:57] <erDiZz> later I've read that EMC code's licensing and IP is not that clear
[23:54:07] <erDiZz> is there any truth in this?
[23:54:08] <fenn> where did you read that?
[23:54:18] <erDiZz> fenn, at EMC web page, I guess
[23:54:38] <erDiZz> there was the reasoning that it's because a lot of people at NIST were working on that
[23:54:43] <erDiZz> so it is hard to trace the roots
[23:54:51] <fenn> it is probably some drama caused by a devel who got upset and left a while ago
[23:54:55] <SWPadnos> the NIST code is public domain, so it has no restrictions
[23:55:11] <SWPadnos> all other code is either GPL or LGPL
[23:55:35] <erDiZz> ok, I'll try to find that statement again to show you...
[23:55:56] <fenn> i think alex went through all the code files and verified their license status
[23:56:55] <SWPadnos> erDiZz, thanks. I'd like to either correct the page where you found that information, or correct the file(s) in question
[23:57:51] <erDiZz> I think it's this:
http://www.tuxcnc.org/pivot/entry.php?id=5#body
[23:57:58] <erDiZz> Due to the adhoc development of RCSlib and EMC over the year, some of the sources are GPL, others, a "not for commercial use", and a few, copyright of "XXXX" without any attendant license (It must be assumed "proprietory & restricted"). The remainder or the code is public domain - Anyone contemplating using the code for anything other than personal use needs to do a complete and full audit.
[23:58:03] <fenn> there was some concern about GPL "infecting" various LGPL libraries, but i'm not terribly concerned about that
[23:58:15] <erDiZz> fenn, and what about "non-commercial"?
[23:58:39] <fenn> that's FUD, and has no merit, otherwise he'd simply state what the files were
[23:58:59] <fenn> i dont understand why he's doing it either
