Back
[00:00:02] <icee> all your real time tasks, that is.
[00:02:48] <lerman> Ah... In a previous life, I build systems using Sun Solaris. It allowed user tasks to be specified as having real time priority. It worked pretty well with the slight "quirk" that a RT task could hang in a loop which would hang the system. To prevent that while we were debugging, we were careful to run a process at highest priority that looked for an abort signal.
[00:03:07] <lerman> build s/b built
[00:03:19] <icee> there's a big difference between soft realtime and hard realtime
[00:03:44] <icee> when things being late can result in damage to property or loss of life, you want hard realtime.
[00:05:13] <fenn> icee how many pins are you using for addressing? 3?
[00:05:21] <lerman> Well, the big issue is whether the context switch time is bounded. Then it's a matter of degree in the sense that the time might be 25 usec or 250 msec. Both can be hard realtime systems, but the later probably isn't good for many hard real time projects.
[00:05:25] <icee> fenn: addressing?
[00:05:44] <fenn> to talk to the dsp
[00:05:55] <icee> l: The question is whether on the soft realtime system it is really bounded at all
[00:06:17] <icee> l: if there's anything that disables interrupts or deals with locks in the wrong way.. it's not.
[00:06:33] <fenn> to pick which dsp you want to talk to i mean, since there are (n) dsp's present on the bus
[00:06:45] <icee> l: do you want to bet your system on a massive monolithic kernel like linux being correct for all those lines?
[00:07:03] <icee> fenn: TBD; the axis protocol uses 5 bits for a register id, 3 bits for a 'board id'
[00:07:21] <lerman> You can disable interrupts, but the time must be bounded (and preferably, known).
[00:07:50] <icee> it's to be determined whether all the DSPs pretend to be one 4 axis board or 4 1 axis boards
[00:08:02] <icee> lerman: and you need to know that for all paths, and for all combinations of interrupts that can happen
[00:08:42] <icee> and then adding those up, along with the timing information for higher priority tasks, tells you whether you'll be able to guarantee achieving the timing requirements for a particular task
[00:09:46] <icee> fenn: though 4 one-axis boards is likely.. why?
[00:10:02] <icee> er, the 'pico protocol', not axis protoocl
[00:10:17] <lerman> icee: that's a good argument for running with an external dedicated processor. I often go out to my shop and find that my EMC system has crashed overnight. (Well, it could be that the multiple emacs sessions I'm running are causing problems, but I don't really know.
[00:11:04] <fenn> icee: so you are specifying "this variable on that dsp" in one instruction right?
[00:11:26] <icee> fenn: we're using the EPP addressing protocol. IEEE 1274.
[00:11:33] <icee> so an address cycle to set the current register
[00:11:38] <icee> then read/write cycles
[00:11:49] <icee> with autoincrement of address
[00:12:22] <fenn> it just adds one to the address each cycle?
[00:12:22] <icee> I am planning on using some of the unused pico registers to implement a more efficient protocol, btw
[00:12:38] <icee> yes.
[00:12:45] <icee> so you can do an address cycle with data '5'
[00:12:57] <icee> then read (location '5'), read (location '6'), write (location '7'), etc.
[00:13:28] <icee> If we do the 'one axis per board'. i'm planning on this register layout (all hex):
[00:14:17] <fenn> i'm pretty new at all this.. why do we need a variable greater than 8 bits?
[00:14:32] <icee> 14: read- flags (fault state), 15: read- encoder byte 0, 16: read-encoder byte 1, 17: read- encoder byte 2, 18 write: direction, MSBits of duty cycle,
[00:15:05] <icee> 19 write: lsbits of duty cycle, 20 write: flags/commands
[00:15:11] <icee> so one axis update looks like
[00:15:26] <icee> address cycle (14), read, read, read, read, write, write
[00:15:44] <icee> 7 EPP parallel port cycles to read the flags, encoder, and write the new duty cycle
[00:16:04] <icee> well, we want more than 8 bits of precision on the duty cycle/effort level
[00:16:09] <fenn> why?
[00:16:47] <icee> because more precision is better, and we have 10 bits of ADC and can have even more precision with how we adjust the 'leading pahse' angle and dithering
[00:17:09] <icee> and with the encoder, we can have as many as a million counts per second.
[00:17:09] <fenn> ok so it's based on the resolution of your feedback
[00:17:27] <icee> well, not just the resolution of the feedback
[00:17:45] <fenn> i meant the resolution of the a/d converter
[00:18:03] <icee> even if we're running a control loop to keep current at '304', there's a difference between 304 leading the rotor by 10 degrees and 20 degrees
[00:18:27] <icee> as to the encoder stuff.. you can get 1 million counts per second or more
[00:18:31] <fenn> yeah
[00:18:45] <icee> if you're updating at 1KHz, that means you need at least 2000 possible values to avoid ambiguity
[00:19:58] <fenn> arent we updating at less than 1khz?
[00:20:06] <icee> we're hoping to update at 10KHz, actually.
[00:20:24] <fenn> each servo loop it checks all (n) encoder readouts?
[00:20:30] <icee> yah.
[00:20:44] <icee> so that's 7*4 parallel port cycles for 4 axes.
[00:21:05] <icee> so the maximum theoretical is about 35KHz
[00:21:24] <icee> but, ... i know we won't get anywhere near that for various reasons
[00:22:11] <fenn> i'm not clear on what 35khz refers to
[00:22:22] <icee> 35KHz servo updates.
[00:22:27] <icee> read encoder / write new duty cycle
[00:22:41] <icee> that's based on 1000000 / 28
[00:23:06] <fenn> back up a bit :)
[00:23:22] <fenn> maximum encoder count is like 8000 cpr * 3000 rpm * 60 sec/min
[00:23:29] <fenn> == 144000000
[00:23:40] <Jymmm> per what?
[00:23:41] <icee> 60 sec/min
[00:23:52] <icee> er
[00:24:03] <fenn> add another 0 to that
[00:24:30] <icee> i think you have your math a little wrong
[00:24:38] <fenn> yeah maybe
[00:24:43] <fenn> how many encoder pulses per second?
[00:25:07] <lerman> fenn: Didn't you want to divide by 60? You want counts per second. => 8000 * 3000 / 50
[00:25:09] <fenn> 8000*3000/60?
[00:25:15] <fenn> ok :)
[00:25:39] <fenn> (the motors are 3000 rpm max right?)
[00:25:41] <lerman> Yeah, that's what my brain said -- but my lying fingers couldn't understand.
[00:25:49] <icee> 4500 rpm max
[00:25:57] <icee> they provide 2000 counts/rev though.
[00:26:20] <fenn> but quadrature gets you 8000 no?
[00:26:39] <icee> i don't believe so.
[00:26:43] <fenn> cpr is ambiguous.. does it mean counts/rev or cycles/rev?
[00:27:08] <lerman> When specing encoders, it is usually cycles/rev.
[00:27:35] <fenn> sorry if i'm driving everyone nuts
[00:27:58] <fenn> where does this million counts/sec figure come from?
[00:27:59] <lerman> Too late for that (at least in my case).
[00:28:32] <icee> fenn: it's a design value with conservatism
[00:28:45] <icee> 8192 counts * 4500 rev/min / 60 sec/min
[00:28:50] <icee> gives you 600000
[00:28:56] <icee> so my design value says we need to cope with 1M
[00:29:56] <icee> so, to deal with 1M
[00:30:24] <icee> updates can be at most 128 microseconds apart with 8 bits of count resolution
[00:30:25] <lerman> If you reliably read the counters every msec, you need only a 16 bit counter. That can save 2 reads per axis.
[00:30:45] <icee> l: two reads?
[00:30:52] <a-l-p-h-a> I'm getting the following error when I try to do get an "sudo apt-get dist-upgrade"
http://paste.ubuntulinux.nl/4087 any one know what to do?
[00:31:06] <lerman> Don't you have 4 byte counters now?
[00:31:09] <icee> f: 32.7 milliseconds apart with 16 bits of count
[00:31:11] <icee> l: no, 3 bytes
[00:31:19] <lerman> Sorry.
[00:31:22] <icee> same as the pico systems univ pwm controller, which we're endeavoring to be compatible with
[00:31:34] <icee> and 16 seconds with 3 bytes of count.
[00:32:01] <lerman> I'm using the pico systems controller -- compatibility would be a good thing (TM -- martha stewart)
[00:32:39] <fenn> alpha get rid of xfonts-base
[00:32:39] <icee> l: we're building a controller for synchronous ac motors that is loosely compatible with it
[00:32:50] <fenn> alpha you can reinstall it if it doesn't work
[00:33:10] <icee> as in, we might replace the protocol, or work on the pico drivers some.. but for the 1 axis case it will be compatible for testing
[00:33:52] <icee> i guess for our 'abbreviated' register map we could just use the two least significant bytes of the count
[00:34:22] <icee> that's worth a 15% performance improvement in number of parallel port cycles
[00:34:58] <icee> it sure makes things worse if something bad happens for a second and EMC stops updating and then resumes
[00:35:08] <lerman> I'm having trouble understanding (as in I don't) how one relates the update rate and resolution to the count rate.
[00:35:34] <icee> l: let's say you have an 8 bit counter.
[00:35:52] <icee> if you are updating, and the counter moves less than 128 in either direction
[00:35:59] <icee> it's obvious to see which direction and how far the thing rotated
[00:36:09] <icee> if it moved more than 128 counts, there's ambiguity.
[00:36:32] <lerman> If EMC stops updating and resumes, you should be able to detect a counter overflow by keeping track of the last time it was read.
[00:37:01] <icee> yah, but keeping track of such things costs cycles on the microcontrollers.
[00:37:22] <lerman> Yes, I know that -- I thought you were talking earlier about the output (PWM) resolution and update reate.
[00:37:29] <icee> Basically, all I am doing is whenever there's a parallel port address cycle, it will reset a timer
[00:37:58] <icee> l: no, our effective resolution only has to do with the resolution with which we can measure the current levels. our pwm resolution is much greater
[00:38:26] <icee> l: we can get a little more resolution than our quality of measurement of current, because we can dither current levels and because we have control of phase angle
[00:38:39] <lerman> Ah... I understand now.
[00:38:40] <icee> if the timer expires, we'll e-stop.
[00:38:48] <icee> still, even in that case, it would be nice to preserve machine position
[00:39:50] <fenn> yes please dont make me re-home every time emc misses a cycle
[00:40:22] <icee> fenn: well, hopefully EMC will be able to keep above the 1KHz reliably which this will demand to keep functioning
[00:40:37] <icee> how far above 1KHz it can reliably do will control how aggressively you can set PID gains and accelerations
[00:40:48] <icee> (more so for large, fast machines)
[00:41:56] <fenn> so i'm looking at the PIC16Fxx chips, and they use 8 bit a/d converters, so i wouldn't need 2 bytes of output right?
[00:42:15] <fenn> since i can't sense the current more accurately than 8 bits
[00:42:17] <lerman> Apropos the previous discussion, you could always move the PID and rest of the control loop onto the controller.
[00:42:34] <icee> f: do the PIC16F* have a hardware quadrature decoder?
[00:42:43] <fenn> no
[00:42:49] <icee> f: it sure is a nice thing to have.
[00:43:03] <icee> with hardware filters, etc.
[00:43:41] <icee> and anyways, even if you have lower requirements, i'd urge you to still use our protocol and preferably our boards and designs
[00:44:04] <fenn> this is for a brushed servo controller
[00:44:14] <icee> there's a big advantage to us pooling our efforts in driver writing, the controller software, the maturity of the board
[00:44:23] <icee> f: OK, so use our board, but with a different amplifier and slightly different software
[00:44:48] <icee> you'd just basically null out the sine table stuff
[00:45:13] <fenn> why does it matter what's on the board if i'm using the same protocol?
[00:45:33] <fenn> say you have 2 brushless motors and 2 brushed motors
[00:45:38] <fenn> and the plug into the same bus
[00:45:39] <icee> it doesn't, really; but there's an advantage if we have multiple eyes looking at everything
[00:46:00] <fenn> i really am coming at this with zero experience
[00:46:04] <icee> yah, that should work fine, other than with perhaps parallel port loading
[00:46:13] <icee> fenn: so, leverage our experience, and use our board.
[00:46:23] <fenn> my previous digital circuit experience is a binary counter
[00:46:33] <icee> I'd like it if our board could drive brushed servos, and it should be easy to write that software
[00:46:40] <fenn> i need to learn how to do this stuff on my own
[00:47:15] <fenn> your board could easily drive brushed servos
[00:47:17] <fenn> but it's overkill
[00:47:29] <fenn> and the price reflects that
[00:47:36] <fenn> and it adds up quick if you have 6 axes
[00:47:45] <fenn> i'm trying to build a small cheap hexapod system
[00:47:57] <icee> most of the price is in 4 layers, the perimeter area for the connectors, and all the protection on the i/o's
[00:48:09] <icee> the difference in price for the microcontrollers themselves is small.
[00:48:45] <fenn> this is a 4 layer board??
[00:49:03] <icee> resilience to noise and safety from EMI is a good thing
[00:50:21] <fenn> i will build my single sided, 8-bit, pic-based board, and when i can afford it, i will attempt your design
[00:50:26] <icee> f: if you really want to go cheap, you ought to use a CPLD; that way you can get quadrature decoding
[00:51:49] <icee> f: OK.. well, pay particular attention to how the analog inputs are isolated, the TVS parts (SP720), the differential hookups for the decoder
[00:52:00] <icee> and if you're dealing with anything with any significant mass, make sure you have a robust emergency stop system
[00:52:35] <icee> also note what i'm doing with the WAIT signal on the EPP
[00:52:49] <fenn> any suggestions on where to start with cpld's? (never heard of a cpld before)
[00:52:49] <icee> because that's kinda tricky.
[00:53:10] <icee> f: learn a HDL (I like VHDL) and download the xilinx foundation ISE stuff.
[00:53:49] <icee> i'd think in xilinx's little PLCC parts you could fit a quadrature decoder with filter, and a few pwm generators with deadtime. maybe even enough for 2 axes.
[00:54:10] <icee> 2 axes brushed, that is.
[00:54:21] <fenn> vhdl is like spice?
[00:54:23] <icee> a CPLD is pretty much a simpler FPGA, without external config memory
[00:54:35] <icee> hardware description languages are ways you design digital logic
[00:55:02] <icee> it's like a programming language but most everytihng happens in parallel
[00:55:14] <fenn> how does this help me understand microcontrollers?
[00:55:25] <icee> it doesn't. it helps you understand digital logic ;)
[00:55:40] <icee> and how things like microcontrollers and microcontroller peripherals are designed
[00:55:56] <icee> fenn: how are you planning on doing the quadrature decoding?
[00:56:21] <fenn> i hadn't really figured that out yet
[00:56:38] <icee> f: how many mips are you going to have on your part?
[00:57:05] <icee> because if you're planning on like.. having an interrupt handler per quadrature edge, that's going to be 10-30 cycles per encoder count
[00:59:25] <fenn> ok so 10Mips
[01:00:18] <icee> so 100% cycles doing encoder work will let you handle up to 300,000 edge counts/second
[01:01:22] <icee> or 2500RPM; you'll obviously have to be doing other things, like responding to hte parallel port quickly, so that's going to top you out at 1200RPM or so
[01:01:23] <icee> acceptable?
[01:02:27] <fenn> the motors i've got have 500 counts/rev encoders
[01:02:45] <icee> the fastest flash parts are 5 mips, btw
[01:02:52] <icee> in 16F
[01:03:10] <fenn> hmm it said 100 ns instruction time, i assumed that was equivalent to 10mips
[01:03:22] <icee> was that 16C?
[01:03:41] <lerman> Once upon a time, I looked at using an attiny13 processor to do conversion from quadrature encoder to up/down counts. That's a $2 chip that runs 20mips with 8 pins. You could use one of them as a front end to the "main" processor.
[01:04:17] <icee> yah, that's another thing fenn
[01:04:26] <icee> you should use atmel parts, not microchip parts if you can get away with it
[01:04:34] <icee> only reason i'm using the dspic is the quadrature decoder
[01:04:45] <icee> they are much, much, much nicer to deal with.
[01:04:53] <fenn> why is that?
[01:05:24] <icee> f: the programming of the parts is simpler, the peripherals are better designed.. you can target them with gcc without engaging in black magic
[01:05:50] <icee> there's good open source collections of headers (avr libc, etc)
[01:06:36] <icee> and perhaps as a best item
[01:06:43] <icee> no weird messed up bulletins like this:
[01:06:53] <lerman> Free development tools on Windoze or Linux.
[01:07:06] <icee> (spam:)
[01:07:06] <icee> In some cases, depending on the revision of the MPLAB ICD 2 and the
[01:07:06] <icee> dsPIC30 DSC device, a crosstalk problem may exist when the device is
[01:07:06] <icee> being programmed. Due to the locations of the PGC and PGD pins,
[01:07:06] <icee> crosstalk may degrade the signal and cause the MPLAB ICD 2 to fail
[01:07:06] <icee> programming of the target device. To correct this, try the following:
[01:07:08] <icee> 1. Construct a RJ12 modular cable and replace the 15-inch cable
[01:07:10] <icee> that comes with the MPLAB ICD 2. Keep the length as short as
[01:07:12] <icee> possible, preferably under 6 inches. Also, remove the jacket from
[01:07:14] <icee> the cable, so that the conductors are far apart from each other
[01:07:16] <icee> (especially the PGC and PGD signals). The standard MPLAB
[01:07:18] <icee> ICD2 modular cable is wired as shown in Figure1-2, that is, RJ12
[01:07:20] <icee> pin 1 on one end connects to RJ12 pin 6 on the other end. This
[01:07:22] <icee> solves the problem in nearly all cases.
[01:07:41] <icee> 'remove the jacket from the cable, and spread out the conductors, because the drivers in our parts are too strong for the programmers we make to deal with the crosstalk'
[01:08:09] <lerman> Using atmel products solves the problem in ALL cases.
[01:08:45] <fenn> that's because the atmel sinks less current right?
[01:09:05] <icee> fenn: atmels source/sink 20mA on the i/os
[01:09:23] <icee> well, -most- parts do. as always, trust the data sheet
[01:10:04] <icee> microchip designed both their programmer and the structure of their parts input/output buffers with respect to noise
[01:10:16] <icee> hence all these weird suggestions about filter network on digital pins and things from the enthusiast community
[01:10:27] <icee> er badly with respect to noise
[01:10:53] <fenn> i hadn't seen any of that yet
[01:10:55] <icee> f: the attiny26 is only $2.50, runs at 16MHz which is almost 16 mips
[01:11:19] <icee> lawrenceg and I are both pretty experienced doing digital design, and we're having a hell of a time just trying to program the dspic
[01:12:06] <icee> and in #robotics people are always coming in complaining that their microchip programmer or their homebrew programmer doesn't work with PICs
[01:12:17] <fenn> just to make sure, i need 8 data i/o, 2 quadrature, 2 limits, 1 home, 1 fault, 1 a/d, and 2 pwm's right?
[01:12:35] <icee> fenn: I have one global fault line on my board
[01:12:37] <lerman> icee: So, if the reason you are using the dspic is for the quadrature encoder, why aren't you using an external one (say a cpld design)?
[01:12:40] <icee> you need 8 data i/o plus 4 signals i think
[01:13:03] <icee> lerman: because onboard peripherals are nicer, and if we had to talk to the CPLD that would have overhead in pin count
[01:13:33] <fenn> why the hell do you need a cpld to decode quadrature?
[01:13:54] <icee> f: having a digital filter is very nice.
[01:13:57] <fenn> isn't there a simple hardware circuit, like a 555 and a flipflop or something?
[01:14:02] <icee> how are you going to deal with glitches/noise?
[01:14:32] <icee> f: a CPLD is probably cheaper than trying to use discrete parts to do it
[01:14:41] <icee> and is certainly smaller in board area.
[01:15:05] <icee> and I've decoded quadrature on microcontrollers before.. it is a pain and easy to screw up.
[01:15:42] <lerman> But I'll bet it's just as easy to screw up in a CPLD.
[01:16:04] <icee> l: oh, it's probably easier to screw up in a CPLD. but at least you can fix it in a CPLD
[01:16:14] <icee> on a micro, you may not have the capabilities with your board layout to get the results you want
[01:16:35] <icee> you might not have enough cycles left over, or enough filtering, or whatever, and you just lose.
[01:16:40] <lerman> OTOH, that's a good argument for using a chip w built in quadrature decoder.
[01:17:11] <icee> l: yah.. and since we need a microcontroller (to hold sine tables, etc) the dspic was an easy choice
[01:17:27] <lerman> What type of digital filtering is commonly used in a quad decoder?
[01:17:28] <icee> the only other option was an FPGA, but acceptable FPGAs come in nasty packages and require level conversion
[01:17:55] <icee> l: you can require a quadrature settle to a new value for at least N cycles before you count the transition
[01:18:02] <icee> N clock cycles
[01:18:21] <icee> so bouncing, glitches from supply noise, etc don't matter
[01:18:58] <icee> if you do the obvious thing to decode quadrature in a microcontroller-- put an interrupt on one signal, and then sample the other signal for direction
[01:19:21] <icee> if the encoder goes from position 0->1, and an interrupt fires, and then back to 0 before your interrupt is serviced, you're screwed unless you're very careful
[01:19:36] <lerman> No, no, no. (As I'm sure you know) That's just plain wrong.
[01:19:53] <icee> yah.
[01:20:08] <fenn> what if you debounce the raw quadrature signals with an external chip
[01:20:32] <icee> but doing it right is relatively expensive in cycles, and strictly limits the maximum time you can disable interrupts
[01:20:41] <lerman> f: a glitch is not the same as a bounce.
[01:21:09] <icee> well, a schmitt trigger comparator with the right filter network can clean things up a lot.
[01:21:19] <icee> and the circuit i built in my board design does a -little-
[01:21:39] <lerman> One of these days, I'll have to write the code for the attiny13 and see how fast I can do the conversion from quad to up/down.
[01:21:51] <icee> (bottom of page 5,
http://lyle.org/~mlyle/servoctrl.pdf )
[01:22:15] <icee> l: well, then you wouldn't deal with interrupts, you'd probably just infinite loop, right?
[01:23:12] <lerman> Yup.
[01:23:28] <fenn> isn't that totally useless then?
[01:23:34] <lerman> What did I just look at -- bottom of page 5.
[01:23:42] <icee> f: you need to deal well with all 3 cases; glitches, a signal bouncing, and when the encoder is 'jittering' between two output values
[01:23:52] <icee> l: that's how the encoders are hooked up to m yservo control board
[01:24:11] <icee> differential signals in, through RC and bias circuits, to a RS-422 receiver (max3095), off page to quadrature decoder on micro
[01:24:28] <icee> f: isn't what totally useless?
[01:24:39] <fenn> a micro that can't do any interrupts
[01:24:41] <lerman> Jitter is easy if you permit hysteresis of one count -- and impossible if you don't.
[01:24:54] <icee> f: if all it is doing is one task, writing it without interrupts is better.
[01:24:57] <icee> it's more performant
[01:25:08] <fenn> but what is it going to write to?
[01:25:09] <lerman> icee said it.
[01:25:28] <icee> f: output pins on the microcontroller, or a SPI, or whatever
[01:26:02] <icee> f: polling is unpopular these days, but it's often the best way to deal with real world systems
[01:26:04] <lerman> It reads from the encoder and outputs to two single bit ports. one is a count up signal; the other a count down signal.
[01:26:18] <icee> you just.. need to know what you're doing
[01:26:50] <lerman> Polling is the way to go for a processor dedicated to a single simple task (or even a single not so simple one).
[01:28:01] <icee> l: or for several hard-realtime tasks, when you can tightly bound the runtime for each
[01:28:47] <lerman> Yes.
[01:28:49] <icee> l: e.g. adding something to your quadrature decoding loop, to check whether the SPI has finished writing, and if so, to provide another character..
[01:30:05] <fenn> this is too much for poor old fenn
[01:30:31] <icee> fenn: before you go too much farther, come up with a cycle budget
[01:30:46] <icee> of the things you need to do, the rates you need to do them at, and how long you think they'll take
[01:31:09] <fenn> how long does it take to read an a/d? 1 cycle? 100 cycles?
[01:31:12] <icee> and since this is an early system, and some of the things-- the quadrature decoding, or responding to parallel port requests-- are time critical.. allow significant safety margin
[01:31:20] <lerman> Even a bad guess is better than no estimate.
[01:31:29] <icee> f: it probably takes 3-4 cycles to start the conversion.. then a lot of wall clock time
[01:31:39] <icee> then 3-4 cycles to read the result out. more if you do it in an interrupt.
[01:32:11] <fenn> will i need to use interrupts to talk to the parallel port?
[01:32:26] <icee> I'm not using them.
[01:32:56] <icee> here's the thing, though-- you have less than 10 microseconds from when the strobe goes low on the data port to deal with the request, assert wait, and deassert it
[01:33:17] <lerman> A recent system I worked on ran almost everything off a 1 msed interrupt. At each interrupt, it read the result of the last A/D conversion and started the next one.
[01:33:29] <icee> at 5 MIPs, that's 50 instructions
[01:34:28] <lerman> icee: So, if you didn't use interrupts for the parallel port, you had better not do much in any interrupt handlers you do have.
[01:34:30] <icee> that's what i'm talking about with cycles btw. instruction cycles
[01:34:42] <icee> l: well, I have 20MIPs to play with
[01:34:49] <icee> but yah, i'm not going to.
[01:36:07] <fenn> so what does that mean? i have to do everything in 50 cycles?
[01:36:30] <fenn> i have to do stuff, and check the data line every 50 cycles?
[01:36:35] <fenn> then do more stuff.
[01:36:46] <icee> f: you have 50 cycles from when the computer asserts a strobe to finish responding to it
[01:37:00] <lerman> f: yes, it means that you have to break things into 50 cycle hunks.
[01:37:06] <icee> so if it takes you 20 cycles to respond to it (optimistic), you must check at least every 30 cycles
[01:37:23] <icee> or, you can use an interrupt, but then you're incurring the cost of the interrupt firing
[01:37:46] <icee> and it means that any code that is running may be delayed by up to 30 cycles
[01:37:53] <lerman> icee: you didn't say whether you really like the idea of using the parallel port. I suspect it's the worse choice except for all the others.
[01:37:55] <fenn> i had no idea this stuff was so tight
[01:38:05] <icee> l: well, EPP is pretty nice.
[01:38:36] <icee> l: I don't love the parallel port, but.. existing drivers on the PC side, etc, makes it a slam dunk choice
[01:39:56] <icee> f: I'm a little concerned by it even on the dspic parts, to be honest
[01:40:22] <icee> i'll be a lot happier once one of us (LG or I) sees it working
[01:41:04] <icee> f: what you're talking about doing, at the count rates you should see, etc
[01:41:09] <icee> isn't impossible, but it's very borderline
[01:41:21] <icee> on an atmel part you'd have a lot more margin
[01:41:50] <icee> oh, btw.
[01:41:57] <icee> you don't have a multiplier, on 16F, right?
[01:42:09] <icee> that really pretty much rules out running a PID or PI control loop on current levels
[01:42:26] <fenn> i was just going to compare commanded and sensed
[01:42:50] <fenn> crap
[01:45:15] <fenn> how do you implement a pwm on a microcontroller?
[01:45:25] <icee> preferably using a timer
[01:45:30] <icee> with output compares
[01:45:54] <icee> you program the output compare registers, and the PWM line is low during the time the timer is less than the output compare reg.
[01:46:26] <icee> the DSPIC makes it nice and easy for us to generate nice PWM for h-bridges, because it is set up to create complementary signals with dead time
[01:48:01] <fenn> i think my brain just quit.. bbiaf
[01:53:03] <lerman> Well, folks, I'm calling it a night. Thanks for "talking". Ken
[01:53:19] <icee> ;)
[01:53:21] <icee> g'nite lerman
[02:10:43] <fenn> whew
[02:12:10] <fenn> do you really have to keep everything in your head at the same time? or can you break it up into manageable smaller tasks?
[02:14:37] <Jymmm> * Jymmm hands fenn a "Compact Brain Flash" card =)
[02:15:11] <fenn> jymmm are you reading this stuff? i have to do everything in 30 instruction hunks!
[02:15:38] <Jymmm> fenn: Nope (I'm a lil smarter than that =)
[02:15:53] <Jymmm> * Jymmm chuckles
[02:56:28] <Jymmm> Just FYI...
http://www.plasticsmag.com/routing.asp?fIssue=Jan/Feb-05&aid=4139
[03:04:13] <markwayne> hello
[03:04:29] <fenn> hi
[03:04:42] <markwayne> oh it works
[03:04:59] <fenn> look! look! it's twitching! poke it again!
[03:05:10] <markwayne> :)
[03:05:38] <markwayne> just setting up a irc client
[03:05:55] <markwayne> mozz chat
[03:06:44] <fenn> * fenn likes xchat
[03:07:45] <Jymmm> fenn: REMOVE THE BARE ELECTRICAL WIRES FROM YOUR FLESH!
[03:08:15] <fenn> now now, i can do whatever i like with these wires
[03:08:26] <markwayne> windoz firefox plugin
[03:08:33] <fenn> besides, how else am i going to use your "compact brain flash" card?
[03:09:01] <Jymmm> fenn: It's flash... no electricity needed - built in solar cell
[03:09:33] <fenn> it runs on brain power right
[03:09:57] <fenn> markwayne: we actually do talk about cnc stuff, believe it or not
[03:10:18] <markwayne> ok yea I used to get on the years ago
[03:10:42] <markwayne> what happened to paul btw
[03:11:07] <fenn> he seems to have lost interest.. :(
[03:11:20] <fenn> must be a lady
[03:11:53] <markwayne> commerical interested pressing maybe
[03:12:37] <markwayne> that last BDI build thrash was enough to make a saint cuss
[03:13:05] <markwayne> so I can understand
[03:15:17] <fenn> jymmm why are you using downcut bits?
[03:15:58] <Jymmm> fenn: I'm using downcut in wood, not plastic
[03:16:18] <fenn> to keep it from splintering?
[03:16:54] <Jymmm> fenn: Ah, no. Talked to Les... He said when doing cnc routing it can actually be very dangerous not to use downcut.
[03:17:19] <fenn> why?
[03:17:22] <markwayne> how do you keep the chips from building up in the kerf
[03:17:39] <Jymmm> fenn: as upcut bits cn pull the material out ooff the table - plus no surface splitering as well.
[03:18:02] <Jymmm> markwayne: the "fna" on the router blows them out.
[03:18:12] <markwayne> fan
[03:18:19] <markwayne> ahh
[03:19:02] <Jymmm> Now... Using a 1/8" downcut full plung into 3/4" material is another story... they pack into the void BIG time =)
[03:19:58] <markwayne> but 3/4 is heavy and is less likey to lift off the table
[03:20:24] <Jymmm> not really =)
[03:21:04] <Jymmm> Another thing is I trust Les. If he has a reason for saying to do something a certain way, I dont question it other than to understand why.
[03:21:24] <fenn> i always question everything to understand why
[03:21:41] <Jymmm> fenn: Why?
[03:21:42] <fenn> unless i feel like i am being annoying
[03:22:37] <fenn> it's the best way to learn, and it generally exposes if the other person doesn't know what they are talking about
[03:22:58] <fenn> blind faith is for lemmings
[03:24:18] <fenn> i wonder if emc supports constant feed/rev mode...
[03:31:57] <markwayne> like threading :)
[03:32:04] <fenn> yep
[03:32:17] <fenn> threading support is kinda up in the air still, from what i've heard
[03:32:36] <fenn> but some progress has been made since the mazak retrofit
[03:33:00] <fenn> i guess
[03:36:18] <markwayne> one thing at a time is a good policy
[03:36:43] <markwayne> mill then lathe
[03:37:10] <fenn> they needed to be able to orient the spindle in order to do tool changes
[03:37:36] <fenn> so some code was put in to control the position of a spindle, and voila
[03:38:34] <fenn> i think icee thrashed my brain pretty good.. nothing i say sounds correct anymore
[03:41:24] <markwayne> well you have to encode the spindle any way
[03:41:47] <fenn> a tachometer works pretty well for most app's
[03:42:06] <markwayne> spindle orient is sometimes done with machinical widgets
[03:43:59] <fenn> should I be concerned with toxic gases coming off of PVC plastic while cnc routing?
[03:44:09] <markwayne> you need a index pluse at least
[03:44:25] <markwayne> you feel dizzy?
[03:44:38] <fenn> i havent done any yet actually
[03:46:51] <Jymmm> fenn: Yes... PVC produces HCL
[03:47:14] <Jymmm> hydrpchloric acid
[03:47:21] <Jymmm> hydrochloric acid
[03:49:30] <Jymmm> fenn: Acrylic, ABS, PP, PET, HDPE and safe to machine, PVC, CPVC, or any other polmer that has 'chrlo' in it's name should be avoided for machining or burning.
[03:50:07] <fenn> what am i gonna do with all these .5" sheets of pvc i found? :)
[03:50:23] <Jymmm> fenn: Acrylic, ABS, PP, PET, HDPE and safe to machine. PVC, CPVC, or any other polymer that has 'chrlo' in it's name should be avoided for machining or burning.
[03:50:30] <Jymmm> are yousure it's PVC ?
[03:50:50] <fenn> it's gray, and smells really bad when you cut it
[03:51:00] <Jymmm> could be ABS
[03:51:07] <fenn> actually it only smells bad on the chop saw, lathe turning doesnt smell
[03:51:28] <Jymmm> chop saw?! not for plastic
[03:51:34] <fenn> er, miter saw i mean
[03:51:46] <fenn> 80 tooth carbide alternate top bevel
[03:52:11] <Jymmm> sounds right, I have/use a 60T
[03:52:33] <fenn> abrasive chop saws are stupid
[03:53:01] <Jymmm> nope... good for glass and dense metals
[03:53:28] <Jymmm> or rock (brick, etc)
[03:54:13] <fenn> there's one in my shop and it stinks like hell, is inaccurate, leaves a wicked sharp burr on every cut, and burns the snot out of everything
[03:54:27] <fenn> and it's really loud and gets grit everywhere and cuts out the power
[03:54:35] <fenn> i mean trips the breaker
[03:54:50] <Jymmm> lol, toss it my way if you dont want it =)
[03:54:57] <fenn> it's not mine :P
[03:55:41] <Jymmm> If I keep this up I'll have every saw I'll ever need and not every actually buy one =)
[04:01:06] <Jymmm> though, I have had to replace the blades =)
[04:01:20] <fenn> who gave you a saw?
[04:01:50] <Jymmm> everybody
[04:02:17] <Jymmm> jigsaw, compound mitersaw, tablesaw, radial arm saw
[04:02:51] <fenn> i have to make do with HF crap
[04:02:55] <fenn> oh well
[04:03:40] <Jymmm> well, these arent' all in the best of shape... some rebuilding is needed
[04:04:20] <Jymmm> the HF bandsaw isn't too shabby at all though.
[04:04:27] <fenn> no?
[04:04:39] <Jymmm> That's what I've been told by lots of folks
[04:04:41] <fenn> i've heard it's a good deal for the money, but it's a piece of crap nonetheless
[04:04:44] <Jymmm> jest a sec...
[04:05:39] <Jymmm> goes on sale for $150 every so often...
http://www.harborfreight.com/cpi/ctaf/Displayitem.taf?itemnumber=37151
[04:05:57] <Jymmm> I have been told that you DO need to buy a good bi-metal blade though.
[04:06:10] <Jymmm> the one that comes with it is crap.
[04:20:04] <Jymmm> fenn: Didn't you order some headphones from HF ?
[04:20:16] <fenn> yeah they are really nice
[04:20:31] <fenn> the sound cuts out at too low of a level though
[04:20:37] <Jymmm> I have a big head... are they REALLY adjustable?
[04:20:43] <fenn> no they arent adjustable at all
[04:21:04] <Jymmm> bummer, ear plugs are inconvienant
[04:21:11] <fenn> they are kinda tight.. not something you would want to wear for 8 hours
[04:21:25] <Jymmm> ah, ok. nm. good to know though
[04:21:27] <fenn> might be able to adjust it by bending the metal
[04:21:41] <Jymmm> I suspect the cups are small though
[04:21:47] <fenn> it's just a metal spring headband
[04:22:20] <fenn> hmm actually it is adjustable a little bit
[04:22:34] <fenn> but you can't adjust the clamping pressure, only the distance from the top of the head to the ears
[04:22:52] <fenn> i could take a picture if you like
[04:23:02] <Jymmm> sure, but no rush
[04:32:40] <fenn> Jymmm:
http://fenn.freeshell.org/camera/DCP_0588.JPG also 589 and 590
[04:36:06] <fenn> try 590 again if it messed up
[04:36:24] <fenn> anyway it's worth $15 if you dont have any decent earmuffs
[04:36:45] <Jymmm> fenn: ok, cool. if they have them in the store I'll check em out.
[04:37:11] <fenn> i want to hack them to receive am/fm and then get an fm broadcaster for my computer
[04:37:21] <Jymmm> lol
[04:38:00] <Jymmm> I wouldn't want to be distracted like that when I'm wearing them.
[07:50:40] <fenn> why are people on cnc zone so fuckking dumb!?!?!
[08:02:20] <fenn> of course, the only helpful post was by lerman :\
[09:07:06] <fenn> i am thinking 2 chips per servo.. one chip reads the encoders, the other does PWM; both chips talk EPP
[09:07:32] <Jacky^afk> Jacky^afk is now known as Jacky^
[09:07:49] <fenn> sounds a lot easier than mixing polling and interrupts
[09:07:51] <Jacky^> morning
[09:07:54] <fenn> morning
[09:08:08] <fenn> Jacky^: just got my brain blasted into oblivion
[09:08:15] <Jacky^> :)
[09:08:30] <Jacky^> yesterday i pasted an url for you
[09:08:36] <fenn> what about?
[09:08:41] <Jacky^> probably you already know ..
[09:08:49] <Jacky^> about pics and servos
[09:09:14] <fenn> i think i missed that
[09:09:37] <Jacky^> http://www.jrkerr.com/icproducts.html
[09:09:46] <Jacky^> i found it tome ago ..
[09:10:07] <Jacky^> it seems the simplest way to get servo up and running
[09:10:26] <fenn> it's just a chip!
[09:10:29] <Jacky^> maybe in the software section of website there's the source code
[09:10:47] <Jacky^> yes, just a chip ..
[09:10:54] <fenn> anyway i dont need all that, emc already does PID and trajectory planning
[09:11:25] <Jacky^> emc2 have hal encoder comp. too ..
[09:11:39] <Jacky^> but i dont think work great
[09:11:50] <Jacky^> i mean as rpm/min it can do
[09:11:57] <Jacky^> count
[09:12:19] <Jacky^> will be a bit slow..
[09:12:35] <fenn> you mean run the quadrature pulses into the parallel port??
[09:12:46] <Jacky^> yeah,
[09:13:00] <fenn> yeah that's too slow and too many pins too
[09:13:36] <Jacky^> so, you wnat to use a pic for it ?
[09:14:04] <Jacky^> would be a good idea, i think
[09:14:14] <fenn> i've been told avr's are much easier to use
[09:14:53] <Jacky^> good
[09:14:54] <fenn> more peripherals come standard, easier to program, faster chips, etc
[09:16:29] <Jacky^> nice
[09:16:36] <fenn> this all seems kinda ridiculous for a first electronics project
[09:16:52] <Jacky^> :)
[09:16:54] <fenn> like i should be making a blinking led first or something
[09:16:56] <Jacky^> why ?
[09:17:04] <Jacky^> hahaha
[09:17:07] <Jacky^> nah ..
[09:17:16] <fenn> i'm still confused about why ttl is 50ma
[09:17:26] <fenn> like, how do you get more than 50 ma?
[09:17:31] <Jacky^> btw, i heard someone here around was working on that ..
[09:17:49] <fenn> a blinking led is a good way to know you programmed the micro right
[09:17:54] <Jacky^> maybe icee, or some other, can't remember
[09:18:05] <fenn> i think lawrenceG was working on that
[09:18:09] <Jacky^> ask all before start
[09:18:13] <Jacky^> yeah ..
[09:21:21] <fenn> hmmm saturday and still no volunteers for a vote counter
[09:21:36] <fenn> maybe i will blast off a message to my LUG and see if anyone volunteers
[09:32:47] <fenn> the mystical white bear emerges from the bamboo thicket at dawn...
[09:34:17] <fenn> O great spirit, bless this servo driver design! May the other chip programmers be free from envy!
[09:35:47] <fenn> May the winds be always at their back, and high in negative ion concentration.
[09:38:13] <shirokuma> the world would be much more positive if the ions wouldn't be so negative
[09:38:47] <fenn> no, no, you've got it all backwards..
http://tinyurl.com/b2fzr
[10:49:18] <fenn> an APT interpreter... mmmm... it makes me all warm and fuzzy just thinking about it
[10:52:35] <fenn> would be especially sexy with good preview functions for Axis
[12:13:21] <alex_joni> morning
[14:21:15] <alex_joni_> alex_joni_ is now known as alex_joni
[14:32:33] <CIA-6> 03alex_joni * 10emc2/src/emc/usr_intf/iosh.cc: commented out savaToolTable, not used caused a warning
[14:49:58] <CIA-6> 03alex_joni * 10emc2/docs/AUTHORS: added names to AUTHORS, please add your name here if you submit code to emc2
[15:17:40] <Jacky^> hi Jymmm
[15:17:46] <Jacky^> morning
[15:17:57] <Jymmm> mornin
[15:21:23] <CIA-6> 03alex_joni * 10emc2/directory.map: clean up and bring up to date
[15:28:28] <CIA-6> 03alex_joni * 10emc2/src/emc/hal_intf/ (Makefile exthalmot.c extintf.h): removed obsolete hal_intf files
[15:40:37] <Jacky^> * Jacky^ play /home/jack/KC and sunshine band.mp3 :P
[15:41:12] <alex_joni> play /home/jack/The sound of silence.mp3
[15:41:21] <Jacky^> hehe alexxxx
[15:41:28] <Jacky^> hard working ? :P
[15:41:33] <Jacky^> i know ..
[15:41:50] <Jacky^> thats all work maded in the week :P
[15:42:02] <alex_joni> http://bash.org/?top
[15:42:10] <Jacky^> :)
[15:42:31] <Jacky^> good
[15:43:04] <Jacky^> i'm helping my daughter to get bluetooth working on his debian
[15:43:19] <Jacky^> but have a lot of upgrade.. 145 mb :/
[15:43:59] <Jacky^> we are using 4 mbit dsl, but debian mirrors wont go up to 20-25 kbs
[15:44:08] <Jacky^> damn bandwith !
[15:44:11] <Jacky^> :D
[15:44:38] <Jacky^> 88% [259 xlibmesa-dri 27832/5709kB 0%] 29,0kB/s 9m23s
[15:44:42] <Jacky^> :(
[15:47:37] <CIA-6> 03alex_joni * 10emc2/src/emc/Makefile: removed hal_intf from the Makefile
[16:04:36] <alex_joni> just type /quit whoever, and it'll quit them from irc
[16:05:13] <Jacky^> ?
[16:05:35] <alex_joni> try it :P
[16:06:54] <alex_joni> ROFL
[16:07:52] <emclogg3r> cool :P
[16:08:06] <emclogg3r> emclogg3r is now known as Jacky^
[16:08:29] <alex_joni> can't believe this still works :))
[16:08:31] <alex_joni> wb
[16:08:36] <Jacky^> :)
[16:08:39] <Jacky^> it work
[16:18:55] <Jymmm> les_w !!!
[16:19:06] <les_w> hi jymmm
[16:19:17] <les_w> got some mail...thanks!!!
[16:19:25] <Jymmm> les_w ah, very cool =)
[16:19:31] <Jacky^> hi les
[16:19:35] <les_w> i'll say
[16:19:39] <les_w> hi jacky
[16:19:40] <Jymmm> lol
[16:19:56] <Jymmm> brb... coffee
[16:19:59] <les_w> k
[16:20:13] <les_w> had to work a little this morning
[16:20:52] <les_w> getting ready for the corporate suits...they are coming next week
[16:27:49] <Jymmm> les_w sounds like fun
[16:27:54] <Jymmm> (not)
[16:28:16] <les_w> well I need to make sure the funding keeps rolling in
[16:28:51] <les_w> But I hope to get a little break after the meeting
[16:28:54] <rayh> Just make the check out to rayh.
[16:29:01] <les_w> haha
[16:29:24] <les_w> break= setting up the new spindle and getting the turkey stuff going
[16:29:27] <Jymmm> les_w: Heh.... too bad you dont have a REALLY old barn that have falling down (maybe your neighbor across the street), then setup some 1950's oscope, VOM, etc in there and watch them freak out as you tell them this is your lab.
[16:29:48] <les_w> not far from that
[16:30:05] <Jymmm> les_w: I mean with gaping holes that a horse coudl fit thru
[16:30:18] <Jymmm> straw on the ground, etc
[16:30:21] <les_w> using '70's vintage tektronix scopes
[16:30:47] <les_w> well, I am doubling the shop size.
[16:30:57] <les_w> sepearate tronics lab
[16:31:03] <les_w> spray booth
[16:31:13] <les_w> and metal shop
[16:31:34] <les_w> the machines start rolling in right after this meeting
[16:31:37] <alex_joni> CNC_Workshop, petev
[16:31:42] <Jymmm> les_w: I mean like this -->
http://www.kumeyaay.info/santa_catarina/SantaCatarinai/Old_Shack.jpg
[16:31:43] <alex_joni> darn.. wrong channel
[16:32:19] <Jymmm> les_w or this -->
http://www.magicravenphotography.com/Ballarat,%20%20Old%20Adobe%20Shack.jpg
[16:33:11] <les_w> you have been snoopin around taking pictures of my house again...
[16:33:31] <Jymmm> les_w: Well, I reserved the best for last =)
[16:33:55] <les_w> anyway...I have a big tax liability this year ...REAL big. It's time to buy machines.
[16:34:27] <alex_joni> get some laser-hybrid welding stuff
[16:34:33] <alex_joni> very neat
[16:34:41] <alex_joni> 15kW+ lasers
[16:34:54] <les_w> I think I will get a plasma anyway
[16:35:00] <les_w> lasers are cool too
[16:35:02] <Jymmm> les_w get a laser engraver ~$24k
[16:35:04] <alex_joni> I'd suggest a microplasma too
[16:35:09] <les_w> built some laser tables before
[16:35:14] <les_w> 2kW
[16:35:14] <alex_joni> about <10k
[16:35:23] <Jymmm> les_w
http://www.oregonicons.com/oldshackpic.jpg
[16:35:59] <les_w> well, so far, some big woodworking tools...plasma, a VMC, a few other things
[16:36:37] <les_w> hey...my barn!
[16:37:11] <Jymmm> I do have a photo of a shack that the roof caved in as well, but not online.
[16:37:24] <les_w> I guess I will end up with something like Roland's place
[16:37:24] <Jymmm> (c) Jymmm
[16:37:29] <alex_joni> * alex_joni goes back to clening up...
[16:37:36] <les_w> He has a lot of space doesn't he ray?
[16:37:51] <alex_joni> les_w: maybe you'll host a fest for emc sometime? *wink*
[16:38:03] <les_w> haha sure
[16:38:17] <rayh> Quite a bit of space. More if he didn't have two giant G&L machines
[16:38:23] <les_w> We have had NIST here before
[16:38:45] <rayh> and a 20' travel grinder
[16:38:54] <les_w> I would like a setup like Roland's.
[16:39:10] <les_w> he must have 20,000 square feet or something
[16:40:06] <les_w> But I am at that point where I have to decide if I want to live at a factory or commute again.
[16:41:09] <Jymmm> Is it living at the factory, or just getting out of the house?
[16:41:46] <les_w> well, whether to build large facilities here on the property...
[16:41:59] <les_w> at some point I might have zoning problems
[16:42:06] <les_w> zoned agricultural
[16:42:08] <les_w> now
[16:42:29] <Jymmm> so, paint 'John Deer' on the side of the CNC Center you'll be getting.
[16:42:52] <les_w> exactly....or make the outside look like a barn
[16:42:58] <rayh> I'd like my factory to be about a mile or so through the woods.
[16:43:13] <Jymmm> rayh: factory or stiles?
[16:43:29] <rayh> Visited with a guy near Nashville who has his "rebreather diving stuff" in a barn.
[16:43:39] <les_w> a mile or so away would be good
[16:44:07] <rayh> As you walk home through the woods, you shed the day's work.
[16:44:30] <Jymmm> rayh: That sounds awesome
[16:44:38] <les_w> I think I ought to buy some close by land zoned business and put something up
[16:44:48] <les_w> something near 3 phase power
[16:44:49] <Jymmm> les_w brothel
[16:44:56] <les_w> Have to make my own here
[16:45:05] <rayh> Yep. I wouldn't have it at home if I had a choice.
[16:45:16] <rayh> I've worked with to many people who do.
[16:45:21] <les_w> right
[16:46:07] <les_w> Well I made the current shop "convertible"...It can become an apartment. Has full water and sewer hooked up
[16:47:10] <Jymmm> les_w: I'll move in next week =)
[16:47:19] <les_w> haha
[16:47:40] <Jymmm> most apt have w&d as perks, I'll have cnc machines!
[16:48:22] <les_w> I once new a guy who had a woodworking shop in his house
[16:48:37] <les_w> living room had band saws, etc in it
[16:48:41] <Jymmm> oh, I was playing with some acrylic last night... gonna have to really work on the chipload though.
[16:48:59] <Jymmm> les_w: I'm *ALMOST* that bad, but not quite.
[16:49:23] <les_w> acrylic is tough
[16:50:05] <Jymmm> I cranked the rpms to their lowest, but still had some crap using a router v bit. Gonna have to buy more tooling
[16:50:32] <Jymmm> I found this set of articles though.... very informative -->
http://www.plasticsmag.com/routing.asp?fIssue=Mar/Apr-03&aid=3751
[16:50:54] <Jymmm> I still dont understand what an "o" bit is
[16:51:27] <alex_joni> an "o" bit is an output bit, as opposed to an "i" bit which is an input bit
[16:52:04] <Jymmm> alex_joni "o" vs "v" (smartass)
[16:52:11] <Jymmm> brb... smoke
[16:52:20] <alex_joni> I don't know "v" bits (verbose? maybe?)
[16:52:33] <les_w> well back to the shop. Couple more hours. It is a nice warm fall day, so ought to go play 9 too.
[16:52:42] <les_w> not sure about an O bit
[16:53:06] <alex_joni> 9=18/2 ?
[16:55:27] <etla> golf is a dangerous addiction...
[16:56:17] <etla> a_j: do you know how upload and images work in the wiki ?
[16:57:06] <alex_joni> nope, last time I tried they didn't...
[16:57:09] <rayh> I think it was broken the last time I tried. SteveS is working on it.
[16:57:16] <etla> ok...
[16:57:37] <etla> I found a nice paper on double-jerk limited trajectory planning
[16:57:45] <alex_joni> how's it called?
[16:57:47] <etla> I'll try to implement it in matlab first
[16:57:58] <alex_joni> the file I mean..
[16:58:19] <etla> ? for the wiki ?
[16:58:46] <Jymmm> les_w: me neither but osburn mentions it too in their catalog
[16:58:55] <alex_joni> etla: the paper you found
[16:59:13] <etla> traj planning and feedworward design for high performance motion systems
[16:59:23] <etla> 2004 american control conference
[16:59:23] <alex_joni> and the file?
[16:59:31] <alex_joni> who wrote it?
[16:59:42] <etla> got it thru ieee explore...
[17:00:33] <alex_joni> I see... who wrote it?
[17:00:53] <Jymmm> les_w:
http://www.plasticrouting.com./article.asp?F_ID=18
[17:01:14] <etla> a_j: in scholar.google.com put "trajectory planning and feedforward design for high performance motion systems"
[17:01:26] <etla> it's about 7th in the list
[17:01:32] <alex_joni> yeah, but on the first page it should say who wrote it..
[17:01:53] <etla> labrechts, boerlage, steinbuch. eindhoven univ tech
[17:02:17] <alex_joni> ahh.. ok, never read it
[17:03:26] <etla> if I understand it welll enough I'll try to write somehting in matlab
[17:04:03] <alex_joni> * alex_joni read a few papers on traj planning
[17:04:15] <alex_joni> even understood some, but it would take too much time to do that
[17:05:32] <etla> do you know anything about the work cradek did with segmentque
[17:15:25] <alex_joni> he did some bugfixes
[17:25:04] <Jymmm> etla: Les has his own 9 holes in his backyard.
[17:25:53] <etla> jymm: oh, thats nice !
[17:26:56] <Jymmm> etla: Yep, just get 30 acres and a tractor and you can hove your own 9 holes too!
[18:09:59] <CIA-6> 03alex_joni * 10emc2/directory.map: more fixes to directory.map, also added install directories proposed
[18:18:07] <les_w> etla still there?
[18:19:12] <alex_joni> les_w: 9 holes that quick?
[18:19:16] <les_w> If you are reading about trajectory planners...it's a good thing. I't's a real problem with emc.
[18:19:46] <les_w> alex...not 9..2. Just a par 3 and 4 in the back.
[18:19:48] <les_w> wip
[18:20:00] <alex_joni> par 3?
[18:20:11] <les_w> well about 400 meters.
[18:20:12] <alex_joni> you need practice :D
[18:20:33] <alex_joni> 400 m - that's doable in a single shot
[18:20:49] <etla> les_w: I'm here, just doing some experimenting in matlab
[18:21:10] <les_w> sucked down a good paper from IEEE?
[18:21:21] <etla> traj planner requires solution of 3rd deg equation which I don't remember by heart... google is my friend
[18:21:44] <etla> yes, it's a conference paper with more or less a cookbook recipie for calculating trajectories
[18:22:05] <les_w> I have the solutions in an old college text
[18:22:43] <les_w> We have tried and tried and tried to improve the tp in emc.
[18:23:04] <etla> I think there are two separate issues
[18:23:25] <les_w> No one seems to be able to follow what's in there, so it's kind of hard to rewrite it
[18:23:31] <les_w> What issues?
[18:23:44] <etla> one is the trajectory of one simple move, i.e. G0X100, wether that is done as a trapezoidal move or something more fancy
[18:23:54] <etla> the other thing is blending, lookahead, G64
[18:24:19] <etla> the first one is in the paper I'm reading
[18:24:29] <les_w> well, in g64 emc has cubic subinterpolated trapezoidal
[18:24:41] <les_w> but the algo breaks down at high speed
[18:25:08] <les_w> a big problem is servo rate
[18:25:15] <etla> and there is no tolerance
[18:25:26] <etla> tell me more about servo rate!
[18:25:32] <les_w> It is just too slow for HSM
[18:25:40] <les_w> It's fine for hobby stuff
[18:26:08] <etla> where is the bottleneck
[18:26:10] <les_w> There seems to be a brick wall of about 400 microseconds
[18:26:20] <les_w> with any speed computer
[18:27:15] <les_w> it needs to be 5-10 times better for modern HSM
[18:27:56] <etla> so does linux/emc run on anything with that kind of update rate ?
[18:27:57] <lerman> les_w: the 400 microseconds is to do what?
[18:28:10] <les_w> etla, the bottlenck is user/RT comms acording to paul
[18:28:28] <les_w> 400 microseconds to update all the servos
[18:29:28] <lerman> And using a 2ghz machine isn't twice as fast as using a 1 ghz machine?
[18:29:36] <alex_joni> lerman: nope
[18:29:49] <les_w> ken, seemingly not.
[18:30:16] <les_w> even with a 150 MHz machine
[18:31:01] <les_w> although I have not run an actual servo loop in a 2 GHz machine to confirm this
[18:31:07] <lerman> I'd think that means we are memory speed limited. If the code and data don't stay in cache, the extra processor speed might not do any good.
[18:31:25] <les_w> I wish someone would give it a try
[18:31:53] <les_w> Paul suspects 200 MHz or 2 GHz...same speed.
[18:31:53] <lerman> So, one questions I have is do the RT extensions to Linux disable the cache for RT processes?
[18:32:53] <les_w> Not a programmer, but I would think it would have to. Statistical methods would seem to be of little or no use in hard RT
[18:32:56] <alex_joni> cache? which cache?
[18:33:25] <lerman> The processor (on chip) cache.
[18:34:19] <alex_joni> nope.. those are not accessible to be switched off
[18:34:27] <alex_joni> same goes for pipelines
[18:34:40] <alex_joni> that's why a 2GHz processor sucks for RT
[18:34:50] <les_w> hmm
[18:35:09] <alex_joni> because branch prediction & co .. are sometimes wrong :)
[18:35:29] <les_w> and my little dsp boards are getting <50 microseconds
[18:35:49] <Jacky^> :P
[18:36:35] <lerman> So, I think we either need to find out why it is so slow... OR port this to a dedicated fast standalone processor.
[18:37:09] <les_w> I have one...it already uses the interpreter
[18:37:14] <les_w> fast and cheap
[18:37:25] <les_w> the kmotion card
[18:37:33] <lerman> Has anyone done an instruction count for the servo update path? Where does the time go, specifically.
[18:37:56] <lerman> How fast is the kmotion card?
[18:38:17] <les_w> let me gret you a link
[18:40:13] <les_w> http://www.dynomotion.com/
[18:40:51] <les_w> again, this is using the emc rs274 interpreter in the host machine
[18:40:56] <etla> is it opensource ?
[18:41:38] <les_w> It could be. I have been talking a lot with the developer.
[18:42:30] <les_w> It seems to be a dynamite card....not horribly expensive either.
[18:43:07] <les_w> with a cnc control software....it would be great
[18:43:10] <etla> 4 axes are nice, but I'd like more encoder inputs, for spindle and jog-wheel. does it do that
[18:43:24] <les_w> but the developer has a day job
[18:43:29] <les_w> checking
[18:43:37] <etla> do you envision it as standalone or hooked up to a (non realtime?) pc ?
[18:44:12] <les_w> either...but a pc for the gui etc makes sense
[18:44:21] <les_w> oh and it has servo amps on it!
[18:44:43] <les_w> we have talked the developer into putting much higher power amps on it
[18:45:09] <les_w> Great platform...just needs code.
[18:45:16] <etla> max supply 300V and max current 10A would be a start
[18:45:23] <les_w> yeah
[18:45:41] <les_w> well so far 20 amp 90v I think
[18:45:49] <lerman> Are the servo amps *ever* the size you need? I've blown a few -- I'm glad I didn't blow the processor board. I don't think I want a few hundred (or thousand) watts running around a cpu board.
[18:46:12] <etla> optoisolated pwm outputs might be safer
[18:46:26] <lerman> Works for me.
[18:46:50] <les_w> well without is possible too....he is open to that. Cost would drop a bunch too.
[18:47:03] <lerman> What processor does it use? (And what C compiler, development environment...?)
[18:47:12] <etla> looks like a TI dsp
[18:47:18] <les_w> 320
[18:47:27] <etla> TI hands out their code composer studio to all interested universities
[18:47:34] <etla> if you happen to work at a uni that is :)
[18:47:58] <lerman> Do I *look* like a university (don't answer that) :=]
[18:48:01] <les_w> 600 MFLOP
[18:48:44] <lerman> Well, how many mflop is a 2 ghz pentium? Mflops don't say it all.
[18:48:54] <les_w> I think the developer would be delighted with open source code project for his board
[18:49:50] <les_w> He has a day job...would like to sell some of these!
[18:50:03] <etla> 1 MHz max encoder count is a bit limiting
[18:50:14] <etla> think 8000pulse/rev at 3000-4500 rpm
[18:50:20] <alex_joni> etla: 1MHz is pretty common..
[18:50:29] <alex_joni> not very many go beyond..
[18:50:41] <lerman> They talk about a 90usec update time for all four servos. Call it 10,000 per second. So, if we are traveling at 10 inches per second, we can update every .001 inches.
[18:51:03] <les_w> it's enough...but not as good as the galil acelera @ 20 Mhz
[18:52:05] <les_w> I would consider 90 usec for four axes very good performance
[18:52:49] <lerman> Or think of 10 inches per second, that's an encoder resolution of a hundred thousandth of an inch.
[18:53:06] <les_w> If anyone is interested I could try and get him on here.
[18:53:24] <alex_joni> depends on how interested he is..
[18:53:34] <les_w> yeah
[18:53:42] <etla> les_w with the software that he now has, how hard is it realistically to get it working ?
[18:54:15] <les_w> well, we have been working on him. I think with the right software this would be a dynamite control
[18:54:21] <lerman> No it doesn't. If you can get him on here, I'd be interested in what he has to say.
[18:55:47] <les_w> well, he can do some rs274 commands. His TP is crude and needs reworked. A machine control gui needs to be written.
[18:56:07] <etla> does it need a RT OS then ?
[18:56:31] <lerman> My next vacation is in March. I might take my notebook with me and see about building a QT based gui by copying mach's -- no, make that *using mach's gui for inspiration*.
[18:56:38] <les_w> note that he does have pidff and two software biquad IIR filters
[18:56:43] <les_w> which is good
[18:58:13] <etla> what do the filters do ?
[18:58:26] <les_w> I think the host computer would not have to be RT
[18:59:08] <etla> it will be crucial to get development tools to as many as possible
[18:59:16] <les_w> etla, filter functions are typically used to put zeros over poles created by machine structural resonances
[18:59:21] <les_w> very powerful
[19:00:26] <alex_joni> lerman: ask paul to send you what he's got
[19:00:28] <etla> shouldn't be needed with a double-jerk limited tp
[19:00:36] <alex_joni> afaik he has already built some QT widgets for emc
[19:00:42] <cncuser> hello folks
[19:00:48] <alex_joni> hello
[19:00:53] <cncuser> hi alex_joni
[19:01:01] <alex_joni> cncuser: some reported problems with puppysit..
[19:01:24] <les_w> etla, I think it would be needed even with fifth order
[19:01:31] <cncuser> alex_joni: yes, i read it on the list, thank you for removing it and putting back online the old version
[19:01:43] <alex_joni> cncuser: no problem..
[19:01:46] <etla> les_w: you mean stepper motor related resonances ?
[19:01:55] <les_w> any bandwidth that gets to a machine structural pole and phase margin is gone.
[19:02:09] <les_w> no not stepper
[19:02:12] <les_w> machine
[19:02:59] <les_w> for example gantry rocking greates the lowest pole pair in my machine...which is typical
[19:03:06] <les_w> creates
[19:03:36] <lerman> Wouldn't FIR filters be better because they have better phase characteristics? (I assume that both X and Y are passed thru the same filter).
[19:03:37] <etla> ok, I'm not convinced as I have not seen this myself. but they can always be turned off I guess
[19:04:28] <cncuser> has anyone a hint on software for getting bitmaps into 3d data ? like dxf. simple ones are ok, i just want to make black z-100. a simple relief
[19:04:29] <les_w> plenty of video and other stuff on the galil site about maintaining phase margin
[19:04:35] <les_w> it's important.
[19:04:47] <alex_joni> cncuser: there are some software out there...
[19:04:50] <alex_joni> let me look
[19:05:02] <cncuser> alex_joni: thanks :)
[19:05:11] <alex_joni> http://timeguy.com/cradek/image-to-gcode
[19:05:16] <alex_joni> cradek's code..
[19:05:29] <cncuser> nice, is there a gcode to dxf converter ?
[19:05:37] <cncuser> for i need to fineedit
[19:05:42] <alex_joni> not that I know of..
[19:05:47] <cncuser> hmmm
[19:05:55] <alex_joni> only the other way around
[19:05:57] <cncuser> i need somthing that i can edit :)
[19:06:10] <cncuser> i dont want to edit gcode listings :)
[19:06:13] <alex_joni> you can edit g-code
[19:06:14] <alex_joni> :D
[19:06:16] <lerman> Why not just edit the initial image?
[19:06:20] <cncuser> haha
[19:06:43] <cncuser> lerman: its a "realtime app"
[19:07:22] <lerman> I don't understand?
[19:07:50] <cncuser> lerman: sorry wrong window :))
[19:08:13] <lerman> I don't do windows.
[19:08:59] <cncuser> lerman: i think editing the dxf will be easier. than do do that ot pixels
[19:09:15] <cncuser> lerman: i love my windows
[19:09:47] <mshaver> cncuser!
[19:10:06] <mshaver> i have a couple puppy questions!
[19:10:14] <cncuser> that mozilla window over there, the gaimbox down there, the xchat in the middle
[19:10:23] <cncuser> mshaver: hi, go on
[19:10:39] <les_w> well, off to the grocery for me. And since the latest invention is going real well I'm going to get a bunch of filet mignon for a cookout. No hamberger today. Is that ok?
[19:11:12] <mshaver> did you recompile the kernel inside puppy using usr_devfx.sfs, or did you do it in vector linux?
[19:11:28] <Jacky^> Jacky^ is now known as Jacky^dinner
[19:11:41] <cncuser> mshaver: i did it in debian sarge
[19:11:57] <lerman> lew_w: CU later.
[19:12:09] <les_w> k ken
[19:12:42] <mshaver> so you compiled the kernel & modules there and them moved them to puppy?
[19:14:10] <cncuser> mshaver: yes, i compiled a debian kernelpackage (for my develsystem runs debian sarge) and then copied the kernel to a chrooted puppysit i have setup. i allways use the same kernel on the sargebox as i do on the puppysit so i can chroot into /puppy-sitdev mount /proc and /dev on it and am able to use emc like with puppy bootet
[19:42:42] <Jacky^dinner> Jacky^dinner is now known as Jacky^
[19:45:03] <cncuser> cncuser is now known as jblunzen
[19:54:59] <les_w> good grief. $15/lb for meat.
[19:56:05] <dmess> eatin the high grade tonite boy.... ; ) i love good burnt meat...
[19:56:23] <jblunzen> bye
[19:56:47] <les_w> things have been going well, so yeah bought a couple pounds.
[19:57:18] <dmess> ever found a del monoco cut??
[19:57:26] <les_w> I have to burn it properly.....on cherry scraps from the cnc production of course.
[19:57:32] <mshaver> mshaver is now known as mshaver_away
[19:57:35] <les_w> this is tenderloin
[19:58:10] <les_w> emc makes all my grilling wood
[19:58:28] <dmess> ok.. smallish steaks... but good... i got moose tenderloin waiting for me at my dads... ; )
[19:58:34] <les_w> mmm
[19:59:34] <les_w> just be sure to cnc machine the wood/charcoal.... very precise cooking.
[20:00:06] <Jymmm> lol
[20:00:10] <Jymmm> and use cherry too
[20:00:15] <les_w> yeah
[20:01:01] <Jymmm> les_w: In the "O" vs "V" flute... I *THINK* it has to do with the shape of the cutting edge. I'll call em Monday to be sure.
[20:01:18] <dmess> cherry, maple , beech all make good smokin woods
[20:01:48] <alex_joni> use sherry not cherry ;)
[20:01:51] <alex_joni> on yourself :D
[20:02:07] <Jymmm> JUST got back from the plastics store... picked up some stuff to play with.
[20:03:05] <dmess> anything nifty?? minlon samples??
[20:03:33] <Jymmm> cast acrylic, polycarb, anti-glare acrylic. It's their bits and pieces bin... all the stuff costed $7
[20:03:47] <Jymmm> oh and some cobolt blue acryclic too =)
[20:03:52] <Jymmm> cobalt
[20:03:54] <dmess> cool poly if fun
[20:04:54] <Jymmm> Well, I think I'll need a special cutter... single flute.
[20:05:26] <Jymmm> can't get the chipload high enough with a v cutter
[20:05:47] <Jymmm> and rpm is at 8000 (the lowest I can go)
[20:09:08] <Jymmm> Now I just need to find some CHEAP white LEDs
[20:09:30] <Jymmm> cheap as in close to price of RED LEDs
[20:09:51] <Jymmm> too bad WalMart doesn't sell em
[20:11:03] <les_w> I smell light pipe signs...
[20:14:18] <les_w> I was a very early user of the ultrabright leds
[20:15:25] <les_w> I designed the optics for the anunciator in the Boeing 777 aircraft. It was the first cockpit use of ultrabright leds.
[20:15:33] <les_w> That was a long time ago.
[20:16:34] <les_w> Despite the 100,000 hr life, they are still press to test.
[20:17:14] <les_w> Dead warning light= possible dead people.
[20:19:07] <alex_joni> dead unwarned people ;)
[20:19:17] <les_w> ha yeah.
[20:21:54] <dmess> dead ppl dont need a warning... nearly alive ones though... might be nice
[20:22:11] <les_w> What a sin. Just put adolph's meat tenderizer on tenderloins. I'll be eatin' em with a soda straw!
[20:22:30] <dmess> why??
[20:22:38] <les_w> good question!
[20:22:59] <dmess> man.. now i gotta go dig up some steaks too..
[20:23:03] <les_w> now where are my belts and suspenders?
[20:23:30] <les_w> I am trying to do the pavlov thing. Is it working?
[20:33:31] <Jymmm> the what?
[20:34:03] <les_w> um
[20:34:10] <alex_joni> the dog experiment
[20:34:27] <Jacky^> zombie dogs ?
[20:34:35] <Jymmm> no bow wow experiments or I'll be usign les tractor
[20:35:01] <les_w> http://nobelprize.org/medicine/educational/pavlov/readmore.html
[20:35:43] <Jymmm> Ah, heard it on a commercial, wanted to know the origin
[20:35:57] <Jymmm> ding dong
[20:36:07] <les_w> hahaha
[20:36:10] <les_w> slobber
[20:36:15] <Jymmm> lol
[20:36:22] <Jacky^> http://www.foxnews.com/story/0,2933,160903,00.html
[20:36:27] <Jacky^> :/
[20:36:43] <Jymmm> yeah, flesh over charcoals sounds pretty good.
[20:37:08] <Jymmm> been wanting a good hamburger for the last couple of weeks - even over a steak.
[20:37:42] <les_w> ding
[20:38:13] <Jymmm> nah, no ground beef (I think - checks)
[20:38:17] <les_w> jacky: wild . reanimating dogs.
[20:38:41] <Jacky^> les_w: gulp
[20:39:24] <les_w> I stopped eating hot dogs after touring a slaughter house in Chicago. We made pneumatic pig killers.
[20:39:30] <dmess> i didnt find steaks .... but a nice 5 lb centercut roast that'll be steaks soon... ; )
[20:39:52] <les_w> <slobber>
[20:40:04] <dmess> yeah... the bonkometer..... cool les..
[20:40:09] <les_w> where is my drool cup?
[20:41:04] <dmess> i seen 1 used on cows too... clamp the thing and pow to the melon
[20:41:15] <les_w> right
[20:42:08] <Jymmm> YES!!!
[20:42:20] <dmess> was yours emc controlled?? ' ; )
[20:42:22] <Jymmm> we have hamburgerage!!!
[20:43:01] <les_w> plc's were used...but again...I am burning the meat on emc cut wood.
[20:43:08] <dmess> find the neighbourhood's unwanted dog and have steak tooo...
[20:43:20] <Jymmm> * Jymmm smacks dmess
[20:43:21] <les_w> Korean eh?
[20:43:27] <les_w> yum
[20:43:56] <dmess> native canadian.... if its alive and you kill it... eat it
[20:44:46] <les_w> you know, my tractortoy is made in Korea....nice engineering. They make nice machine tools too. Very impressed.
[20:44:47] <dmess> i ate my 1st beaver at 5
[20:44:57] <les_w> Dog meat makes you smart I guess.
[20:45:04] <Jymmm> lol
[20:45:20] <dmess> daewoo machine tools are very nice
[20:45:38] <les_w> dmess: holy S*%t you got started early!
[20:46:00] <dmess> toshiba even licenced a few models to them to build and sell under 2 banners
[20:46:28] <dmess> what do you mean...??
[20:46:28] <les_w> nice tools. Good engineering.
[20:46:44] <les_w> heh
[20:47:00] <Jacky^> uhmm
[20:48:05] <dmess> les... we ate the tail too... ; )
[20:48:25] <les_w> This is a family irc channel. I wouldn't want to shock or corrupt fine honest folks like jacky.
[20:48:39] <Jacky^> :)
[20:49:02] <Jacky^> i was reading an article abou the mummy ..
[20:49:11] <dmess> nor i.... its a canadian industrius animal with a big flat tail
[20:49:18] <les_w> haha
[20:49:21] <Jacky^> 7� people died after studing him
[20:49:25] <Jacky^> ghghg
[20:49:29] <Jacky^> very strange
[20:49:42] <Jacky^> the mummy found in the ice ..
[20:49:53] <les_w> jacky, ALL people that study mummies die.
[20:49:53] <Jacky^> O_O
[20:50:02] <Jacky^> les_w: strange ..
[20:50:13] <Jacky^> too much peoples
[20:52:13] <les_w> oh no. Crisis. I am out of beer. BBIAW. Have to rectify that situation immediately.
[20:54:00] <Jymmm> les_w: What happened? Forgot to close the valve on the 5,000 gallon SS storage tank?
[20:54:43] <les_w> I had some, but now it's gone. Not sure what happened.
[20:58:02] <dmess> me niether im on the way out too ...bbl
[20:58:41] <Jymmm> les_w: Put down the needle and step away from the Beer IV
[21:12:33] <etla> les_w: you still there ?
[21:27:03] <les_w> back...had to correct a fluid dynamics problem
[21:27:25] <etla> have you seen the mesanet 5i20 card ?
[21:27:36] <les_w> no...have a link?
[21:27:40] <etla> does it compare to the dsp board
[21:27:52] <etla> it's an fpga chip on a pci card, www.mesanet.com
[21:27:56] <etla> click motion control
[21:28:19] <etla> but probably, the 200k gate restriction will mean that it can't handle very fancy stuff
[21:28:34] <les_w> looking
[21:28:38] <etla> the DSP's program memory is pretty much unlimited I guess
[21:30:13] <etla> they have a motion controller implemented, softdmc I think it's called
[21:30:28] <etla> don't know what the loop rate on that is...
[21:30:39] <Jymmm> les_w ROTF... fluid dynamics....
[21:31:10] <les_w> looks fast. Some of their cards use national LM629 I see. I have programmed that chip a bit. Obsolete now.
[21:31:31] <etla> the fpga is a xilinx spartan II I think
[21:32:51] <icee> 200kgates is a bit sparing to try and do motion control in imo
[21:33:16] <etla> they have something simple working but I'm thinking it's not expandable enough
[21:33:28] <les_w> I don't know much about programming gate arrays, but I do know that even a high performance cartesian cnc control is really not a demanding
[21:33:32] <les_w> thing
[21:33:42] <icee> les: you don't get many multipliers in 200kgates
[21:33:50] <icee> i think spartan ii has a few embedded 18x18 multipliers
[21:33:53] <etla> the dsp card without the powerams and with a free/available development tool would be ideal
[21:34:01] <icee> i'm much more familiar with spartan 3 / spartan 3l
[21:34:08] <les_w> hi icee.
[21:34:13] <icee> hey :)
[21:34:23] <les_w> you would know much more about it
[21:34:55] <icee> just for approximate scale, an ARM7TDMI is about 50-60k gates without program memory
[21:35:12] <icee> and on spartan ii's fastest speed grades would probably synthesize in at 15-20MHz
[21:35:48] <icee> the smallest microcoded execution units that you would want to use, without multiplier, are about 15kgates
[21:36:15] <les_w> We were talking earlier about general purpose boxes being increasingly unsuitable for hard RT. Didn't you talk some about that not being the case?
[21:36:24] <les_w> like...
[21:36:30] <les_w> 10k servo updates?
[21:36:35] <icee> Why are they unsuitable for hard RT?
[21:36:57] <icee> the performance improvements we're getting for context switching are nowhere near linear with processor frequency or MIPS, but there continues to be improvement
[21:37:35] <icee> current task switch times on real RTOS's, like QNX, weigh in at about 1500-3000 pentium iv clock cycles, or slightly less for athlon/a64/pentium m
[21:37:46] <les_w> Well I'm asking really. Can an office box do 10k pidff 4 axis servo updates?
[21:37:53] <icee> yes.
[21:38:03] <les_w> well, good.
[21:38:40] <etla> have you tried it ? :)
[21:38:58] <icee> we got lowly dell pentium 3 1.26GHz to handle 420,000 network messages/second (about 20-30/context switch)
[21:39:11] <icee> etla: that doesn't mean emc/rtai can do it; just that I'm sure the cycles are there to do it.
[21:39:42] <icee> and the state machining there was a lot more complicated and had a lot more branching than a PID control loop
[21:39:56] <icee> and a lot more data interdependencies
[21:40:06] <les_w> yes, pidff is not complicated
[21:40:42] <icee> magma/adeos just stinks.
[21:41:12] <icee> les: I bet you could do 10k servo updates on pentium i with a real RTOS
[21:41:26] <les_w> yeah?
[21:41:36] <icee> it's likely.
[21:42:31] <les_w> And i'll bet if I had a cnc control (servo HSM) that I could sell for $2k it would move big time.
[21:43:11] <icee> check this out, for instance:
[21:43:12] <icee> http://www.ia.pw.edu.pl/~sacha/XEuro95.pdf
[21:43:17] <les_w> looking
[21:43:22] <icee> 23 microsecond message latency for 100 byte messages
[21:43:26] <icee> back in 1995 on a 486
[21:43:45] <etla> let's port emc to DOS ! a real RTOS !
[21:44:04] <Jymmm> DeskNCrt
[21:44:21] <les_w> neat.
[21:44:30] <icee> in principle that's fast enough to do 10KHz servo updates.
[21:45:21] <les_w> I seem to recall being able to do small fir digital filters in a 486 at 100k in poor old borland c in dos.
[21:45:49] <icee> les: but as you say, there's TP and performance problems in emc, and building a real machining control is hard
[21:46:12] <les_w> yes. I will cost a couple man years
[21:46:15] <icee> also bugginess. i'm still getting freezes in emc2 after moving to new hardware
[21:46:25] <icee> well, maybe, maybe not.
[21:47:01] <icee> the performance issues are not that bad to fix, IMO-- though I haven't gotten deeply into the code
[21:47:12] <icee> the TP is bad but of a known, limited scope
[21:47:19] <les_w> I like the maybe not bit best....
[21:47:20] <icee> fixing flakiness like I'm experiencing, though-- that's just scary.
[21:47:31] <alex_joni> icee: what flakiness?
[21:47:42] <Jymmm> alex_joni apple pie
[21:47:47] <icee> a_j: I'm still experiencing crashes on emc2, after moving to new hardware.
[21:47:49] <icee> they're less frequent
[21:48:00] <icee> but if i leave it on for 2-3 days it's sure to hang.
[21:48:08] <les_w> Frustrating for me. I know the math, but am only a rank amateur at code.
[21:48:13] <icee> other people here have mentioned the same thing
[21:48:28] <alex_joni> never seen/heard that
[21:48:42] <icee> <lerman> icee: that's a good argument for running with an external dedicated
[21:48:43] <icee> +processor. I often go out to my shop and find that my EMC system has crashed
[21:48:43] <icee> +overnight. (Well, it could be that the multiple emacs sessions I'm running
[21:48:43] <icee> +are causing problems, but I don't really know.
[21:48:43] <icee> etc
[21:49:04] <alex_joni> hmmm
[21:49:17] <icee> <gurrag:#emc> Shure... much better than the earlier BDI:s
[21:49:17] <icee> <gurrag:#emc> It craches ones a day.... Some days not
[21:49:17] <icee> <gurrag:#emc> Some crashes are harder, like putting down X, but I think that
[21:49:17] <icee> +is more RT related than EMC related
[21:49:34] <les_w> Bottom line: emc will work ok on a sherline or an old Bridgeport, but for modern HSM....no way.
[21:50:09] <alex_joni> gurrag I just talked to
[21:50:16] <alex_joni> seems he had APM enabled in the bios
[21:50:17] <icee> that's just /lastlog crash
[21:50:27] <alex_joni> and that's what caused the problems
[21:51:10] <icee> i have apm turned off
[21:51:18] <icee> the new machine is a sempron 2800+; way overkill
[21:51:24] <alex_joni> yup
[21:51:33] <alex_joni> I'm running emc2 perfectly on a 300 MHz Geode
[21:51:56] <alex_joni> with GUI exported over ssh
[21:52:30] <icee> a_j: it's probably not even an emc2 problem
[21:52:42] <icee> i don't think magma/adeos is well tested for all hardware combinations
[21:52:45] <alex_joni> what rtai?
[21:52:53] <alex_joni> magma?
[21:52:59] <alex_joni> magma is pretty new..
[21:53:13] <alex_joni> experimental.. to say the least :D
[21:53:25] <icee> well, why is it in the currently shipped bdi, then?
[21:53:37] <alex_joni> ask Paul that..
[21:54:14] <icee> you guys really like to torture your users, don't you? :P
[21:55:23] <alex_joni> I don't ..
[21:55:45] <alex_joni> I really don't
[21:55:48] <alex_joni> but I have no connections with the BDI either..
[21:56:01] <icee> :( i just want to run a combination of software that other people have tested and there's a certain degree of maturity
[21:56:13] <icee> i can't do that with the emc2 branch, i can't really do that with emc1 building it myself
[21:56:21] <icee> from what i can see
[21:56:22] <alex_joni> otoh, it worked ok on all I've tried so far..
[21:56:32] <alex_joni> why not with the emc2?
[21:56:39] <icee> bdi is running something you call 'experimental' without being marked
[21:56:48] <icee> a_j: because i'm checking out from a branch under active development, right?
[21:56:53] <alex_joni> yes
[21:57:02] <icee> i could check out and get the newly committed 'make your machine explode' feature
[21:57:17] <alex_joni> those don't get commited to HEAD
[21:57:22] <alex_joni> always in branches..
[21:57:35] <alex_joni> also I'm thinking about starting releases for emc2
[21:58:46] <roltek> you guys are missing the real point. what happens when one of these bad releases hurts somebody
[21:59:12] <alex_joni> roltek: that happens?
[21:59:16] <alex_joni> what happens?
[21:59:21] <icee> yah, there is a certain amount of danger to life and property with the way things work
[21:59:38] <alex_joni> sh*t happens.. no warranties in life
[21:59:40] <icee> I'm pretty careful with how i do test and bring things up, but.. not everyone will be
[21:59:54] <alex_joni> buy a fscking expensive software, and it might blow up
[22:00:19] <alex_joni> but the EULA you accepted reads in nice small print: no warranties taken, etc
[22:00:39] <icee> EULA?
[22:00:48] <roltek> if shit happens than the board members are not doing there job
[22:00:53] <alex_joni> end user licence agreement
[22:00:59] <icee> alex: there's an EULA?
[22:01:09] <alex_joni> not to emc
[22:01:16] <alex_joni> I said fscking expensive software
[22:01:40] <alex_joni> roltek: the board members need to test the software?
[22:01:50] <icee> there needs to be process
[22:01:57] <icee> so people know what they're getting
[22:02:49] <alex_joni> has anyone read the README for emc2?
[22:03:25] <alex_joni> thought so..
[22:03:31] <icee> a disclaimer in a doc file doesn't really cover you legally, you know.
[22:03:42] <icee> a EULA that a end-customer signs doesn't even.
[22:04:15] <anonimasu> icee: you can always buy a fanuc.
[22:04:45] <roltek> i have fanuc's and they don't hurt people
[22:05:04] <icee> Hey, I'm comfortable accepting the risk. still, there are low-cost things that can be done in process that can make everyone-- including the developers-- happier
[22:05:09] <roltek> maybe this board should take some pride in what they do
[22:05:37] <icee> e.g. having real releases lets you know better whether a issue being reported still exists and whether there has been regression
[22:05:39] <alex_joni> roltek: and you're suggesting emc is?
[22:05:49] <anonimasu> icee: right
[22:06:01] <roltek> make sure it works before it's released
[22:06:10] <icee> and after they don't hurt anyone after a few weeks of being used, you can pronounce their level of maturity
[22:06:27] <alex_joni> well.. emc2 works for more than a year now
[22:06:27] <icee> keep the newbies/hobbyists off the development branches where they're just a hassle to deal with
[22:06:44] <alex_joni> and it still is marked as experimental
[22:07:08] <icee> I give up. :P
[22:07:09] <anonimasu> alex: true
[22:08:04] <alex_joni> icee: I've been watching emc2 for a long time now
[22:08:18] <alex_joni> and I think alltogether there were about 2 weeks when HEAD was busted
[22:09:04] <alex_joni> I think it's safe to say that an emc2 HEAD is ok for you.. at any time
[22:09:13] <alex_joni> notice _you_ not the average user
[22:09:28] <alex_joni> let users hassle with the BDI, it's best for them
[22:09:56] <alex_joni> not sure why paul chose to go with magma on it, but I haven't seen any magma-related problems on the BDI
[22:10:48] <alex_joni> maybe others reported some, but that must have been directly to paul
[22:12:03] <alex_joni> when there'll be a release certainly it will be emc1 first
[22:12:17] <alex_joni> and only after a while emc2 (but that's still away)
[22:12:37] <alex_joni> * alex_joni goes back to actually doing something
[22:22:59] <les_w> is it ok if I go to the music room now?
[22:23:05] <les_w> I promise to be good.
[22:23:13] <alex_joni> les_w: you may go to your room
[22:23:22] <alex_joni> but you are grounded for the next week
[22:23:32] <les_w> thank you sir.
[22:23:35] <les_w> hah?
[22:23:39] <les_w> heheh
[22:23:46] <alex_joni> you need to clean up your barn
[22:24:01] <les_w> uh...ok.
[22:24:05] <alex_joni> you'll have company :)
[22:24:36] <les_w> I have 3 tractors in my barn.
[22:24:46] <les_w> I'll clen em up
[22:24:59] <les_w> though they are pretty clean
[22:25:30] <les_w> had to detail the front end loader with a toothbrush....got dirt on the bucket.
[22:41:52] <alex_joni> hi rayh
[22:43:15] <rayh> Hi alex
[22:44:14] <Jymmm> * Jymmm pictures les' next sign.... "LM Watts.... An authorized John Deer Dealership"
