Back
[00:00:12] <SWPadnos> you should write in C++, making heavy use of STL and templates
[00:00:19] <SWPadnos> and polymorphism
[00:00:19] <Ziegler> lol
[00:00:40] <SWPadnos> especially polymorphism
[00:01:11] <CIA-8> 03jmkasunich 07HEAD * 10infrastructure/farm-scripts/run_farm: hide some extraneous output
[00:02:34] <owhite> *grumble*
[00:03:33] <granville> hi guys, i've got the number of notches on the pulleys and number of steps for 1 rev. can someone tell me how to figure out the right scale?
[00:03:46] <SWPadnos> yep
[00:04:01] <SWPadnos> is there a belt or gear reduction as well?
[00:04:23] <granville> i think i may have to run back and get one more number, but here goes....
[00:04:26] <Rugludallur> owhite: im currently working on a dxf2gcode python converter :D
[00:05:04] <granville> the motor had 2000 steps for 1 rev, and the pully on the motor is a 16x the belt connects it to a 60x
[00:05:13] <owhite> rugludallur: what's the plan? would it work on the command line, or are you working on some type of GUI?
[00:05:32] <Rugludallur> owhite: both, got a 3D viewer with gui and command line
[00:05:37] <granville> the 60x is on a shaft with a 14.5 degree 16 tooth pinion gear that meshes into the rack.
[00:06:13] <owhite> Rugludallur: is this the pythonCAD project or something else?
[00:06:23] <jmkasunich> granville: so the only thing we need now is the teeth per inch of the rack
[00:06:39] <Rugludallur> owhite: something else, although I use the dxf module from the pythoncad project
[00:07:09] <Rugludallur> owhite: not sure if I will do spline to polyline though, I think that might be better done by the cad appliation saving the dxf
[00:07:12] <granville> measuring 2 inches, it looks like 8 teeth, so i'm figuring 4 tpi. the gears for the pulley as well as the rack gear are martin gears from mcmaster carr
[00:07:34] <jmkasunich> measured as accurately as possible - for example, if you have a six inch dial caliper, count how many teeth fit in just under 6 inches, and measure the length of that many teeth as carefully as you can
[00:07:53] <jmkasunich> oh, do you have the mcmaster carr part number?
[00:08:00] <granville> i'm trying to find the receipt so i can get the part number.
[00:08:02] <owhite_> Rugludallur: how far along is your project?
[00:08:11] <jmkasunich> granville: that would be perfect
[00:09:23] <Rugludallur> owhite: been working for 2-3 days now, got parsing done, 3D viewer complete, currently outputting gcode for everything except arcs
[00:09:53] <Rugludallur> owhite: still need to do quite a bit of testing and optimization
[00:10:14] <owhite_> Rugludallur: well I'd be interested in hearing about your progress.
[00:10:29] <owhite_> I gotta run.
[00:10:30] <Rugludallur> owhite: let me get ya a screenshot from 3d :D
[00:11:01] <Ziegler> ok gues
[00:11:03] <Ziegler> guys
[00:11:06] <Ziegler> I got the circuit working
[00:11:14] <Ziegler> but I think I am sending the pulses to fast to the steper
[00:11:15] <jmkasunich> motors turning?
[00:11:19] <Ziegler> its jittering
[00:11:28] <Ziegler> bu the phases are fireing in order
[00:11:36] <jmkasunich> could be - unipolar drive is very limited in speed and acceleration
[00:11:52] <jmkasunich> that is controlled by the ini file, you can turn the values down a lot and see what happens
[00:12:03] <Ziegler> can I edit that live?
[00:12:04] <jmkasunich> if it starts working turn them up slowly...
[00:12:13] <jmkasunich> no, gotta exit from emc
[00:12:17] <Ziegler> ok brb
[00:13:02] <jmkasunich> granville: I'm gonna guess that you have a 16 tooth, 12 pitch gear
[00:13:09] <jmkasunich> the outside diameter is 1.5 inches
[00:13:24] <granville> organization isn't my strong suite, i found a few receipts but not the right one.
[00:13:40] <granville> 1.5 inches sounds about right.
[00:13:50] <jmkasunich> whats the most precise measuring tool you have?
[00:14:09] <granville> calipers. i was using them measuring the 8 teeth in 2 inches.
[00:14:22] <Ziegler> Do I turn down MAX_VELOCITY ?
[00:14:37] <jmkasunich> measure the gear OD and width and we can compare them to the mcmaster catalog values
[00:14:40] <Ziegler> its at 1.2...
[00:14:45] <Ziegler> is that rps?
[00:14:45] <jmkasunich> Ziegler: yes
[00:14:50] <jmkasunich> thats inches per second
[00:14:58] <Ziegler> ahh
[00:15:00] <granville> ok, give me 5 minutes, the shop is 1000 feet away.
[00:15:10] <jmkasunich> granville: ouch
[00:15:49] <jmkasunich> Ziegler: you are just spinning a motor with no leadscrew or other linear drive on it right now?
[00:15:55] <Ziegler> yes
[00:17:05] <jmkasunich> ok, you probably want to change the INPUT_SCALE in the AXIS_0 section of the ini file
[00:17:14] <jmkasunich> since you don't have a screw or anything, lets work in revolutions
[00:17:22] <jmkasunich> do you know how many steps per rev your motor is?
[00:17:26] <jmkasunich> (commonly 200)
[00:17:50] <Ziegler> one sec let me find the specs (I ripped it out of a cheap scanner this morning)
[00:18:24] <jmkasunich> in that case it might be coarser, maybe 48 per rev or something
[00:19:19] <Ziegler> http://www.tranzistoare.ro/datasheets/90/502505_DS.pdf This is basically it.. .ecept mine had 5 wires
[00:19:35] <Ziegler> 7.5 angle
[00:19:58] <jmkasunich> 360 /7.5 = 48 steps/rev
[00:20:27] <jmkasunich> so, if you set OUTPUT_SCALE to 48, then the units will be motor revs (which is reasonable when you are just playing around)
[00:20:39] <jmkasunich> later you'd put the screw turns per inch and such into the mix as well
[00:21:02] <jmkasunich> with scale = 48, then the 1.2 max vel is 1.2 revs per second, or 72 rpm
[00:21:08] <jmkasunich> which your motor might do OK
[00:21:39] <jmkasunich> the original scale value was 4000, so 1.2 velocity = 6000 RPM - no wonder it wouldnt' spin
[00:23:30] <granville> ok, the pinion gear looks like between 1.15 and 1.17, the rack is .75x.75
[00:24:05] <jmkasunich> thats the outside diameter?
[00:24:15] <jmkasunich> how many teeth did you say it had - 16?
[00:24:19] <Ziegler> ok my input scale was 4000 but me output scale was 1
[00:24:26] <jmkasunich> ignore output scale
[00:24:37] <jmkasunich> oops, I told you output scale, my mistake
[00:24:37] <Ziegler> ohh I want to change input scale
[00:24:42] <Ziegler> :D
[00:25:48] <Ziegler> ummm
[00:25:57] <jmkasunich> granville: hello?
[00:26:03] <granville> right 16 teeth
[00:26:04] <Ziegler> no estop want to turn on every time I change the x value
[00:26:07] <Ziegler> now*
[00:26:36] <granville> i'm guessing it's the 6325K13
[00:26:44] <jmkasunich> granville: those specs don't seem to match up
[00:27:04] <jmkasunich> thats what I thought from the OD and tooth count
[00:27:20] <jmkasunich> but that has a 1/2" face width, you said the rack is 3/4" wide
[00:27:39] <granville> hmm
[00:28:01] <jmkasunich> the only rack that is 3/4 x 3/4 is the 12 pitch stuff, 6295K16
[00:28:14] <jmkasunich> but a 12 pitch 16 tooth gear has an OD of 1.500
[00:28:24] <granville> maybe that give clearance between the plate the rack is mounted on and the pinion gear.
[00:28:27] <jmkasunich> (6325K24)
[00:29:08] <jmkasunich> so, we still don't know if its 12 pitch or 16 pitch
[00:29:27] <jmkasunich> the OD and tooth count says 16 pitch
[00:29:32] <granville> souns like 16 pitch right?
[00:30:03] <granville> the 12 pitch would be 1.5 inches in diameter, right?
[00:30:17] <jmkasunich> but 16 pitch has 5.093 teeth per inch, and you said it was about 4
[00:30:46] <jmkasunich> 12 pitch has 3.819 teeth per inch, much closer to 4
[00:31:11] <jmkasunich> stuff isn't adding up, one of those two measurements must be wrong
[00:31:13] <granville> i may have been counting valleys insted of peaks, would that make 5 closer?
[00:31:21] <jmkasunich> might
[00:31:29] <jmkasunich> I think the diameter/tooth method is more accurate
[00:31:43] <jmkasunich> lets assume its 16 pitch, you can confirm it some other day
[00:31:54] <jmkasunich> (for example, count the number of teeth in _ten_ inches
[00:31:58] <granville> ok, lets go with that and see if we come up with the scale value i had last night.
[00:32:20] <jmkasunich> the difference between 50.9 and 38.2 is hard to miss
[00:32:29] <jmkasunich> right....
[00:32:34] <granville> ok
[00:32:49] <jmkasunich> so, we have a 16 pitch gear, with 16 teeth
[00:33:04] <jmkasunich> that is convenient, it means the pitch diameter is exactly 1.000 inches
[00:33:20] <jmkasunich> so the circumfirence is pi times 1.000 = 3.1415927 inches
[00:33:24] <Ziegler> step gen 9 works much better
[00:33:27] <jmkasunich> thats how far it moves with one turn
[00:33:34] <jmkasunich> Ziegler: I thought it would
[00:33:39] <Ziegler> :-)
[00:33:46] <Ziegler> 5 didnt like to go in reverse
[00:33:51] <jmkasunich> since thats half stepping, you'll want to change the scale to 96 (96 half-steps per rev)
[00:33:59] <granville> that's one turn of pinion gear in the rack?
[00:34:05] <jmkasunich> granville: yes
[00:34:21] <jmkasunich> 3.14blahblah inches per turn of the gear
[00:34:26] <jmkasunich> now the belt
[00:34:37] <jmkasunich> you have 60 teeth on the big pulley?
[00:34:57] <granville> right, it's also a martin 60x so i'm sure on that one, it was written on the side.
[00:35:15] <Ziegler> you guys rock
[00:35:16] <jmkasunich> and 16 teeth on the little pulley
[00:35:34] <granville> right, and the little one is on the motor, the big on the shaft going to the pinion gear.
[00:35:39] <jmkasunich> so 3.75 revs of the little one for each rev of the big one
[00:35:56] <jmkasunich> I'm gonna back up a sec
[00:36:10] <jmkasunich> we said 3.14... inches per rev, but we really want to know revs per inch
[00:36:43] <jmkasunich> so 1/3.14.... = 0.31831 revs per inch
[00:36:48] <jmkasunich> at the gear
[00:36:59] <granville> ok
[00:37:18] <granville> how did you get the 3.75
[00:37:29] <jmkasunich> 0,31831 revs per inch at the gear times 60/16 teeth = 1.19366 revs per inch at the motor
[00:37:32] <jmkasunich> 60/16
[00:37:41] <granville> nevermind, you have to put a decimal in python or it does integer math.
[00:37:56] <jmkasunich> I'm using an actual calculator ;-)
[00:38:58] <jmkasunich> 1.19366 revs per inch at the motor times 2000 steps per rev = 2387.324 steps per inch
[00:39:10] <jmkasunich> is that what you had?
[00:39:17] <granville> i think so.
[00:40:48] <granville> i've got -2378.3242000000014
[00:41:24] <jmkasunich> .3242 is enough ;-)
[00:41:31] <SWPadnos> I think you have a Pentium bug :)
[00:42:08] <SWPadnos> I get 2378.32414638 (on my HP calculator)
[00:42:20] <jmkasunich> this is a fairly large router, right?
[00:42:36] <jmkasunich> 24"x24"? 48"48"? or ?
[00:42:36] <granville> right, 5 feet by 10 feet
[00:42:39] <jmkasunich> ok
[00:42:56] <jmkasunich> next step is to stretch out a measuring tape on the table, full length or close to it
[00:43:44] <jmkasunich> set the tool just above the tape, carefully jog it one edge of the tool exactly lines up with an inch mark (maybe 4" for example)
[00:43:56] <granville> ok
[00:44:10] <jmkasunich> then with feedrate set quite slow to make sure you don't miss any steps, jog exactly 1 inch, see if the tape agrees
[00:44:18] <jmkasunich> if so, jog 10 inches, see if it agrees
[00:44:27] <jmkasunich> if so, jog 50 inches and check again
[00:44:46] <jmkasunich> you can use MDI for those jogs
[00:44:53] <granville> ok
[00:45:12] <SWPadnos> one thing about the time it takes to do the jogs - the time should be correct regardless of whether the distance is correct or not
[00:45:21] <jmkasunich> true
[00:45:45] <tomp> john, last nite he had .125" error after 35" travel, so didnt see any error at 1" travel ( if that helps)
[00:45:45] <jmkasunich> they will take a little longer than expected because of accel/decel time, but not much
[00:45:54] <SWPadnos> hopefully there was an error in measurement of the time - it should be a little longer than expected, f anything
[00:45:58] <granville> after correcting the scale last night, it was moving the right time for a f1 feed rate, exactly 60 seconds.
[00:45:58] <SWPadnos> right - what he said
[00:46:13] <SWPadnos> it should have been the right time anyway
[00:46:20] <jmkasunich> tomp: 1/8" in 35 = 0.003" in 1"
[00:46:24] <jmkasunich> not likely to see that
[00:46:26] <SWPadnos> unless it took too long due to valocity limits
[00:46:33] <tomp> right, hard for him to see
[00:46:40] <jmkasunich> thats the reason for very long jogs when checking scaling - much more sensitive
[00:47:08] <SWPadnos> hopefully both X and Y have the same drivetrain??
[00:47:26] <SWPadnos> I'd imagine a beefier sprocket on one axis
[00:47:27] <jmkasunich> if not, gotta repeat the measurements and calcs for the other axis
[00:47:31] <SWPadnos> yep
[00:47:33] <granville> x and y are the same. z is a leadscrew
[00:47:36] <SWPadnos> yay
[00:47:50] <granville> i've got the scale set to 40000 on z and that seems to be right.
[00:48:20] <SWPadnos> 2000 steps/rev, 2x or 4x gearing, and 10 or 20 TPI screw?
[00:49:41] <granville> no gearing on the z, the motor has a coupling onto a small leadscrew, not sure the size. but 20 tpi sounds right given the 40,000 scale value.
[00:49:52] <SWPadnos> yep
[00:50:13] <SWPadnos> of course, I meant to say gearing + 5 or 10 TPI screw - oh well ;)
[00:50:20] <jmkasunich> probalby 1/4-20 threaded rod
[00:51:31] <granville> this could be a mechanical problem with the big pulleys, they are held in place with set screws and i did catch them slipping once, i ground a flat place on the shaft for them and thought that was fixed, maybe not.
[00:53:09] <granville> once i get this one working, i'm thinging about building joe's 2006 project from cnczone, it looks like a fun project!
[00:53:34] <tomp> put the setscrew against a key in a keyway :-)
[00:55:03] <granville> that would be a better idea, that's the way i have the one on the motor shaft but it already had keyway. i guess i should pull the shafts and mill a keyway into them to fix this for good.
[00:55:43] <tomp> just kidding, you should be able to snug it up enuf for this test
[00:56:30] <granville> does espn use emc to control that camera they have on the tripod cables over football fields?
[00:56:31] <tomp> but some mark to indicate slippage is ez
[00:57:35] <tomp> there was some suspended hexapod ( cable hexapod) work done, but dunno 'bout espn
[00:58:01] <granville> i saw the cable hexapod setup that's what made me wonder.
[00:58:18] <tomp> look at alex's tri-pod
[00:58:51] <granville> one other thing, when i was doing rapid moves last night, the z axis move was interpolated with the x and y. i thought all g00 moves should move z axis first then x,y. is there a setting for this?
[00:59:59] <tomp> hmm, i think g00 moves all 3 at once but not interpolated ( 1 for x 2 for y, 10 for z etc ), not sequential
[01:00:21] <tomp> in g00 the short move gets done early
[01:00:58] <tomp> ?
[01:01:20] <granville> ok they were moving all at once, don't know about the speed. i know that on my bridgeport the z moves 1st then it make x/y. boss9 is still running so i haven't converted it to emc yet, but i wish it was emc, i hate downloading to that thing!
[01:01:57] <tomp> oh, the bport is doing a 'sfety' thing, it 'gets clear, then over bombsite...
[01:02:01] <tomp> safety
[01:02:26] <granville> right, shouldn't emc have the same safety?
[01:02:58] <tomp> you can program it in 2 lines as you wish, or talk to your friendly post-processor ;-)
[01:03:35] <tomp> i make macros for other systems that go to clearnace plane first, like you describe.
[01:03:46] <tomp> clearance
[01:04:33] <granville> ok, can you tell me about limit switches, i have the switches, but haven't wired them to the parallel port yet. can i make emc go hit each switch back of n inches, and set 0?
[01:04:59] <tomp> and it wont be safe for the horizontal mill:-) my ,macros get info from a global 'tool axis', so can use tombstones
[01:05:02] <SWPadnos> no - espn does not use EMC
[01:05:22] <SWPadnos> at least, SkyCam doesn't - I know that for sure
[01:05:26] <granville> i guess it's too cheap for them ;0
[01:05:40] <SWPadnos> they're pretty cheap, actually ;)
[01:05:47] <tomp> look at Hektor, the spray can graphitti robot
[01:06:56] <tomp> simple, 1 polar angle and a radius... spray can suspended from cogged cables , painting pictures on a wall
[01:07:11] <granville> that's awesome!
[01:07:23] <tomp> got the videos?
[01:07:49] <tomp> comes in a briefcase, way cool
[01:08:51] <tomp> it's alex's tripod with 3rd leg being gravity
[01:10:02] <tomp> sorry, about limit swx...
[01:10:31] <granville> yeah, i was watching one of those videos too, too cool!
[01:10:31] <tomp> yes... i'm looking for the limit swx back off & set ref pt info...
[01:12:04] <tomp> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Home_Switches_With_EMC
[01:13:09] <granville> how do you start the homing seq once you have the limit switches connected?
[01:14:42] <SWPadnos> it varies between the GUIs
[01:14:56] <SWPadnos> but in general it'll be a button, keystroke or menu item
[01:15:08] <tomp> in tkemc, after removing estop & applying mc power, click a DRO (say X), then click 'home'
[01:15:33] <granville> there is a home button but it zero's the axis, does it work different after you have limit switches configured?
[01:16:13] <SWPadnos> yes, I think so
[01:16:36] <granville> ok i'll save that for another day.
[01:16:46] <SWPadnos> when you have no homing sequence/switches defined, it can't possibly find home, so it just assumes that you know what you're doing
[01:17:37] <granville> ok that makes sense
[01:24:52] <granville> tomp, what about max accel and maxvel, and maxaccel?
[01:25:58] <granville> i've got max-accel at 20, stepgen-maxvel at 4.18 and stepgen-maxaccel at 21.0
[01:28:44] <cradek> http://linuxcnc.org/docs/EMC2_User_Manual.pdf pg 74,75
[01:29:12] <cradek> oops, too slow, that's the homing information
[01:30:36] <cradek> looks like that wiki page is old and doesn't describe all the features of emc2
[01:32:29] <granville> i put negatives on all my scale values to make each axis go the right direction, i found this in the emc manual but not in the emc2 manual, is this still proper in emc2?
[01:32:39] <jmkasunich> YES
[01:32:52] <tomp> page 70
[01:36:21] <granville> tomp i guess you are saying page 70 for velocity and acceleration, are there ways to calculate the right numbers for these?
[01:36:55] <jmkasunich> trial and error - they depend on your motors, gearing, drives, etc
[01:37:20] <jmkasunich> gradually increase speed until you start to lose steps, then back off by about 10-20%
[01:37:25] <jmkasunich> then do the same for accel
[01:37:36] <granville> what about an acceptable range for each?
[01:37:45] <jmkasunich> huh?
[01:38:03] <jmkasunich> faster is better (unless you get to a point where you think your machine is too fast)
[01:38:50] <granville> since the feedrate specifies the speed, does this only control how fast it gets to full speed?
[01:39:10] <jmkasunich> use G0 for that testing
[01:39:20] <jmkasunich> G0 will run at max speed, not feedrate
[01:39:38] <jmkasunich> accel controls how fast it gets to top speed
[01:40:42] <cradek> the ini file is the set of constraints under which your machine works properly. Once it's set, no gcode will cause the machine to try to exceed them
[01:41:08] <Rugludallur> is it OK if I write/paste 10 lines into this conversation ?
[01:41:16] <jmkasunich> ok
[01:41:20] <granville> sure
[01:41:20] <cradek> so if you program F9999 and your ini has 1 inch/sec max velocity, you get F60 instead
[01:41:29] <Rugludallur> Here goes:
[01:41:45] <jmkasunich> oops
[01:41:47] <Rugludallur> :D
[01:42:01] <jmkasunich> try 5 at a time
[01:42:11] <cradek> or pastebin.ca
[01:42:23] <Rugludallur> pastebin it is
[01:42:50] <tomp> grabville: sorry was away.. the machine tells you what these parms can be, you only record the info ;-)
[01:42:59] <tomp> granville sorry
[01:44:34] <Rugludallur> http://pastebin.ca/259054
[01:44:39] <granville> so 1.2 for max velocity is the same as a limit of f80?
[01:44:50] <jmkasunich> F72
[01:44:54] <Rugludallur> If you are interested in dxf to gcode converter I would really like comments on that :D
[01:45:03] <jmkasunich> 1.2 inches per second * 60 seconds per minute = 72 inches per minute
[01:45:33] <granville> ok, should have used a calculator!
[01:48:46] <cradek> Rugludallur: I'm having a hard time understanding this
[01:49:11] <Rugludallur> cradek: ok, let me walk you through the logic
[01:49:15] <cradek> Rugludallur: I don't understand encapsulation or toolpath(object)
[01:49:36] <cradek> I think I need an overview - what's the input like and how does it represent the toolpath to be cut?
[01:49:52] <Rugludallur> cradek: toolpath is any number of arcs/lines/polylines that have a common start/end
[01:50:45] <cradek> ok a closed path is a toolpath, what's an object?
[01:51:20] <Rugludallur> cradek: a toolpath can be closed or not closed, but when a toolpath is 100% within the boundaries of another toolpath it is "encapsulated"
[01:51:56] <cradek> ok, it's not clear to me what that means in the 3d case
[01:52:45] <cradek> let's back up a sec - what's a 3d toolpath look like?
[01:52:46] <Rugludallur> cradek: it's a way for me to determine on which side the tool offset should be applied, so in the cad program you define a solid or a curve network which forms a 3d object
[01:53:21] <cradek> ok so they're not toolpaths really, they're part outlines around which the toolpath goes
[01:53:21] <Rugludallur> cradek: Anything that hat arcs/lines/polylines that can be "joined" to form a 3d object
[01:53:52] <Rugludallur> cradek: yes, well they can be on both outside and inside
[01:54:07] <Rugludallur> cradek: in the case of laser or plasma the toolpath is quite often on the inside
[01:55:04] <cradek> ok so you will make one pass of the tool inside or outside of each of the closed "loops"?
[01:55:14] <Rugludallur> cradek: yes
[01:56:16] <cradek> ok I see now - you're worrying so much about the order because you're cutting out parts
[01:56:51] <Rugludallur> cradek: yes, and sometimes you cut out a part from a part from a part .....
[01:56:52] <cradek> sounds like this is really for a laser/plasma type machine only
[01:56:58] <cradek> sure
[01:57:01] <Rugludallur> cradek: the 2d is
[01:57:13] <cradek> ok I understand the goals now I think
[01:57:17] <cradek> oh wait, what's the 3d then?
[01:57:38] <Rugludallur> 3d is for milling/turning but I have not given that as much thought
[01:57:51] <Rugludallur> as I don't have any practical experience with milling or cnc turning
[01:58:02] <cradek> ok
[01:58:16] <cradek> let's talk about the 2d case then
[01:59:16] <cradek> why is it important to cut the smallest area first?
[01:59:37] <jmkasunich> because that piece might fall out of the sheet once its cut
[01:59:43] <robin_sz> right
[01:59:45] <Rugludallur> right
[01:59:49] <jmkasunich> if you cut a big one loose, then try to cut the piece inside it.....
[01:59:51] <cradek> that's the encapsulation problem though isn't it?
[02:00:12] <Rugludallur> yes and there is more, it's also to determine on which side the tool offsets should be applied
[02:00:21] <cradek> I'm thinking of ( o O ) where () is a big circle
[02:00:31] <cradek> why do you need to cut the o before the O?
[02:00:38] <robin_sz> dont need to
[02:01:04] <cradek> ok that's in #2a
[02:01:16] <robin_sz> you only need to cut the "parts within a part" before you cut the "part"
[02:01:27] <cradek> right, he's calling that encapsulation
[02:01:45] <robin_sz> right
[02:02:07] <robin_sz> theres some other funky stuff to do there as well, part avoidance for example
[02:02:36] <Rugludallur> robin_sz: hmm, could you please explain ?
[02:02:47] <robin_sz> you should arrange the G0 moves between one part and the next so as not to pass over already cut parts, in case one has tipped up
[02:03:15] <cradek> ah interesting
[02:03:21] <cradek> they may not fall out cleanly?
[02:03:33] <robin_sz> well, ideally, you dont want them to fall out at all
[02:03:34] <Rugludallur> robin_dz: Got ya, hmm it's not always possible to avoid that but it can be kept to a minimum
[02:04:21] <cradek> I'm worried about #14
[02:04:41] <cradek> if I program a O shape, how do you know if I want the hole or the O that dimension?
[02:04:46] <robin_sz> on the laser, we put microjoints in .. cut for say, 300mm, stop, go back 20mm, weld the joint over for 2mm, move forward 10mm start cutting again
[02:04:48] <cradek> you have to let the user specify it
[02:04:57] <robin_sz> no
[02:05:07] <robin_sz> an O is always done from the outside
[02:05:17] <Rugludallur> My thought there is that if you want a hole cut in something you have to model what you want to cut the hole in
[02:05:25] <Rugludallur> so if you want a hole in a plate you have to model the plate
[02:05:30] <robin_sz> the sheet is always the scrap
[02:05:32] <robin_sz> exactly
[02:05:37] <cradek> ok
[02:05:51] <cradek> that makes sense
[02:05:56] <robin_sz> theres loads and loads of nesting software already that does this
[02:06:00] <cradek> this really is going to be very special purpose it sounds like
[02:06:28] <robin_sz> no, its very very common in the laser/plasma/oxy-fuel cutting industry
[02:06:45] <robin_sz> it all we do, all day every day :)
[02:06:46] <Rugludallur> yes but for milling/turning is another ting
[02:06:48] <cradek> that's special purpose to me, the guy with a milling machine
[02:07:00] <robin_sz> oh with a mill?
[02:07:09] <Rugludallur> cradek: if you see things you want different for milling pls let me know
[02:07:10] <robin_sz> the signmaking boys do this all day with routers
[02:07:14] <cradek> yeah this is special purpose software for cutting flat stuff
[02:07:19] <robin_sz> right
[02:07:20] <Rugludallur> cradek: btw this is all within a layer
[02:07:29] <robin_sz> Rugludallur, you have tried sheetcam?
[02:07:38] <jmkasunich> there are mills, lathes, and everything else ;-)
[02:07:43] <Rugludallur> robin_dz: I have, don't like the output
[02:07:47] <cradek> robin_sz: I'm sure the idea here is to make free software to do this
[02:07:49] <jmkasunich> (from a machinists view of the world)
[02:08:03] <cradek> jmkasunich: mills, lathes, and other stuff I don't have
[02:08:15] <robin_sz> Rugludallur, the output is completely configureable from the Lua macros
[02:08:31] <Rugludallur> robin_sz: already have the parser and most of the gcode output, even have a 3d viewer for it ->
http://imagebin.org/6655
[02:08:50] <robin_sz> parser for ?
[02:08:55] <robin_sz> DXFs?
[02:08:58] <Rugludallur> robin_dz: yup
[02:08:59] <cradek> Rugludallur: the hard part is going to be determing encapsulation, and then the harder part still will be the tool offsetting
[02:09:14] <cradek> or are you going to let emc do the offset?
[02:09:20] <Rugludallur> cradek: that was the idea
[02:09:34] <cradek> ok then the hard part will be figuring out valid entry moves :-)
[02:09:58] <robin_sz> coo, so you nest this in your CAD package and this tool will generate gcode around it?
[02:10:02] <cradek> and if you're cutting concave corners you will have to add appropriate fillet arcs
[02:10:14] <Rugludallur> robin_dz: it's all python so can be run as plugin or on it's own
[02:10:48] <Rugludallur> cradek: noted
[02:10:54] <robin_sz> interesting
[02:10:55] <cradek> to do the fillet arcs, your program has to know the approximate tool diameter
[02:11:14] <Rugludallur> cradek: provide a tooltable in the same format as EMC uses ?
[02:11:28] <robin_sz> Rugludallur, how do you go about positioning the start point?
[02:11:44] <cradek> you want to start off the path for blowout don't you?
[02:11:52] <robin_sz> yeah
[02:12:07] <robin_sz> and deciding where on the profile is a very manual thing
[02:12:07] <Rugludallur> robin_dz: yup, lead in and start with a pierce
[02:12:39] <robin_sz> ive not seen any software that gets it right more than 10% of the time
[02:12:48] <Rugludallur> Since I already know what is inside of part and what is outside the rest is just a matter of finding the shortest possible combo of moves
[02:13:16] <cradek> I recommend you optimize the path last :-)
[02:13:28] <robin_sz> some parts you want the lead in on a corner ... some you know which is the edge that is going to get welded, or wont be seen, and you put the leadin there
[02:13:34] <cradek> the traveling salesman problem is well known because it's hard
[02:14:14] <cradek> if cutting outside, it seems like starting on a convex corner would be good -- but cutting inside, you may not have any
[02:14:19] <robin_sz> thats the normal way, generate each part as a subroutine, then link them up in some order, allow the user to reconfigure the order if they want
[02:14:41] <cradek> I meant worry about writing that feature last
[02:14:46] <jmkasunich> cradek: the traveling salesman problem is only hard if you want the absolute best answer
[02:14:48] <Rugludallur> yup
[02:14:50] <cradek> (jepler and I have done some work on it that might help you)
[02:14:53] <jmkasunich> its not to hard to get a very good answer
[02:14:56] <robin_sz> jmkasunich, im getting real busy now :)
[02:15:10] <cradek> jmkasunich: harder than you think I bet
[02:15:27] <robin_sz> jmkasunich, just taken on a 2nd factory to do the fabrication work, 3 more staff :)
[02:15:36] <jmkasunich> depends on how good an answer you want
[02:15:54] <jmkasunich> if you get within 5-10% of the absolute best path, thats not to bad
[02:16:09] <cradek> yes, and that's pretty darn hard
[02:16:26] <jmkasunich> ok, I'll take your word for it (for now)
[02:16:34] <Rugludallur> But it's not that many combinations for 2d work
[02:16:57] <robin_sz> in anyt real situation, the cut speed is at least 10x slower than the G0 speed, so the difference between a good and a poor optimization solution is actually not really important
[02:17:09] <cradek> true
[02:17:39] <cradek> sometimes the order the user drew the paths is pretty decent, and better than you can get with bad algorithms (like cut the nearest thing next)
[02:18:07] <robin_sz> just working from the left hand end of the sheet up to tthe right hand end is not a bad plan either
[02:18:09] <jmkasunich> if the patterns are closed, there are only two orders - counterclockwise and clockwise
[02:18:30] <jmkasunich> and you usually finish each part where you started it
[02:18:31] <cradek> no he's talking about minimizing the jog time between a bunch of closed paths
[02:18:37] <jmkasunich> understood
[02:19:06] <jmkasunich> you said something about the order in which the user drew _the_ path, I thought you were talking about a single part
[02:19:10] <cradek> (it's exactly TSP because the closed paths are irrelevant and you're traveling between points)
[02:19:14] <cradek> oh I see
[02:19:19] <cradek> I meant "paths"
[02:19:40] <cradek> the user didn't draw way over here and then way over there, because he doesn't like to zoom around so much
[02:20:03] <jmkasunich> the user might have used block copy to make 10 of a particular part, in a 2x5 array
[02:20:08] <cradek> (this is the ordering REALIZE gives you by chance)
[02:20:12] <Rugludallur> and some users (like cradek) are carefull about where curves start and end (to be able to export directly to g-code)
[02:20:27] <cradek> true, and "over then down" isn't a bad solution
[02:20:51] <jmkasunich> this is bringing back memories
[02:21:02] <robin_sz> painful ones?
[02:21:14] <jmkasunich> at least 16-18 years ago I did some optimization for a NC punch press
[02:21:20] <cradek> Rugludallur: (and which direction the loops go)
[02:21:46] <jmkasunich> which is also the TSP, there are no individual part paths, just locations for punch hits
[02:21:51] <cradek> you don't care about loop direction do you
[02:21:55] <Rugludallur> I do
[02:21:57] <robin_sz> he does
[02:22:03] <cradek> why?
[02:22:11] <robin_sz> routers and mills only go one way
[02:22:15] <robin_sz> so does plasma
[02:22:20] <Rugludallur> plasma swirl causes left hand cut to be 90° while right hand is 87 or so
[02:22:28] <Rugludallur> on decent torches that is
[02:22:28] <cradek> oh! cool
[02:22:33] <tomp> yeah
[02:22:46] <cradek> so you may have to juggle the closed paths around
[02:22:49] <tomp> ? same in australia?
[02:22:54] <robin_sz> yeah
[02:22:57] <cradek> hahaha
[02:22:59] <Rugludallur> lol
[02:23:41] <robin_sz> and you get ore dross on one edge than the other
[02:23:43] <robin_sz> more
[02:24:00] <cradek> if you draw a path tracing around the minimum spanning tree, you trace each edge twice and visit all points, so the TSP weight is less than twice the MST weight.
[02:24:04] <cradek> this is the algorithm jepler and I used
[02:24:09] <cradek> http://www.ics.uci.edu/~eppstein/161/960206.html
[02:24:27] <cradek> you know you have an answer with no worse than 2x the best distance
[02:24:42] <Rugludallur> thanks: I will take a look tomorrow when Im rested
[02:25:35] <robin_sz> plasma is a really speciallised CNC ... a bit liek wire EDM and lathe, it has its own peculiar requirements
[02:26:05] <cradek> Rugludallur: your design looks good to me, but you have some hardish problems coming up :-)
[02:26:34] <cradek> Rugludallur: I think the 3d case is not at all well defined yet (like you said)
[02:26:35] <Rugludallur> cradek: well, if I get a good version 1 up im happy
[02:27:03] <Rugludallur> cradek: If you got any great ideas for the 3d stuff I would really like to hear them
[02:27:18] <cradek> it's an entirely different problem
[02:27:26] <Rugludallur> cradek: from what I gathered you put each z movement in a new layer in your program
[02:27:28] <cradek> I don't see how you can do anything more complex than 2.5d by reading dxf
[02:27:43] <cradek> no, each layer is a tool
[02:27:51] <cradek> z depths are just depths
[02:27:53] <Rugludallur> cradek: sorry, yes (my mistake)
[02:28:23] <cradek> REALIZE is very much just 2.5d
[02:28:23] <Rugludallur> cradek: im still working with dxf 1.2 though, I have not taken a look at the newer formats
[02:28:43] <cradek> the entry plunges are particularly bad (on my machine) and I usually doctor the gcode
[02:29:10] <cradek> but to get a nasty line/arc/line/arc/arc/line thing out of cad into gcode, it's great
[02:29:21] <Rugludallur> yup, I can imagine
[02:29:57] <cradek> what kind of radius can you get on a concave corner?
[02:30:20] <Rugludallur> depends on amperage, which again depends on thickness
[02:30:38] <cradek> I see
[02:30:47] <Rugludallur> 3mm material I can probably get down to .5mm radiant
[02:30:48] <cradek> sounds like it will be hard to decide what radius of fillet arcs are needed
[02:31:03] <Rugludallur> cradek: each amperage setting gets a tool in the tool table
[02:31:24] <Rugludallur> cradek: with standoff height and radius
[02:31:34] <cradek> I see
[02:31:56] <Rugludallur> cradek: and a seperate tool for the pierc/gauge which is only called when starting a cut
[02:32:07] <Rugludallur> cradek: seperate radius and standoff height
[02:32:22] <cradek> oh you pierce and then change "tools"?
[02:32:37] <Rugludallur> cradek: that was the idea, have not tried it though
[02:33:09] <cradek> changing tools causes motion to stop
[02:33:27] <cradek> I figured you would want to pierce and then cut to the edge then around, without stopping
[02:33:44] <jmkasunich> isn't piercing done while stopped anyway?
[02:33:47] <Rugludallur> cradek: well there is a pierce delay in any case but ..
[02:34:02] <Rugludallur> so might not matter, will have to test it
[02:34:08] <cradek> ah ok
[02:34:12] <tomp> have you looked at energy (tool)tables for emc? (i'm looking at sink edm)
[02:34:35] <cradek> what does that mean?
[02:34:51] <tomp> the energy changes so i/o chgs
[02:34:53] <Rugludallur> tomp has been thinking the same I have, making a tool table with the amperage values
[02:34:57] <cradek> you have the loaded tool number in hal so you could do any number of things
[02:35:09] <tomp> and some interface/sync is needed
[02:36:25] <tomp> yes hal can do it
[02:36:40] <Rugludallur> cradek: regarding the 3d stuff, I think before I start that I will go read all the new dxf specs and see what kind of 3d support is in
[02:37:29] <jtr> logger_emc: bookmark
[02:37:29] <jtr> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2006-11-27.txt
[02:37:35] <cradek> yeah I have never tried to use anything newer than 3dfaces
[02:37:44] <Rugludallur> cradek: I know there is some solids stuff in there and secondary stuff but I don't know how extensive
[02:38:12] <cradek> 3dfaces are those four pointed triangles :-)
[02:38:35] <Rugludallur> cradek: isn't a 3d face just a polygon ?
[02:38:44] <cradek> yes
[02:38:48] <Rugludallur> thought so
[02:39:31] <Rugludallur> just defining the piece you mill/turn from as a solid would enable an application to do some pretty nifty 3d toolpathing
[02:40:02] <Rugludallur> For lathes that and a 2d cross section should be all you need in combo with the tool table
[02:40:07] <cradek> I've written some of that - it's not very good
[02:40:15] <cradek> for a lathe I can sure see it
[02:40:39] <Rugludallur> milling is a whole lot harder, and once you start talking 5 axis ,, eeek
[02:40:43] <cradek> yes
[02:40:58] <cradek> you can sure represent a simple lathe part in 2 dimensions
[02:41:24] <Rugludallur> yup
[02:42:07] <Rugludallur> get's tricky when you got a milling turret though :P
[02:43:08] <Rugludallur> cradek: have you thought about using two dxf's as a combo for a 3d object '
[02:43:19] <cradek> nope
[02:43:33] <tomp> like 2 paths ( upper & lower) for wedm?
[02:43:40] <cradek> I think using flag dxfs for 3d is pretty much the wrong approach
[02:43:46] <Rugludallur> cradek: that's one of the things I thought about for milling, exporting each view on it's own and joining
[02:43:47] <cradek> flaT
[02:44:18] <Rugludallur> cradek: ok, any thoughts for a good inter-exchange format ?
[02:45:00] <cradek> of 3d geometry? there are lots I'm sure but I don't know which is "best"
[02:45:49] <Rugludallur> cradek: ok, i'll save that for a later date :)
[02:46:03] <Rugludallur> Im off to sleep (almost 3am), good nigh
[02:46:07] <cradek> goodnight
[02:46:12] <tomp> nite
[02:46:20] <tomp> me too , thanks all
[02:56:12] <Ziegler> night all
[02:56:16] <Ziegler> thanks afain for all the help
[02:56:32] <Ziegler> :D
[04:07:46] <jmkasunich> jmkasunich is now known as jmk-away
[04:32:05] <Jymm> Jymm is now known as Jymmmmmmmmmm
[04:37:00] <Jymmmmmmmmmm> Jymmmmmmmmmm is now known as Jymmm
[08:21:19] <Jymmmm> SWPadnos you alive?
[09:33:26] <anonimasu> hm
[10:05:24] <LH_school> 'lo
[10:05:29] <LH_school> logger_emc: bookmark
[10:05:29] <LH_school> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2006-11-27.txt
[10:06:02] <LH_school> that doesn't bode well
[10:40:53] <LH_school> bbl
[11:45:38] <anonimasu> *yawn*
[11:45:42] <anonimasu> what's up?
[11:48:18] <Dallur> *yawn*
[11:48:21] <Dallur> lunch time :D
[11:48:29] <anonimasu> hehe
[11:48:31] <anonimasu> already ate lunch
[11:48:38] <anonimasu> I need caffeine.
[11:48:49] <anonimasu> im drawings stuff today
[11:48:53] <anonimasu> chasing people, around :)
[11:49:14] <Dallur> :P im off for lunch, see you in a bit
[11:50:05] <anonimasu> laters
[12:52:27] <Lerneaen_Hydra> 'lo
[12:52:34] <Lerneaen_Hydra> logger_emc: bookmark
[12:52:34] <Lerneaen_Hydra> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2006-11-27.txt
[12:52:42] <Lerneaen_Hydra> ...
[12:52:48] <Lerneaen_Hydra> slow today
[12:53:06] <Lerneaen_Hydra> looks like I missed all the action
[13:07:27] <kwajstabo> hello
[13:07:35] <Lerneaen_Hydra> hi
[13:08:13] <kwajstabo> can you tell me who wrote the hal module...was this a fsmlabs work?
[13:08:39] <Lerneaen_Hydra> which hal module?
[13:09:03] <Lerneaen_Hydra> or the entire HAL framework?
[13:10:48] <kwajstabo> hal...harvare abstrac layer
[13:11:13] <Lerneaen_Hydra> oh, the entire framework, and not an induvidual module?
[13:11:38] <kwajstabo> i thought this is a module
[13:11:42] <Lerneaen_Hydra> you might be better off asking one of the devs, iirc jmk did work on that, though they probably all know where it came from
[13:12:01] <Lerneaen_Hydra> in HAL there are seperate modules that do certain tasks
[13:12:16] <Lerneaen_Hydra> (counter, quadrature input and so on)
[13:12:43] <kwajstabo> i was wondering, why this hal support only 6 steper motors
[13:12:53] <kwajstabo> why not more
[13:13:39] <Lerneaen_Hydra> you could probably add support for more without too much trouble, at least that's what I seem to remember them saying.
[13:13:57] <Lerneaen_Hydra> in most applications you don't need more than six motors
[13:17:18] <cradek> HAL was written by the EMC2 team but mostly by John Kasunich
[13:17:45] <Lerneaen_Hydra> looks like my guess^W memory was correct :D
[13:17:47] <kwajstabo> if there is not much trubble, why they did not make support for more of them...i would like to make a cnc machine that automaticljy changes the tools and workpieces.
[13:18:11] <kwajstabo> and i am running out of free axes
[13:19:08] <cradek> there is support for 8 motors in all of HAL - you should not use axes for a tool changer
[13:19:59] <cradek> the tool changer can be done in HAL and classicladder
[13:20:23] <cradek> have a look at the demo-mazak configuration in CVS for a nontrivial tool changer setup
[13:20:47] <kwajstabo> ok, thank you
[13:21:14] <cradek> adding more than 8 joints to HAL would be easy if you need them (say, more than 8 stepgens or PIDs) but adding more than 6 to the interpreter and motion controller would be very hard
[13:21:36] <jepler> support for more than 8 'freqgen' or 'stepgen' can be done by recompiling. The "step_type" array has to be declared with a fixed size, and 8 was the size that was chosen.
[13:21:44] <jepler> if you need to increase this limit, there is information on building emc2 from source on our wiki
[13:22:00] <cradek> right, thanks jepler
[13:23:08] <kwajstabo> is there an option for commanding the emc from "outsde"...for instance if i have a camera and i want to set the position of tool
[13:26:48] <kwajstabo> for instance, my idea is to place a smd components to a pcb. There would be a camera, that would drive the emc so that it would grab a smd component.
[13:29:15] <jepler> You don't need to use emc's g-code interpreter to create the position commands. You can write your own HAL component which will give position commands instead.
[13:29:30] <jepler> but it is hard to do both -- use emc's g-code interpreter sometimes, and use some other HAL component at other times.
[13:29:49] <cradek> if MDI is good enough, you can send MDI commands with the mdi program
[13:29:57] <jepler> oh yes, that's true
[13:30:14] <cradek> bbl
[13:36:39] <kwajstabo> what is MDI?
[13:37:10] <jepler> it is a mode where g-code is sent to the interpreter one line at a time, instead of being read from a file
[13:37:25] <jepler> I think it stands for something like "manual data interface"
[13:37:27] <skunkworks> manual data input.
[13:37:32] <skunkworks> or something like that
[13:37:34] <skunkworks> :)
[13:38:01] <skunkworks> morning
[13:38:26] <jepler> hi skunkworks
[13:38:39] <skunkworks> How is the fpga working?
[13:38:51] <skunkworks> (excited about that also)
[13:39:07] <jepler> pretty good! I *think* that everything works -- everything but index pulse has been minimally tested.
[13:39:31] <jepler> the features of the firmware are described here:
http://emergent.unpy.net/01164408418
[13:39:48] <skunkworks> holy sh*t. Nice work. That was fast.
[13:39:58] <jepler> well thank you
[13:40:34] <jepler> I'm a bit surprised myself, being so new at FPGAs.
[13:42:28] <jepler> oh -- and I think that "45 microseconds" figure (time to read and write registers) is wrong -- I divided the cycle counts by the wrong CPU speed. It's more like 100uS
[13:42:58] <skunkworks> wow - those specs are pretty cool. the thing is so cheap I think I may be one of your beta testers. The 100% df issue is not an issue with me ;)
[13:43:00] <jepler> skunkworks: is "up/down" the pwmgen style you use with your servo board?
[13:43:04] <skunkworks> yes
[13:45:08] <skunkworks> I can see where I will probably need higher resolusion encoders.
[13:45:18] <jepler> btw I bought one of the "flashy" modules as well -- I hope to write a linux app that works with the captured data in the next few days.
[13:45:22] <jepler> why will you need higher resolution encoders?
[13:47:11] <jepler> the only negative thing I have to say is that the fpga4fun guy seems to reveal as little information as possible -- though he did give me the extra information I asked for about the communication between pluto-p and the PC when using his flashy firmware, so maybe I shouldn't complain.
[13:49:00] <skunkworks> This is just my thought - As I push the servo away from is commanded possition - The harder I push - the harder it pushes back. The thing is - it takes a few encoder edges to do this - the one servo I can push a few thousands.
[13:49:27] <skunkworks> Thats good.
[13:49:44] <skunkworks> because my resolution is around .0002
[13:49:47] <jepler> and it's not your "deadband" setting?
[13:50:06] <jepler> bbl, time to drink coffee with my co-worker
[13:50:12] <Lerneaen_Hydra> jepler: is the fpga some type of contoller module on the cheap?
[13:50:14] <skunkworks> :)
[13:51:00] <jepler> Lerneaen_Hydra: the pluto-p costs something like 60USD
[13:51:27] <Lerneaen_Hydra> why use that instead of one of the pre-existing solutions?
[13:51:39] <skunkworks> cheap.
[13:51:49] <Lerneaen_Hydra> how expensive are the other ones :/
[13:51:52] <skunkworks> the next card is over 200 dollars (mesa)
[13:52:25] <Lerneaen_Hydra> oh
[13:52:29] <Lerneaen_Hydra> that bad eh
[13:52:37] <skunkworks> :) yes I am a cheap bastard
[13:52:52] <Lerneaen_Hydra> hmm, 20khz, why not use a parport?
[13:53:50] <skunkworks> I have been. and it works pretty well so far. but you have to lower the encoder resolution to a point that the computer will be able to read it at the speeds I need.
[13:54:21] <skunkworks> plus it requires a pretty decent computer. The fpga would not.
[13:54:53] <Lerneaen_Hydra> 20khz isn't fast, that's 50µS base period
[13:56:04] <skunkworks> for reading encoders you want twice that for headroom.
[13:56:17] <Lerneaen_Hydra> 25µS still isn't a lot
[13:56:58] <skunkworks> no it isn't. Like I say.. It works but if I could get a fpga that works with the 28 i/o I would go for it.
[13:57:42] <Lerneaen_Hydra> what I'm trying to say is, why get the fpga for $60 when a free computer can do the same speeds for free?
[13:58:15] <Lerneaen_Hydra> err, one free too much
[13:58:31] <skunkworks> because at some point I would like to use encoders with a 1000 line or more. this will not work thru the parallel port.
[13:59:10] <skunkworks> (for the speeds I need)
[13:59:18] <Lerneaen_Hydra> oh, how fast can you run the fpga?
[13:59:38] <skunkworks> 4 quadrature channels, sample rate 40MHz to a 12-bit counter
[13:59:57] <skunkworks> http://emergent.unpy.net/01164408418
[14:00:01] <Lerneaen_Hydra> 40mhz!
[14:00:09] <Lerneaen_Hydra> oh, that's a bit better
[14:00:13] <skunkworks> :)
[14:00:29] <Lerneaen_Hydra> I was under the impression that 20khz was the max or something
[14:00:44] <Lerneaen_Hydra> though seeing as how it's an fpga that's not very likely
[14:01:19] <skunkworks> ? don't know - jepler would have to answer that. :)
[14:01:27] <Lerneaen_Hydra> so essentially its for reading fast encoders
[14:01:34] <skunkworks> yes
[14:01:37] <Lerneaen_Hydra> what about driving steppers?
[14:01:47] <skunkworks> I think that is in the plan.
[14:01:52] <Lerneaen_Hydra> you'd be limited by the parport speed, right?
[14:02:16] <skunkworks> no - you would have the fpga do the pulse train and figuring out where to go
[14:02:19] <Lerneaen_Hydra> unless you send something like "untill the next base_period output x cycles" over the parport
[14:02:23] <Lerneaen_Hydra> yeah, cool
[14:04:36] <skunkworks> Yes it is. :)
[14:04:58] <skunkworks> aren't these guys great?
[14:10:48] <Lerneaen_Hydra> yeah :)
[14:10:55] <Lerneaen_Hydra> awesome
[14:39:38] <cradek> jepler: what is "glitch free"?
[14:41:13] <skunkworks> I think I am going to have to order one of these things :)
[14:42:04] <Lerneaen_Hydra> $60, not that bad
[14:42:06] <skunkworks> cradek: did you have a good thanks giving?
[14:42:19] <skunkworks> givings
[14:42:24] <Lerneaen_Hydra> what can you use instead of optocouplers at that speed?
[14:42:29] <jepler> cradek: suppose the old PWM value is 100, the current PWM counter is 200. The PWM output will be off. Now I set the PWM value to 300. The output turns on immediately.
[14:42:31] <cradek> the long weekend was better than the holiday itself, but in general, yes
[14:42:59] <skunkworks> I took all of last week off. ;)
[14:43:06] <jepler> cradek: if it was glitch-free, the output would remain off until the counter reset, and then turn on for a full 300 cycles
[14:43:24] <cradek> jepler: I get it
[14:43:36] <cradek> jepler: is that important?
[14:43:53] <skunkworks> honestly - my servo drive is opto - isolated and encoders are by default isolated. I would not be affraid to just hook it up.
[14:43:54] <jepler> cradek: not sure; The AVR datasheet makes a point of being "glitch free"
[14:45:02] <jepler> see page 35 of
http://www.atmel.com/dyn/resources/prod_documents/doc0839.pdf
[14:45:15] <anonimasu> kwajstabo: wouldnt you want to separate the machine and the workpiece changer to get things easier to overlook?
[14:45:17] <jepler> I suspect it doesn't matter much when driving servo motors
[14:47:49] <cradek> is the duration of the glitch always between the old and new values?
[14:47:56] <cradek> seems like it is
[14:48:08] <skunkworks> jepler: going to hook it up to your etch-o-sketch?
[14:48:28] <skunkworks> or cradeks' lathe? :)
[14:48:46] <cradek> I think my lathe will be his test subject
[14:49:13] <skunkworks> good test of the index pulse
[14:49:20] <cradek> I don't think the etch-a-sketch can be tuned very well - it's not a very good test platform
[14:51:13] <skunkworks> cradek: what happenes with coordinated motion on your lathe when the spindle isn't turned on. Does the axis move each direction when the spindle is spun cw and ccw?
[14:51:47] <cradek> no, emc can't currently back up, it depends on the spindle not moving backward
[14:52:07] <cradek> when we want to do rigid tapping that will need some thought
[14:52:26] <skunkworks> :)
[14:52:54] <cradek> as soon as someone brings me a bridgeport with vfd spindle I'll work on rigid tapping
[14:53:06] <anonimasu> cradek: you need a servo dont you?
[14:53:18] <anonimasu> cradek: will rigid tapping work with just a normal motor and a vfd?
[14:53:21] <cradek> ideally, but not necessarily
[14:53:40] <anonimasu> hm, ok..
[14:53:49] <cradek> in theory it just has to be able to stop and reverse when you want
[14:54:00] <cradek> I wouldn't try to use a bottoming tap of course
[14:54:10] <anonimasu> hm, it should work with my spindle then.. if you do get it working :)
[14:54:21] <skunkworks> the spindle would have to accellerate slower than what the axis could move.
[14:54:22] <cradek> yeah it's not written at all yet
[14:54:34] <anonimasu> huydralic spindle :)
[14:55:07] <cradek> yeah the axis has to keep up in accel and vel both - and that depends on your spindle rpm and tap pitch
[14:55:42] <anonimasu> hm, should make for nice rigid tapping laters..
[14:55:57] <anonimasu> i can stop in about 0.2 secs.
[14:56:56] <skunkworks> tapping is normally done at lower rpms <100rpm - at least in my experience.
[14:56:59] <cradek> it would be great to have a machine set up for tapping at fest
[14:57:12] <Lerneaen_Hydra> when/where is fest?
[14:57:18] <jepler> at the threading speeds used (only about 400 RPM?), I think the nist-lathe could accelerate with the spindle
[14:57:26] <jepler> Lerneaen_Hydra: galesburg, IL, USA sometime in the late spring
[14:57:30] <Lerneaen_Hydra> 400rpm! O.O
[14:57:38] <Lerneaen_Hydra> cool :)
[14:57:45] <jepler> ouch this page is a bit ugly
http://www.cnc-workshop.com/
[14:58:04] <Lerneaen_Hydra> ack
[14:58:08] <cradek> June 11-17, 2007
[14:58:13] <cradek> MY EYES!
[14:58:14] <anonimasu> hm, some of theese years im going to fest/workshop..
[14:59:10] <jepler> I am very glad I went last year -- it was great to meet people like jmk, swp, skunkworks, fenn, ray, matt s., and everyone else I forgot
[14:59:28] <jepler> jon elson, steve stallings
[14:59:49] <cradek> it was fun, and we got a lot done too
[15:00:01] <Lerneaen_Hydra> euro-fest would be cool, though a bit less populated
[15:00:08] <anonimasu> it's kind of a bit far to go from sweden..
[15:00:19] <Lerneaen_Hydra> yeah
[15:00:27] <jepler> cnc-workshop isn't just emc people -- but "fest" is what the emc part seems to be called
[15:00:27] <skunkworks> It was funny - when I first got there - I walked around the office area - where the classes where held. I thought that I was missing something. (where where the emc gurus?) I finally found them stuck in the corner of another building.
[15:00:31] <Lerneaen_Hydra> that's why everyone else should come here instead :D
[15:00:47] <Lerneaen_Hydra> haha
[15:04:19] <jepler> I probably wouldn't make it but I think an european emc fest / cnc workshop would be a fine idea
[15:04:28] <jepler> we've got a fair number of european users
[15:04:49] <skunkworks> I keep badgering alex to come :)
[15:05:03] <SWPadnos_> I think Alex said that he may make it this year
[15:05:22] <SWPadnos_> he just couldn't swing everything (work, girlfriend, visa) last year
[15:09:49] <Lerneaen_Hydra> not many euro-devs though :(
[15:10:08] <Lerneaen_Hydra> poor alex has to support all europe :p
[15:10:28] <SWPadnos_> heh
[15:10:42] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[15:14:17] <jepler> hi SWPadnos
[15:14:28] <SWPadnos> hi jepler
[15:17:28] <SWPadnos> I noticed (but didn't fully read) a discussion about the AVR PWM and its glitch-free features
[15:17:42] <jepler> Lerneaen_Hydra: I don't remember if I answered this -- the PWM clock is also 40MHz, so it counts from 0 to 2048 about every 50 microseconds / 20kHz. So over each 50 microsecond time period, the PWM can have one of 2048 different duty cycles.
[15:18:39] <Lerneaen_Hydra> oh, so 20khz inside each base period
[15:18:47] <SWPadnos> I don't think you need to go all the way with that - they use ip/down counters for several modes, but I think you can get by with just a holding register that gets clocked into the compare register at the end of every PWM cycle
[15:19:05] <jepler> SWPadnos: do you think "glitch free" is important for running a servo motor, though?
[15:19:24] <jepler> I don't have a lot of gates left, 3 more 12-bit registers would be a big expense
[15:19:31] <SWPadnos> I'm not sure. I think it's more of an RF noise thing, actually
[15:21:13] <SWPadnos> actually, I suspect it's fine for smaller motors, but high power motors may have issues - consider the Mazak while dragging windows around - a couple of ms seemed to make a difference there
[15:21:44] <jepler> this is much less time than a ms, though
[15:22:04] <SWPadnos> yep - so it shouldn't be a big deal
[15:22:19] <SWPadnos> (until you find a motor/machine where it is ;) )
[15:22:26] <Lerneaen_Hydra> jepler: how many gates does the pluto have?
[15:22:34] <Lerneaen_Hydra> was it 500-ish?
[15:23:47] <jepler> Lerneaen_Hydra: 576 "logic elements"; they call it "10,000 typical gates"
[15:24:08] <jepler> there's one flip-flop per LE
[15:24:14] <Lerneaen_Hydra> oh, nice
[15:24:23] <Lerneaen_Hydra> so you get many and/or/xor/invert into a LE?
[15:24:35] <jepler> did you look at the datasheet at all?
http://www.altera.com/literature/ds/acex.pdf
[15:24:46] <SWPadnos> what's the package for that chip - if they sell a kit/bare board, it may be possible to get a higher gate count part in the same form factor
[15:24:47] <Lerneaen_Hydra> err, I missed that
[15:25:21] <jepler> look at page 21 for a picture of what one LE is
[15:25:45] <jepler> SWPadnos: no, only the ep1k10 is available in the 100-lead package
[15:25:51] <SWPadnos> ah
[15:26:15] <jepler> with the 144-lead package you have more choices -- 3x and 5x as many LEs
[15:26:42] <SWPadnos> yep. very few FPGA choices in hand-solderable packages
[15:26:51] <SWPadnos> relative to the number of BGA choices, at least
[15:29:26] <Lerneaen_Hydra> BGA is t3h shit :p
[15:29:45] <SWPadnos> yeah - if only I had an X-ray inspection machine at home
[15:29:51] <SWPadnos> * SWPadnos checks eBay
[15:30:28] <jepler> * jepler isn't sure if SWPadnos is serious about buying an x-ray inspection machine or not
[15:30:31] <anonimasu> hm, Im not going this year, but the next one..
[15:30:33] <jepler> it wouldn't surprise me if he were
[15:30:36] <SWPadnos> heh
[15:31:54] <anonimasu> SWPadnos: do you need one for bgs?
[15:31:56] <anonimasu> bga?
[15:31:59] <SWPadnos> holy crap - you can get an airport X-ray machine for $599 *or less)
[15:32:14] <SWPadnos> yeah - you can't see the pads under the chip, which is all of them
[15:32:26] <anonimasu> why do you need to see them?
[15:32:29] <jepler> now I know -- swp *is* buying an x-ray machine
[15:32:41] <SWPadnos> err - to test whether the chip was correctly soldered ...
[15:32:56] <anonimasu> SWPadnos: why not have somone make a board with a socket for you?
[15:32:57] <SWPadnos> no - they're $10k (but there is one on eBay, which is funny)
[15:33:09] <SWPadnos> you can't reliably socket a BGA
[15:33:24] <anonimasu> yes you can..
[15:33:32] <anonimasu> * anonimasu has seen thoose test sockets ;)
[15:33:49] <anonimasu> but they might set you off more then a xray machine
[15:34:02] <SWPadnos> it would be less expensive to buy an X-ray machine, if a production run has more than 10 units ;)
[15:34:17] <Lerneaen_Hydra> SWPadnos: tell that to intel -.-
[15:34:23] <Lerneaen_Hydra> wonderful socket
[15:34:38] <Lerneaen_Hydra> not at all problem ridden
[15:34:45] <SWPadnos> FCPGA isn't quite BGA, though I'd have to look up the differences ;)
[15:35:19] <SWPadnos> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=130028556337
[15:35:23] <Lerneaen_Hydra> http://en.wikipedia.org/wiki/Socket_t <- almost bga
[15:35:24] <SWPadnos> cheap, at any price
[15:35:30] <anonimasu> flip chip ball array
[15:35:34] <Lerneaen_Hydra> at least the CPU looks like a bga
[15:36:15] <anonimasu> http://www.necel.com/pkg/en/pk02_03.html
[15:36:16] <anonimasu> yeah
[15:36:21] <anonimasu> it's the bonding that's different
[15:36:23] <SWPadnos> actually, Flip Chip Pin Grid Array, I think
[15:37:02] <SWPadnos> I wonder where to get those sockets at a reasonable price (they're also not available for "standard" BGA, AFAIK)
[15:37:23] <SWPadnos> I know you can get test sockets - for $1k a piece or so
[15:37:54] <anonimasu> hm,
http://www.locknest.com/newsite/products/bga/index.htm
[15:38:24] <SWPadnos> oh good - they have 0.5mm pitch sockets O_O
[15:38:33] <anonimasu> first hit on google I think
[15:38:34] <anonimasu> :)
[15:38:55] <SWPadnos> but they only go up to 400 pins :(
[15:39:12] <anonimasu> nope..
[15:39:25] <anonimasu> 727..
[15:39:25] <SWPadnos> the 0.5mm pitch line tops out at 20x20
[15:39:30] <anonimasu> ah 0.5
[15:39:30] <SWPadnos> I haven't looked at the others
[15:40:03] <anonimasu> that's 1.5, but that seems large
[15:40:38] <SWPadnos> ah - ok, 1.27mm pitch goes up to 1064 pins
[15:40:57] <SWPadnos> which strangely enough still isn't enough for the larger FPGAs
[15:41:34] <anonimasu> http://www.advintcorp.com/
[15:41:36] <SWPadnos> I wonder how much those cost ...
[15:42:46] <SWPadnos> cool stuff. I sit corrected - you can socket a BGA (but I still son't want to :) )
[15:42:53] <SWPadnos> don't
[15:43:10] <anonimasu> well, if cpu makers do it..
[15:43:18] <anonimasu> SWPadnos: besides if you are prototyping :)
[15:43:38] <SWPadnos> oh sure - for prototypes that can work (though the sockets are huge compared to the chips)
[15:44:09] <SWPadnos> actually, there are SMT proto assembly houses that also do X-ray inspection - you can probably get 5 boards built and inspected for the cost of one socket
[15:44:56] <anonimasu> well, doing it yourself isnt too nice even if you do have xray..
[15:45:38] <SWPadnos> I agree. I prefer to not solder anything beyond 0603, though I've done 0402 by hand (multi-element resostors at 020 pitch)
[15:45:47] <SWPadnos> resistors
[15:46:30] <anonimasu> :)
[15:49:05] <CIA-8> 03jepler 07HEAD * 10emc2/lib/python/nf.py: fix for problem reported by flo-h: can't find axis share directory when installed to /usr/local but python installed to /usr
[15:49:36] <anonimasu> SWPadnos: yeah, and the headache
[15:50:47] <jepler> I can't find eagle library files for any of those TQFP FPGAs :(
[15:51:21] <SWPadnos> you probably can't route anything larget than 100-144 pins in the free version of eagle anyway
[15:51:25] <SWPadnos> you need more layers for the fanout
[15:51:56] <jepler> I was going to try doing one of those 144-pin ones in 2 layers .. I agree, it's likely to suck
[15:52:16] <SWPadnos> what's the max board size in the free Eagle?
[15:52:24] <jepler> 80x100mm, 2 layers
[15:52:30] <SWPadnos> hmmm
[15:54:20] <jepler> VCCint, VCCio, gnd, and signals -- it'll suck in 2 layers
[15:57:40] <SWPadnos> and you probably want a DB25 connector on there as well
[16:00:09] <jepler> yeah, I want pluto-p with more gates and more I/Os brought to the .1" headers
[16:01:19] <SWPadnos> heh - headers - the other space hog ;)
[16:01:58] <SWPadnos> you have 4 axes of encoder and PWM/step+dir right now (or similar), right?
[16:03:04] <jepler> right, plus 6 other inputs and 4 other outputs
[16:03:20] <SWPadnos> which you'd like to increase?
[16:03:30] <jepler> yes
[16:04:03] <SWPadnos> do you want to provide ground/common connections for each I/O? (easier for wiring, not for board routing)
[16:04:31] <jepler> worse for board area too
[16:04:33] <jepler> I'm not sure
[16:04:46] <jepler> bbl
[16:04:48] <jepler> work calls
[16:04:52] <SWPadnos> enjoy
[16:27:27] <jepler> hm -- the encoder counter size had better be bigger than the encoder counts per rev when using index pulse
[16:27:41] <SWPadnos> heh
[16:27:42] <jepler> otherwise the index pulse will always fall on the same encoder count modulo the counter size
[16:28:51] <jepler> This is a list of Commercial Exhibitors for the Second Annual CNC-Workshop
[16:28:51] <jepler> ...
[16:28:55] <jepler> Advanced Lap Sitting - Boris, the Shop Cat
[16:29:08] <jepler> * jepler chuckles
[16:29:19] <jepler> I forgot about boris -- I should have listed him among the "people" I met at fest
[16:29:28] <SWPadnos> yep - Boris was always on the water heater when I'd go to get water to make coffee :)
[16:30:03] <skunkworks> I think the only limit on the free version of eagle is board size
[16:30:17] <SWPadnos> you can do 12-layer boards?
[16:30:26] <skunkworks> oh - and 2 layers ;)
[16:30:36] <SWPadnos> ok, I think we've been there ;)
[16:30:41] <cradek> http://neme-s.org/CNC_Workshop/P6240116.JPG
[16:31:09] <cradek> boris watching one of the presentations
[16:31:50] <SWPadnos> he looks more interested than the humans
[16:33:03] <skunkworks> thank god he like attention. one of our cats would freak out and die with all those people.
[16:33:44] <cradek> too bad there are no photos from last year linked from the workshop web page
[16:33:55] <jepler> if he didn't like the attention I'm sure he could find somewhere to hide
[16:38:10] <skunkworks> I should see if dad took some.
[16:38:33] <skunkworks> jepler: you never found your memory stick did you?
[16:39:56] <jepler> here are some of fenn's photoshttp://fenn.freeshell.org/retrofest/
[16:40:00] <jepler> skunkworks: no, I never did
[16:41:30] <jepler> oh -- I guess most of those are from the '05 fest
[16:42:51] <SWPadnos> hmmm - fenn wasn't at fest '05 (at NIST)
[16:43:38] <cradek> 05 was in IA, 04 was NIST
[16:43:45] <cradek> ... I think
[16:43:48] <SWPadnos> ah - that was the CNC workshop in 05, which wasn't coincident with Fest - it was just the beginning of the Mazak retrofit
[16:44:22] <SWPadnos> that's part of why we did it at CNC workshop this year - because people couldn't travel for 2 weeks
[16:44:36] <SWPadnos> in the summer
[16:44:39] <SWPadnos> plus family vacations ;)
[16:46:12] <jepler> Lerneaen_Hydra: after you're done with the electric cycle, make one of these:
http://blog.modernmechanix.com/2006/11/27/belt-drive-replaces-wheels-on-novel-motorcycle/
[16:46:36] <Lerneaen_Hydra> :p
[16:46:41] <Lerneaen_Hydra> steering looks like a pita
[16:46:48] <Lerneaen_Hydra> effeciency probably sucks too :p
[16:47:15] <SWPadnos> there's a newer version of that that actually can steer
[16:47:44] <SWPadnos> they use a link belt of some sort, that can flex from side to side
[16:51:23] <Lerneaen_Hydra> neat
[17:04:11] <skunkworks> jepler: you have to solder your header on the pluto board correct?
[17:06:50] <jepler> skunkworks: the board comes as shown in this image: .w.g.t.highlighting.f.lf.c2.fr7.b invoke
[17:06:54] <jepler> er
[17:06:56] <jepler> http://www.fpga4fun.com/images/Board_Pluto-P.jpg
[17:06:58] <jepler> that image
[17:07:15] <SWPadnos> what the hell was that other thing? :)
[17:07:18] <skunkworks> ok. How are you planning to connect the outside world to it?
[17:07:24] <jepler> a male header for the longer connector is included but not soldered on
[17:07:28] <jepler> SWPadnos: a trade secret, probably
[17:07:31] <SWPadnos> heh
[17:07:41] <cradek> you can't write trade secrets in tcl - it's impossible
[17:07:44] <SWPadnos> looks like postscript
[17:08:34] <jepler> the shrouded header is for JTAG apparently
[17:09:33] <Dallur> +
[17:09:41] <SWPadnos> -
[17:09:51] <Dallur> sorry, unplugging laptop :P
[17:09:54] <Lerneaen_Hydra> at least it's not brainfuck or whitespace or something
[17:10:02] <Lerneaen_Hydra> (jepler's secret)
[17:10:03] <SWPadnos> feckfeck
[17:10:07] <Lerneaen_Hydra> sure looks nasty though
[17:11:45] <jepler> it's very easy to understand -- .w.g.t.highlighting.f.lf.c2.fr7.b is the name of a widget, and "invoke" is the action to be taken
[17:11:53] <jepler> but if I tell you what .w.g.t.highlighting.f.lf.c2.fr7.b is, I have to kill you
[17:12:03] <Lerneaen_Hydra> the f.lf.c2.fr7.b looks nasty though
[17:12:10] <cradek> jepler: a widget?
[17:12:17] <SWPadnos> no -a doohickey
[17:12:19] <Lerneaen_Hydra> colors and parameters maybe
[17:12:28] <Lerneaen_Hydra> looks obfusticated
[17:12:30] <SWPadnos> I think I'd like to invent a language where the GUI elements are called doohickeys
[17:12:33] <Lerneaen_Hydra> (sp?)
[17:12:39] <SWPadnos> obfuscated
[17:13:29] <Lerneaen_Hydra> ah, right
[17:13:38] <skunkworks> jepler: is there an online manual for the pluto board? I don't see one. Sounds like you only get it when you buy it?
[17:14:14] <jepler> skunkworks: jas
[17:15:40] <jepler> skunkworks: yes, he sends you a URL when you complete the purchase
[17:15:46] <skunkworks> ok
[17:16:12] <jepler> you get the stuff mentioned in the section "What files are provided with Pluto-P?"
[17:16:55] <Lerneaen_Hydra> how's linux flashing capability?
[17:17:27] <jepler> Lerneaen_Hydra: fast and easy -- but the devel software is windows-only (I'm running it in vmware)
[17:17:34] <Lerneaen_Hydra> ack
[17:18:48] <SWPadnos> it's too bad that Altera has no free Linux tools
[17:18:58] <SWPadnos> you can get a Linux version if you pay for it
[17:20:00] <jepler> is the linux version cheaper than a w2k or wxp license?
[17:20:12] <jepler> (I haven't even looked at the prices)
[17:20:18] <SWPadnos> I don't think so
[17:20:37] <cradek> * cradek makes a face
[17:20:41] <SWPadnos> it may be mor, in fact - it's ratgeted at designers who use other unices - like Soalris
[17:20:45] <SWPadnos> gah
[17:20:50] <SWPadnos> more / targeted
[17:20:57] <jepler> soalris?
[17:20:58] <jepler> :-P
[17:21:13] <SWPadnos> well, that doesn't deserve a correction ;)
[17:21:19] <cradek> SWPadnos: you need a new keyboard or less coffee habit
[17:21:27] <SWPadnos> more coffee habit
[17:23:57] <SWPadnos> ouch! their IP core for hypertransport is very expensive
[17:24:20] <SWPadnos> $23495 at DigiKey, plus $5995/year (I think) for renewal
[17:25:54] <skunkworks> jeeze - you have to be making the real money to make that back.
[17:27:02] <SWPadnos> yep
[17:27:10] <SWPadnos> very real money
[17:33:01] <jepler> haha
[17:33:01] <jepler> What can you do with your Dragon?
[17:33:01] <jepler> Any well-trained Dragon can throw flames and smoke. That's easy; just plug the USB to the main power (110 to 240V, depending on where you are). While that will void the warranty, you should get some smoke... and maybe some flames.
[17:33:10] <jepler> </description of one of the fpga4fun boards>
[17:42:24] <Lerneaen_Hydra_> logger_emc: bookmark
[17:42:24] <Lerneaen_Hydra_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2006-11-27.txt
[17:42:42] <Lerneaen_Hydra_> haha
[17:51:35] <Lerneaen_Hydra_> Lerneaen_Hydra_ is now known as Lerneaen_Hydra
