Back
[01:16:49] <atex57> No workshop this year???
[01:18:08] <SWPadnos> looks that way
[01:21:11] <atex57> Bummer!! The email from Roland said something about a meeting in Kansas, I hope so as I have a lot of learning to do about HAL and CL.
[01:21:26] <SWPadnos> I'm not sure what taht may be, or when
[01:21:51] <SWPadnos> it may be more like the EMC "fests" of old, rather than a teaching/learning thing :)
[01:22:28] <SWPadnos> there's nothing officially planned yet, as far as I know
[01:22:37] <SWPadnos> we've just talked about it a little
[01:22:38] <archivist> * archivist hopes for a .uk or .eu one
[01:22:45] <SWPadnos> I'm game :)
[01:22:47] <skunkworks> is it leaning towards stuarts shop?
[01:23:03] <SWPadnos> well, he's got a shop with loads of heavy iron, so that's cool
[01:23:16] <SWPadnos> but then again, I don't know if he has a single stepper motor in the building ;)
[01:23:33] <atex57> I guess the "fests" that was before my time.
[01:23:35] <archivist> he must have a printer
[01:24:12] <SWPadnos> atex57, they're more like programming and planning sessions
[01:24:28] <atex57> OK
[01:24:32] <SWPadnos> not really about CNC and all that, more about making EMC do more/better stuff
[01:25:02] <SWPadnos> (of course CNC is also involved though, since EMC is a CNC controller ;) )
[01:27:28] <archivist> for the uk a spread at the midlands model engineer would be a good idea
[01:29:19] <SWPadnos> oh October, interesting
[01:29:50] <archivist> last year the new mach owner was there
[01:29:57] <SWPadnos> Brian
[01:30:03] <SWPadnos> or Bryan
[01:30:22] <archivist> I went to his talk
[01:30:49] <SWPadnos> an, near Coventry
[01:31:02] <archivist> it was interesting listening to the questions :)
[01:31:04] <SWPadnos> I knew I had seen Leamington Spa somewhere - probably on a road sign
[01:31:06] <SWPadnos> heh
[01:31:19] <SWPadnos> what kind of questions were there?
[01:31:41] <archivist> motherboard and latency and other fails
[01:32:16] <SWPadnos> oh, interesting
[01:32:42] <SWPadnos> actually, they have a cuide for setting up a PC to run Mach. they include some BIOS settings and stuff - it might be good to see how much it helps EMC also :)
[01:32:55] <archivist> as may have guessed I was not converted :)
[01:33:10] <SWPadnos> heh
[01:33:51] <archivist> talk was not about mach so mach questions were off topic
[01:34:04] <SWPadnos> huh. what was it about?
[01:34:41] <archivist> tool choice for cnc
[01:34:57] <archivist> that he seemed to know his stuff
[01:35:18] <SWPadnos> oh, nice
[01:35:43] <archivist> he was a machine shop manager
[01:36:49] <archivist> I could do time on a stand at that show in october as its not that far from here
[01:39:11] <archivist> time to burger off home
[01:39:16] <SWPadnos> see you
[01:39:26] <geo01005> Anybody want to hear more about this MESA SPI stuff?
[01:39:33] <SWPadnos> no
[01:39:36] <SWPadnos> I mean yes
[01:39:38] <SWPadnos> :)
[01:39:57] <geo01005> I just posted a blog, so feel free to read or not.
[01:39:58] <SWPadnos> did you get something working, or were you thinking about it more, or what?
[01:40:01] <SWPadnos> ok :)
[01:40:17] <geo01005> http://geo01005-ideas.blogspot.com/2009/02/spi-serial-interface-for-mesa-anything.html
[01:41:01] <geo01005> More painful ideas from the inexperienced
[01:41:07] <SWPadnos> heh
[01:41:34] <SWPadnos> strange. the first image isn't loading for me
[01:41:39] <SWPadnos> ah, there it is
[01:42:18] <SWPadnos> do you know of a program like XML notepad for Linux?
[01:42:39] <geo01005> No... I'm sure one exists... well maybe.
[01:42:56] <geo01005> I'm here on my Windows box at school, so I used it.
[01:43:03] <SWPadnos> I can see that
[01:43:06] <archivist> SWPadnos, the last one I played with exploded on the 16meg xml I fed it
[01:43:22] <SWPadnos> maybe a different once would be good
[01:43:24] <SWPadnos> one
[01:44:13] <archivist> that IDE has an xml plugin hmm e....
[01:44:24] <SWPadnos> oh - eclipse?
[01:44:30] <geo01005> yes.
[01:44:31] <archivist> yup
[01:44:40] <SWPadnos> come to think of it, Code::Blocks and/or Anjuta may also
[01:45:21] <archivist> yup dont feed it bloat (or any xml aware prog unless its good)
[01:45:39] <SWPadnos> http://xml-copy-editor.sourceforge.net/
[01:45:49] <geo01005> Where can I post that link, so some people not online could see it?
[01:45:59] <SWPadnos> what link?
[01:46:09] <SWPadnos> to you blog entry?
[01:46:12] <geo01005> yes.
[01:46:13] <SWPadnos> your
[01:46:29] <archivist> mailing list
[01:46:32] <SWPadnos> I think there's a wiki page or two with some ideas - you could mention this and put a link there
[01:46:44] <SWPadnos> and/or send to the developers mailing list (pleas not the user list)
[01:46:49] <SWPadnos> +e
[01:47:03] <SWPadnos> also, this conversation is archived and indexed by google
[01:47:19] <geo01005> So am I crazy?
[01:47:27] <SWPadnos> yes
[01:47:34] <archivist> we all are, dont worry
[01:47:36] <SWPadnos> lemme read the blog post to see how crazy ;)
[01:49:44] <seb_kuzminsky> geo01005: you're crazy ;-P
[01:49:53] <SWPadnos> yep, I'm thinking that too :)
[01:49:56] <geo01005> I thought so.
[01:50:03] <SWPadnos> writing software to write software isn't trivial
[01:50:14] <geo01005> Sure, I understand that...
[01:50:26] <seb_kuzminsky> the drivers for the spi slaves should probably be written in C or in our "comp" language, which compiles to C
[01:50:30] <geo01005> I didn't say I wanted to do it :)
[01:50:31] <SWPadnos> making it so the software gets automatically rewritten, compiled, then installed every time you run it is also a chore
[01:50:54] <seb_kuzminsky> then *maybe* you can use xml to connect drivers to spi ports
[01:51:08] <SWPadnos> and that fourth bullet point - how to get it to work with the current hostmot2 driver, is a crucial one
[01:51:13] <seb_kuzminsky> but writing the *driver* in xml, and compiling *that* to C, well, that's crazy ;-)
[01:51:16] <geo01005> I'm thinking you would just compile once for a specific setup.
[01:51:27] <SWPadnos> that could work better
[01:51:40] <seb_kuzminsky> brb
[01:52:20] <geo01005> Now keep in mind that the driver it's self is not in XML, just the specifics for each device.
[01:52:47] <SWPadnos> sure. I don't know hotw you'd compile XML to code
[01:52:56] <SWPadnos> unless you're using UML models
[01:53:02] <SWPadnos> (which we don't want to do)
[01:53:42] <geo01005> I'm thinking of some python script that would parse the XML and spit out the C code.
[01:54:47] <SWPadnos> since it's ulikely that we'd want to deal with pathological cases (a 16-bit A/D + 2x 10-bit D/A with their bits interleaved with some digital I/O), there may be a somewhat generic way of specifying devices
[01:55:17] <SWPadnos> parsing XML and spitting out C code is probably a thesis-level project
[01:55:57] <SWPadnos> there are only four things that are likely to be attached: ADC, DAC, digital out and digital in
[01:55:58] <geo01005> I wish I sortof knew what the output of the file would look like...
[01:56:28] <SWPadnos> there are other things that are equivalent to ADC/DAC - a PWM output is still an analog output
[01:56:47] <SWPadnos> there could also be "bitfields" - integer multibit values
[01:57:07] <SWPadnos> so maybe 6 things (analog, multibit, single bit * in, out)
[01:57:35] <SWPadnos> it's likely that multiple devices of the same type will be contiguous for a given SPI channel
[01:58:13] <SWPadnos> so there might be a 6-channel A/D, a 4-channel DAC, two 8-bit digital input chips and a couple of 8-bit digital output chips
[01:59:04] <SWPadnos> so, a specification that says "6 analog bipolar 16-bit inputs, then 4 analog bipolar outputs, then ..." would do the job
[01:59:51] <SWPadnos> the other main issue is whether you need an activation signal - either an SPI command or a pin strobe - to get the devices to "do their thing"
[01:59:59] <geo01005> yes, but there are more specifics to each of the devices, how is the data framed, are there extra bits, ect..
[02:00:07] <SWPadnos> yep
[02:00:35] <SWPadnos> framing is the easiest thing to deal with, I think
[02:01:08] <SWPadnos> the driver does that before sending out the data, since SPI chips are generally daisy-chained
[02:01:22] <SWPadnos> so the alignment field you have in there is necessary
[02:01:26] <geo01005> In the XML file I made the Ask_device_data element contains the exact bits needed for that paricular decive and channel.
[02:01:50] <SWPadnos> there are devices that need a pin strobe, or nothing, to activate
[02:02:28] <geo01005> Are you talking about the chip select?
[02:02:32] <SWPadnos> but if any device needs a start message, then all devices need to be programmed with appropriate "no-op" commands, or they'll do something when the chip select is deasserted
[02:02:45] <SWPadnos> some have chip select in addition to other control lines
[02:03:00] <SWPadnos> in general, you connect all the CS lines together for a particular chain
[02:03:05] <geo01005> I belive that all SPI devices have a chip select.
[02:03:28] <SWPadnos> sure, but look up the AD7656 for an example of other ways of triggering an ADC conversion
[02:03:36] <geo01005> it isn't like i2c where the decives have an address on the bus.
[02:04:05] <geo01005> devices...
[02:04:07] <SWPadnos> that chip has 6x 16 bit bipolar inputs, but they can be triggered separately (in pairs), or together, or via an SPI command
[02:04:21] <SWPadnos> I understand the differenced between SPI and I2C
[02:04:27] <SWPadnos> differences
[02:05:00] <geo01005> hmm, I see.
[02:05:50] <SWPadnos> there are some chips, like multi-channel DACs, that have a separate "update" pin, because you need to clock in 4x words of data, but you may want simultaneous update
[02:06:00] <SWPadnos> (like the AD5764, for example ;) )
[02:06:38] <SWPadnos> I know all this because I designed a board that connects to a Mesa card, and has those chips on it ;)
[02:07:19] <geo01005> Is this not a special case?
[02:07:33] <SWPadnos> hmmm. I should change the driver for that to re-initialize the ICs whenever it detects a cable reconnect
[02:07:38] <SWPadnos> no, I don't think so
[02:08:09] <SWPadnos> that's the hard part. there are a lot of chips, and if you really want something generic, you have to think about all those cases
[02:08:34] <geo01005> I must always just be looking at more simple chips that don't have any bells and whistles.
[02:08:56] <SWPadnos> that ADC is intended for 3-phase power monitoring applications I think - phases ABC, with simultaneous voltage/current sampling per phase
[02:09:34] <SWPadnos> that's an application I can imagine being applicable here, for someone making an AC motor drive, for example
[02:09:37] <geo01005> It just seams like wrecks the simplicity of a serial connection.
[02:10:00] <geo01005> Sure, I can see that being very useful.
[02:10:01] <SWPadnos> that ADC happens to also have a parallel bus, and up to 3 simultaneous SPI channels, so it's a bit of a beast
[02:10:36] <SWPadnos> but there are many devices that may need multiple CS/strobe/latch/whatever lines, and defining how and what those are isn't trivial
[02:11:34] <SWPadnos> incidentally, one thing you should know about me is that I often think about things in such a way as to make them impossible - something simple that works for you is a great start, and someone else who needs more can add it later :)
[02:11:38] <geo01005> How fast do you sample that ADC?
[02:12:02] <SWPadnos> my board gets about 175 kHz on all 6 ADC and all 8 DAC channels (there are two 5764)
[02:12:28] <SWPadnos> that could be tweaked a bit, but I didn't want to bother since that's about 10x as fast as it needs to be
[02:13:08] <geo01005> that is pretty quick.
[02:13:15] <SWPadnos> yep
[02:13:25] <SWPadnos> those are really nice chips, but you pay for it
[02:13:42] <SWPadnos> the DACs are in the $50 range each, and the ADC is about $25
[02:14:12] <geo01005> Here I am thinking about 2-5 kHz, and I'm wondering why you care about the difference in time between conversions with a fast spi bus.
[02:14:44] <SWPadnos> oh - related to simultaneous sampling?
[02:14:49] <geo01005> yes.
[02:15:08] <SWPadnos> for some applications, like power, if you don't sample at the same time, you don't get an accurate reading
[02:15:20] <SWPadnos> also consider differential measurements
[02:15:49] <SWPadnos> if you trigger one conversion, then transfer the data, then trigger the next, then the time between the conversions could be significant
[02:16:06] <SWPadnos> if you're measuring independent entities though, it doesn't matter at all
[02:16:21] <geo01005> yes it can when you are sampling at 175 kHz.
[02:16:21] <SWPadnos> and if you're measuring things that are relatively static, then it also probably doesn't matter
[02:16:47] <SWPadnos> that sample rate is driven by the fact that the SPI bus couldn't be clocked any faster
[02:17:02] <geo01005> How fast are the fastet mesa PCI card running?
[02:17:16] <SWPadnos> I think there's a 50 or 100 MHz internal clock
[02:17:32] <geo01005> I mean how fast are the servo loops being closed?
[02:17:44] <SWPadnos> for the 7i43, no faster than
[02:17:48] <SWPadnos> err, wait a minute
[02:17:55] <SWPadnos> in the application I did those boards for?
[02:18:43] <geo01005> The 7i43 is limited to a couple of kHz, I'm wondering about something like a 5i20 running a servo thread.
[02:18:57] <SWPadnos> the application I did was at 10 KHz
[02:19:18] <SWPadnos> it's probably possible to go faster - the motherboard I had sucked big time for PCI accesses
[02:20:15] <geo01005> I just wasn't sure if anybody woulld be doing sampling at the rates you used for your application.
[02:20:57] <geo01005> Well, it seams I thought I was thinking in general way for SPI, but yet again, I'm thinking in real specifics.
[02:21:00] <SWPadnos> some might. the reason I made the card capable of that was so that the FPGA could do multiple samples and average them
[02:21:16] <SWPadnos> heh. it's really hard to do everything
[02:21:47] <SWPadnos> as I said though, if you start with what works for you, or for simpler devices (something that is only one class of I/O), then others can add to it as they see fit
[02:22:15] <geo01005> I was just trying to find an easy way to set up a set of data to stuff into the FIFO, and an easy way to interpret the results.
[02:23:35] <geo01005> XML seamed like a good way to describe how to do that.
[02:25:24] <SWPadnos> oh -XML may be fine for that, it's a question of how much data is really needed
[02:25:47] <geo01005> I was thinking that the data sent to the SPI decives would be a constant.
[02:26:03] <SWPadnos> that may be useful only for single channel devices
[02:26:18] <SWPadnos> in some cases, you need to send a read command for each channel
[02:26:25] <SWPadnos> and/or a write command
[02:26:41] <SWPadnos> in addition to initialization data at startup
[02:26:49] <geo01005> Well a set of constant to send down the pipe, you may have to wait for the responce...
[02:27:16] <SWPadnos> ok, right. I remember you had a "send, wait for response ..." thing in there
[02:28:02] <geo01005> What am I thinking, that won't work...any device you output data to, like a DAC, or digital output won't be a constant.
[02:28:05] <SWPadnos> heh. right on time ;)
[02:28:19] <SWPadnos> oh, of course outputs wouldn't be constant
[02:28:21] <PCW> Time to go home almost...
[02:28:39] <SWPadnos> oh, a comment and run?
[02:28:55] <PCW> yep hit-and-run...
[02:28:59] <SWPadnos> heh
[02:29:36] <geo01005> Well I better get running soon.
[02:29:56] <geo01005> I should stop bothering all of you with my SPI stuff.
[02:30:51] <PCW> Some of the complexity can be hidden in the SPI interface setup
[02:30:53] <PCW> For our motion control oriented stuff (low speed)
[02:30:55] <SWPadnos> brainstorming is good
[02:30:55] <PCW> we plan on using our buffered SPI interface
[02:30:56] <PCW> which is designed to use a single spi interface
[02:30:58] <PCW> with multiple chip selects
[02:32:13] <SWPadnos> I was thinking about CS being used to clock in data, but the need for a separate "latch" or "conversion start" pin
[02:32:22] <SWPadnos> err - CS used when clocking in data ...
[02:32:25] <PCW> geo01005: I made you a bit file, more trouble than I originally thought
[02:32:27] <PCW> because I had to add a decoded/cs/frame option
[02:32:55] <PCW> on the 7I65 we have the latch-all at once pin but its not really needed
[02:33:33] <geo01005> I belive the latch-all is what SWP and I were just talking about.
[02:33:48] <SWPadnos> yes and no
[02:34:16] <geo01005> PCW:Thanks for going that, I'm sorry it took more time than just a couple of minutes.
[02:34:20] <SWPadnos> PCW, is that latch-all pin controlled by the SPI module or is it under software control?
[02:34:39] <PCW> Its kind of outside the scope of SPI, but its would be doable with the current interface by using a space CS bit
[02:34:50] <PCW> (spare)
[02:34:54] <SWPadnos> heh
[02:35:01] <SWPadnos> I was wondering how mark/space came into this ;)
[02:35:57] <geo01005> So i'm new to this whole mailing list thing, well I have read lots of them, but do I just send an email to this address:emc-developers@lists.sourceforge.net?
[02:36:16] <geo01005> The subject becomes the subject on the list?
[02:36:33] <SWPadnos> yes, I think that's how to do it
[02:36:34] <PCW> Current SPI interface Im using with the 7I65 is BSPI. it support the 4 different SPI devices on the 7I65 fine
[02:36:35] <PCW> Almost all the magic is done by writing the channel descriptors (just once at startup)
[02:37:30] <geo01005> I figured that most all the hardware issues are solved with the channel descriptors.
[02:38:11] <PCW> Yes, painful though it be to figure the magic the first time...
[02:40:35] <PCW> I still need to add the autosend feature for A-Ds so a single write
[02:40:37] <PCW> can trigger a bunch of read request/channel addrs
[02:42:44] <geo01005> That would be nice.
[02:43:10] <geo01005> Well I think that I did that right. That blog address should be on the developers list now.
[02:45:43] <geo01005> For everyone to cringe over
[02:51:17] <geo01005> Well goodnight.
[03:00:56] <PCW> SWP: Was it Jepler that was looking at the ldmicro ladder compiler for PIC?
[03:02:56] <SWPadnos> could be, but I'm not sure
[03:05:51] <PCW> Had this crazy idea of making a HM2 PLC option
[03:05:53] <PCW> using ldmicros intermediate token output
[03:05:54] <PCW> and interpreting it with a fast but dumb little
[03:05:56] <PCW> CPU in the FPGA
[03:06:42] <SWPadnos> ladder in the FPGA would be great for lots of things, but I wonder about synchronizing with the host thread(s)
[03:07:22] <PCW> dual ported RAM for host interface
[03:07:46] <scstemp> scstemp is now known as steve_stallings
[03:07:54] <PCW> (PLC interface to everything)
[03:08:36] <PCW> (including host)
[03:08:41] <SWPadnos> I guess I'm thinking more about the idea that it's best to know that inputs won't change during a thread execution
[03:09:23] <SWPadnos> so I think you'd want to synchronize the loop in the FPGA to some thread on the host CPU
[03:09:39] <PCW> possible
[03:11:53] <SWPadnos> it could be as simple as writing to one register to start the process - the FPGA PLC then samples and processes everything, then when you write to another location it posts the results
[03:13:21] <PCW> Some things might want to run stand alone as well, maybe a address range for free run/ host syncronous
[03:14:44] <SWPadnos> actually, something like a latch/passthrough bit would be fine
[03:15:03] <SWPadnos> just don't update the PC interface registers when it's in "latch" state
[03:18:25] <PCW> Right, with the correct double buffering, the time when the host interface would be "busy" could be kept very short
[03:23:02] <PCW> time to go...
[03:23:04] <PCW> bye all
[09:47:12] <christel> [Global Notice] Hi all, we just lost everything on the other side of the atlantic -- it would appear we've got between our US and EU hubs, we're looking into the issue and hopefully we'll have things back to normal shortly. Apologies for the inconvenience and thank you for using freenode.
[10:19:09] <christel> [Global Notice] Hi all, it would appear we've discovered yet another bug in hyperion, the ircd we run -- how we've managed to use it successfully for so long is now but a great mystery. The network is back up, for now, but in light of this we will be looking at bringing our ircd-change forward, details shall be forthcoming. Please accept my sincere apologies for the instability as of late and thank you for your patience.
[10:56:08] <christel> [Global Notice] Hi all, It appears I may have been too harsh on hyperion -- this crash wasn't a segfault after all, but some of hardened gentoo's 'security' measures deciding that our ircd is a threat. More information will be provided on the blog when we have a better picture and know what actions will be taken to prevent this from occuring again. Thank you for using freenode and have a good day!
[11:27:51] <piasdom> g'mornin all
[11:28:19] <BigJohnT> morning
[11:29:46] <piasdom> hey BigJohnT, how's it giong ?
[11:34:17] <BigJohnT> ok, my back is getting better
[11:40:44] <piasdom> didn't know about your back..been awhile ?
[11:42:38] <BigJohnT> slipped on the ice a few days back and landed flat on my back
[11:43:02] <BigJohnT> when it quits hurting it will feel so much better
[11:43:30] <piasdom> D***,that's sucks..hope you get better soon
[11:44:06] <piasdom> hahahahhaha...that pain seems to be the problem...if it just went away :)
[12:49:57] <BigJohnT> .tock
[12:49:59] <Gracie> "Wed, 18 Feb 2009 12:49:58 GMT" - tycho.usno.navy.mil
[13:11:13] <The_Ball> BigJohnT, i grew up with ice, now i've moved to a warmer climate
[13:11:53] <The_Ball> hope it get's better soon, not much is worse than serious back pain
[13:26:05] <BigJohnT> I grew up in Alaska... but it didn't help me the other day :/
[13:26:25] <BigJohnT> it's getting better The_Ball
[13:26:30] <BigJohnT> thanks
[13:32:15] <Guest663> Guest663 is now known as skunkworks_
[13:32:48] <skunkworks_> logger_emc: bookmark
[13:32:48] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2009-02-18.txt
[13:33:58] <mshaver> skunkworks_: why'd ya do that? I'm asking because I really don't know what that does.
[13:34:40] <mshaver> ok, look, a log since last night
[13:34:59] <mshaver> where they're talking about fest this year - must read this
[13:46:19] <tomp> may be of use: hardy and intrepid packages for vmware tools
http://www.monarialx.it/en/vmwareserver
[13:46:59] <skunkworks_> mshaver: :)
[13:52:58] <mshaver> skunkworks_: skunkworks! :-D
[14:10:51] <UncleGemc> g-morning
[14:11:42] <UncleGemc> Anyone out there know of some good websites for rfq's, alternatives to www.mfgquote.com?
[14:41:03] <tomp> wow, after only a few months, i am now on the net with wireless on this gateway POS with realtek RTL8187B wireless chip ( ubuntu refused to see it ).
[14:41:12] <tomp> I got the fix from
http://www.ubuntuforums.org/showthread.php?P=4784343. outside of a bit of guesswork in the ubuntu wireless cfg, it was just as listed.
[14:41:19] <tomp> In System | Administration | Network , unlock with your pwd, then edit the wireless connection (made by the listed 'sudo ./wlan0up' cmd),
[14:41:26] <tomp> edit it to the network name (ESSID), leave it as WPA Personal (what i did), leave the pswd blank, set the cfg to DHCP
[14:41:27] <tomp> ( i'm in a hotel, this is common )) and wham! you on the air! happy dance!!
[14:42:34] <tomp> this is for any other ubuntu hardy emc users who keep lookin for that eth0 cable in hotels too cheap to wire them in ;)
[14:44:00] <tomp> uh, i think you gotta 'sudo ./wlan0up' everyboot, but its better than no inet
[14:44:49] <tomp> hmm, wherethef was i when i issued that ?
[14:45:17] <tomp> ah, time for some symlinks
[14:50:59] <tomp> heh, isnt this a nice keyboard :) this POS is better than the eeepc POS
[15:57:04] <shrdlu-> hm, I just wasted many hours and nearly had a nervous breakdown because I forgot to put in 'P0'
[15:57:10] <steve_stallings> steve_stallings is now known as steves_logging
[16:01:52] <seb_kuzminsky> P0 is involved in a lot of my nervous breakdowns too
[16:02:06] <shrdlu-> hehe
[16:22:16] <shrdlu-> hm, modern inkjet printers must have some pretty fancy raster motion algos
[16:22:44] <shrdlu-> to get the speeds they do
[16:23:09] <archivist> I used to write said code
[16:23:50] <shrdlu-> oh rly?
[16:24:13] <archivist> yup, we had it all in software
[16:24:28] <shrdlu-> what kind of machines?
[16:24:36] <archivist> ink jet
[16:25:04] <archivist> we bought in Canon and made them faster
[16:25:39] <shrdlu-> I've been trying to get EMC to do so, but I now understand it's not immediately possible to get it smooth
[16:25:58] <shrdlu-> although I'm doing one at the moment, it's not great but it'll have to do
[16:27:04] <archivist> our feed back was not good enough so there was a bit of jitter
[16:30:35] <shrdlu-> feedback in what sense?
[16:30:57] <archivist> opto
[16:31:52] <archivist> software toggled the motor H bridge on the opto edge
[16:33:18] <shrdlu-> I guess I don't know what feedback means, technically
[17:30:02] <seb_kuzminsky> hi geo
[17:36:15] <geo01005> howdy.
[19:05:41] <geo01005> It seams like I read on one of the logs that someone was trying to develop a method for automaticly creating a new bit file for hostmot2 configurations.
[19:05:50] <geo01005> Any truth to that?
[19:05:58] <seb_kuzminsky> geo01005: yes, jmkasunich and jepler were hacking on that
[19:07:52] <geo01005> I wonder...
[19:09:22] <geo01005> So the difficulty with the hostmot2 driver is that the cards are FPGA and can be just about anything right?
[19:10:08] <seb_kuzminsky> the cards have fpgas, and the fpgas can have lots and lots of different firmwares, true
[19:10:10] <seb_kuzminsky> however...
[19:10:29] <seb_kuzminsky> "hostmot2" means a family of firmwares that are self-describing, according to a particular protocol
[19:10:39] <seb_kuzminsky> see src/hal/drivers/mesa-hostmot2/firmware/src/regmap
[19:10:39] <geo01005> So either the driver has to be ultra flexible, or you have to have lots and lots of firmwares.
[19:11:16] <seb_kuzminsky> the particularly interesting data structures in that file are the IDROM, the Module Descriptors (MDs), and the Pin Descriptors (PDs)
[19:11:37] <seb_kuzminsky> those three things completely tell the driver what the currently loaded firmware can do
[19:11:48] <seb_kuzminsky> geo01005: really both of the things you say
[19:12:02] <seb_kuzminsky> *because* the driver is so flexible, you *can* have lots and lots of firmwares
[19:12:18] <seb_kuzminsky> as long as the firmwares describe themselves using those three data structures, the driver will know what to do with them
[19:12:50] <seb_kuzminsky> if the firmware has a functionality that the driver doesnt understand, the driver can just skip that part, and work with the parts of the firmware that it *does* understand
[19:13:03] <geo01005> Excuse me.... I miss wrote..either the driver has to be ultra flexible, or you have to have lots and lots of DRIVERS.
[19:13:18] <seb_kuzminsky> ah yes
[19:13:41] <seb_kuzminsky> the whole point of hm2 is to have a flexible driver & firmware combo that can serve many different needs
[19:14:10] <alex_joni> and to have stepgens :D
[19:14:13] <geo01005> So how difficult would it be to write a hm2 driver for an exact configuration?
[19:14:20] <seb_kuzminsky> the firmware can be extended to have new capabilities, and the driver can be extended to support those new capabilities, in a relatively painless way
[19:14:32] <seb_kuzminsky> alex_joni: including stepgen yes :-)
[19:14:56] <seb_kuzminsky> geo01005: it'd be pretty easy, you could use the generic hostmot2 driver to learn from
[19:15:16] <seb_kuzminsky> but it wouldnt be much more difficult to have your driver understand the idrom, mds, and pds, and thus work with all hm2 firmwares
[19:15:20] <seb_kuzminsky> what are you trying to accomplish?
[19:16:39] <geo01005> Well, so I'm trying to understand where the difficulty is. Reading though the Hm2 code it looks like a great majority of the code is to make the driver flexible.
[19:16:55] <geo01005> Only a handfull of lines that actually do the data transfer.
[19:16:57] <alex_joni> geo01005: you can look at the "obsolete" m5i20 driver
[19:17:02] <alex_joni> which was the old 5i20 driver
[19:17:13] <alex_joni> but that one only supports servo mode
[19:17:18] <alex_joni> and a certain firmware
[19:17:24] <seb_kuzminsky> geo01005: you mean the difficulty with adding spi?
[19:17:39] <geo01005> The difficulty of changing anything..
[19:17:48] <seb_kuzminsky> hmm
[19:18:17] <seb_kuzminsky> i still dont understand what you're up to
[19:18:20] <seb_kuzminsky> what do you want to change?
[19:18:23] <geo01005> I just wondering if it is easier to change the extising driver, or to develop a tool that dynamicly, maybe not at runtime, creates a driver for a specific setup.
[19:18:49] <seb_kuzminsky> much of the hostmot2 code is in modeling the hostmot2 functionality (pwmgen, stepgen, encoder, & gpio)
[19:19:02] <seb_kuzminsky> the code for parsing the IDROM and MDs and PDs is pretty small
[19:19:17] <seb_kuzminsky> turning those things into HAL objects that work is the bulky part ;-)
[19:20:00] <geo01005> yes...That is the part that seams the hardest...Is it because the language it akward?
[19:20:28] <geo01005> Wouldn't that part be cake if the exact configuration was know at complie time?
[19:20:43] <geo01005> complie.
[19:20:59] <geo01005> wrong again...i'm sure you know I ment compile.
[19:21:07] <seb_kuzminsky> it's pretty much cake right now, imo
[19:22:05] <seb_kuzminsky> it's *bulky* (lots of lines of code), because each HAL object needs to be created and error-checked, but it's not conceptually difficult
[19:22:40] <seb_kuzminsky> read a handful of bytes from the MD, turn that into an array of encoders or whatever, and export those encoders to HAL
[19:23:03] <seb_kuzminsky> this is all the hm2_*_parse_md() functions
[19:23:14] <seb_kuzminsky> is that what you're asking about?
[19:23:19] <geo01005> I suppose.
[19:23:46] <geo01005> It sounds like I'm trying to come up with solutions to problems that don't need to be solved.
[19:23:59] <geo01005> or that arn't problems at all.
[19:24:13] <seb_kuzminsky> i'm not even sure what solutions or problems you're talking about... :-/
[19:25:24] <pjm_> evening all
[19:27:10] <geo01005> Well to me augmenting the hm2 driver with spi uarts, whatever is a problem. I guesse to most of you it is just a task.
[19:27:49] <geo01005> I suppose i won't be able to really help much here untill I can understand C a little better.
[19:28:01] <seb_kuzminsky> yes C is useful for hacking on this stuff ;-)
[19:28:28] <SWPadnos> it's kind of required for kernel modules
[19:28:33] <seb_kuzminsky> adding SPI support to hm2 would mean writing a "sub-driver" for talking to the SPI part of the hm2 firmware
[19:28:45] <seb_kuzminsky> but there's a pre-requisite before doing that...
[19:28:55] <geo01005> A module like a PWM right?
[19:29:12] <seb_kuzminsky> you have to know how you want your hm2-spi driver to model the spi to the rest of the system
[19:29:50] <seb_kuzminsky> how do you talk to the spi slave? does the spi slaves get their own drivers? and if so, how to the spi-slave-drivers *use* the hm2-spi-master driver?
[19:29:59] <seb_kuzminsky> and how do you configure this pile of code?
[19:30:10] <seb_kuzminsky> *those* are the tricky design issues that need to be resolved up front
[19:30:33] <seb_kuzminsky> once there are reasonable answers to those questions, the code pretty much writes itself i think
[19:32:02] <geo01005> hmm, ok.
[19:33:34] <geo01005> It seams like the models for the current modules (encoder, pwm, stepgen, and gpio) where fairly straight forward, no?
[19:33:50] <seb_kuzminsky> well i think so :-)
[19:34:30] <seb_kuzminsky> the interface for the hm2 "sub-drivers" isn't as clean as it could be, but it's usable
[19:34:56] <seb_kuzminsky> there's a bunch of functions to write, and they have to be added to the hostmot2 "parent driver" in the right places...
[19:35:14] <seb_kuzminsky> that's probably the icky-est part of adding hm2 sub-drivers today
[19:35:49] <seb_kuzminsky> i have a vague plan to formalize that interface some, so you fill out a sub-driver struct with callback functions, but that's not in place yet
[19:35:57] <SWPadnos> cool
[19:36:34] <SWPadnos> it could even be separate HAL modules, which might help the loadrt config options
[19:37:18] <SWPadnos> loadrt hostmot2 / laodrt hm2_pci / loadrt hm2_stepgen stepgens=3,4,5 ...
[19:38:32] <geo01005> So is anybody aware of some standard SPI models?
[19:38:41] <seb_kuzminsky> SWPadnos: it's not quite that easy unfortunately
[19:38:55] <SWPadnos> the only thing that's standard about SPI is that it uses clock, data, and chip select lines
[19:39:10] <SWPadnos> there are no additional definitions that define what the data is, unfortunately
[19:39:16] <SWPadnos> seb_kuzminsky, yes, I know there are issues :)
[19:39:22] <seb_kuzminsky> the hal hm2-sub-driver module would have to be told what board(s) to attach itself to, and have separate config strings for them all...
[19:40:03] <seb_kuzminsky> how about this
[19:40:16] <SWPadnos> each function module (stepgen/pwmgen ...) only needs to know which board numbers it should try to use, and which functions to enable on those boards
[19:40:24] <seb_kuzminsky> this is my understanding of SWPadnos's idea the other day
[19:40:46] <seb_kuzminsky> the hm2-spi sub-driver would export to HAL something very like the BSPI interface afforded by the hm2 firmware
[19:40:59] <seb_kuzminsky> then separate spi-slave drivers would be in separate hal modules
[19:41:11] <seb_kuzminsky> then hal nets would be used to connect them
[19:41:14] <seb_kuzminsky> hm?
[19:41:50] <geo01005> Would certinly work, but what do I know.
[19:42:19] <seb_kuzminsky> SWPadnos: is that what you meant yesterday?
[19:43:41] <geo01005> Wouldn't you need something to get from the slave driver to hm2?
[19:43:49] <seb_kuzminsky> geo01005: hal
[19:44:02] <seb_kuzminsky> the slave driver would set the hm2-spi-driver's hal pins & params
[19:44:26] <seb_kuzminsky> i havent thought it trough, i just like the idea of using hal to dynamically connect slave-drivers to spi uarts
[19:45:09] <SWPadnos> seb_kuzminsky, that's kind of like what I meant
[19:45:29] <SWPadnos> I don't know that HAL pins/signals are the best way of doing lower level stuff though
[19:46:22] <SWPadnos> it would be nice if the hm2 SPI driver could just present the data (in and out) on pins, and have the other module cook that so it's useful
[19:46:47] <seb_kuzminsky> the other modules (the spi-slave modules) would have to be able to specify framing & timing parameters i think
[19:46:54] <SWPadnos> I'm not sure what you mean by "export the BSPI interface" (I don't actually know what the B stands for either ;) )
[19:47:08] <seb_kuzminsky> that's peter's "buffered spi" interface
[19:47:12] <SWPadnos> seb_kuzminsky, maybe, maybe not
[19:47:18] <SWPadnos> ah, buffered - thanks ;)
[19:47:42] <SWPadnos> I guess I'm thinking about it at a high level
[19:47:46] <geo01005> So the firmware takes care of all the hardware timing, right?
[19:47:48] <SWPadnos> you have an SPI interface in the hm2
[19:48:19] <SWPadnos> that interface takes care of moving data over a serial bus and presenting it to HAL
[19:48:43] <SWPadnos> if I want to connect a particular A/D to a parallel port pin, and use a parallel port software SPI driver, I'll get the same data
[19:49:05] <seb_kuzminsky> geo01005: yes, that's part of spi, you just feed it (and get back) a sequence of bytes
[19:49:17] <SWPadnos> if I buy a SPI interface card (I think they exist), then I'll get the same data for my "end-user device" driver
[19:49:40] <seb_kuzminsky> SWPadnos: yeah
[19:49:49] <SWPadnos> abut the setup for those three transfer devices is different
[19:49:53] <SWPadnos> s/abut/but/
[19:50:38] <seb_kuzminsky> now we need something like the parport layer in the non-realtime linux kernel, where you register your low-level spi uart driver with the framework, and then slave-drivers can attach themselves to these abstract spi uarts
[19:50:43] <SWPadnos> in the end, I want to connect an int or something to the input of my A/D driver, and then split out status / sign / scaling in my driver
[19:50:58] <SWPadnos> or whatever
[19:51:13] <SWPadnos> I don't know if that's getting too generic and modular though :)
[19:51:25] <SWPadnos> hmmm
[19:51:39] <SWPadnos> always check the other end of the granola bar package before trying to open this end
[19:52:39] <seb_kuzminsky> mmm granola bar
[19:52:43] <seb_kuzminsky> bbl lunch
[19:52:46] <SWPadnos> heh
[19:53:14] <geo01005> going to class...
[19:53:22] <SWPadnos> see you
[20:52:22] <rob> rob is now known as Guest93918
[20:53:46] <Guest93918> Guest93918 is now known as rob__
[20:54:16] <rob__> rob__ is now known as robh__
[21:31:14] <skunkworks_> http://imagebin.ca/img/HjlIxz.jpg
[21:31:23] <skunkworks_> I swear I suck at copy and paste
[21:31:43] <skunkworks_> http://www.cnczone.com/forums/showpost.php?p=569445&postcount=126
[21:43:56] <cradek> I think mesa already has pci express cards
[21:44:14] <skunkworks_> I rememeber a converstion about aht.
[21:44:15] <skunkworks_> that
[21:44:24] <cradek> (not sure I've ever seen a single motherboard without a PCI slot)
[21:44:58] <cradek> "the interface cards available today work only with today's hardware!!" isn't a big criticism IMO
[21:45:05] <skunkworks_> heh
[21:45:12] <cradek> no, I'm serious
[21:45:36] <cradek> folks are actively building hardware to work with emc.
[21:45:37] <skunkworks_> what - emc will evolve? ;)
[21:45:41] <archivist> it is if we want older boards for better latency
[21:46:10] <cradek> archivist: but older motherboards are more likely to have pci and parport
[21:46:11] <archivist> * archivist thinking of the power management
[21:46:33] <cradek> this post was about the (greatly exaggerated IMO) death of pci and parport
[21:46:54] <archivist> parports are hard to find in the UK
[21:48:08] <archivist> only ones I found new have the dodgy chips
[21:48:13] <cradek> http://www.cnczone.com/forums/showpost.php?p=557808&postcount=122
[21:48:37] <pjm_> archivist i found a nice dual-port card on ebay for 15 quid that works perfectly with emc2
[21:48:40] <cradek> about this one: I just installed two machines on 8GB CF cards. the CF cards that size are a couple dozen dollars...
[21:49:11] <seb_kuzminsky> lots of folks are still in the 1990's-era "fit it on a floppy" mentality
[21:49:13] <cradek> (of course I wouldn't miss openoffice either)
[21:49:33] <archivist> heh I use the spreadsheet often for gear calcs please keep in default install
[21:49:49] <cradek> fwiw, I think the base hardy install actually is < 2GB. I was surprised.
[21:49:53] <cradek> not much <.
[21:50:42] <archivist> pjm_, what chips are on the cards
[21:51:12] <pjm_> i can give u the ebay item # for the card i bought
[21:51:29] <pjm_> but the card itself is in the pc
[21:51:31] <archivist> if netmos then ....
[21:51:39] <pjm_> ah no it wasnt a netmos
[21:51:43] <pjm_> i avoided them
[21:52:06] <skunkworks_> netmos works just fine if you don't use epp
[21:52:21] <archivist> that 8410 system went cheap last week
[21:52:30] <skunkworks_> (pluto and mesa parallel port cards)
[21:52:33] <pjm_> i'm half considering buying a mesa 5i20
[21:53:31] <pjm_> archivist
http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=260324698558
[21:53:33] <pjm_> was the card
[21:54:01] <cradek> pjm_: you won't ever regret buying a mesa instead of screwing around with parports
[21:54:28] <seb_kuzminsky> * seb_kuzminsky agrees
[21:54:39] <pjm_> cradek yeah well i'm getting to the point i need higher IO speeds, particularly as I want to use a 'proper' spindle encoder
[21:54:47] <pjm_> rather than my home-made 8ppr
[21:55:07] <archivist> I need to as well for hobbing
[21:55:11] <seb_kuzminsky> you can do high-res encoders fine over the parport with a 7i43
[21:55:17] <geo01005> I like my 7i43, but wish I had a 5i20.
[21:55:58] <geo01005> Computer dosn't have a PCI slot....
[21:56:03] <cradek> a wish and a couple hundred dollars...
[21:56:14] <cradek> doh
[21:56:14] <seb_kuzminsky> geo01005: wow! what kind of computer?
[21:56:54] <pjm_> ah 7i43,, interesting, i need to look at that
[21:57:34] <pjm_> i want to have a decant pulse train output for spindle speed and a encoder input from it etc
[21:57:43] <geo01005> it isn't new. It's a all in one machine, no expansion ports.
[21:58:20] <seb_kuzminsky> wow, *no* ports, not even pc/104-plus?
[21:58:26] <geo01005> nope.
[21:58:37] <seb_kuzminsky> then 7i43 is for you ;-)
[21:58:40] <geo01005> Just the par port and USB
[21:58:47] <geo01005> oh, and ethernet.
[21:59:00] <seb_kuzminsky> there's an ethernet anyio board coming out...
[21:59:28] <geo01005> ooooooh, I've been deaming about that for a while now :)
[21:59:40] <geo01005> ethernet anyio board :)
[21:59:40] <skunkworks_> seb_kuzminsky: are you working on a rt eithernet driver for hal? ;)
[21:59:59] <skunkworks_> lots of people would love you.. ;)
[22:00:07] <seb_kuzminsky> heh
[22:00:08] <geo01005> got to run.
[22:00:10] <seb_kuzminsky> no i have no plans to hack on that
[22:00:17] <archivist> aw
[22:00:26] <seb_kuzminsky> see ya geo01005
[22:01:38] <seb_kuzminsky> maybe after i finish converting my manual benchtop mill & lathe ;-)
[22:01:52] <seb_kuzminsky> that should be, oh, about 2099 or so at this rate ;-)
[22:02:17] <archivist> its already 2009 so should be done!
[22:03:05] <skunkworks_> http://www.cnczone.com/forums/showpost.php?p=569462&postcount=127
[22:03:49] <pjm_> btw the 7i43, do i need the 200k or 400k gate fpga?
[22:04:04] <seb_kuzminsky> the 200 K currently does everything the 400 K does
[22:04:15] <seb_kuzminsky> future firmwares *may* be bigger, but for now the 200K is fine
[22:04:31] <seb_kuzminsky> i'd say, buy the 200K and save your pennies for a 5i23
[22:06:34] <pjm_> yeah for 80$ that is a good price actually
[22:07:23] <SWPadnos> just to play devils advocate, for an extra $10, you can be sure that your FPGA is big enough :)
[22:07:34] <SWPadnos> or maybe it's $20
[22:07:46] <seb_kuzminsky> $10 is like three days of my coffee habit
[22:08:14] <cradek> seb_kuzminsky: you know you can make that stuff at home, right?
[22:08:23] <seb_kuzminsky> oh, i do
[22:08:40] <seb_kuzminsky> and at the office
[22:08:45] <seb_kuzminsky> it adds up ;-)
[22:08:49] <seb_kuzminsky> * seb_kuzminsky jitters off the chair
[22:08:52] <SWPadnos> heh
[22:09:23] <SWPadnos> it's funny that I can buy 2 pounds of coffee beans at Costco (about a 1 month supply at a pot a day) for the same amount as 3-4 cups of regular coffee at Starbucks
[22:09:25] <skunkworks_> * skunkworks_ just found out they added mocha to the vendo machine
[22:10:11] <skunkworks_> 3 cups later....
[22:12:13] <skunkworks_> (still only $1.50)
[22:12:40] <seb_kuzminsky> anyone know any books or movies that feature machining or fabrication as plot points?
[22:14:03] <SWPadnos> err
[22:14:05] <archivist> do a search on openlibrary.org
[22:14:14] <SWPadnos> only ones that feature "grey goo" type of stuff
[22:14:28] <SWPadnos> nothing like "James Bondo" or anything
[22:14:29] <skunkworks_> The flight of the phenix.. sort of..
[22:14:39] <skunkworks_> phenix?
[22:14:45] <SWPadnos> phoenix, probably
[22:14:51] <archivist> revenge of the cnc
[22:15:01] <skunkworks_> one with jimmy stuart is pretty good
[22:15:07] <SWPadnos> "Arc Buddy from HELL"
[22:15:09] <skunkworks_> I have not seen the latest
[22:15:10] <seb_kuzminsky> the lathe that ate denver
[22:15:22] <SWPadnos> there's "The Iron Giant", sort of
[22:15:41] <SWPadnos> "The Time Machine"
[22:15:42] <archivist> drop forged in hell
[22:15:45] <SWPadnos> sort of :)
[22:15:51] <pjm_> btw, out of interesting, what is the maximum pulse train freq i should expect to be able to generate and read with a 7i43? 50KHz?
[22:16:06] <skunkworks_> heh - I think it is in the mhz..
[22:16:12] <SWPadnos> MHz
[22:16:17] <pjm_> ahh wow, that high
[22:16:30] <SWPadnos> on the generator side, it will be higher than any step/dir drive can handle
[22:16:34] <seb_kuzminsky> 7i43: 100 MHz
[22:16:38] <pjm_> so my 125ppr encoder would be fine at the top speed of 6K RPM
[22:16:49] <pjm_> ok great - thanks ;-)
[22:17:05] <seb_kuzminsky> oh, encoder input, i thought you meant pwmgen
[22:17:07] <SWPadnos> lessee, 125*4 = 500, *100 RPS = 50 kHz
[22:17:31] <archivist> but accelerating it up and back down wont be that quick
[22:17:50] <pjm_> well i need a pulse train output too for my VFD, but that is up to about 33KHz I think it said the maximum input freq is
[22:17:52] <SWPadnos> accel has nothing to do with resolution
[22:17:55] <seb_kuzminsky> ten or so mhz for encoder edge frequency on the PCI boards, a bit more on the 7i43
[22:18:05] <skunkworks_> there is a movie called 'the machinist' but I think that is his occupation - not really the story
[22:19:05] <skunkworks_> in castaway - he fabricates a lot of things..
[22:19:11] <skunkworks_> ;)
[22:19:15] <SWPadnos> MacGyver
[22:19:27] <skunkworks_> junk yard wars.
[22:19:30] <SWPadnos> heh
[22:19:36] <skunkworks_> the british version.
[22:19:44] <SWPadnos> also MythBusters
[22:19:47] <seb_kuzminsky> i tried to watch "rough science" but couldnt take it
[22:38:10] <seb_kuzminsky> * seb_kuzminsky fetches flight of the phoenix
[22:57:04] <mshaver> seb_kuzminsky: Which one, the original with Jimmy Stewart, or the new remake?
[22:57:57] <mshaver> or perhaps the book...
[22:58:50] <seb_kuzminsky> both the movies
[22:58:55] <seb_kuzminsky> i'll watch them side by side to compare
[22:59:39] <seb_kuzminsky> tonight i'm going to see "Children of Men", one of my fave dystopian sci-fi flicks
[22:59:47] <mshaver> The original is better, but then again...
[22:59:51] <mshaver> * mshaver is old!
[22:59:56] <seb_kuzminsky> heh
[23:01:56] <mshaver> I'll have to check that one out. Tonight I'm going to go to sleep listening to this William Gibson book-on-tape, although the way I feel, I won't get very far with it.
[23:02:14] <seb_kuzminsky> which one?
[23:02:38] <mshaver> It's called Spook Country
[23:02:50] <seb_kuzminsky> i liked that one :-)
[23:03:12] <mshaver> I'm only just into the second cd
[23:04:11] <mshaver> I need to get together with you and work on some following error stuff one of these days
[23:04:31] <seb_kuzminsky> sounds good
[23:04:44] <seb_kuzminsky> you heard the v0 stepgens in the 2.2 firmwares are all bad, right?
[23:04:48] <mshaver> stepgen_maxaccel is a strange variable
[23:05:09] <mshaver> I have a bitfile from Peter with V1
[23:05:28] <seb_kuzminsky> i wouldnt be terribly surprised if i messed up on the stepgen maxvel and maxaccel...
[23:05:33] <seb_kuzminsky> any feedback is welcome...
[23:05:43] <mshaver> maxvel seems fine
[23:06:12] <seb_kuzminsky> what's maxaccel doing to you?
[23:06:21] <mshaver> maxaccel is odd: if too low, following error grows, if too high, motion is jerky
[23:07:06] <seb_kuzminsky> ferror should always grow during the accel phase of a motion; with lower maxaccel that phase will last longer
[23:07:14] <mshaver> This is also odd:
[23:07:17] <mshaver> http://www.mattshaver.com/emc2/halscope/asym-ferror.png
[23:07:52] <seb_kuzminsky> how it creeps up during the cruise? or how it's asymmetric? (or both?)
[23:07:54] <SWPadnos> seb_kuzminsky, did you use the stepgen algorithms from the software stepgen?
[23:08:05] <seb_kuzminsky> sort of
[23:08:06] <mshaver> the asym part
[23:08:16] <SWPadnos> so the accel and that kind of stuff?
[23:08:43] <seb_kuzminsky> brb
[23:08:47] <SWPadnos> next question: if you update the step rate register(s), does the FPGA snap to the new rate or slew to it?
[23:08:50] <SWPadnos> darn
[23:09:06] <mshaver> darn exp2
[23:09:12] <SWPadnos> heh
[23:12:11] <seb_kuzminsky> SWPadnos: snap
[23:12:17] <seb_kuzminsky> accel is handled in the driver
[23:12:40] <seb_kuzminsky> it's a "dirty room" implementation - i read the stepgen.c code and then implemented the hm2 stepgen
[23:12:43] <SWPadnos> ok, so you took out all the stuff in stepgen that tried to calculate the number of steps that would be issued over the next servo period?
[23:13:20] <SWPadnos> since the stepgen make_pulses function slews to the new rate, the stepgen step generator is conceptually differnt from the hm2 one
[23:13:30] <seb_kuzminsky> well i didnt take it out, i never implemented it in the first place ;-)
[23:13:30] <SWPadnos> different too
[23:13:41] <SWPadnos> ah - that's less work, good ;)
[23:15:19] <seb_kuzminsky> mshaver: in that pic, is there headroom between stepgen.maxvel and the tp's maxvel?
[23:15:48] <mshaver> no
[23:16:04] <SWPadnos> oh -silly you ;)
[23:16:18] <seb_kuzminsky> didn't we talk about headroom already young man?!
[23:16:19] <SWPadnos> you should have a couple percent headroom for both accel and vel
[23:17:05] <mshaver> Yeah, but I've changed that. The problem is a "couple percent" isnt enough, but too much stepgen_maxaccel is also bad.
[23:17:32] <SWPadnos> if you need more headroom, you need to get it by reducing the TP maxacecl/maxvel
[23:17:35] <seb_kuzminsky> wait, we're talking about vel, not accel, right now, right?
[23:17:42] <SWPadnos> not by increasing the stepgen limits
[23:18:14] <SWPadnos> the stepgen needs to be set at or below the physical capabilities of the motors
[23:18:55] <SWPadnos> the TP needs to be enough below that to prevent FE
[23:19:20] <SWPadnos> what are the actual numbers for (MIN_)FERROR and the accels/vels?
[23:19:29] <mshaver> but, let's say there were no stepgen max anything, then the only limitation would be the TP limits, right?
[23:19:37] <mshaver> http://www.mattshaver.com/emc2/configs/smithy/1240.ini
[23:20:03] <seb_kuzminsky> mshaver: well, and the limits imposed by the mechanism
[23:20:36] <seb_kuzminsky> mshaver: what!? axis instead of easytroll?
[23:20:41] <mshaver> yes, exactly. But why is stepgen_maxaccel = 1000 ok, but 100000 is bad?
[23:20:45] <SWPadnos> -l ;)
[23:21:04] <mshaver> I knew they were asking for it with that name...
[23:21:21] <seb_kuzminsky> if maxaccel is too high, inertia might be too much for the stepper's torque?
[23:21:32] <seb_kuzminsky> or maybe i have a bug? :-/
[23:21:47] <mshaver> but what I want is _only_ the tp limits
[23:21:49] <SWPadnos> this config should work the same regardles sof whether the machine is attached
[23:21:57] <SWPadnos> all you need is the 7i43 to test it out
[23:22:10] <SWPadnos> it should have nothing to do with the motors
[23:22:28] <mshaver> I just want the stepgen to do what the tp says, not add another layer of filtering
[23:22:35] <seb_kuzminsky> good point - power off the steppers and look at halscope to see if the stepgen position feedback follows the tp's commands
[23:22:58] <SWPadnos> seb_kuzminsky, it makes no difference if the motors are attached (so the already-takes traces should be valid)
[23:23:05] <SWPadnos> s/takes/taken/
[23:23:06] <mshaver> there's no real feedback here
[23:23:14] <seb_kuzminsky> right
[23:23:32] <SWPadnos> mshaver, are the hal files in the same place?
[23:23:34] <seb_kuzminsky> the "feedback" is from the hm2 stepgen, telling emc where it actually stepped to
[23:23:50] <mshaver> yes, just view the dir
[23:23:54] <SWPadnos> ah yes, I see that
[23:24:35] <mshaver> if you go up to .com/emc2 you can see everything
[23:24:56] <SWPadnos> I bet there's an overflow problem in the accel calcs
[23:25:07] <mshaver> I'm looking at my usb key to see if I have other scope pics
[23:25:26] <SWPadnos> scale is 50800 * accel=100000 = > 32 bits
[23:25:35] <SWPadnos> (or 31)
[23:25:44] <mshaver> sign?
[23:25:53] <SWPadnos> then again, it could be a float, so don't listen to me ;)
[23:29:31] <mshaver> this is probably the latest ferror trace:
[23:29:34] <mshaver> http://www.mattshaver.com/emc2/halscope/g1x10f460.png
[23:30:05] <seb_kuzminsky> that looks pretty good to me
[23:30:20] <SWPadnos> hmmm. I think you can remove the hm2_5i20.{read,write}_gpio functions
[23:30:22] <seb_kuzminsky> what's wrong that i'm missing?
[23:30:34] <SWPadnos> read and write do the GPIO as well, don't they?
[23:30:38] <seb_kuzminsky> SWPadnos: yes
[23:30:59] <seb_kuzminsky> the *_gpio functions are for if you want to do *just* gpio in a faster thread
[23:31:03] <SWPadnos> right
[23:31:07] <mshaver> if I make stepgen_maxaccel less than 1000, but still much greater than tp maxaccel, it gets asymetrical and rounded
[23:31:09] <seb_kuzminsky> the normal read and write do everything, including gpio
[23:31:24] <SWPadnos> seb_kuzminsky, the problem there is that it goes to 0.022 or so and stays there
[23:31:30] <SWPadnos> it=ferror
[23:31:36] <seb_kuzminsky> isn't that good?
[23:31:53] <SWPadnos> it should be slightly nonzero during accel and decel, but as close to zero as possible at all other times
[23:32:18] <SWPadnos> 0.22 isn't very good at all, especially for synthesized feedback
[23:32:20] <mshaver> if I make stepgen_maxaccel 100000, it has the same shape, but lots of high frequency noise rides on the trace and the motors get _very_ rough
[23:32:22] <SWPadnos> err, 0.022
[23:32:38] <seb_kuzminsky> how can it be close to zero during cruise without feedforward?
[23:33:13] <SWPadnos> there's no PID, everything is feedforward for stepgen
[23:33:23] <seb_kuzminsky> hmm
[23:33:33] <seb_kuzminsky> as i understood it, it's more like "everything is P"
[23:33:59] <SWPadnos> could be
[23:34:11] <seb_kuzminsky> well those two are very different
[23:34:14] <SWPadnos> yeah ;)
[23:34:46] <seb_kuzminsky> i wonder what that last trace would look like with sw stepgen
[23:34:50] <SWPadnos> I think the software stepgen has a "pre-tuned PID"
[23:34:54] <SWPadnos> you could try it ;)
[23:35:00] <mshaver> Here's another good one: You'll note that SERVO_PERIOD = 100000 in the .ini. If I change that to SERVO_PERIOD = 1000000, the machine won't run at all. The motion is horrible.
[23:35:23] <SWPadnos> I did notice the 10 kHz update rate
[23:35:37] <SWPadnos> I was surprised until I saw that it's a 5i20 rather than a 7i43
[23:35:53] <seb_kuzminsky> i run my development machine at 1 Khz just fine, i wonder what's up with that
[23:35:53] <mshaver> JMK asks me about it all the time. I always say, "it's the only way it will work".
[23:36:33] <SWPadnos> mshaver, do you change it so all three are 1M?
[23:36:37] <SWPadnos> or just servo?
[23:36:45] <seb_kuzminsky> i wonder if your 400 KHz steprate is implicated in that problem too...
[23:37:30] <SWPadnos> oh interesting. the maxvel is too high for the stepgen
[23:37:31] <mshaver> I've tried most all permutations. Only the servo thread is used for hal functions.
[23:37:49] <SWPadnos> 50800 * 10 = 508000, the max rate is 400 kHz with those timing parameters
[23:38:15] <mshaver> what's the *10?
[23:38:21] <SWPadnos> STEPGEN_MAXVEL
[23:39:38] <SWPadnos> so your max vel is slughtly under 480 IPM (as noted in the comments), or <8 IPS (is that where the 7.7 came from elsewhere?)
[23:39:45] <SWPadnos> slightly
[23:39:51] <mshaver> yes, but: 1: maxvel can be set to 100000000 and it works fine, and 2: both of these params are maxs - the tp will never exceed it's own limits
[23:40:54] <SWPadnos> well, you have a point
[23:40:55] <SWPadnos> or two
[23:41:31] <seb_kuzminsky> i gotta go but i'll look into this later tonight
[23:41:42] <mshaver> yep, they're 400kHz drives:
http://www.leadshine.com/2-4-21.html
[23:41:59] <mshaver> see you seb! thanks!
[23:42:51] <SWPadnos> what's between the 5i20 and the stepper drivers?
[23:43:11] <mshaver> a 7i47 ;)
[23:43:25] <SWPadnos> well, that's a problem
[23:43:35] <mshaver> why?
[23:43:36] <SWPadnos> the I/Os on the 7i47 may not be fast enough
[23:43:47] <mshaver> not a 37, a 47 ;)
[23:44:00] <SWPadnos> oh. I should look at what that is :)
[23:44:05] <mshaver> it's an rs422 differential card
[23:44:11] <SWPadnos> ah, ok
[23:44:14] <mshaver> don't bother, not on their site
[23:44:20] <SWPadnos> righto
[23:44:49] <SWPadnos> interesting application of RS422 - drive the LED in one state and don'reverse bias in the other - clever way to avoid hooking up a power supply
[23:44:51] <mshaver> I use it for stepgen and pwm outs and encoders in
[23:44:59] <SWPadnos> ok
[23:45:18] <mshaver> actually recommended by the drive maker
[23:45:44] <mshaver> it does reverse bias at 5v, but the optos can take it
[23:46:10] <mshaver> I guarantee it turns off!
[23:46:52] <SWPadnos> yep
[23:47:05] <SWPadnos> the pain with optos is usually having to have a power supply in there
[23:47:15] <SWPadnos> well, that and delay times :)
[23:47:38] <mshaver> the pain with this setup is that many drives common the anode for step & dir
[23:47:45] <mshaver> like a gecko
[23:47:54] <SWPadnos> yes indeed
[23:48:12] <mshaver> the chinese drives though are typically independent
[23:52:07] <mshaver> well SWP, I think I'm going to get some sleep. Oh, forgot to ask: Is fest in KS?
[23:52:20] <SWPadnos> no idea :)
[23:52:33] <SWPadnos> we should probably send a mail to the dev list at some point
[23:52:43] <SWPadnos> lest the rumor mill take over and decide for us
[23:53:14] <mshaver> yeah. I'd like to have it here: shorter drive for us!
[23:53:17] <SWPadnos> I think we may end up with an "old style" fest this year, I don't know if anything similar to the CNC workshop will come together
[23:53:40] <SWPadnos> Greg Jackson has also offered, but I don't know if you could come ;)
[23:53:52] <mshaver> I think we _need_ and old style fest
[23:53:58] <mshaver> I'd come.
[23:54:03] <SWPadnos> maybe we should ask Fred also, NIST was a pretty good spot
[23:54:16] <SWPadnos> yeah. I don't think we've gotten much done at the workshops :)
[23:54:26] <mshaver> after 9/11 it's kind of spooky over there
[23:54:38] <SWPadnos> I've only been there after 9/11 :)
[23:55:27] <mshaver> really? you used to be able to just drive on in, park & go inside. I used to joke that I could go there, take an office, and noone would be the wiser.
[23:55:36] <SWPadnos> heh
[23:55:38] <SWPadnos> that would have been fun
[23:55:51] <mshaver> they do have some stuff
[23:55:52] <SWPadnos> I was only there for Fest in 2005(?)
[23:55:58] <SWPadnos> maybe it was 2006
[23:56:26] <SWPadnos> no, 2005. there were 3 CNC workshops, and the Fest before that was my first
[23:56:45] <geo01005> Quick (hopefully) SPI question. Any reason to support the interupt function that some SPI GPIO chips provide?
[23:56:52] <mshaver> I thought the NIST fest was pre-police-state
[23:57:00] <geo01005> Interupt generated on pin change.
[23:57:11] <SWPadnos> geo01005, not on the PC side. at the moment HAL can use exactly one interrupt, and that's the timer
[23:57:47] <mshaver> yeah, we're a strictly polled system
[23:57:48] <SWPadnos> mshaver, there may have been one before the one I attended, but when we were there, Fred had to escort us to lunch every day, and we had to get guest passes and stuff
[23:58:14] <SWPadnos> then again, I would have gotten lost without an escort, especially before eating
[23:58:14] <geo01005> The only reason I could think of is to only read the device if the input has changed, but that would lead to some jitter in the loop, I think.
[23:58:16] <mshaver> wow. could I have missed a whole fest?
[23:58:24] <SWPadnos> no, you were there
[23:58:43] <mshaver> actually, that's worse...
[23:59:53] <mshaver> I mean, I remember being there, but that I can't place it within even a five year window of time...
[23:59:54] <SWPadnos> let's see. you, Tom Hubin, Steve S, JMK, Ray, Paul, me, Martin Kuhnle (I think), someone else from europe, Fred, Jon E, and a couple others I don't remember
[23:59:57] <SWPadnos> heh
