#emc | Logs for 2007-01-02

Back
[00:01:07] <alex_joni> heh.. Mario. is taking it now :)
[00:04:26] <lerneaen_hydra> alex_joni: indeed ;)
[00:05:12] <alex_joni> his fault
[00:08:23] <alex_joni> ok, good night people
[00:08:53] <jtr> I thought that response was appropriate.
[00:41:23] <lerneaen_hydra> 'night all
[00:48:46] <jmkasunich> * jmkasunich is back
[00:48:56] <SWPadnos> welcome back
[00:49:01] <SWPadnos> happy new year
[00:49:01] <cradek> hi jmk
[00:49:08] <jmkasunich> 108 unread emails :-(
[00:49:13] <SWPadnos> that's it?
[00:49:18] <SWPadnos> is that before or after spam filtering?
[00:49:44] <jmkasunich> after
[00:49:58] <jmkasunich> probably half are commit emails
[00:50:40] <SWPadnos> those are easy then ;)
[00:51:17] <SWPadnos> oh - you use webmail, so you probably don't have automatic filters to move things to different folders
[00:51:30] <jmkasunich> right
[00:52:08] <cradek> jmkasunich: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?PyVCP
[00:52:47] <jmkasunich> slick
[00:52:57] <jmkasunich> IMO, the existing VCP can go away ;-)
[00:53:25] <jmkasunich> well, I suppose I should examine it more closely, but thats my first impression
[00:55:25] <cradek> does pyvcp require axis?
[00:55:51] <jmkasunich> it doesn't look that way
[00:56:01] <SWPadnos> the standalone window leads me to believe not
[00:56:04] <cradek> ok
[00:57:35] <jepler> cradek: as the tree stands, it may not be set up to run apart from axis
[00:57:42] <jepler> but its requirements are python+Tkinter
[00:57:44] <jepler> basically
[00:57:48] <cradek> ok
[00:58:27] <jepler> python-dev to build, because it needs the hal module
[01:17:13] <ejholmgren>
[01:35:39] <jmkasunich> finally caught up with reading mail
[01:35:45] <jmkasunich> now to write a reply or two
[01:37:34] <SWPadnos> interesting - I think the wiki software thinks it should execute the pyvcp files
[01:37:45] <SWPadnos> that's why it gives an error instead
[01:37:52] <A-L-P-H-A> SWPadnos... okay... what was the exact total again? and I'll mail out a check asap.
[01:37:55] <jmkasunich> cause they're XML?
[01:37:56] <A-L-P-H-A> $268?
[01:38:09] <SWPadnos> yep
[01:38:16] <SWPadnos> jmkasunich, no, they're python
[01:38:24] <A-L-P-H-A> SWPadnos? yep to me?
[01:38:39] <SWPadnos> A-L-P-H-A, yep, yep to you
[01:38:47] <SWPadnos> $268
[01:38:52] <A-L-P-H-A> SWPadnos, yep, okay yep to me.
[01:39:22] <A-L-P-H-A> now time to bug jmkasunich... :) so. umm. hi. how's the step/dir progress for mesa coming? :D
[01:39:24] <A-L-P-H-A> hehehe
[01:39:27] <SWPadnos> A-L-P-H-A, ok, yep. you got the yep then? the yep that was for you?
[01:39:50] <jmkasunich> I don't have my board yet
[01:39:59] <jmkasunich> and I just got back from five days away from home
[01:40:26] <SWPadnos> right now, FedEx has his board (and everyone else's)
[01:40:32] <jmkasunich> but I did spend some time one evening thinking about implementation details and wrote down a lot of my thoughts, that will help once I get the board
[01:40:47] <A-L-P-H-A> SWPadnos, not mine I don't think... unless you trust me for $268. hahaha.
[01:40:58] <SWPadnos> it's mine until the check clears :)
[01:41:10] <Jymmmm> lol
[01:41:14] <SWPadnos> ok - the package is in New Jersey
[01:41:14] <A-L-P-H-A> fair enough.
[01:41:14] <Jymmmm> CBD
[01:41:15] <SWPadnos> how unfortunate
[01:41:17] <SWPadnos> heh
[01:41:35] <Jymmmm> CBD == Cash Before Delivery, 30 day hold on checks and money orders.
[01:41:57] <A-L-P-H-A> luckily I don't need it right this minute. :D
[01:42:06] <A-L-P-H-A> Jymmmm, moved in and settled yet?
[01:42:08] <SWPadnos> nah - I'll probably send it out as soon as (1) my credit union decides I can withdraw the cash and (2) I feel like making out 5 copies of the international invoice crap
[01:42:28] <elson> Hello, all!
[01:42:36] <SWPadnos> hi Jon. happy new year
[01:42:37] <A-L-P-H-A> hi
[01:42:41] <Jymmmm> A-L-P-H-A moved in, tv broke, replaced. Frig broke, replaced it. replacement frig not doin so well 24hours later.
[01:42:51] <Jymmmm> A-L-P-H-A Murphy is hard at work.
[01:42:54] <SWPadnos> don't forget the broken monitors
[01:42:53] <elson> Happy new year to all of you, too!
[01:42:53] <A-L-P-H-A> Happy Hugmonay!
[01:43:11] <SWPadnos> A-L-P-H-A, maybe you should take your meds ...
[01:43:23] <elson> Murphy, yeah, I've seen his work.
[01:43:41] <SWPadnos> he's very skilled
[01:43:43] <A-L-P-H-A> Happy Hogmanay!
[01:43:43] <Jymmmm> SWPadnos Yeah, those too. But a friend of mine took care of us on those, and the replacement TV, plus helped us move the new frig.
[01:43:47] <A-L-P-H-A> that's how you spell it.
[01:44:46] <jmkasunich> hi jon
[01:45:32] <elson> Hello, John! If you hadn't heard, I updated my ancient EMC1 system to EMC2 this weekend.
[01:45:53] <jtr> SWPadnos: Been meaning to ask you - did you get my payment?
[01:45:57] <jmkasunich> yeah, I just got done reading 108 emails (I was away the last few days)
[01:46:02] <Jymmmm> SWPadnos: AND... the new cellphones I got for XMAS, one needs to be replaced because it goes roaming where the other EXACT same one doesn't.
[01:46:09] <SWPadnos> jtr, yep - check your email :)
[01:46:15] <elson> Now, I'm trying to get homing working, and having a bit of trouble.
[01:46:38] <elson> 108? Hah. I get 400+ a day (not all EMC of course)
[01:46:52] <SWPadnos> CCED has been slow lately, but it does peovide a lot of reading
[01:46:55] <SWPadnos> provide
[01:46:59] <SWPadnos> also the gecko list
[01:47:11] <jmkasunich> I gave up trying to keep up with them
[01:47:34] <SWPadnos> yeah - I finally gave up on Linux Kernel earlier this year
[01:47:51] <SWPadnos> now I can leave my computer off for more than 6 days without overflowing my 10M mail limit on the server
[01:48:39] <jmkasunich> elson: what kind of problems with homing?
[01:48:53] <cradek> I hope I have jon the right advice yesterday
[01:48:55] <cradek> gave
[01:48:57] <A-L-P-H-A> who's got unreal tournament and wants to play?
[01:48:59] <elson> Anyway, Chris Radek suggested yesterday that I needed the encoder reset on index function to make homing work on the latest EMC2. But, unless I hooked the pin to the wrong signal, the motion system doesn't seem to use axis.n.index
[01:49:01] <jtr> SWPadnos: Oops. I don't have enough display real estate.
[01:49:14] <SWPadnos> heh
[01:50:33] <elson> So, I have it set to use the index pulse, but after the 2nd slow approach to the index switch, it just keeps crawling along.
[01:50:37] <SWPadnos> jtr, you need one of these: http://en.wikipedia.org/wiki/T221
[01:50:43] <jmkasunich> IIRC (and its been a while since I looked), when the motion controller sees the home switch (the second time), it should assert a HAL pin that tells the encoder counter "reset to zero the next time you see an index pulse"
[01:51:02] <jmkasunich> when the encoder sees the index, it resets the position to zero and clears that same signal
[01:51:07] <elson> OK, what pin does it send this on?
[01:51:06] <jmkasunich> (yes, its bidirectional)
[01:51:11] <cradek> that pin is axis.N.index-enable
[01:51:18] <jmkasunich> hang on, lemme fire up emc
[01:51:28] <cradek> btw hi jon, john
[01:52:49] <elson> OK, this is what I have : linksp Xindex <= ppmc.0.encoder.00.index
[01:52:49] <elson> linksp Xindex => axis.0.index-enable
[01:52:53] <jmkasunich> http://pastebin.ca/300185
[01:53:37] <Jymmmm> Well folks off to work, be back on in 90 minutes.
[01:53:39] <SWPadnos> doesn't that have to be RW on the driver end?
[01:53:49] <jmkasunich> bit FALSE Xindex-enable
[01:53:49] <jmkasunich> <=> axis.0.index-enable
[01:53:49] <jmkasunich> <=> encoder.0.index-enable
[01:54:04] <jmkasunich> SWPadnos: yes, it should be
[01:54:21] <elson> I think my driver has a write pin, and a readback copy.
[01:54:36] <jmkasunich> thats why its not working
[01:54:58] <cradek> I thought you fixed that on the others
[01:55:02] <elson> OK, so the axis end needs to see it as RW?
[01:55:07] <jmkasunich> here's the canonical encoder (the software based one)
[01:55:08] <jmkasunich> http://pastebin.ca/300190
[01:55:32] <jmkasunich> (the pastes are from the servo-sim config)
[01:56:18] <ejholmgren> ow.. cat is tryinto chew my left hand off
[01:56:40] <SWPadnos> Is it safe to say that conceptually, the index handling has been moved out of "EMC" and into HAL (ie, the driver)
[01:56:49] <jmkasunich> sort of
[01:57:34] <jmkasunich> the encoder driver is supposed to reset to zero if its index-enable pin is true, and it sees and index, and when the reset is done, it should set index-enable false
[01:57:52] <jmkasunich> however, deciding what happens as a result of that is still up to EMC
[01:57:58] <jmkasunich> for an axis, its used for homing
[01:58:04] <jmkasunich> for a spindle, its used for spindle sync
[02:00:07] <jmkasunich> documentation of the "correct" behavior for an encoder driver: http://pastebin.ca/300199
[02:00:17] <jmkasunich> (pulled from the main hal document)
[02:00:29] <SWPadnos> sure - the meaning of an index is still up to EMC, but the handling of the index and encoder position is up to the driver
[02:00:44] <SWPadnos> (as directed by emc)
[02:01:01] <elson> OK, well, I am going to have to work on this, but in my code the encoder[n].index_enable is set to type HAL_IO
[02:01:23] <jmkasunich> does your driver implement the documented behavior?
[02:01:34] <jmkasunich> run it completely independent of emc to test it
[02:01:50] <jmkasunich> loadrt your driver, link a signal to the driver's index pin
[02:02:10] <jmkasunich> put a few halmeters on that signal, and some other pins, like the "counts" parameter
[02:02:17] <jmkasunich> turn the encoder shaft and watch it count
[02:02:23] <jmkasunich> sets the index signal true
[02:02:41] <elson> Well, I really have never quite figured out how to do that. Running it WITH emc2 and using halscope pretty much gives me the info I need, though.
[02:02:42] <jmkasunich> turn it some more, you should see the count reset, and the index enable go false again
[02:03:28] <jmkasunich> ok, can you post a halscope pic of the tail end of the homing sequence?
[02:03:38] <jmkasunich> you could trigger on index-enable going true
[02:03:40] <elson> Right, that's what I'd expect.
[02:03:48] <SWPadnos> there's a handy script called "halrun" that will run a hal file, then leave you in an interactive halcmd
[02:05:08] <SWPadnos> you probably need only 3 lines in the hal file: loadrt hal_ppmc / newsig test bit / linksp test ppmc.0.encoder.0.index-enable
[02:05:19] <elson> well, what I seem to see is that axis.0.index-enable is always = 1, which I assume means true.
[02:05:43] <jmkasunich> never goes false, even after the encoder has turned a full revolution?
[02:06:04] <elson> right. But, it seems like it is true even when NOT doing the home
[02:06:06] <elson> operation!
[02:06:21] <jmkasunich> well thats screwy
[02:06:32] <jmkasunich> is your driver writing a one to that pin?
[02:06:43] <cradek> 32770 bit I/O FALSE axis.0.index-enable
[02:07:01] <cradek> my (sim) setup shows it false
[02:07:10] <jmkasunich> you're not running the ppmc driver
[02:07:33] <elson> I thought so, too. Oh, that's a point. I have no idea what my driver write, I THINK maybe it will only write a false when it has done the reste counter on index function.
[02:07:43] <cradek> that's true, I thought we were talking about an output from motion
[02:08:47] <jmkasunich> I just took a quick look at the ppmc code, and it seems like it can only write zero to the pin
[02:08:49] <jmkasunich> (which is correct)
[02:08:52] <elson> Well, I think the scheme is axis starts the process by setting it true, when it is done, the driver sets it false.
[02:09:02] <jmkasunich> exactly
[02:09:10] <jmkasunich> "axis" meaning the motion controller
[02:09:15] <elson> That's what I (vaguely) remember.
[02:09:40] <elson> right, motion control sends to axis.n.index-enable
[02:10:15] <jmkasunich> elson: what is the idea behind ind_enb_copy?
[02:10:39] <elson> Maybe I should disconnect the hal pin, and just watch what motion is sending.
[02:10:53] <jmkasunich> not a bad idea
[02:11:13] <jmkasunich> I still think the best way is to confirm proper operation of the driver in isolation
[02:11:23] <elson> Umm, it likely was a way to watch an internal variable to make sure something was getting through to the driver. It must be a vestige of testing that needs to come out.
[02:11:30] <jmkasunich> ok
[02:11:42] <jmkasunich> you're not connecting anything to it in HAL right now?
[02:12:13] <elson> I may have to learn how to do the isolated driver thing.
[02:12:35] <elson> The _copy pin? No, I don't think it is used from the outside.
[02:12:45] <jmkasunich> ok, then we can ignore it for now
[02:12:51] <jmkasunich> I agree it should go away late
[02:12:53] <jmkasunich> later
[02:13:00] <SWPadnos> yey - I fixed the python execution problem on the wiki :)
[02:13:02] <SWPadnos> yay
[02:13:24] <elson> OK, well, let me go do some testing and I'll let you know what I figure out.
[02:13:38] <jmkasunich> before you go...
[02:13:45] <jmkasunich> function active at a time, so the code takes a shortcut
[02:13:45] <jmkasunich> and the highest numbered channel takes precedence. */
[02:14:00] <jmkasunich> note it only makes sense for one channel to have this
[02:14:03] <jmkasunich> oops
[02:14:12] <jmkasunich> note it only makes sense for one channel to have this
[02:14:12] <jmkasunich> function active at a time, so the code takes a shortcut
[02:14:12] <jmkasunich> and the highest numbered channel takes precedence.
[02:14:19] <jmkasunich> the above is a comment from the driver
[02:14:25] <jmkasunich> not sure I understand
[02:14:41] <jmkasunich> is there a hardware limitation that says only one encoder can look for an index pulse at a time?
[02:15:12] <elson> OK, this is about having only one axis at a time setup to reset the counter on index pulse. It avoids a couple ands and ors to mask off the one axis to complete homing while other axes could be simultaneously searching for index.
[02:15:26] <jmkasunich> I'm confused
[02:15:32] <SWPadnos> but it prevents homing multiple axes simultaneously
[02:15:33] <jmkasunich> forget homing
[02:15:37] <jmkasunich> forget emc
[02:15:42] <elson> There is no HARDWARE limitation. The driver is a bit dumb about this right now.
[02:16:03] <jmkasunich> does you hardware have some kind of crosstalk between the channels, such that only one channel can be looking for an index pulse?
[02:16:42] <elson> What would happen, due to simplistic code, is that when the first axis was to find the index pulse, the bits that tell the other axes to reset on index would ALSO be cleared.
[02:17:07] <jmkasunich> so in the hardware, there are 4 bits in some register
[02:17:23] <jmkasunich> each bit tells the hardware for one encoder counter "reset when you see the next index pulse"
[02:17:31] <jmkasunich> is that correct?
[02:18:04] <elson> No hardware limitation, only that the bits that command the reset count on index pulse are all in one register. If you want more than one on at a time, the driver needs to keep track, and mask off those that find home one at a time.
[02:18:16] <elson> Exactly.
[02:18:40] <jmkasunich> how does the hardware tell the software that an index pulse has been detected?
[02:19:36] <elson> This is kind of a problem. There is another section of hardware that sets a latch bit when the index is seen. You can read these bits in the index latch register.
[02:20:17] <jmkasunich> this code?
[02:20:18] <jmkasunich> /* if in index_enable mode and we have seen the index pulse
[02:20:18] <jmkasunich> on that axis, then turn off index-enable */
[02:20:18] <jmkasunich> if (*(slot->encoder[i].index_enable) && i ==3) {
[02:20:18] <jmkasunich> if ((indextemp & (1<<i)) != 0) {
[02:20:18] <jmkasunich> *(slot->encoder[i].index_enable) = 0;
[02:20:19] <jmkasunich> /* major shortcut here - assumes never can have more than
[02:20:21] <jmkasunich> one ENCINDX bit set at a time */
[02:20:21] <elson> (There is also a non-latched index sense bit, that is unreliable, as it only samples the bit when the CPU requests it.)
[02:20:21] <jmkasunich> SelWrt(0x00,slot->slot_base + ENCINDX, slot->port_addr);
[02:20:25] <jmkasunich> *(slot->encoder[i].ind_enb_copy) = 0;
[02:20:28] <jmkasunich> }
[02:20:29] <jmkasunich> }
[02:21:08] <elson> That looks like the code, I need to verify it is reading the index LATCH, not the index sense bit.
[02:21:12] <jmkasunich> the " && i ==3" part seems like a bug, only channel 3 can ever reset its index-enable hal pin
[02:22:19] <jmkasunich> maybe the driver needs to keep its own copy of the 4 bits that tell the 4 hardware channels "reset when you see an index"
[02:22:27] <elson> OUCH! I think you have found it. A quick HACK to make the spindle sync work on axis 3! I remember hacking this a couple months ago! OOPS - red face!
[02:22:53] <elson> Yeah, I ought to take the time to code it all up right! It can't be that complicated.
[02:23:12] <jmkasunich> I have a feeling there are other issues, as you suggest - it won't deal well with multiple index-enables active at once
[02:23:15] <jmkasunich> but that is a refinement
[02:24:36] <elson> Well, maybe just a little restructuring needed, but the general layout SHOULD be able to handle mult. index-enables active at once. It needs to have 4 bits to remember which ones are on, and a little masking off.
[02:24:43] <SWPadnos> multaxis code: for (i=0;i<4;i++) if (*(slot->encoder[i].index_enable) ) temp |= 1<<i;
[02:25:00] <SWPadnos> plus the needed initialization and finalization of temp ...
[02:26:01] <elson> Yup, that's mostly what it would look like.
[02:26:28] <SWPadnos> with the new shadow register scheme, are all used registers still written, or only those that have changed?
[02:26:44] <skunkworks> jmkasunich: welcome back!
[02:27:23] <elson> No, only the ones needed. There is a scheme to mask which ones you need to read/write. it greatly speeds up the driver.
[02:28:17] <jmkasunich> hi skunkworks
[02:28:19] <SWPadnos> yep - I recall that there's now a map of used registers to cut down on address writes - I was wondering if the write function also dynamically decides whether specific registers have changed, and skips updating them if possible
[02:28:28] <elson> Oh, wait, no, it will rewrite the same value to a register every time. If not, it would need to write to the address reg. to skip over a reg that doesn't need to change.
[02:28:54] <jmkasunich> yeah, there is no gain (and maybe a penalty) from skipping a single register
[02:29:00] <SWPadnos> right - it would need to create a new map of registers to update every time (which may still be a win, but annoying to code)
[02:29:03] <jmkasunich> if you are skipping 2 or more then there is a gain
[02:29:10] <SWPadnos> yep
[02:29:16] <elson> Skipping over one reg is likely no big deal.
[02:29:39] <SWPadnos> all the logic would probably run in less CPU time than waiting for one epp write though
[02:30:00] <jmkasunich> elson: is there some specific reason that you are using direct writes to the index control regs, instead of the cache?
[02:30:06] <jmkasunich> are they skipped normally?
[02:30:31] <elson> On the univ. stepper, the velocity write is 3 bytes/axis, but the way the numbers work, they generally all get used.
[02:30:51] <jmkasunich> SWPadnos: an EPP address cycle takes as long as an EPP data cycle
[02:31:11] <elson> Maybe being able to skip the whole block of digital I/O, which rarely changes, could save some time.
[02:31:28] <jmkasunich> so "data1, usless data2, data3" is just as bad as "data1, addr3, data3"
[02:31:34] <SWPadnos> yes
[02:31:47] <SWPadnos> but 3 axes not getting updated while the fourth is would be a win
[02:32:07] <jmkasunich> lets focus on the index problem for the moment
[02:32:20] <SWPadnos> anyway - just wondering. it isn't needed, and is probably more complex than the value it provides
[02:32:47] <elson> With a 600 MHz CPU, and mobo parport (which isn't too fast) the whole 4-axis servo update cycle is 80 us, including digital ins and outs!
[02:32:59] <jmkasunich> you'd need a second copy of the cache... when writing to the HW, you copy from the main cache to the copy
[02:33:18] <jmkasunich> the next time, you compare cache and copy
[02:33:34] <jmkasunich> if two or more items in a row haven't changed, you skip them
[02:33:41] <SWPadnos> yeah. figuring out what's a win would be the fun part (already there Iguess, since that has to be done when new registers are added to the map)
[02:34:06] <elson> right! I think I need to start picking at the code, and fix my ugly hack. Now that I actually understand how the thing is supposed to work, I think I can do it right.
[02:34:20] <jmkasunich> well, if you assume that an EPP cycle is 1000 times slower than just about anything else, then a win is anything that cuts down on EPP cycles
[02:34:47] <SWPadnos> and that would be true for anything ~1GHz or faster ... :)
[02:35:00] <jmkasunich> ok, for 100MHz, its only 100 times slower
[02:35:13] <elson> Well, but what does it buy you? The worst case is having to write everything, and you can't set the servo cycle faster than worst case time.
[02:35:22] <jmkasunich> elson: exactly right
[02:35:56] <jmkasunich> so lets forget we even mentioned that idea
[02:35:59] <SWPadnos> yep - like I said, curious and probably not worth the time ... :)
[02:36:06] <SWPadnos> forget what?
[02:36:19] <elson> Well, I have to go eat, and then maybe do some reading and figure out what the HECK I wrote 2 months ago!
[02:37:09] <elson> As it is, with a decent computer and reasonable parport, you can probably make it to 10 KHz servo cycle. That should be good enough!
[02:37:19] <jmkasunich> yep
[02:37:52] <elson> Thanks again for the help understanding how everything hooks together!
[02:38:25] <SWPadnos> sorry for the sidetrack there :)
[02:38:32] <jmkasunich> you're welcome
[02:38:36] <elson> No prob!
[02:40:15] <jmkasunich> SWPadnos: on a completely different topic....
[02:40:19] <SWPadnos> ja
[02:40:24] <jmkasunich> what do you use if you need to breadboard hardware?
[02:40:26] <jmkasunich> a few chips, etc
[02:40:39] <jmkasunich> wirewrap seems so 1970s
[02:40:49] <cradek> a milling machine
[02:40:58] <jmkasunich> :-P
[02:40:59] <SWPadnos> for DIP parts, the standard radio shack many-hole thingies
[02:41:03] <skunkworks> I was going to say that :)
[02:41:06] <cradek> wirewrap sucks
[02:41:16] <jmkasunich> perfboard, or the plastic ones with the metal contacts inside?
[02:41:20] <SWPadnos> for most things though, I use SMT and therefore cheap proto board companies
[02:41:23] <SWPadnos> plastic/metal
[02:41:50] <cradek> do you mean 'solder up permanently' or 'wire up to test'?
[02:42:00] <jmkasunich> once a design is more than a wild idea protoboard (or milled board) is fine
[02:42:08] <jmkasunich> but the earliest stages are too fluid for that
[02:42:14] <jmkasunich> especially the companies
[02:42:28] <cradek> oh wire up to test - definitely the plastic boards with springy contacts
[02:42:27] <skunkworks> made a lot of things on those white breadboards.
[02:42:41] <cradek> I have a nice big one with power supply banana connectors
[02:42:49] <SWPadnos> yep - them's the ones
[02:42:54] <skunkworks> always wanted one of those
[02:42:54] <jmkasunich> I'm thinking of stuff like testing serial ADC to FPGA links, etc
[02:43:13] <skunkworks> low freqency and low power work fine'
[02:43:36] <jmkasunich> I bet 5-10MHz serial links don't count as low frequency
[02:43:38] <SWPadnos> I'd make boards then - you're probably looking at multi-MHz serial comms
[02:43:44] <cradek> that stuff is all surface mount isn't it?
[02:43:59] <jmkasunich> pretty much
[02:44:14] <cradek> then you're stuffed
[02:44:29] <jmkasunich> the other thing I'm gonna want to breadboard is availalbe in dip or soic
[02:44:34] <SWPadnos> also connectors are rarely on 0.1" centers (other than headers)
[02:45:01] <jmkasunich> yeah - the "real thing" will definitely be a board
[02:45:16] <cradek> jepler and I have made some whatever-to-0.1" boards for certain ports
[02:45:23] <cradek> db9/db25, usb, etc
[02:45:31] <cradek> parts
[02:45:33] <cradek> dammit
[02:45:40] <jmkasunich> soic to 0.1 ?
[02:45:46] <jmkasunich> ie soic to dip
[02:45:46] <cradek> I've done that too
[02:45:49] <cradek> yes
[02:46:07] <SWPadnos> http://www.4pcb.com has pretty inexpensive low-cost options - $33/ea for 3 of something with full mask/legend
[02:46:18] <jmkasunich> thats still $100
[02:46:23] <jmkasunich> fine if I'm gonna use it
[02:46:25] <cradek> that's still $100 each try
[02:46:37] <SWPadnos> or the bare bones option - $really cheap, but no mask/legend (still plated through though)
[02:46:38] <fenn> there's a zillion tutorials on toner transfer on thenet
[02:46:44] <jmkasunich> not so fine if its an excersise in finding out what doesn't work
[02:46:49] <skunkworks> * skunkworks likes solder mask.
[02:47:12] <jmkasunich> fenn: I've done "etch it yourself" boards
[02:47:13] <cradek> fenn: I've only had marginal success with that - UV is the way to go, but more expensive
[02:47:19] <jmkasunich> I'm cheap, but not that cheap
[02:47:22] <SWPadnos> heh
[02:47:22] <cradek> ha
[02:47:30] <fenn> cradek: from what i've heard, toner transfer works better than photo-mask
[02:47:30] <cradek> jmkasunich: finish your mill first...
[02:47:32] <SWPadnos> they're not so easy for SMT stuff either
[02:47:48] <skunkworks> I soldered the headers on the pluto board last week - the solder mask is great.. I guess it has been a while since I have soldered a board like that.
[02:47:50] <cradek> fenn: I could never get a good transfer, but only tried a few times
[02:47:58] <cradek> (I think any etching is a pain in the ass)
[02:48:09] <SWPadnos> solder mask is what makes it possible for humans to solder 0402 parts ... :)
[02:48:16] <cradek> SWPadnos: wimp :-)
[02:48:18] <cradek> bbl
[02:48:18] <jmkasunich> cradek: even with milling, the development cycle is long compared to wirewrap or solderless breadboard
[02:48:21] <fenn> what you need 0402 parts for anyway?
[02:48:26] <SWPadnos> small things
[02:49:29] <jmkasunich> cradek: not so much the first trip round the cycle, but the modification time
[02:49:40] <jmkasunich> (assuming you can't use cut/jumper)
[02:49:41] <skunkworks> jmkasunich: I really don't think it is that bad.. depends on how big the project is - with a vaccum table I can do double sided boards pretty quick. Then I scrape traces to modify the board - or mill another one.
[02:50:01] <SWPadnos> jmkasunich, usually, the low cost manufacture options have a base cost plus some very low cost per sq.in.
[02:50:27] <jmkasunich> right, thats why no matter what you do, you aren't gonna get much below $100 per turn
[02:50:32] <SWPadnos> you can make 3 or 4 circuits on a single board and get a few of them. each would allow you to prototype a few things
[02:50:36] <jmkasunich> fine once the design is stable
[02:50:40] <SWPadnos> $50-60 is the low end
[02:50:59] <jmkasunich> still an incentive to keep the number of turns low
[02:51:06] <SWPadnos> there's also olimex, which will give you baords for free if you release the design as open wource (or something like that)
[02:51:07] <jmkasunich> and to plan ahead so you can proto several different circuits
[02:51:11] <SWPadnos> err - source
[02:51:24] <jmkasunich> the exact opposite of "play with whatever interests you at the time" development
[02:52:08] <jmkasunich> this one: http://www.olimex.com/pcb/ ?
[02:52:14] <SWPadnos> yes
[02:52:21] <SWPadnos> they used to do that, not sure they still do
[02:53:43] <jmkasunich> $33 for 6.3x3.9 double sided plated thru
[02:53:46] <jmkasunich> not bad
[02:53:55] <SWPadnos> no mask or legend though, right?
[02:54:02] <skunkworks> oooh - plate thru - I like that also. :)
[02:54:30] <jmkasunich> made in Bulgeria
[02:54:55] <jmkasunich> silkscreen is $5 extra
[02:55:48] <skunkworks> I have made circuits at work (silk screening company) - never re-screened a solder mask though - never really thought of that.
[02:56:23] <SWPadnos> http://www.pcbfabexpress.com tends to be better on the really bare boards, in my experience
[02:56:26] <jmkasunich> silkscreen in this context = legend, not soldermask
[02:56:37] <skunkworks> for my self. - actually was a stepper drive a long time ago.
[02:56:38] <SWPadnos> for "nicer" boards, Advanced Circuits is better
[02:57:26] <jmkasunich> the $33 does include mask btw
[02:57:46] <jmkasunich> oh, it also includes single side legend
[02:57:49] <SWPadnos> oh, cool
[02:57:52] <jmkasunich> the $5 is for bottom side legend
[02:58:04] <SWPadnos> so it includes top legend as well?
[02:58:12] <jmkasunich> yeah
[02:58:17] <SWPadnos> and you can buy just one at that price?
[02:58:23] <jmkasunich> one 6.3x3.9
[02:58:49] <jmkasunich> and if your board is smaller, they will panelize multiple copies of you artwork, and then cut them apart, for free
[02:59:21] <SWPadnos> ok. that's pretty good. pcbfabexpress has a minimum of 5 pieces, but $10/board prices (for 10 sq.in), 2 side mask, 1 side screen
[02:59:48] <jmkasunich> this is 24 sqin, for $33
[03:00:19] <SWPadnos> 10 sq. in per board, so 50 total for $50 (but only 5 pieces, even if they're 2 sq. in.
[03:00:21] <SWPadnos> )
[03:00:26] <jmkasunich> pcfabexpress is 50 sqin for $50, but you get five copies of the same 10sqin board
[03:00:31] <SWPadnos> rigth
[03:00:35] <SWPadnos> right
[03:01:16] <jmkasunich> olimex also offers 12.6x7.8 (98 sqin) for $132
[03:02:00] <SWPadnos> strange size - 320x200 mm
[03:02:19] <SWPadnos> it's probably 1/2 or 1/4 panel
[03:02:34] <jmkasunich> the smaller one is 160x100, they call it Euro format
[03:02:44] <jmkasunich> the larger is twice as wide and long
[03:02:50] <SWPadnos> right - also happens to be the max size for eagle free, right?
[03:03:06] <jmkasunich> might be
[03:03:19] <jmkasunich> they take eagle files btw
[03:03:37] <SWPadnos> that is an advantage for you with Olimex
[03:05:03] <jmkasunich> they have some interesting info on their design tips page
[03:05:17] <jmkasunich> the time for a tool change (drilling machine) is the same as the time to drill 100-200 holes
[03:05:59] <SWPadnos> actually, in a recent CCED discussion, they were talking about 300kRPM spindles on Excellon machines ...
[03:07:08] <SWPadnos> they need to optimize their tool change operation. They should be braking the spindle as they move toward the carousel, and spinning back up on the way to the next drill location ;)
[03:07:21] <jmkasunich> shipping is $9 for regular airmail (8-14 days), and $55! for 2-3 days
[03:07:42] <SWPadnos> heh - I believe you did mention Bulgaria ;)
[03:07:49] <jmkasunich> yeah
[03:08:03] <cradek> after trying the board houses I prefer any process I can do in my basement, even if it's perfboard and point-to-point wiring
[03:08:20] <SWPadnos> I got a package of Opto-22 relays from there. it was impossible to track the package, even though there was a tracking number (same from HK)
[03:08:46] <cradek> (any process is fast compared to 14 days)
[03:08:51] <jmkasunich> cradek: yep
[03:09:13] <SWPadnos> plus the 3-5 business days to manufacture the board
[03:09:18] <jmkasunich> milling is attractive, but I really like plated thru holes
[03:09:28] <cradek> yeah the holes are the drawback.
[03:09:37] <SWPadnos> and alignment of DS boards can be tricky
[03:09:41] <cradek> you learn tricks to deal with it - using DIP leads as thru holes
[03:10:05] <cradek> but that rules out low profile sockets
[03:10:20] <jmkasunich> anyway, this has digressed from the original topic, which was quick and dirty prototyping
[03:10:28] <jmkasunich> solderless breadboards if slow enough
[03:10:33] <SWPadnos> sorry - no experience there ;)
[03:10:45] <jmkasunich> otherwise maybe perfboards, but those will have speed issues too
[03:10:46] <SWPadnos> err - except for the solderless crap from time to time :)
[03:11:18] <jmkasunich> one of the things I was thinking about the other day was I/O expansion for the 5i20
[03:11:25] <SWPadnos> if the local radio shacks still have actual prototyping stuff, you can get adapter boards for several SOIC patterns to multi-hole (probably on 0.1" spacing) layouts
[03:11:44] <jmkasunich> once you start loading the FPGA up with encoder counters and PWMgens, and such, you don't have lots of regular I/O pins left
[03:12:16] <SWPadnos> yeah - dropping a 5807 or something off a serial shift register would be a good thing (like the G-Rex)
[03:12:24] <cradek> RS doesn't have anything like that anymore
[03:12:45] <SWPadnos> they sometimes do in the celarance section ;)
[03:12:49] <SWPadnos> clearance
[03:13:06] <jmkasunich> I came up with a scheme that lets you use about 40 FPGA flip-flops and 4 pins to get 32 inputs and 32 outputs
[03:13:39] <jmkasunich> using good old 74HCTxxx shift registers on the outside
[03:13:47] <SWPadnos> sounds like clock, data, and 2 chip selects to me
[03:14:00] <jmkasunich> no, clock, strobe, data in, and data out
[03:14:01] <SWPadnos> ok, two pair of clock and data then :)
[03:14:10] <SWPadnos> ok
[03:14:25] <SWPadnos> that's just what Mariss put on the G-Rex
[03:14:31] <jmkasunich> an 8 bit shift register for input (parallel in, serial out) is $0.48 at digikey
[03:14:48] <jmkasunich> for output (serial in parallel out with an output register) is $0.96
[03:14:58] <SWPadnos> 595 and 458, it looks like
[03:15:19] <jmkasunich> 595 and 165 (maybe 164, don't have my notes handy)
[03:15:46] <jmkasunich> adding more I/O is in chunks of 32 bits, and requires only 32 FPGA flipflops and 2 more pins
[03:16:04] <SWPadnos> yep - 165 (I had been looking at the wrong section of the board :) )
[03:16:25] <jmkasunich> oh, those are the numbers Mariss used?
[03:16:26] <SWPadnos> you'll need more for the clock dividers, but it's definitely low resource usage
[03:16:28] <SWPadnos> yep
[03:16:46] <jmkasunich> thats why the first 32 bits used 40 FFs
[03:17:04] <SWPadnos> did you synthesize this, or is that an estimate?
[03:17:08] <jmkasunich> estimate
[03:17:29] <SWPadnos> ok. I suspect more are needed for clocks / synchronization
[03:17:42] <jmkasunich> maybe a few
[03:17:52] <cradek> do those PO shift registers have a parallel load?
[03:18:03] <jmkasunich> no
[03:18:13] <jmkasunich> you can get parallel out, or parallel in, but not both
[03:18:25] <jmkasunich> well, you can, but then you trade off something else
[03:18:42] <jmkasunich> the 595 and 165 combo seems like the best ones
[03:18:47] <cradek> I mean load the outputs from internal buffers (during shifting, you don't get wrong outputs)
[03:18:50] <SWPadnos> parallel in/out = a bus, which is what would be coming out of the FPGA anyway
[03:18:59] <jmkasunich> cradek: yes
[03:18:59] <SWPadnos> that's why you use FF's
[03:19:08] <jmkasunich> there is the shift register, and an output register
[03:19:13] <cradek> ah ok
[03:19:16] <SWPadnos> you clock them all once the shift is finished
[03:19:25] <jmkasunich> the clock shifts the data, and the strobe loads the output register
[03:19:30] <cradek> got it
[03:19:35] <cradek> I should have looked up the part
[03:20:14] <jmkasunich> basically the cycle is: write data to 32 bit registers in the FPGA, then the fpga asserts a signal that switches the input SR chips from parallel load mode to serial shift mode
[03:20:42] <jmkasunich> then you clock the input data into the FPGA register while clocking the output data from the _same_ register to the output SRs
[03:21:04] <jmkasunich> then you deassert the strobe signal, which latches the output data, and puts the input SRs back into parallel load mode
[03:21:15] <jmkasunich> then the driver reads the 32 bits of input data from the FPGA
[03:21:37] <jmkasunich> the driver needs to rewrite the output data every time, but thats no big deal
[03:21:54] <jmkasunich> halves the FF and logic usage in the FPGA ;-)
[03:22:15] <jepler> neat
[03:22:19] <SWPadnos> I'm not so sure that sharing ragisters is that easy in the FPGA ...
[03:22:31] <jmkasunich> ?
[03:22:44] <SWPadnos> lemme reread your explanation - one sec :)
[03:22:54] <jmkasunich> the mesa configs have several registers that can be both written and read by the CPU
[03:23:22] <SWPadnos> they're actually two registers that happen to get accessed from the same address
[03:23:28] <jepler> how fast can you clock the SR chips?
[03:23:30] <SWPadnos> in an FPGA, nothing is free
[03:25:16] <jmkasunich> SWPadnos: in pwmgen.vhd, I see:
[03:25:28] <jmkasunich> if loadpwmval = '1' then
[03:25:28] <jmkasunich> if unsignedmode = '0' then
[03:25:28] <jmkasunich> pwmval <= ibus(14 downto 5);
[03:25:30] <jmkasunich> and
[03:25:40] <jmkasunich> if readpwmval = '1' and pcrreadcmd = '0' then
[03:25:40] <jmkasunich> if unsignedmode = '0' then
[03:25:40] <jmkasunich> obus(14 downto 5) <= pwmval;
[03:25:50] <jmkasunich> the way I see that is pwmval being a row of FFs
[03:26:55] <jmkasunich> one FF per bit
[03:27:30] <SWPadnos> pwmval is an internal signal, not an "externally published" register
[03:27:44] <jmkasunich> jepler: the TTL shift registers can probably clock at several MHz
[03:29:11] <jepler> hm this datasheet gives 20MHz
[03:29:22] <jepler> ti's sn74hc594
[03:29:38] <jmkasunich> SWPadnos: lots of things in there have "loadfoo" and "readfoo" signals (sometimes not both for the same foo), and they sure as heck seem to be registers that the software can read/write
[03:29:47] <jmkasunich> dunno how those foo
[03:29:49] <jmkasunich> oops
[03:30:11] <jmkasunich> how those foos in the low level stuff map to the top level file where there are multiple instances of each low level thing
[03:30:27] <jmkasunich> jepler: yeah, I was being conservative
[03:30:44] <jmkasunich> I thought about using the PCI clock (33MHz) divided by maybe 4
[03:30:50] <SWPadnos> note that in hostmot5-4e.vhd, the pwmgen instantiation creates separate STD_LOGIC vectors for ibus and obus for each pwmgen
[03:31:43] <jmkasunich> are you sure?
[03:31:48] <SWPadnos> nope ;)
[03:31:54] <SWPadnos> but it looks that way to me :)
[03:32:14] <jmkasunich> doesn't "ibus => LAD (15 downto 0) mean "connect ibus of the instance, to the global signals LAD" ?
[03:32:34] <jmkasunich> kinda like HAL pins and signals ;-)
[03:32:52] <SWPadnos> I'm not sure your method is safe when the chip I/O is asynchronous relative to the PCI I/O (ie, you need both the read and write versions of the register available to both sides at all times)
[03:32:53] <jmkasunich> jepler: if you used PCI clock divided by 4, you could transfer 32 bits in 4uS
[03:33:02] <jmkasunich> way faster than any BASE_PERIOD
[03:33:21] <jmkasunich> SWPadnos: no, I cheat
[03:33:25] <SWPadnos> heh
[03:33:32] <jmkasunich> the driver would write the output data while the SRs are idle
[03:33:43] <SWPadnos> how does it know?
[03:33:46] <jmkasunich> then the 32 clocks would happen, and it would go idle again, for the read of input
[03:34:03] <jmkasunich> I'd have a busy bit somewhere
[03:34:34] <SWPadnos> I suspect that the logic savings is less valuable than the driver complexity
[03:34:41] <SWPadnos> this is a 200k gate chip, after all
[03:34:49] <jepler> in the case of pluto I would just assume the reads and writes would happen far enough apart, going as they do over the epp protocol which is glacial compared to 4uS
[03:34:55] <jmkasunich> although if it takes 4uS, and the transfer is initiated by the "write_bits" HAL function, while reading the input register is done by the "read_bits" HAL function, all I need to ensure is that read_bits is called at least 4uS after write_bits
[03:35:03] <jepler> yes exactly
[03:35:05] <SWPadnos> that's the problem I was getting to :)
[03:35:37] <SWPadnos> I suspect that a few hundred (or even a few thousand) gates would be better used than 4 or 8 uS of CPU time
[03:35:46] <jmkasunich> with a 10uS base period, if you call write_bits at the end of the thread, and read_bits at the beginning, you'll almost always have plenty of delay
[03:36:13] <SWPadnos> almost is only good enough in ...
[03:36:23] <jmkasunich> thats why you have the busy bit
[03:36:34] <skunkworks> jepler: I did have the period set to 1000000 - I think I was confused again (pluto)
[03:36:41] <skunkworks> 1ms
[03:36:43] <SWPadnos> I wonder how muych logis the busy bit takes :)
[03:36:50] <SWPadnos> gah - how much logic
[03:36:50] <jmkasunich> if for some reason one pass of the thread runs long (thus starting the transfer late) then the next pass will wait for the transfer to finish
[03:37:08] <SWPadnos> nearly guaranteeing that it also runs long ...
[03:37:09] <jmkasunich> busy = state counter != 0
[03:37:31] <SWPadnos> plus address decoding and that kind of thing (for a n existing status register, presumably)
[03:38:13] <jmkasunich> I'm not sure what you are getting at
[03:38:30] <SWPadnos> hmmm - I thought there was a file that showed the resource usage for the hostmot5-4 config
[03:38:36] <jmkasunich> having separate regsiters for input and output means doubling the number of flip-flops used
[03:38:45] <jmkasunich> that adds up fast,
[03:38:56] <SWPadnos> it's not all flip-flops
[03:39:01] <jmkasunich> considering that this thing can support 128 inputs and 128 outputs with 8 FPGA pins
[03:39:29] <jmkasunich> the state counter will have non-trivlal logic (a 5 bit counter, plus a little more stuff)
[03:39:56] <jmkasunich> but the registers scale linearly - one FF and one LUT based logic block per bit
[03:40:14] <SWPadnos> you can store 4 bits in a single block
[03:40:57] <SWPadnos> registers can actually be RAM that gets written after a complete shift cycle
[03:41:07] <jmkasunich> I thought each block consisted of 2 LUT based logic blocks (4 inputs, can be combined to give a 5 input function) and 2 FFs, with a few specific things like a clock enable mux on each FF
[03:41:10] <SWPadnos> and read when requested via PCI
[03:41:33] <SWPadnos> hmmm - lemme check (I don't know the architecture well enough to argue that)
[03:42:05] <SWPadnos> I just suspect that the total logic usage is much less important than the CPU load accessing the data
[03:42:10] <jmkasunich> we're picking nits here anyway, if implementation shows that separete input and output registers are cheaper, I'd do that
[03:42:28] <jmkasunich> the cpu load is just a 32 bit read for input and a 32 bit write for output
[03:42:30] <SWPadnos> and if the driver can be simplified by not having to handshake with the hardware, then that's a win too
[03:42:38] <SWPadnos> plus the wait for valid data
[03:42:46] <jmkasunich> the act of writing the output would trigger the 5 bit counter/state machine
[03:43:07] <SWPadnos> sure - the write is easy (though you can never get the period lower than 4 uS - no big deal)
[03:43:15] <jmkasunich> you'd want to read the status register and test the done bit, but unless you were really abusing things, it would _always_ be done in time
[03:43:50] <SWPadnos> well - it'll be interesting to see the needed logic
[03:44:00] <jmkasunich> suppose base period is 10uS, and the thread does: read-bits, stepgen-make-pulses, write-bits
[03:44:38] <jmkasunich> as long as the time from read-bits to write-bits is less than 6uS, then you'll have 4uS from write-bits to the next invocation of read-bits
[03:44:49] <SWPadnos> sure
[03:44:59] <jmkasunich> if its more than 6uS, then your base thread is using 60% of the cpu, which is a bit much IMO
[03:45:12] <jmkasunich> and you should make base period longer
[03:45:21] <jepler> what happens if you only run the read function and not the write function, or run them in different HAL threads?
[03:45:21] <jmkasunich> if its 20uS, you got tons of time
[03:45:27] <jmkasunich> then you're fscked
[03:45:29] <SWPadnos> anyway - you're right - we're picking nits (unimportant ones at that)
[03:45:30] <SWPadnos> heh
[03:46:42] <jmkasunich> my thoughts are that FPGA resources should be spend doing things that software can't do
[03:46:42] <SWPadnos> I guess that would be a jmk_mesa.read_write function then :)
[03:46:53] <SWPadnos> I agree with that
[03:46:58] <jmkasunich> like counting encoder pulses, or making PWM
[03:47:13] <SWPadnos> but the higher-level aim is to reduce the complexity and execution time of the accopmanying code
[03:47:16] <jmkasunich> or shifting bits
[03:47:33] <SWPadnos> assuming that I could spell tonight, that would have made sense :)
[03:47:45] <jmkasunich> it makes sense
[03:48:19] <SWPadnos> I guess my thought is that we shouldn't cut corners until we see that there isn't enough room for all the squares we want in the FPGA :)
[03:48:47] <jmkasunich> considering that these are PCI accesses, not ISA or parport, packing/unpacking 32 HAL pins into a 32 bit word to be written/read from the FPGA will take longer than the rest of the interaction with the FPGA
[03:48:58] <jmkasunich> and the serial transfer itself takes place in parallel with other stuff
[03:49:10] <SWPadnos> that's true
[03:49:26] <SWPadnos> I'm not sure how the parallel read / parallel-write / serial in/out shift register will work though
[03:49:34] <jmkasunich> the real driving force behind this isn't to get the number of FFs down, its to conserve the 72 I/O pins
[03:49:50] <SWPadnos> I suspect it may take more logic than you think, but I certainly don't know enough to be sure
[03:49:58] <jmkasunich> I counted up all the stuff I might want in my wildest Shoptask config, and 72 is cutting it very close
[03:50:29] <jmkasunich> I don't know enough to be sure either
[03:50:32] <SWPadnos> a little 32-in / 32-out (preferably isolated) I/O device would be great
[03:51:04] <jmkasunich> but I'll be very very angry if the tools don't let me get one input and one output per FF (not counting the state machine, which is amortized over all the I/O)
[03:51:15] <SWPadnos> ok - each CLB can be configured as a 16x1 synchronous RAM
[03:51:59] <jmkasunich> to keep the SW overhead down I'd want 32 bit PCI transfers, so you're talking 32 CLBs right off
[03:52:16] <SWPadnos> ?
[03:52:27] <jmkasunich> 16x1...
[03:52:32] <SWPadnos> there's a 32-bit internal bus already, I think (with the mesa configs anyway)
[03:52:35] <jmkasunich> if you want N x 32, you need 32 CLBs
[03:52:42] <jmkasunich> exactly
[03:52:50] <SWPadnos> no, it's 16 bits wide and 1 bit deep, I thinkbut
[03:52:59] <SWPadnos> -but
[03:53:09] <jmkasunich> bet it 16 deep and 1 wide
[03:53:17] <jmkasunich> a 1 deep ram isn't a ram, its a register
[03:53:24] <jmkasunich> no address lines needed ;-)
[03:53:24] <SWPadnos> heh -true enough
[03:54:05] <SWPadnos> consider what each bit in your register needs to do though - first, you probably want to protect it while in use
[03:54:13] <jmkasunich> I bet that with 16 CLBs you can build a 32 bit shift register than can be written to from the internal bus, read by the internal bus, or shifted (not at the same time of course)
[03:54:22] <SWPadnos> you don't necessarily want a rogue write to screw up an in-process transfer
[03:55:07] <jmkasunich> I wouldn't try to protect it in hardware
[03:55:25] <jmkasunich> hardware resources get consumed whether you are using them or not
[03:55:56] <jmkasunich> a software loop that busy waits on a "busy" bit in a status register only consumes time when you attempt a write at the wrong moment
[03:56:11] <SWPadnos> true
[03:56:27] <jmkasunich> the busy bit would actually be the strobe signal, so it costs nothing
[03:56:40] <SWPadnos> I'm a fan of double-buffering though: write when you want, read when you want, the hardware takes care of the rest
[03:56:53] <jmkasunich> the status register costs something, but I assume that can be spread over multiple things - lots of status in a part that big
[03:57:00] <SWPadnos> you always get a consistent number, even if it isn't the latest (like HAL)
[03:57:11] <jmkasunich> different philosophies then
[03:57:17] <SWPadnos> yep :)
[03:58:03] <jmkasunich> since this config would only be used with the matching HAL driver, I have no reservations at all about making the driver smarter
[03:58:29] <SWPadnos> I guess I like hardware that's harder to screw up, but you're right - the driver is the real interface to it
[03:59:24] <jtr> Older topic - quick and dirty breadboarding option (may not be applicable) is described in http://www.k7qo.net/manhattan.pdf
[04:00:02] <jtr> also http://www.ke6us.com/construction_tips.htm
[04:01:11] <jtr> with manhattan construction, you take little pieces of pc board, glue them to a main board, and use them as tie points.
[04:01:48] <jmkasunich> jtr: interesting, but seems more applicable to analog circuits (where there are fewer but more complex circuit nodes) than digital
[04:02:25] <jtr> DIPs take bigger pieces of copper clad with arrays of pads.
[04:03:23] <jtr> Agreed, but possibly as good as the white breadboards. you do get a ground plane.
[04:03:34] <jmkasunich> thats true
[04:03:40] <jtr> Depends on what you're doing.
[04:06:15] <jtr> wouldn't do a m5i20, but might be applicable to specialized i/o
[04:12:23] <jmkasunich> jtr: thanks, thats a handy technique to add to the arsenal
[04:12:42] <jmkasunich> not what I'm looking for at the moment, but good to know anyway
[04:14:29] <jtr> cool. I had seen it years ago and never tried it - just saw it again a month ago, a week after I could have used it.
[04:14:42] <skunkworks> Time for bed - night
[04:21:19] <jmkasunich> any VM experts out there? Is there a way to suspend VMs from a script instead of using the vmware console?
[04:22:16] <jmkasunich> looks like there are some Perl intefaces
[04:22:16] <cradek> vmware-cmd -?
[04:22:55] <jmkasunich> jmkasunich@ke-main-1006:~$ apropos vmware-cmd
[04:22:55] <jmkasunich> vmware-cmd: nothing appropriate.
[04:23:16] <cradek> no manpage - crappy packaging
[04:23:17] <cradek> vmware-cmd -?
[04:23:26] <cradek> /usr/bin/vmware-cmd <cfg> suspend <powerop_mode>
[04:23:26] <cradek> -- suspends a VM
[04:23:37] <jmkasunich> duh
[04:23:38] <jmkasunich> thanks
[04:23:48] <jmkasunich> (I just figured out that it has built in help)
[04:25:18] <SWPadnos> you'll be happy to see VMWare 6 - you can actually run the VMs in the background - no GUI at all
[04:25:47] <jmkasunich> I only start the GUI when I want to interact with the VMs, usually its not running
[04:26:02] <SWPadnos> but the VMs are ?
[04:26:07] <jmkasunich> yes
[04:26:40] <SWPadnos> interesting - I guess they should take that off their bulelt list of improvements then :)
[04:33:52] <jmkasunich> cradek: do you know what goes in the <cgf> spot? I've tried the config file (.vmx) and the directory holding all the files for that VM
[04:34:25] <jmkasunich> jmkasunich@ke-main-1006:~/vmware/VMs/VM02-breezy-nonrt$ vmware-cmd VM02-breezy-nonrt.vmx getstate
[04:34:25] <jmkasunich> /usr/bin/vmware-cmd: Could not connect to VM VM02-breezy-nonrt.vmx
[04:34:25] <jmkasunich> (VMControl error -14: Unexpected response from vmware-authd: Invalid pathname: VM02-breezy-nonrt.vmx)
[04:35:29] <jmkasunich> duh
[04:35:41] <jmkasunich> gotta register them first
[04:36:26] <jmkasunich> no, they are already registered
[04:39:52] <SWPadnos> have you tried specifying the full path to the .vmx files?
[04:40:28] <jmkasunich> that worked
[04:40:29] <jmkasunich> lame
[04:40:36] <SWPadnos> indeed
[04:42:24] <SWPadnos> hmmm - I hope nobody gets annoyed at my mentioning emc2/mesa on the geckodrive list
[04:43:00] <Jymmm> SWPadnos phuk em they can't take a joke.
[04:43:30] <SWPadnos> well, the list is owned by gecko, so there is a lot of frowning on promoting other competing products
[04:43:53] <Jymmm> geckos plug into a mesa board, right?
[04:43:53] <jmkasunich> why are you mentioning it at all?
[04:44:22] <SWPadnos> a guy wants to retrofit a CHNC, and was asking about geckos/mach (and wondering about spindle synch, etc)
[04:44:35] <jmkasunich> hmm, "vmware-cmd <full-path-to-config-file> start" will start a suspended VM
[04:44:42] <SWPadnos> I pointed out that EMC2 has spindle synch, and with the emsa card, he may be able to keep his drivers
[04:44:58] <jmkasunich> but "vmware-cmd <full-path-to-config-file> suspend" won't suspend a running one
[04:45:05] <SWPadnos> (they're the original PWM drivers that are nicely matched to the motors)
[04:45:08] <SWPadnos> odd
[04:45:29] <jmkasunich> jmkasunich@ke-main-1006:~/vmware$ vmware-cmd /home/jmkasunich/vmware/VMs/VM02-breezy-nonrt/VM02-breezy-nonrt.vmx suspend
[04:45:29] <jmkasunich> VMControl error -8: Invalid operation for virtual machine's current state: Make sure the latest version of VMware Server Tools are running
[04:45:48] <jmkasunich> I have no idea what <powerop_mode> is supposed to be
[04:45:54] <jmkasunich> for start I left it out and it worked
[04:46:01] <SWPadnos> someone had mentioned serovs being "closed loop to the gecko" I think - I wanted to point out that there is a better alternative
[04:46:09] <SWPadnos> http://www.vmware.com/support/esx2/doc/vmware-cmd.html
[04:46:44] <ejholmgren> them's fightin' words
[04:46:59] <SWPadnos> indeed
[04:47:05] <SWPadnos> but only for low-vbrow losers
[04:47:08] <SWPadnos> err - hi :)
[04:47:13] <ejholmgren> ;)
[04:48:00] <ejholmgren> last I read was "There is no HARDWARE limitation"
[04:49:12] <SWPadnos> strange - that's a roughly 20-minute timeout
[04:50:15] <ejholmgren> bitchx on osx must not be good about keeping the connecion alive
[04:50:30] <ejholmgren> connection
[04:50:36] <SWPadnos> or they use modem-scale connection timeouts for IRC :)
[04:51:47] <ejholmgren> just got done making a few heads for the 3 knife trimmer at work
[04:52:09] <ejholmgren> PITA to make by hand, need to get the cnc router up and going
[04:54:26] <SWPadnos> you know - I bet quickstep can't do "quick-quadrature-input"
[05:15:58] <jmkasunich> thanks for the help - I now have scripts that will suspend and resume the farm slots automatically
[05:16:05] <SWPadnos> cool
[05:16:17] <jmkasunich> handy when I want to do something that requires all of the memory in this box, like FPGA work
[05:16:23] <SWPadnos> heh
[05:16:31] <SWPadnos> and all the CPU horsepower
[05:16:35] <jmkasunich> that too
[05:16:47] <jmkasunich> although the CPU load is light when the slots aren't doing compiles
[05:17:38] <SWPadnos> the FPGA compiles under LabView were all done by the Xilinx tools, and placing 1.5M gates (50% of the 3M gate chip) took ~40 minutes on my big box
[05:17:58] <SWPadnos> so it wasn't spending a lot of time trying to get stuff to fit
[05:18:09] <jmkasunich> actually, the sleeping slots do amount to 20% load
[05:18:24] <SWPadnos> timekeeping on the guests, I'll bet
[05:18:30] <jmkasunich> yeah
[05:18:43] <jmkasunich> with them suspended the base load is abotu 2%
[05:18:45] <jmkasunich> about
[05:18:52] <SWPadnos> that's a lot better
[05:18:59] <SWPadnos> this is the Sempron 3000 or so?
[05:19:08] <jmkasunich> yeah
[05:19:14] <jmkasunich> 2800
[05:19:20] <SWPadnos> ah - ok
[05:19:53] <SWPadnos> I'd be curious to see what one of those FPGA recompiles takes now, with the CPU upgrade
[05:20:10] <SWPadnos> but not curious enough to boot up the Win2k disk and run LabView
[05:20:18] <jmkasunich> heh
[05:22:08] <ejholmgren> is the compile farm multiple machines?
[05:22:14] <jmkasunich> not any more
[05:22:24] <jmkasunich> multiple virtual machines running on my main computer
[05:22:42] <SWPadnos> cool - I nearly hit desk on one side of my keyboard, and I found my Actel FPGA softeware :)
[05:40:42] <jmkasunich> goodnight all
[05:40:48] <Jymmm> nite jmkasunich
[08:52:09] <A-L-P-H-A> bored
[08:56:22] <fenn> do something
[09:24:08] <A-L-P-H-A> dunno what
[10:13:41] <lerneaen_hydra> 'lo
[10:14:04] <anonimasu> hello
[10:15:46] <lerneaen_hydra> anything fun happening?
[10:19:38] <anonimasu> looking at canbus io modules
[10:20:50] <lerneaen_hydra> oh, cool. btw, stepper motors for a 1:1 drive for a smaller mill, would they cost around 1000sek or so (say, between 500 and 1500)?
[11:21:15] <anonimasu> something like that
[14:19:54] <etla> hi all
[14:20:53] <skunkworks> Hi
[14:21:49] <etla> what's up ?
[14:22:54] <skunkworks> work :)
[14:24:02] <skunkworks> nice work on the PyVCP - one of these days I will get to the point of using more of emc
[14:27:51] <etla> thanks, it took a couple of hours of effort during 2-3 days...
[14:28:17] <etla> but it seems to be working, and I was pleasantly surprised by how fast jepler could integrate it with AXIS
[14:28:56] <skunkworks> very nice
[14:30:08] <tomp> hello
[14:31:48] <skunkworks> hello
[14:31:58] <skunkworks> how is ubuntu coming?
[14:32:02] <skunkworks> (dapper)
[14:33:31] <tomp> me? I' got a new install put together & it works, the solutrion was to trash it all & build new starting at partitioning :)
[14:34:17] <tomp> i went onto freshmeat & saw a new gCAD3D and got that, been looking at it, seems to have APT built
[14:34:48] <tomp> and got last few days logs about python vcp stuff, amazing fast changes!
[14:35:29] <tomp> hope you had a good New Year's
[14:36:04] <anonimasu> not muhhm
[14:36:13] <anonimasu> got a picture about the axis integration?
[14:37:21] <tomp> looking in logs...
[14:38:55] <jepler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?PyVCP
[14:38:58] <jepler> http://wiki.linuxcnc.org/uploads/lathe_sim_pyvcp.png
[14:39:18] <jepler> (the image is what you get running configs/sim/lathe.ini in HEAD)
[14:40:03] <etla> jepler: do you know all the stuff that runs in the background of sim/lathe ?
[14:40:16] <etla> it seems to require much more resources than just sim (axis)
[14:40:43] <etla> but I'm running under vmware, so on native ubuntu sim/lathe might run just fine
[14:40:53] <jepler> etla: it includes a simulation of a spindle with encoder and index pulse, so there are things running on the "fast" thread (50uS)
[14:41:13] <jepler> the reguar sim/axis.ini only has things running in the "slow" thread (1ms)
[14:41:17] <skunkworks> <troll>thats starting to look like mach</troll> :) just need some more flashing lights.
[14:42:29] <tomp> jepler: got the picture: can the new control panels be standalone ( or tear-away ?)
[14:43:40] <jepler> tomp: when etla started, it was a standalone window -- that might be temporarily broken, but if it is that functionality will be restored somewhere along the line
[14:47:11] <tomp> i like the idea of a cnc desktop , where i put the XYZ DRO where i want it & as big & as transparent as I like... able to cfg my cnc display for me... i thought that meant individual widgets in moveable sizeable windows, with some form of IPC like dcups or nml or..., this VCP2 is getting close :)
[14:55:37] <etla> tomp: I agree! I'm hoping to show the part/tool offsets + axis load (PID output) for each axis etc.
[14:56:31] <etla> jepler: are you maintaining www.linuxcnc.org, or is it alex's "job"
[15:02:04] <etla> I was thinking that one way to get more 'life' into www.linuxcnc.org would be to have a script that aggregates emc-related news from a number of developer blogs. most developers seem to have blogs anyway where they publish stuff. Now the frontpage is pretty static with only a small announcement for each release
[15:07:57] <jepler> etla: that's an interesting idea
[15:08:05] <jepler> etla: I have some kind of login on linuxcnc.org but I never use it
[15:08:56] <jepler> there are probably many programs for doing that, I'm using "planet" for my personal feeds: http://unpy.net/planet/
[15:09:06] <jepler> but I doubt it integrates with the joomla that is used for the rest of the site
[15:09:20] <etla> jepler: OK. I bet there are standard plugins for Joomla that do RSS aggregation. A developer would need to have a site that supports RSS, create a special category 'emc' that get's published on www.linuxcnc.org and somehow register the site
[15:10:30] <etla> jepler: ha, some familiar posts in that list!
[15:10:48] <jepler> my personal blog and the axis blog support ATOM but I don't do tags/categories
[15:13:12] <etla> so at least RSS and ATOM would have to be supported. and somehow the emc-related posts filtered from personal stuff (categories would be an easy solution)
[15:14:35] <jepler> for myself, I would just make sure "everything emc" went to the axis blog, not my personal blog
[15:16:56] <etla> I would create a new category, emc, which could also go on linuxcnc.org. The whole posts need not be on linuxcnc.org, but at least the title and a bit of text and a link.
[15:18:31] <jepler> what I mean is that everything from axis.unpy.net would be suitable for showing on the linuxcnc page -- it's all about emc
[15:20:12] <etla> yes, I understand. I might suggest something like this to Alex when he's around.
[15:20:48] <jepler> my guess is that he will like the idea
[15:23:12] <etla> damn. after all this python at home - matlab at work feels strange
[15:23:48] <jepler> I've never done matlab -- are there enough similarities that you can forget which one you're programming at the moment?
[15:24:27] <etla> jepler: well it's weakly typed (I think that's the correct term), so you can assign stuff any way you want
[15:24:41] <etla> but whitespace doesn't work as smartly as in python
[15:29:15] <jepler> I see
[15:29:28] <jepler> I'm happy every day I get to work with Python, and unhappy whenever it's C, C++ or tcl
[15:30:05] <etla> but matlab definitely has 'batteries included' when it comes to scientific calculations - very suitable for rapid prototyping etc
[15:31:23] <jepler> python has a respectable matrix module as an add-on, but easy to get in ubuntu. have you tried it? http://numpy.scipy.org/
[15:32:29] <jepler> (actually there are about 3: numeric, numarray, and numpy -- I have no clue which is best, though I think numeric is oldest and numpy the newest)
[15:32:34] <etla> I've looked at it but not tried it.
[15:32:54] <etla> there's also something called octave for linux which is a 'free matlab'
[15:33:38] <jepler> hmm http://matpy.sourceforge.net/
[16:10:10] <tomp> ? the spindle speed shows 543.5, the mdi textentry sez m3s2000, the spindle override is at 100% ? is it accelerating? http://wiki.linuxcnc.org/uploads/lathe_sim_pyvcp.png
[16:10:33] <cradek> it might have been accelerating
[16:10:54] <cradek> the sim/lathe config has simulated physics on the spindle to make testing new lathe features easier
[16:11:11] <etla> tomp: yes, it's accelerating. under vmware, my sim/lathe is pretty slow
[16:11:29] <etla> almost unusable
[16:12:02] <cradek> if under vmware you should build with --enable-simulator
[16:12:17] <tomp> gotcha. nice work on pvvcp etla, thanks!
[16:12:19] <cradek> it will probably run a lot better if you don't try to do realtime
[16:12:46] <etla> does everything work as normal with --enable-simulator ?
[16:18:00] <tomp> anyone looked at rtai/scilab/scicos?
[16:20:23] <cradek> etla: as far as I know, everything except hardware access works
[16:20:40] <jepler> you can't do things like lock up your machine with a bad choice of BASE_PERIOD though
[16:20:50] <SWPadnos> and of course it's not RT, so you shouldn't run a machine with it
[16:21:36] <SWPadnos> tomp, not too closely, but I have looked at them a little
[16:22:03] <SWPadnos> I think in the context of a GUI for HAL configuration
[16:22:16] <SWPadnos> (not as a LabView replacement or the like)
[16:36:47] <lerneaen_hydra> * lerneaen_hydra gasp!
[16:37:02] <lerneaen_hydra> did SWPadnos mention labview, and not insult it at the same time?
[16:37:12] <lerneaen_hydra> then again, he said as a labview replacement
[16:37:12] <SWPadnos> sorry - I hadn't had enough coffee
[16:37:35] <lerneaen_hydra> Hmm, I suppose I'll overlook this matter, but only this time
[16:37:41] <SWPadnos> ok. thank you
[16:37:56] <lerneaen_hydra> * lerneaen_hydra feels so generous today
[16:37:58] <lerneaen_hydra> ;)
[16:38:13] <SWPadnos> must be your new years resolutions kicking in, huh?
[16:38:37] <lerneaen_hydra> oh, absolutely
[17:18:47] <Guest551> heloo happy new yar for
[17:18:48] <Guest551> all
[17:18:58] <Guest551> and good bless you
[17:19:39] <Guest551> friends a like know a make m codes
[17:20:02] <Guest551> i know this is m100 a m199
[17:20:12] <Guest551> how to make this?
[17:20:16] <Guest551> please
[17:20:47] <SWPadnos> Hi Rafa - happy new year
[17:20:51] <SWPadnos> place an executable file called M109 (for example) in your G-code directory
[17:21:04] <SWPadnos> must be capital m: M109, not m109
[17:21:22] <Guest551> hi
[17:22:13] <Guest551> i make a one programa for this?
[17:22:42] <SWPadnos> each custom M code is a separate program
[17:22:48] <lerneaen_hydra> SWPadnos: does the file have to be executable?
[17:22:53] <SWPadnos> yes
[17:23:06] <Guest551> for exemple:
[17:23:58] <lerneaen_hydra> SWPadnos: what type of language are mcodes written in?
[17:24:03] <lerneaen_hydra> hal-commands?
[17:24:06] <SWPadnos> anything that can be executed ...
[17:24:18] <Guest551> I want to bind an motor
[17:24:21] <SWPadnos> shell script, perl, python, C, C++, fortran ...
[17:24:39] <lerneaen_hydra> oh, nice
[17:24:54] <lerneaen_hydra> and it sends parameters to the mcode nicely?
[17:24:58] <SWPadnos> (not that there's a Fortran NML or HAL library, but still ...)
[17:25:12] <SWPadnos> there are two parameters for custom M codes - P and Q
[17:25:13] <lerneaen_hydra> like m101 -p 24 sends -p 24 to the app via stdin?
[17:25:41] <SWPadnos> I think it sets an environment variable, but I don't remember for sure
[17:25:55] <lerneaen_hydra> ok
[17:26:21] <Guest551> for example m7 and m8 set in motion the refrigeration
[17:26:22] <SWPadnos> nope - they are passed on the command line
[17:26:33] <Guest551> make this in C?
[17:26:51] <SWPadnos> Guest551, you can't change the operation of any M code under 100. only codes 100-199 work this way
[17:27:04] <Guest551> ?
[17:27:08] <SWPadnos> an example provided with emc2: http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/nc_files/M101?rev=1.3
[17:27:20] <Guest551> i see this
[17:27:32] <SWPadnos> and a C example: http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/nc_files/M102.c?rev=1.3
[17:28:25] <Guest551> I do not understand
[17:28:41] <Guest551> friend
[17:28:43] <Guest551> ..
[17:28:57] <Guest551> i have one motor
[17:29:09] <Guest551> and i need to motion this
[17:29:26] <Guest551> for this a need one code M
[17:29:33] <Guest551> for example:
[17:30:03] <Guest551> m8 set motion refrigeration
[17:30:33] <Guest551> and a like to make one code for my motor
[17:30:34] <Guest551> ok?
[17:30:42] <SWPadnos> do you mean M8 = "stop motion"?
[17:31:30] <Guest551> no
[17:31:48] <SWPadnos> ok - M8 is coolant on
[17:31:56] <SWPadnos> you don't need any custom M codes for that
[17:32:06] <Guest551> ok
[17:32:40] <SWPadnos> you need to connect the flood coolant HAL pin so that your coolant pump will turn on
[17:32:57] <Guest551> i dind't know to make this
[17:33:16] <SWPadnos> is the coolant system connected to the computer?
[17:33:20] <Guest551> i like to make this in m100 or m101
[17:36:19] <Guest551> as well as m6 it binds spindle I I want a code that binds my engine
[17:36:55] <SWPadnos> M6 is the code. you need to make the HAL connection to get it to work
[17:37:20] <Guest551> ok
[17:37:26] <Guest551> not this
[17:37:54] <Guest551> i know for m6 is code
[17:38:46] <Guest551> I want is to create a code m
[17:39:24] <Guest551> I know that for this I must use m100 or m101 or m199
[17:39:29] <Guest551> but ..
[17:39:36] <Guest551> how to make this
[17:39:59] <Guest551> make a programa in c or perl ou pascal ou shell?
[17:40:15] <Guest551> and associat for m100?
[17:40:35] <SWPadnos> you must know how to do what you want. once you make a program to do what you want, you name it M100 or M101 or M109 and put it in your nc_files directory
[17:40:52] <SWPadnos> name the program M101 and copy it to your nc_files directory
[17:41:00] <SWPadnos> (or some other M1xx number)
[17:42:09] <Guest551> make a program in c or other languaje ok?
[17:42:12] <SWPadnos> any language
[17:42:20] <Guest551> ok
[17:42:35] <Guest551> how to associat mi program
[17:42:39] <Guest551> with m100?
[17:43:03] <SWPadnos> that is done my naming the executable "M100"
[17:43:12] <SWPadnos> and placing it in your nc_files directory
[17:43:33] <Guest551> make one program, and rename this for m100
[17:43:51] <SWPadnos> cp MyProgram nc_files/M100
[17:44:00] <SWPadnos> that's all you need to do :)
[17:44:11] <Guest551> and placing in nc_files directory?
[17:44:16] <SWPadnos> yes
[17:44:18] <Guest551> ok?
[17:44:45] <Guest551> in the directory
[17:44:49] <Guest551> ..
[17:45:05] <SWPadnos> the directory that emc2 looks for G-code files
[17:45:18] <SWPadnos> when you open a file in Axis or tkEmc
[17:45:41] <Guest551> no friend
[17:45:44] <Guest551> in the directory
[17:45:46] <Guest551> a program exists
[17:45:52] <Guest551> please one moment
[17:46:03] <SWPadnos> name yours M127 then ...
[17:47:04] <Guest551> exists one code
[17:47:56] <Guest551> that one of that page that you indicated me before
[17:48:06] <Guest551> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/nc_files/M102.c?rev=1.3
[17:48:13] <Guest551> remember?
[17:48:34] <SWPadnos> yes. you can replace it or name your program with a different number, like M120
[17:48:46] <Guest551> so that it serves this code?
[17:50:17] <Guest551> so that it serves the code that this in the page?
[17:50:29] <Guest551> the page is ..
[17:50:36] <Guest551> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/nc_files/M102.c?rev=1.3
[17:52:22] <Guest551> or to use this program?
[17:56:42] <Guest551> what this in the page makes the program that..
[17:56:54] <Guest551> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/nc_files/M102.c?rev=1.3 ?
[17:57:16] <SWPadnos> I do not understand your question
[17:57:33] <etla> I'm trying ./configure --enable-run-in-place --enable-simulator but I get error: GNU PTH Library required. is that normal?
[17:59:38] <Guest551> no
[17:59:52] <Guest551> i like to know ..
[18:00:18] <Guest551> what it makes?
[18:00:29] <Guest551> in the page have one code in c
[18:00:47] <Guest551> compiling this..
[18:01:05] <Guest551> is generat a one program
[18:01:42] <Guest551> watt make this?
[18:01:51] <Guest551> ok?
[18:02:43] <Guest551> this is a m102.c
[18:03:47] <etla> SWP: the stdout output from M102 is fed to the interpreter ? or ?
[18:04:16] <Guest551> ?
[18:04:48] <SWPadnos> no, stdout goes nowhere (afaik) - the program has to actually do what it wants to do by itself
[18:05:12] <SWPadnos> hopefully there's a way of telling emc if an error occurs (like exit codes), but I'm not sure that's in there
[18:05:48] <Guest551> ok
[18:05:58] <etla> ok, so you can do practically anything from that program. but it's not intended for g-code scripting or similar
[18:06:05] <Guest551> friends very thanks fro all
[18:06:23] <Guest551> but i have one more question
[18:06:59] <SWPadnos> etla, correct
[18:07:30] <Guest551> ilke to know where this the code
[18:07:37] <Guest551> ..
[18:08:17] <Guest551> that start makes cicle
[18:09:09] <etla> G2 and G3 make circles :)
[18:09:19] <SWPadnos> cycle, I think ...
[18:09:26] <SWPadnos> ?
[18:09:33] <Guest551> for example im interface Axis, key R start the
[18:09:50] <Guest551> start this cicle
[18:10:26] <SWPadnos> do you want a physical button or a control on the monitor?
[18:11:01] <Guest551> i want a fisical buton
[18:11:04] <Guest551> but ..
[18:11:50] <etla> you should learn to use halui
[18:11:55] <SWPadnos> you probably need to use halui. I think it is not available in version 2.0.5
[18:12:42] <Guest551> I heard to speak of halui
[18:12:50] <Guest551> but ..
[18:13:16] <etla> you can practice your halui skills with.....<drumroll>..... pyVCP!
[18:13:27] <Guest551> not necessary of this at the moment
[18:14:10] <Guest551> I can write my ideia for what necessary?
[18:15:45] <SWPadnos> yes you can
[18:15:57] <SWPadnos> I hope to understand :)
[18:16:15] <Guest551> i have 2 machine
[18:16:33] <Guest551> machine A and machine B
[18:16:36] <Guest551> ok?
[18:16:53] <Guest551> Machine B execute your work
[18:17:08] <Guest551> end of work
[18:17:16] <Guest551> Machine A
[18:17:20] <Guest551> ..
[18:17:29] <Guest551> start
[18:17:32] <Guest551> how:
[18:17:43] <Guest551> in machine B
[18:17:53] <Guest551> i have one parport
[18:18:03] <Guest551> i make one program
[18:18:13] <Guest551> this program read parport
[18:18:55] <Guest551> when read = 127
[18:18:57] <SWPadnos> halui is what you want. it can control emc functions from HAL inputs (like buttons or the output from machine A)
[18:19:24] <Guest551> but no halui in emc 2.0.5
[18:19:45] <Guest551> and compliles emc is very hard
[18:19:50] <SWPadnos> no. wait for 2.1 or compile HEAD (or v2_1_branch) from CVS
[18:19:57] <SWPadnos> 2.1 should be available soon
[18:20:35] <Guest551> I tried but I did not obtain
[18:21:01] <Guest551> in ubuntu is easy?
[18:21:01] <SWPadnos> I remember
[18:21:05] <SWPadnos> yes
[18:21:19] <Guest551> but i dont obtain
[18:21:26] <SWPadnos> when 2.1 is available, the update system will tell you
[18:21:39] <SWPadnos> you don't have ubuntu?
[18:21:48] <Guest551> i have ubuntu
[18:21:52] <Guest551> please one moment
[18:22:01] <Guest551> 2.1 is availabe?
[18:22:07] <SWPadnos> not yet
[18:22:17] <SWPadnos> when it is, the update manager will tell you
[18:23:18] <Guest551> how?
[18:23:44] <SWPadnos> it only works if the computer is connected to the internet
[18:23:46] <Guest551> ok sory
[18:24:00] <Guest551> ok
[18:24:17] <SWPadnos> the update manager will download the new package lists every day, and tells you if there is a newer version of any installed package
[18:24:21] <Guest551> come bak for mi is]deia ok?
[18:24:43] <Guest551> update manager is synaptic?
[18:24:59] <SWPadnos> no. it is a small program that runs in the background
[18:25:15] <SWPadnos> it will show an orange indicator (near the clock) when there are updates available
[18:26:40] <Guest551> ok in up
[18:26:51] <Guest551> in up?
[18:27:47] <Guest551> you says this sitema will pass emc 2.0.5 for 2.1?
[18:28:42] <Guest551> you says this sitem will pass emc 2.0.5 for 2.1?
[18:29:04] <Guest551> because i have emc 2.0.5
[18:29:15] <SWPadnos> it will tell you when 2.1 is available
[18:29:47] <Guest551> ok
[18:30:12] <Guest551> friend mi idea is
[18:30:24] <Guest551> whel read = 127
[18:30:41] <Guest551> then machine A start
[18:31:27] <Guest551> because this i like know where the code for cicle start
[18:45:35] <eholmgren> what's the name of the package that the ladder logic in emc is based on?
[18:45:50] <SWPadnos> classicladder
[18:46:51] <eholmgren> it could be used as a software based plc, correct?
[18:48:14] <SWPadnos> that's its purpose
[18:51:08] <eholmgren> hrmmnn... would I need to use it within emc and use the hal to tie parport pins it inputs and outputs?
[18:51:25] <eholmgren> or can it function like that on its own
[18:52:49] <eholmgren> found the docs, looks like it can
[18:58:27] <SWPadnos> yeah - the versin with EMC is a port to HAL-land
[18:58:33] <SWPadnos> version
[19:02:54] <Guest551> ?
[19:04:25] <jepler> eholmgren: you can use hal+classicladder without using emc. in the emc2.1 source directory hal/classicladder/projects_examples there are several .hal files that can be run with "halrun" (though, hm, it doesn't seem to be working at the moment...)
[19:05:41] <eholmgren> jepler: I have an 8 relay parport card coming in that I need a way to controll
[19:06:08] <eholmgren> hoping to experiment with some environmental control for my orchid room
[19:09:29] <jepler> eholmgren: if you like ladder diagrams then hal+classicladder is worth a try
[19:16:37] <awallin> just compiled with --enable-simulator and sim/lathe runs much better now than with RT (I'm under vmware)
[19:17:08] <cradek> good
[19:17:21] <cradek> I also noticed rt under vmware was pretty hard to use
[19:18:00] <awallin> for servo-sim, is there similar physics models for the joint movements ?
[19:18:09] <awallin> I mean similar to sim/lathe
[19:19:01] <awallin> hey! why isn't it possible to rotate the view in lathe mode ?
[19:19:32] <cradek> because a lathe is 2d, not 3d, we figured it made no sense
[19:20:39] <awallin> oh, ok.
[19:20:57] <cradek> I'm not sure how much is simulated in servo-sim - I haven't messed with it
[19:21:32] <cradek> awallin: what lathe mode could really use is the ability to have the X axis up or down - some machines have the tool on the "top" so this view is awkward
[19:23:11] <awallin> yes, I've seen the slant-bed machines with the tool coming in from the top
[19:42:28] <lerneaen_hydra> cradek: most, if not all, larger cnc lathes have the X axis "behind" the spindle
[19:42:44] <cradek> lerneaen_hydra: yes, I know
[19:43:40] <cradek> that's why I said it's needed :-)
[19:43:47] <cradek> maybe someone will write it one of these days
[19:44:02] <SWPadnos> LATHE=2 in the ini :)
[19:45:43] <cradek> until then the operator can set up a series of mirrors
[19:45:51] <cradek> or stand behind the machine
[19:48:50] <lerneaen_hydra> :p
[19:49:07] <lerneaen_hydra> or just ignore that the gui isn't exactly correct
[20:10:53] <CIA-8> 03awallin 07HEAD * 10emc2/lib/python/pyvcp.py:
[20:10:53] <CIA-8> a new widget "jognumer" which controls a HAL_FLOAT pin
[20:10:53] <CIA-8> the value is displayed just like the number widget does
[20:10:53] <CIA-8> but can be jogged up/down using the mouse wheel
[20:11:17] <CIA-8> 03awallin 07HEAD * 10emc2/lib/python/vcpparse.py: support for jognumber
[20:13:03] <CIA-8> 03awallin 07HEAD * 10emc2/lib/python/pyvcp.py: remove debug print statements...
[20:25:43] <CIA-8> 03awallin 07HEAD * 10emc2/configs/sim/pyvcp_demo.xml: a more sensible pyvcp demo, describing what each widget does
[20:30:00] <CIA-8> 03awallin 07HEAD * 10emc2/lib/python/pyvcp.py: fix blinking cursor for jognumber
[20:32:18] <lerneaen_hydra> * lerneaen_hydra gasp
[20:32:25] <lerneaen_hydra> mousewheel jogging! :D
[20:32:41] <anonimasu> hello
[20:32:43] <anonimasu> hm
[20:33:36] <lerneaen_hydra> 'lo
[20:33:42] <anonimasu> what's up?
[20:34:56] <anonimasu> hm
[20:34:59] <lerneaen_hydra> I just finished the PWM controller for my electric bike project
[20:34:59] <anonimasu> im reading on the list..
[20:35:01] <anonimasu> nice
[20:35:45] <anonimasu> I'm reading some list mails :)
[20:36:04] <lerneaen_hydra> find anything fun?
[20:36:10] <anonimasu> I dont know if doing lots of stuff while machining is really all that smart.
[20:36:39] <anonimasu> while possible, keeping your eyes on the workpiece/preview is a sane thing to do :)
[20:36:41] <SWPadnos> running vmware should be ok - it's subordinate to the RT system
[20:36:57] <anonimasu> oh, I still feel like it's a stupid thing to do
[20:36:58] <anonimasu> :)
[20:37:04] <lerneaen_hydra> anonimasu: sounds great :)
[20:37:16] <lerneaen_hydra> I do that too, though usually only after I've run the part once before
[20:37:19] <anonimasu> I usually keep one finger on pause/feedhold
[20:37:31] <anonimasu> just the first run though
[20:39:59] <SWPadnos> try playing an mp3 with mach running - it's hilarious
[20:40:52] <anonimasu> heh.
[20:44:39] <anonimasu> http://imagebin.org/6825
[20:46:35] <skunkworks> cute ;)
[20:46:41] <anonimasu> 9 weeks now :)
[20:50:05] <lerneaen_hydra> SWPadnos: what happens?
[20:51:40] <lerneaen_hydra> someone sets it up the bomb?
[20:52:11] <anonimasu> we get signal
[20:52:22] <SWPadnos> actually, every timer in the system (including those that time how long you've hovered over a control so that a pop-up tooltip will be displayed) get about 5x slower
[20:52:28] <lerneaen_hydra> main screen turn on!
[20:52:36] <SWPadnos> the MP3 skips incessantly
[20:52:36] <lerneaen_hydra> :p
[20:52:39] <lerneaen_hydra> nice
[20:53:09] <SWPadnos> and it doesn't get any better until you reboot (I think)
[20:53:15] <lerneaen_hydra> wth
[20:53:20] <anonimasu> cool :D
[20:53:24] <SWPadnos> it may get fixed when you logout and back in
[20:53:31] <SWPadnos> btu I thin it was reboot-ville (again)
[20:53:43] <lerneaen_hydra> linux >> win (at least for something like this)
[20:53:46] <SWPadnos> argh - time to thaw the fingers
[20:53:53] <SWPadnos> so it seems
[20:54:28] <SWPadnos> I think the major issue is that people are afraid of Linux - they don't know anything about it, so it's scary because it's different from what they're used to (even if it is better in many ways)
[20:54:55] <anonimasu> yep
[20:55:12] <lerneaen_hydra> people are like inductors :p
[20:55:13] <lerneaen_hydra> they resist change
[20:55:37] <anonimasu> lol
[20:55:55] <SWPadnos> or capacitors, depending on the type of change you're talking about :)
[20:57:27] <lerneaen_hydra> yeah
[20:57:55] <lerneaen_hydra> dv/dt or di/dt and all
[21:07:00] <eholmgren> I can't see how most people would be afraid of a distro like ubunto though ...
[21:07:18] <SWPadnos> it's like metric ...
[21:07:16] <eholmgren> ubuntu
[21:07:47] <eholmgren> has anyone demo'ed vista yet?
[21:07:48] <SWPadnos> clearly more useful, but not the same
[21:07:59] <eholmgren> maybe the difference would be enough to make linux not all that weird
[21:08:16] <eholmgren> diff from XP and 2K, etc
[21:08:28] <SWPadnos> dunno. but it is windows, and will be installed on every new computer within a year, so thatt'll become the new norm
[21:08:30] <SWPadnos> sigh
[21:08:52] <SWPadnos> oops - gotta run for a bit. bbl
[21:12:33] <anonimasu> vista rocks!
[21:12:36] <anonimasu> especially the drm stuff
[21:12:59] <robin_sz> yeah ... I heare its good for playin movies
[21:59:26] <goslowjimbo> I am trying to run HAL by itself presently, attempting to create a DRO. I tried to drive the parport pin 2 high, and it took 40 mA of a 5 volt supply. This sort of points to the parport still being an output. When does parport get changed to an input?
[22:00:14] <cradek> you can specify input mode when you load the hal_parport driver, let me find you a page number in the docs
[22:01:02] <goslowjimbo> I did that : halcmd loadrt parport cfg="0x378_in"
[22:01:51] <cradek> what emc version is this?
[22:02:08] <cradek> (I think the format of that may have changed)
[22:02:54] <goslowjimbo> 2.0.0.something. I downloaded it with Ubuntu over the holidays
[22:04:53] <jepler> the underscore is almost certainly wrong. I think cfg="0x378 in" may be what you want?
[22:05:16] <cradek> 0x378_in works for me in 2.0
[22:05:18] <goslowjimbo> I'll try that.
[22:05:22] <cradek> 02 bit -W FALSE parport.0.pin-02-in
[22:05:28] <cradek> do you get these -in pins?
[22:05:30] <jepler> cradek: oh really
[22:05:42] <cradek> if you get the -in pins, it's loaded right
[22:06:17] <jepler> jmk pointed out in his e-mail about this that the "put port in 'input' mode" instruction may only be executed when the parport.write function is executed
[22:06:22] <jepler> which would be a surprise if you weren't using .write at all
[22:06:29] <cradek> oh!
[22:06:38] <cradek> is that maybe the problem goslowjimbo?
[22:07:13] <goslowjimbo> Yes, that may be it. My routine doesn't have a write anywhere
[22:07:25] <cradek> try adding write to your thread
[22:07:29] <jepler> yes, try to 'addf ... parport.0.write' or 'addf ... parport.write-all' in your hal file
[22:07:37] <cradek> thanks jepler - I would have never thought of that in a million years
[22:07:42] <jepler> cradek: me either, but he did
[22:07:59] <cradek> I'd rather he would have fixed it instead of sending an email :-)
[22:08:05] <goslowjimbo> will do. Do I still need to play with "0X378_in" ?
[22:08:22] <cradek> no, that's fine if you are getting pins like -02-in
[22:10:39] <goslowjimbo> OK. Another thing that is happening is the same instructions direct from the keyboard don't work in a file. If I execute the file (halcmd -f-V foobar) I just get a show with no structure at all.
[22:12:58] <cradek> do you mean halcmd -V -f file?
[22:13:06] <goslowjimbo> yes
[22:13:13] <cradek> (I don't know if -f-V file would work)
[22:13:30] <goslowjimbo> What would?
[22:13:32] <jepler> one thing that comes to mind is that 'halcmd -f' will stop after the first error, while 'halcmd -kf' will continue after an error
[22:14:16] <jepler> 'halcmd -kf' is often shown as the way to run an "interactive halcmd", but with a filename the "-k" ("k"ontinue after error) is usually not included
[22:15:20] <cradek> also, I don't think you caught the distinction I made: you typed "halcmd -f-V file" which I think is a syntax error
[22:15:35] <cradek> then I asked if you meant "halcmd -V -f file" which is the expected syntax
[22:16:00] <jepler> $ halcmd -f-V example.hal
[22:16:00] <jepler> Unknown option '--'
[22:17:14] <goslowjimbo> You're right, I didn't catch that. I wasn't sure that you liked the foobar, and so didn't notice the change
[22:18:15] <A-L-P-H-A> is there a "tree" command equiv in linux?
[22:18:24] <cradek> what's tree?
[22:18:45] <A-L-P-H-A> DOS command, tree... it lists all the directories in a tree structure.
[22:19:06] <A-L-P-H-A> if it's a child folder, it indents.
[22:19:31] <cradek> ls -R and du come to mind, nothing strictly equivalent I think
[22:19:41] <A-L-P-H-A> http://news.bbc.co.uk/2/hi/africa/6225301.stm
[22:21:11] <A-L-P-H-A> ls -DR doesn't give me just the folders...
[22:22:06] <goslowjimbo> So this is why the -V option didn't seem to do much?
[22:25:41] <goslowjimbo> Thanks guys. I'm off to try these fixes.
[22:34:15] <awallin> -
[22:45:16] <jepler> a new reflow solder method for the home: http://geektechnique.org/projectlab/726/diy-obsolete-ibook-logic-board-repair (don't miss the video http://geektechnique.org/images/1222t.jpg)
[23:06:30] <jepler> SWPadnos: is there a micro-atx version of the antec sonata? I don't need that big a case, but I like some of the sonata features (the fan and the drive mounting)...
[23:20:12] <jepler> I suppose you'd never buy anything as bush-league as a micro-ATX system
[23:24:46] <jepler> NSK3300 seems to have the special hard drive mounting and the 120mm rear fan..
[23:26:59] <jepler> on second thought I do want "3" "5.25 inch" bays
[23:28:57] <jepler> hi roltek