#emc | Logs for 2007-03-03

Back
[00:33:03] <mdynac> greetings all....
[00:33:31] <cradek> hi
[00:34:23] <mdynac> the new emc2.1 with the adaptive feedrate works like a charm so far....
[00:34:43] <cradek> ok lay it on us - it's never all good news when you show up
[00:35:15] <jmkasunich> cradek <-- pessimist
[00:35:43] <cradek> I prefer 'realist'
[00:35:53] <mdynac> relax , i'm not having any emc related problems....just gotta retune my x axis copley servo amp a bit.....
[00:35:55] <cradek> mdynac: just giving you a hard time, sorry
[00:36:32] <cradek> have you cut any neat stuff since the leaf?
[00:36:34] <mdynac> the x axis does not like it when i try to pid tune emc, the y axis is just fine
[00:36:57] <mdynac> just doing straight cuts of pcd and cdn diamond
[00:37:03] <mdynac> cbn sorry
[00:37:29] <cradek> I remember you had some noise problem (moves were the wrong length?) - did you figure that out?
[00:39:22] <mdynac> not having that problem anymore, if you remeber the machine just went totally afu on me, just got worse and wosre, then the hard drive crashed completely, changes that and emc2.1 was released just in time, put that on it, whipped up my config files and all is well....
[00:39:56] <cradek> strange - must have been a hardware problem, but wow what a strange one
[00:40:37] <mdynac> i think the hard drive was just getting worse and worse, and somehow sticking things up a bit
[00:40:54] <mdynac> but i could be wrong...
[00:41:35] <cradek> hard to say - glad you ahve it working again though
[00:44:17] <mdynac> i am now in the process of finding a very compact pc, like shuttle size or smaller to use in the machine, along with a nice flat screen n the machine to give it that polished look, right now it runs off of a p3 toewr and giant 19 inch crt sitting atop a table along side the generator, with wires ans stuff going every which way...
[00:45:18] <cradek> I successfully ran the latency tests on a PIII HP e-pc - they are < $100 on ebay
[00:45:41] <ds3> what about the dell optiplex? those seem to show up a lot and relatively cheap
[00:45:59] <cradek> the only problem is they can only take 256MB (one socket, and a 512 didn't work)
[00:46:29] <mdynac> kewl, i bought an IBM netvista for 200 bucks at tiger direct, we have a store right in Naperville, but it would not hold the motenc-lite board, that pc uses "compact pci cards......
[00:46:48] <cradek> ohhh I forgot you need pci! e-pc is right out
[00:47:08] <cradek> you're going to be stuck with a mostly full-size desktop case
[00:47:24] <mdynac> the netvista is tiny, i really like it execpt for the compact pci stuff
[00:48:13] <mdynac> putting gentoo linux on it as we speak, wow what a process, but the p4 2.4gig cpu is compiling quite quick
[00:49:03] <cradek> I'm pretty used to the 10 minute ubuntu install now
[00:49:19] <mdynac> there is one manufacturer that has a small footprint p4 machine that will hold a fullsize pci card with a right angle adaptor....
[00:50:13] <mdynac> ubuntu = 10 minutes, gentoo = weekend, but it is without a doubt the fastest linux i have ever run.....
[00:50:55] <cradek> bbl
[01:05:07] <ds3> how PCI slots you need?
[01:05:16] <ds3> 2U systems can be had pretty reasonably
[01:07:49] <mdynac> just one
[01:08:25] <mdynac> i'm trying to find that pc that holds a fullsize pci card with a right angle adaptor....
[01:08:49] <mdynac> so one pci card fits nicely in a very very compact box
[01:09:02] <petev> most of the older shuttle boxes will hold one PCI and one APG
[01:12:10] <ds3> then even a 1U box will work
[01:14:17] <mdynac> 1u 2u etc are 19" rackmount correct? if so too wide for me, shuttle wouls be better...
[01:16:25] <skunkworks> mdynac: so your edm is cutting to your satifaction?
[01:16:43] <mdynac> i suppose i could mill out the top cover of the netvista then insert the motenc card so it will stick out of the top of the box by 1" then build a mini cover to enclose the card......
[01:17:08] <mdynac> yes sir it is cutting PCD and CBN like soft butter....
[01:17:17] <skunkworks> Nice
[01:17:42] <mdynac> just gotta fine tune servo drives and emc PID stuff a bit more....
[01:18:08] <ds3> yeah, 19" rack mount but very thin
[01:19:40] <mdynac> i wish i could fine a true bare bones pc with no serial ports no parallel port or usb firewire on board sound on board ethernet, just a mouse keyboard monitor and one pci slot.....
[01:21:02] <petev> why wouldn't you want USB or ethernet?
[01:21:07] <mdynac> like back in the old days with multi io cards and parallel cards etc....
[01:22:03] <ds3> what kind of processor ?
[01:22:31] <mdynac> the pc will only run the edm machine.........and nothing else......eventually when i boot the machine i want it to boot straight to emc with no kde or gnome stuff, just like a real machine tool...
[01:22:56] <petev> yes, but how do you want to transfer gcode to it?
[01:23:05] <petev> I like to use the USB DOK or ethernet for that
[01:23:06] <mdynac> right now a p3 is just fine, running servos here
[01:23:50] <mdynac> well okay an ethernet port, but most of my customers just use a floppy....
[01:23:59] <petev> a floopy?
[01:24:20] <mdynac> sure they still have the out there
[01:24:20] <petev> I guess they are to used to $500 floppies from the likes of Haas
[01:24:28] <petev> that's stone age
[01:24:40] <petev> even the real machine makers are moving to USB and flash cards
[01:24:48] <mdynac> yes but it is what they do........
[01:24:54] <mdynac> true
[01:25:22] <mdynac> okay so i do need some kinda input to it, but just one.....
[01:25:34] <skunkworks> I have had one machine that has had issues with real time latency when a usb device was plugged in.. something to watch for.
[01:26:04] <mdynac> not too worry i will NEVER hook up a usb anything to the computer....
[01:26:34] <mdynac> or a firewire thingy or serial stuff or a printer for that matter
[01:27:16] <skunkworks> usb memory sticks are so convenient though
[01:27:35] <skunkworks> and they don't stop working after a few months ;)
[01:28:02] <mdynac> what would i ever use one for in a machine tool
[01:28:17] <petev> to transfer gcode
[01:28:51] <ds3> serial port is just fine for g-code transfer
[01:28:55] <ds3> ;)
[01:29:07] <mdynac> correct...
[01:29:23] <petev> my boss6 had serial ;-)
[01:29:25] <mdynac> gee even at 9600 baud it is quick...
[01:29:40] <ds3> mdynac: you can still get MB's with no features on it... but those tend to be speciality items
[01:29:54] <ds3> you can even buy 286 MB's new (and supported)
[01:30:12] <ds3> 9600 is a bit taxing if you are doing lots of surfacing from CAM output
[01:30:14] <mdynac> i've noticed....the new Chmer edms we sell have a minimal type of pc in it....
[01:30:49] <mdynac> 286 is more than enough cpu to run an edm.....
[01:30:52] <ds3> someone posted, think on CNCZONE, that HAAS controllers are DOS based with a min. PC
[01:31:12] <mdynac> most of the machines i repair run on 8088's
[01:31:17] <petev> if you really want to make a hardened embedded type control, check out these DOM modules
[01:31:17] <petev> http://www.mini-box.com/s.nl/sc.8/category.14/.f
[01:31:40] <ds3> actually, if you have the $$$, they do make SO-DIMM sized "PCs"
[01:32:42] <mdynac> thanks for the link they got kewl stuff!!!!
[01:32:50] <petev> yes
[01:34:24] <ds3> mdynac: have you looked at PC104's?
[01:34:58] <mdynac> yes but i decided to stay away from that pc/104 stuff
[01:35:26] <petev> it's not pc104
[01:35:30] <ds3> they are small and don't always have the extra ports
[01:35:54] <petev> most of those boards are the small form factor stuff from VIA
[01:36:01] <petev> mini and nano itx
[01:36:35] <mdynac> i c and they have a pci riser card!!!!
[01:36:44] <petev> yes, several different ones
[01:36:53] <petev> both left/right and different heights
[01:37:13] <mdynac> so i can fit it in a small enclosure.....
[01:37:32] <petev> yes, some of the small cases will hold one PCI with the right angle riser
[01:38:08] <petev> I have one here, but I'm still not convinced it's the answer for a motenc
[01:38:17] <petev> you still have to get all the cables out
[01:38:23] <petev> it works better with the m5i20
[01:38:30] <petev> as the back bracket is open
[01:38:58] <skunkworks> cradek: g92 actually works as I am used to now. Tried it tonight.. Don't be mad. ;)
[01:40:15] <mdynac> i only use two cables, just one i/o so i may be able to squeeze it out with a bit of motenc card tweaking....i've already considered doing this to my card to take up one slot
[01:44:01] <mdynac> gee they went on strike!!!
[01:45:02] <mdynac> that was neat...
[01:46:03] <ds3> beware of VIA boards.... the C3 CPUs can be uh.... surprising =)
[01:47:16] <petev> they don't have the same performance per MHz as a P4, but other than that I have not had problems
[01:50:54] <mdynac> suprisinlg bad?
[01:51:39] <mdynac> are we talking about latency?
[02:00:15] <CIA-6> 03cradek 07TRUNK * 10emc2/src/Makefile: stupid trick to fool editors that parse make output into working
[02:03:46] <ds3> they seem to have all sorts of gotchas, not just in speed.
[02:04:16] <mdynac> well scratch that idea then, i nwant to move in the forward direction....
[02:04:20] <ds3> I have a C3 board I got for $5 new (rebate) and mystery problems kept popping up; some people blame it on the VIA686 chipset used but.... *shrug*
[02:05:08] <mdynac> i'll stick with intel or athlon
[02:05:25] <ds3> beware of AMD chipsets also
[02:05:48] <mdynac> k then just a good 'ol PII or P4
[02:05:55] <mdynac> PIII
[02:06:02] <ds3> or at least review the errata; they do, and will bite you (been bitten, twice)
[02:06:20] <mdynac> actually my first emc with servos ran just fine on a hp vectra PII
[02:08:13] <skunkworks> I have a gantry running on a mini case pII 400 - though now it has a pIII 600
[02:08:25] <skunkworks> worked great
[02:08:30] <mdynac> kewl
[02:09:16] <skunkworks> wait for it... Compaq
[02:09:40] <skunkworks> came out of a univerity - 2 pci on a riser card.
[02:12:33] <mdynac> i remember back in the 80's when i was in the Navy, we had a Compaq portable in our radar shop, we also had several c64's and a kaypro portable....
[02:13:03] <skunkworks> lunch box portables. with crts ;)
[02:13:45] <mdynac> you could feed a family of 10 with that compaq linchbox!!!
[02:14:09] <skunkworks> picknick basket?
[02:14:15] <skunkworks> ;)
[02:14:39] <mdynac> back in the day Compaq was king....
[02:14:51] <skunkworks> what did they use the c64's for?
[02:15:22] <skunkworks> or is that classified?
[02:15:25] <mdynac> they all were personal
[02:15:37] <skunkworks> a
[02:15:38] <skunkworks> ah
[02:15:50] <mdynac> we used an HP1000 and a pdp8 in our ATE station...
[02:16:55] <mdynac> with removable 10 meg hard drive cartridges about the size of a medium pizza box!!
[02:20:41] <mdynac> yeah we would while away the hours on the carrier playing "dig dug" or some other "awesomw" vid game...
[02:39:13] <CIA-6> 03cradek 07rigid_tap * 10emc2/src/emc/kinematics/ (tc.c tc.h tp.c tp.h): unfinished rigid tap support
[02:40:02] <skunkworks> :)
[02:45:08] <cradek> hmm, the description of rs274d's g84 in machinery's handbook is incomplete
[02:45:15] <cradek> does anyone know how an existing machine does it?
[02:46:24] <skunkworks> not of the top of my head - we had to use floating holders.
[02:46:42] <cradek> hmm, ngc defines it, but I don't like it
[02:46:59] <cradek> if the pitch is 2 threads per millimeter, the active length units are millimeters, and the feed rate has been set with the command F150, then the speed should be set with the command S300, since 150 x 2 = 300.
[02:47:24] <skunkworks> eww
[02:47:26] <DanielFalck> cradek, I've used G84 on my Centroid
[02:47:43] <cradek> I'd like to see a depth and pitch specified instead of that mess
[02:47:55] <cradek> DanielFalck: http://www.isd.mel.nist.gov/personnel/kramer/pubs/RS274NGC_3.web/RS274NGC_33a.html#1003437
[02:47:57] <cradek> is this how it works?
[02:48:08] <jmkasunich> somewhere you're gonna have to specify the spindle drive's accel limits
[02:48:18] <DanielFalck> example: G84 X1 Y1 R.1 Z-.5
[02:48:19] <jmkasunich> ini file I would expect
[02:48:29] <DanielFalck> tap a .5 deep hole
[02:48:34] <cradek> is R.1 the pitch (10tpi)?
[02:48:49] <DanielFalck> but the feed rate and spindle speed are critical
[02:49:08] <DanielFalck> M3 S500 F27.78- 18 pitch tap
[02:49:12] <cradek> oh so it does use F/S for the pitch too
[02:49:18] <DanielFalck> yes
[02:49:30] <jmkasunich> what is the R for?
[02:49:38] <DanielFalck> I use a floating tap head
[02:49:42] <cradek> standard canned cycle retract
[02:49:51] <DanielFalck> safe height to retract to
[02:49:55] <jmkasunich> ok
[02:50:18] <cradek> DanielFalck: is G84 not normally rigid tapping?
[02:50:47] <DanielFalck> I'm just used to the floating head on my machine, but let me look in a Fadal manual
[02:50:52] <cradek> thanks
[02:51:37] <cradek> I'm thinking something like: Gxx.x K-1 P.0625 (tap 1" deep, 16 tpi)
[02:52:16] <cradek> G33.1 maybe
[02:54:00] <DanielFalck> cradek: sorry, I can't find the Fadal manual at the moment
[02:54:21] <DanielFalck> I have access to loads of Fanuc stuff at work on Monday though
[02:54:21] <cradek> ok, thanks anyway
[02:54:53] <cradek> rs274d has G84 X- Y- C- D- F- but it doesn't really say how C,D work
[02:55:18] <cradek> like g76, I may roll my own, and we can add a better gcode interface later if we want it
[02:55:41] <cradek> (by better I mean more compatible)
[02:56:22] <cradek> I think it would be a lot nicer to specify the pitch directly
[02:56:30] <DanielFalck> http://www.practicalmachinist.com/ubb/ultimatebb.php/topic/13/4361.html#000000
[02:57:09] <DanielFalck> whoops
[02:57:54] <cradek> If I run the program below, I get an error msg “500”. The book says to refer to section 5 to understand. I can not find section 5 or error code 500 anywhere.
[02:57:58] <cradek> hahaha
[02:58:06] <cradek> 500! 500!
[02:58:50] <DanielFalck> yasnac does rigid tapping well too
[03:01:54] <cradek> is a tension/compression holder like a tapping head but with less give?
[03:02:13] <DanielFalck> it let's the tap float up and down
[03:02:24] <skunkworks> I get the vauge impression that g84 requires a floating head - g84.x is rigid
[03:02:44] <DanielFalck> so you are going into the hole, reverse spindle direction, and the tap continues down a bit
[03:02:58] <cradek> ok, I understand
[03:02:59] <DanielFalck> and it eventually catches back up as you go up
[03:03:16] <cradek> I am going to make emc track it, so you don't need a floating holder
[03:03:24] <DanielFalck> http://www.practicalmachinist.com/cgi-bin/ubbcgi/ultimatebb.cgi/topic/13/4427.html?#000001
[03:03:25] <cradek> it's just like lathe threading in that respect
[03:04:41] <cradek> ok skunkworks is right: sometimes it's G84.x for rigid
[03:05:17] <cradek> thanks guys
[03:05:19] <DanielFalck> there he is
[03:05:27] <bytecolor> here I am!
[03:05:29] <DanielFalck> bytecolor is a machinist
[03:05:34] <cradek> welcome
[03:05:43] <DanielFalck> cradek had some questions on rigid tap
[03:05:56] <bytecolor> DanielFalck, way to put me on the spot... j/k
[03:06:02] <DanielFalck> sorry : _
[03:06:04] <DanielFalck> : )
[03:06:07] <bytecolor> heh, what's up?
[03:06:29] <DanielFalck> I use G84 with a tension compression holder
[03:06:38] <DanielFalck> do you have any details on rigid tapping
[03:06:42] <cradek> ok so that's not 'rigid'
[03:06:51] <bytecolor> no
[03:06:53] <cradek> does your machine do rigid? and if so what's the gcode for it?
[03:06:56] <DanielFalck> definitely not
[03:07:12] <cradek> bytecolor: (I'm writing rigid tap in EMC2)
[03:07:46] <cradek> not knowing anything about other machines, I'm tempted to make a gcode Gxx.x K- P- where the depth (K) and pitch (P) are specified directly
[03:07:47] <bytecolor> oh? well I dont think I could help there? I mean I know how to call a canned cycle but thats about it
[03:08:26] <skunkworks> that is what cradek needs ;)
[03:08:35] <cradek> what's the canned cycle and how does it work?
[03:09:10] <bytecolor> cradek, it's up to you really, I suppose you might want to follow Haas/Fanuc style, but there are other options like specifying a factor for spindle reversal (so it feeds out 3x, 4x the infeed)
[03:09:28] <bytecolor> that's handy in ridgid tapping
[03:09:39] <cradek> hmm, I didn't think of different in and out speeds
[03:09:52] <bytecolor> mazak is programmed in IPR, hass in IPM
[03:09:53] <cradek> can you do that with spiral taps?
[03:09:57] <bytecolor> it just depends
[03:10:29] <cradek> ok let's take another approach if you would humor me
[03:10:48] <bytecolor> cradek, yes but I usually grind all but the first few threads off to keep the chip from snapping the tap on the way out
[03:10:56] <bytecolor> you can buy taps like that though
[03:11:02] <cradek> if you were to design a gcode that would do a rigid tap, and is as simple as possible, what would it look like?
[03:11:30] <bytecolor> like a drill cycle, really
[03:11:39] <cradek> I think the pitch would be declared directly with a P word, instead of some ratio of feeds/speeds
[03:11:46] <bytecolor> mazak specifies an H300 (300% the infeed)
[03:11:55] <bytecolor> for retract
[03:12:28] <cradek> ok
[03:13:15] <DanielFalck> crotchetyGuy is a machinist too
[03:13:27] <DanielFalck> crotchetyGuy: we're discussing rigid tapping
[03:13:30] <cradek> I think nobody wants to buy my P word scheme...
[03:14:06] <bytecolor> cradek, you're familiar with R planes, G99 G98, etc all the basics?
[03:14:14] <cradek> yes
[03:14:24] <bytecolor> Okuma uses 3 retract planes, Fanuc/Haas 2
[03:15:13] <cradek> it just seems goofy - you WANT to ask for a certain inch/rotation, but you have to specify it as a ratio between inch/minute and rotation/minute
[03:15:40] <cradek> I see that everyone does use some variation of that "goofy" way though
[03:16:04] <cradek> with lathes you can specify the inch/rotation directly (like G33)
[03:16:33] <cradek> as more of a programmer than machinist, this looks just like a lathe thread turned sideways to me
[03:16:35] <bytecolor> cradek, P is generally reserved for a dwell in canned cycles
[03:17:07] <cradek> yeah that's true
[03:17:35] <bytecolor> but then again, it's EMC you can do what you want
[03:18:13] <cradek> sure, that's true too, or we could accept two formats
[03:18:48] <cradek> someone in this thread says G84.2 taps in IPR
[03:19:26] <cradek> it seems like each controller does it however it wants, and they make the machinist adapt
[03:19:36] <bytecolor> nod
[03:19:52] <DanielFalck> and emc isn't bound by as many rules
[03:20:10] <bytecolor> I like specifying pitch on a mazak, no conversion. the feed is adjusted for whatever RPM you put in
[03:20:22] <cradek> is that 84.2?
[03:20:38] <cradek> that sounds the most sane to me (pitch)
[03:21:06] <bytecolor> I've never used a .# in a tap cycle
[03:21:18] <cradek> hmm ok
[03:22:04] <bytecolor> you'll probably want to supply a floating cycle, then charge $8k for the ridgid option :P
[03:22:16] <cradek> thanks bytecolor, I think I'll get back to the guts of it now, and I'll keep these ideas in mind when I do the gcode part
[03:22:31] <cradek> bytecolor: haha
[03:23:10] <cradek> an $8k or two would buy me a mill like I need...
[03:23:13] <bytecolor> cradek, G84 X Y Z R F is the most common I suppose
[03:23:19] <crotchetyGuy> make sure that the rigid option is already in the machine, they just have to call you to get the code per Haas
[03:24:17] <cradek> how about for $8k I'll tell people to add RIGIDTAP=ON to their ini file
[03:24:32] <bytecolor> cradek, you should keep the retract factor in mind, that's a nice touch
[03:24:42] <cradek> heck even if I put that in the manual I bet I'd still get a few payments!
[03:25:03] <DanielFalck> so where do you specify a pitch that is independent of feed and spindle speed?
[03:25:45] <bytecolor> you just use the pitch as the F word on a mazak
[03:25:54] <DanielFalck> oh ok
[03:26:08] <DanielFalck> seems a bit confusing
[03:26:09] <bytecolor> mazaks are _smart_ machine tools
[03:26:30] <bytecolor> mazatrol is the shizzle on a lathe, not so much on a mill
[03:27:22] <DanielFalck> I would forget what mahine I'm using, divide rpm/spindle speed and screw up big time
[03:27:41] <cradek> that sounds pretty tragic - big difference between 10ipm and 10ipr
[03:27:43] <bytecolor> that's what post processors are for ;)
[03:27:59] <DanielFalck> would it be silly to just use a P word? I think you guys mentioned that before
[03:28:05] <DanielFalck> postp
[03:28:06] <bytecolor> they make me real lazy I forget codes all the time because I'm not actually looking at G code
[03:28:32] <bytecolor> I had to write the posts though
[03:28:45] <cradek> DanielFalck: I'm strongly leaning toward supporting a P word but probably NOT with G84
[03:29:21] <DanielFalck> G33?
[03:29:23] <cradek> G84 should probably work like others' G84 if we have G84 at all
[03:29:34] <cradek> maybe G33.1 (since G33 doesn't reverse)
[03:29:37] <DanielFalck> ok
[03:29:55] <cradek> but in my thinking, it's just like G33 plus reversal
[03:30:08] <bytecolor> I've only used G33 for single point threading
[03:30:23] <cradek> yes that's what it is in EMC too
[03:30:33] <bytecolor> how does EMC do a canned drill cycle?
[03:30:43] <bytecolor> Fanuc-like?
[03:31:04] <cradek> yes I think so
[03:31:45] <cradek> bytecolor: http://www.isd.mel.nist.gov/personnel/kramer/pubs/RS274NGC_3.web/RS274NGC_33a.html#1003424
[03:32:23] <bytecolor> L for repeats I'm assuming
[03:32:46] <cradek> The L number is optional and represents the number of repeats. L=0 is not allowed. If the repeat feature is used, it is normally used in incremental distance mode,
[03:32:54] <cradek> ...
[03:33:18] <cradek> hmm if I did G33.1 we wouldn't have repeat
[03:33:49] <cradek> but we have looping
[03:34:37] <bytecolor> With this cycle, the programmer must be sure to program the speed and feed in the correct proportion to match the pitch of threads being made.
[03:34:51] <bytecolor> programmer shouldnt have to worry about that
[03:34:58] <bytecolor> but <shrug>
[03:35:09] <cradek> that's my feeling too, I think it's silly
[03:35:17] <bytecolor> cradek, looks like standard G code
[03:36:13] <cradek> bytecolor: but EMC doesn't do all of it... Any that stop/start/reverse/orient the spindle aren't yet supported
[03:36:54] <bytecolor> so no fine bore cycle
[03:37:16] <cradek> the back boring cycle is a great big "yeah right"
[03:37:32] <bytecolor> where the spindle stops at the bottom of the hole, orient (M19) move dx/dy retract
[03:37:45] <bytecolor> to prevent a witness mark
[03:38:20] <bytecolor> you guys have a blast with this stuff huh :)
[03:38:21] <cradek> nope, no orient support
[03:38:31] <bytecolor> like silly putty
[03:38:42] <jmkasunich> the problem with orient is you need to have a spindle drive that can do it
[03:38:51] <bytecolor> ah
[03:39:41] <jmkasunich> folks with J head bridgeports for instance, have plain old constant speed AC motors and vari-speed belt drive
[03:39:42] <bytecolor> well I suppose orientation would be much easier than say C axis interpolation on a lathe
[03:39:52] <jmkasunich> somehow we gotta support everybody
[03:39:54] <cradek> jmkasunich did piece together orient support for tool change on the mazak retrofit
[03:39:58] <bytecolor> jmkasunich, mpd
[03:40:03] <bytecolor> *nod
[03:41:06] <jmkasunich> seems like there should be a canonical machine command for orient (and for precision spindle work - stopping at the right place during threading for example
[03:41:18] <jmkasunich> and other canonical commands for finding out what the spindle can and cannot do
[03:41:30] <cradek> jmkasunich: http://www.isd.mel.nist.gov/personnel/kramer/pubs/RS274NGC_3.web/RS274NGC_34a.html#1000491
[03:42:10] <jmkasunich> ;-)
[03:42:24] <cradek> and the implementation:
[03:42:24] <cradek> void ORIENT_SPINDLE(double orientation, CANON_DIRECTION direction)
[03:42:24] <cradek> {
[03:42:24] <cradek> /*! odo FIXME-- unimplemented */
[03:42:24] <cradek> }
[03:42:24] <jmkasunich> it doesn't say what happens if the spindle can't do that
[03:43:07] <jmkasunich> what the heck is spindle_retract?
[03:43:16] <jmkasunich> and how does it differ from a Z move?
[03:43:44] <DanielFalck> a 'real fast' Z move to a safe location?
[03:44:00] <DanielFalck> something to help the programmer set and forget
[03:44:13] <cradek> Retract the spindle at the current feed rate to the fully retracted position.
[03:44:17] <jmkasunich> these are canonical commands, not g0-code
[03:44:18] <jepler> jmkasunich: the layer interpreting the canon calls would give the operator an error if an ORIENT_SPINDLE is issued that is not possible on the hardware
[03:44:19] <cradek> seems pretty clear to me
[03:44:25] <bytecolor> The rate at which the spindle turns while orienting is up to the implementation. muahah I've seen people sling test indicators across the shop on a mazak (it's a fast orient)
[03:45:21] <jmkasunich> cradek: sure, that says what it does, but why?
[03:45:44] <jepler> jmkasunich: at least I think thats how they'd do it in the nist interpreter model, rather than having a capability query canon call
[03:45:46] <jmkasunich> and how is that distinguished from a Z move?
[03:46:08] <jmkasunich> jepler: that seems reasonable I guess
[03:46:10] <cradek> jmkasunich: the difference is you don't have to specify the target in any coordinate system
[03:46:14] <jepler> (the same as rs274ngc doesn't handle "there's no A axis on the machine" itself)
[03:46:34] <crotchetyGuy> umm..can someone give me a quick summary of the controversy? sorry, latecomer.
[03:47:02] <bytecolor> crotchetyGuy, how to implement a ridgid tap cycle I think
[03:47:01] <cradek> crotchetyGuy: I don't think there is one :-)
[03:47:01] <jmkasunich> jepler: so if you program a tapping move on a machine that can't do tapping, you won't get the bad news until you hit that spot in the program?
[03:47:25] <jmkasunich> started out as a discussion of how other controls spec rigid tapping in g-code
[03:47:29] <jmkasunich> and digressed from there
[03:48:57] <jepler> jmkasunich: yes, though "verify" in the classic guis and the preview plot in axis will usually keep that from happening
[03:50:27] <crotchetyGuy> simple and standard works for me.
[03:50:26] <jmkasunich> does the preview plot actually call the canonicals?
[03:50:52] <cradek> yes that's how the plot is generated
[03:51:14] <jepler> axis has its implementation of each canonical call
[03:51:16] <jmkasunich> fake canonicals? or do you pass an arg that tells the canonical machine to fake it
[03:51:42] <jmkasunich> so fake canonicals then....
[03:51:57] <jmkasunich> if they are fake, how do they know the real machine's capabilities?
[03:51:59] <cradek> well they draw lines instead of moving a tool
[03:52:02] <jepler> when I turn ORIENT_SPINDLE into something more than a stub, it'll probably make an educated guess based on whether a HAL pin is connected
[03:52:29] <jepler> or if that's not good enough, have it look at something from the ini
[03:52:50] <jmkasunich> for threading, the spindle needs to be reversible under program control
[03:52:58] <jmkasunich> figuring that out is gonna be fun
[03:53:07] <roltek> spindle retract was for a k&t machine with a quill
[03:54:02] <jmkasunich> roltek: and Z was the knee?
[03:54:42] <roltek> yes but most k&t were horizontals
[03:55:26] <jmkasunich> ok, so saddle is Y, and quill is independent of that
[03:55:29] <roltek> they called them z and z primes
[03:55:50] <jmkasunich> oh, right. saddle is Z
[03:56:20] <jmkasunich> aren't u v and w supposed to be additional linear axes parallel to x, y, and z?
[03:56:51] <jmkasunich> * jmkasunich is in way over his head - this is why I stick to device drivers
[03:58:12] <roltek> x,y,z,b,z primes and 5th don't remebered what we called that
[04:00:02] <roltek> i have used u,s and w's on hatchi lathes for taper
[04:00:33] <roltek> compensation
[04:03:35] <roltek> g84 on lathes is only used for compression tapping
[04:03:47] <roltek> on mills
[04:10:54] <roltek> see you guy's later
[05:19:39] <ds3> Haas treats U/V as incremental versions of X/Z
[05:20:01] <jmkasunich> I was reading some threads about antique machines, and saw a funny quote
[05:20:14] <jmkasunich> big new leather flat-belt arrives at the factory
[05:20:44] <jmkasunich> boss says "why all those pieces - at the price we're paying it should be one piece"
[05:20:57] <jmkasunich> belt guy says "you ever see a cow that long?"
[05:32:40] <K`zan> LOL
[09:57:24] <xemet> jepler are you there?
[10:15:17] <alex_joni> xemet: it's a bit early in the US
[10:15:20] <alex_joni> in 3-4 hours
[10:16:40] <xemet> right alex...I've forgot
[12:42:08] <kwajpol> hello
[12:42:25] <alex_joni> hi
[12:43:20] <kwajpol> i have a small problem....jog speed doesnt influence on A axis movement
[12:43:29] <kwajpol> any idea what why
[12:43:55] <kwajpol> i use axis UI
[12:47:03] <alex_joni> you need the angular jog speed
[12:47:10] <alex_joni> what version of AXIS are you using?
[12:47:16] <alex_joni> and version of emc2
[12:48:50] <alex_joni> "On machines with a rotary axis, a second jog speed slider is shown. This slider sets the jog rate for the rotary axes (A, B and C)."
[12:49:00] <alex_joni> from the EMC2 User Manual -> AXIS interface
[12:52:23] <kwajpol> i see, thank you (i have the latest version of emc and axis)
[12:53:24] <alex_joni> kwajpol: then there must be another slider
[13:06:16] <kwajpol> yes, there is...i found it....one more question (if i may)....is it possible to set the default yog speed or max jog speed in axis UI
[13:10:10] <alex_joni> Yes I think so
[13:10:26] <kwajpol> is there i aini file for axis UI
[13:10:28] <alex_joni> it is the DEFAULT_SPEED from [TRAJ]
[13:10:36] <alex_joni> in the ini file
[13:11:55] <alex_joni> (I think so at least :)
[13:14:21] <xemet> hi
[13:15:11] <xemet> I've emc2.1.1 compiled in a directory, run in place mode, why when I change a source file it recompiles also a lot of hal files that Iìve not changed?
[13:17:27] <alex_joni> what kind of source file?
[13:17:55] <alex_joni> there must be some dependency between them
[13:18:14] <xemet> maybe I've understood...
[13:18:33] <xemet> I've not to run ./configure every time I recompile, right?
[13:18:39] <alex_joni> no
[13:18:41] <alex_joni> only once
[13:18:49] <alex_joni> all you need to run is 'make"
[13:19:07] <kwajpol> alex: even though, i set the max velocity to 10,000 mm/min in ini file, i can still set the jog speed to 600,000 mm/min. The problem is, that the default speed is very high, end if i forget to decreese it and move one axis, it moves realy fast (one day i fill crash it)
[13:19:07] <xemet> ok, I've tried to recompile without run ./configure and it compile only the file needed
[13:19:17] <alex_joni> if it tells you so, then you need to 'sudo make setuid' <- usually only the first time
[13:19:26] <xemet> thanks
[13:19:27] <alex_joni> kwajpol: the ini file is in units / second
[13:19:44] <kwajpol> oh :)
[13:21:13] <xemet> thinking anout that, maybe could be better to set the max vel ecc. in mm/min, like shown in the
[13:21:28] <xemet> GUI, and let the software translate it in unit/s when it needs it
[13:22:22] <kwajpol> now i get this error: "Unexpected realtime delay, check dmesg for details."
[13:22:49] <kwajpol> the dmesg showed this: http://pastebin.com/892653
[13:23:41] <kwajpol> will the machine still function properly
[13:25:07] <jepler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TroubleShooting#Unexpected_realtime_delay_check_dmesg_for_details
[13:25:23] <jepler> "If you see this message, it usually indicates that some element of your hardware is incompatible with the real-time software"
[13:26:42] <kwajpol> once, i was reading the wiki about incompatibility of nvidea graphical card...but i cant find this any more
[13:28:03] <xemet> jepler: I've compiled the sources for your G5, it works, but maybe I've missed something, because I had to remove (comment) the CHF function because the compiler said setError and NCE_VARIABLES not defined in this scope....I've serached for setError declaration but without success...
[13:28:20] <xemet> jepler: any suggestion?
[13:28:54] <jepler> xemet: NCE_VARIABLES was only added recently on the TRUNK version of emc. If you used "-rv2_1_branch" or any other "-r" when you checked out your sources, you didn't get an appropriate version.
[13:28:57] <xemet> jepler: CHKF macro...not function...
[13:29:19] <xemet> ah ok
[13:29:28] <xemet> I downloaded the 2.1.1
[13:29:37] <jepler> xemet: use the CVS TRUNK
[13:29:43] <xemet> ok thanks
[13:38:59] <xemet> why if I use printf("%f/n", c) it prints the /n, and doesn't gon in a newline?
[13:40:14] <jepler> xemet: because "/n" and "\n" are different
[13:40:36] <xemet> oooooooops
[13:44:49] <kwajpol> is emc mailing list still in use....i get an error if i click on "Emc-users Archives".
[13:45:42] <jepler> kwajpol: yes, the emc-users and emc-developers lists are still in use
[13:46:02] <jepler> kwajpol: occasionally sourceforge has reliability trouble, so try again later
[13:46:17] <kwajpol> ok, thank you
[13:48:41] <jepler> here's another place to view recent messages on our mailing lists: http://news.gmane.org/gmane.linux.distributions.emc.user http://news.gmane.org/gmane.linux.distributions.emc.devel
[14:06:25] <maddash> i'm having trouble runnin /usr/realtime/testsuite/kern/latency/run -- it outputs "rtai-load: cannot find run info: /home/qw/.runinfo." Am i supposed to generate this .runinfo file on myself? how?
[14:09:25] <maddash> ok. i instead of executing the forementioned command (/usr/realtime/...), i `cd /usr/realtime/testsuite/kern/latency/` followed by `./run` -- now i'm getting "Error opening /dev/rtf3"
[14:11:35] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TroubleShooting#RTAI_Latency_test
[14:11:46] <alex_joni> sudo mkdir /dev/rtf; sudo mknod /dev/rtf/3 c 150 3;
[14:11:46] <alex_joni> sudo mknod /dev/rtf3 c 150 3;
[14:11:48] <alex_joni> cd /usr/realtime*/testsuite/kern/latency; ./run
[14:11:49] <maddash> seems like udev is deleting this stuff on purpose - do i just makedev and mknod?
[14:12:02] <alex_joni> maddash: read that page
[14:12:07] <alex_joni> you need to create the nodes
[14:13:00] <maddash> thanks for the quick copy and paste, alex_joni
[14:13:20] <alex_joni> np
[14:16:02] <maddash> is it just me or do these #'s seem...bad? http://pastebin.ca/379779
[14:20:13] <xemet> jepler: how do you generate the diff file?
[14:28:12] <alex_joni> xemet: cvs diff -u > file.diff
[14:29:25] <alex_joni> bbl
[14:30:10] <xemet> if I've two source files, with same name, but with some differencies, is there a way to create one of these files with + and - on the left (I've seen them for the first time last week...so I don't know anything about them)
[14:30:22] <xemet> are they created with cvs?
[14:40:14] <Ziegler> Is there an easy way to upgrade from 2.0.4 >> 2.1?? in ubunutu?
[14:41:09] <jepler> Ziegler: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UpdatingTo2.1
[14:41:21] <jepler> xemet: diff -u oldfile newfile
[14:41:43] <Ziegler> danke
[14:41:51] <jepler> xemet: 'cvs diff -u' shows changes from the cvs version to your modified version
[14:42:05] <jepler> xemet: and 'patch' is a program for applying the changes in a patch in an automated way
[15:11:12] <cradek> I had a dream/nightmare about trying to buy a new computer. The motherboards were categorized by "which game you want to play" and they all had slot types I didn't recognize (round!?) and took ram I had never seen before (it stood up on end!?)
[15:14:49] <cradek> also they were ATX shape, but there were no ports on the back panel that I recognized
[15:16:50] <xemet> jepler: thanks, I will try it.
[15:17:05] <xemet> now I go, bye bye
[15:20:40] <jepler> good morning cradek
[15:21:07] <cradek> hi
[15:21:29] <cradek> you've been busy answering questions today (mostly with URLs I see)
[15:22:19] <cradek> it's good that we have the answers to a lot of the common questions on the wiki
[15:27:45] <jepler> it's unfortunate that people aren't able to find them easily
[15:28:19] <jepler> breakfast time here, bbl
[15:28:35] <cradek> yeah, I don't know how to fix that - I'm a little afraid the good information is buried in a lot of outdated or irrelevant stuff, and only we know which are the good pages
[15:28:43] <cradek> mmm breakfast
[15:56:14] <jepler> mmm breakfast was zucchini bread
[15:56:28] <jepler> now back to trying to understand USB HID
[15:56:39] <alex_joni> hi guys
[15:56:50] <alex_joni> jepler: I might have a Logitech Gamepad later for testing
[15:57:34] <jepler> alex_joni: I have a good grasp of it from the linux side, though if you want to try your gamepad with hal_input I'd be interested in the results
[15:57:59] <alex_joni> jepler: one of these: http://www.logitech.com/index.cfm/products/details/US/EN,CRID=2225,CONTENTID=6951
[15:58:16] <alex_joni> jepler: that's my plan for later tonight
[15:58:31] <alex_joni> 2 analog joysticks, 12 buttons
[15:58:57] <alex_joni> and a 8-way d-pad
[15:58:58] <jepler> I am trying to adapt 'usbtiny' (USB firmware for AVR) into a USB HID device--I want to do buttons, encoder, and an LED
[15:59:15] <alex_joni> doesn't mjoy work?
[16:01:03] <jepler> alex_joni: I assume it works as claimed on the website, but there are two problems with it. First, the license is, "All presented programs and source code are under GPL licence (for non commercial use)." which is the kind of crazy statement that makes me prefer to look at another option
[16:01:21] <jepler> alex_joni: the second is that it doesn't support encoders as-is
[16:01:22] <alex_joni> heh.. :)
[16:01:41] <jepler> usbtiny is GPL with no weird (parentheticals) tacked on
[16:04:33] <fabiotv> hello
[16:05:15] <alex_joni> hi
[16:07:47] <fabiotv> I have a question!
[16:08:25] <alex_joni> I might have an answer!
[16:10:50] <alex_joni> fabiotv: lets compare them.. maybe they match
[16:12:02] <alex_joni> jepler: this might be also interesting: http://www.avrfreaks.net/modules.php?op=modload&name=News&file=article&sid=572&mode=thread&order=0&thold=0
[16:13:47] <fabiotv> alex_joni: I have installed home switch, all ok if use the mouse select
[16:14:21] <jepler> alex_joni: yeah but that's serial rather than hid
[16:15:49] <alex_joni> I think you can program it
[16:16:26] <jepler> fabiotv: so what is the problem?
[16:16:45] <fabiotv> but if use G28 or G30 they do not find the switch!
[16:17:01] <jepler> fabiotv: That is not the purpose of G28.
[16:17:25] <alex_joni> fabiotv: G28 is supposed to go to the already found HOME position
[16:17:49] <jepler> there is not a g-code instruction to perform the homing process.
[16:17:52] <alex_joni> similar to G0X0Y0Z0 (but that would also know about offsets you might have active)
[16:20:06] <fabiotv> G28 to go Home position, ok
[16:22:23] <alex_joni> * alex_joni assumes it's G28 without looking it up in the manual
[16:24:53] <jepler> "G28" is essentially the same as "G0 G53 X#5161 Y#5162 Z#5163" -- it's just a rapid movement to a particular coordinate defined in the var file, usually X0Y0Z0.
[16:26:30] <fabiotv> yes, ok
[16:27:07] <fabiotv> no g-code is not previewed in order to try home switch?????
[16:27:16] <cradek> G28 optionally goes 'through' another point
[16:27:29] <cradek> there is no way to home the machine from gcode
[16:27:33] <jepler> I think they both optionally go through another point
[16:27:41] <alex_joni> fabiotv: no, no g-code for homing on homeswitches
[16:30:39] <alex_joni> although you can use a g-code for probing ;)
[16:31:26] <alex_joni> it's a crazy scheme.. but you can do something like this
[16:31:46] <alex_joni> have an M-code that links the homeswitch to the probing input
[16:31:51] <jepler> alex_joni: no, please don't suggest this
[16:31:57] <alex_joni> * alex_joni shuts up :)
[16:32:01] <alex_joni> jepler: another topic
[16:32:09] <alex_joni> I got the gamepad ;)
[16:32:48] <jepler> there should be no need to home once the machine is running -- for instance, if you want to do that because you think your motors might have lost position, you need to fix the problem instead of homing from time to time while milling.
[16:34:32] <alex_joni> jepler: pastebin.ca/379911
[16:35:14] <jepler> alex_joni: and now in halrun, 'loadusr hal_input' 'show'
[16:35:26] <jepler> (if you have a recent CVS TRUNK built, anyway)
[16:35:44] <alex_joni> thought I did..
[16:36:13] <alex_joni> might have been wrong ;) (can't find program 'hal_input') ;)
[16:36:52] <alex_joni> ok.. now it's a bit better
[16:37:01] <alex_joni> ImportError: No module named linux_event
[16:37:11] <jepler> . scripts/emc-environment
[16:37:49] <jepler> if that doesn't do it, make sure you did a 'cvs up' at the top level recently -- should be a file lib/python/linux_event.py
[16:38:01] <alex_joni> it works
[16:38:08] <alex_joni> how are the names called?
[16:38:17] <alex_joni> * alex_joni also has emc2 running.. lots of names ;)
[16:38:53] <jepler> the names come from linux
[16:39:31] <alex_joni> nada..
[16:39:36] <jepler> if the device has an absolute axis with ID 0x2 then it's called REL_Z
[16:39:44] <jepler> oh -- I forgot some steps :-P
[16:39:45] <alex_joni> pastebin.ca/379913
[16:40:02] <alex_joni> now he tells me :D
[16:40:30] <jepler> ls -l /dev/input/event*
[16:40:46] <jepler> the most recently added one is for your device -- is it readable by you?
[16:40:49] <alex_joni> I see 0..3
[16:40:53] <alex_joni> no, only root
[16:41:16] <jepler> ok. the quick way is chown alex /dev/input/event3 but that'll only work until you pull the plug
[16:41:29] <jepler> so this time, just do the chown
[16:41:42] <alex_joni> done
[16:41:47] <jepler> now, loadusr hal_input 3
[16:41:51] <jepler> then show -- you should get stuff now
[16:42:03] <alex_joni> even the loadrt was verbose
[16:42:46] <alex_joni> pastebin.ca/379920
[16:43:03] <alex_joni> that's crazy :D
[16:44:00] <jepler> hm -- I wonder if abs-z and abs-rz are actually the second stick and are just misnamed?
[16:44:20] <jepler> try doing a 'watch -n.1 halcmd show' and play with each part of the control
[16:44:41] <alex_joni> trying that now ;)
[16:47:41] <alex_joni> XY is one joystick
[16:47:49] <alex_joni> RZ and Z is the other one
[16:49:11] <alex_joni> wonder if hal_input can export pins for the vibration of the device :D
[16:49:12] <jepler> technically Z should be something that moves in the Z axis (pull up / push down) and RZ should be something that rotates around the Z axis
[16:49:12] <alex_joni> that would be cool
[16:49:30] <alex_joni> jog the mill.. and when it hits limit switches it should vibrate
[16:49:32] <alex_joni> :P
[16:49:40] <jepler> the linux event layer has some kind of vibration support but I don't understand it or have a device that might be compatible
[16:50:01] <alex_joni> ok, all those things there work OK :)
[16:50:27] <jepler> now instead of doing that manual "chown" and specifying "3" you should write a /etc/udev/rules.d file and find an appropriate string identifier
[16:50:37] <alex_joni> oh joy ;)
[16:50:40] <jepler> this is described in the hal_input manpage but I wonder if anybody but me would understand it
[16:50:50] <alex_joni> * alex_joni tries as an exercise :P
[16:50:53] <jepler> I was hoping you would
[16:56:08] <alex_joni> crw-rw---- 1 root plugdev 13, 67 2007-03-03 18:55 event3
[16:56:21] <jepler> looks good
[16:56:27] <jepler> you should be in group plugdev, at least I was on my system
[16:56:29] <alex_joni> yup, first try
[16:56:43] <alex_joni> hal_input crashed ;)
[16:56:51] <alex_joni> when I unplugged the device (no surprise)
[16:57:17] <jepler> nope, not surprising
[16:57:20] <alex_joni> yup.. works now :)
[16:57:27] <alex_joni> I'd say the hal_input manpage is great
[16:57:32] <jepler> what did you find for a device string identifier?
[16:57:46] <alex_joni> the only info I didn't see there was where to get the vendor and model id from
[16:57:53] <alex_joni> I looked in /proc/usb/devices
[16:58:15] <jepler> " You can
[16:58:15] <jepler> view the name, phys, and id of attached devices by executing
[16:58:16] <jepler> less /proc/bus/input/devices."
[16:58:48] <CIA-6> 03jepler 07TRUNK * 10emc2/src/hal/user_comps/hal_input.py: get rid of debug statement
[16:58:51] <alex_joni> I went directly to Permissions and UDEV
[16:58:50] <alex_joni> :)
[16:59:08] <alex_joni> jepler: great stuff as always
[16:59:09] <alex_joni> :P
[16:59:18] <jepler> hm, I wonder what to do about this joypad of mine
[16:59:20] <alex_joni> * alex_joni tries connecting it
[16:59:33] <jepler> the devices I tried before now go from -NNN to NNN for their axes
[16:59:37] <alex_joni> wonder if a hal-file would be interesting in the sample configs
[16:59:37] <jepler> with the center at 0
[16:59:52] <jepler> this device goes from 4 to 1021 instead
[16:59:57] <alex_joni> this one is 0..1
[16:59:58] <jepler> with 512 as the center
[17:00:05] <alex_joni> with 0.5 at the center
[17:00:14] <jepler> I mean -counts -- are you looking at -position?
[17:00:20] <alex_joni> yeah
[17:00:32] <jepler> 'counts' is what actually comes from linux, and it's always an integer
[17:00:34] <alex_joni> counts is 0..255
[17:00:44] <jepler> I construct -position in the usual way by dividing -counts by -scale
[17:00:51] <alex_joni> 127,128 at the center
[17:00:52] <jepler> I guess I need to provide an offset as well
[17:01:53] <fabiotv> sorry for my bad English; the machine would not have to lose the steps, but he is important also for reset the axis Z when the cutter is changed with touch, much software makes it
[17:02:38] <jepler> fabiotv: emc uses tool length offsets for that purpose, but this requires you to know the tool length beforehand
[17:02:51] <alex_joni> or probing to find the tool length :)
[17:03:58] <jepler> alex_joni: then explain about probing if you like
[17:04:04] <jepler> if it's just one axis it won't be gross at all
[17:04:37] <alex_joni> fabiotv: probing is a g-code which will move towards a certain point untill an input is activated
[17:04:43] <alex_joni> you can use it from MDI
[17:08:18] <fabiotv> ok, I try to install the probe!! thanks
[17:10:39] <fabiotv> I would have many questions from I make you, I am ignoring in this!!
[17:10:39] <alex_joni> fabiotv: you need to link the external pin (probably parport) to motion.probe-input
[17:10:53] <alex_joni> fabiotv: keep asking if you have problems
[17:12:52] <alex_joni> jepler: hmm.. we need some more pins for halui ;)
[17:13:11] <jepler> alex_joni: what pins are those?
[17:13:15] <alex_joni> for jogging
[17:13:25] <alex_joni> velocity based like TELEOP jogging
[17:13:38] <alex_joni> I want to jog with the joysticks
[17:14:29] <alex_joni> that way one could jog at lots of different speeds.. depending how hard he tips the joystick
[17:14:44] <alex_joni> (the scale for position would do the counts->speed mapping)
[17:17:14] <fabiotv> alex_joni: ok, must read the handbook before, then I ask ; thanks
[17:17:25] <alex_joni> fabiotv: your welcome
[17:18:33] <elovalvo> alex_joni: Hi
[17:18:53] <alex_joni> hi Ernesto :)
[17:19:25] <elovalvo> alex_joni: How to know my name?
[17:19:39] <alex_joni> elovalvo: I got an email from you a while ago :)
[17:19:45] <alex_joni> * alex_joni sometimes has a good memory
[17:20:05] <alex_joni> I just liked the name Lo Valvo
[17:20:15] <elovalvo> alex_joni: I am the university teacher of xemet
[17:20:20] <alex_joni> yes, I know :)
[17:20:22] <fabiotv> elovalvo: anche lei quì
[17:20:34] <alex_joni> hope you don't mind I called you Ernesto
[17:20:51] <elovalvo> alex_joni: No problem!
[17:21:12] <elovalvo> fabiotv: si sono a casa a surfure
[17:22:00] <elovalvo> alex_joni: yesterday I have purchase a gamepad wirelss logistich
[17:22:15] <alex_joni> I am just playing with one :)
[17:22:29] <alex_joni> mine is called RumblePad 2
[17:23:36] <elovalvo> and, with help of xemet, has beeen used on minimill
[17:23:58] <elovalvo> alex_joni: yes, rumblepad 2
[17:24:12] <elovalvo> Nice!
[17:24:15] <alex_joni> cool, I am just trying to set it up now :)
[17:24:59] <ejholmgren> sounds like fun
[17:27:46] <elovalvo> in this moment I try to compile postp of apt360 but i receive some errors
[17:28:19] <jepler> you should ask the aptos developers about that -- I don't think anyone in here has built apt360
[17:28:59] <elovalvo> jepler: OK. Thanks
[17:29:34] <crotchetyGuy> what errors?
[17:29:59] <crotchetyGuy> postp is rather unstable right now
[17:30:32] <elovalvo> <crotchetyGuy> http://www.pastebin.ca/378418
[17:32:51] <alex_joni> elovalvo: how is palermo these days?
[17:32:59] <crotchetyGuy> I will look into it....
[17:36:26] <maddash> http://pastebin.ca/379971 --- my source file; http://pastebin.ca/379972 --- my hacked up version of configs/stepper/standard_pinout.hal
[17:36:50] <alex_joni> jepler: loadusr hal_input 3 -W ..?
[17:38:17] <maddash> after i compile my source file, i run `bin/halcmd -k -f [name of my hal file]`, then i execute my compiled program. when i test the voltages between pin 14 and the ground, i get a steady 96.6 mV, instead of the expected flux/1 sec. what's wrong?
[17:39:12] <alex_joni> maddash: you need a thread
[17:39:26] <alex_joni> and the write function of the parport driver connected to that thread
[17:40:04] <jepler> alex_joni: I don't understand the question
[17:40:15] <alex_joni> jepler: nm.. was wondering how I can loadusr -w
[17:40:18] <alex_joni> but found out
[17:40:29] <jepler> alex_joni: should be 'loadusr -W hal_input'
[17:40:44] <jepler> the component name is hal_input, so -n is not needed
[17:41:07] <alex_joni> maddash: loadrt threads name1=madthread period1=50000
[17:41:10] <maddash> alex_joni: but when i track test.bit from halmeter, the display appropriately switches from "true" to "false"
[17:41:28] <alex_joni> maddash: that's correct
[17:41:42] <alex_joni> but it doesn't get written to the parport physical pins
[17:41:54] <alex_joni> maddash: add that line along with:
[17:42:04] <alex_joni> addf parport.0.read madthread 1
[17:42:08] <alex_joni> addf parport.0.write madthread 1
[17:45:21] <maddash> alex_joni: i suppose "madthread" is just an arbitrary name?
[17:45:28] <alex_joni> yes
[17:46:46] <crotchetyGuy> elovalvo: you might try a cvs update- you may have checked it out at a time it was in a bad state. Let me know what that does for you.
[17:47:46] <maddash> alex_joni: i'm looking at the man page for HALCMD http://www.linuxcnc.org/docs/2.1/html/man/man1/halcmd.1.html it doesn't specify the period1 name1 parameters. what do these mean?
[17:48:02] <elovalvo> <crotchetyGuy> OK. Thanks
[17:48:58] <alex_joni> maddash: man threads
[17:48:58] <elovalvo> My dog say: "I need to go"
[17:49:02] <CIA-6> 03jepler 07TRUNK * 10emc2/docs/man/man1/hal_input.1:
[17:49:02] <CIA-6> improve handling of absolute axes: add 'offset', 'min' and 'max' parameters, make offset and scale take effect even when new events are not received
[17:49:02] <CIA-6> rename position-scale to scale
[17:49:04] <CIA-6> 03jepler 07TRUNK * 10emc2/src/hal/user_comps/hal_input.py:
[17:49:04] <CIA-6> improve handling of absolute axes: add 'offset', 'min' and 'max' parameters, make offset and scale take effect even when new events are not received
[17:49:07] <CIA-6> rename position-scale to scale
[17:49:07] <alex_joni> ci vediamo elovalvo
[17:49:15] <elovalvo> Bye and thanks at all
[17:51:05] <maddash> alex_joni: for now, i'm only writing to the test.bit signal. is it absolutely necessary to include "addf parport.0.read madthread 1" as well
[17:51:15] <alex_joni> no
[17:51:22] <alex_joni> that's for reading from the parport
[17:51:58] <jepler> Guest907: hi skunkworks
[17:52:01] <Guest907> Hi
[17:52:04] <alex_joni> hi skunkworks
[17:52:12] <Guest907> Guest907 is now known as skunkworks1
[17:52:22] <skunkworks1> want to see a mess?
[17:52:24] <skunkworks1> http://www.electronicsam.com/images/KandT/conversion/
[17:52:56] <alex_joni> FAST
[17:52:57] <alex_joni> :P
[17:54:05] <alex_joni> skunkworks1: wtf are those on the back?
[17:54:08] <alex_joni> rearcontroller
[17:54:29] <jepler> yeah that was the picture that scared me the most too
[17:54:34] <skunkworks1> yah - the rotary switch lost its end of run ;)
[17:56:45] <maddash> are you guys clairvoyant? how did you know that was skunkworks?
[17:57:00] <alex_joni> maddash: that's a secret
[17:57:09] <alex_joni> we could tell you .. but we'd have to kill you
[17:59:42] <skunkworks1> That was feedrate override..
[17:59:46] <maddash> alex_joni: go ahead. i'll just roll out the backups i've made of my own consciousness.
[18:00:05] <cradek> why not just fix that controller? "rearcontrller" looks simple enough
[18:01:29] <cradek> I fixed my old frequency counter that looked like that (but only about six cards)
[18:01:32] <ejholmgren> what are all the cards?
[18:02:04] <skunkworks1> cradek: doesn't it though?
[18:02:31] <cradek> mostly discrete transistor flip-flops I bet
[18:02:35] <skunkworks1> all
[18:02:44] <skunkworks1> germanium
[18:03:07] <skunkworks1> real transister-transister logic
[18:03:47] <cradek> at least it doesn't look like it has paper capacitors
[18:04:05] <cradek> unless those blue ones are replacements already
[18:04:27] <skunkworks1> we had to replace a bunch
[18:04:34] <cradek> skunkworks1: no core memory in the thing?
[18:04:58] <skunkworks1> not that I know of
[18:05:12] <skunkworks1> tons of divide by 10 cards
[18:05:19] <cradek> ha one of them has a _NO_GOOD_ tag on it
[18:05:25] <cradek> start there :-)
[18:05:48] <cradek> skunkworks1: binary or ring counter?
[18:06:01] <skunkworks1> binary
[18:06:12] <jmkasunich> will somebody test http://linuxcnc.org/docs/HAL_Documentation.pdf
[18:06:22] <jmkasunich> it isn't coming up for me
[18:06:30] <cradek> fine here
[18:06:31] <jmkasunich> no 404 or anything, just sits there
[18:07:03] <jmkasunich> strange
[18:07:20] <skunkworks1> jmkasunich: works here also
[18:07:32] <cradek> skunkworks1: I can't believe how many tools that holds
[18:07:49] <cradek> if you had more than one holder that is!
[18:08:01] <skunkworks1> :) we have a bunch
[18:09:25] <jepler> the pdf works for me too
[18:09:32] <jmkasunich> this is annoying
[18:09:41] <jmkasunich> the user manual link on the same page works fine
[18:09:56] <jmkasunich> but the hal manual won't
[18:09:56] <alex_joni> jmkasunich: what page?
[18:10:03] <jepler> 12:06:10 <jmkasunich> will somebody test http://linuxcnc.org/docs/HAL_Documentation.pdf
[18:10:04] <jmkasunich> linuxcnc docs page
[18:10:24] <alex_joni> works here..
[18:10:25] <cradek> how did you run it with the thumbwheels? is that like MDI?
[18:10:27] <alex_joni> jepler: I saw that..
[18:10:35] <jmkasunich> I've tried restarting my browser..... no clue what is going on
[18:10:52] <alex_joni> cradek: thumbwheels?
[18:11:08] <skunkworks1> cradek: yes - that is mdi
[18:11:08] <cradek> the number wheels marked XYZIJK etc
[18:11:31] <alex_joni> this is weird..
[18:11:36] <alex_joni> getting joint0 ferrors..
[18:11:39] <alex_joni> only once in a while
[18:11:55] <alex_joni> (no message about too fast steps/sec or such)
[18:11:58] <alex_joni> no RT errors either
[18:12:35] <cradek> * cradek hides
[18:12:37] <skunkworks1> cradek: we never used it - it was to flakey. The tape emulator I wrote had an mdi part/
[18:12:52] <alex_joni> might have been because I very rapidly changed jog directions :(
[18:13:01] <alex_joni> cradek: it's during jogs .. so you're off the hook
[18:13:09] <cradek> you need headroom for jogging
[18:13:19] <jmkasunich> you have any backlash configured?
[18:13:22] <alex_joni> no
[18:13:29] <alex_joni> default stepper-xyza config
[18:15:19] <cradek> MAX_VELOCITY = 1.2
[18:15:21] <cradek> STEPGEN_MAXVEL = 1.212
[18:15:27] <maddash> alex_joni: this is my new hal file, taking account your suggestions: http://pastebin.ca/380005 note that test.bit is now linked to pin 8 -- this is because i tried pins 14, 9, 8 , but still got the constant 96.7 mV between pin {14,9,8} and ground
[18:15:29] <alex_joni> using this gamepad it jogs perfectly at 45 degrees
[18:15:37] <jmkasunich> only 1% headroom
[18:16:09] <alex_joni> maddash: where's your component?
[18:16:34] <alex_joni> you need to run your component and link the pin of that to a signal
[18:16:42] <alex_joni> newsig signal bit
[18:16:41] <maddash> alex_joni: you mean the c source file that handles test.bit? http://pastebin.ca/379971
[18:16:49] <alex_joni> linksp signal yourcomponent.pin
[18:16:57] <alex_joni> linksp signal parport.0.pin-08-out
[18:17:28] <alex_joni> maddash: you need to run your component at some point
[18:17:40] <maddash> alex_joni: did you look at my new .hal? cf. lines 24/25
[18:17:43] <alex_joni> loadusr -W <name>
[18:18:01] <alex_joni> maddash: that's a new signal named 'test.bit' of type bit
[18:18:04] <maddash> alex_joni: no, i just run the program compiled from the c source...
[18:18:11] <alex_joni> not the output of the component
[18:18:55] <jmkasunich> somebody that is running dapper.... did you get an update to firefox yesterday? if so, does "Tools->ClearPrivateData" still open a dialog like it used to?
[18:19:33] <alex_joni> yes
[18:19:35] <alex_joni> it does here
[18:19:38] <maddash> alex_joni: perhaps i wasn't clear before. I compile the c source code, and run the resulting executable. but before i do that, i load the .hal file via `halcmd -k -f [path to .hal]`
[18:19:44] <jmkasunich> and you did the update?
[18:19:52] <jmkasunich> something is borked with my firefox then
[18:20:05] <jmkasunich> I even did a reinstall with synaptic
[18:20:07] <cradek> did you restart it yet?
[18:20:10] <cradek> oh
[18:20:09] <jmkasunich> yes
[18:20:13] <cradek> hmm
[18:20:17] <alex_joni> maddash: the hal file needs to connect the pin of your component to the pin on the parport
[18:20:39] <jmkasunich> I did not do a restart right after the update, cause I had pages open that I was referring to
[18:20:40] <maddash> alex_joni: my module is clearly loaded into hal, b/c `halcmd show comp` outputs "pphid [the name of my executable], parport" and halmeter does the "true"/"false" thing properly
[18:20:52] <jmkasunich> but since then I've restarted firefox several times, and reinstalled it once
[18:21:09] <alex_joni> maddash: maybe this is more clear: http://pastebin.ca/380017
[18:21:12] <cradek> maybe save your bookmarks and nuke your profile
[18:21:23] <alex_joni> jmkasunich: there was some user reporting problems with libnss
[18:21:26] <alex_joni> in the last update
[18:21:37] <alex_joni> check the logger yesterday or the day before
[18:21:41] <alex_joni> here in #emc
[18:22:14] <maddash> alex_joni: what is "test.bit"?
[18:22:25] <alex_joni> the pin name of your component
[18:22:37] <alex_joni> result = hal_pin_bit_new("test.bit"
[18:23:08] <maddash> alex_joni: how would i know whether the loadusr line did its job properly?
[18:24:00] <jmkasunich> alex_joni: no hits on libnss in the logs last three days
[18:24:11] <jmkasunich> maybe you saw it in another channel?
[18:25:27] <maddash> alex_joni: i assume that "connectio" line 9 is a typo
[18:25:55] <alex_joni> maddash: right
[18:27:28] <CIA-6> 03jepler 07TRUNK * 10emc2/src/hal/utils/halcmd_completion.c: make 'getp' complete pin names as well as param names
[18:28:46] <maddash> alex_joni: i load the hal file prior to running my program (http://pastebin.ca/379971). output errors: "HAL:11: ERROR: test exited without becoming ready
[18:28:46] <maddash> HAL: ERROR: pin 'test.bit' not found
[18:28:46] <maddash> HAL:13: link failed
[18:28:46] <maddash> "
[18:29:08] <alex_joni> test exited without becoming ready
[18:29:27] <maddash> alex_joni: obviously, i can't run my program before loading the .hal, because it relies on test.bit.
[18:29:42] <maddash> alex_joni: catch-22 conundrum.
[18:29:49] <alex_joni> no, you don't need to run it before the hal file
[18:29:49] <jepler> ??
[18:29:56] <alex_joni> the hal file executes your program..
[18:29:57] <jepler> you should fix your program so that it will load with 'loadusr'
[18:30:07] <alex_joni> loadusr -W test
[18:30:10] <jepler> and you should learn the difference between a pin and a signal, which also appears to be part of the confusion
[18:30:15] <maddash> jepler: it's not my program. it's yours...
[18:30:51] <jepler> it's yours now
[18:30:54] <jepler> man hal_ready
[18:31:00] <jepler> if I wrote it, it was probably before hal_ready() existed
[18:31:33] <maddash> jepler: is test.bit not a signal? parport pins only come in the form "parport.0.pin-##-out"
[18:31:35] <alex_joni> jepler: it does have hal_ready(comp_id) in it
[18:31:43] <maddash> jepler: what does "hal_ready" have to do with this?
[18:32:14] <maddash> jepler: the only alteration i made is to add a sigint handler, from jmkasunich's advice
[18:32:31] <jepler> alex_joni: oh, does it?
[18:32:38] <maddash> jepler: http://pastebin.ca/318591?srch=hal_pin_bit_new
[18:32:38] <jepler> so why the 'test exited without becoming ready" error?
[18:33:23] <maddash> jepler: clearly, the functional code is yours. i'd appreciate any help.
[18:34:40] <jmkasunich> perhaps line 24 should actually print a message instead of just exiting
[18:34:56] <jepler> I thought hal_pin_bit_new printed an error message itself
[18:35:03] <jmkasunich> seems to me that or lone 20 is the only way the program would exit without hitting hal_ready
[18:35:16] <maddash> jmkasunich: line 24 of...?
[18:35:26] <jmkasunich> http://pastebin.ca/318591?srch=hal_pin_bit_new
[18:35:35] <jepler> HAL: ERROR: duplicate component name 'test'
[18:35:48] <jepler> or this error from hal_init which is the more likely error
[18:35:53] <jmkasunich> right
[18:36:04] <maddash> jmkasunich: if you dont mind, can you cf. http://pastebin.ca/379971 instead? this is the new one i wrote after the sigint advice you gave me. it's also the one i'm testing.
[18:36:21] <jmkasunich> ok, looking now
[18:36:35] <jepler> maddash: your .hal file should "loadusr -W test", then use link or net to connect the test pin to the parport pin
[18:36:36] <maddash> s/wrote/hackedup/ ,, as most of the credit goes to jepler...
[18:36:41] <jmkasunich> line 33 MUST call hal_exit() before calling exit()
[18:36:53] <alex_joni> maddash: you ran your program first?
[18:36:57] <alex_joni> then the hal file?
[18:37:10] <maddash> alex_joni: i did both permutations.
[18:37:14] <alex_joni> obviously the second instance of your program would barf on hal_init("test")
[18:37:23] <alex_joni> maddash: you need to run ONLY the hal file
[18:37:24] <alex_joni> nothing else
[18:37:33] <alex_joni> scripts/realtime restart
[18:37:39] <alex_joni> then halrun ...hal
[18:37:45] <maddash> alex_joni: that isn't an issue. before each test, i kill off halcmd's comps, and `scripts/realtime stop`
[18:38:04] <alex_joni> ok, but make sure you don't run your program from outside of the hal file
[18:38:36] <maddash> alex_joni: huh? you mean halcmd -k -f [.hal file] before running the program?
[18:38:44] <alex_joni> INSTEAD
[18:38:55] <jmkasunich> never "run" the program
[18:38:56] <maddash> s/before/instead of/?
[18:39:00] <jepler> the whole hal file should look like this: http://pastebin.ca/380031
[18:39:07] <jmkasunich> just invoke it inside the hal file with loadusr
[18:39:11] <jepler> you should run it with 'halrun'
[18:39:27] <jepler> halrun will exit when 'test' exits (for instance, because you 'halcmd unload' or 'kill -INT' it)
[18:39:48] <jepler> (assuming that it exits properly, by calling hal_exit())
[18:40:02] <jepler> you should not run 'test' yourself, you should let 'loadusr' do it
[18:41:03] <maddash> jepler: 'test' being the name of the program, right? because in alex_joni's suggested hal file (http://pastebin.ca/380017), test is a signal(or pin?), not a program...
[18:41:04] <jepler> ('net' is a newer alternative to 'newsig' + 'linkXX', but if it would help I can write that hal file to use newsig/link)
[18:41:41] <jepler> maddash: calling everything 'test' doesn't make it easy to refer to anything
[18:42:11] <jepler> maddash: 'test' is the name of the compoent created by that source file (hal_init("test"))
[18:42:12] <alex_joni> I specifically named the signal "connection"
[18:42:34] <jepler> the name of the pin created by 'test' is 'test.bit' (result = hal_pin_bit_new("test.bit",HAL_OUT,&data->b,comp_id);)
[18:42:55] <maddash> jepler: mm. i called my program "pphid" and signal "test.bit"...what about alex_joni's "linksp connection test.bit"?
[18:42:58] <jepler> your first hal files created a *signal* named test.bit; I suggested using "toggling" and I guess alex recommended using "connection"
[18:43:37] <maddash> let me take the linear combination of all your suggestions and make the appropriate changes...hold on a sec.
[18:43:41] <alex_joni> if you called your program pphid then you need to change the hal_init("pphid") and pin_bit_new("pphid.bit"..
[18:43:51] <jepler> alex_joni: yes, I agree
[18:43:55] <alex_joni> and the hal file needs to "loadusr -W pphid
[18:44:21] <alex_joni> jepler: think this is usefull to put in CVS or wiki?
[18:44:30] <alex_joni> http://www.pastebin.ca/380036
[18:44:31] <jepler> if you didn't create a program called "test", then the program that halcmd actually executed would have been /usr/bin/test, which has a different purpose entirely than being a HAL component
[18:45:12] <jepler> alex_joni: I don't know -- my joystick doesn't have any pin called abs-hat0x-position in hal_input
[18:45:32] <alex_joni> this is a gamepad
[18:45:52] <alex_joni> the inputs hat* belong to the thumbpad or what it's called
[18:46:06] <jepler> if you put a comment in saying that the pin names for other gamepads may be different, sure
[18:46:13] <alex_joni> wiki?
[18:46:32] <alex_joni> or in configs/common/
[18:46:35] <jepler> also you sholdn't use "hal_input 3" in an example, nobody shold use that form
[18:46:43] <alex_joni> er.. right
[18:49:58] <maddash> 13:43:41 <alex_joni> if you called your program pphid then you need to change the hal_init("pphid") and pin_bit_new("pphid.bit".. ------------- the former is obvious, but what about the latter? i thought that pin-bit names were arbitrary, provided there was no conflict
[18:50:17] <jepler> maddash: by convention the pin and parameter names start with the component names
[18:50:24] <jmkasunich> yes, they are arbitrary, but using the program name as the prefix is a convention that avoids confusion
[18:50:28] <alex_joni> maddash: yes, but it saves from confusion to be consistent in naming
[18:50:47] <jepler> it is not a requirement, just a guideline or convention
[18:50:53] <jmkasunich> firefox is really pissing me off
[18:51:06] <alex_joni> jmkasunich: found what I told you to look for?
[18:51:13] <jmkasunich> no
[18:51:18] <alex_joni> logger_emc: bookmark
[18:51:18] <alex_joni> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2007-03-03.txt
[18:51:50] <alex_joni> 16:49:41 <LawrenceG> * LawrenceG grumble grumble.... nss update breaks evolution.... mumble mumble
[18:51:53] <alex_joni> 16:50:56 <LawrenceG> * LawrenceG use LD_LIBRARY_PATH=/usr/lib/firefox evolution & as a workaround until new evolution pkg released
[18:51:58] <alex_joni> hmm.. it was about evolution.. nm
[18:52:45] <jmkasunich> [13:23] <jmkasunich> alex_joni: no hits on libnss in the logs last three days
[18:53:03] <jmkasunich> oh, I searched for libnss
[18:53:05] <alex_joni> missed that .. sorry..
[18:54:09] <jmkasunich> I just backed up my bookmarks, and deleted the entire .mozilla/firefox/kjp773ix.default directory (which I thought was my profile)
[18:54:19] <jmkasunich> but firefox still knows about my bookmarks
[18:54:47] <alex_joni> how about deleting .mozilla ?
[18:54:51] <skunkworks> wow - just got my 11 80mm fans off of ebay.. they look great. it was like 15 dollars.
[18:55:04] <jmkasunich> maybe .mozilla/firefox
[18:55:16] <jmkasunich> I don't want to bork .mozilla/thunderbird
[18:55:22] <alex_joni> :-)
[18:55:50] <jmkasunich> duh, its .mozilla-thunderbird
[18:55:55] <jmkasunich> so I can kill .mozilla
[18:56:19] <jmkasunich> wtf!?
[18:56:27] <alex_joni> still there I bet :D
[18:56:35] <jmkasunich> yep
[18:57:28] <alex_joni> are you in the right userhome? :)
[18:57:44] <jmkasunich> yes
[18:58:19] <jmkasunich> this computer is borked
[18:58:38] <jmkasunich> the file browser thinks anything that ends with .dat is a MPEG video
[18:58:40] <jmkasunich> wtf is going on?
[18:58:54] <alex_joni> I think that's common
[19:00:42] <jepler> make sure the firefox process has actually died/been killed?
[19:02:23] <jmkasunich> thank you!
[19:02:26] <jmkasunich> that made a difference
[19:03:35] <jepler> it's coming back to me now: after installing the firefox update, i had some particular web page that just froze when I tried to load it
[19:04:47] <robin_sz> meep?
[19:04:53] <jmkasunich> * jmkasunich pops stack a few times
[19:05:01] <jmkasunich> I think I was replying to a mail before that crap started
[19:05:04] <jmkasunich> hi robin
[19:05:12] <robin_sz> evening
[19:05:56] <jmkasunich> hmm... Jack Ensor found a legit docs bug
[19:06:16] <jmkasunich> at least one (and I bet many) of the commands in the hal manual assume run-in-place, not installed
[19:06:44] <maddash> ok guys, here's my new pphid.c (http://pastebin.ca/380047) and new standard.hal (http://pastebin.ca/380058)
[19:07:19] <jmkasunich> oh, actually its not a bug
[19:07:29] <jmkasunich> other than assuming that people know what a man page is
[19:08:23] <jepler> maddash: if you want me to guess what problem you're having, I can.
[19:08:33] <jepler> maddash: but it's so much easier if you say what the problem is
[19:08:37] <alex_joni> waitusr test
[19:08:54] <alex_joni> jepler: what's an abs for float?
[19:08:59] <alex_joni> abs() I mean
[19:09:15] <jepler> (I bet it's that the component name "pphid" and the 'loadusr' command name "/home/qw/pphid/pphid" don't match exactly; use -Wn pphid /path/to/pphid in that case)
[19:09:19] <jepler> alex_joni: fabs() ? #include <rtapi_math.h>
[19:09:28] <alex_joni> ok, thanks
[19:10:09] <maddash> sorry, jepler, i was getting a bit ahead of myself. voltage readings on pin 08 and ground still hold constant, @ 97.9 mV
[19:10:54] <maddash> halmeter, as usual, displayed the appropriate 1sec flip between true and false.
[19:11:01] <alex_joni> maddash: look at pphid.bit and see if that toggles
[19:11:19] <alex_joni> how about parport.0.pin-08-out ? does that toggle too in halmeter?
[19:11:33] <jepler> the problem is that 'loadusr -W' is still waiting for the component named "/home/qw/pphid/pphid", which is what you instructed it to do
[19:12:16] <maddash> odd, when i halcmd'ed my standard.hal, it gave a "waiting for pphid" (something like that)...my pphid ran anyway, but when i sent sigint i got "HAL:8: ERROR: /home/qw/pphid/pphid exited without becoming ready"
[19:13:00] <maddash> jepler: so i have to include some code in pphid.c to tell hal that pphid is starting, right?
[19:13:13] <jepler> maddash: that's what hal_ready() does
[19:14:17] <maddash> alex_joni: no, parport's pin 08 doesn't toggle.
[19:14:27] <jepler> halcmd: loadusr -W /tmp/pphid
[19:14:34] <jepler> Waiting for component '/tmp/pphid' to become ready...
[19:14:48] <jepler> the component name "pphid" and the 'loadusr' command name "/home/qw/pphid/pphid" don't match exactly; use -Wn pphid /path/to/pphid in that case
[19:14:58] <maddash> jepler: indeed. but i make a call to hal_ready on line 40 of pphid.c...
[19:15:35] <alex_joni> maddash: you pass an argument to loadusr
[19:15:46] <alex_joni> that is the name of the file it expects to come ready
[19:16:01] <alex_joni> loadusr -W /home/maddash/pphid
[19:16:17] <alex_joni> that would expect a component named "/home/maddash/pphid" to become ready
[19:16:37] <alex_joni> and for that to work you would have to use hal_ready("/home/maddash/pphid")
[19:16:46] <alex_joni> but that won't work once you decide to move the file
[19:17:00] <alex_joni> so loadusr has an option to tell it the name of the component that needs to get ready
[19:17:15] <alex_joni> loadusr -Wn pphid /home/maddash/pphid
[19:17:21] <maddash> this is the exact sequences of msgs: http://pastebin.ca/380072
[19:17:36] <alex_joni> that would run the component /home/maddash//pphid, but wait for a component named "pphid"
[19:17:40] <alex_joni> which is what you want
[19:18:07] <maddash> alex_joni: hal_ready takes int, not const char*, no?
[19:18:10] <maddash> http://www.linuxcnc.org/docs/2.1/html/man/man3/hal_ready.3hal.html
[19:18:22] <alex_joni> I meant hal_init..
[19:18:24] <alex_joni> http://pastebin.ca/380074
[19:18:26] <alex_joni> try that
[19:22:43] <maddash> alex_joni: is waitusr a recent addition? i'm getting "HAL:11: Unknown command 'waitusr' "
[19:23:05] <alex_joni> I didn't write that
[19:23:12] <alex_joni> I just fixed you pastebin
[19:23:44] <maddash> i was following jepler's suggestion: http://pastebin.ca/380031
[19:24:11] <jepler> maddash: waitusr is in emc 2.1.1 and in TRUNK
[19:24:28] <jepler> if you're using some version from CVS older than emc 2.1.1 then you are doing yourself a disservice by not upgrading
[19:24:49] <maddash> jepler: indeed. i shall get right on it.
[19:25:57] <maddash> finally. parport.0.pin-08-out toggles properly in halmeter, and so does the physical pin 8.
[19:27:26] <maddash> brb compiling the new HEAD's gonna eat up all the cpu cycles
[19:30:34] <jepler> hooray
[19:30:42] <maddash> where do i get the pretty flowchart that maps out all the branches? i have a knack for eye candy...
[19:31:12] <alex_joni> cvs.linuxcnc.org
[19:32:25] <maddash> is HEAD > TESTING? or vice versa?
[19:32:53] <jmkasunich> there is a different flowchart for every file
[19:33:05] <alex_joni> maddash: we haven't used TESTING in a while
[19:33:12] <maddash> jmkasunich: yes, i finally took notice of those little icons
[19:33:22] <alex_joni> TRUNK (also incorrectly referred to as HEAD) is the latest development files
[19:33:37] <alex_joni> sometimes buggy, sometimes unstable, sometimes broken completely
[19:33:47] <jmkasunich> the best way to see the state of things is to look at the revision graph for VERSION:
[19:33:47] <maddash> alex_joni: but always fun.
[19:33:51] <alex_joni> if you want to have the latest good code, use -rv2_1_branch
[19:34:04] <jmkasunich> http://cvs.linuxcnc.org/cvs/emc2/VERSION?graph=1
[19:34:06] <alex_joni> -r=revision 2_1_branch
[19:34:26] <jmkasunich> trunk is on the left, the 2.1 branch in the middle, and the 2.0 branch on the right
[19:34:27] <maddash> jmkasunich: thanks! that was the graphic i was looking.
[19:34:33] <maddash> jmkasunich: for.
[19:34:51] <jmkasunich> and the released are tagged in green
[19:36:17] <skunkworks1> ooh - rigid tap :)
[19:36:22] <maddash> alex_joni: jmkasunich told me you attempted compiling EMC2 for ARM --- how'd that work out?
[19:36:39] <alex_joni> not me
[19:36:47] <jmkasunich> not me
[19:37:51] <alex_joni> would someone mind if I backport the analog jog pins to 2.1 ?
[19:38:21] <jepler> let me look at the patch first
[19:38:22] <alex_joni> although I don't have a real urge to do that.. it just works so cool :D
[19:38:28] <alex_joni> jepler: commiting on trunk soon
[19:39:13] <skunkworks1> eww http://www.electronicsam.com/images/KandT/conversion/leftsadle.JPG
[19:39:14] <maddash> who's going to try to execute a GIF image??
[19:40:08] <alex_joni> skunkworks1: seen that already :)
[19:42:12] <maddash> emc2.gif sounds like techno
[19:42:22] <maddash> `cat emc2.gif > /dev/dsp`
[19:50:17] <ejholmgren> wow
[19:50:25] <ejholmgren> O_o
[19:53:22] <CIA-6> 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/halui.cc: add analog pins for jogging. this can be used together with joysticks. (scale the float input to -max_jog-speed .. max_jog_speed), with an idle position around -deadband .. deadband
[19:53:40] <skunkworks1> alex_joni:http://www.electronicsam.com/images/KandT/conversion/card1.JPG
[19:54:04] <skunkworks1> alex_joni: http://www.electronicsam.com/images/KandT/conversion/card1.JPG
[19:54:40] <skunkworks1> http://www.electronicsam.com/images/KandT/conversion/card2.JPG
[19:54:41] <jmkasunich> nice
[19:54:59] <skunkworks1> http://www.electronicsam.com/images/KandT/conversion/cheatsheet.JPG
[19:55:15] <alex_joni> that looks like an 1-Q DC servo
[19:55:16] <alex_joni> card1
[19:55:52] <skunkworks1> here is our current servos ;) http://www.electronicsam.com/images/KandT/conversion/hyservo.JPG
[19:56:15] <alex_joni> skunkworks1: you bumped it
[19:56:55] <skunkworks1> bumped it?
[19:57:13] <alex_joni> yeah, it's angled :P
[19:57:28] <skunkworks1> ah - :)
[20:00:21] <CIA-6> 03jmkasunich 07TRUNK * 10emc2/src/hal/utils/halcmd_commands.c: tweak help text for setp to reflect that it can set params or pins, not just params
[20:09:03] <skunkworks1> alex_joni: so what is a 1-Q dc servo?
[20:09:26] <alex_joni> one quadrant
[20:09:36] <alex_joni> half of a H bridge..
[20:09:45] <alex_joni> err.. less than half :)
[20:09:46] <jepler> "1Q (1 quadrant) is for speed or torque in one direction"
[20:10:03] <skunkworks1> ah. I think it is what runs the hydraulic valve which controls the servo.
[20:10:14] <alex_joni> yup .. that might be it
[20:13:18] <skunkworks1> it will be so nice to get rid of all of it ;)
[20:31:24] <jtr> skunkworks1: gotta keep the tape reader in case the floppy goes bad. ;)
[20:31:41] <CIA-6> 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/halui.cc: only jog if in manual, and MACHINE_ON, no real use to pop up lots of errors otherwise
[20:59:31] <alex_joni> haha, #define KEY_ZENKAKUHANKAKU 85
[21:00:08] <alex_joni> #definen KEY_KATAKANAHIRAGANA 93
[21:01:49] <skunkworks> jtr: not in a million years
[21:01:56] <lerneaen_hydra> lunar eclipse today :)
[21:02:11] <lerneaen_hydra> starts in 1h 42min
[21:02:23] <alex_joni> here too :)
[21:02:24] <alex_joni> a bit earlier
[21:02:52] <lerneaen_hydra> earlier?
[21:03:00] <lerneaen_hydra> it must be in 1h 42 mins worldwide
[21:03:10] <lerneaen_hydra> or, well, for those that can see it
[21:03:15] <alex_joni> if you say :)
[21:03:26] <lerneaen_hydra> a solar ecplise is different though
[21:03:56] <alex_joni> I would have guessed that a lunar ecplise starts differently based on TZ
[21:04:11] <lerneaen_hydra> as the penumbra traces over the earth, wheras in this case the penumbra traces over the moon
[21:11:42] <robin_sz> I have told my childrenb to keep an eye on the moon, if it turns red, then theres a werewolf about
[21:12:08] <maddash> is it just me, or does parport.0.pin-09-in exist, according to HAL_Documentation.pdf?
[21:12:27] <alex_joni> maddash: only if you define the port as input
[21:13:26] <robin_sz> nah, a lunar eclips occurs pretty much simultaeneously for everyone
[21:13:27] <maddash> alex_joni: and by default, hal_parport gets loaded as out, right?
[21:13:36] <alex_joni> right
[21:14:07] <robin_sz> its crystal clear and cold here, perfect viewing conditions
[21:14:27] <maddash> alex_joni: should've told me to RTFM. haha. it's on p53 of hal_doc.pdf
[21:14:34] <maddash> alex_joni: thanks, anyway
[21:16:21] <maddash> can p55 of hal_documentation.pdf be altered so that the block diagrams are oriented properly in portrait mode?
[21:16:40] <maddash> hurts my head to have constantly turn sideways...
[21:16:47] <jepler> maddash: your pdf viewer may have a "rotate" button
[21:17:21] <jepler> maddash: but complaining about the documentation in an insignificant way is a *REALLY* good way to piss off the developers who wrote it
[21:17:57] <fabiotv> good night
[21:18:38] <ds3> you forgot the silverbullets!!!@#@!#@#!!
[21:20:12] <maddash> jepler: i know about the rotate button. except i regularly consult p55 while reading the rest of the doc. and i'm not complaining - i'd be more than willing to make the changes myself, if permitted.
[21:20:50] <jepler> maddash: we welcome contributions -- personally I don't know how to "fix" it
[21:20:57] <maddash> jepler: who wrote it?
[21:21:05] <jepler> if you're a wizard at lyx document layout you're exactly the person to fix it
[21:21:25] <jepler> probably jmk wrote it -- he made the parts of the documentation with the nice full-page diagrams of how things work
[21:21:26] <maddash> it's pdf, so i think i'll need the "source."
[21:21:31] <jepler> the source is in the cvs
[21:29:34] <maddash> ok, correcting hal_doc is next on my todo list
[21:31:22] <jepler> you can generate diffs for .lyx files
[21:31:30] <jepler> e-mail me (jepler@unpy.net) the changes for inclusion
[22:01:29] <robin_sz> eclipse is about 1/3rd here now
[22:01:47] <crepincdotcom> somebody nick hilighted me in the past 24 hrs.... somebody looking for me?
[22:04:03] <Martzis> Hello all!
[22:04:03] <Martzis> I have some problems with my EMC configuration.
[22:04:03] <Martzis> I have EMC 2.1.1 and Pico-Sytems Universal Stepper Controller.
[22:04:03] <Martzis> My current .ini file is here: http://martsola.com/univstep.ini
[22:04:11] <alex_joni> http://imagebin.org/7470
[22:04:15] <Martzis> Axis 0 and 1 work great.
[22:04:15] <Martzis> If I am trying to increase MAX_ACCELERATION I will get Joint x following error.
[22:04:15] <Martzis> How I should modify other parameters to prevent this?
[22:04:24] <Martzis> Axis 2 has another kind of problem. I runs smoothly when the speed is high but in low speeds it makes jumps back and forth. This jumping can continue even when the motion should be stopped.
[22:05:13] <alex_joni> MAX_VELOCITY = 50
[22:05:13] <alex_joni> MAX_ACCELERATION = 2.0
[22:05:14] <alex_joni> PID_MAX_VEL = 15
[22:05:28] <alex_joni> somehow I feel those should be similar values
[22:05:32] <alex_joni> MAX_VEL and PID_MAX_VEL
[22:05:43] <alex_joni> PID_MAX_VEL a bit larger
[22:06:11] <Martzis> I'll try
[22:13:52] <Martzis> I changed MAX_ACCELERATION = 25 and PID_MAX_VEL = 55
[22:14:05] <Martzis> Now it runs smoothly
[22:14:23] <Martzis> Axis 2 problem still exists
[22:14:44] <alex_joni> what do you understand as axis 2 ?
[22:14:47] <alex_joni> Z ?
[22:14:50] <Martzis> yes
[22:15:22] <alex_joni> did you change the PID_MAX_VEL there too?
[22:15:54] <Martzis> Yes
[22:16:26] <alex_joni> how large are the jumps?
[22:16:29] <jepler> does it "jump" by one step, or by many steps?
[22:16:51] <Martzis> it looks like it takes many steps
[22:17:01] <Martzis> I have 10x microstepping
[22:17:21] <Martzis> stepper moves abous 10 degrees
[22:17:21] <alex_joni> PID is not tuned ok
[22:17:21] <jepler> you may want to make your "deadband" larger -- it is not as large as 1 step (1/400 = .00125) but if it's not 1-(micro)step moves then I don't think it's due to the deadband
[22:17:37] <alex_joni> I would guess
[22:19:12] <Martzis> hmm
[22:19:20] <Martzis> I just got an idea
[22:19:49] <Martzis> it is possible that jumps are only microsteps
[22:20:28] <alex_joni> what kind of stepper do you have?
[22:21:08] <Martzis> This driver: http://www.embeddedtronics.com/microsteppld.html
[22:21:14] <alex_joni> is the 400 steps/mm accurate?
[22:21:30] <Martzis> Yes
[22:21:32] <alex_joni> does the screw move 10mm on one turn?
[22:21:40] <alex_joni> err.. 5
[22:21:48] <alex_joni> if it's a 200 steps/rev. stepper
[22:21:51] <Martzis> X and Y are 2 mm / turn and Z is 5
[22:22:02] <Martzis> 200 steps motor
[22:22:06] <alex_joni> right
[22:22:23] <alex_joni> does it move more than one motor step?
[22:22:31] <Martzis> I might have cabling problem
[22:22:50] <alex_joni> might be.. but somehow I doubt that
[22:22:55] <Martzis> step and dir signal cable are rotated tightly together
[22:23:33] <Martzis> previously i had a problem that when I moved x the y made some steps by it self
[22:23:44] <Martzis> I moved cables and it stopped
[22:24:43] <Martzis> Not it is possible that the dir signal (which is alternating) is copied to the step signal
[22:25:03] <alex_joni> what cable distance?
[22:25:17] <Martzis> I used ethernat cable
[22:25:45] <maddash> * maddash conjures up a wireless stepper controller with complementary wireless stepper motors
[22:26:20] <Martzis> Cables are about 30 cm long
[22:27:28] <maddash> if i want to send a signal into parport.0.pin-09-in, i would attach one end of a wire to physical pin 9 and the other end to the ground ,right?
[22:28:34] <jepler> maddash: make sure and set the port to input mode. by default, pin 9 is an output pin, and hooking it to GND could damage your hardware
[22:29:13] <jepler> (er, aren't pins 2-9 the data port?)
[22:29:15] <maddash> jepler: oh crap. does the port revert back to output mode after i unload HL?
[22:29:24] <maddash> s/HL/HAL/g
[22:29:31] <jepler> maddash: I'm not sure what happens when the driver exits, or before it's run the first time
[22:30:39] <jepler> it might be preferable to choose a dedicated input, such as pin 10
[22:30:43] <maddash> jepler: block diagrams in HAL_Doc.pdf say otherwise...unless i'm not understanding what you mean by "data port"
[22:31:20] <jepler> "data" as the term is used in this table: http://www.beyondlogic.org/spp/parallel.htm#2
[22:31:57] <maddash> jepler: , actually, i'm running low on pin-space , and trying to squeeze everything into 8-13,15
[22:33:22] <jepler> I see
[22:34:34] <CIA-6> 03alex_joni 07TRUNK * 10emc2/src/emc/kinematics/pumakins.c: fixes to puma kins (thanks to Martin Priess for hints)
[22:36:19] <maddash> this is bad. i wrote a readpins.hal file (http://www.pastebin.ca/380228), loaded it with halcmd, and ran halmeter to monitor parport.0.pin-{09,10}-in. the problem is that I'm not getting response in halmeter when i ground physical pin {09,10}. however, i do see the voltage jump from ~.04 mV to > 5 mV when i ground/unground these two pins. what am I doing wrong?
[22:37:16] <alex_joni> does halmeter show TRUE ?
[22:38:50] <maddash> no, false -- parport.0.pin-{09,10}-in, that is
[22:39:00] <alex_joni> then grounding it works
[22:39:08] <jepler> bbl -- real life is calling
[22:39:14] <alex_joni> try connecting it to 5V (thorough a resistor)
[22:39:21] <alex_joni> jepler: what's that?
[22:40:43] <maddash> alex_joni: but it stays FALSE whether or not i ground the 2 pins
[22:42:59] <alex_joni> maddash: that's expectable
[22:43:09] <alex_joni> I think
[22:43:18] <alex_joni> a floating input doesn't need to be a certain value
[22:43:24] <alex_joni> try putting your hand on the pin
[22:43:29] <alex_joni> see if it changes
[22:47:13] <maddash> alex_joni: this won't hurt much, will it?
[22:47:22] <skunkworks> wow I thought I installed eagle on here. guess that was a different computer
[22:54:11] <alex_joni> maddash: certainly not
[22:57:35] <skunkworks> ok - I installed eagle - now where the heck did it put it?
[23:01:34] <alex_joni> look for it's nest
[23:02:28] <skunkworks> Now I remember - I finally just opened up terminal and typed 'eagle'
[23:03:41] <skunkworks> * skunkworks is used to icons after a program is installed ;)
[23:08:33] <robin_sz> moon is lovely and red now
[23:08:55] <robin_sz> tried to take a photo through the scope, but insufficient light for my ccd
[23:09:08] <cradek> neat, wonder if we'll be able to see it here
[23:09:13] <cradek> later, I mean
[23:09:25] <robin_sz> same time for everyone
[23:09:41] <robin_sz> its in the shadow for 48 minutes now ...
[23:09:50] <cradek> I know, but I read it would still be eclipsed when the sun starts to go down here
[23:10:00] <robin_sz> if you cant see it during that 48 minutes ...
[23:10:02] <robin_sz> right
[23:10:06] <robin_sz> still light huh?
[23:10:07] <cradek> hmm, it won't be very dark yet at 18:00
[23:10:12] <cradek> yeah, only 17:10 here
[23:10:30] <lerneaen_hydra> cloudy here :(
[23:10:46] <robin_sz> you have another 45 minutes of full eclips, plus an hour or so of partial .. still pretty.
[23:13:07] <lerneaen_hydra> yeah
[23:13:54] <jepler> I don't think it rises here until after totality has ended
[23:13:59] <jepler> http://sunearth.gsfc.nasa.gov/eclipse/OH/image1/LE2007Mar03-Fig1.GIF
[23:14:09] <jepler> I'm past the U3 line
[23:22:39] <robin_sz> im past the point of insanity
[23:24:10] <robin_sz> I shall book myself an aardvark riding lesson soon, assuming i can get a saddle for my aardvark.
[23:24:25] <robin_sz> cup of tea mr Herriott?
[23:42:53] <maddash> ughhhhhhhhhhhhhhhhhh darn input pins!!
[23:52:05] <jmkasunich> too cloudy here, can't even see the moon