Back
[01:44:23] <fenn_> fenn_ is now known as fenn
[02:11:49] <cradek> BJT's system is misconfigured in a way that's asking for occasional trouble if it can't handle full acceleration up to full velocity
[02:51:19] <jmkasunich> cradek: someday I'd like to look into fixing that initial overshoot on synced moves
[02:51:50] <cradek> sounds great
[02:51:58] <jmkasunich> I think basiclly what it needs is an offset added to the target position that covers the accel delay
[02:52:33] <jmkasunich> right now, pos = spindle_pos * pitch + starting_pos
[02:53:16] <jmkasunich> if it was spindle_pos * pitch + starting_pos - accel_dist, I think it would avoid the overshoot
[02:53:29] <cradek> similarly one of these days I want to work on configurable "position lag tweaking" for rigid tapping
[02:53:51] <cradek> I should play with that at workshop
[02:53:55] <jmkasunich> on this thread (M12x1.75), there is about 2 turns or more of unusable Z before it steadies out
[02:54:20] <cradek> jmkasunich: my high accel machine hides that very nicely
[02:54:39] <cradek> does it get better if you go slower?
[02:54:44] <jmkasunich> I almost ruined a part by starting too close
[02:54:48] <cradek> ouch
[02:54:59] <jmkasunich> I'm not gonna try - these parts take close to 20 mins at 330 RPM
[02:55:16] <jmkasunich> I'd like to be going faster, but the facing operation is the limit
[02:55:25] <jmkasunich> gotta get that VFD so I can do CSS
[02:55:34] <cradek> yeah you really need that
[02:55:38] <cradek> new motor too right?
[02:55:47] <jmkasunich> yeah, its a big project
[02:55:57] <jmkasunich> I think ballscrews come first
[02:55:57] <cradek> CSS is very cool.
[02:57:07] <jmkasunich> the sound of threading with that overshoot is very distinctive
[02:57:27] <jmkasunich> time to change parts
[02:58:13] <cradek> you know as much about spindle sync as anyone now - please do play with it
[03:00:02] <jmkasunich> #15 is running, I think that will be the last one today
[03:01:01] <jmkasunich> I hate turning the corners off of square stock
[03:01:22] <cradek> yeah that never works very well.
[03:01:43] <jmkasunich> my "roughing" cuts for the facing operation are only 0.030 deep and 1.5 ipm
[03:02:02] <jmkasunich> bout 0.0045 per rev
[03:02:17] <cradek> must be a big diameter if you're at 330 rpm
[03:02:41] <jmkasunich> 2" square, so 2.8 at the corners
[03:03:01] <jmkasunich> 241 SFPM if I did the math right
[03:03:29] <jmkasunich> its 12L14 steel
[03:03:33] <cradek> yeah something like that
[03:03:43] <cradek> woo that's pretty fast then - using carbide?
[03:03:45] <jmkasunich> so I'm definitely pushing it (HSS tool)
[03:04:02] <cradek> soon to be a HSS ex-tool
[03:04:09] <jmkasunich> carbide probably wouldn't like the interrupted cut
[03:05:12] <cradek> meh, 6 corners on a $2 insert...
[03:05:56] <jmkasunich> and how many times to I have to restart the program after a corner chips off
[03:07:06] <cradek> goodnight...
[03:07:17] <jmkasunich> goodnight
[09:05:15] <fenn_> fenn_ is now known as fenn
[12:23:18] <skunkworks_> logger_dev: bookmark
[12:23:18] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-03-28.txt
[13:26:02] <skunkworks_> ok - I tried to wing it as far as I could. the card loads but I am not getting any pins.
[13:26:04] <skunkworks_> http://pastebin.ca/960765
[13:28:13] <skunkworks_> not sure how to set the address and dir
[13:37:59] <cradek> where did you get 0800c0h? I see e400 in your lspci output
[13:38:41] <skunkworks_> heh - each port has an address - c0h is one of the plugs on the board.
[13:39:06] <skunkworks_> 0800 was from the lspci
[13:39:18] <cradek> try io="e400"
[13:41:19] <cradek> dir=0 seems like it should give you all in or all out
[13:41:51] <skunkworks_> fails with e400 will not load. 0800 will
[13:42:24] <cradek> does it say anything helpful in dmesg when it fails to load?
[13:42:26] <jepler> 0xe400
[13:42:46] <cradek> oh!
[13:42:51] <cradek> * cradek <- newbie
[13:44:52] <skunkworks_> now I get a bunch of errors in axis - 'error registering pci8255.0...
[13:45:19] <skunkworks_> with the 0xe400 address. That seems promising.. :)
[13:46:14] <cradek> rtapi_print_msg(RTAPI_MSG_ERR, "registering %s ... %x %x\n"
[13:46:20] <jepler> looks like I left some debugging crap in there
[13:46:20] <cradek> I bet this shouldn't be ERR...
[13:46:48] <skunkworks_> or... not :)
[13:47:11] <jepler> there are a lot of ERR in there that shouldn't be
[13:48:22] <skunkworks_> I am getting pins now.. and a realtime error :)
[13:48:32] <skunkworks_> delay
[13:48:33] <jepler> if you want to recompile and get rid of them, simply do a global search and replace of RTAPI_MSG_ERR with RTAPI_MSG_DBG
[13:48:43] <cradek> I'll check it in, I've already done that
[13:48:48] <jepler> cradek: that would be great
[13:49:09] <skunkworks_> I think I should play with this on a dapper machine.
[13:49:33] <CIA-22> EMC: 03cradek 07TRUNK * 10emc2/src/hal/drivers/pci_8255.c: oops, these are debug info, not errors
[13:50:09] <jepler> cradek: it needs to be changed in 2.2 as well
[13:51:34] <skunkworks_> jepler: how does the dir work? is each 0 for 4 bits?
[13:52:27] <CIA-22> EMC: 03cradek 07v2_2_branch * 10emc2/src/hal/drivers/pci_8255.c: oops, these are debug info, not errors
[13:52:49] <jepler> skunkworks_: no.
[13:55:33] <jepler> skunkworks_: The 'a' and 'b' ports are switched 8 bits at a time; the 'c' port is switched 4 bits at a time. reading the source, I am not sure which bit is for 'a' and so on...
[13:57:13] <cradek> but it's a bitmask, right?
[13:57:24] <jepler> yes, it's a bitmask
[13:57:40] <jepler> 4 bits for each of the 3 connectors
[13:57:53] <cradek> so if you specify it in hex, each hex digit will control a,b,c1,c2
[13:57:58] <jepler> of those 4 bits, one of them switches the direction of "A", one switches the direction of "B", and two switch the direction of "C", 4 bits each
[13:58:04] <jepler> yes
[13:58:49] <jepler> put 0x at the beginning just like you did for io=
[13:58:54] <cradek> should be easy for skunkworks_ to figure out the rest :-)
[13:59:20] <cradek> try 0x111,222,444,888 and see what bits you get
[13:59:31] <cradek> then, write a manpage...
[14:00:13] <jepler> hah
[14:00:16] <jepler> that'd be great
[14:07:09] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/direction.out
[14:08:03] <jepler> whoops, forgot dir=0; fixed
[14:09:47] <skunkworks_> :)
[14:09:48] <cradek> what a strange ordering
[14:10:11] <cradek> 1=c, 2=b, 4=c4, 8=a
[14:10:54] <skunkworks_> ah - so the debug outputs where probably what was throwing the realtime delay error?
[14:10:58] <jepler> it's related to the way the 8255 direction register is specified
[14:11:08] <cradek> skunkworks_: no, it shouldn't be related
[14:11:32] <jepler> WRITE((dir&3) | ((dir & 0xc) << 1) | 0x80, ioaddr, 3);
[14:11:47] <skunkworks_> oh - well - I think I will try it in a dapper machine. Then I can easially get trunk and play.
[14:12:04] <jepler> (the low 3 bits to the 8255 direction register are the same as the low 3 bits of the dir specification)
[14:12:41] <cradek> I see that (low 2)
[14:12:47] <jepler> er, yes
[14:13:42] <jepler> C-low and B are sort-of related, and C-high and B are sort-of related. There are various modes in which you can use them a bit like a data bus, with C-bits acting like read/write/strobe or something
[14:13:50] <jepler> I forget the details -- the hal driver only uses them as dumb I/Os
[14:14:11] <skunkworks_> will it also control the relay?
[14:14:33] <skunkworks_> * skunkworks_ just needs to play with it.
[14:14:42] <jepler> skunkworks_: it's supposed to, yes. I never tested it very heavily.
[14:14:50] <cradek> hal_pin_bit_newf(HAL_IN, &(inst[i].relay), comp_id, "pci8255.%d.relay", i);
[14:15:10] <skunkworks_> sweet. I should have seen that when it finally exported the pins.
[14:18:27] <jepler> I don't think my hardy crashes are related to load; I had the system running all night rebuilding the kernel package
[14:23:17] <jepler> cradek: does this look accurate to you?
http://emergent.unpy.net/files/sandbox/homing-types.png
[14:24:58] <cradek> I think so
[14:27:29] <CIA-22> EMC: 03jepler 07TRUNK * 10emc2/docs/src/config/ini_homing.lyx: a table to clarify the different types of homing (e.g., how to get index-only homing
[14:28:12] <CIA-22> EMC: 03jepler 07v2_2_branch * 10emc2/docs/src/config/ini_homing.lyx: from trunk: a table to clarify different types of homing
[14:28:47] <CIA-22> EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: note documentation improvements
[14:39:25] <skunkworks_> one last time.. What is the command to run halcmd from trunk? .mumble
[14:43:54] <jepler> skunkworks_: . scripts/emc-environment, then just type halrun or halcmd
[14:44:52] <skunkworks_> thanks - exactly what I needed
[14:55:10] <skunkworks_> I have had hardy lock up on me once.. Screen when black. I don't know if it was static though.
[14:55:26] <jepler> huh, apparently automake already works for nonrecursive make (long as you write all your stuff in one .am file?)
http://www.mega-nerd.com/erikd/Blog/CodeHacking/nonrecursive_automake.html
[15:07:56] <skunkworks_> jepler: do you remember what the 12v terminal block is for?
[15:28:46] <skunkworks_> jepler: dapper system says
http://pastebin.ca/960918
[15:32:04] <cradek> [disabled]?
[15:37:08] <jepler> skunkworks_: I think that is power for the relay
[16:10:35] <skunkworks_> disabled is bad?
[16:10:54] <skunkworks_> * skunkworks_ is just trying to get the relay to work :)
[17:30:32] <skunkworks_> I cannot get the relay to fire..
http://pastebin.ca/961064
[17:43:15] <skunkworks_> heh - the relay is showing as an 'in' bit
[17:43:58] <skunkworks_> never mind
[18:31:24] <skunkworks_> the digital I/o seems to work :) cool
[18:31:47] <skunkworks_> I should say O
[18:31:48] <skunkworks_> :)
[18:32:32] <skunkworks_> so the card is working
[18:33:30] <skunkworks_> * skunkworks_ cannibalized a floppy cable
[18:33:40] <skunkworks_> * skunkworks_ found an un-keyed one.
[18:34:53] <skunkworks_> wow - it outputs 0v for logic 0 and a hefty 5v for logic 1
[18:35:06] <skunkworks_> impressive
[18:43:22] <skunkworks_> * skunkworks_ seems to be talking to himself
[18:43:54] <cradek> don't feel bad; we all do it sometimes
[18:46:59] <skunkworks_> so the question is - what am I doing wrong with the relay.
[18:47:20] <skunkworks_> I am running 12v into the card from the computer power supply.
[18:47:21] <jepler> skunkworks_: if I remember looking at the board, the logic-level output from the PCI bridge chip operates an opto that can allow the 12V to flow through the relay coil. No 12V, no relay operation.
[18:47:34] <skunkworks_> ^
[18:47:43] <skunkworks_> :)
[18:47:58] <jepler> double-check the polarity?
[18:48:08] <skunkworks_> I thought maybe I needed the write relay function - but that didn't help
[18:48:21] <skunkworks_> I will check again. went by the polarity written on the board.
[18:50:18] <skunkworks_> yes - ground is towards the motherboard
[19:14:02] <skunkworks_> With my jerry rigged setup - I sure can get it lost easy. It seems to go into open collector mode. Then only a reboot will fix it.
[19:14:21] <skunkworks_> It acts like it does until emc is loaded.
[19:45:28] <jepler> what goes into open collector mode
[19:45:29] <jepler> ?
[19:46:06] <skunkworks_> port 1
[19:47:00] <skunkworks_> right now I only have a dvm. When the compter is booting - the dvm voltage jumps around. Then when emc starts - it goes to 0 volts.
[19:47:40] <skunkworks_> when I zap it - or what ever i to - the voltmeter jumps around like (not physically) like it does when the compter is booting.
[19:47:50] <skunkworks_> I have not gotten it to do it for a while.
[19:49:58] <skunkworks_> I have flood coolant turning on bit 0 of the first header. I am excited :)
[19:50:31] <skunkworks_> restarting emc did not reset the card. Reboot did
[20:27:50] <skunkworks_> mist and flood.. I am the man.
[20:58:46] <alex_joni> heh
[20:59:57] <skunkworks_> Hi alex
[21:00:17] <alex_joni> * alex_joni was wondering what skunkworks_ is on
[21:00:32] <skunkworks_> high on friday I guess
[21:00:42] <alex_joni> nice
[22:15:31] <alex_joni> * alex_joni heads to bed
[22:15:34] <alex_joni> good night all
[23:07:26] <skunkworks> jepler: when you get a chance - could you try your pci8255 card? I put it in a different computer and still don't get the relay to trigger. The port changed on this computer 0x1000. The normal header I/O's seems to work great.
[23:19:04] <fenn_> skunkworks: what's the relay for?
[23:19:08] <fenn_> fenn_ is now known as fenn
[23:20:40] <skunkworks> no clue.
[23:20:54] <skunkworks> (I mean - I don't know what it was ment to do.)
[23:21:53] <skunkworks> I should be able to activate it thru emc but can't. Either my card doesn't work - or I am doing something wrong or the driver isn't quite right :)
[23:25:29] <skunkworks> I mean jeeze - it is 72 i/o plus the relay - I want it all. ;)
[23:29:47] <jmkasunich> is there a modern (meaning works with Gnome) version of "write" - so one computer can send a message to a user at another?
[23:30:19] <jmkasunich> having the CNC pop up a dialog saying "drill a hole, dummy" doesn't work when the dummy is staring at a different screen
[23:37:14] <alex_joni> jmkasunich: maybe using pidgin as an IM client
[23:37:57] <jmkasunich> hmm
[23:38:15] <jmkasunich> I could just send an IRC message to myself
[23:38:31] <jmkasunich> I think there's a cmd line IRC client that can just connect, send, disconnect
[23:39:32] <alex_joni> is the other machine a linux machine too?
[23:40:43] <alex_joni> there is a thing called WinPopup
[23:40:52] <alex_joni> supposedly it can work on linux too
[23:41:03] <alex_joni> smbclient has support for sending messages over the protocol
[23:41:19] <alex_joni> cat mymessage.txt | smbclient -M MACHINE
[23:42:06] <alex_joni> on the remote machine you can set up a smb server which does something when the message is received
[23:42:15] <alex_joni> e.g. opens a gedit with the message loaded
[23:45:24] <skunkworks> * skunkworks thought alex was going to bed
[23:48:14] <alex_joni> yeah, well.. that's how it goes
[23:48:19] <skunkworks> ;)
