Back
[00:10:48] <toastydeath> OR DOES IT
[00:11:27] <toastydeath> does/is
[00:20:14] <jmkasunich> lash issues would be no worse than index with a switch
[00:20:25] <jmkasunich> (you must always start on the same side of the index pulse in either case)
[00:20:46] <jmkasunich> aliasing, yes, if the operator sets it in the wrong place he can wind up off by one turn of the screw
[00:30:45] <ds2> eh?
[00:31:06] <ds2> isn't a switch typically located on the slide/table where as the encoder on the screw?
[00:31:06] <jmkasunich> eh?
[00:31:13] <jmkasunich> yes
[00:31:37] <ds2> so if the screw has lash, the switch will do the right thing but the encoder won't
[00:31:50] <ds2> or have I missed some other subtly?
[00:32:04] <jmkasunich> the homing move is made in only one direction, so lash will be taken out
[00:32:15] <ds2> ah
[00:32:18] <jmkasunich> in general, an index pulse is MORE accurate than a switch
[00:32:52] <jmkasunich> very few switches are better than a couple thou repeatablilty, an index pulse is accurate to one count which could be 0.0001
[00:33:02] <ds2> so by that line of reasoning, if I just attach a photo sensor + a disc w/1 hole to the back side of my steppers, I would have a better homing system then with switches?
[00:33:13] <jmkasunich> no
[00:33:22] <ds2> what's the difference?
[00:33:58] <jmkasunich> if you have a 2000 line per rev (8000 count per rev) encoder, the index line is exactly 1 count wide
[00:34:30] <jmkasunich> if you make a "index" with a hole and an opto-detector, it is NOT going to be accurate to 1/8000 of a revolution
[00:34:46] <ds2> why can't I key it off the leading edge of the pulse?
[00:35:52] <jmkasunich> because a homemade index doesn't have an "edge", it has a "ramp"
[00:36:14] <jmkasunich> as your hole moves in front of your sensor, the light gradually gets brighter
[00:36:22] <jmkasunich> at some point the sensor says "ok, its on now"
[00:36:28] <jmkasunich> but that won't be very accurate
[00:36:34] <jmkasunich> a real encoder has a precision mask
[00:36:50] <ds2> okay, I'll throw in a comparator to trip it at a known point on the ramp
[00:36:50] <jmkasunich> the light _still_ doesn't go from off to on over zero distance, its still a ramp
[00:37:01] <jmkasunich> but it ramps up over about 1/8000 of a turn
[00:38:15] <jmkasunich> there is a whole list of things you can do that affect the accuracy
[00:38:29] <jmkasunich> make the ramp steeper, trigger at a precise level on the ramp, etc
[00:38:34] <ds2> but I think I see what you are pointing out
[00:38:55] <jmkasunich> the encoder folks get paid good money to do all those things
[00:39:34] <jmkasunich> you could eventually approach or maybe even beat their accuracy, but by that time, you aren't using a simple hole and sensor anymore - you've re-invented a good encoder index
[00:41:36] <ds2> *nod*
[00:59:12] <toastydeath> pew pew pew
[01:04:05] <toastydeath> i was also thinking about getting an interferometer beampath tattoo
[01:04:43] <toastydeath> i don't know if i'll get it
[02:11:03] <Skullworks-PGAB> JMK - US digital came out with another "budget" encoder - the E7P
[02:11:26] <Skullworks-PGAB> but no index :(
[02:12:47] <Skullworks-PGAB> the E4P was cheap but had a max of 300 line - this new one goes up to like 1350 IIRC
[02:30:34] <tomp2> alex_joni: I think 'Hektor' is a bit like your tripodkins , but uses gravity replace the 3rd strut.
http://www.hektor.ch/ . Do you think tripodkins would work for controlling a hektor device?
[03:21:51] <maddash_> maddash_ is now known as sudo_maddash
[03:22:08] <sudo_maddash> hi ho
[03:22:15] <maddash> sudo_maddash: hey.
[03:22:43] <sudo_maddash> maddash: how's the patient doing?
[03:22:59] <cradek> -!- maddash is now known as wtf_maddash
[03:23:12] <sudo_maddash> :(
[03:23:19] <maddash> er, I mean, :(
[03:29:51] <maddash> #include\
[03:29:51] <maddash> <stdio.h>
[03:29:51] <maddash> #include <stdlib.h>
[03:29:51] <maddash> #include <string.h>
[03:30:24] <maddash> :(
[03:30:32] <maddash> #include\
[03:30:32] <maddash> <stdio.h>
[03:30:32] <maddash> #include <stdlib.h>
[03:30:32] <maddash> #include <string.h>
[03:30:32] <maddash> #define w "Hk~HdA=Jk|Jk~LSyL[{M[wMcxNksNss:"
[03:34:08] <maddash> #include <stdio.h>
[03:34:10] <maddash> char *p="#include <stdio.h>%cchar *p=%c%s%c;main(){printf(p,10,34,p,34,10);}%c";main(){printf(p,10,34,p,34,10);}
[03:34:33] <maddash> i think that's the most trivial
[03:38:01] <ds2> whoa
[03:39:29] <maddash> :P
[06:23:29] <alex_joni> tomp2: sure it would
[06:23:50] <alex_joni> you could even have a third strut pulling it down, to take care of bouncing which is hektor's problem
[09:03:05] <x3rox> For designing my CNC.mill's power supply: Is 10.000 uF ok for 3 steppers with 1.7~2.0 A each? (3 L297+L298 paires).
[09:05:48] <alex_joni> what voltage?
[09:06:52] <x3rox> ~36-40V
[09:07:04] <alex_joni> probably yes
[09:08:05] <Jymmm> calc it baby, calc it!
[09:08:50] <alex_joni> * alex_joni needs to get ready
[09:09:03] <alex_joni> Jymmm: going to germany for a couple of days
[09:09:29] <x3rox> Jymmm: And how?
[09:09:28] <Jymmm> I am? damn, nobody told me
[09:11:19] <x3rox> alex_joni: How is the capacitor calculated, please?
[09:11:48] <Jymmm> x3rox: I'm looking, dont get your panties in a bunch!
[09:12:19] <x3rox> :D
[09:14:46] <x3rox> I think, as long as the +5V are stable, it should work, I am only unsure about drawbacks on the current-chopping, if voltage is too noisy. Could result in wild oscillations?
[09:16:21] <Jymmm> yo pantie boy...
http://www.geckodrive.com/photos/Step_motor_basics.pdf page 11
[09:17:10] <Jymmm> x3rox: But, it be a VERY GOOD IDEA to read the whole document too
[09:18:06] <x3rox> Jymmm: are you a pantie fetishist? ;-)
[09:18:48] <Jymmm> x3rox: Nope, just inpatient ppl bug the shit out of me.
[09:21:33] <x3rox> Well, i come to ~13000 uF @ 36V. I'll try with 10000 uF first. I know this doc, but it does not explain the background (this is what I do not prefer). Anyway, I'll try. Thanks!
[09:22:17] <archivist> http://sound.westhost.com/power-supplies.htm#capacitor-value for a bit of powersupply background
[09:22:24] <Jymmm> x3rox: I understand, but it's the closest we got. Unless you go to engineer skool and get edjoomakated
[09:23:49] <Jymmm> Voltage Regulator Handbook - National Semiconductor Corp. - 1981 Edition
[09:27:43] <x3rox> Ok. archivist showed me a link. All this probably bases on usual 50/60 Hz power supplies (as it appears to me). So with rising frequency it will get much, much better. The formula (80000 * I) / V seems to be somewhat empiric and will surely be on the very safe side, so I really will have to try it.
[09:28:56] <archivist> x3rox, no the supply still need rating at input frequency not load F
[09:29:46] <Jymmm> archivist: F You! And the wavelength you rode in on! =)
[09:30:54] <Jymmm> archivist: nice url btw.... never can get a straight answer out of Mariss
[11:28:34] <cradek_> cradek_ is now known as cradek
[12:07:56] <skunkworks]> skunkworks] is now known as skunkworks_
[16:20:59] <skunkworks]> cia seems to have network connectivity issues.
[16:21:59] <archivist> there is a CIA in #brlcad with the same problem today
[16:22:37] <archivist> are they all hosted in one place
[16:22:43] <skunkworks]> right
[16:22:57] <archivist> * archivist looks at IP, yes
[16:23:33] <archivist> #mediawiki as well
[16:34:37] <xemet> hi
[16:35:19] <skunkworks]> Hi
[16:35:36] <skunkworks]> paper bowls do not work with soup very well.. even 2 layers soak thru
[16:35:50] <xemet> someone could remember me the command to see the differences between the cvs trunk version of EMC2 and my modified version?
[16:36:02] <xemet> and store them in a patch file?
[16:36:38] <archivist> diff
[16:36:47] <xemet> uhm...the complete command?
[16:37:09] <xemet> I remember something like cvs diff u or somthing similar
[16:37:45] <cradek> cvs diff -u >mypatch
[16:38:03] <xemet> ok! Thank you very much!
[17:18:37] <optimum> ĺo all
[17:18:43] <optimum> (ler hydra here)
[17:19:08] <optimum> anyone know where to find/set stepgen parameters, like dirhold for example?
[17:23:16] <skunkworks]> it would be in the hal file page 102 of
http://www.linuxcnc.org/docs/EMC2_Integrator_Manual.pdf
[17:23:46] <skunkworks]> (F L O A T) stepgen.<chan>.dirhold 2013 Minmum time from the end of a step pulse to a direction
[17:23:58] <skunkworks]> change (step type 0 only).
[17:24:50] <skunkworks]> you will probably have to add them. I don't think they are in there by default. I have not need to use them yet
[17:28:00] <optimum> Skullworks-PGAB, ah, thats where it was hiding, thanks :)
[17:29:55] <optimum> skunkworks, I take it it doesn matter which hal file itś placed in?
[17:31:40] <skunkworks]> what ever hal file is called in the ini
[17:31:44] <skunkworks]> HALFILE = max.hal
[17:32:43] <optimum> well, lets say Ive got many loaded hal files
[17:33:41] <skunkworks]> I would say which ever one has the stepgen stuff.. But that is just a guess
[17:35:19] <optimum> funny, emc dies with ¨unknown command ¨stepgen.0.dirhold¨¨
[17:35:54] <optimum> isnt the syntax stepgen.<num>.dirhold <int>
[17:36:57] <skunkworks]> I think so.. unless something changed.
[17:37:08] <skunkworks]> is this installed or trunk?
[17:37:19] <optimum> installed
[17:37:35] <optimum> I take it the command is just written on a blank line
[17:37:40] <optimum> with no other stuff before or after
[17:37:46] <skunkworks]> right
[17:38:28] <skunkworks]> setp stepgen.0.dirold... I think.
[17:38:34] <optimum> oh, setp
[17:38:39] <optimum> duh
[17:39:12] <optimum> yeah thats better
[17:41:47] <skunkworks]> I don't know what units that is in.. I would assume ns but I am not sure.
[17:42:05] <optimum> intervals of base period
[17:42:17] <skunkworks]> ah
[17:43:05] <optimum> right, that works nicely
[17:43:08] <optimum> thanks
[17:43:09] <optimum> bbl
[18:03:08] <skunkworks]> in g64 tolerance mode -- emc actally combines line segements if they don't diviate from the P amount - correct?
[18:03:19] <cradek> yes
[18:03:55] <skunkworks]> Thanks
[18:05:41] <jepler> skunkworks]: you've got a ]
[18:06:45] <skunkworks]> that was a typing error this morning.
[18:06:52] <skunkworks]> skunkworks] is now known as skunkworks_
[18:07:20] <skunkworks_> might not have been all here this morning - even more than ususal
[18:16:23] <skunkworks_> sound ok?
http://pastebin.ca/650154
[18:20:42] <skunkworks_> http://pastebin.ca/650159
[18:29:45] <jepler> I dunno how much tolerance mode really improves contouring from naive cam -- hopefully enough to justify all the bugs it introduced (the known ones have been fixed :-P)
[18:30:09] <skunkworks_> :)
[18:34:01] <cradek> for emc, the most important thing you can do for contouring performance is set your acceleration correctly (as high as possible)
[18:34:34] <skunkworks_> I see that with this little machine
[18:35:36] <skunkworks_> I don't think I have had anything set to 20ips/s
[18:36:41] <skunkworks_> before
[18:36:43] <cradek> looks like I set stuart's machine to 18
[18:37:04] <cradek> @ 4ips
[18:37:14] <cradek> that thing moves
[18:37:31] <skunkworks_> nice
[18:37:46] <skunkworks_> where you drooling over it?
[18:37:47] <skunkworks_> ;)
[18:37:55] <cradek> no, too big for my garage
[18:38:16] <archivist> adjust the garage
[18:38:53] <cradek> I'd have to put a machine that size in the "barn" (garage--) and there's no heat or AC there
[18:40:34] <cradek> I'd much rather have something 75% as big in the garage
[18:42:11] <archivist> I had a rubish miller which I managed to find a customer for, I need a good one some day
[18:43:04] <archivist> one of the chinese/taiwan mill drills with a round column
[18:43:50] <cradek> round column is good for a drill press ... for a mill, not so much
[18:45:05] <archivist> height was "random" vibration was awfull, and it wasnt square
[18:45:35] <archivist> face milling produced a saw tooth form
[18:52:39] <skunkworks_> hmm - my post isn't making it to the list.
[18:54:18] <skunkworks_> last time I posted was in 05 I think
[18:57:44] <jepler> skunkworks_: you posted to -users fairly recently -- you nominated several people
[18:58:06] <skunkworks_> sorry - this was the gecko list.
[18:58:12] <jepler> oh oh
[18:58:42] <skunkworks_> hmm - now that I think about it - I wonder if I have ever posted to the geko list.
[18:59:52] <les_w> hi guys long time no see
[18:59:57] <skunkworks_> Hey les_w
[19:00:00] <cradek> hi les!
[19:00:02] <skunkworks_> how is it going?
[19:00:26] <les_w> ok. busy with invention and rebuilding house
[19:00:50] <skunkworks_> How is the invention coming?
[19:01:30] <skunkworks_> * skunkworks_ thinks he remembers it being something about power from air flow
[19:01:45] <les_w> I had some strength of materials issues but was assigned some metalurgists to work on it.
[19:01:55] <les_w> they willl solve it
[19:01:59] <skunkworks_> Nice
[19:02:12] <skunkworks_> les_w: played with emc2 yet.. ;)
[19:02:20] <les_w> yeah, I'm doing acoustics most all the time now
[19:02:33] <les_w> have not had the machine even on for months!
[19:03:04] <les_w> I hope to get a break from the sound stuff though
[19:03:18] <dmessier> great to hear from you les
[19:03:37] <les_w> thanks great to talk to you
[19:03:46] <les_w> have new project
[19:03:57] <les_w> ever heard of kester solder?
[19:04:09] <cradek> of course
[19:04:21] <les_w> the corp bought 'em.
[19:04:48] <les_w> now they want me to detect flux voids on the solder lines
[19:04:59] <les_w> tough
[19:05:46] <skunkworks_> jeepers - you definatly have neat problems to solve.
[19:06:12] <jepler> hi les!
[19:06:16] <les_w> I wish I had just one job that I knew how to do and just did it
[19:06:37] <les_w> hi jepler
[19:07:15] <dmessier> can't eddy current inspection do that les???
[19:07:36] <les_w> all the stuff assigned to me hasn't been done.....so I kind of know nothing about my work in the beginning!
[19:07:52] <dmessier> i like those jobs... ; )
[19:08:08] <les_w> dmess....the flux is an insulator
[19:08:13] <skunkworks_> I like winging it also..
[19:08:26] <les_w> working with ir and ultrasonic.
[19:08:56] <dmessier> yes so eddy current would see an anolmoly in the soldered joint
[19:09:27] <les_w> ir is tough because shiny solder has an emissivity of about .08
[19:09:27] <dmessier> ultra sonic might work too
[19:09:34] <les_w> it will but $$$
[19:10:04] <dmessier> i doubt more than ir... how many components a day??
[19:10:26] <les_w> i'll need to be at several megahertz. if ultrasonic
[19:10:40] <dmessier> how bug a compenent??
[19:10:44] <dmessier> big
[19:10:59] <les_w> for ir it is also problematic that shiny metals are non gray bodies
[19:11:11] <les_w> an ultrasonic one?
[19:11:34] <skunkworks_> I assumed he is inspecting the solder itself - checking for gaps in the flux core.. ?
[19:11:55] <dmessier> i doubt it would be we use u/s on aluminum pcs all the time to measure wall thickness'e
[19:12:12] <les_w> It would be a tranciever with the solder wire dunked in a vat of coupling agent
[19:12:28] <les_w> yeah gaps in the flux core during manufacture
[19:12:56] <dmessier> oh running THE flux core solder... gottcha
[19:13:27] <les_w> I guess kester makes most of the word's solder wire
[19:13:52] <les_w> our hobart makes an awful lot of fluxcore welding wire too
[19:13:53] <dmessier> if there were no flux would the solder fill the void or just leave an empty hole?
[19:14:20] <les_w> it will just leave a hole
[19:14:29] <les_w> a hollow core
[19:14:35] <jepler> then just measure the weight per length
[19:14:49] <les_w> very good!
[19:15:20] <dmessier> if the u/s shows full wire thkness with flux in... then it may show wall thickness without flux...
[19:15:36] <les_w> ok. jepler gets all the money.
[19:15:37] <skunkworks_> jepler: that is too easy ;)
[19:15:38] <les_w> heh
[19:15:59] <jepler> ooh money -- I want the shiny kind
[19:16:28] <les_w> actually we are looking at shaking it at low frequency to measure mechanical impedance...that is really "weighing" it
[19:16:38] <les_w> shiny money...hmm
[19:17:02] <dmessier> if the u/s is sensitive enuf .. and the fux IS picket up at measeurable matter.. then when missing it will show the thkness of 1 side of the tube only
[19:17:36] <dmessier> monitor it??
[19:18:03] <dmessier> i take it this needs to fit into a line of some sort
[19:18:12] <les_w> well if the coupling agent has the same characteristic impedance as lead and flux....a void will look just like a bubble of air!
[19:18:26] <les_w> yeah, black box on lines
[19:18:30] <dmessier> yes///
[19:19:03] <les_w> lead has unusually low phase velocity though.
[19:19:10] <les_w> 1300 m/s
[19:19:40] <les_w> there is tin too
[19:19:43] <les_w> and bismuth
[19:19:52] <dmessier> but you could MAP what a good piece looks like... and a bad piece... and see SOMETHING different
[19:20:11] <dmessier> and monitor changes...
[19:20:17] <les_w> oh software will be involved for sure
[19:20:27] <les_w> custom stuff
[19:21:10] <dmessier> i think fof the speeds you need the u/s is the only option... or xray... no.. its lead.. sorry my bad
[19:21:27] <les_w> I think some transforms so only things that move at line speed show up
[19:21:38] <les_w> haha
[19:21:44] <les_w> need neutrinos
[19:22:04] <skunkworks_> heh - neutrino generator
[19:22:08] <dmessier> you were worried about the $$ withu/s... HA
[19:22:32] <les_w> I shouldn't worry much...I get the $$$
[19:22:41] <les_w> but too much and no deal
[19:24:20] <les_w> I think they would be ok with a box up to about $100k...not much more though.
[19:24:36] <dmessier> that s/ware too though..
[19:24:49] <les_w> I hope they are having lots of solder flux voids.
[19:25:02] <dmessier> no shite
[19:25:11] <les_w> yeah 80% of the cost will be SW of course
[19:25:43] <dmessier> linux based??
[19:26:00] <les_w> I mean heck...you guys get $100 per debugged line right?
[19:26:10] <les_w> linux would be good yes.
[19:26:59] <dmessier> using the paraport and plc within emc2 would be quite easy... really
[19:27:40] <les_w> cool
[19:27:51] <les_w> ah...late lunch ready...bbiaw
[19:28:02] <dmessier> later
[19:36:57] <danielbr> jepler: about a new gif led option for pyvcp i'd draw this led
http://imagebin.org/9826
[19:37:00] <danielbr> i find this example
http://pastebin.ca/650244 and this works so I did this change in the pyvcp_widgets
http://pastebin.ca/650246
[19:37:40] <skunkworks_> I thought the up arrow in axis mdi worked to go thru the mdi history.. Or is that only in trunk?
[19:40:09] <dmessier> is the live ubuntu-EMC2 cd installable.. if so frome where??
[19:40:50] <skunkworks_> http://www.linuxcnc.org/content/view/21/4/lang,en/
[19:41:05] <danielbr> skunkworks: the mdi arrow is only in trunk
[19:41:36] <skunkworks_> danielbr: thanks - I thought it worked and figured it made it into the last release.
[19:42:15] <dmessier> NO install icon present folks..
[19:43:00] <skunkworks_> oh - the live cd - the install icon is right on the desktop.. Do you have it booted already?
[19:43:35] <dmessier> yes.. on the other box
[19:44:12] <skunkworks_> unless something has changed - the install icon should be right on the desktop.
[19:44:47] <dmessier> only icon on the desktop ia the cdrom icon
[19:45:45] <jepler> dmessier:
http://linuxcnc.org/iso/emc2-ubuntu6.06-desktop-i386.iso has an "install" icon on the desktop when booted. I have installed ubuntu and emc2 this way many times
[19:45:58] <jepler> there is a much older "live CD" based on ubuntu breezy 5.10, but it could not be installed to the hard drive
[19:46:18] <dmessier> this is 6.06
[19:47:35] <danielbr> jepler: can you look at my very bad python in
http://pastebin.ca/650246 ? What is the error?
[19:47:39] <skunkworks_> is it on every desktop? maybe your on a differnt one? goto desktop 1
[19:49:28] <dmessier> sorry.. the boy does have a breezy cd in..
[19:49:42] <skunkworks_> jepler saves the day.. ;)
[19:49:54] <dmessier> now lemme fint the other
[19:50:01] <dmessier> find
[19:59:36] <JymmmEMC> As of Ubuntu 6.06 (Dapper Drake), you can also install off the LiveCD.
[19:59:46] <JymmmEMC> https://help.ubuntu.com/community/LiveCD
[19:59:57] <skunkworks_> JymmmEMC:
http://www.electronicsam.com/images/engraver/emc2axis.JPG
[20:00:31] <JymmmEMC> skunkworks your new machine?
[20:00:49] <skunkworks_> yes - the stair stepping is the picture not the machine
[20:01:13] <skunkworks_> I hooked 3 parker drives to it.
[20:01:40] <JymmmEMC> skunkworks ah, ok. cool. keeping it hu =)
[20:02:22] <skunkworks_> have not decided 100% yet. have not destroyed anything. Just unplugged their cable and hooked in my drives.
[20:02:40] <skunkworks_> it is a bit of a mess right now.
[20:02:46] <JymmmEMC> skunkworks Do you still have (manual) speed control?
[20:02:56] <JymmmEMC> spindle wise
[20:03:15] <skunkworks_> no - that was part of the other controller. I just plug it in test it.
[20:03:35] <skunkworks_> I am driving the parkers directly from the printer port ;)
[20:03:43] <JymmmEMC> skunkworks Just keep it. Great price, hard to replace, and really not that big
[20:04:34] <JymmmEMC> or sell it to me cheap =)
[20:05:14] <skunkworks_> ;)
[20:05:19] <JymmmEMC> skunkworks Do you think the speed control is easy to interface?
[20:05:36] <skunkworks_> No - it is part of the drive board that smoked.
[20:05:47] <JymmmEMC> hang on a sec...
[20:07:22] <JymmmEMC> skunkworks this has a 0-10V speed control
http://www.cnc4pc.com/Store/osc/product_info.php?cPath=33&products_id=48
[20:13:38] <skunkworks_> I have seen that. - this motor I think is brushless. (not a universal motor)
[20:14:48] <skunkworks_> I don't know what I am going to do about it yet.
[20:16:50] <skunkworks_> JymmmEMC: did you see I am running the parkers directly from the printer port? Working great.. :)
[20:28:15] <approx> hi all! how difficult it would be to create custom output driver to emc?
[20:28:31] <approx> one that would communicate to servo drives thru parallel port
[20:28:40] <approx> drives have 3-wire spi-interface
[20:30:11] <approx> protocol is very simple, with single 32 bit commad drives can get velocity or torque command and emc would get encoder position in return
[20:30:22] <cradek> I don't know anything about spi, but if you do, you could get a good idea by looking at some of the existing drivers
[20:30:41] <cradek> that sounds a lot like the pluto and ppmc systems, which communicate with EPP
[20:30:46] <approx> I took a look, but got no good idea :p
[20:30:47] <skunkworks_> the problem is I think is that there isn't a realtime serial driver yet.. I think
[20:30:51] <jepler> approx: SPI is new, but the type of information transferred (velocity command and encoder position) is a good match for emc
[20:31:11] <approx> yes, the drive is designed emc in mind
[20:31:25] <jepler> approx: do you know what inb() and outb() are?
[20:31:29] <approx> yes
[20:31:39] <jepler> approx: and you can write SPI code using them?
[20:31:53] <approx> I have done SPI apps using parapin library
[20:32:14] <approx> communication code takes only few lines of code
[20:32:28] <approx> one wire is clock, second data out and third is data in
[20:32:57] <jepler> approx: you'll have to write the equivalent of parapin using inb() and outb(), and learn enough about HAL to know how to register the HAL pins for your driver.
[20:33:23] <jepler> approx: (I'm not familiar with parapin)
[20:33:36] <approx> I think parapin uses inb and outb
[20:33:50] <approx> it is just nices frontend to it
[20:34:08] <approx> -s
[20:34:53] <jepler> approx: are you familiar with HAL yet (i.e., writing .hal files, what a pin is)?
[20:34:59] <approx> no
[20:36:48] <jepler> approx: I think that if you're willing to read documentation & some source code you'll quickly understand the things you need to
[20:36:55] <approx> but I think I need a custom parallel port threat that does the communication. right?
[20:37:00] <approx> thread
[20:37:45] <approx> some simple skeleton driver would be cool, just would need to fill in blanks :)
[20:38:07] <jepler> approx: start here:
http://linuxcnc.org/docs/2.1/html/hal/comp/
[20:38:12] <approx> pluto driver looks confusing at first look
[20:38:17] <jepler> there's a "very simple made up hardware driver" under the heading "out8"
[20:39:39] <jepler> your driver will have HAL pins like "dac.0.value", "dac.0.scale", "dac.0.offset"; inside it will do some calculations and figure out the right 32 bit value to send on the SPI bus. Then it will issue the right combination of outb() instructions to actually send the value.
[20:40:45] <approx> I think driver need to run at about 32kHz update rate and output one bit per update
[20:41:05] <approx> 32kHz would equal 1ms servo period
[20:42:23] <dmessier> sounds awesome..
[20:42:24] <jepler> with pluto, I do many I/O instructions all from the servo thread
[20:42:44] <approx> the SPI is optoisolated and needs slower timing
[20:43:07] <jepler> how slow? several uS rise & fall time?
[20:43:12] <approx> yep
[20:43:15] <jepler> hmm
[20:43:27] <cradek> sounds hard to get 1kHz updates out of it then
[20:43:31] <jepler> are you sure you can transmit all the data you need to, once per ms? Is 32 bits for one motor velocity command, or for several?
[20:43:42] <approx> one command is only 32 bits
[20:44:00] <cradek> but that is 64 transitions (the clock has to change twice)
[20:44:23] <approx> hmm.. correct. my mistake
[20:44:32] <approx> thread needs to run at 64kHz then
[20:45:15] <cradek> using two threads is an interesting approach - I don't think we have anything like that yet
[20:45:39] <cradek> except, the fast thread can interrupt the slow thread ... that seems problematic
[20:45:44] <approx> so how does the step/dir module work?
[20:45:46] <dmessier> they would have to 'handshake'...
[20:46:20] <dmessier> kinda inverse time..
[20:46:36] <dmessier> that was for cradek
[20:47:10] <dmessier> you can only get ther as fast as the slowest thd will allow you...
[20:47:33] <approx> I think the solution is something like step/dir driver but with SPI protocol
[20:48:42] <dmessier> all the drives really want is a dir and speed at the same time interval
[20:48:53] <jepler> approx: you're right, there are other modules that have to transfer data between slow & fast threads, and that can be done correctly
[20:49:35] <dmessier> iv you use vector algorithm.. its xyz of untit vector... and speed.. till the next cycle
[20:50:11] <dmessier> if timing is good so will path
[20:50:26] <jepler> if you find that you need to use a 2ms servo period so that you have time to transfer all the bits, it will not have a big negative effect on contouring performance or anything like that
[20:51:04] <approx> that is what I thought
[20:51:38] <jepler> even if there is the need for extra busy waits, I still think that the approach of doing all the I/O from the servo thread could still be worth a try
[20:52:16] <dmessier> absolutely... its cleanest there too
[20:52:17] <jepler> on the third hand, if you are doing it all at BASE_THREAD rate then you don't actually have to write a hardware driver, just something that has some HAL "bit" outputs that can be hooked to existing hardware drivers like hal_parport, and that's an advantage too
[20:52:17] <approx> one 32 bit command can be transferred in 0.2msecs
[20:52:26] <approx> maybe on 0.1ms
[20:53:06] <dmessier> then this point may be mut... we need to try it..
[20:53:10] <dmessier> mute
[20:53:13] <jepler> moot?
[20:53:33] <dmessier> nah...
[20:53:35] <jepler> hi lerneaen_hydra
[20:54:05] <dmessier> not hearing... or worth speaking about
[20:54:16] <jepler> bbl
[20:54:22] <approx> so I need FUNCTION(_) { outb(out_, ioaddr); } that has 64 outb:s and delays in between?
[20:55:00] <approx> simply put, of course something more too
[20:55:04] <jepler> approx: yeah -- you could put as many outb() instructions in there as you want
[20:55:14] <jepler> you could put a for loop or while loop, as long as it terminates
[20:55:24] <approx> is there accurate delay function available?
[20:55:27] <jepler> inside the {} is basically "C" code
[20:55:51] <jepler> void rtapi_delay(long int nsec)
[20:56:00] <approx> how accurate is that?
[20:56:02] <jepler> there is a manual page for rtapi_delay
[20:56:46] <jepler> I'm not sure about accuracy -- I *hope* that it has the regular meaning of all delays: at least the requested time, though possibly more
[20:57:06] <approx> that would be good enough
[20:57:18] <jepler> (for instance, it could be more because all waits are a multiple of 5ns, or because the thread got interrupted by a faster thread)
[20:57:30] <approx> but I found that linux usleep and nanosleep are really inaccurate
[20:57:41] <dmessier> there probably will be some lap time los..
[20:58:19] <jepler> another delay technique is "repeat the last outb() instruction" -- it will delay "about 1 microsecond", but that is not going to be a portable amount of delay
[20:58:24] <jepler> now, really, I'll bbl
[20:58:26] <jepler> good luck approx with your driver
[20:58:30] <jepler> come back and ask more questions anytime
[20:58:55] <approx> thank you for help :)
[21:01:13] <dmessier> cant we use a timing thrd...
[21:01:41] <dmessier> linked to thr rt clock
[21:03:03] <approx> do these appear outside the module (out8)? :
[21:03:04] <approx> pin out u32 out_ "Output value; only low 8 bits are used";
[21:03:05] <approx> param r u32 ioaddr;
[21:03:31] <approx> http://linuxcnc.org/docs/2.1/html/hal/comp/
[21:05:41] <approx> I think I'm beginning to understand
[21:35:39] <maddash> greetz
[21:38:18] <maddash> ...
[21:38:25] <fenn> ?
[21:38:46] <maddash> whoa.
[21:38:49] <maddash> it worked
[21:39:06] <fenn> today #emc, tomorrow the world!
[21:39:11] <maddash> better kill my connection before the FBI comes
[21:39:36] <maddash> btw, fenn, 123456789/999999999 is indeed equal to .123456789.....
[22:54:12] <toast_> toast_ is now known as toastydeath
[23:09:19] <toastydeath> pew pew pew
[23:16:39] <anonimasu> pew
[23:44:08] <skunkworks> where is the axis.ngc located?
[23:44:42] <toastydeath> arrrr
