Back
[00:00:48] <SWPLinux> I have a 1.6M one that I can tar up. do you want that one and the various TCad incarnations to play with now?
[00:01:07] <SWPLinux> I can stick the 21M one on the web if you'd like to set up a download for it
[00:03:02] <rayh> That would be okay also.
[00:08:13] <SWPLinux> I can dcc the smaller file to you if you like (it's 415k)
[00:11:51] <robin_sz> so ... I have a part to cut from 100mm dia tube
[00:12:35] <robin_sz> basically, I have to cut away a slot, 270 degrees for 900mm in a tube ...
[00:13:01] <robin_sz> I was thinking "how can I do this" .. and then .... bing! idea!!
[00:13:54] <robin_sz> I have: 1) a plasma cutter ...
[00:14:01] <robin_sz> and 2) a robot :)
[00:25:19] <rayh> Okay I got a few gcode files from SWPadnos. Anyone else got a few part files I can get a look at?
[00:37:17] <CIA-6> 03petev 07TRUNK * 10emc2/src/libnml/inifile/ (inifile.cc inifile.hh): Added Find() methods for int and double.
[00:48:08] <Jymmmm> niggly bits?!
[00:49:23] <SWPLinux> it's british
[00:49:45] <Jymmmm> * Jymmmm don't think he wants to know.
[01:09:56] <robin_sz> niggly bits ... like "the complicated bts" .. "the troublesome bits" .. "the awkwards bits"
[01:11:06] <robin_sz> probably derived from "niggardly"
[01:24:18] <Jymmmm> ah
[01:25:01] <Jymmmm> robin_sz: After your fire, now I'm gonna install a smoke alarm on the enclosure =)
[01:25:16] <robin_sz> wont work
[01:25:30] <Jymmmm> why not?
[01:25:36] <robin_sz> dust
[01:25:54] <robin_sz> they hate dust
[01:26:06] <Jymmmm> One panel is canvas, I'm *hoping* that will prevent false alarms
[01:26:15] <Jymmmm> outside, not inside
[01:26:21] <robin_sz> ah
[01:26:42] <robin_sz> well, i uess it will alarm once the canvas panel burns through :)
[01:27:19] <Jymmmm> Yeah, all this clear vinyl won't bring the humidity up to like 4000000%, hoping the canvas keeps the dust contained will still allowing 8 sq ft of heat ventilation
[01:27:43] <robin_sz> you could try a more traditional method
[01:28:04] <Jymmmm> 14" midget in the enclosure with an air horn?
[01:28:08] <robin_sz> how do miners traditionally detect smoke and gas?
[01:28:17] <Jymmmm> fuck off
[01:28:31] <steves_logging> steves_logging is now known as steve_stallings
[01:28:37] <robin_sz> aww, go on ...
[01:28:43] <Jymmmm> you first
[01:28:54] <Jymmmm> it is big enough to hold a body or two.
[01:28:56] <robin_sz> all you have to do is train it to press a button every 15 seconds ...
[01:29:47] <Jymmmm> eh $6 smoke alarm
[01:30:05] <jepler> http://blog.modernmechanix.com/2007/03/07/monster-clock-has-no-hands/
[01:30:08] <robin_sz> fire starts ... parrot dies, stops pressing button .. alarm sounds ...
[01:30:09] <Jymmmm> got a place to mount it already too
[01:30:21] <jepler> wow what a crazy idea
[01:30:35] <cradek> rayh: the motor mounts for my lathe had nice gcode with helical hole and slot milling, but I can't find them for some reason
[01:30:37] <Jymmmm> jepler has Chris seen it yet?
[01:30:47] <robin_sz> and ... time it right, you could serve it with fries too
[01:31:15] <jepler> Jymmmm: dunno, I don't think he reads that site
[01:31:31] <cradek> jepler: that's cool
[01:32:49] <Jymmmm> the 11 looks like legos
[01:32:55] <robin_sz> I do like thie master clock :)
[01:33:28] <robin_sz> we had one of those t0 run our pulse clock system at the bbc
[01:33:41] <robin_sz> big pendulum clock in a cabinet
[01:33:43] <jepler> yeah it does have a kind of 'legos' look
[01:33:55] <cradek> robin_sz: on a huge cube of concrete?
[01:34:05] <robin_sz> bolted to a wall inthe basement
[01:34:31] <robin_sz> it wasn't free running ...
[01:34:45] <jepler> do you suppose the one minute digit moved continuously?
[01:34:52] <robin_sz> it was corrected by a series of 1s pulses derived fromt he master clocks in London
[01:35:25] <Jymmmm> http://www.brightstarlasers.com/index.htm
[01:35:31] <robin_sz> the idea was it kept ticking at about the right speed if the pulse chain broke
[01:36:10] <Jymmmm> at least the laser tube is water cooled
[01:37:36] <jepler> robin_sz: how was the 1s pulse transmitted?
[01:38:06] <Jymmmm> 5, 10, 15, 25 MHz
[01:48:17] <CIA-6> 03cradek 07TRUNK * 10emc2/lib/.cvsignore: new ignores
[01:59:46] <jtr> looks like the 11 is upside down in the clock picture - the margins are reversed from the 10 and 12.
[02:00:15] <jepler> skunkworks: if you're around, I may want to send you an experimental pluto firmware to try on your machine that has trouble
[02:00:56] <jepler> skunkworks: also I'm interested in what you see if you hook one of the inputs to VCC and halscope the corresponding pin
[02:01:18] <CIA-6> 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: fix g28 and g30 to go to the saved position regardless of the currently-active gcode units
[02:01:42] <jepler> cradek: I'd be happy to correct the documentation. The variables are now in the machine's "native units" all the time?
[02:01:52] <cradek> yes, and thank you
[02:02:43] <CIA-6> 03cradek 07v2_1_branch * 10emc2/src/emc/rs274ngc/interp_convert.cc: fix g28 and g30 to go to the saved position regardless of the currently-active gcode units
[02:05:07] <CIA-6> 03jepler 07TRUNK * 10emc2/docs/src/gcode/main.lyx: document the current behavior of g28/g30: they use native machine units for the home location variables. make it clear that this does not perform a "homing sequence"
[02:05:45] <CIA-6> 03jepler 07v2_1_branch * 10emc2/docs/src/gcode/main.lyx: merge rev1.19: document behavior of g28/g30
[02:06:50] <CIA-6> 03cradek 07v2_1_branch * 10emc2/debian/changelog: bugfix
[02:06:52] <cradek> thanks jepler
[02:07:16] <cradek> was there anything else we thought we should fix before 2.1.2?
[02:07:59] <jepler> cradek: I didn't see the backport of the cutter comp bugfix
[02:08:01] <jepler> did I miss it?
[02:08:19] <cradek> no, I didn't backport it yet
[02:08:21] <jepler> OK
[02:08:37] <jepler> I don't know of anything else pending but I'm very forgetful
[02:08:56] <cradek> maybe a 4 axis thing, but also maybe not
[02:09:46] <jepler> since several "mill the wrong thing" bugs have been fixed, I think we should do a release again
[02:09:56] <cradek> yes definitely
[02:12:18] <jepler> glad we're on the same wavelength
[02:12:43] <cradek> wonder if swp tested comp any - I can't blame him if he didn't
[02:12:44] <skunkworks> jepler: I am back
[02:12:55] <jepler> skunkworks: hello
[02:13:01] <skunkworks> Hi
[02:14:32] <jepler> skunkworks: download this file, place it in the same location as the .rbf file in your source tree (emc2.1/src/hal/drivers/pluto_server_firmware/), and re-build:
http://emergent.unpy.net/index.cgi-files/sandbox/pluto_servo.rbf
[02:14:51] <jepler> skunkworks: (or emc2.trunk or whatever you called it)
[02:15:30] <skunkworks> ok - Have to reboot into ubuntu
[02:15:41] <skunkworks> biab
[02:15:56] <jepler> skunkworks: the change delays the "data is ready on the parallel port" signal from the pluto to linux -- I'm not sure if that's the problem or not
[02:16:15] <skunkworks> ok - I will try it with and without the cable
[02:16:59] <jepler> skunkworks: did you finish closing on your house?
[02:17:03] <jepler> oops there he went
[02:17:55] <SWPLinux> yes he did
[02:18:01] <SWPLinux> he's now the proud owner of 2 houses :)
[02:20:34] <jepler> that's too many
[02:31:24] <skunkworks> drop it into the firmare directory and do a make?
[02:31:33] <skunkworks> jepler: I mean
[02:32:59] <skunkworks> firmware I mean
[02:38:28] <skunkworks> jepler: I tried it with the cable just to make sure that it was still doing the odd counting and it was. (before I updated your new firmware). Now I dropped the firmware in and did a make from the src directory. Looks like it fixed that issue.. Now the count from the encoder doesn't flash between 2 numbers and randomly change.
[02:39:10] <skunkworks> :) nice work
[02:49:14] <skunkworks> ran it 200 inches one way - (1 inch per rev) and back to 0 - lined right up. (1000 rpm about)
[03:02:49] <skunkworks> Jepler: so far so good. :)
[03:03:19] <skunkworks> jepler: now I can have my portable plugged into power while running the pluto :)
[03:04:25] <skunkworks> I have a 4 foot cable at work I should try for shits and giggles.
[03:46:46] <jepler> skunkworks: whee
[03:46:58] <jepler> skunkworks: (sorry, I have guests over and I can only talk to you when I want to be rude to them)
[03:48:59] <jepler> skunkworks: hum, I accidentally had other unrelated changes in the firmware I sent you.
[03:50:07] <jepler> skunkworks: can you test another one tonight if I get it online in the next few minutes? If this really fixes the bug I'd like to have it in the next 2.1 release and I think that's coming right up
[03:50:15] <skunkworks> yes
[03:50:49] <jepler> skunkworks: OK coming right up ..
[03:53:34] <jepler> skunkworks:
http://emergent.unpy.net/index.cgi-files/sandbox/2/pluto_servo.rbf
[03:53:37] <skunkworks> sorry - on the phone with my wife :)
[03:54:41] <jepler> np
[03:54:47] <jepler> like I said I'm being rude to my guests
[03:55:42] <skunkworks> I will have to remember to see that sign - If I ever visit you ;)
[03:58:05] <jepler> you're welcome to come over for dinner anytime .. but there's no guarantee I won't chat with #emc instead of talking with you
[03:59:21] <jepler> and not really anytime -- call first
[03:59:25] <cradek> the defense to that is to bring a computer
[04:00:04] <skunkworks> :)
[04:00:08] <jmkasunich> I do seem to recall a little IRC when we were sitting at the same table at the fest
[04:00:17] <skunkworks> jepler: Seems to be working also.
[04:00:38] <jepler> skunkworks: great
[04:02:33] <skunkworks> jepler: 300 rotations forward and 300 back - same location btw my craftman drill runs 1200 rpm clockwise and only 1000 rpm ccw
[04:02:37] <ds3> any guesses as to how fast of a system I would need if I want to use emc to generate PWM to control a PM motor for a spindle with a 1 pulse per N rev (1pulse per rev + divider) encoder over a 20RPM-12000 RPM range?
[04:02:47] <CIA-6> 03jepler 07TRUNK * 10emc2/src/hal/drivers/pluto_servo_firmware/ (pluto_servo.rbf servo.v): fix communication problem reading from the pluto board by delaying the nWait signal 3 clocks
[04:04:27] <jepler> ds3: 12000 pulses per minute is no problem to read in software, as long as the time spent "high" is long enough (BASE_PERIOD + latency, basically)
[04:05:00] <ds3> jepler: but what about the generate PWM part?
[04:05:17] <jepler> ds3: I'm not sure if the velocity output of the 'counter' module is any good when there is less than 1 pulse per ms, it may spend most of the time giving a velocity of 0, then a high number in the 1ms when a pulse is seen.
[04:06:08] <ds3> Hmmm okay let see
[04:06:15] <skunkworks> jepler: Should I tell the guy to wait for the next emc2 release? and if he feels energetic - build a rip?
[04:06:19] <jepler> ds3: I have only run small servo motors (6W or something) off of emc's 'pwmgen' but it seems to work OK
[04:07:11] <ds3> jepler: Not sure how to relate servo motor behavior with a spindle since the a servo would accelerate - run - decel
[04:08:36] <jepler> skunkworks: I intend for the bugfix to be in the emc 2.1.2 release, but I don't know when that will be.
[04:09:40] <jepler> skunkworks: it's up to you whether to suggest he build his own -- if it doesn't sound like he is knowledgeable about linux, maybe best not to?
[04:09:59] <skunkworks> jepler: is there an easy way to fix the installed pluto firmware?
[04:10:08] <skunkworks> on his computer?
[04:10:21] <jepler> ds3: I haven't done closed-loop control of a spindle yet, but I am tempted to think it's just a matter of connecting the desired and actual speeds to a PID and tuning it
[04:10:54] <jepler> skunkworks: no, the firmware is compiled directly into the pluto_servo.ko driver so it can't be changed without recompiling the rest
[04:11:05] <skunkworks> ok
[04:11:49] <ds3> jepler: but what would you use for the physical driver? I was thinking of maybe a MOSFET in series with the motor and I drive the gate via a parallel port pin (logic level MOSFET, ~200V rating)
[04:12:53] <jepler> ds3: I'm not smart at electronics by a longshot
[04:13:13] <jepler> ds3: so I hesitate to make a recommendation
[04:13:33] <CIA-6> 03jepler 07v2_1_branch * 10emc2/src/hal/drivers/pluto_servo_firmware/ (pluto_servo.rbf servo.v): merge from TRUNK: fix unreliable reading of encoders
[04:13:33] <ds3> 'k
[04:13:54] <cradek> yay!
[04:13:55] <jepler> ds3: I'd be tempted to try something like that, however
[04:14:15] <ds3> Hmmm
[04:14:58] <ds3> trying to decide if I should rig up a crude digital pot with my current controller or replace it with a fully encoded spindle
[04:15:10] <CIA-6> 03jepler 07v2_1_branch * 10emc2/debian/changelog: note new bugfix
[04:15:23] <cradek> what was the fix?
[04:15:31] <ds3> hehe
[04:15:46] <ds3> for the "Software does not work right" bug of course ;)
[04:15:48] <jepler> cradek: I guess you'll have to look at the diff to be sure
[04:16:08] <jepler> cradek: are you just encouraging me to write better change messages, or are you asking about the technical details of the pluto bugfix?
[04:16:19] <cradek> haha
[04:16:36] <cradek> no I just wondered if it was something simple to explain
[04:16:38] <skunkworks> are you guys thinking the next few weeks for the next version?
[04:16:48] <cradek> skunkworks: sooner I bet
[04:17:08] <jepler> wanna commit to sometime this month?
[04:17:12] <skunkworks> So if I say a week or 2 I probably won't be too wrong?
[04:17:32] <jepler> btw I'll be away for most of april, I'll be travelling
[04:18:22] <cradek> "this month" is pretty sure
[04:22:26] <skunkworks> cradek: this would get him jeplers fixes without actually getting head? cvs -z5 -d:ext:anon@cvs.linuxcnc.org:/cvs co -rv2_1_branch -d emc2.1-branch emc2
[04:22:46] <cradek> yes
[04:22:51] <skunkworks> thanks
[04:22:58] <cradek> that'll get a new tree that will correspond to the upcoming release
[04:23:44] <SWPLinux> but he won't be able to compile unless he's got all the stuff from "apt-get build-dep emc2"
[04:23:51] <cradek> right
[04:24:19] <jepler> cradek: in a read request (data from device to computer), the device puts the data on the bus and also drives nWait HIGH. I delayed nWait by a few nS, on the theory that maybe the data hadn't stabalized yet.
[04:24:34] <skunkworks> Yes - I am pointing him to the wiki if he feels comfortable
[04:24:36] <cradek> oh, neat
[04:26:18] <jepler> except that skunkworks says it fixed his laptop with the cable, I'm not sure the fix and the theory fit the observed behavior
[04:26:36] <cradek> hm
[04:27:22] <jepler> (this could explain junk or earlier data being read later, but the problem seemed to be later data being read earlier)
[04:30:05] <skunkworks> ok?
http://www.cnczone.com/forums/showthread.php?p=268628#post268628
[04:30:35] <jepler> * jepler reads
[04:31:26] <jepler> skunkworks: "then you would go into the rv2_1_branch directory and enter" the directory will actually be named "emc2.1-branch" if you follow the directions
[04:32:56] <skunkworks> fixed
[04:33:21] <skunkworks> it should be scripts\emc shouldn't it?
[04:34:40] <skunkworks> never mind - I had typed it write
[04:34:43] <skunkworks> right
[04:35:10] <SWPLinux> scritps/emc ...
[04:35:16] <SWPLinux> err - sripts/emc
[04:35:21] <SWPLinux> no, scripts/emc
[04:35:24] <SWPLinux> yay!
[04:35:26] <skunkworks> :) right
[04:35:36] <skunkworks> ok - going to bed - night guys.
[04:35:49] <skunkworks> jepler: thanks for the fix.
[04:36:09] <jepler> skunkworks: I hope it works for this guy too
[04:36:28] <jepler> I wish I understood the problem more fully and was more confident in the fix
[04:37:07] <SWPLinux> jepler: the EPP hardware waits for nWait before completing the read cycle?
[04:37:19] <skunkworks> * skunkworks will try an even longer cable tomorrow ;)
[04:37:44] <skunkworks> night
[04:38:00] <jepler> SWPLinux: here's one of the timing diagrams I've looked at:
http://www.beyondlogic.org/epp/epp.htm#7
[04:39:02] <SWPLinux> when is nWait cleared in the pluto?
[04:39:06] <jepler> in the pluto, nWait is just an inverted, delayed version of nStrobe
[04:39:24] <SWPLinux> which is?
[04:39:36] <jepler> Addr Strobe/ on that picture
[04:39:39] <SWPLinux> one of data_strobe or addr_strobe?
[04:39:40] <SWPLinux> ok
[04:39:43] <jepler> (except there are two strobes.. yes)
[04:40:00] <jepler> they're OR'd or AND'd or something
[04:41:04] <jepler> 'night all
[04:41:07] <SWPLinux> and the AND/OR of the two strobes is what causes the pluto to drive the data lines?
[04:41:10] <SWPLinux> see you
[04:42:39] <jepler> argh you made me look at the code again
[04:43:25] <SWPLinux> sorry
[04:43:29] <jepler> assign EPP_dataout = (EPP_read & EPP_wait) ? EPP_data_mux : 8'hZZ;
[04:44:07] <jepler> EPP_wait is the internal, opposite-polarity version of the same thing that is on Wait/ so I didn't actually change the relationship between driving wait and data
[04:44:36] <jepler> * jepler sighs
[04:44:50] <SWPLinux> look at it tomorrow :)
[04:46:04] <jepler> EPP_data_mux comes from data_reg which comes from addr_reg and data_buf (also registered)
[04:46:30] <jepler> what I did was move both wait and data compared to the changes to addr_reg and data_buf
[04:46:56] <jepler> that makes a bit more sense: for a short time, I would have been driving the output based on the old value of addr_reg or data_buf
[04:48:25] <jepler> goodnight -- for real this time
[04:48:28] <jepler> SWPLinux: don't say anything more :-P
[04:48:36] <SWPLinux> good night
[04:48:41] <SWPLinux> :P
[04:48:48] <jepler> jerk
[06:01:38] <steve_stallings> steve_stallings is now known as steves_logging
[07:15:28] <K`zan> Night folks
[09:36:38] <jlmjvm> alex:Good Morning
[13:53:43] <Martin_Lundstrom> hello everyone
[13:55:36] <rayh> Hi Martin
[14:02:13] <Dallur> hey Martin
[14:07:34] <anonimasu> hi
[14:15:24] <skunkworks> jepler: the 6 ft long cable works also - the pluto would do nothing before. (led would not even flash)
[14:15:26] <Martin_Lundstrom> Dallur, any success?
[14:15:26] <Dallur> My plasma table is finally ready, all hardware assembled, all sensors working and axis moving
[14:15:45] <Martin_Lundstrom> anonimasu, how is your stuff coming along?
[14:15:59] <Martin_Lundstrom> Dallur, cool
[14:16:13] <Martin_Lundstrom> was it hard to configure emc?
[14:16:14] <Dallur> Martin: I'm working on the software now, Tonight I'm going to start a rewrite, move to pyvcp, use gantry kinematics and
[14:16:33] <Martin_Lundstrom> Dallur, I have some code
[14:16:42] <Dallur> Martin: clean up some stuff, also want to hook up a couple of more signals through classicladder
[14:16:52] <Martin_Lundstrom> but I use HAL components
[14:17:14] <Dallur> Martin: I use hal for most things to, but some things I could not do in HAL I moved to classicladder
[14:17:26] <Martin_Lundstrom> Maybe your solution is better!?
[14:17:35] <anonimasu> maralready cutting stuff..
[14:17:50] <Dallur> anonymasu: everything working great without any THC ?
[14:17:54] <anonimasu> yeah..
[14:18:13] <Dallur> anonimasu: excellent :D
[14:18:14] <Martin_Lundstrom> Shall I try to look up my code and send it to you? (its spagetti ;) )
[14:18:15] <anonimasu> but the plasma is useless for thicker stuff..
[14:18:34] <anonimasu> I'm waiting for a oxy-acetylene head with valves and stuff..
[14:18:35] <Martin_Lundstrom> anonimasu, ball!
[14:18:43] <Dallur> Martin: Sure, I will start working on the software tonight
[14:18:47] <anonimasu> Martin_Lundstrom: what?
[14:19:06] <anonimasu> Martin_Lundstrom: seems like the fsckers making plasmas overstates the specs
[14:19:13] <Dallur> anonimasu: how thick is ,, thick ?
[14:19:22] <Martin_Lundstrom> hmm
[14:19:41] <anonimasu> 30mm..
[14:19:47] <anonimasu> or well 20mm is also too slow..
[14:19:50] <Dallur> anonimasu, 120A ?
[14:21:57] <anonimasu> no
[14:22:05] <anonimasu> well 51.9A at 220v..
[14:22:09] <anonimasu> err 69..
[14:22:13] <anonimasu> 69.9..
[14:22:24] <Martin_Lundstrom> Dallur, can you accept the dcc offer?
[14:23:10] <anonimasu> I'm cutting 30mm at 400mm/min with oxy-acetylene..
[14:23:12] <anonimasu> no kerf..
[14:23:23] <Martin_Lundstrom> did you get it?
[14:23:56] <Dallur> Martin: yup :D
[14:24:15] <Martin_Lundstrom> Dallur, the hack is somewhat proven
[14:24:29] <anonimasu> Dallur: that's how it looks..
[14:24:31] <Dallur> anonimasu: yeahh, for the thicker stuff in mild steel oxy is way faster
[14:24:33] <Martin_Lundstrom> I have made 1h of cutts with it
[14:24:57] <Dallur> Martin: great :D
[14:25:00] <anonimasu> that's about the only stuff we cut..
[14:25:06] <anonimasu> I've got some 40mm parts comming soon
[14:25:23] <anonimasu> the only problem with my design is that I only have one driven rail..
[14:25:32] <Dallur> anonimasu: Nice, did you adjust the rig for the oxy torch or did you already have an oxy table set up ?
[14:25:32] <anonimasu> and the belts are long..
[14:25:39] <Martin_Lundstrom> Dallur, Do you want me to give you a sumary for how my code works?
[14:25:51] <Dallur> Martin: perhaps later, i'm at work now
[14:25:51] <anonimasu> I just changed for the oxy torch..
[14:25:53] <anonimasu> same mount..
[14:25:54] <anonimasu> :)
[14:26:09] <Martin_Lundstrom> Dallur, ok, I try to be around
[14:26:12] <Dallur> anonimasu: nice, did you install solenoids for the gas or is it always on ?
[14:26:27] <Dallur> Martin: ok, I will head home in 3 hours or so
[14:27:16] <anonimasu> I'll be getting a head and valves soon..
[14:27:28] <Martin_Lundstrom> anonimasu, what config are you using for you cncplasma?
[14:27:38] <anonimasu> I'll run the gas always on, and a valve to switch the cutting on/off..
[14:27:44] <anonimasu> Martin_Lundstrom: a stock stepper config..
[14:28:00] <anonimasu> im not bothering with THC/BI dont have a z axis yet..
[14:28:05] <Martin_Lundstrom> anonimasu, ok, cool
[14:28:12] <Martin_Lundstrom> ok
[14:28:44] <Dallur> anonimasu: Do you have any videos/pictures yet ?
[14:28:48] <Martin_Lundstrom> anonimasu, there is some cheaper stuff that you can use as a z axis
[14:29:04] <anonimasu> Martin_Lundstrom: it's a time issue..
[14:29:17] <Martin_Lundstrom> ok
[14:30:04] <Martin_Lundstrom> anonimasu, nice that you already got it working :)
[14:30:23] <anonimasu> it took about a weekend to make mounts and stuff..
[14:30:43] <anonimasu> and a 4 hour job at the mill :)
[14:30:58] <anonimasu> to make holes..
[14:31:06] <anonimasu> drilling every decimeter is a pain :)
[14:31:24] <Martin_Lundstrom> anonimasu, do you have any photos?
[14:31:29] <anonimasu> no
[14:32:00] <anonimasu> I've cut about 20 parts.. on it :)
[14:32:04] <anonimasu> a sheet..
[14:32:12] <Martin_Lundstrom> have fun
[14:32:16] <anonimasu> I'll be making 40 out of something once the 2nd belt arrives
[14:32:27] <anonimasu> that was the only issue, the deflection of the beam is minimal..
[14:32:50] <Dallur> anonimasu: so right now one side lags behind the other ?
[14:33:08] <anonimasu> yeah
[14:33:33] <anonimasu> Dallur: well, the belt slacks and springs into position, because it isnt stiff enough..
[14:33:54] <Dallur> anonimasu: ahh so you have a dead-band
[14:34:03] <anonimasu> it's not really lag..
[14:34:17] <anonimasu> yeah, im waiting for a 2nd side drive to arrive :)
[14:34:30] <anonimasu> so I can drive both sides off one motor..
[14:34:30] <Dallur> anonimasu: :D
[14:34:50] <Dallur> anonimasu: going to put a shaft across ?
[14:34:53] <anonimasu> yeah
[14:34:58] <anonimasu> it's just a decimeter or so..
[14:35:13] <Dallur> anonimasu: ahh ok :D
[14:35:23] <anonimasu> I have a T setup remember?
[14:35:25] <anonimasu> ;)
[14:36:07] <Dallur> anonimasu: I was getting worried about twist in a 2m long shaft :)
[14:36:50] <anonimasu> oh, it's relative to the diameter of the shaft ;)
[14:38:25] <Dallur> Just got a new toy here at work, sd37p2 with a q6700 cpu, quad core with 2x150G raptors, running our linux build process right now, making it sweat :D
[14:39:16] <Dallur> to bad linux RT isn'
[14:39:24] <Dallur> isn't very thread friendly
[14:55:09] <jlmjvm> dallur:what kind of video card are you running?
[15:09:45] <Dallur> jlmjvm: just some old junk, :( build servers don't need good gpus :)
[15:10:25] <jlmjvm> k,was wondering if you were using a pci express vid card
[15:24:11] <xemet> hi
[15:25:00] <xemet> I've got my first approximated NURBS with EMC2 using my G5.2, G5.3 codes! Thank you jepler!
[15:25:15] <jepler> neat -- do you have a screenshot to show?
[15:25:52] <xemet> jepler: I need to implement the gcodemodule in order to show the preview in axis
[15:26:09] <xemet> I can do a screenshot of the backtrace
[15:27:14] <jepler> backtrace meaning the red line when you run the program?
[15:27:20] <jepler> sure, I'd like to see that
[15:27:20] <xemet> there are still a lot of question to solve, first how many division (in your spilne, you set a constant division, but the nurbs can vary a lot in dimesnion depending on how many control points I use)
[15:27:36] <xemet> jepler: yes...how do you call it?
[15:27:43] <jepler> xemet: I call it "backplot"
[15:27:47] <SWPadnos> oh yeah - that reminds me. I have my mother working on a type of cubic that you can calculate path length of, take derivatives, etc. Also she's working on a method that could be used to figure out the optimal number of arc segments to split a spline (or other curve) into
[15:28:06] <SWPadnos> eventually there may be equations to use :)
[15:28:18] <jepler> SWPadnos: hah great
[15:29:09] <xemet> SwPadnos, yes I think we will need something to optimize the number of division and the way in wich the nurbs is divided
[15:29:11] <jepler> xemet: in python, "backtrace" is the information shown when the program encounters an error, it shows the lines of code involved
[15:29:41] <xemet> jepler: ah ok, so I can do a screenshot of the backplot
[15:30:14] <xemet> jepler: a question...in gcode module...practically, I should repeat all the calculations to find the nurbs points...?
[15:30:22] <jepler> xemet: imagebin.org is a place to upload it if you don't have another website to put a screen shot online
[15:30:51] <jepler> xemet: yes and no
[15:31:29] <xemet> jepler: for your cubic bezier, you did know the expression, for nurbs the expression is dependant from the number of control points, so I've to calculate the points on the fly, so I've at leat other three sub-function
[15:31:56] <xemet> jepler: should I copy them in the gcodemodule?
[15:32:04] <SWPadnos> closed form is a real bitch in these cases
[15:32:22] <jepler> xemet: in gcodemodule you want to divide the curve up into straight segments rather than arcs, so the code will not be exactly the same.
[15:32:48] <xemet> jepler: I know, but to do the lines, I need to know the points...
[15:33:07] <xemet> jepler: you calculate the points using the cubic bezier expression
[15:33:54] <xemet> jepler: I don't have a fixed expression,
[15:34:28] <xemet> I use other functions to calculate the points, so I should copy them in Gcode module, in order to recalculate points there
[15:34:41] <jepler> xemet: OK, now I think I understand your question
[15:35:01] <jepler> xemet: yes, you can simply copy those functions to gcodemodule.cc
[15:35:13] <xemet> jepler: ok
[15:35:21] <jepler> xemet: however, it would be best to have only one copy of the functions, rather than two.
[15:35:42] <xemet> jepler: I tought
[15:35:57] <jepler> xemet: by putting those functions in a new source file which is linked into both gcodemdule and emc itself
[15:36:10] <xemet> understand
[15:37:06] <jepler> xemet: for instance, you could put them in a new file like 'rs274ngc_nurbs.cc' and add that to the list of LIBRS274SRCS in src/emc/rs274ngc/Submakefile
[15:37:17] <jepler> then those functions would be available to anything using librs274
[15:37:40] <xemet> jepler: good, I will try that
[15:38:09] <jepler> xemet: also, put the prototype of the functions in rs274ngc.hh
[15:38:19] <jepler> (do you know what a prototype of a function is?)
[15:39:00] <xemet> uhm...no :) (maybe "function allusion?")
[15:39:47] <jepler> if your function is 'int f(double a, double b) { ... }' then its prototype is 'extern int f(double, double);' or 'extern int f(double a, double b);'
[15:41:12] <jepler> for each function that is defined in one file and used in another, you put the prototype in a header file, so that all the files know the form of the function -- its
[15:41:22] <jepler> name, its return type, and its argument types
[15:41:24] <xemet> ok, understood
[15:42:47] <xemet> so I should put the functions in a source, add this new source to the submakefile and add them as prototypes in a header shared between emccanon.cc and gcodemodule.cc
[15:42:52] <SWPadnos> I think in C++ you need to specify the variable names in the prototype (I'm not positive though)
[15:46:46] <SWPadnos> hmmm - that may be for class member functions only
[15:49:18] <xemet> http://imagebin.org/7551 5 control points nurbs generated on the fly with MDI commands
[15:50:36] <jepler> neat! it must be very gratifying to see that
[15:51:17] <xemet> yes :) specially because two week ago for me the emc2 source files were absolutely obscure!!
[15:51:44] <xemet> now they are still obscure...:) but I know a 1-2% :)
[15:52:46] <jepler> more importantly, you know that you *can* learn more of it, if you care to
[15:53:42] <xemet> well, I really like to learn new things, so I think I will continue...
[15:54:08] <xemet> however that would bee impossible without your help and your patches...
[15:54:18] <jepler> xemet: do you have a plan for how to subdivide the curve better?
[15:54:30] <xemet> at the moment...not
[15:54:54] <xemet> also, I need to know how EMC2 would like to have it...
[15:55:21] <xemet> explain...I would like to know what is the smallest segment I can do without EMC2 having trouble
[15:55:43] <xemet> you told me there is no formulas for that
[15:55:44] <jepler> If the user specified a tolerance (such as G64 P0.01) then you should get with 0.01 of the actual NURBS curve even if it makes emc2 slow down
[15:56:09] <xemet> yes...there are a lot of problems...
[15:56:51] <xemet> first, I do not have a nurbs expression like for exaple x(u) = a +b + c*u + U^2...
[15:56:57] <xemet> etc.
[15:57:32] <jepler> now let me talk about the case with emc drawing short *straight* segments for a moment. If you look at the plot of velocity vs time when drawing a line from (0,0,0) to (1,0,0) you will see a trapezoidal shape. The rising slope is called acceleration, the constant part is called cruise, and the falling slope is called deceleration
[15:57:33] <xemet> so, I know nurbs points calculated with certain u values
[15:58:00] <xemet> understood
[15:58:10] <jepler> if the line is short, it is a triangle: there is no cruise phase
[15:58:22] <xemet> so the segment *must* allow the complete acceleration, costant velocity and decelration
[15:58:23] <jepler> (if the distance moved is short, e.g., (0,0,0) to (0.01,0,0)
[15:58:41] <jepler> emc only does well at keeping the requested speed when there is a cruise phase on every line
[15:59:26] <xemet> understood, the question is, how do I know the measure of the smallest segment when I know requested velocity and max vel and max acc of the machine?
[15:59:37] <jepler> so the length of the line is related to the acceleration and the requested velocity
[15:59:50] <xemet> yes
[16:00:02] <jepler> I don't have the equation at hand but I think you could work it out for yourself
[16:00:28] <xemet> yes, now that I think about it, it should be very simple
[16:00:36] <xemet> in the case of straight segments
[16:01:03] <jepler> for *arcs* the situation is more complicated, because a certain part of the acceleration is required in order to stay on the circular path -- I believe term for this is "centripetal acceleration"
[16:01:09] <jepler> this acceleration depends on the radius of the arc
[16:01:15] <xemet> yes, I know
[16:01:28] <xemet> it can be figured out with some equations
[16:01:45] <jepler> so you get an equation that includes arc length, requested feed rate, and arc radius
[16:02:38] <xemet> so do I calculate the acceleration and compare it with the max acc of the machine??
[16:02:58] <xemet> uhm
[16:02:59] <jepler> I have to go to a meeting .. I hope to be back later
[16:03:06] <xemet> ok
[16:03:50] <xemet> see you
[16:28:35] <CIA-6> 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/ (interp_arc.cc interp_convert.cc): fix ijk format single-arc entry. still need to patch up r format.
[16:38:26] <CIA-6> 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_arc.cc: check for tool too big
[16:44:46] <CIA-6> 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_arc.cc: fix r format single-arc entry
[17:08:31] <a-l-p-h-a> anyone miss me?
[17:12:50] <jepler> a-l-p-h-a: of course
[17:21:32] <skunkworks> jepler: did you see the 6ft cable works also?
[17:22:01] <jepler> skunkworks: no -- that's good news too
[17:22:20] <jepler> skunkworks: you've never used index pulse yet, have you?
[17:22:41] <skunkworks> NO
[17:22:44] <skunkworks> NO
[17:22:46] <skunkworks> No
[17:22:49] <skunkworks> sorry
[17:24:38] <plattschnauze> does anybody knows if alex is going online today?
[17:25:53] <SWPLinux> he's traveling, so it's anybody's guess
[17:26:11] <skunkworks> plattschnauze: no - he is on a business trip iirc.. so his access has be spastic.
[17:26:18] <skunkworks> what SWPLinux said
[17:26:25] <plattschnauze> thanks
[17:31:25] <CIA-6> 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: fix typo
[17:31:54] <plattschnauze> im trying to get the pumakins run , and at my momentary point im asking myself why the axis are going so slow while jogging in worldcor ? maybe ramps, or cpu-speed ? does anybody know?
[17:34:53] <SWPLinux> joint accel/velocity limits?
[17:38:47] <plattschnauze> in axis mode they run quit fast
[17:39:49] <plattschnauze> sorry for my english
[17:41:55] <SWPadnos> can you post your ini file to
http://pastebin.ca ?
[17:46:59] <plattschnauze> i could only send e-mails becaus im a winidiot and new to linux , i think i will go on with alex when hes back, because he already has all files from my emc, and i wont get you to mutch work, but thanks
[17:47:35] <SWPLinux> if you can load that website on your EMC computer, then all you have to do is copy from your ini file and paste into the editing area
[17:47:48] <SWPLinux> the keystrokes are the same as in Windows (ctrl-C, ctrl-V)
[17:48:14] <SWPLinux> either way is OK though ;)
[17:53:22] <plattschnauze> thanks for trying but i would try some things, in case of no results , i would come back for asking
[17:53:28] <SWPLinux> ok
[17:56:02] <duerz> anyone got time for some greenie questions?
[17:58:17] <skunkworks> ask away
[18:00:01] <duerz> this hal stuff really has me miffed
[18:00:32] <SWPLinux> that's not a question :)
[18:00:44] <duerz> for example - when you first design a machine - you draw out the prints with all the devices(io) right?
[18:02:00] <SWPLinux> are you looking for a graphical tool to configure HAL with?
[18:02:25] <duerz> well - then in my world anyway - you then draw out a symbols file - which tells you where all the io is hooked o\up at.
[18:02:47] <duerz> according to your harware of course
[18:03:01] <SWPLinux> ok, so you're using some CAD / diagramming package to make drawings
[18:03:10] <duerz> a graphical tool would be helpful
[18:03:30] <SWPLinux> it would. unfortunately, none exists at the moment (that's really usable)
[18:03:55] <duerz> these points then go where in hal - pins?
[18:04:19] <SWPLinux> let me make sure I know what you're starting with (when you go to configure EMC)
[18:04:31] <SWPLinux> do you have a wiring diagram for the machine?
[18:04:36] <duerz> yes
[18:04:53] <SWPLinux> ok, and you have specs for the motor drivers and other components used?
[18:05:06] <duerz> yes
[18:05:46] <SWPLinux> ok. then it should be pretty easy, though not very "pretty" to configure HAL (in the sense that editing text files isn't as pretty as making drawings)
[18:06:52] <SWPLinux> would you also know at this point what hardware you expect to use (parallel port, USC, Mesa card, additional 8255-based digital I/O, Motenc, STG ...), or would you decide on hardware based on the number of I/Os and type of motor drivers you're using?
[18:08:04] <duerz> you see - where im getting miffed is- the convention of naming these io points- and where do they go? are they already named - for example i will be using the vigilant card with io expander
[18:08:38] <SWPLinux> ok - I'm not familiar with the exact features of that card (or what the driver exports), but I can give you general help
[18:10:27] <SWPLinux> do you have the vigilant card installed in a computer you can configure with?
[18:10:57] <duerz> ok - i have your vti - which came in your software. it wont run - unless i have the card. So i put the card in - and does it automatically configure the io mapping and name the points?
[18:11:08] <SWPLinux> (this is a problem with configuration - you can't see what a driver will export unless you have a realtime system with the hardware installed)
[18:12:15] <SWPLinux> the card should be detected if you try loading the sample config for VTI
[18:12:39] <SWPLinux> the driver will export pins with certain names, and those correspond to the hardware detected
[18:13:13] <duerz> under what section in hal - pins?
[18:13:17] <SWPLinux> you need to connect those pins to various parts of EMC to do what you want
[18:13:26] <SWPLinux> yes, pins, params, and functions
[18:14:52] <duerz> they caanot be renamed?
[18:14:57] <duerz> cannot?
[18:15:20] <SWPLinux> no - the items exported by the driver are hardcoded (they can be changed if you want to edit the source and recompile)
[18:15:34] <duerz> no thanks :)
[18:15:36] <SWPLinux> you can change the connections and the names of the connections (signals)
[18:17:12] <SWPLinux> oh - I think I see a different question than I answered above. yes, if you load the vti config, then it should see the card and provide you with a configuration. If you don't like where things are connected, you need to edit the .hal files
[18:17:45] <SWPLinux> you'll have to make a copy in some directory where you have write permission to make changes
[18:18:38] <duerz> ok - ill have tp play around with this - before i truly understand it
[18:18:50] <SWPLinux> have you read the HAL section of the users manual?
[18:19:09] <duerz> yes-2x
[18:19:12] <SWPLinux> heh
[18:19:17] <duerz> its not sinking in
[18:19:47] <SWPLinux> remember that HAL is only the means of configuring how the internals of EMC are connected
[18:20:25] <SWPLinux> this does include the ability to change where things connect to the outside world, because HAL drivers are the interface to the hardware that talks to the world
[18:21:41] <SWPLinux> unfortunately, there are no diagrams (no chapter at all, actually) for the VTI hardware, because none of the active developers of emc2 have that hardware :)
[18:21:47] <duerz> well i gotta beat my head up againt hal for a couple days. ;)
[18:22:17] <duerz> we use vti all the time with OPenCNC
[18:22:21] <SWPLinux> make sure you're able to use halcmd to discover things - that's key
[18:22:38] <lerneaen_hydra> 'lo
[18:22:49] <SWPLinux> it's very easy to use halcmd or halconfig to see what you have to work with
[18:23:24] <duerz> yes - ive seen it - with your halui sim
[18:24:24] <SWPLinux> once you know how to look around in HAL, then you need to learn what the various pieces of EMC are called - what features the motion controller has and what pins they're on, etc.
[18:24:56] <SWPLinux> after that, you should have no problem connecting things in emc to whatever they need to connect to on your machine
[18:25:35] <duerz> thank you sir
[18:25:44] <SWPLinux> any time (for the most part) :)
[18:26:03] <SWPLinux> it's easy once you get used to it - I think you'll be impressed with the capabilities
[18:28:23] <duerz> im sure i will - do any of you guys provide training for a fee? :)
[18:28:37] <SWPadnos> sure - where are you located?
[18:28:45] <SWPadnos> (I'm all for free travel ;) )
[18:28:47] <duerz> michigan
[18:28:59] <SWPadnos> bummer - that's not much better than Vermont
[18:29:05] <SWPadnos> UP or LP?
[18:29:16] <duerz> lp - ann arbor
[18:29:54] <rayh> I'm in michigan -- UP. That probably is a 7+ hour drive for most michigan folk.
[18:30:02] <duerz> i would have to ask my boss though - he is the one having me research this
[18:30:32] <duerz> rates?
[18:30:40] <rayh> I'll be in Ann Arbor in a couple weeks but wouldn't have more than an hour to spend.
[18:30:57] <rayh> Not much time for HAL and EMC2!
[18:31:28] <duerz> i wouldnt think so
[18:31:41] <duerz> ive been banging my head for days
[18:32:18] <SWPadnos> CNC workshop may be a good thing to attend, if mid-June isn't too late for you
[18:32:33] <duerz> where is that held?
[18:32:41] <SWPadnos> Galesburg, IL
[18:32:47] <SWPadnos> http://www.cnc-workshop.com
[18:32:54] <duerz> they teach emc only
[18:33:09] <SWPadnos> no - lots of stuff
[18:33:19] <SWPadnos> and most of the EMC2 developers also attend
[18:33:44] <duerz> what other controls do they teach?
[18:34:14] <SWPadnos> not so much for controls, but build-your-own and retrofitting, plus other techniques (lost-foam casting, anodizing ...)
[18:34:45] <duerz> i need just emc training
[18:35:12] <skunkworks> doesn't ray teach emc classes during the workshop?
[18:35:16] <SWPadnos> generally
[18:35:47] <duerz> rayh?
[18:35:46] <SWPadnos> there will be EMC related classes - I don't know how many at this point (and the website isn't too infromative)
[18:35:49] <SWPadnos> yes
[18:35:58] <rayh> yes sir.
[18:36:05] <skunkworks> :)
[18:36:16] <rayh> Reading back I see that you are using a vti card.
[18:36:27] <duerz> yes
[18:36:38] <rayh> You can not rename it's pins or params.
[18:36:58] <duerz> i see - you amiliar with opencnc?
[18:37:01] <rayh> But you can name your own signals and connect them to the vti pins.
[18:37:33] <rayh> Then you can use those signals just like you would in the listing for a commercial cnc.
[18:38:35] <rayh> Or even better, you can name them in common english so you know exactly what the device is.
[18:38:57] <duerz> right!! - thatis what i was looking for
[18:39:12] <rayh> Then when you setup machine logic using classicladder you can also use that common name as the name of the ladder variable.
[18:39:32] <rayh> so as a crude example
[18:40:36] <rayh> newsig xmlim
[18:40:50] <rayh> for x axis minus limit
[18:41:19] <rayh> linkps vti.0.input0 xmlim
[18:41:33] <jepler> you need to speicfy the type, e.g.: newsig xmlim bit
[18:41:43] <rayh> right sorry thanks jeff.
[18:42:38] <duerz> starting to make sense
[18:42:38] <rayh> let me start a system and do this for real.
[18:43:42] <rayh> linksp xmlim classicladder.0.in-00
[18:44:14] <rayh> and then in ladder press Symbols
[18:44:48] <rayh> and add variable %I0 and name it xmlim
[18:46:19] <rayh> The signal names in ladder need to be < nine letters or it gets all jumbled up.
[18:46:54] <rayh> I don't have the vti card so the actual name of the vti input pins are different from my example.
[18:47:25] <rayh> I'd start emc2 with the vti configuration. Once it starts open halshow and look for the actual pin names.
[18:47:59] <duerz> im about to find out - soon as get it all set up
[18:48:07] <duerz> thanks
[18:48:36] <SWPadnos> rayh, thanks for saying what I was trying to say in a more understandable form :)
[18:54:59] <rayh> np
[18:55:10] <rayh> I just went through this yesterday.
[19:01:15] <duerz> ok i just put the card in and VTI came up - i see the in 00/in-00 not . in the hl config under pins/ vti
[19:03:04] <rayh> fantastic.
[19:03:27] <duerz> :)
[19:03:52] <duerz> although i dont think the io expander card is being read
[19:06:43] <jepler> duerz: based only on looking at the comments in the hal_vti driver I think you simply add more letters to dio= in the loadrt line to use the I/O expander
[19:10:45] <duerz> in vti_io.hal file?
[19:11:08] <jepler> vti_motion.hal, I think
[19:11:15] <jepler> vti_motion.hal:6:loadrt hal_vti num_chan=4 dio="IOIO"
[19:12:32] <duerz> "IOIO"means?
[19:12:55] <SWPadnos> in out in out
[19:13:01] <duerz> binary?
[19:13:09] <SWPadnos> each letter is 4 or 8 bits - I'm not sure which
[19:13:39] <jepler> the comments at the top of the source file explain what the letters mean.
http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/hal_vti.c?rev=1.12;content-type=text%2Fx-cvsweb-markup
[19:13:46] <jepler> I denotes 8 bits of input; O denotes 8 bits of output
[19:14:05] <jepler> you can also write io and io for 4 bits of each in a block of 8 bits
[19:14:09] <jepler> er, io and oi
[19:17:13] <duerz> i see- i off to the races now - i think
[19:17:18] <duerz> thanks again
[19:41:08] <CIA-6> 03cradek 07TRUNK * 10emc2/nc_files/comp311_2.ngc: single arc entry demo program
[20:01:17] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/sai/driver.cc: make sure the program's return value is 0 (EXIT_SUCCESS) when interpretation finished successfully
[20:09:28] <xemet> other nurbs test, same control points different order k:
http://imagebin.org/7554
[20:14:32] <CIA-6> 03jepler 07TRUNK * 10emc2/scripts/runtests: allow tests to be implemented as shell scripts, not hal scripts. this will be used for interpreter tests
[20:16:14] <CIA-6> 03jepler 07TRUNK * 10emc2/tests/ccomp/mill-line-arc-entry/ (expected test.ngc test.sh test.tbl test.var): first cutter compensation regression test
[21:06:43] <CIA-6> 03cradek 07v2_1_branch * 10emc2/src/emc/rs274ngc/interp_convert.cc: merge 1.58: incremental mode comp motion
[21:07:35] <CIA-6> 03cradek 07v2_1_branch * 10emc2/src/emc/rs274ngc/interp_convert.cc: merge 1.60, 1.61: single arc entry comp motion
[21:08:32] <jepler> cradek: by the way, I think that sai doesn't yet read new-format tool tables
[21:08:43] <CIA-6> 03cradek 07v2_1_branch * 10emc2/src/emc/rs274ngc/interp_arc.cc: merge 1.9-1.11, single arc entry comp motion
[21:09:38] <cradek> jepler: ok we'll want to fix that
[21:10:02] <jepler> a non-"interactive" mode would be nice too
[21:13:13] <duerz> for some reason i dont think the VTI driver works?
[21:14:14] <cradek> have more details?
[21:15:14] <duerz> the inputs 8-? are all reversed. the inputs are all high?
[21:15:20] <duerz> 0-7 ok
[21:15:48] <duerz> not boards - tesed with different system
[21:16:23] <duerz> in vti motion have dio="IOIOIOIO"
[21:16:24] <cradek> are they stuck high, or just reversed?
[21:16:44] <duerz> WELL THE NOT'S ARE LOW AND THE OTHERS ARE HIGH
[21:17:41] <duerz> 0-7 the nots are high and the others are low
[21:17:57] <duerz> ??
[21:18:13] <cradek> sorry I'm pretty clueless about that driver and board
[21:18:16] <cradek> maybe someone else can help
[21:18:25] <jepler> the e-mail address I have for the most recent developer on the vti driver is <ejohnson AT aaainc.com>
[21:19:02] <jepler> have you hooked something up to the inputs that should drive them LOW? If there is nothing attached, maybe they simply have pull-up resistors that are active.
[21:19:59] <duerz> i will hook up boards
[21:36:30] <duerz> yeppers that was it - has to be hooked up to something. Strange OpenCNC didnt do that though?
[21:40:08] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py:
[21:40:08] <CIA-6> reset_interpreter rewrites the var file, which causes it not to exist for a
[21:40:08] <CIA-6> short time, but axis was not waiting for this. As long as the new var file is
[21:40:08] <CIA-6> written before EMC_COMMAND_TIMEOUT (1 second), this fixes the error
[21:40:08] <CIA-6> IOError: [Errno 2] No such file or directory: 'sim.var'
[21:40:09] <CIA-6> when opening an ngc file
[21:42:35] <CIA-6> 03jepler 07v2_1_branch * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: merge rev 1.52: fix intermittent error "IOError: [Errno 2] No such file or directory: 'sim.var'"
[21:43:48] <jepler> cradek: did you do a changelog entry for the compensation fixes yet?
[21:43:50] <jepler> don't forget it, that's a biggie
[21:44:15] <cradek> not yet
[21:44:17] <jepler> and the original incremental arc thing, if that was different
[21:47:32] <CIA-6> 03jepler 07v2_1_branch * 10emc2/debian/changelog: note new axis varfile bugfix
[21:55:41] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/sai/saicanon.cc: use specified var file instead of the hard-coded one
[21:56:38] <SWPadnos> hmmm - who has control of list settings on SourceForge?
[21:56:57] <SWPadnos> it may make sense to add the wiki and linuxcnc.org to the footer
[21:57:18] <SWPadnos> (if possible)
[21:58:02] <SWPadnos> to the footer of dev list and user list emails, that is
[21:59:18] <CIA-6> 03cradek 07TRUNK * 10emc2/tests/ccomp/mill-g90g91g92/ (expected test.ngc test.sh test.tbl test.var): a somewhat complex test using various coordinate modes, and tool comp with single-arc (helix) entry
[22:02:30] <cradek> wow, I had not used g92 in a program before - I like how AXIS shows the origin move
[22:03:29] <cradek> and the dimensions update! that is the coolest thing ever.
[22:04:00] <SWPadnos> heh
[22:06:48] <skunkworks> what? cradek using g92?
[22:06:55] <cradek> only in a regression test!
[22:08:30] <skunkworks> riiiight. ;)
[22:08:52] <CIA-6> 03cradek 07TRUNK * 10emc2/tests/ccomp/mill-g90g91g92/ (expected test.ngc): a little more perverse
[22:08:58] <robin_sz> TRUNK! ...
[22:09:07] <robin_sz> * robin_sz imagines a giant elephant
[22:09:24] <robin_sz> I can do a fair impression of an elephant actually
[22:09:28] <roltek> cradek did you get the book
[22:10:21] <cradek> yes thank you! it was there this morning (strangely)
[22:10:45] <roltek> good i hope this helps
[22:11:08] <cradek> I haven't had a chance to look at it yet, but I bet it will
[22:11:18] <cradek> we're often short on good lathe information
[22:11:20] <cradek> I appreciate it
[22:11:54] <roltek> i'll have to see if i can get some mill book's also
[23:23:49] <Martin_Lundstrom> Hello folks
[23:23:58] <Martin_Lundstrom> Dallur, Are you still around?
[23:25:03] <CIA-6> 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/ (rs274ngc.hh interp_convert.cc interp_arc.cc): fix semicircle single-arc entry move in R format
[23:27:40] <Rugludallur> hey Martin, im still here but heading off to bead
[23:27:54] <Rugludallur> Martin: err bed, (pretty tired)
[23:34:21] <Rugludallur> good night people
[23:37:17] <Martin_Lundstrom> nighty