Back
[00:15:09] <jmkasunich> btw, jepler / cradek - feature request for axis
[00:16:02] <jmkasunich> in mill mode. I can zoom/pan the preview to hell and gone, and then get back to a nice overall view by hitting the predefined view buttons (two Z views, X, Y, and perspective)
[00:16:18] <jmkasunich> in lathe mode, if I get the zoom or pan off in left field, there is no easy recovery
[00:16:36] <jmkasunich> can you put a "restore default view" button up where the mill predefined view buttons are?
[01:07:41] <cradek> jmkasunich: hit "v"
[01:07:59] <cradek> but yeah, it should have an icon so it's discoverable
[01:22:51] <SWPadnos> jmkasunich, I think the idea might be to "DMA" all the data into memory, regardless of which type of device it's coming from
[01:23:05] <SWPadnos> then the driver code deals with memory structures rather than many PCI reads
[01:23:10] <SWPadnos> (or EPP reads)
[01:23:39] <SWPadnos> whether it's DMA or not is immaterial, the code would do a block transfer of whatever data is needed
[01:26:01] <jmkasunich> DMA adds a constraint for the VHDL designer
[01:26:09] <jmkasunich> all registers must only be written once
[01:26:43] <jmkasunich> what if I want to design VHDL and a matching driver that needs to write multiple things per one iteration of the driver code
[01:26:47] <jmkasunich> or even conditional writes, etc
[01:27:27] <jmkasunich> my point is that EPP constrains the design - if I wanted to live within those constraints I would buy an EPP product - I bought a PCI card because I'm not afraid to open my computer, and I want the benefits of PCI
[01:30:42] <SWPadnos> considering that there's a lot of address space for both PCI and EPP, I'd say that VHDL that re-uses a single address for multiple things (like the G100 using the same address for all 6 velocity registers) is a strange if not bad design
[01:31:10] <jmkasunich> I'm not thinking of doing that kind of stuff so much
[01:31:20] <jmkasunich> more a matter of things like syncing
[01:31:30] <SWPadnos> I can understand conditional writes though - somethng like a reset register or something
[01:31:32] <SWPadnos> sure
[01:32:26] <jmkasunich> IMO the difference between PCI and EPP isn't just quantitative (bandwidth), its qualitative
[01:32:43] <SWPadnos> I guess I was looking at it like the USC (which is EPP of course)
[01:32:48] <jmkasunich> you design things differently, and you code differnetly, when you aren't breathing through a straw
[01:32:58] <SWPadnos> the low level code reads in a block of data and writes out a block of data
[01:33:11] <SWPadnos> it doesn't matter how that data gets moved, or over which bus
[01:33:16] <jmkasunich> and the USC is constrained by that limitation
[01:33:26] <jmkasunich> you simple can't do some things
[01:33:34] <SWPadnos> right
[01:33:54] <SWPadnos> incidentally, if I'm keeping you from some machining, we can talk about it at the hotel tomorrow :)
[01:34:07] <jmkasunich> if a PCI card will let me do things that EPP won't, I don't want the driver arch to say "sorry, can't do that cause the least common denominator (EPP) won't do it"
[01:34:14] <jmkasunich> we should
[01:34:38] <jmkasunich> (I'm going back and forth because I edit the g-code here with a nice kb and screen, then run it there)
[01:34:53] <SWPadnos> sure, I wouldn't want to limit the possibilities of a PCI card with the architecture
[01:35:16] <SWPadnos> but any function that can't be done on EPP wouldn't need to use the unified interface - that function couldn't exist on an EPP card
[01:36:24] <SWPadnos> so if the implementation is to have a function pointer and a data address for reads and writes, then for PCI the address base might be the PCI address and the function is pci_write()
[01:36:37] <SWPadnos> for EPP the address is a memory buffer and the function is fake_EPP_write()
[01:37:46] <jmkasunich> cradek: hitting v makes that letter appear in the MDI box
[01:38:05] <jmkasunich> seb_kuzminsky: I commented a bit on your discussion with SWP earlier - take a look at the log
[01:38:30] <SWPadnos> we'll talk more later - I have to pack for tomorrow morning now :)
[01:38:38] <SWPadnos> when does your flight leave?
[01:38:40] <jmkasunich> me too, after I make these parts
[01:38:43] <SWPadnos> heh.
[01:38:50] <jmkasunich> 8ish?
[01:39:00] <SWPadnos> weird - is it not a direct flight?
[01:39:08] <jmkasunich> its direct
[01:39:18] <jmkasunich> might be 8:50ish
[01:39:24] <SWPadnos> oh right - you arrive a couple of hours earlier
[01:39:31] <SWPadnos> in a different town
[01:39:53] <jmkasunich> minor details
[01:39:58] <SWPadnos> it sounded strange because my flight leaves at 8:20 and I arrive (via Chicago) at 2:15 - about the same time as you
[01:40:10] <SWPadnos> I just forgot about the car trip in there ;)
[01:43:41] <cradek> jmkasunich: in f3 tab
[01:43:59] <jmkasunich> yeah, I found that out
[01:44:08] <jmkasunich> inconvenient when I'm in F5 tab
[01:44:21] <cradek> sure thing
[01:44:24] <jmkasunich> the buttons always work in mill mode
[01:44:25] <SWPadnos> anyone have any suggestions on stuff to bring (other than proper attire)?
[01:44:50] <jmkasunich> I was gonna ask several questions, but I really should shut up now
[01:44:56] <cradek> a devel environment
[01:45:05] <SWPadnos> yeah - got that on the laptop (sim only though)
[01:45:12] <jmkasunich> are either of you going to be up late tonight (11pm eastern or so)
[01:45:19] <SWPadnos> I'll be up taht late I'm sure
[01:45:25] <SWPadnos> that
[01:45:31] <cradek> I probably will, but barely
[01:45:39] <jmkasunich> I want to talk about the trip, but I simply MUST make these parts, and drop them off
[01:45:59] <SWPadnos> ok. I'll wait around a bit to be sure we can discuss it
[01:46:05] <cradek> if I'm not around, I'll read in the morning
[01:46:05] <SWPadnos> if necessary ;)
[01:46:46] <SWPadnos> I could actually bring one of these little embedded computers in a carry-on suitcase
[01:46:51] <SWPadnos> with a 5i22 in it
[01:47:00] <jmkasunich> some of my q's are things like "how cold is it in the shop" which will affect the packing I do tonight
[01:47:05] <jmkasunich> tomorrow is a bit late for that
[01:47:06] <SWPadnos> heh
[01:47:37] <SWPadnos> it's a working machine shop, so my bet is that it's cold in the morning and just fine the rest of the day
[01:48:04] <cradek> it was tolerable but I don't recall what month I was there
[01:48:20] <cradek> there was a wide variation in temp
[01:48:28] <SWPadnos> I thought it was in summer - within a few months of CNC workshop
[01:48:36] <cradek> take layers I guess
[01:49:09] <cradek> it was rainy and I think cold
[01:49:23] <cradek> no, rainy and hot
[01:49:26] <cradek> forget it, this is pointless
[01:49:32] <SWPadnos> so hot and muggy
[01:49:47] <cradek> yes and some areas were cooled, some not
[01:50:31] <cradek> I bet our setup will be in a comfortable room, but the G&L will be cold
[01:51:01] <skunkworks> a few of you guys are going to stuarts shop?
[01:51:05] <SWPadnos> yep
[01:51:28] <skunkworks> that sounds interesting... Going to play with scales + encoders?
[01:51:41] <cradek> yes that's one of the goals
[01:51:59] <SWPadnos> but no steppers!
[01:52:00] <SWPadnos> :)
[01:52:01] <skunkworks> Neat (that is something - someday) that We would like to try.
[01:52:33] <SWPadnos> hmmm. does anyone know if those scales are absolute?
[01:52:46] <jmkasunich> sheeit
[01:52:57] <SWPadnos> whaa-it?
[01:53:16] <jmkasunich> all this farting around, and a typo made me hit the work and lose steps (and thus my carefully achieved touch-off)
[01:53:24] <SWPadnos> bummer
[01:53:37] <skunkworks> yecky
[01:53:48] <SWPadnos> AXIS_IS_UNHOMED=1
[01:54:05] <jmkasunich> actually, its X that lost it, and I can home X
[01:54:16] <jmkasunich> unfortunately, I only have a home-all button
[01:54:34] <skunkworks> jog it to a known position..
[01:54:40] <jmkasunich> and if I do that, I lose my Z touch off (no home switch on Z)
[01:54:42] <SWPadnos> [AXIS_0][I_MEANT_JOINT_0]IS_UNHOMED=1 :)
[01:55:12] <SWPadnos> if you have a mouse, can't you select an axis and hit the home key?
[01:55:17] <cradek> jmkasunich: use the menu
[01:55:18] <SWPadnos> even without a mouse I bet
[01:55:23] <cradek> menu menu menu
[01:55:36] <jmkasunich> the home button is home all, lemme look at the menues that I never normally see
[01:55:59] <jmkasunich> cradek to the rescue
[01:56:03] <SWPadnos> heh
[01:56:03] <jmkasunich> (thanks)
[01:57:04] <cradek> SWPadnos: maybe homing both encoders is going to be the hard part
[01:57:49] <jmkasunich> sometimes I'm an idiot
[01:58:04] <jmkasunich> I started running the program again - corrected on disk, but not reloaded
[01:58:12] <jmkasunich> realized it before it crashed again tho
[01:58:25] <skunkworks> heh
[01:59:43] <SWPadnos> cradek, hmmm - could be. especially if they both have index marks
[01:59:49] <SWPadnos> we'd just have to pick one as the master
[02:00:31] <SWPadnos> actually, if they both have quadrature output, then you just run the index from one of the encoders to the index input of both encoder counters
[02:00:50] <SWPadnos> so they both reset at the same time (though there could still be one count or so of gating error)
[02:00:54] <cradek> true
[02:01:33] <skunkworks> you guys going to play with the 5 axis machine also?
[02:01:48] <skunkworks> viper?
[02:02:04] <SWPadnos> what might be "interesting" would be watching one encoder change, but not the other, as the table moves from thermal expansion
[02:02:33] <SWPadnos> though there may be no indication of that if the scale is matched to the expansion coefficient of steel
[02:02:47] <SWPadnos> (or iron)
[02:06:41] <skunkworks> driving home. Have a good trip you guys.
[02:06:51] <SWPadnos> thanks - drive safely
[02:08:03] <jmkasunich> that was fun - rough turn and face, drill, bore, ream, finish turn and face, part off
[02:08:06] <jmkasunich> one program
[02:08:16] <SWPadnos> the joys of CNC :)
[02:08:21] <jmkasunich> now I run it one more time, then do another (differnt) part
[02:11:51] <seb_kuzminsky> thanks jmk i'll check
[02:15:18] <seb_kuzminsky> jmkasunich: sorry to hear about your divorce... hopefully things are better now
[02:16:21] <seb_kuzminsky> about epp vs pci: yes they're very different, in bandwidth, latency, and addressing mechanism
[02:16:34] <seb_kuzminsky> but i'm still holding out hope that the i/o differences can be hidden behind clean interfaces
[02:17:08] <seb_kuzminsky> that allow efficient, dma-based io over pci, and the dog-slow annoying transfers you have to do over epp
[02:17:09] <SWPadnos> it's more a question of whether we can keep the performance and flexibility of PCI while we also have the ability to hide the possibility of a device being on EPP
[02:17:19] <SWPadnos> you can DMA from EPP as well ;)
[02:17:25] <SWPadnos> but it's still dog slow
[02:17:30] <seb_kuzminsky> from ecp, but not from epp (iirc)
[02:17:31] <jmkasunich> 2nd run done, looks like about 9 mins per part
[02:17:33] <SWPadnos> or at least over ECP
[02:18:20] <seb_kuzminsky> here's what i'm thinking: split the code into a "interface the firmware to HAL" part and a "talk to the hardware" part
[02:18:38] <seb_kuzminsky> the first part has an internal representation of what it wants to communicate to the firmware
[02:19:14] <seb_kuzminsky> the "firmware" part tells the "io" part things like: read encoders count registers
[02:19:40] <seb_kuzminsky> the "io" part does the appropriate I/O and updates the values in the struct shared with the "firmware" part
[02:20:15] <SWPadnos> jmkasunich pointed out a couple of places where that separation may not be ideal - consider a register that resets something whenever it's read (or written)
[02:20:18] <seb_kuzminsky> there would be a little API between them, and different i/o drivers would implement the same functions, but with totally different behaviods internally
[02:20:31] <seb_kuzminsky> brb, gotta go read bedtime stories...
[02:20:45] <SWPadnos> the "consumer code" would need to strictly control when those reads/writes occur
[02:20:47] <SWPadnos> heh
[02:51:16] <seb_kuzminsky> swpadnos: i agree the "consumer code" needs to control when the i/o happens, but isn't that easily accomplished with a synchronous api?
[02:51:42] <seb_kuzminsky> the consumer code (aka firmware driver) would make function calls into the io code, which would do the io, update the shared structures, and return
[02:51:43] <SWPadnos> yes, but you really don't want EPP to be synchronous - that implies an address cycle for every transfer
[02:52:15] <SWPadnos> EPP should be buffered most of the time, PCI doesn't need to be (but it is useful on some chipsets, as I found out the hard way)
[02:53:04] <seb_kuzminsky> one EPP address write cycle for each firmware function, then N data read (or write) EPP cycles to do the transfer (using address autoincrement)
[02:53:42] <seb_kuzminsky> how would an asynchronous epp interface work? run the io in a different thread?
[02:53:59] <SWPadnos> well, I used the word synchronous when I meant something else ;)
[02:54:07] <SWPadnos> buffered, most likely
[02:54:27] <seb_kuzminsky> hm, i still dont understand what you mean by buffered epp
[02:55:02] <seb_kuzminsky> afaik epp is byte-at-a-time (or u32-at-a-time if you're lucky) with no fifo or dma or buffering anywhere
[02:55:21] <seb_kuzminsky> ecp does those things, but no motion control hardware I know of implements ecp
[02:55:47] <seb_kuzminsky> maybe the firmware could be rewritten to do ecp... hmmm
[02:56:15] <seb_kuzminsky> but anyway, i think epp is plenty fast! it's no PCI, but with the 7i43 I can do 4-channel, 4 KHz servo control, with
[02:56:24] <seb_kuzminsky> a nice margin in the timing
[02:58:32] <SWPadnos> seb_kuzminsky, look at the USC driver
[02:58:50] <SWPadnos> there's a single read command and a single write command
[02:59:01] <SWPadnos> err - function
[02:59:25] <SWPadnos> each of those functions reads/writes a set of addresses to/from a RAM buffer
[02:59:35] <SWPadnos> the RAM buffer mirrors the register set on the USC
[03:00:05] <SWPadnos> the list of registers to transfer is set by the "consumer" functions (HAL functions)
[03:00:29] <SWPadnos> each says "I need this set of registers", and the buffering code extends the list as necessary
[03:01:00] <SWPadnos> I'm not sure if we ever added the optimization where a small gap is read anyway, but a larger gap is skipped with a new address cycle
[03:01:23] <SWPadnos> so the consumer code uses a set of RAM locations that mirror the USC registers
[03:02:03] <seb_kuzminsky> yes, that sounds perfect
[03:02:10] <SWPadnos> that's the problem ;)
[03:02:38] <SWPadnos> with some functions, you may want to read/write a specific register at a specific time, so you still need a "direct access" mode
[03:02:51] <SWPadnos> I think we can do it, but jmk's point is something to be taken into accound
[03:02:53] <SWPadnos> account
[03:03:26] <seb_kuzminsky> you and jmk have way more experience in this area than me, i appreciate your advice on this
[03:03:47] <SWPadnos> it always helps to have several (dozen) points of view :)
[03:03:50] <seb_kuzminsky> i'm trying to understand what's wrong with how I'm thinking of it
[03:04:44] <seb_kuzminsky> i see the register bitmap in the read_all() function, is that sort of what you're trying to get away from in PCI-land?
[03:05:02] <SWPadnos> not looking it as a PCI thing - more of a functionality thing
[03:05:06] <seb_kuzminsky> you dont want to have to wait to read the earlier registers in the bitmap before you get to the one timing-critical register you care about now?
[03:05:21] <SWPadnos> the consumer code needs to be able to access data (easy using a buffer)
[03:05:29] <seb_kuzminsky> i agree
[03:05:33] <SWPadnos> it also needs to be able to access registers directly for other reasons
[03:05:39] <seb_kuzminsky> what i'm thinking is this:
[03:05:40] <SWPadnos> synchronization was one of those
[03:06:00] <SWPadnos> (write a register to tell the FPGA to load all velocity settings, for example)
[03:06:33] <seb_kuzminsky> each function that the firmware exports (and that the consumer code wants to use) gets its own read() and write() functions (if applicable)
[03:06:42] <seb_kuzminsky> the consumer code then calls those when appropriate
[03:07:02] <seb_kuzminsky> those functions get stuff out of the ram buffer and send it to the device over whatever communication medium it uses
[03:07:23] <seb_kuzminsky> the consumer code thus gets to say things like pwmgen.write() or encoder.read()
[03:07:46] <seb_kuzminsky> makes for reasonably low latency between when the consumer code wants something to happen and when it happens
[03:08:11] <seb_kuzminsky> while still letting the api hide funny i/o behaviors behind a clean interface
[03:08:43] <SWPadnos> as long as the API also allows direct access (on PCI at least, it could be disabled on the EPP bus), then it can work
[03:09:07] <SWPadnos> unless the assumption is that the reads and writes just happen when the function is called, regardless of the inefficiency of EPP
[03:09:36] <seb_kuzminsky> well, as fast as possible, as fast as the i/o driver can make it happen given the limitations of the io medium
[03:09:39] <seb_kuzminsky> fast on pci, slower on epp
[03:09:49] <seb_kuzminsky> the i/o driver doesnt have anything else to do, just io
[03:09:57] <seb_kuzminsky> all the smarts is in the consumer code
[03:10:34] <seb_kuzminsky> when the crazy ethercat drivers come online all it is is a new io driver
[03:11:25] <seb_kuzminsky> so far you mentioned latency between i/o request and the actual transfer, and "synchronization"
[03:11:37] <seb_kuzminsky> i think i understand the first one and i think it's not a problem if the api is designed right
[03:11:53] <seb_kuzminsky> i dont understand the synchronization issue
[03:12:54] <SWPadnos> I don't think latency is an issue - it's the CPU cycles that get burned doing EPP transfers including address cycles
[03:15:01] <SWPadnos> there may be cases when you want to start some things going at a specific time
[03:15:32] <SWPadnos> like you cycle-count or use the TSC for timing something, then write to a register to get the FPGA to "start"
[03:16:11] <SWPadnos> that will work only if you can literally end your timing loop and outb / mov the data to the FPGA in the next couple of instructions
[03:16:35] <seb_kuzminsky> that sounds like a cause/effect latency issue, which i think is totally doable in an i/o agnostic interface
[03:16:50] <SWPadnos> (that's an illustrative example only)
[03:17:16] <SWPadnos> no, on EPP, writing a 32-bit register takes as much as 7 microseconds - 3 for the address cycles and 4 for the 32 bits
[03:17:29] <SWPadnos> (probably less, like 3.5 us, but still a lot)
[03:17:31] <seb_kuzminsky> you do some big(-ish) transfers to prime the fpga, then do your cycle-counting busy-wait loop until the golden moment, then call the api-function that sends the "go" command within a handful of instructions
[03:17:44] <SWPadnos> with PCI, it could be 0.3 us
[03:18:07] <seb_kuzminsky> you could do the address cycles before the wait
[03:18:27] <seb_kuzminsky> but in any case, this is simply a limitation of epp, not something that can be fixed in software
[03:19:02] <seb_kuzminsky> the pci i/o driver will still be running at bus speed
[03:19:20] <SWPadnos> I guess the idea is that the slug that is EPP shouldn't burden the eagle that is PCI ;)
[03:19:37] <SWPadnos> just so there's a common (least common denominator) interface
[03:19:46] <seb_kuzminsky> i would agree, if i could understand how pci is burdened by this :-)
[03:19:57] <SWPadnos> it's not PCI, it's the API
[03:20:17] <seb_kuzminsky> the api is too slow for pci?
[03:20:38] <SWPadnos> if all drivers have to use an API that's not something like pci_addr->MyRegister = 100, then there's a burden placed on the driver just for compatibility with EPP devices
[03:20:39] <seb_kuzminsky> if you limit the scope of the driver to pci, then you dont need the api and it feels unnecessary
[03:25:07] <maddash> hm, should the HOME_TAINTS_EASILY ini option be categorized with the rest of HOME_IGNORE_LIMITS, HOME_IS_SHARED, etc?
[03:25:31] <SWPadnos> it should probably be per joint like those
[03:26:29] <seb_kuzminsky> swpadnos: i'm thinking something like write_MyRegister(device_t *dev, u32 val)
[03:27:13] <SWPadnos> I had considered something with a function pointer, where the read/write functions are called like busStruct->write(addr,value)
[03:27:28] <SWPadnos> ahd the write function can be different for the various buses, buffered/nonbuffered, etc.
[03:28:51] <seb_kuzminsky> where device_t can hold a PCI device and the function is implemented as the code you gave, or an EPP device and it's an outl
[03:29:01] <seb_kuzminsky> or a code pointer in the device_t, sure
[03:29:42] <SWPadnos> it still adds inefficiency, but since it 's cycles at ns scales doign I/O at us scale, it probably doesn't matter
[03:30:55] <seb_kuzminsky> it's an axiom of computer science: all problems can be solved by adding a level of indirection, except inefficiency :-)
[03:31:02] <SWPadnos> heh
[03:31:12] <SWPadnos> actually, I need to run - I've got an early flight tomorrow
[03:31:22] <SWPadnos> we'll be able to continue this weekend though, if you're abvailable
[03:31:39] <seb_kuzminsky> ok, have fun
[03:31:50] <seb_kuzminsky> are you going to cabin fever?
[03:32:07] <SWPadnos> no, Wichita ;)
[03:32:09] <maddash> SWPadnos: vegas?
[03:32:15] <SWPadnos> no, was just there
[03:32:20] <maddash> I know
[03:32:44] <SWPadnos> heh - don't need to go back for a couple of months ;)
[12:22:36] <cradek_> cradek_ is now known as cradek
[17:33:28] <skunkworks> johns site is down.
[19:46:18] <fenn> from mdi tab, ctrl-+ and ctrl-- start a jog but then it keeps going
[20:32:56] <alex_joni> oopsy..
[20:33:02] <alex_joni> that falls under the category don't do it
[20:33:08] <alex_joni> fenn: is that AXIS?
[20:33:28] <fenn> yes
[20:33:34] <alex_joni> 2.2.x ? or TRUNK?
[20:33:55] <fenn> pre-2.3 from some date
[20:34:02] <fenn> i can recompile and see if it's still there
[20:35:34] <alex_joni> I doubt it makes a difference, but that would be nice