#emc | Logs for 2007-04-14

[00:00:59] <Rugludallur> hmm I think there is a usability issue with the net command that should be fixed, if you don't specify a "signal name" the command is silently ignored, for example the following line does not raise an error or work: net oneshot.1.time-left => wcomp.5.in
[00:35:27] <chr0n1c> i am milling myfirst part out of a pc of wood... i drew it in mastercam and posted it withthe mpfan post.. you need to manuall edit out the 3 lines of garbage out of the resulting g-code... then emc runs it fine.
[00:35:46] <chr0n1c> so far it's been running for 12 minutes
[00:36:24] <chr0n1c> it's a multipass program to carve a crazy part i drew... then cut out from the wood. i have been recording video w/no sound
[00:46:44] <ejholmgren_> ejholmgren_ is now known as ejholmgren
[01:14:59] <asdfqwega> * asdfqwega bounces with barely contained antici.......PATION
[01:15:24] <asdfqwega> Taig mini-mill to show up Monday
[01:16:37] <asdfqwega> ...and I'm trying to get a handle on the current status / syntax of EMC2's subroutine/parameter additions
[01:18:48] <SWPadnos> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Oword
[01:24:27] <Jymmm> SWPadnos: one cat5, split to two jacks, any issue on 100mbs?
[01:24:43] <SWPadnos> not that I know of, unless you get into very long cable runs
[01:24:56] <Jymmm> SWPadnos eh, 40'
[01:25:02] <SWPadnos> >100m
[01:25:17] <SWPadnos> or at least in that kind of range
[01:25:18] <Jymmm> ok, cool. just need to find the pinout
[01:25:45] <Jymmm> http://www.ertyu.org/steven_nikkel/ethernetcables.html
[01:25:53] <SWPadnos> the number of twists per foot are different in the different pairs, so there are some very arcane physics differences between pairs
[01:26:21] <SWPadnos> and remember, everyone uses 568b
[01:27:27] <Jymmm> SWPadnos: ok, so should I stay with the "standard" or flip the pairs around to split out the cable and reduce the crosstalk?
[01:27:50] <Jymmm> And I didn't know the twists per pair were different
[01:27:51] <SWPadnos> I'd build or buy a breakout box
[01:28:44] <jmkasunich> oooohhh... blinky lights!
[01:28:58] <SWPadnos> just get a triple-port Leviton/Keystone jack, use the center for the feed, and the top/bottom as normal jacks for the two devices
[01:29:07] <SWPadnos> jmkasunich, I take it you have a stepper config running :)
[01:29:15] <jmkasunich> not really
[01:29:23] <SWPadnos> or at least blinking lights ;)
[01:29:43] <jmkasunich> I just loaded a test config, that mapped some stuff to the I/O pins
[01:29:49] <Jymmm> SWPadnos: Eh, in the office I already have a 2 rj45 port jack, and tossing a rj45 splitter in the garage
[01:29:56] <jmkasunich> the rate command and the position feedback
[01:30:08] <jmkasunich> the pins float hi, so rate is FFFFFF = -1
[01:30:14] <jmkasunich> so position is counting
[01:30:43] <SWPadnos> Jymmm, make two boxes, then you use short patch cables to feed into one, a single long wire to get to the garage, and another box to split into two ports again
[01:30:56] <SWPadnos> it's much easier when a cable breaks
[01:31:23] <SWPadnos> jmkasunich, nice
[01:32:07] <Jymmm> SWPadnos: I just don't remember which pairs are "live" LOL
[01:32:26] <jmkasunich> I wasn't even trying to make blinky lights, just testing the loader
[01:32:36] <SWPadnos> pins 1,2,3,6 make up the main connection (pairs 1+3, I think
[01:32:47] <chr0n1c> i wish i had blinky lights for my machine...:(
[01:33:05] <chr0n1c> ok so does hal do serial interface for sensors and suck?
[01:33:05] <Jymmm> SWPadnos then repeat for the other half?
[01:33:10] <chr0n1c> such*
[01:33:29] <jmkasunich> no at the moment
[01:33:31] <SWPadnos> you'd just have to pick something for the other jack, like use blue instead of prange, and brown instead of green
[01:33:35] <chr0n1c> and... has anyone made a silicone realdoll emc machine?
[01:33:38] <jmkasunich> what kind of serial thing do you have in mind?
[01:33:38] <SWPadnos> s/prange/orange/
[01:34:07] <SWPadnos> there are two HAL drivers for serial ports (AFAIK)
[01:34:09] <Jymmm> SWPadnos ah, gotcha
[01:34:10] <skunkworks> logger_emc: bookmark
[01:34:10] <skunkworks> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2007-04-14.txt
[01:34:18] <SWPadnos> one is called serport, and uses a few of the modem control pins as generic bit I/O
[01:34:19] <chr0n1c> you could g-code a vagina program
[01:34:27] <chr0n1c> anyways.. jsut an idea
[01:34:30] <chr0n1c> just*
[01:34:30] <jmkasunich> one of the drivers uses the serial port control pins as I/O
[01:35:00] <chr0n1c> ok... serport... will look into it
[01:35:01] <chr0n1c> ty
[01:35:06] <SWPadnos> the other is hal_serial (not sure if it's included), which uses a simple protocol (DPP - Dumbest Possible Protocol) to talk to somewhat intelligent devices
[01:35:43] <SWPadnos> but you have to write the software on the device, since DPP isn't a standard of any sort
[01:36:05] <chr0n1c> i have some turk prok sensors... possibly those would interface to serial?
[01:36:16] <SWPadnos> I have no idea what those are
[01:36:18] <chr0n1c> proximity sensors
[01:36:34] <chr0n1c> magnetic i guess
[01:36:49] <chr0n1c> three wires
[01:36:58] <SWPadnos> if you make a microcontroller board that can see the output from the prox switches, then yes. not directly though
[01:37:00] <chr0n1c> i presume they are kinda alalogish
[01:37:02] <toastyde1th> i used proximity sensors once
[01:37:06] <toastyde1th> to kill a man
[01:37:13] <chr0n1c> oh my toasty!
[01:38:08] <chr0n1c> i think i am going to use my mini mill to cnc a new circut board for a bteer driver card...
[01:38:27] <chr0n1c> any suggestions on a card with schematics?
[01:39:08] <SWPadnos> well, perhaps "kill" is too strong a word. but I made him very angry though.
[01:39:09] <chr0n1c> servo drive possibly...
[01:41:14] <jmkasunich> SWPadnos: did you ever do any testing of two 5i20 in the same PC?
[01:41:22] <SWPadnos> nope
[01:41:30] <jmkasunich> me neither (yet)
[01:41:40] <jmkasunich> and I don't want to power down to add the 2nd one
[01:41:51] <SWPadnos> I have only one installed in the panel PC (since that's how I intend to run it)
[01:42:07] <jmkasunich> I think I found a bug in the existing loader program that would make it always load the config into the first board even if you ask for a higher one
[01:42:22] <SWPadnos> I can stick two into another PC, but I only have A64 machines at the moment, so RT is an issue
[01:42:25] <SWPadnos> hmmm
[01:42:41] <SWPadnos> that would be annoying
[01:43:08] <SWPadnos> though we'd have a problem with loading separate configs unless we named the driver differently (with the current scheme)
[01:43:36] <jmkasunich> I'm not worried about the current scheme anyways
[01:43:40] <SWPadnos> heh
[01:44:13] <jmkasunich> I just confirmed the bug - if you tell it to load into board 2, it will detect board 0 and load it there
[01:44:25] <SWPadnos> bummer
[01:44:26] <jmkasunich> my version of the loader won't
[01:44:36] <SWPadnos> I guess that confirms that nobody is using more than one board ;)
[01:45:17] <jmkasunich> I found the bug as I was working on my loader (a copy of peters)
[01:45:39] <jmkasunich> I took out stuff we won't use (the ability to output a .h file, the ability to read prom files instead of bitfiles)
[01:45:46] <jmkasunich> and will be putting in stuff to talk to the config ram
[01:47:33] <skunkworks> jmkasunich: Sounds like your going to town.. Nice work.
[01:48:02] <jmkasunich> I'm getting up to speed on VHDL - I like it
[01:48:34] <SWPadnos> heh. you probably haven't gotten to the C++ like parts yet ;)
[01:48:48] <jmkasunich> what parts are those?
[01:49:12] <SWPadnos> overloading (essentially) - you can define different architectures for the same high-level constructs
[01:49:17] <SWPadnos> strong typing
[01:49:18] <jmkasunich> oh
[01:49:27] <ds3> is there a cheap way to try out VHDL? (or verilog)
[01:49:30] <SWPadnos> probably others I don't remember
[01:49:34] <jmkasunich> strong typing I've seen - it can be a bit if a nuisance
[01:49:40] <SWPadnos> vendor tools are free (as in beer)
[01:49:43] <jmkasunich> ds3 yes, there are free ways
[01:49:49] <ds3> but what about hardware?
[01:49:58] <SWPadnos> $200 fora mesa card is a pretty good start
[01:49:59] <ds3> I got a pile of 22V10's but can't find any synthesis for it
[01:50:06] <jmkasunich> mesa 5i20 board, 200,000 gates for $200
[01:50:06] <SWPadnos> hah
[01:50:13] <SWPadnos> you won't, these days
[01:50:14] <ds3> $200 is $200 more then what my budget allows
[01:50:24] <SWPadnos> there are boards that are only $100 over budget
[01:50:32] <SWPadnos> or $59 over, for the pluto-p
[01:50:34] <ds3> really?
[01:50:40] <jmkasunich> the pluto is $60 ish
[01:50:41] <ds3> will look up pluto-p
[01:50:54] <jmkasunich> for 10K gates maybe? or is it more?
[01:50:55] <SWPadnos> http://www.knjn.com/board_pluto-P.html
[01:51:02] <ds3> nice thing about a 22V10 is I understand it from the PALASM days
[01:51:16] <SWPadnos> more like 1k - it's something like 58 CLBs
[01:51:36] <jmkasunich> its gotta be more than that
[01:51:43] <SWPadnos> it probably is considered a 10k or so device
[01:51:49] <jmkasunich> jepler was able to get several pwms and encoders in there
[01:51:49] <ds3> CLB == 1 entire PAL/GAL?
[01:51:54] <jmkasunich> no
[01:52:15] <SWPadnos> ds3, not quite, but probably not far from the functionality
[01:52:29] <jmkasunich> on the mesa board, 1 CLP = 4 flip flops and 4 logic blocks (each logic block is a 4 input lookup table, so it can do any function of 4 inputs)
[01:52:31] <SWPadnos> fewer inputs and way fewer outputs in a CLB vs. a GAL22V10
[01:52:46] <SWPadnos> plus some extra steering logic plus carry logic
[01:52:53] <jmkasunich> but the mesa board has 1000+ CLBs
[01:53:00] <ds3> Hmmmm that doesn't sound very high density
[01:53:07] <jmkasunich> 4704 FFs and 4704 4-input LUTs to be precise
[01:53:14] <SWPadnos> well, what do you want for $59? :)
[01:53:27] <ds3> what is a LUT? (is that an AND-OR plane?)
[01:53:29] <SWPadnos> plus RAM blocks and stuff like that
[01:53:32] <SWPadnos> look-up-table
[01:53:34] <jmkasunich> look up table
[01:53:53] <jmkasunich> 4 inputs, 1 output, any function of 4 variables
[01:54:06] <ds3> I know what it stands for, but not sure what to make of it...i.e. is it basically a EEPROM feeding into a decoder?
[01:54:28] <jmkasunich> its a 16 bit deep x 1 bit wide memory
[01:54:33] <jmkasunich> the four inputs are the address
[01:54:43] <jmkasunich> and the stored data comes out based on the input
[01:54:49] <ds3> oh so it is a really a tiny EEPROM then?
[01:55:05] <jmkasunich> ram actually, the data is loaded in before you start running it, from a file
[01:55:18] <ds3> I see.
[01:55:35] <jmkasunich> FPGAs and 22V10s have different strengths
[01:56:07] <jmkasunich> the limiting factor for GALs and such is P terms - you can have 20 inputs into a function as long as there aren't too many p-terms
[01:56:18] <jmkasunich> IOW, _some_ functions of many inputs are fine
[01:56:29] <ds3> they way it was explained to me is a FPGA is a pile of 22V10 connected up in a programmable way
[01:56:31] <jmkasunich> for FPGAs, you can do _any_ function, but only of a limited number of inptus
[01:56:39] <ds3> oh I see
[01:57:16] <jmkasunich> if you need 12 inputs, you will use at least 3 (more likely 4) LUTs
[01:57:22] <SWPadnos> look at the info here: http://www.altera.com/literature/lit-acx.jsp
[01:57:35] <jmkasunich> even if the function is only 1 p-term like a 12 input AND gate
[01:57:43] <SWPadnos> that has descriptions of the ACEX chips, which are on the pluto board (and quite old these days)
[01:59:33] <CIA-19> 03jmkasunich 07TRUNK * 10emc2/src/hal/utils/m5i20cfg.c: fixed bug that would access board #0 regardless of what boardnumber was specified
[01:59:55] <jmkasunich> there, now the old program works right (at least, it refuses to load into board 1 if I don't have a board 1)
[02:00:07] <ds3> Hmmm the serial ones are even cheaper
[02:00:46] <SWPadnos> do you mean the MESA serial FPGA cards?
[02:00:59] <ds3> Pluto
[02:01:04] <SWPadnos> ah
[02:01:54] <ds3> do those boards work well on batteries?
[02:02:13] <SWPadnos> dunno
[02:02:13] <jmkasunich> ?
[02:02:38] <jmkasunich> they plug into PCs... so unless the PC is a laptop, batteries don't make much sense
[02:02:42] <SWPadnos> from what Jeff saw on the pluto-P, I'd say those boards are for experimentation only - I wouldn't deploy anything on one
[02:02:57] <ds3> when I learned about them, they were major power hogs
[02:03:05] <SWPadnos> jmkasunich, there are other boards that have config PROMs on them, so separate power could be useful
[02:03:12] <jmkasunich> ah
[02:03:31] <SWPadnos> if you clock them very high, and use most of the FPGA fabric, then they can be power hungry
[02:03:34] <jmkasunich> * jmkasunich finds it hard to get interested in the pluto
[02:03:56] <SWPadnos> but they're in the single watts range, at worst (for anything not too far over your budget ;) )
[02:04:04] <ds3> jmaksunich: what's your disappointment with the Plutos?
[02:04:14] <ds3> yes, they seem very attractive to play with
[02:04:19] <jmkasunich> once you've been in the big city (200K gates and 72 I/O) its hard to go back to the farm
[02:04:30] <ds3> oh in that sense
[02:04:35] <SWPadnos> they're hobby projects, not reliable products
[02:04:49] <jmkasunich> pluto is hobby, mesa is real
[02:04:59] <ds3> reliable? what makes it unreliable?
[02:05:20] <SWPadnos> well, they run the whole chip on 5V, when it's specced for 3.3 core
[02:05:26] <SWPadnos> so it gets warm
[02:05:46] <ds3> ah. okay
[02:05:52] <SWPadnos> they aren't built to be used in a factory - they're built for experimentation
[02:05:55] <jmkasunich> its a bare PC board that plugs into the parallel port, so its outside the PC, vulnerable to damage, etc
[02:06:11] <SWPadnos> not enough bypass caps, poor design rules (from what I hear - I haven't seen a board myself)
[02:06:12] <ds3> well, any deployment would put it in case
[02:06:18] <jmkasunich> I forget how they power it, is it leeching power from the parport somehow, or is there a wall wart?
[02:06:24] <ds3> but the 5V thing does seem a killer
[02:06:30] <SWPadnos> issues with longer cables, so an external case can cause problems ...
[02:06:36] <ds3> at least a LDO....
[02:06:37] <SWPadnos> wall wart
[02:06:45] <jmkasunich> * jmkasunich hates wallwarts
[02:06:47] <ds3> they need to be downloaded on every power up?
[02:07:03] <jmkasunich> the ones without onboard memory, yes
[02:07:11] <ds3> Ohhhhhh that sucks
[02:07:39] <jmkasunich> many FPGAs can use serial proms for the config data, and SWP said something about pluto having boards with onboard proms...
[02:08:09] <SWPadnos> some of the serial ones do
[02:08:41] <SWPadnos> pluto-II, cyclone EP1C3T100 + 1 mbits FPGA boot-PROM
[02:09:01] <SWPadnos> or $69.95 for the Cyclone II + 4Mbits PROM
[02:09:22] <jmkasunich> what kind of gate counts do those have?
[02:09:31] <SWPadnos> I'm looking that up now
[02:09:30] <jmkasunich> 4Mbits sounds huge for a small FPGA
[02:10:07] <SWPadnos> the cyclone 2 is pretty capable - you can stick a 32-bit NIOS processor in even the cheapest ones and still have room left over
[02:10:07] <jmkasunich> the mesa FPGA has about 1.3Mbits
[02:10:10] <ds3> Hmmm
[02:14:25] <SWPadnos> interesting
[02:14:43] <SWPadnos> the 2C5 is about the same size as the 200k Xilinx part - 4608 LEs
[02:14:57] <jmkasunich> how much moola?
[02:15:04] <SWPadnos> but it has way more RAM - 26 blocks of 4 kbits+512 parity bits
[02:15:19] <SWPadnos> $69.95 for the KNJN play board
[02:15:23] <jmkasunich> the xilinx has 13 blocks of 4K, no parity
[02:15:27] <SWPadnos> 13 embedded multipliers
[02:15:58] <SWPadnos> I think those are 9x9, but have extra logic so you can do 18x18 with only two of them (but I could be confusing a different architecture there)
[02:16:03] <ds3> SWPadnos: did you see the guys making the FPGA boards in the CF formfactor?
[02:16:14] <SWPadnos> at EC?
[02:16:15] <SWPadnos> ESC
[02:16:17] <ds3> yeah
[02:16:25] <SWPadnos> no - not this year
[02:16:44] <ds3> if they weren't $2500 each, the CF size would be nice
[02:16:47] <SWPadnos> I do remember a company from last year that had big-ass FPGAs designed for socket 939
[02:17:08] <ds3> i remember those folks... speaks hyperchannel,right?
[02:17:16] <SWPadnos> like 3, 4, and 6M gate chips, in an Opteron socket, with hypertransport and dual-DDR memory busses
[02:17:20] <SWPadnos> yep
[02:17:27] <SWPadnos> $7 or 9k, IIRC
[02:17:47] <ds3> hehe
[02:18:34] <SWPadnos> http://www.xtremedatainc.com/xd1000_brief.html
[02:19:17] <ds3> know someone that was considering it but they couldn't get their act in order
[02:19:33] <SWPadnos> that would be me ;)
[02:19:42] <ds3> haha
[02:19:55] <SWPadnos> I figured it could be good for accelerating video post production, but haven't gotten that contract yet
[02:20:28] <ds3> what about using the PCI board with the 8 or 16 MIPS cores?
[02:20:41] <SWPadnos> PCI would be a limitation there
[02:20:59] <SWPadnos> I have high hopes for processing ~1.5 GBytes/second of data
[02:21:10] <ds3> PCIe prehaps?
[02:21:16] <SWPadnos> not necessarily in realtime, but that would be nice
[02:21:32] <SWPadnos> that could work, but I have to get the data over some network, then fiddle with it
[02:21:46] <SWPadnos> then spit it back out to disk and/or another output
[02:21:56] <SWPadnos> so I have as many as 5 passes across a bus
[02:22:07] <ds3> my last project with an AMD board left me with a very bad aftertaste
[02:22:20] <ds3> put a raid interface on the board!
[02:22:33] <SWPadnos> why is that?
[02:22:46] <SWPadnos> (the bad aftertaste, not RAID)
[02:22:59] <ds3> the "erratas"
[02:23:07] <ds3> 50% of the damn chipset is broq
[02:23:14] <SWPadnos> hmmm
[02:23:43] <ds3> Take a look at the AMD-8111 chipset... suppose to be a PCnet, USB 2.0, and a few other stuff on there
[02:23:45] <SWPadnos> the last time I tried to use an AMD chip in some embedded thing (other than EMC, where others have done all the RT infrastructure) was the Elan SC520
[02:23:47] <ds3> none of them works.
[02:23:59] <SWPadnos> hmmm
[02:24:16] <SWPadnos> the 520 sucked big-time for interrupt response
[02:24:21] <ds3> maybe nVidia can build a bigger one
[02:24:28] <ds3> isn't the ELAN's out of productions?
[02:24:36] <SWPadnos> I'm not sure, could be
[02:25:03] <SWPadnos> it is (was) a 486-like chip (I think they called them 586-class though)
[02:25:25] <ds3> it is as much of a 586 as their 5x86,aka quad clock 486's
[02:25:52] <ds3> the last AMD seminar, they were pushing the Geode
[02:26:03] <SWPadnos> hmmm
[02:26:18] <SWPadnos> I didn't go to any of the vendor seminars this year
[02:26:35] <ds3> it helps to have them down the street
[02:27:24] <SWPadnos> yep, and to not have paid $1200 to be there
[02:27:38] <SWPadnos> I prefer to get real information rather than a long sales pitch when I'm paying for it
[02:28:59] <ds3> *nod*
[02:29:23] <ds3> The AMD one is not worth paying; but the ones from ADI are. those are good talks
[03:09:28] <Jymmm> SWPadnos I thought you said 5120, as i the MEsa card
[03:09:39] <SWPadnos> 5i20, when?
[03:09:50] <Jymmm> [04/13 19:24:31] <SWPadnos> the 520 sucked big-time for interrupt response
[03:10:05] <SWPadnos> nope - elan SC520 CPU
[03:15:32] <skunkworks> I bought some bearings - 1mmX3mmX1mm. I knew that they where going to be small - but seeing them still took me by suprise.
[03:15:58] <bytecolor> is EMC installed into /usr by default?
[03:16:22] <bytecolor> does the user have an option to install into /usr/local or elsewhere?
[03:18:15] <bytecolor> I've written a front end to apt360 (some of you may have been playing with it). The only thing is I use the _official_ version of bwidgets (jeplers Tkinter widgets), not the version that comes with EMC (I dont want the EMC dependency)
[03:21:26] <SWPadnos> if it's possible to install debian packages somewhere other than where they're designed to go, then that method should work for EMC as well
[03:21:30] <SWPadnos> I'm not sure that's possible though
[03:21:51] <SWPadnos> if you do a build, then you should be able to specify a prefix of some sort at configure time
[03:21:59] <bytecolor> nod
[03:22:30] <SWPadnos> I'm not sure of the specifics, or if the 'make install' target actually is designed around the PREFIX idea
[03:23:12] <bytecolor> ./configure --prefix=...
[03:34:53] <bytecolor> gonna install from the script on my 6.06 laptop and see where everything goes...
[03:35:13] <SWPadnos> beware - there's no "uninstall" target ...
[03:35:19] <bytecolor> s'ok :)
[03:36:04] <bytecolor> it's really only jeplers hacked version of bwidget I'm concerned with
[03:36:36] <bytecolor> the version I use (unpythonic) is the same version as the EMC, but they arent the same :)
[03:36:54] <SWPadnos> isn't unpythonic jepler's site?
[03:36:56] <bytecolor> nod
[03:37:07] <SWPadnos> how different are they?
[03:37:15] <SWPadnos> is it source code or locations?
[03:37:43] <bytecolor> well some calls like to the NoteBook widget are different, If I try to use jeplers version, it doesnt work, but if I grab the unpythonic ver is does
[03:38:27] <SWPadnos> when you say "jepler's version", are you talking about the version included with EMC?
[03:38:34] <bytecolor> nod, sorry
[03:38:43] <SWPadnos> ok - got kind of confusing there ;)
[03:38:48] <bytecolor> actually both are his :)
[03:38:55] <SWPadnos> right - hence the confusion
[03:39:16] <bytecolor> very nice set of widgets
[03:39:30] <bytecolor> took me a while to figure them out, but still very nice
[03:39:57] <ds3> fwiw, --prefix works
[03:40:03] <bytecolor> nod
[03:40:21] <bytecolor> I've actually built EMC on this box, but I never installed it, I just run axis from the source dir
[03:40:53] <bytecolor> I'd like to eventually call axis from my app
[03:41:03] <SWPadnos> did you build for run-in-place?
[03:41:07] <bytecolor> yes
[03:41:21] <SWPadnos> ok - else you get funny path issues from time to time
[03:41:34] <bytecolor> I just run the script that sets up the environment vars
[03:41:48] <SWPadnos> ok, that works
[03:42:35] <bytecolor> well that didnt take long, lets see if axis works on the lappy
[03:44:22] <bytecolor> and there it is, cool
[03:46:36] <bytecolor> I need some way to tell if EMC's version of bwidget is installed
[03:47:34] <cradek> bytecolor: I'm puzzled by this whole thing, because I think emc2 uses the system bwidget package
[03:48:10] <bytecolor> there is no ubuntu bwidget package afaik, not one with python bindings
[03:48:31] <cradek> Filename: pool/universe/b/bwidget/bwidget_1.7.0-1_all.deb
[03:48:50] <cradek> the one we use is in universe
[03:48:51] <bytecolor> that's the Tcl/Tk widget set
[03:49:04] <bytecolor> no python bindings
[03:49:17] <cradek> oh ok
[03:49:20] <cradek> * cradek <- clueless
[03:49:56] <bytecolor> jepler has the pybwidget package specifically for python, well I'm kind of groping myself here ;)
[03:50:27] <bytecolor> I'm sure jepler can shed some light
[03:50:56] <cradek> surely
[03:52:07] <bytecolor> if you do a dpkg -L bwidget you'll see there are no .py? files. all .tcl as far as code goes
[03:52:33] <cradek> yes I see the wrapper bwidget.py now
[03:52:56] <cradek> it is gpl - why not just copy it into your project
[03:53:16] <bytecolor> I could I suppose...
[03:53:43] <cradek> it's just one simple file of wrappers - then you can use the system bwidget too
[03:53:43] <bytecolor> I think you guys did a lot of that eh?
[03:53:50] <bytecolor> with opengl and togl
[03:54:05] <cradek> yes because those didn't exist in system packages, or were broken
[03:54:12] <bytecolor> nod
[03:57:54] <bytecolor> man I've went through so many gui changes, started with GLUT, tried wxPython (gl widget sucked) tried Tkinter (missing too much stuff) and finally... bwidgets
[03:58:32] <bytecolor> dont want to use PMW, or tix
[03:58:47] <bytecolor> bwidget seems to fill in a lot of the missing pieces of Tkinter
[03:59:58] <bytecolor> the pybwidget on unpythonic actually installs it's own version of the .tcl files :/
[04:00:41] <bytecolor> and I dont know how those clash with the debian bwidget packages, but I have the all installed on this box, it's just a matter of what binds tighter in the path
[04:01:14] <bytecolor> kwazy! :)
[04:06:49] <bytecolor> here's a screenshot of what I'm working on ->
[04:07:04] <SWPadnos> cool
[04:07:44] <cradek> wow
[04:07:48] <cradek> you might get me to learn apt
[04:08:15] <bytecolor> hehe, apt is really cool, but yeah, kind of a steep learning curve
[04:08:22] <cradek> yes appears that way.
[04:08:33] <cradek> sort of hard to build too - I tried (only briefly)
[04:08:47] <bytecolor> the guy that wrote the apt360 processor that my app is a front end for has been working on a post processor for EMC
[04:08:50] <cradek> it could use some polishing and packaging
[04:08:57] <bytecolor> nod
[04:10:08] <cradek> I thought someone (tom?) said only a couple lines (start and end) needed tweaking
[04:10:23] <bytecolor> I've got vapt set up as a package, using distutils, but I dont want to release it until I get this bwidget figured out.
[04:10:38] <bytecolor> cradek, what do you mean?
[04:10:49] <cradek> the gcode needed only very slight tweaking
[04:11:26] <cradek> I'm off to bed - can't type straight anymore
[04:11:29] <bytecolor> ah, well it's getting better, he may have been referring to the % at the start/end not sure
[04:11:28] <cradek> goodnight
[04:11:32] <bytecolor> nite
[04:11:37] <SWPadnos> see you
[04:14:29] <bytecolor> I should crash too, gotta finish laying some tile tomorrow (ugh)
[04:14:58] <SWPadnos> urk
[04:15:11] <SWPadnos> night. I suppose I should hit the sack as well
[04:15:23] <bytecolor> seeya SWPadnos
[04:16:41] <a-l-p-h-a> weird...
[04:16:49] <a-l-p-h-a> logger_emc, bookmark
[04:16:49] <a-l-p-h-a> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2007-04-14.txt
[04:17:13] <a-l-p-h-a> hydra was being weird... I wasn't in the chan, but appearantly I was.
[05:21:11] <chr0n1c> anyone awake?
[05:21:25] <chr0n1c> i thought i'd let you know the peck drilling cycle works great
[05:21:32] <chr0n1c> for my machine...
[06:30:48] <toastyde1th> toastyde1th is now known as toastydeath
[08:22:05] <lerneaen_hydra> a-l-p-h-a: err, what was I doing?
[10:05:29] <Rugludallur> hmmf, I am pretty sure the sum component is broken in trunk, anyone here willing to verify ?
[10:08:48] <alex_joni> Rugludallur: how so?
[10:09:02] <Rugludallur> alex_joni: no matter what the input pins, output is always 0
[10:09:12] <alex_joni> did you addf?
[10:09:17] <Rugludallur> alex_joni: yup
[10:09:23] <alex_joni> you sure?
[10:09:33] <Rugludallur> alex_joni: more than sure, I tripple checked :D
[10:09:49] <Rugludallur> addf sum2.0 servo-thread
[10:09:50] <Rugludallur> 52 addf sum2.1 servo-thread
[10:09:53] <alex_joni> can you pastebin the output from halcmd show ?
[10:09:59] <Rugludallur> alex_joni: just a sec
[10:10:08] <alex_joni> and you are havign issues with both sum2's ?
[10:10:10] <alex_joni> or just one?
[10:10:29] <Rugludallur> alex: http://pastebin.ca/439534
[10:10:35] <Rugludallur> alex_joni: same with all sum pins
[10:11:18] <alex_joni> wtf are lines 9..14
[10:11:52] <Rugludallur> alex_joni: beats me
[10:12:11] <Rugludallur> alex_joni: all I did was halcmd show |grep su
[10:12:20] <Rugludallur> alex_joni halcmd show |grep sum
[10:13:07] <Rugludallur> alex_joni: relevant config: http://pastebin.ca/439537
[10:13:38] <Rugludallur> alex_joni: I see the error now what I posted
[10:14:19] <alex_joni> Rugludallur: to make it easy..
[10:14:21] <Rugludallur> alex_joni: wait, that's not an error that's just me being dislexic :P
[10:14:32] <Rugludallur> alex_joni: want me to do a simple config ?
[10:15:17] <alex_joni> make sure the gains are not zero
[10:15:27] <alex_joni> out = in0 * gain0 + in1 * gain1 + offset;
[10:15:34] <alex_joni> that's the sum2 function
[10:16:04] <alex_joni> http://www.linuxcnc.org/docs/devel/html/man/man9/sum2.9.html
[10:16:16] <Rugludallur> alex_joni: hmm,, that is different from how the old comp sum behaved
[10:16:22] <alex_joni> I *think* they might default to zero
[10:16:47] <Rugludallur> alex_joni: they do
[10:17:05] <alex_joni> ok, so it works now.. I hope
[10:17:14] <alex_joni> Rugludallur: can you be a sport and add it here: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UPDATING ?
[10:17:18] <alex_joni> * alex_joni needs to run
[10:17:36] <Rugludallur> later
[10:17:46] <alex_joni> ok.. bye
[10:18:07] <alex_joni> btw, a short hint: man sum2
[10:18:25] <alex_joni> if you use run-in-place always do : ". scripts/emc-environment"
[10:18:38] <alex_joni> then man and co work as expected
[10:18:40] <alex_joni> bbl
[10:19:20] <Rugludallur> thanks
[11:21:03] <tomp> Rugludallur: some files that end in .comp may have very new man files.
[11:21:10] <tomp> the man file is created from the .comp file by this command "comp --document somefile.comp"
[11:21:19] <tomp> this will create a somefile.9 man file in the current directory.
[11:21:20] <tomp> This is what I used to get docs on some files, else I inspect the source for hal-pin and hal-param.
[11:25:35] <Rugludallur> tomp: ok, I reported a bug also, I think the default gain should be 1 :)
[11:25:46] <Rugludallur> tomp: but I should also be more carefull to read the docs :D
[11:52:04] <Rugludallur> I'm thinking about extending the comp (Two input comparator) component to include a bit pin which is set high only when the two inputs are exactly equal, any thoughs ?
[11:52:54] <Rugludallur> I find it a bit silly to use two "comp" and and an "and" component to achive this
[12:00:05] <tomp> Rugludallur: look at the docs for the program 'comp' ( in the hal manual ). you can write a brand new custom comp, its just a text file, and you have the other sources to model from, then build it and use it.
[12:00:43] <tomp> Rugludallur: to begin, just look at a simple .comp file
[12:01:09] <Rugludallur> tomp: it's not a problem, I just don't like doing stuff unless I think it has a chance of being accepted into trunk
[12:03:02] <tomp> this is kind of meant to be a solution for special needs, so might never get into trunk unless it has some precedent ( like it emulates an Xor gate or some other common primitive )
[12:03:51] <Rugludallur> tomp: the reason I brought it up is that I don't see any clear way to compare two float values to see if they are equal, only if one is larger than the other
[12:04:23] <Rugludallur> tomp: which I think is a pretty fundamental feature :D
[12:05:50] <tomp> there is no equal comp? yes, thats fundamental enuf. no need for op-amp like tools to say 2 floats are same
[12:08:42] <tomp> maybe use the sum2 but make the gain of one input -1 and the other +1, the output would be 0 when the 2 inputs were equal ( not a boolean0, a float 0 )
[12:09:49] <Rugludallur> tomp: that would then need to be converted to bit
[12:10:16] <Rugludallur> tomp: imho comp should just have an equal out pin ,, which would use the histerisis as well
[12:10:42] <tomp> so it could be 'close enuf' ?
[12:10:49] <Rugludallur> tomp: yup
[12:10:57] <Rugludallur> tomp: with many pos signals they don't match 100$
[12:11:00] <Rugludallur> tomp: err 100%
[12:23:42] <tomp> will this help ? http://pastebin.ca/439616
[12:24:06] <tomp> untested ( ready for you to test :)
[12:24:32] <Rugludallur> tomp: hehe I'm compiling over here to :D
[12:26:08] <tomp> i need to make an auto symbol generator for .comp files, so gEDA can draw schematics with a 'net list' and a library of .comp files
[12:26:16] <Rugludallur> tomp: my approach is a bit different http://pastebin.ca/439618
[12:26:38] <tomp> yep
[12:27:49] <tomp> we both assume one state and change it if neccesary, that always saves 1 line of code :) ( guilty till proven innocent :)
[12:28:58] <Rugludallur> tomp: I tried to re-use as much of the existing logic for performance reasons, but It's not nearly as clear as yours
[12:30:21] <tomp> the 'style' of emc is to be separate, i code more like you wrote ( where's the ternary op ?? )
[12:31:24] <Rugludallur> tomp: I'll use your code and test it :D
[12:55:10] <Rugludallur> tomp: http://pastebin.ca/439650
[12:55:23] <Rugludallur> tomp: that works great :D
[12:55:33] <tomp> super!
[12:56:48] <tomp> doh! && :-[
[12:57:15] <Rugludallur> tomp: :) python does that to you :D
[13:09:53] <lerman> Rugludallur: I would code that slightly differently. In the case where equ is true, there is no need to test out. If the values are within the hysteresis band, the output doesn't change.
[13:12:27] <Rugludallur> lerman: right, put it inside an if (equ)
[13:12:35] <lerman> Then, no need to test out. if tmp is negative out = 0 else out = 1
[13:13:22] <lerman> out = (tmp < 0) ? 0 : 1 // replaces the if(out) stuff.
[13:13:45] <Rugludallur> lerman: the other option would be to use the same if statements as the out stuff
[13:14:48] <Rugludallur> lerman: I'll see if I can wrap my head around implementing those changes :D
[13:16:43] <lerman> Can we code it so that the assy language has no branches? Branches are the most expensive part of most code.
[13:17:06] <lerman> (How fast is fast enough?)
[13:17:57] <Rugludallur> lerman: I'm hoping to replace the comp in trunk with this so fast is good
[13:19:15] <lerman> I agree -- but change the word 'hoping' to 'going' :-)
[13:20:19] <Rugludallur> lerman: I don't control what gets accepted :D
[13:20:55] <lerman> I don't like the fact that the divide by two is done each time through the loop. Is it possible to compute hist/2 at init?
[13:22:54] <lerman> I guess I'm asking if there is an init function that is executed and a way to have statics (I'm not familiar with the structure of components.)
[13:26:17] <Rugludallur> lerman: it would be even easier to just define it as the distance from the point to either of the edges
[13:27:07] <lerman> That's true. The question is which is more intuitive to the user.
[13:28:22] <Rugludallur> lerman: I first used that feature today and initially I thought it was the single distance, not the band ,, but that's just me
[13:29:09] <lerman> Just make sure the code matches the docs and either way would be fine, I think.
[14:06:12] <tomp> the code documents itself comp --documentation somefile.comp thats what the strings are about, and maybe use halfHyst as the parameter to avoid div math.
[14:10:36] <Rugludallur> hmm . the problem with comparing floats is that float calculations are never absalute, so people might experience some perceived wierdness unless they specify hyst
[14:10:49] <Rugludallur> do you guys think it's OK to just document this or ?
[14:13:56] <Rugludallur> lerman: I think this is optimal for performance: http://pastebin.ca/439733
[14:15:09] <tomp> maybe like this? http://pastebin.ca/439732 oh, whats lerman done? same diff, we're into style, i dont see performance being an issue, this is some cyclical update yes?
[14:16:29] <Rugludallur> tomp: well it's run as a part of servo-thread in my case
[14:16:48] <lerman> Nested ifs are hard to read:
[14:17:08] <tomp> Rugludallur: sorry , i see you wrote that last paste, looks fine. can we put comments into these?
[14:17:53] <tomp> are there #defines ? 0 = LESS, 1= MORE ??
[14:18:23] <Rugludallur> lerman: I started with an elif and got error so the option is to move the second if out, would that be a better option?
[14:18:57] <lerman> something like
[14:18:58] <lerman> equ = 0;
[14:19:01] <lerman> if(tmp <-hyst) out = 0;
[14:19:01] <lerman> else if (tmp > hyst) out = 1;
[14:19:03] <lerman> else equ = 1
[14:19:16] <Rugludallur> lerman: gotja
[14:21:32] <lerman> On the other hand, the compiler might make all of them the same. Modern compilers are smart enough to optimize the code quite nicely. Also, modern machines are so fast that branches tend to be more expensive than anything else.
[14:22:36] <Rugludallur> lerman: i'm pushing mine to the limit because I need a whole bunch of steps (base thread runs at 15000)
[14:23:24] <lerman> Can't hurt to optimize.
[14:23:27] <Rugludallur> how abuot http://pastebin.ca/439740
[14:23:55] <Rugludallur> do you guys think it's clear for users that float comparison will fail if they try to compare prime float values ?
[14:24:01] <Rugludallur> unless they specify a hyst
[14:25:23] <Rugludallur> no wait, that should not happen,,,,,,
[14:27:29] <Rugludallur> hmm must be that stepper cmd and fb are get truncated somewhere in my views because some of the comparisons seem to fail unless hyst is set to > 0
[14:30:13] <lerman> Looks good, but there is (possibly)still room to optimize. Issues: (1) out is stored even if it is not changed. Memory writes are expensive (2) branches are expensive.
[14:30:14] <lerman> Instead of the test for the sign of a floating value: out =~( msb of float). One could do that with ugly, hard to read, nasty casts and shifts. I suspect that the cost of invoking this function is considerably higher than any savings to be made by further optimization.
[14:30:16] <lerman> Don't waste any time looking at the above thoughts. In fact, don't even read the above. :-)
[14:40:12] <tomp> the last post is very readable, note that even the < and > are 'fuzzy' with floats ( just like '=' is fuzzy near the edges ). you can also 'compile' the comp so that it just leaves the 'c' source in the current directory, and inspect that code. ( the .comp is an intermediate 'language' that a python toll converts to c )
[14:40:42] <tomp> s/tool/tool
[14:40:53] <tomp> :) s/toll/tool
[14:42:43] <feoc> hello
[14:43:14] <feoc> anyone about?
[14:43:27] <feoc> having an issue when trying to pid tune the mill
[14:43:38] <feoc> seems to be running really slow on the jogs
[14:43:53] <feoc> measured it at the signal out and its only doing 2v
[14:47:30] <tomp> feoc: i dont know how to do this in emc, but on a lot of machines,
[14:47:41] <tomp> i'd place the axis in 'open loop', and maybe even uncouple the motor's transmission from the joint.
[14:47:47] <tomp> then I'd figure what my max velocity (or rpm ) was,
[14:47:57] <tomp> and find what voltage was necessary to make that happen ( assuming servo drive and analog amp ).
[14:48:01] <tomp> Then i'd make sure the control system ( emc) output that voltage when max velocity was requested.
[14:48:22] <feoc> how do you put it in open loop?
[14:48:50] <tomp> dunno, thats the 1st thing i said ;)
[14:49:04] <feoc> :(
[14:49:22] <feoc> id expect to see +- 10v for my amp
[14:49:24] <tomp> i know what it means... to allow you tyo exercise the axis without the control trying to change the control signal
[14:49:42] <feoc> yah i know
[14:49:48] <feoc> just dunno how to do it in emc :(
[14:49:49] <feoc> lol
[14:50:27] <tomp> ok, +/- 10, leave a bit of 'headroom for quick reversals... maybe 7.5 or 8 v for max vel ( control can force 10 to quick stop or reverse )
[14:52:58] <tomp> if you tune the amp to use rail to rail for the working envelope, you cant cope with any more, you'll have plenty of 'resolution' if you use +/-7.5v for min to max velocity.
[14:53:23] <tomp> and 'doing it in emc' may not be neccesary ( in this way...)
[14:54:12] <tomp> tune with a battery and a pot untill say 7.5V gets min/max velocity, then the emc part is just getting it to give 7.5V at max vel. you separate the problem into simpler parts.
[14:54:17] <feoc> yah
[14:54:45] <feoc> well i can feed 6-7v into the amp
[14:54:53] <feoc> runs quite nice
[14:55:30] <tomp> can you 'scale' the input ( turn a gain pot) so it moves at max velocity with just 6-7v?
[14:55:41] <tomp> (and stay nice )
[14:58:06] <feoc> iv tryed that
[14:58:13] <feoc> the servo amp starts acting a bit nutty
[15:05:56] <feoc> right ill go playt
[15:06:02] <feoc> see if i can set DAC scaling
[15:06:10] <tomp> IF the control never ever tries to output a voltage greater than 10V then tuning max velocity at 10V is fine.
[15:06:17] <tomp> A lot of controls will go past that value in attempting to reverse or brake.
[15:06:23] <tomp> For emc, please ask a developer.
[15:06:39] <feoc> ok
[15:06:40] <tomp> I'll be doing some of this soon & re-acquaint myself with the .ini parameters ,
[15:06:41] <tomp> i expect a value that specifies the voltage required to achieve max velocity for such a system.
[15:06:46] <feoc> even if i can just get it a bit higher
[15:06:56] <feoc> at the mo 2v is just too slow
[15:07:16] <tomp> yeh, not what you want at all
[15:07:40] <feoc> no point trying to tune the pid untill its moving properly
[15:08:20] <feoc> catch you later
[15:08:26] <tomp> right, get the amp right, then the control loop, bye
[16:18:36] <jmkasunich> hi guys
[16:18:43] <jmkasunich> regarding the changes to comp:
[16:19:02] <jmkasunich> 1) we don't want to change the meaning of "hyst" as seen by the user
[16:19:23] <jmkasunich> 2) hyst is a parameter that can be changed by the user at any time, so we can't do the divide by 2 at init time
[16:20:16] <jmkasunich> 3) we can do "halfhist = 0.5 * hyst" at the beginning of the funct and use that everywhere else
[16:20:47] <jmkasunich> I bet gcc is smart enough to turn "hyst/2" into "hyst * 0.5" anyway
[16:22:54] <jmkasunich> Rugludallur: regarding "I just don't like doing stuff unless I think it has a chance of being accepted into trunk"
[16:23:19] <jmkasunich> if you send a ssh key to cradek, you can be added as a developer and commit it yourself
[16:24:12] <jmkasunich> "accepted" implies that there is some elite group that approves everything... I prefer to work by concensus, and as long as everybody involved is reasonable that works
[16:25:08] <jmkasunich> your addition to comp is quite reasonable (the reason I didn't do equ originaly is that true analog signals are never equal... but the addition of hyst makes it a meaninfull thing, and a good addition to the compoent
[16:27:35] <jmkasunich> feoc: you still around?
[16:33:35] <CIA-19> 03jmkasunich 07TRUNK * 10emc2/src/hal/components/sum2.comp: make sum2 gains default to one, not zero, per the 'principle of least astonishment' - by default, a summer should sum its inputs
[17:07:55] <robin_sz> hi jmkasunich
[17:08:07] <Rugludallur> jmkasunich: I was afk, I already have commit to cvs, I just like to run things past other people first :D
[17:08:28] <CIA-19> 03jmkasunich 07v2_1_branch * 10emc2/src/hal/components/sum2.comp: backport: change default gains for stepgen to 1.0
[17:08:34] <CIA-19> 03jmkasunich 07v2_1_branch * 10emc2/debian/changelog: document recent fixes
[17:08:52] <jmkasunich> Rugludallur: ok
[17:18:36] <robin_sz> * robin_sz has another look at what tuxcnc is up to ...
[17:19:09] <Rugludallur> jmkasunich: what do you think about ?
[17:19:10] <Rugludallur> http://pastebin.ca/439948
[17:20:06] <jmkasunich> looks good do me...
[17:20:16] <jmkasunich> you've built it and looked a the generated man page?
[17:20:42] <jmkasunich> I'm curious about the blank line in the hyst description (line 8)
[17:20:53] <jmkasunich> does the man page look right?
[17:20:54] <cradek> "hyst" not "hist" in the docs
[17:21:03] <jmkasunich> duh, right
[17:21:11] <cradek> how about equal instead of equ for the pin?
[17:21:24] <cradek> to me 'equ' is equate
[17:21:42] <Rugludallur> cradek: i'm with you, I prefer equal
[17:21:43] <jmkasunich> yeah, letters are cheap
[17:23:24] <lerman> I tend to prefer something like "isEqual" for a boolean value.
[17:23:41] <jmkasunich> not for hal pins
[17:24:01] <lerman> right.
[17:39:43] <CIA-19> 03cradek 07v2_1_branch * 10emc2/nc_files/holecircle.py: remove debug output
[17:40:44] <CIA-19> 03cradek 07v2_1_branch * 10emc2/src/ (configure configure.in): fix holecircle (EMC2_HOME in the env)
[17:41:05] <CIA-19> 03cradek 07v2_1_branch * 10emc2/debian/changelog: holecircle fix
[17:41:46] <Rugludallur> I have tested and verified that gantrykins works great on a real life machine, any thoughs on commiting it to trunk ?
[17:42:49] <CIA-19> 03cradek 07TRUNK * 10emc2/src/ (configure.in configure): always set EMC2_HOME properly
[17:43:15] <robin_sz> * robin_sz briefly wonders how a gantry kinematics is not hte same as plain old x y z
[17:43:43] <Rugludallur> robin_sz: think about syncing up two motors for the same axis (two joints, one axis)
[17:44:06] <robin_sz> one axis, two motors?
[17:44:25] <Rugludallur> robin_sz: yup , it's a gantry driven on both sides
[17:44:32] <robin_sz> oh, right
[17:44:36] <CIA-19> 03cradek 07TRUNK * 10emc2/nc_files/holecircle.py: remove debug output
[17:45:04] <robin_sz> i knew it was possible, didn;t know anyoen had such a machine
[17:46:15] <Rugludallur> robin_sz: http://dallur.com/index.php?id=44&tx_lzgallery_pi1[subg]=10&tx_lzgallery_pi1[showUid]=41&tx_lzgallery_pi1[old]=5x5x1&tx_lzgallery_pi1[pic]=23&tx_lzgallery_pi1[colrows]=1x1
[17:48:10] <robin_sz> intersting
[17:48:48] <robin_sz> you think those nice linear rails will survive?
[17:49:11] <Rugludallur> robin_sz the dust, I hope so :D
[17:49:29] <Rugludallur> robin_sz: if not I have 4 spares :P
[17:49:53] <robin_sz> well, they don't normally last long if the dust gets near
[17:50:05] <robin_sz> nice glavanising though
[17:50:25] <Rugludallur> robin_sz: yeahh, I had the whole thing dipped as one piece :D
[17:50:27] <robin_sz> what are the bolts with the discs on top for?
[17:50:35] <Rugludallur> robin_sz: those are for the steel plates
[17:50:47] <robin_sz> oh ... hmm
[17:50:53] <robin_sz> the actual metal to be cut?
[17:51:04] <Rugludallur> robin_sz: yup they hold the metal to be cut
[17:51:09] <robin_sz> oh ...
[17:51:22] <robin_sz> you know its nor normal to use spikes?
[17:51:38] <Rugludallur> robin_sz: it's not, usually people use flat bars bent in S
[17:51:54] <Rugludallur> robin_sz: kinda like strips of corrugated iron
[17:52:16] <robin_sz> they are not usually flat on top, usually wobbly profile
[17:53:05] <robin_sz> I guess those bolts will work if you can arrange your cuts not to hit them
[17:53:38] <Rugludallur> robin_sz: it should be ok for the cuts to hit them actually
[17:53:56] <Rugludallur> robin_sz: they should deflect to the sides
[17:54:01] <robin_sz> err
[17:54:28] <Rugludallur> robin_sz: I don't want to start a cut on one though :D
[17:55:16] <robin_sz> well, I woudl expect the cut to be severly affected as it passes over that
[17:57:00] <robin_sz> the other lokely problem is you have only very few support bars, parts are going to tip up and catch the torch
[17:57:23] <robin_sz> but the machine does look nice .. especially the ally side plates
[17:57:24] <Rugludallur> robin_sz: yeahh, but all my pieces are like 1mx 5m
[17:57:41] <robin_sz> ahh, then that will be fine
[17:57:44] <cradek> are any of you
[17:58:09] <Jymmm> http://whatismyip.com/
[17:58:12] <Jymmm> nope
[17:58:21] <Rugludallur> nope
[17:58:49] <Jymmm> h-69-3-68-239.sfldmidn.dynamic.covad.net
[17:58:58] <cradek> maybe it's jmk
[17:59:46] <robin_sz> using 6 x 2m sheets?
[17:59:50] <Rugludallur> robin_sz: the actual area of those bolt heads that touches the plate is very very small, maybe a square mm not more, they are quite a bit rounded
[17:59:54] <Rugludallur> robin_sz: yup
[18:00:17] <Jymmm> cradek: http://h-69-3-68-239.sfldmidn.dynamic.covad.net/cgi-bin/blosxom/index.html
[18:00:56] <cradek> heh answers that, doesn't it
[18:01:00] <Jymmm> =)
[18:01:22] <Jymmm> It's funny how many people think they are "anonymous" on the internet =)
[18:04:02] <Jymmm> Yah, taxes done.
[18:06:17] <Jymmm> cradek: Since you picked ubuntu as the distro for emc, thought you might have an idea... Can you think of why the live cd can do the grpahics fine, but on certain machines when you install, it's snafued?
[18:06:33] <Rugludallur> doesn
[18:06:54] <Rugludallur> doesn't the install cd use only VESA drivers ?
[18:06:59] <cradek> Jymmm: that's not enough information to guess
[18:07:09] <cradek> Rugludallur: no I think it does a similar detection
[18:07:22] <cradek> but true, using the vesa driver might fix the machine
[18:08:14] <Jymmm> But I would suspect that LIVE would be "worse off" than an acutal install.
[18:10:02] <cradek> well obviously it's doing something different - figure out what, and there's your answer
[18:10:18] <cradek> for instance, look at xorg.conf when booted live, then compare it with the installed one
[18:10:19] <Jymmm> lol, yeah right!
[18:10:26] <cradek> no, I'm serious
[18:10:33] <cradek> it's not magic, you have to troubleshoot
[18:10:35] <Jymmm> oh, ok. I thought you meant go thru the source code
[18:12:21] <robin_sz> Rugludallur, what are you going to do underneath to catch the fumes?
[18:13:05] <Jymmm> don't fumes rise?
[18:13:10] <robin_sz> I guess you could always paint the room orange-brown so it wont show up :)
[18:13:39] <robin_sz> Jymmm, on plasma all the fumes are underneath the plate
[18:13:42] <robin_sz> nothing on top
[18:13:51] <Jymmm> ah
[18:14:18] <robin_sz> normally, you put a big box and a few huge fans to suck them out and through a vent .. or an elecrostaic seperator
[18:15:20] <robin_sz> you don't want to breathe it in though.
[18:16:40] <robin_sz> anyone about to eat?
[18:17:29] <robin_sz> before you do .. look at this very hungry elephant video (scroll down past the semi-naked chicks at the top)
[18:17:32] <robin_sz> http://www.porkolt.com/funny/animals/elephants/zoo/gross-35095.html
[18:19:19] <Rugludallur> robin_sz: for now I'm going going to do anything about the plasma dust, actually I'm giong to move it outside while cutting, I won't be cutting enough to justify spending the work on a sysetm
[18:20:02] <Rugludallur> robin_sz: originally I was going to make a bath, I can always add it later though
[18:20:38] <robin_sz> just cover in the sides and get a real big fan ...
[18:21:00] <robin_sz> water baths only work if yo submerge the sheet
[18:21:15] <Rugludallur> robin_sz: I can actually do that if I want (the design allows it)
[18:21:47] <Rugludallur> robin_sz: but untill I get everything else working i'm just going to leave it as is
[18:23:56] <jmkasunich> cradek: why were you asking about that IP?
[18:24:04] <jmkasunich> (yes, as you found out its me)
[18:24:38] <robin_sz> Rugludallur, I thnk you will be suprised just how much fume it makes
[18:25:28] <robin_sz> Rugludallur, you've cut with hand plasma right?
[18:28:46] <Rugludallur> robin_sz: yup, and I know it makes a huge mess and it's really fine dust and gets everywhere
[18:29:00] <Rugludallur> robin_sz: but when it's outside I don't really care :D
[18:29:37] <Rugludallur> robin_sz: the whole table is on wheels, it's trailerable to :D
[18:31:34] <robin_sz> ahh right
[18:31:38] <robin_sz> outside it will be fine
[18:32:05] <robin_sz> it does make about 5 times as much fume as a hand plasma though
[18:32:08] <jmkasunich> Rugludallur: you are insane you know....
[18:32:30] <jmkasunich> * jmkasunich refers to the argon filled computer
[18:32:32] <robin_sz> or, it makes the same amount of dust, but in 1/5th of the time
[18:33:39] <robin_sz> either way, its much more extreme than a hand plasma
[18:34:47] <Rugludallur> jmkasunich: it's the only sensible way to cool a cpu to -20/-40, no better way to keep condensation away :D
[18:35:14] <Rugludallur> robin_sz: If it becomes to much I will do something about it :D
[18:35:55] <robin_sz> you could just buy a faster CPU?
[18:36:03] <robin_sz> run it at sane temperatures?
[18:36:05] <Rugludallur> robin_sz: now where is the fun in that :P
[18:37:47] <feoc> evening all
[18:38:23] <feoc> had a bit of an ebay slip today
[18:38:24] <feoc> http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&ih=007&sspagename=STRK%3AMEWA%3AIT&viewitem=&item=170098544213&rd=1&rd=1
[18:38:25] <feoc> lol
[18:39:50] <Rugludallur> feoc: now for the converting :D
[18:41:03] <cradek> shipping free! haha
[18:41:40] <feoc> nah i think ill leave that one manual
[18:41:51] <robin_sz> coo, biggish mill
[18:42:03] <robin_sz> gotta be ... 3, 4 tonnes?
[18:42:03] <feoc> robin_sz its small comprared to my CNC
[18:42:10] <feoc> thats about 2 ton
[18:42:28] <robin_sz> looks solid
[18:42:47] <feoc> yeah i want it for skimming and cylinder boring
[18:42:49] <robin_sz> a bp is about 1800 kg
[18:42:59] <robin_sz> that looks a lot heavier
[18:43:02] <feoc> so wanted somthing with a sturdy turret
[18:43:06] <feoc> could be
[18:43:11] <feoc> my hurco mill was 4 ton
[18:43:35] <feoc> http://img.photobucket.com/albums/v280/rallyslag/31012007175.jpg
[18:44:02] <robin_sz> nice
[18:44:08] <robin_sz> before or after delivery
[18:44:12] <feoc> thats after
[18:44:29] <robin_sz> was this the one on ebay with a faulty control?
[18:44:44] <feoc> quite possibly
[18:45:28] <robin_sz> I keep looking at mills, never quite get around to buying one
[18:45:38] <feoc> got that lathe at the same time
[18:45:43] <robin_sz> I fancy a waterjet or a wire
[18:45:51] <feoc> that thing weighed 6+ ton
[18:45:54] <robin_sz> got em working yet?
[18:46:01] <feoc> working on the mill at the moment
[18:46:06] <feoc> got basic movments now
[18:46:15] <robin_sz> right
[18:46:21] <robin_sz> on the original control?
[18:46:26] <feoc> nope
[18:46:39] <robin_sz> emc?
[18:46:42] <feoc> :)
[18:46:43] <feoc> yarp
[18:46:54] <robin_sz> you should have fun with toolchange :)
[18:47:03] <feoc> heh tell me about it
[18:47:34] <robin_sz> i was discussing this with another channel member last week
[18:48:07] <feoc> think it will be done via classic ladder
[18:48:14] <feoc> not looked too much into it yet
[18:48:17] <robin_sz> indeed
[18:48:26] <feoc> too engrossed in this PID tuning stuff
[18:48:41] <robin_sz> he was stuck getting classic ladder to move the machine axes ...
[18:48:58] <feoc> how did he get around it/
[18:49:05] <robin_sz> dont think he has yet
[18:49:09] <feoc> ah
[18:49:43] <robin_sz> theres some sort of problem having the machine move if the move was not commanded by the interpreter
[18:50:00] <robin_sz> after that, i forgot what the rest of it was
[18:50:03] <feoc> yeah you will get follow errors
[18:50:07] <cradek> moving to a fixed tool change location, or something more complex?
[18:50:31] <feoc> moving the Z to a set height
[18:50:44] <robin_sz> moving to a position, lowering z, activating tool chnage, raising z, moving back to where you started
[18:50:50] <feoc> then lifting up as the carousel takes tool out
[18:51:14] <cradek> ok
[18:51:34] <feoc> also involves stopping the spindle at a set point too
[18:51:45] <robin_sz> and some sort of sane procedure for if the tool_in_spindle switch doesnt get set
[18:52:05] <cradek> that's a lot of complexity.
[18:52:29] <robin_sz> its standard afaik
[18:53:07] <feoc> yah my hurco works like that
[18:53:11] <robin_sz> basically htats what commercial mills with atc do
[18:54:27] <cradek> well one style - the ones with an arm (like the mazak at fest) don't
[18:54:26] <robin_sz> obviously it can be done, because AIUI, they got atc going on the Mazak
[18:55:13] <robin_sz> I guess there at different styles
[18:55:34] <cradek> yeah that's the problem really
[18:55:43] <feoc> will be interesting getting my lathe setup with emc
[18:55:45] <cradek> coding support (in C) for any one is trivial
[18:55:56] <feoc> that has all sorts of stuff in it like drill heads and C axis ect
[18:56:20] <robin_sz> feoc, does it not have a workign control?
[18:56:37] <feoc> its flaky as hell
[18:56:41] <feoc> its a siemens system 8
[18:56:41] <robin_sz> oh
[18:57:01] <feoc> its got some feed and speed override that i cant seem to clear
[18:57:31] <robin_sz> oh
[18:57:37] <robin_sz> got the manual?
[18:57:49] <feoc> yah
[18:57:54] <feoc> its not the best tho
[18:58:07] <feoc> iv checked all the axis switches and moved axis away from them
[18:58:13] <feoc> so thats not causing it
[18:58:18] <robin_sz> emc lathe supprt is ... fairly young :)
[18:58:23] <feoc> yah i know
[18:58:27] <robin_sz> door open switches?
[18:58:39] <feoc> it knows when door is open and closed
[18:59:20] <feoc> tbh ill only be using it as a basic lathe to start with
[19:00:09] <feoc> gonna be building a plasma cutter soon aswell
[19:00:23] <feoc> so it will be good to have a EMC workshop :)
[19:02:07] <feoc> might well have to convert that sturdimill at some point for the hell of it
[19:02:28] <feoc> but id imagine id need to buy ballscrews ect to make it worthwhile
[19:04:34] <CIA-19> 03jmkasunich 07TRUNK * 10infrastructure/farm-scripts/check_cvs: longer cvs timeout, and wait before retry - ease the load on the CVS server
[19:07:56] <feoc> bbl gonna go make some dinner
[19:19:43] <jmkasunich> Rugludallur: how far along are you on the argon computer?
[19:47:25] <Jymmm> Jymmm is now known as Jymmmmmmm
[19:54:57] <Rugludallur> jmkasunich: I have not done any work on it for a long time, I have the case ready, the psus, pelter, I also have a huge block of 99.99% pure copper for the cpu blocks
[19:55:25] <Rugludallur> jmkasunich: Don't know if I will ever finish it, need more hours in the day for that :P
[19:55:46] <jmkasunich> heh
[19:56:25] <jmkasunich> what I was wondering about - even on a water cooled PC, lots of stuff is air cooled - and fresh cool air enters the case to replace hot air that leaves carrying heat out
[19:56:38] <jmkasunich> with argon, you can circulate in the case, but there is no exchange
[19:56:57] <jmkasunich> how will you get rid of the heat that is picked up by the circulating argon?
[19:57:00] <Rugludallur> jmkasunich: actually when you cool the cpu that far down the problem is not cooling the other stuff
[19:57:19] <jmkasunich> are you sure?
[19:57:35] <jmkasunich> zero air exchange with the outside world is gonna change things a lot
[19:57:35] <Rugludallur> jmkasunich: if it is then you just add a radiator
[19:57:57] <jmkasunich> a radiator inside the case, using cold water to cool the argon?
[19:58:04] <Rugludallur> jmkasunich: yup
[19:58:19] <Rugludallur> jmkasunich: another option is to have a double surface top, and water inside that
[19:58:21] <jmkasunich> that would work of course - just didn't know if you were planning for it
[19:59:07] <jmkasunich> how are you gonna seal things up tight? or will you replenish the argon as needed?
[19:59:23] <jmkasunich> things like cdrom slots will leak a lot, even things like ethernet connectors will leak
[19:59:39] <Rugludallur> jmkasunich: no cdrom slots, nothing like that
[19:59:59] <jmkasunich> nothing goes in or out except wires?
[20:00:01] <Rugludallur> jmkasunich: basically the only things in/out is DC, USB and DVI/VGA
[20:00:25] <Rugludallur> jmkasunich: and those all go through sealed connectors
[20:00:25] <jmkasunich> no network?
[20:00:43] <Rugludallur> jmkasunich: yeahh, also network
[20:01:01] <jmkasunich> you are making short extensions that go from the sealed connector at the box wall to the connectors on the PCBs?
[20:01:13] <Rugludallur> jmkasunich: yup
[20:01:24] <jmkasunich> sounds like a neat solution to hostile environments
[20:01:40] <Rugludallur> jmkasunich: yup, I plan to do a similar thing for the computers on my boat
[20:01:45] <jmkasunich> an (almost) hermetically sealed computer
[20:02:03] <jmkasunich> heh, use seawater for cooling
[20:02:15] <jmkasunich> (with a suitable heat exchanger to avoid corrosion issues
[20:02:17] <Rugludallur> jmkasunich: nahh , just use aluminium for the case
[20:02:26] <Rugludallur> jmkasunich: and conduct the heat to the case
[20:03:45] <Rugludallur> jmkasunich: I have done that with some Geode based machines without any problems
[20:35:31] <maddash> how does the use of USB input affect realtime latency in EMC?
[20:35:54] <skunkworks_> depends on the motherboard.
[20:36:36] <skunkworks_> I have a few motherboards that have issues with real time latency when a usb device is plugged in
[20:37:52] <maddash> how does it depend?
[20:38:12] <maddash> and, what about after you plug the device in?
[20:43:01] <christel> [Global Notice] Hi all, looks like one of our UK sponsors had a bit of a routing hiccup. Affected users ~2500. Normality should be restored momentarily. Thank you for using freenode and have a great day.
[20:44:28] <skunkworks_> it is when the usb device is plugged in.
[20:46:01] <asdfqwega> Can anyone help with a 'rtai_smi' problem?
[20:48:47] <skunkworks_> this issue? http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?FixingDapperSMIIssues
[20:49:16] <asdfqwega> Oh, that page tells how to get the module...just not how to get it loaded when you start EMC2
[20:49:50] <asdfqwega> ...and I've added it to /etc/emc2/rtapi.conf...but it still doesn't load :(
[20:50:10] <skunkworks_> you have to edit a file - hoping someone else would chime in here. I don't remember the exact file and location. (so that emc loads it each time)
[20:50:19] <skunkworks_> I see that it isn't on the wiki
[20:52:41] <Skullworks_PGAB> skunkworks : you have the docs on that H-bridge you are working on?
[20:53:46] <Skullworks_PGAB> last Sunday JMK help me crush some numbers and I see I have to move up to a bigger Z axis motor
[20:54:21] <jmkasunich> can't gear/belt it down?
[20:55:06] <Skullworks_PGAB> So I have a 40V Ametek 600oz/in like is sold from Camtronics
[20:55:35] <Skullworks_PGAB> will still use the Pittmans geared down for X/Y
[20:55:36] <skunkworks_> asdfqwega: you could load it manaully by doing a insmod <file name> I think
[20:56:38] <Skullworks_PGAB> I think the head weight would be too much for the other motors - overheating issues
[20:57:54] <skunkworks_> Skullworks_PGAB: http://www.cnczone.com/forums/showpost.php?p=274587&postcount=9
[20:58:00] <Skullworks_PGAB> Head is all Iron and steel - and I don't have the spindle motor mounted, and that isn't lite either.
[20:58:46] <Skullworks_PGAB> total is around or over 100lbs.
[20:59:35] <Skullworks_PGAB> skunk - thats perfect
[21:00:14] <skunkworks_> * skunkworks_ thinks that it is the latest circuit layout
[21:01:14] <jepler> https://sourceforge.net/tracker/?func=detail&atid=106744&aid=1700407&group_id=6744
[21:01:31] <maddash> is it ok if I modify the hal_parport.c source so that parport.0 (in input mode) outputs pins 2-4?
[21:01:47] <Skullworks_PGAB> skunkworks : did you mill that PCB?
[21:01:50] <skunkworks_> yes
[21:01:59] <skunkworks_> Skullworks_PGAB: yes
[21:02:00] <jepler> maddash: no, that's not likely to work. there's a erason that only a few combinations of inputs and outputs are allowed
[21:02:01] <Skullworks_PGAB> double sided?
[21:02:09] <jepler> that's a limitation of the parport hardware, not the driver.
[21:02:10] <skunkworks_> skunkworks_: yes
[21:02:42] <skunkworks_> Skullworks_PGAB: yes ;)
[21:03:16] <maddash> jepler: really? i'm looking at a doc that says that the parport hardware "will allow the input of up to 9 bits or the output of 12 bits at any one given time"
[21:03:28] <Skullworks_PGAB> could I get the G-code(s) - I have access to a 12000rpm Okuma ....
[21:03:45] <Skullworks_PGAB> and carbide engraving cutters...
[21:03:52] <skunkworks_> I don't know if I have it here. will look
[21:03:52] <feoc> oooh http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&rd=1&item=190101612536&ssPageName=STRK:MEWA:IT&ih=009
[21:04:01] <feoc> thats just begging for a cnc conversion
[21:04:43] <skunkworks_> * skunkworks_ loves horizontal machining centers
[21:04:57] <Skullworks_PGAB> DeVlieg Spiramatic - good iron!
[21:05:08] <feoc2> looks pretty solid
[21:05:42] <feoc2> feoc2 is now known as feoc
[21:06:09] <feoc> make for a nice retro fit with EMC
[21:06:14] <jmkasunich> maddash: got a URL for that document?
[21:06:19] <jmkasunich> the parport has 3 blocks
[21:06:40] <jmkasunich> pins 2-9 (8 pins) work together, they can be all in, or all out, but not mixed
[21:06:45] <maddash> http://www.beyondlogic.org/spp/parallel.htm
[21:07:22] <jmkasunich> then there are 4 pins that are the control port, always outputs on some hardware, but some boards MAY let you use them as inputs
[21:08:10] <asdfqwega> Huh...how does one get access to edit the wiki?
[21:08:16] <jmkasunich> thats a long page - where do you see something that says 2-4 can be outputs and the rest inputs
[21:08:26] <jmkasunich> asdfqwega: click on preferences at the bottom of each page
[21:08:30] <maddash> jmkasunich: the first line
[21:08:46] <jmkasunich> enter your name, leave the regular pw alone, enter the obvious 3 letter password in the admin pw box
[21:08:48] <maddash> "The Parallel Port is the most commonly used port for interfacing home made projects. This port will allow the input of up to 9 bits or the output of 12 bits at any one given time, thus"
[21:09:09] <jmkasunich> I hope you read more than the first line
[21:09:29] <maddash> have you seen the table?
[21:09:46] <maddash> http://www.beyondlogic.org/spp/parallel.htm#2
[21:09:49] <jmkasunich> yes, you can get 9 inputs (EMC can give you more than that), and you can get 12 outputs, but not at the same time
[21:10:08] <maddash> jmkasunich: i know. but that's not true in MEC.
[21:10:18] <maddash> EMC*
[21:10:22] <jmkasunich> yes - that table covers the three ports I was telling you about
[21:10:30] <jmkasunich> data, control, and status
[21:10:38] <jmkasunich> what do you mean its not true in EMC
[21:10:42] <maddash> it's either 12 inputs or 12 outputs...
[21:10:49] <skunkworks_> jmkasunich: do you know the location of the file to add the smi kernel to. isn't it modules.conf or something like that. For asdfqwega
[21:10:52] <jmkasunich> bul;
[21:10:54] <jmkasunich> bull
[21:11:02] <Skullworks_PGAB> Use struggling with a laptop - get lazy and just plug in a second LPT port via PCI card...
[21:11:14] <Skullworks_PGAB> Unless
[21:11:21] <Skullworks_PGAB> not use
[21:11:29] <feoc> why use parralel ports at all?
[21:11:35] <jmkasunich> maddash: in "out" mode, 2-9 are outputs, and the 4 control pins are outputs, total 12 out, and the 5 status pins are inputs
[21:11:36] <feoc> aint they a bit old and clunky
[21:11:44] <jmkasunich> so 12 out + 5 in
[21:11:51] <maddash> jmkasunich: no disagreement there
[21:12:03] <jmkasunich> feoc: because the price is right, and for certain uses they are all you need
[21:12:08] <skunkworks_> feoc: cheap I/O and usually comes with the old computers.
[21:12:18] <skunkworks_> 'older'
[21:12:22] <jmkasunich> "in" mode, 2-9 are inputs, as are the status pins, control is still output
[21:12:26] <jmkasunich> so 4 out and 13 in
[21:12:29] <maddash> feoc: my motherboard only has RS-232 and LPT ports..
[21:12:32] <feoc> i guess
[21:12:58] <feoc> my mesa card didnt cost all that much tho
[21:13:01] <skunkworks_> A few people here run servos with thier printer ports. :)
[21:13:29] <skunkworks_> in more ways than one.
[21:13:29] <jmkasunich> maddash: there is another mode, "X" maybe? (I didn't write it, and would have to read docs to be sure), tristates the control pins and uses them for inputs
[21:13:54] <jmkasunich> I'm not sure if you can do "in X" and "out X", or if X assumes either in or out
[21:13:58] <Skullworks_PGAB> likewise anything but an LPT is wasted on steppers usually - geckos with a higher voltage supply can out pace an LPT - but not much else can
[21:14:02] <jmkasunich> inX would be 17 inputs
[21:14:11] <maddash> jmkasunich: let's leave "X" alone for now. could you (re-)explain why halparport behaves different from what that doc specifies?
[21:14:14] <jmkasunich> outX would be 8 outputs and 9 inputs
[21:14:25] <jmkasunich> no, because I don't think it does
[21:14:34] <jmkasunich> could you explain why you think its different?
[21:14:48] <feoc> Skullworks_PGAB fair enough i guess
[21:15:41] <Skullworks_PGAB> most steppers run out of torque before they run out of step pulses
[21:15:53] <skunkworks_> Skullworks_PGAB: do you have eagle?
[21:16:00] <Skullworks_PGAB> the demo
[21:16:05] <skunkworks_> that is all you need.
[21:16:09] <Skullworks_PGAB> ok
[21:16:12] <feoc> so parralel port could run 2 servos then?
[21:16:23] <feoc> what about encoder inputs?
[21:16:41] <Skullworks_PGAB> depends on how you hook things up
[21:16:57] <jmkasunich> each axis of software servo (software PWM and software encoder counting) needs 2 outs for the PWM and 2 ins for the encoder
[21:17:10] <maddash> jmkasunich: according to the table in the beyondlogic doc, the parport allocates 11 output (not counting pin1)in output mode, and 8 input pins (again, not counting pin 1) in input mode
[21:17:15] <skunkworks_> Skullworks_PGAB: then either use cradeks eagle to gcode program or http://groups.yahoo.com/group/pcb-gcode/
[21:17:32] <Skullworks_PGAB> with geckos - encoders go back to each amp, and emc could just count the output pulses and trust the amps to follow...
[21:17:32] <maddash> jmkasunich: so, basically, parport.0.input has a bit too many inputs
[21:17:45] <feoc> how do you do software pwm and encoder counting?
[21:18:03] <jmkasunich> maddash: you are counting the ones labeled in/out twice
[21:18:06] <Skullworks_PGAB> or use a Pluto on the paraport
[21:18:12] <jmkasunich> feoc: in software ;-)
[21:18:15] <Skullworks_PGAB> thats my plan
[21:18:21] <jmkasunich> (with HAL modules)
[21:18:29] <Skullworks_PGAB> use the Pluto processor
[21:18:32] <skunkworks_> feoc: http://www.cnczone.com/forums/showthread.php?t=25929
[21:18:34] <feoc> jmkasunich anything more specific or is it non existant ?
[21:18:41] <maddash> jmkasunich: huh?
[21:19:02] <Skullworks_PGAB> or there are options using the USC
[21:19:07] <jmkasunich> feoc: I dunno what you mean... HAL as software componets that can count encoder pulses, and that can generate PWM
[21:19:41] <feoc> jmkasunich ok :)
[21:19:50] <jmkasunich> how specific do you want? you can always read the source of emc2/src/hal/components/encoder.c or emc2/src/hal/components/pwmgen.c, or their man pages
[21:20:22] <feoc> ah so hal can do it already
[21:20:36] <jmkasunich> maddash: the only way I can get 11 outs and 8 ins from that table is to count the ones that are listed as in/out both ways
[21:20:53] <jmkasunich> feoc: yes, for a couple of years now actually ;-)
[21:21:13] <jmkasunich> maddash: when you install a driver, you gotta pick one or the other
[21:21:15] <feoc> iv only been playing with emc for a month or so
[21:21:21] <feoc> never heard of hal before that
[21:21:31] <maddash> jmkasunich: huh? who said anything about 8 ins?
[21:22:04] <jmkasunich> you did:
[21:22:04] <jmkasunich> <maddash> jmkasunich: according to the table in the beyondlogic doc, the parport allocates 11 output (not counting pin1)in output mode, and 8 input pins (again, not counting pin 1) in input mode
[21:22:17] <asdfqwega> I wonder if anyone still uses serial-connected pulse generators or servo controllers
[21:22:45] <jmkasunich> maddash: I have no idea why you aren't considering pin 1...
[21:23:11] <maddash> jmkasunich: in case i wasn't clear, it's either {inp,out} = {5,11} (emc does this) or {8,8} (emc does not do this)
[21:23:45] <jmkasunich> you are not clear at all
[21:24:02] <maddash> er
[21:24:35] <jmkasunich> for starters, both 5,11 and 8,8 add up to 16, and there are 17 usable pins on the parport
[21:24:49] <maddash> so?
[21:24:54] <jmkasunich> EMC's "out" mode has 5,12
[21:25:07] <jmkasunich> EMC's "in" mode has 13,4
[21:25:12] <maddash> erm, did you read my msg? "(emc does this)"
[21:25:24] <asdfqwega> wiki on SMI updated, and SMI working properly on this machine :)
[21:25:28] <Skullworks_PGAB> sure - serial is used by the UHU and also DeskCNC
[21:25:30] <maddash> 17:25:08 <jmkasunich> EMC's "in" mode has 13,4 <---- vs. 8,8
[21:25:31] <jmkasunich> emc does NOT do 5,11, it does 5,12
[21:25:48] <tomp> picture help ? http://wiki.linuxcnc.org/uploads/geda-hal-040907.jpg
[21:25:56] <jmkasunich> maddash: there MORE than just out and in modes
[21:26:01] <maddash> jmkasunich: stop counting pin 1 for a moment
[21:26:16] <jmkasunich> why not count pin 1?
[21:26:25] <jmkasunich> what make is special>?
[21:26:53] <maddash> are you deliberately trying not to understand me?
[21:26:57] <jmkasunich> what make it special?
[21:27:28] <jmkasunich> no, I'm trying very hard to understand you, but you seem to be basing your statements on some assumption athat are not true
[21:27:40] <maddash> like?
[21:28:31] <jmkasunich> like, pin1 is special, pins 2 thru 9 are always outputs, and pins 1, 14, 16, and 17 can be used as inputs
[21:29:01] <jmkasunich> I don't know why that document lists 1, 14, 16, and 17 as in/out... on at least some parport they are out only
[21:29:06] <maddash> you just said that pin 1 was special -- how could it be an input? this is going nowhere.
[21:29:15] <jmkasunich> NO I DID NOT!!!
[21:29:25] <jmkasunich> you are the one who is treating pin 1 as special....
[21:29:34] <jmkasunich> you are the one who doesn't want to count it
[21:29:40] <maddash> 17:28:31 <jmkasunich> like, pin1 is SPECIAL, pins 2 thru 9 are always outputs, and pins 1, 14, 16, and 17 can be used as INPUTS
[21:30:09] <maddash> you're the current author of the hal_parport.c -- can i have your permission to modify it?
[21:30:14] <jmkasunich> I said that right after I said you are are making incorrect assumptions, and you said "like?"
[21:30:21] <jmkasunich> I just listed your incorrect assumptions
[21:30:45] <jmkasunich> its open source, you don't need my permission
[21:31:05] <jmkasunich> but what you are describing is not gonna work
[21:31:33] <jmkasunich> pins 2 thru 9 are a group - they are either ALL inputs, or ALL outputs
[21:32:20] <maddash> i'm not debating that
[21:32:44] <jmkasunich> this whole thing started because you talked about making 2-4 change direction
[21:32:51] <maddash> the issue here is why some pins that should be in/out are not --- i don't know how to distill that much further
[21:33:13] <jmkasunich> no pin is "in/out" once you install the driver
[21:33:16] <jmkasunich> it is either in, or it is out
[21:33:33] <jmkasunich> when you install the driver, you tell it which way you want it
[21:33:54] <maddash> read the table, and compare it to p54 of the parport doc
[21:34:35] <maddash> note pins 14, 16 and 17
[21:35:03] <jmkasunich> I assume you mean the HAL doc, not the parport doc
[21:35:06] <jmkasunich> opening now
[21:36:25] <jmkasunich> in the doc, 14, 16, 17, (and 1, I dunno why you insist on treating it separately) are always outputs
[21:37:07] <Skullworks_PGAB> Skunkworks: 15v ?
[21:37:10] <jmkasunich> thats because regardless of what that webpage says, those pins are not usable as inputs on all cards, only on some cards
[21:37:34] <Jymmmmmmm> Not to be a smartass, but can't you make any paraport pin anything you want from within emc?
[21:37:43] <jmkasunich> Jymmmmmmm: no
[21:37:45] <jmkasunich> smartass
[21:37:52] <jmkasunich> some pins are in, some are out
[21:37:53] <maddash> Jymmmmmmm: how i wish that were true
[21:37:58] <jmkasunich> some can be switched, but only some
[21:38:05] <maddash> 'Below is a table of the "Pin Outs" of the D-Type 25 Pin connector and the Centronics 34 Pin connector.'
[21:38:32] <maddash> doc doesn't seem to place any constraints on the parport type
[21:38:57] <jmkasunich> what are you talking about?
[21:39:38] <maddash> i'm contesting your, "those pins are not usable as inputs on all cards, only on some cards"
[21:40:13] <jmkasunich> only on some cards, because not every card manufacturer designs their cards the same
[21:40:25] <jmkasunich> for running a printer, those pins are ALWAYS outputs
[21:40:41] <jmkasunich> and the original printer port specs had them always outputs
[21:40:53] <jmkasunich> cards built to that spec won't let you use them as inputs
[21:41:15] <jmkasunich> in fact, the very earliest cards didn't let you use 2-9 as inputs either
[21:41:21] <maddash> does that mean you'll mod the parport source? because it's rather difficult to understand it...
[21:41:26] <jmkasunich> but anything in the last 10-15 years has had pins 2-9 reversable
[21:41:57] <maddash> jmkasunich: basically, slap on an input mode for pins 14 16 and 17...
[21:42:01] <Jymmmmmmm> * Jymmmmmmm hands jmkasunich a 8bit ISa Hercules Monochrome card with paraport
[21:42:03] <jmkasunich> pins 1, 14, 16, and 17 are sometimes also reversable, but that is not as common - jepler found some recent cards where they were output only
[21:42:11] <maddash> like?
[21:42:21] <jmkasunich> what od you mean like?
[21:42:27] <jmkasunich> like what cards did he find?
[21:42:32] <maddash> yes
[21:42:38] <jmkasunich> damned if I know, ask him
[21:42:46] <maddash> MIA.
[21:42:53] <jmkasunich> he tested mother board parports, laptop parports, he didn't keep a list
[21:43:07] <jmkasunich> the point is, not all hardware is created equal
[21:43:09] <maddash> jmkasunich: seems like you hardcoded the inputs and outputs
[21:43:20] <jmkasunich> some can use 1, 14, 16, and 17 as inputs and some cant
[21:43:41] <Skullworks_PGAB> UMC chipsets were one...
[21:44:10] <Skullworks_PGAB> J.E. mentioned those
[21:44:52] <jmkasunich> } else if ((argv[n][0] == 'x') || (argv[n][0] == 'X')) {
[21:44:52] <jmkasunich> /* experimental: some parports support a bidirectional
[21:44:52] <jmkasunich> * control port. Enable this with pins 2-9 in output mode,
[21:44:52] <jmkasunich> * which gives a very nice 8 outs and 9 ins. */
[21:44:52] <jmkasunich> data_dir[num_ports] = 0;
[21:44:52] <jmkasunich> use_control_in[num_ports] = 1;
[21:44:54] <jmkasunich> n++;
[21:44:56] <jmkasunich> }
[21:45:05] <jmkasunich> "control port" means pins 1, 14, 16, and 17
[21:45:29] <jmkasunich> jepler added the X mode, and jepler tested enough boards to know that some DO NOT work in X mode
[21:45:43] <maddash> that's not in hal_parport.c
[21:45:48] <jmkasunich> yes it is
[21:45:59] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/drivers/hal_parport.c?rev=1.28
[21:46:18] <maddash> hm, so i can't use v2.1branch with that
[21:46:55] <jmkasunich> its in 2.1 as well
[21:47:01] <maddash> haha, "we aren't picky"
[21:47:07] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/drivers/hal_parport.c?rev=
[21:47:11] <maddash> jmkasunich: no it's not
[21:47:18] <maddash> jmkasunich: i'm staring right at it in nano
[21:47:18] <jmkasunich> search for "experimental"
[21:47:34] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/drivers/hal_parport.c?graph=1
[21:48:03] <jmkasunich> revision graph, shows that 1.28 is the current head of trunk, and is the current 2.1 branch (and has been unchanged since 2.1.0)
[21:48:33] <maddash> i was looking at the other parport source..
[21:48:41] <jmkasunich> in fact, jepler added the X mode in 1.21 back in July of last year - just read down the revision graph
[21:49:06] <maddash> * maddash stops his bitching
[21:49:26] <maddash> jmkasunich: thanks for clearing it up
[21:49:29] <jmkasunich> * jmkasunich stops his ranting
[21:49:37] <jmkasunich> quiet and peace return to the channel ;-)
[21:50:03] <jmkasunich> I do admit that we should have documented X mode a long time ago
[21:50:43] <jmkasunich> my only excuse is that its still considered experimental, since we haven't tried it on a large number of boards
[21:50:54] <jmkasunich> I have no idea what percentage of boards it will work on
[21:51:07] <jmkasunich> if its 99%, then we should make it permanent and document it
[21:52:03] <Skullworks_PGAB> JMK: can a condition tested in HAL generate a prompt message during G-code execution?
[21:52:19] <jmkasunich> Skullworks_PGAB: not that I'm aware of
[21:52:21] <Jymmmmmmm> I have a PCI dual port board here I can look at.
[21:52:31] <Skullworks_PGAB> OK
[21:52:52] <jmkasunich> it could be done - for example, there is that "hal_manual_toolchange" component that works with axis
[21:53:08] <maddash> jmkasunich: hm, so in x mode, the parport's state is identical to parport.0.output except with {14, 16, 17} as inputs, instead of outputs?
[21:53:19] <jmkasunich> I think it just has two hal pins... when one goes true, it pops up and says "change the tool", when you click "ok" it sets the other pin
[21:53:43] <jmkasunich> yes, with { 1, 14, 16, 17} as inputs instead of outputs
[21:53:52] <Skullworks_PGAB> thats kind what I was thinking - as to also having to shift gears to allow the spindle to reach target rpm
[21:53:53] <jmkasunich> you really don't like pin 1 do you? ;-)
[21:54:24] <Skullworks_PGAB> Pin 1 is really an odd ball
[21:54:26] <jmkasunich> Skullworks_PGAB: I would look at that component - it probably could be copied and modified easily
[21:55:25] <maddash> jmkasunich: i want all the pins i can get, but I'm under the impression that pin1 is used solely to establish the mode of the parport
[21:55:37] <Skullworks_PGAB> on some boards the don't even connect anything to that pin - just an anchor without any trace leaving
[21:55:50] <chr0n1c> what's up homies
[21:55:50] <jmkasunich> huh?
[21:56:03] <jmkasunich> pins 1 is the data strobe - without it, the printer won't print
[21:57:02] <Skullworks_PGAB> don't know
[21:57:06] <chr0n1c> i am cutting a test run in plastic for a ford logo die... for some reproduction parts. if they like what they see they are going to give me money to build a die from steel. all from a little hombrew cnc machine and your awesome software!
[21:57:29] <Skullworks_PGAB> but saw these issues when people were trying to use the PP zip drives
[21:58:13] <Skullworks_PGAB> Zip drives - a grea idea, that arrived 5 years too late.
[21:58:38] <maddash> jmkasunich: so pin 1 is just as usable as 14/16/17 as an input?
[21:58:49] <jmkasunich> far as I know
[21:59:00] <jmkasunich> I've never used X mode, so....
[21:59:21] <jmkasunich> I don't see any reason why 1 is different than any other pin
[21:59:34] <jmkasunich> hmm, this is confusing
[21:59:43] <jmkasunich> I tried X mode, and it says X is unknown
[22:01:47] <toastydeath> rtfm
[22:02:07] <toastydeath> (ha ha get it)
[22:02:23] <chr0n1c> gmds...
[22:02:27] <chr0n1c> get my duck sick
[22:02:40] <Skullworks_PGAB> The fabulous manual isn't written yet for X mode...
[22:03:43] <jmkasunich> X mode actually gives you both in and out HAL pins for those 4 physical pins
[22:03:49] <jmkasunich> not sure I agree with that....
[22:04:11] <jmkasunich> you can only use them as inputs when the output is high I think (its an open-collector thing)
[22:04:54] <jmkasunich> I think in X mode those pins should be in only, and the driver should write 1's to the hardware
[22:05:35] <jmkasunich> as you can see, X mode hasn't been used much... but if you have a need for that mix of I/O, any improvements and/or bugfixes are welcome
[22:21:46] <Skullworks_PGAB> Somehow I have trouble accepting the meaning of the first E in eagle...
[22:22:49] <CIA-19> 03jmkasunich 07TRUNK * 10emc2/src/hal/drivers/hal_parport.c: parport 'x' mode should not export HAL '-out' pins for physical pins 1, 14, 16, and 17
[22:23:20] <jmkasunich> * jmkasunich goes in search of tasty food
[22:23:49] <Skullworks_PGAB> tastes like chicken...
[22:29:09] <Jymmmmmmm> Maybe you can ask them... http://www.koutech.com/proddetail.asp?linenumber=48
[22:36:39] <Jymmmmmmm> here is the chipset that the one I have is using: http://www.moschip.com/html/Nm9715.html
[22:36:47] <Jymmmmmmm> NM9715CV
[23:46:20] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[23:52:13] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[23:58:30] <Skullworks_PGAB> Skunkworks: You still around?