Back
[00:00:15] <andypugh> A compare and the f-error pin.
[00:01:56] <cradek> you can just use encoders for feedback, and if it loses position, you'll get a following error
[00:02:09] <cradek> that's how emc naturally works - you don't have to play any tricks
[00:02:22] <cradek> usually stepgen provides feedback - you can provide your own
[00:03:20] <lepton> I'm currently using the stepgen feedback, and I could very easily use the encoder instead
[00:03:35] <cradek> yes that's all you need to do
[00:03:41] <lepton> But I'm not sure I want it to trip a following error, since that would stop the machine
[00:03:47] <lepton> In some cases I don't actually want it to stop
[00:03:53] <cradek> but that's the whole point
[00:04:01] <cradek> not stopping ruins your work
[00:04:10] <lepton> Well, I guess what I mean is, I don't want it to go into an estop state
[00:04:18] <lepton> because that trips my contactors and cuts power to the stepper drivers
[00:04:20] <cradek> well it doesn't, it goes to machine off
[00:04:22] <theorb> theorb is now known as theorbtwo
[00:04:30] <lepton> Yeah, I guess I mean machine off
[00:04:39] <Jymmm> could just have a PAUSE button
[00:04:43] <cradek> so? turn it back on, rehome, and resume your work
[00:05:04] <lepton> In some cases that could be dangerous, for example when using a keyseat cutter
[00:05:08] <cradek> actually you don't have to rehome - the encoders maintain the position for you
[00:05:24] <lepton> But not if the encoders' electronics get their power killed
[00:05:40] <lepton> a pause, or stopping stepper gen, seems more universally acceptable to me
[00:05:50] <cradek> no sane setup kills the encoders when there's a ferror
[00:06:06] <lepton> Well, our stepper drivers are also our encoders
[00:06:19] <cradek> your encoder card powers the encoders
[00:06:22] <cradek> huh?
[00:06:23] <Jymmm> * Jymmm mumbles something about EMERGENCY Stop != Oh Shit button.
[00:06:52] <lepton> Our stepper drivers have opto outputs, which we have going into a mesa board with stepper encoders
[00:07:13] <cradek> sorry I'm still lost
[00:07:13] <lepton> If we cut power to our contactor, thus cutting power to the stepper drivers, the encoder loses power
[00:07:16] <lepton> :p
[00:07:26] <lepton> I'm actually not sure if an f-error cuts the contactor
[00:07:29] <lepton> I'm gonna go find out
[00:07:47] <cradek> what do encoders have to do with stepper drives?
[00:07:48] <lepton> (I'm finishing up on EMC conversion, so some details like this are still getting sorted out)
[00:08:14] <lepton> This is a stepper machine with encoder outputs on the stepper drivers
[00:08:19] <lepton> But right now it's all open loop
[00:08:24] <lepton> And will continue to be
[00:08:34] <cradek> what do you mean by the stepper drivers have encoder outputs?
[00:08:55] <cradek> can I see docs online? I've never seen this
[00:08:58] <lepton> Just that! Stepper drivers that have position encoders
[00:09:11] <cradek> you mean the MOTORS have encoders?
[00:09:23] <cradek> driver = electric amplifier thingy that runs motor
[00:09:38] <lepton> Yes, I know
[00:09:43] <lepton> hold on, I'll get you a datasheet
[00:09:51] <cradek> thanks :-)
[00:10:30] <lepton> Here's a pdf link to the system manual:
http://www.orientalmotor.com/products/pdfs/opmanuals/HM-6205-6E.pdf
[00:10:55] <lepton> The stepper drivers also do closed loop control to make prevent missed steps
[00:11:11] <lepton> I'm guessing they're closing the loop on position error and coil current
[00:11:16] <Jymmm> lepton: I think you meant that the drives have encoder INPUTS, not outputs.
[00:12:04] <cradek> um RS232? what the heck is this
[00:13:01] <lepton> It's a big fancy stepper driver
[00:13:29] <lepton> The RS232 allows it to be reprogrammed such that it's IO doesn't match the factory specs any more, which led to some surprises yesterday
[00:13:54] <lepton> Jymmm: I meant outputs ;)
[00:14:00] <lepton> Check out that link, if you're curious
[00:14:26] <Jymmm> lepton: No, INPUT from the encoder to the driver
[00:14:28] <cradek> these aren't the droids, er, stepper drivers you're looking for
[00:14:39] <cradek> Jymmm: it's some weirdo thing - rtfm
[00:14:56] <Jymmm> cradek: Yeah, no thanks if that's the case.
[00:15:05] <lepton> It's certainly a funky system
[00:15:06] <cradek> they have their own control built in, commanded over rs232, and they do have encoder type outputs or something
[00:15:13] <lepton> When I make a new machine it'll all be servos
[00:15:26] <cradek> I bet these are quite useless for any coordinated motion
[00:15:41] <cradek> unless you can seriously dumb them down
[00:15:46] <Jymmm> cradek: Ah, so minimal cabling, and chained serial control.
[00:15:52] <lepton> They do a good job when treated like normal open loop stepper drivers
[00:16:09] <Jymmm> Sonds much like the OEM750X's
[00:16:10] <cradek> how do you command them to step?
[00:16:17] <lepton> step and dir signals
[00:16:29] <lepton> Fairly normal in that regard
[00:16:42] <lepton> I've only used the RS232 to program them
[00:16:47] <cradek> oh ok, I wasn't seeing that in here anywhere
[00:17:00] <lepton> and I only did that today for the first time
[00:17:23] <lepton> We've been running this machine since December quite a lot, started the EMC2 conversion about a month ago
[00:17:29] <lepton> I thought I'd be done within a week
[00:17:34] <lepton> ...how foolish I was
[00:17:43] <lepton> Fortunately I could do it all over again in a week
[00:18:13] <lepton> Actually, I shouldn't say that, since I haven't cut anything yet, and I still don't have modbus up for spindle control
[00:31:06] <lepton> Hmm... any ideas why I'm getting following errors at high speeds?
[00:31:27] <lepton> Somewhere between 200 and 300 ipm I get following errors, shortly after it starts moving when I jog it in axis
[00:31:32] <lepton> this applies to all three axes
[00:32:10] <lepton> Or better yet, suggestions for how I can track down the issue
[00:34:17] <KimK> How old is your machine? What has it been used to cut in the past?
[00:35:09] <lepton> Built in Novemeber of 2009, probably has produced about 200 lbs of aluminum shavings since then
[00:35:21] <lepton> Along with a fair amount of wood and plastics
[00:35:24] <lepton> mostly aluminum, though
[00:42:18] <KimK> So, I'm guessing you can program two of those general-purpose inputs to be step & direction?
[00:42:49] <lepton> There are already pins permanently designated for it
[00:43:09] <lepton> In either step CW / step CCW, or step / dir configuration
[00:43:18] <KimK> Oh, OK, I must not have gotten to that part yet.
[00:43:23] <lepton> It's part of the 36 pin mini centronix cable plug
[00:43:29] <lepton> Stupid expensive cable...
[00:46:02] <KimK> Are you microstepping? How many?
[00:47:59] <lepton> 1625 microsteps per motor rev, pre gear box
[00:49:49] <KimK> And how many motor steps/rev (pre gear box)? Have you got all the internal values (limits) set wide open? (Acc/Dec, max vel, etc.) I think you'd do better to let EMC2 manage those.
[00:53:19] <lepton> As far as I know the stepper drivers do have some internal limits on acceleration and velocity, but they're above those set in EMC
[00:54:43] <KimK> I was thinking it might be better if they were a lot above rather than a little above. Current and similar items can stay as usual.
[00:56:54] <lepton> Agreed
[01:01:21] <KimK> Well, I made one pass thru the manual, halfway looking for that part about programming step & direction inputs, but must have missed it.
[01:02:34] <KimK> What size motors are these? Is it reasonable to expect 200-300 IPM from them?
[01:03:10] <KimK> And what's the screw pitch?
[01:04:10] <lepton> Yeah, we've moved at those speeds without trouble before
[01:04:17] <lepton> On our old control system
[01:04:23] <lepton> It's also rack and pinion
[01:04:40] <lepton> 2482.8171122335 steps per inch
[01:04:47] <lepton> which everything is said and done
[01:04:56] <KimK> What was the old control system?
[01:05:04] <lepton> I'm noticing that the following error comes on doing decceleration
[01:05:08] <lepton> Shopbot control software
[01:05:13] <lepton> SOOOOOOOOOO bad
[01:05:15] <lepton> I've ranted on here about it before
[01:05:19] <lepton> I'll refrain today
[01:05:26] <KimK> Not familiar with it, sorry.
[01:05:48] <lepton> You're better off for it ;)
[01:05:58] <KimK> (Or maybe I'm not sorry, if it's as bad as you say it is!)
[01:07:02] <KimK> Can you pastebin the internal program these drives are loaded with?
[01:07:55] <lepton> Unfortunately not easily, because it's just a terminal that you interact with over rs232
[01:08:04] <lepton> So I don't have a file that I can upload
[01:08:23] <lepton> I've hardly even done anything meaningful programming for it
[01:09:19] <KimK> OK. But you're running the same program on the drives as when the old control system was in charge?
[01:09:54] <lepton> Correct
[01:12:24] <KimK> Do you recall if the program was dirt simple, like "START", "connect pin 1 to STEP", "connect pin 2 to DIR", "END"? Or was it doing something to "help"?
[01:13:49] <lepton> I don't think it's possible to reprogram which pins are step / dir
[01:13:59] <lepton> I'm pretty sure those are fixed, and going through opto inputs
[01:14:57] <KimK> OK. So was the program more like "set standard step & dir mode", "end"?
[01:16:23] <KimK> Sorry to keep bugging you about this, but I'm wondering why the old control guys specified such a smart (more expensive) drive, and why they needed to.
[01:18:58] <spasticteapot> Has anyone here ever CNCd a mould for casting polyester?
[01:19:22] <lepton> I don't think very highly of the company that did the previous control system, and selected this hardware. I believe their motivation for going with these steppers / drivers was to use it's internal closed loop control for preventing missed steps
[01:19:48] <lepton> They advertise it very heavily, and it didn't require changes to their own windows based software
[01:19:49] <spasticteapot> Why not just use a stepper/encoder?
[01:20:02] <spasticteapot> Encoders aren't so expensive.
[01:20:08] <spasticteapot> That said, I don't know jack about EMC.
[01:20:22] <spasticteapot> Or are these steppers with integrated driver circuitry?
[01:20:25] <spasticteapot> Er, CNC.
[01:20:45] <spasticteapot> ....sorry, it's really hot in here and my brain is melting out my ears.
[01:20:49] <KimK> Oh, OK, so they were using it in stepper/servo mode? (Ala Gecko ???, forgot which model)
[01:21:03] <lepton> it's really hot here, too, my brain is also melted
[01:21:53] <lepton> Yeah, they're giving it step / dir signals, and expecting IT to perform like a servo (make sure it is where it needs to be, varying coil current accordingly)
[01:22:02] <spasticteapot> It's a nice idea.
[01:22:35] <spasticteapot> I can't speak for the efficiency of steppers, but the net result is basically the same as a brushless servo with no gearbox.
[01:22:57] <spasticteapot> One moving part and no brushes to go wrong.
[01:23:18] <lepton> except these steppers have built in gearing :p
[01:23:55] <spasticteapot> So....doesn't that defeat the point?
[01:24:14] <spasticteapot> Brushless motors generally are happy at high speeds.
[01:24:42] <KimK> Ah, but steppers are generally not. Are all axis motors and drives the same size? How do the axes differ in weight/mass and is gravity involved in any?
[01:25:09] <pcw_home> Lepton: following error with HostMot2 stepgen?
[01:26:29] <spasticteapot> KimK: Motor theory is WAY beyond me, but from what I remember, configuring a brushless motor for low RPMs/hight torque generally kills your efficiency and, by extension, peak power output.
[01:26:47] <lepton> pcw_home: Yeap
[01:27:01] <spasticteapot> A good R/C airplane motor can produce more power than the largest of steppers despite fitting in the palm of your hand....at about 30,000 RPM.
[01:27:46] <pcw_home> Do you have a base thread enabled in your hal file?
[01:28:48] <lepton> No, only servo threads
[01:29:06] <lepton> I do define a base period, but as far as I know that's not starting a base thread
[01:31:18] <pcw_home> Theres a bug somewhere either in EMC or HostMot2 driver that causes trouble if an (maybe only empty) basethread is started
[01:32:11] <lepton> I saw some talk about that on message board archives
[01:32:24] <pcw_home> for example : loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES
[01:32:26] <pcw_home> will case trouble
[01:32:51] <lepton> I've noticed I get the following above a certain speed threshold (somewhere above 300 ipm) whenever I move, but when I glow lower (upper 200's), I only get the following errors on deceleration
[01:33:51] <lepton> Here are my files:
http://pastebin.com/BVZqbAdQ
[01:34:03] <moop> what is the maximum number of steps per second emc can produce through the parallel port?
[01:34:11] <lepton> I do have this line in my HAL: loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES
[01:34:24] <lepton> looks like that might be troublesome?
[01:34:44] <pcw_home> Yep
[01:35:04] <lepton> So just ommit the base period altogether?
[01:35:40] <lepton> leading to: loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES
[01:37:41] <pcw_home> yep
[01:37:51] <lepton> I took it out, tried it on the machine, same problem :/
[01:38:24] <lepton> following error on deceleration
[01:38:53] <pcw_home> What is you maxaccel?
[01:39:10] <lepton> 12
[01:39:50] <lepton> We're trying to get a more sensible value for that right now. Attempted to calculate it based on the mass of our moving parts, and max torque of the steppers (including gearing)
[01:40:10] <lepton> That lead to a very small value, so I'm skeptical of our math / thinking
[01:40:19] <pcw_home> try setting it to 0 (and keep the previous patch ie no basethred)
[01:41:04] <lepton> trying that now
[01:41:23] <KimK> You know, Seb had recently halscope-captured a case like that, where the decel had issues, but much stronger and longer accel did not. You might try that on your machine since it's simple to try. I might still have his screenshot.
[01:41:43] <KimK> Did Seb ever resolve that case?
[01:42:32] <lepton> pcw_home: Setting max accel to zero solved it
[01:42:42] <lepton> Though it of course leaves our system operating pretty rough
[01:42:53] <lepton> Any guidance on tuning the acceleration value to something appropriate?
[01:45:13] <KimK> Since you're running a stepper/servo, I might have to take back what I said before. You might have to tinker with the internal tuning values on the drives, since hal/emc doesn't really have control of it.
[01:47:25] <lepton> yeah, you're (unfortunately :p) probably right
[01:54:19] <KimK> You can coarse-tune classic servo drives with a square wave (not too big at first) and the motor decoupled. You might be able to do something like that by running (and re-running) simple gcode programs while making adjustments to the drive?
[02:00:26] <lepton> Hmm, so you mean basically trial and error moving the axes around?
[02:05:58] <KimK> Sure, adjusting one axis at a time. First the drive, then EMC. (Lather, rinse, repeat?) General guidance? Heavier axes (assuming same size motors & drives) will need more time to accel/decel without losing steps. Do the lightest axis first, and then estimate the weight/mass and expect proportionally slower acc/dec. Maybe max_vel a little bit lower too. (Proportional? Or is there a square in there? Oh, nevermind.)
[02:06:39] <lepton> That makes sense
[02:07:10] <lepton> I was thinking about calculating the kinetic energy of the moving parts of the machine at max velocity, and then dividing by the max electrical power of the steppers
[02:07:15] <lepton> Which would yield time
[02:07:31] <lepton> and than apply a saftey factor, and use that as a starting point
[02:09:26] <KimK> Sure, if that helps. I'm not sure I'd bother though. A dial indicator and a start/end point will be more useful, I'll bet. And you can write little gcode programs (two lines, out and back) so you get a repeatable input from EMC to the drive.
[02:10:18] <KimK> Oh, you have encoders, maybe you don't need a dial indicator?
[02:10:41] <KimK> Just open up the following errors while you're fooling around.
[02:11:12] <KimK> And watch your position on halscope.
[02:11:40] <pcw_home> Maxaccell of 0 should be fine
[02:12:28] <KimK> There you go. Thanks, PCW.
[02:15:04] <KimK> You might keep an eye on your following error on halscope too, to make sure it looks "reasonable".
[02:15:20] <pcw_home> ( this is assuming you are running in pure step mode)
[02:15:22] <pcw_home> Stepgen Maxaccel of 0 and no base thread should get you a working HostMot2 stepgen system
[02:15:24] <pcw_home> (of course the trajectory generators accel must be set to a reasonable value for the mechanics)
[02:17:48] <KimK> And speaking of mechanics, I seem to recall that using backlash comp alters the acc/dec in some way, so if you can live without backlash comp for now, that might help too.
[02:21:15] <pcw_home> If you are not using the encoders and only a stepgen, there are only 2 ways I know that following errors can happen:
[02:21:16] <pcw_home> 1. Insufficient headroom for the stepgen
[02:21:18] <pcw_home> This can be because the stepgens maxaccel is too low (if used (non 0) it should be a little higher than the axis accel)
[02:21:20] <pcw_home> or because maxvel is too low ((if used (non 0) it should be a little higher than the axis maximum velocity)
[02:21:21] <pcw_home> 2. Because of the empty basethread bug
[02:24:24] <alex_chally> hi all
[02:24:31] <alex_chally> * alex_chally has tapered thrust bearings
[02:25:02] <madsci44> ooh
[02:25:35] <alex_chally> for cheap on ebay too
[02:26:06] <alex_chally> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=150392422221
[02:26:18] <madsci44> i had following errors on my first emc setup - that had open loop steppers, i just had to increase stepgen_max.... values for the headroom and that solved it
[02:26:35] <lepton> Thanks for those explainations, pcw_home
[02:26:52] <lepton> We've been doing accel tuning for the past 30 mineuts, and are much much happier
[02:26:59] <lepton> The machine is moving fast and smooth :)
[02:27:49] <madsci44> good stuff
[02:28:25] <lepton> Indeed! EMC is lots of fun sometimes
[02:29:11] <KimK> Glad to hear it's better.
[02:29:15] <madsci44> especially when its finally up and running :)
[02:30:01] <lepton> I expect to be cutting within the next two days
[02:30:04] <madsci44> you planning to use those for your xy screws alex_chally? or they for something else?
[02:30:19] <lepton> Still need to get modbus running via classic ladder, which I'll hopefully accomplish tomorrow
[02:30:22] <madsci44> what type of machine is it lepton?
[02:30:44] <lepton> A 3 axis router with a 5hp spindle
[02:30:47] <lepton> Started life as a shopbot
[02:31:09] <lepton> We've done a lot of mechanical changes / upgrades to it over the course of this year
[02:31:27] <lepton> and of course now we're running EMC, rather than the incredible awful shopbot windows based control software
[02:31:44] <madsci44> wow cool
[02:32:17] <alex_chally> madsci44, yeah
[02:32:20] <alex_chally> xy screws
[02:32:31] <alex_chally> i have the mount drawn out and everything
[02:33:01] <alex_chally> tomorrow I am going to do some careful measuring of the bearings and then rough out the stock for the bearing holder so I can put it in the CNC and not take up too much time
[02:33:25] <alex_chally> machine that, fit everything together and then do the Y axis ball screw end
[02:34:03] <alex_chally> and I *think* that I can do the same design on the X axis for the bearing block, but I have to extract the X axis screw and bearings from it's bearing block
[02:34:18] <alex_chally> it would be totally boss if i could do both parts exactly the same
[02:34:35] <madsci44> yeah
[02:34:57] <madsci44> are you in canada by any chance, lepton?
[02:35:02] <alex_chally> then the last big hurtle with the physical parts is my X axis nut holder, which I think I am going to manufacture from scratch
[02:35:42] <alex_chally> it has a split holder for the X axis leadnut, but the holder is too small for the ballnut and half of it is integral to the casting
[02:36:20] <alex_chally> as opposed to trying some XY interpolation bullshit on the CNC I am going to face the entire thing off and built a new one from scratch out of aluminium and secure it with screws and some dowel pins
[02:37:56] <madsci44> i guess that way you can even shim it to height if it happens to be off
[02:38:23] <alex_chally> madsci44, yeah, I figure I can tolerance it to +0 -.001 or so and do really well
[02:38:32] <madsci44> yeah
[02:38:39] <alex_chally> it might be worth it to make it out of steel so I can surface grind it really square..
[02:38:59] <alex_chally> probably won't matter fitting it on the first time, but when it is taken apart some day and has to be set up again I bet it would make life easier
[02:39:10] <madsci44> i need to get off my behind and do my mill, i am still arguing with myself over how to orient the x-motor
[02:40:17] <alex_chally> I can see the end of the rainbow with mine, it is nice
[02:40:24] <alex_chally> well, at least the 2 axis rainbow
[02:40:41] <alex_chally> after that is finsihed and working I am going to start on the Z axis mount and stuff
[02:40:51] <alex_chally> which is something I have not even started considering how to do really
[02:46:38] <lepton> madsci44: I'm in Colorado
[02:46:49] <lepton> *goes back to control box wiring
[02:47:28] <madsci44> ah
[02:48:13] <madsci44> oh god i forgot the z axis - im arguing with myself about that too - it would be ok if one of me won decisively
[02:49:51] <alex_chally> madsci44, yeah, there are big questions like gas strut counterbalance on the knee vs moving the quill
[02:50:16] <alex_chally> and then little questions like if I go for the quill, how the fuck do I hold the entire thing onto the head?
[02:51:06] <madsci44> i think im going to skip the knee until i see how well the quill turns out
[02:51:56] <madsci44> is your head a standard type with the feed stop screw in front?
[02:53:54] <alex_chally> yes
[02:54:15] <alex_chally> well, close to standard type, but that is where the feed stop screw is
[02:55:00] <alex_chally> madsci44,
http://farm3.static.flickr.com/2796/4263848415_3dc3d15ca7_b.jpg
[02:57:12] <alex_chally> there are holes tapped on the other side that are the covers for the feed gearbox
[02:57:45] <alex_chally> I could use those, and then do some 1/4-20s or something in a bolt hole pattern around the bottom of the head
[03:05:08] <madsci44> yeah thats very similar to mine
[03:05:50] <MattyMatt> how do you deal with quill v knee in emc2? do you have 2 .ini files?
[03:06:35] <MattyMatt> assuming you've got both motorised of course
[03:07:15] <cradek> I'd make an XYZW config where W = knee
[03:07:27] <madsci44> i dont - yet - so not sure
[03:07:47] <cradek> you could put your tool lengths on W and just move it when you change tools - that would be awesome
[03:08:02] <Jymmm> cradek: Is W like a bastard step child sorta thing?
[03:08:10] <madsci44> oh wow - mechanical offset heh
[03:08:12] <cradek> T1 M6 G43, G0 W0
[03:08:33] <cradek> (knee moves down because this tool is longer)
[03:08:53] <cradek> I'd make positive be knee-moves-down
[03:08:55] <Jymmm> so like an extension of Z ?
[03:09:17] <cradek> well they're separate axes - they just happen to be parallel
[03:09:36] <Jymmm> so Z++ =)
[03:09:37] <cradek> you'd use it just like a knee (move it when you have to for more clearance)
[03:10:06] <alex_chally> I wonder if you could get a cam program to work well with a setup like that
[03:10:17] <MattyMatt> so the knee isn't used with a short quill for heavy jobs?
[03:10:27] <madsci44> so the position of w ads/subtracts from Z ?
[03:11:05] <alex_chally> cradek, it makes perfect sense to have Z up on the knee be in the negative direction, but that breaks my brain just a bit
[03:11:20] <MattyMatt> it would be easy enough with my CAM program ...blender
[03:11:20] <Jymmm> It be slick if you could setup W to operate in conjunction with tool table
[03:11:55] <cradek> Jymmm: W tool offsets are just as easy as Z tool offsets in EMC2.4
[03:12:05] <alex_chally> or maybe if you hit the limit of Z travel it starts moving the knee
[03:12:21] <cradek> yeah you could do funny stuff in kinematics - it might be fun to experiment with that
[03:12:35] <cradek> you could have them add
[03:12:41] <alex_chally> so the first 4.5 inches of Z negative happen with the knee all the way up, extending the quill down, then have it switch motors for the rest of the move
[03:12:51] <alex_chally> you could never interpolate like that though..
[03:12:55] <ds2> that hueristic should probally be tuneable in case someone wants to avoid wear on parts of the screw
[03:13:07] <madsci44> maybe i will do my knee from the start :-)
[03:13:37] <ds2> but that might make constant whatever contouring "interesting" to do right
[03:14:01] <cradek> knee mills are super flexible and take very little space - but nobody enjoys cranking a knee up and down
[03:14:28] <madsci44> my elbow agrees
[03:15:47] <madsci44> ill never attempt it im sure but i have always imagined what it would be like to do everything, ram, tilt pitch, turret
[03:16:38] <MattyMatt> I'd do the lot from the start if the axes are there
[03:16:54] <MattyMatt> I'm finding 3 axes rather limiting already
[03:16:58] <cradek> I don't think tilt would be any use
[03:17:19] <alex_chally> madsci44, I don't think the standard knuckle design could be easily converted
[03:17:26] <alex_chally> it would be easier to make it from scratch
[03:18:16] <madsci44> it would probably be a nightmare mechanically - youd have to use some sort of strut setup - and yeah im not sure what it would add for capability - would be fun to watch tho :)
[03:19:25] <MattyMatt> yeah I suppose a trunnion that adds 2 axes to the workpiece is more useful in reality
[03:20:02] <madsci44> accuracy holds better with all that stuff locked down and stay that way after tram
[03:20:29] <alex_chally> MattyCNC, not to mention a more simple build, with less weight being shifted around
[03:20:52] <MattyMatt> yep, and servicable/replacable
[03:21:37] <madsci44> are there any known setups in EMC with XYZW cradek?
[03:21:53] <MattyMatt> there was a nice ancient lathe on ebay that would have fit on my bed nicely
[03:22:20] <alex_chally> MattyCNC, I keep thinking that finding a little 9x20 lathe with scrap ways would be perfect
[03:22:21] <cradek> I've seen video of a XZW (two turret) lathe
[03:22:51] <cradek> I've never personally seen a cnc-controlled knee
[03:22:56] <alex_chally> chop the ways off and mount the headstock on my table, build a trunion that uses a MT4 taper or whatever
[03:23:31] <MattyMatt> ah without the ways, a homemade headstock would do the job
[03:26:01] <MattyMatt> there wouldn't be much room for tapers on my machine. I need flat rotaries
[03:26:57] <alex_chally> my problem is that this looks so sketchy
[03:26:57] <alex_chally> http://www.youtube.com/watch?v=M_AKhV9-eIk
[03:27:14] <alex_chally> it annoys me tha thte screw needs to be that far away from the quill...
[03:27:53] <geo01005_home> geo01005_home is now known as geo01005
[03:29:36] <madsci44> thats about the layout i was contemplating - there is some good solid casting there to support the bearings - despite it being that far away i am leaning to think i would get better accuracy that way than any other means
[03:30:00] <madsci44> theres too much slop in all the other existing feed mechanisms
[03:34:28] <alex_chally> madsci44, I can't think of anything either, but I still don't like it :-p
[03:39:56] <madsci44> no matter what something is gonig to be "way out there" i figure
[03:42:18] <madsci44> for my x axis motor im down to either leaving it straight out - adding to the overhang, or moving it down lower and having the back face the knee where it can tuck slightly under the saddle to avoid reducing x or y travel, i dont want it at the front because sometimes that surface is handy too
[03:42:28] <MattyMatt> piezo gibbs in the slides :)
[03:42:55] <madsci44> piezo gibbs? lemme guess they vibrate to stay tight but not wear?
[03:43:09] <MattyMatt> nope, vibrate to move the axis
[03:43:18] <alex_chally> how do you control the direction?
[03:43:45] <alex_chally> madsci44, I would tend to have it stick out in and use the extra floorspace
[03:43:45] <MattyMatt> there's a good vid on YT, I'll try to find it tho I can't play it
[03:43:56] <alex_chally> madsci44,it would be super annoying if it was in the way some day...
[03:44:18] <alex_chally> also would probably lead to a smaller belt length, which is mope bettah
[03:44:55] <madsci44> yeah thats the only reason i didnt go for the underneath - yet - maybe :)
[03:45:07] <madsci44> (the belt)
[03:46:06] <madsci44> Y on mine is really easy - motor below back hanging under the edge of the front of the knee
[03:46:48] <madsci44> you are doing your knee ? are you keeping the bevel gear in the drive train?
[03:48:40] <alex_chally> nah, I am going to do the quill
[03:56:00] <madsci44> actually - hah youtube is a handy place to see setups - i never considered looking there - this mill is one size down from mine
http://www.youtube.com/watch?v=78KUDWnz-WU&feature=related he did the knee too on it
[07:05:27] <Jymmm> SWPadnos: cradek jepler jmkasunich alex_joni
http://www.warp9td.com/
[08:02:34] <ries_> ries_ is now known as ries
[08:39:56] <alex_joni> Jymmm: and?
[08:40:05] <alex_joni> the SS has been around a couple years at least
[08:57:24] <Fox_M|afk> Fox_M|afk is now known as Fox_Muldr
[12:40:31] <Fox_Muldr> Fox_Muldr is now known as Fox_M|afk
[15:13:05] <Jymmm> alex_joni: No USB love?
[15:15:31] <skunkworks> logger_emc: bookmark
[15:15:31] <skunkworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2010-07-20.txt
[15:21:28] <Jymmm> skunkworks: howdy
[15:23:29] <pcw_home> Not called the Universal Serial Botch for nothin
[15:23:53] <Jymmm> pcw_home: did you see the board?
[15:24:24] <pcw_home> Didnt look closely
[15:24:28] <Jymmm> k
[15:31:10] <skunkworks> Good morning!
[15:31:34] <skunkworks> * skunkworks still has to order one more servo interface board (7i33)
[15:31:37] <archivist> Jymmm, you have to realise that board does not work the emc way
[15:32:15] <Jymmm> archivist: Besides the emc doesn't support USB?
[15:33:05] <archivist> no because that has the motion on board because you cannot run that over usb
[15:33:35] <Jymmm> Right. Is that such a bad thing?
[15:34:22] <archivist> this argument has been gone over **** times in here
[15:35:19] <pcw_home> The argument should be referred to by number to save time (which reminds me of an old joke)
[15:38:43] <Jymmm> archivist: I'm not debating anything, just asking
[15:44:17] <elmo40> w00t, found a 512Mb stick of RAM for my box :) That should help with latency, no?
[15:45:32] <skunkworks> Jymmm: flexablility and realtime control of things like FO.
[15:46:18] <skunkworks> elmo40: probably not....
[15:47:02] <pcw_home> The basic problem is that USB is not very good at realtime so for example a step generator like the SS
[15:47:03] <pcw_home> has to buffer motion itself meaning that EMC no long knows the actual axis positions anymore.
[15:47:05] <pcw_home> This makes operations that must know real time position like threading or rigid tapping
[15:47:07] <pcw_home> (or anything that requires smart reaction to real time events) no longer possible without moving
[15:47:08] <pcw_home> the locus of control to the external hardware device. (which has many bad side effects)
[15:48:46] <archivist> most could be dealt with in the usb2 synchronous mode except for an idiot plugging in a new device while running
[15:49:39] <pcw_home> Yes the multiplexed nature of USB make it unsuitable as well
[15:52:29] <Jymmm> Well, I underside the USB polling is such a pita, I thought it was just being used here for comms, not so much control
[15:53:30] <pcw_home> should be fine for non-realtime but no-go for motion
[15:54:15] <Jymmm> Well, it must work at least in part
[15:54:46] <pcw_home> for systems without realtime control sure
[15:55:29] <Jymmm> So it's on a delay (so to speak) ?
[15:56:32] <pcw_home> yes, to keep the step motors running smoothly the SS must buffer some amount of motion
[15:56:59] <Jymmm> Is that such a bad thing?
[15:57:47] <pcw_home> No its all fine until you need to interface with realtime I/O like a index pulse or limit switch
[15:58:18] <Jymmm> Isn't that what the FPGA is for?
[15:58:37] <archivist> unless all the other io and motion is on the usb board
[15:58:53] <archivist> and then its not emc anymore
[15:59:18] <Jymmm> So not much different than a mesa board?
[15:59:38] <archivist> just use a pcit has motion so is different
[15:59:48] <archivist> it has motion so is different
[15:59:49] <pcw_home> Well I dont think I would like to move EMC o the FPGA (Much less developer friendly environment)
[16:00:25] <cradek> mesa board doesn't queue motion, or know about homing or probing or threading or feed override or arcs or ...
[16:00:36] <pcw_home> We have buffered motion configs (USB as well) but they are not a good match to EMC
[16:00:36] <skunkworks> the mesa hardware when used with emc is basically encoder counters and output control (pwm i/o or +/-10v)
[16:00:44] <Jymmm> Well if EMC was moved to FPGA, there would be less demands on PC requirements, no?
[16:01:03] <skunkworks> with mesa hardware - there is less demand on the pc.
[16:01:16] <skunkworks> (without moving emc to it)
[16:01:22] <archivist> 9 axis motion is not trivial to stuff in an fpga
[16:01:35] <cradek> yes that's pick-your-poison setup. if you have externally queued motion you don't need realtime in the pc, but you lose the benefits of realtime in the pc
[16:02:19] <pcw_home> Yes any hardware that has step generation and encoder counting will reduce the latency requiremants to the 100s of uSec region
[16:02:22] <cradek> suddenly can you do lathe threading with mesa? with galil? with ppmc? with stg? with motenc? with parport? are all separate questions and the answers depend on ten manufacturers getting it right in their own products
[16:02:49] <cradek> history tells us those manufacturers have a hell of a time getting it right - read web forums to see that :-)
[16:03:03] <L84Supper> well you could keep the real time benefits of a PC and have EMC in both the FPGA and PC of you have a very low latency IO
[16:03:29] <L84Supper> but it's not built into PC chipsets so it's expensive
[16:04:57] <Jymmm> Can someoen tell me what the USC board is doing? I know it's treating the steppers as servos, but I still don't get the benefit of the board.
[16:04:58] <L84Supper> we use ~1uS response IO in HPC nodes but the FPGA's are a few hundred $$
[16:05:51] <skunkworks> Jymmm: mainly - it moves the step generators into hardware.
[16:06:17] <Jymmm> skunkworks: Ok, so doesn't that have some cacheing too?
[16:06:23] <skunkworks> no
[16:06:51] <cradek> no, it has a step pulse generator whose stepping rate gets reprogrammed every servo cycle (millisecond or less)
[16:08:18] <Jymmm> So EMC sends the "command" to the USC, and the USC carries it out, instead of the PC generating the pulses?
[16:08:26] <cradek> yes
[16:08:47] <cradek> external hardware is good at generating nice even step pulses at whatever programmed rate
[16:08:53] <Jymmm> Couldn't that be done with USB ?
[16:08:59] <archivist> ffs
[16:09:00] <cradek> no
[16:09:21] <cradek> because you can't talk to something reliably every millisecond over usb
[16:09:35] <skunkworks> if you look at it as a servo setup - (like with mesa hardware) emc sends out how fast the servos should go - and reads back in the actual encoder postion every ms. Then adjusts accordingly. emc doesn't have to do the grunt work of counting encoders or generating the pwm to run the servos (or +/-10v)
[16:09:37] <Jymmm> Even with USB voodoo?
[16:09:47] <cradek> I have no idea what that means
[16:10:10] <Jymmm> Non-polling mode (?)
[16:10:21] <pcw_home> nice even pulses, yes, knowing where the motor is at any given servo period, no
[16:10:21] <cradek> yes the USC looks exactly like velocity mode servos to EMC
[16:10:48] <archivist> Jymmm, usb is dead for indeterminate periods when other devices are around
[16:11:40] <skunkworks> Jymmm: on paper - you would have better luck with rt over network. (no one has done anything with it yet though)
[16:11:43] <L84Supper> PC IRQ response is like a German or Japanese schedule, on the other side of USB it's like a US Amtrak actual time
[16:11:53] <cradek> ha
[16:12:38] <Jymmm> skunkworks: Yeah, I've been bugging SWPadnos about that for a couple of years
[16:12:44] <archivist> the door to the station is a revolving one and its too small
[16:13:14] <skunkworks> plus only 1 door works at a time...
[16:13:16] <skunkworks> ;)
[16:13:21] <archivist> other train loads stop your information
[16:13:44] <Jymmm> I guess what I don't get is how everyone else is using USB and getting away with it.
[16:14:04] <cradek> we have such awesome products available that work beautifully - I really don't understand the whining about usb
[16:14:05] <archivist> they dont have 9 axix realtime control
[16:14:07] <Jymmm> and THATS what I'm trying to understand.
[16:14:15] <Jymmm> archivist: Do you?
[16:14:22] <Jymmm> Does anyone ?
[16:14:23] <archivist> I have 5
[16:14:26] <L84Supper> you could have a FPGA off of Hypertransport, we could strip down Extoll
http://www.hypertransport.org/docs/wp/UoM_HTX_NIC_02-25-08.pdf
[16:14:32] <cradek> Jymmm: it works badly. read the mach forums for more details.
[16:14:40] <L84Supper> this would respond fast enough
[16:15:17] <archivist> Ive been told of the problems over here in the UK as well
[16:15:25] <Jymmm> cradek: Well, ok. But what about things like a printer or document scanner? (the only usb things I could thinkg of off the top of my head)
[16:15:33] <L84Supper> but now you're into AMD server hardware with multi CPU sockets
[16:15:40] <elmo40> skunkworks: really? won't alter any latency? I find that hard to believe... it will put more programs into RAM now. That should improve latency. doesn't it? LOL one way to find out... boot it up :)
[16:15:47] <cradek> what about them? nobody cares if their printout comes 10 milliseconds late
[16:16:21] <cradek> Jymmm: you're just not paying attention if you think machine control is like printing or scanning documents
[16:16:32] <cradek> usb is great for those applications
[16:16:50] <Jymmm> cradek: Like I said, it's the only USB device I could think of with motors.
[16:17:18] <cradek> the computer doesn't control the motors in a printer.
[16:17:24] <archivist> you see synchronous mode in webcams but do you notice the steppyness of the image
[16:17:36] <Jymmm> sure
[16:17:45] <archivist> thats latency
[16:17:54] <Jymmm> k
[16:18:30] <L84Supper> try and stop your USB printer in under 1ms :)
[16:19:03] <Jymmm> I DO get it that USB sucks. But I'm not thinking of usb for "direct drive" as much as "those vacuum tubes at the bank" it just transports the commands.
[16:20:39] <Jymmm> Kinda like Remote Desktop
[16:20:46] <Jymmm> or VNC
[16:21:21] <archivist> the communication in EMC is realtime
[16:25:02] <L84Supper> any news on the EMC port to the beagleboard? Did the RTAI guys ever get ARM smoothed out?
[16:25:28] <elmo40> RTAI and ARM are not already working?
[16:25:59] <L84Supper> ARM cortex8/9 smoothed out
[16:27:26] <L84Supper> elmo40: last I heard they had some earlier ARM cores working with RTAI ARM7, strongARM
[16:28:13] <Jymmm> Does anyone have a spare GPIO card they want to let go for cheap?
[16:30:04] <L84Supper> the only ARM SOC's I was considering for EMC are the Marvell devices since they have PCIe, openRD is a possibility
http://www.globalscaletechnologies.com/t-openrdcdetails.aspx
[16:31:09] <Jymmm> L84Supper: how much is that?
[16:32:38] <L84Supper> Jymmm: the openRD's are ~$149 for the board and ~249 for the client but there are some low cost tablets and boards coming out of Taiwan soon
[16:42:41] <L84Supper> I had demos of ARM 7-10" tablets with PCIe that were ~$90 at Computex
[16:49:49] <Jymmm> ds2:
http://sfbay.craigslist.org/sby/tls/1853010421.html
[16:51:39] <L84Supper> http://chicago.craigslist.org/chc/bfs/1849040014.html how old is this?
[16:57:06] <Jymmm> L84Supper:
http://www.barkermill.com/
[17:11:47] <L84Supper> http://cgi.ebay.com/WEBB-VERTICAL-MILLING-MACHINE-3HP-TABLE-10-X-50-/320561450814?cmd=ViewItem&pt=BI_Mills&hash=item4aa2f38f3e
[17:12:04] <L84Supper> <--- needs another mill fast
[17:40:09] <IchGuckLive> hi all someone can help me to update from 2.3.5 to 2.4.1
[17:40:18] <IchGuckLive> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UpdatingTo2.4
[17:40:50] <IchGuckLive> Click "Mark All Upgrades" this will update the heaader the image and 415 packets
[17:41:03] <IchGuckLive> can i only update the EMC2.4
[17:56:06] <moop> does anyone know what the difference between normal and orthogonal is?
[17:58:30] <IchGuckLive> normal all degree allowd ortogonal only 90-180-270 and 0
[17:59:31] <moop> i wish my brain could remember maths
[17:59:58] <moop> if i could just remember it i may be able to understand it
[18:00:31] <moop> i thought normal to a vector was the vector perpendicular to it
[18:00:47] <IchGuckLive> in CAD its only alowd to draw horizontal or vertical
[18:01:22] <moop> and I thought orthoganal was the same, but some now starts telling me that orthogonal means that the product of the two is zero...
[18:01:48] <moop> my eyes start to glaze over
[18:03:08] <cradek> dot product of perpendicular vectors is zero
[18:03:41] <cradek> in vector space there are different kinds of 'products'
[18:03:53] <moop> so dot product of 90-180-270 and 0 is also zero?
[18:04:47] <moop> so two vectors can be orthogonal but not normal?
[18:04:48] <cradek> I don't understand that question
[18:05:10] <cradek> usually you say 'normal' when you're talking about a vector vs a plane
[18:05:11] <IchGuckLive> moop YES
[18:05:31] <moop> I think the problem is i dont understand the math well enough
[18:05:51] <moop> so my question is pointless any ways
[18:06:06] <IchGuckLive> i managerd the upgrade to 2.4.2
[18:06:25] <IchGuckLive> yes mashine is up and running after new Stepconf
[18:07:11] <pcw_home> also Sf(x)f(x) = 0 for orthogonal functions (like sin(x),cos(x))
[18:07:12] <pcw_home> the normal vector is orthogonal to any vector in the plane
[18:07:22] <moop> I am trying to work throught some robot arm kinematics, and I am begining to think its beyond me
[18:07:37] <moop> its 10 years since i done any math
[18:07:50] <moop> and i was pretty poor even then
[18:08:20] <pcw_home> (Sf(x)g(x))
[18:09:55] <cpresser> orhogonal is always 90° to normal
[18:09:56] <IchGuckLive> moop did you look at Wipipedia
[18:10:09] <moop> does anyone want to write some robot arm kinematics for me?
[18:10:10] <cpresser> if mulitply to orthogonal vectors yo always get a zero
[18:10:37] <cpresser> wrong: 20:09 < cpresser> orhogonal is always 90° to normal
[18:10:55] <cpresser> i wanted too write: 'tangential is always 90degrees to the normal'
[18:11:00] <IchGuckLive> moop how many Pivot's
[18:11:03] <moop> I am going to check wikipedia
[18:11:07] <pcw_home> dot product multiply...
[18:11:32] <moop> 6 pivots, but strange control with only 5 motors
[18:12:13] <IchGuckLive> 6 in the arm or only 3 to position
[18:12:31] <IchGuckLive> 4 with the main rotat
[18:14:56] <moop> its robot arm but there are chain drive such that the angle of some linkages stay the same relative to the base regardless of what happens at intermediate links and joints
[18:15:19] <moop> its sort of looks like a puma arm
[18:16:10] <moop> I think I am totally confused
[18:16:13] <IchGuckLive> http://www.wescottdesign.com/articles.html
[18:17:23] <moop> that site was of no help to me IchGuck
[18:18:08] <moop> I think I need to go away for two weeks of intensive study, maybe then I will know enough to realise I should give up
[18:20:10] <IchGuckLive> moop querry
[18:20:20] <IchGuckLive> moop 24MB
[18:22:09] <IchGuckLive> moop do you got it ?
[19:16:10] <moop> sometimes i begin to think there is an ubergeek that dwarfs my intelligence, writing the code behind this software
[19:47:44] <salvarane> Hello
[19:50:36] <micges> hi
[19:51:51] <salvarane> I run emc-2.4.0, but the program not runing correctly because the emc2 require that the my system it is overloaded of programs in execution , in this manner the promgram emc2 run correctly without axis
[19:52:22] <salvarane> message
[19:56:54] <micges> salvarane: I don't understand, can you write it other way?
[19:57:08] <salvarane> ok
[19:57:24] <salvarane> I rewrite this
[19:58:21] <micges> (I'm also not native english speaker)
[19:58:42] <salvarane> when I run the emc2-2.4.0 , the programma not runing if my system is idle state, but the the program runing if the my system is very busy
[19:59:18] <salvarane> because thi situation
[20:00:38] <salvarane> the message is the tipical : waiting axis or some thing like
[20:02:44] <archivist> write in your native language and use google translate
[20:03:40] <skunkworks> salvarane: off of the top of my head... Remark out (#) the nlm line of your ini file.
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UPDATING#emc_nml_changes
[20:07:29] <salvarane> thanks , I read
[20:10:38] <salvarane> sorry , but into my configure file stepper_mm.ini , not isn't the option " NML_FILE = emc.nml "
[20:19:33] <salvarane> I think this problem is due to , comunication between the sub system realtime and emc2
[20:21:28] <salvarane> but, I can mistake
[20:23:04] <salvarane> I remeber tha I compiled the kernel 2.6.32.11 patched with rtai 3.8
[20:25:39] <ries_> ries_ is now known as ries
[20:30:54] <skunkworks> http://www.youtube.com/watch?v=LJYhz5aTMnA
[20:33:35] <archivist> my LJ4 was faster :)
[20:34:02] <skunkworks> not as cool though... ;)
[20:37:36] <alex_joni> that vismach model is pretty useless ;)
[20:39:44] <skunkworks> I saw that ;)
[20:42:19] <alex_joni> very cool overall though
[20:43:06] <skunkworks> that guy has a few different configs..
[20:43:16] <skunkworks> Tripod and such
[20:48:40] <alex_joni> seen some of the other vids
[20:49:04] <alex_joni> this one is also a tripod, even if there are 6 motors
[21:13:04] <Fox_M|afk> Fox_M|afk is now known as Fox_Muldr
[21:18:51] <Jymmm> When using PWM for spindle control, is that typically 0-10VDC?
[21:33:32] <DaViruz> pwm is typically 0-100%, voltage being irrelevant
[21:42:24] <alex_joni> except when PWM is used to drive analog drives that expect 0-10V
[21:42:48] <alex_joni> in that case some hardware circuit is used to construct the 0-10V out of the 0-100% PWM
[21:47:07] <alex_joni> whee.. first delta robot run by emc2:
http://www.youtube.com/watch?v=2JbOUqE2eFI
[21:52:00] <andypugh> I have just finished some parts (of my own design, nobody else to blame) that are positively begging to seize together. 80mm x 1mm pitch thread, aluminium into aluminium.
[21:54:07] <andypugh> With EMC screw threads have now become just about the easiest way to join turned parts. Especially as it can do any size and any pitch that takes your fancy
[21:55:56] <moop> i been researching about my idea the other night and seems someone has already done it!
[21:56:25] <andypugh> Which idea was that?
[21:56:31] <moop> http://www3.interscience.wiley.com/journal/114194947/abstract?CRETRY=1&SRETRY=0
[21:56:47] <moop> now someone just needs to implement it in emc
[21:57:00] <andypugh> That session only seems to work for you
[21:57:34] <andypugh> It works without the stuff after the ?
[21:58:19] <andypugh> Genserkins is pretty close to what is described ther.
[21:59:02] <moop> I will have a look at genserkins
[22:02:07] <moop> what would be really nice would be a cad app to layout the joints and geometry of any cnc machine
[22:03:34] <moop> which of the sample configs uses genserkins?
[22:03:45] <andypugh> I am not sure any do.
[22:03:52] <lepton> Is anyone using running an arduino for IO in EMC 2.4.2, a 'la:
http://axis.unpy.net/01198594294
[22:04:28] <moop> i try "grep -re genserkins configs/"
[22:05:06] <andypugh> I suspect that once you have abstracted as far as the D-H parameters that a CAD package would only confuse matters.
[22:05:48] <andypugh> I suspect that the only way to understand genserkins is to look through the source with a stack of textbooks.
[22:06:18] <moop> looks like the puma560_sim_6.hal uses genserkins
[22:06:25] <micges> moop: in master there is puma 560 config that use it
[22:06:36] <micges> :)
[22:06:45] <moop> i found that already micges
[22:06:51] <moop> :)
[22:07:57] <moop> I started writing a shell script to do the generation, but i think it is probably all beyond me
[22:09:22] <moop> I would like to find a copy of the pascal source code referenced here:
http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6V4P-47XNPNF-S&_user=10&_coverDate=12/31/1991&_rdoc=1&_fmt=high&_orig=search&_sort=d&_docanchor=&view=c&_acct=C000050221&_version=1&_urlVersion=0&_userid=10&md5=c0f3d0bf5ac5ba2577d7017541573733
[22:11:06] <Jymmm> moop: only $31.50
[22:13:43] <lepton> Hmm, so it seems that the Arduino code for HAL doesn't work in current versions, based on a forum posting, and Jeff posted a link in response, but the link is dead
[22:13:56] <lepton> Anyone have any leads on what the status of that is?
[22:14:18] <lepton> ref:
http://www.mail-archive.com/emc-users@lists.sourceforge.net/msg20858.html
[22:15:33] <andypugh> Try this link?
[22:15:34] <andypugh> http://www.mail-archive.com/emc-developers@lists.sourceforge.net/msg02827.html
[22:16:39] <andypugh> That is what the link in the first message should be, it seems to have been oddly mangled. (I looked through my mail archive)
[22:24:09] <lepton> Sorry for the drop out, my neighborhood doesn't have any broadband and is stuck in 1990
[22:24:22] <lepton> It seems that the Arduino HAL interface is non-functional right now
[22:30:33] <andypugh> You could an email to the mailing list to see if jepler has any ideas there.
[22:31:32] <lepton> That's a good idea, I'll try to motivate myself to do that after I try to solve it myself some more :)
[22:31:43] <moop> a "grep -re rduino" in the source tree shows no mention of and arduino interface??
[22:32:09] <moop> is there one available?
[22:32:37] <moop> I would think a pic would be a better chip to use?
[22:32:54] <Fox_Muldr> Fox_Muldr is now known as Fox_M|afk
[22:33:10] <andypugh> It's a "contributed component", something you can download and use with EMC2, but not part of the distribution.
[22:33:44] <moop> is it used as a usb interface?
[22:33:55] <andypugh> And the advantage of the Arduino is that it is all there on the board, power supply, programming interface, break-outs to wires etc etc.
[22:34:03] <andypugh> http://wiki.linuxcnc.org/emcinfo.pl?ContributedComponents#Arduino_ADC_PWM_and_digital_I_O
[22:35:12] <moop> are arduinos available with more io lines?
[22:35:22] <andypugh> Yes, the Mega has several more
[22:35:44] <andypugh> http://arduino.cc/en/Main/ArduinoBoardMega
[22:36:11] <moop> a while back I was considering using a pic18f as a usb interface, but never got further that looking at the pic usb code
[22:36:53] <andypugh> That is rather my point. You can buy an arduino, download the GUI, and be twidding LEDs inside 10 minutes
[22:36:55] <lepton> It uses a usb > serial convertor on the board
[22:37:04] <lepton> Yeah, it's a great idea
[22:37:22] <moop> whats the price?
[22:37:37] <andypugh> I think the HAL module communicates via serial.
[22:37:41] <andypugh> $20?
[22:38:07] <moop> $20 all ready to go with no extra components?
[22:38:24] <andypugh> Sorry, $30 (all ready to go)
[22:38:25] <andypugh> http://www.adafruit.com/index.php?main_page=index&cPath=17&zenid=588411c8a70e828f7a67223aa30be3a7
[22:39:10] <moop> the pic i was looking at was $4 but needed quite a few more components and required programming to use usb
[22:39:40] <andypugh> Arduino is open-source, so there are many legitimate copies like Freeduino and Seeduino. They seem a little cheaper
[22:39:41] <andypugh> http://www.nkcelectronics.com/arduino.html
[22:40:22] <L84Supper> anyone ever try one of these retrofit kits?
http://www.servosource.com/Servo_II_Brochure-2pg_070604.pdf
[22:41:40] <moop> I'm getting hungry, I have to go get some dinner
[22:42:20] <andypugh> L84Supper: Looks good. Doesn't look cheap.
[22:42:38] <L84Supper> somebody has one for $500, never installed
[22:42:51] <andypugh> moop: I am using an Arduino to convert resolver to quadrature as my servos are resolver.
[22:43:18] <L84Supper> probably worth it for the motors and mounts, I'd just use Mesa cards instead of it's controller
[22:43:33] <L84Supper> its/it's
[22:44:21] <andypugh> moop: In fact, I have used the Arduino to do the resolver conversion and the phase signal generation:
http://www.youtube.com/watch?v=oyeJfNg3NfQ
[22:48:05] <Valen> ey cradek got mah probing thing working
[22:48:27] <Valen> looks like our switch is +-~.002mm at the moment
[22:48:33] <Valen> thanks for your help with the probing
[22:52:46] <L84Supper> nice switch, what type is it?
[23:03:35] <lepton> Incase anyone is interested, it turns out there's a pretty well developed Modbus Master library for the Arduino
[23:03:44] <lepton> http://code.google.com/p/modbusmaster/
[23:03:58] <lepton> I might try to use that instead of modbus in classic ladder or gs2_vfd
[23:11:13] <andypugh> Night all
