btw, jepler / cradek - feature request for axis
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)
in lathe mode, if I get the zoom or pan off in left field, there is no easy recovery
can you put a "restore default view" button up where the mill predefined view buttons are?
jmkasunich: hit "v"
but yeah, it should have an icon so it's discoverable
jmkasunich, I think the idea might be to "DMA" all the data into memory, regardless of which type of device it's coming from
then the driver code deals with memory structures rather than many PCI reads
(or EPP reads)
whether it's DMA or not is immaterial, the code would do a block transfer of whatever data is needed
DMA adds a constraint for the VHDL designer
all registers must only be written once
what if I want to design VHDL and a matching driver that needs to write multiple things per one iteration of the driver code
or even conditional writes, etc
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
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
I'm not thinking of doing that kind of stuff so much
more a matter of things like syncing
I can understand conditional writes though - somethng like a reset register or something
IMO the difference between PCI and EPP isn't just quantitative (bandwidth), its qualitative
I guess I was looking at it like the USC (which is EPP of course)
you design things differently, and you code differnetly, when you aren't breathing through a straw
the low level code reads in a block of data and writes out a block of data
it doesn't matter how that data gets moved, or over which bus
and the USC is constrained by that limitation
you simple can't do some things
incidentally, if I'm keeping you from some machining, we can talk about it at the hotel tomorrow :)
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"
(I'm going back and forth because I edit the g-code here with a nice kb and screen, then run it there)
sure, I wouldn't want to limit the possibilities of a PCI card with the architecture
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
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()
for EPP the address is a memory buffer and the function is fake_EPP_write()
cradek: hitting v makes that letter appear in the MDI box
seb_kuzminsky: I commented a bit on your discussion with SWP earlier - take a look at the log
we'll talk more later - I have to pack for tomorrow morning now :)
when does your flight leave?
me too, after I make these parts
weird - is it not a direct flight?
might be 8:50ish
oh right - you arrive a couple of hours earlier
in a different town
it sounded strange because my flight leaves at 8:20 and I arrive (via Chicago) at 2:15 - about the same time as you
I just forgot about the car trip in there ;)
jmkasunich: in f3 tab
yeah, I found that out
inconvenient when I'm in F5 tab
the buttons always work in mill mode
anyone have any suggestions on stuff to bring (other than proper attire)?
I was gonna ask several questions, but I really should shut up now
a devel environment
yeah - got that on the laptop (sim only though)
are either of you going to be up late tonight (11pm eastern or so)
I'll be up taht late I'm sure
I probably will, but barely
I want to talk about the trip, but I simply MUST make these parts, and drop them off
ok. I'll wait around a bit to be sure we can discuss it
if I'm not around, I'll read in the morning
if necessary ;)
I could actually bring one of these little embedded computers in a carry-on suitcase
with a 5i22 in it
some of my q's are things like "how cold is it in the shop" which will affect the packing I do tonight
tomorrow is a bit late for that
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
it was tolerable but I don't recall what month I was there
there was a wide variation in temp
I thought it was in summer - within a few months of CNC workshop
take layers I guess
it was rainy and I think cold
no, rainy and hot
forget it, this is pointless
so hot and muggy
yes and some areas were cooled, some not
I bet our setup will be in a comfortable room, but the G&L will be cold
a few of you guys are going to stuarts shop?
that sounds interesting... Going to play with scales + encoders?
yes that's one of the goals
but no steppers!
Neat (that is something - someday) that We would like to try.
hmmm. does anyone know if those scales are absolute?
all this farting around, and a typo made me hit the work and lose steps (and thus my carefully achieved touch-off)
actually, its X that lost it, and I can home X
unfortunately, I only have a home-all button
jog it to a known position..
and if I do that, I lose my Z touch off (no home switch on Z)
if you have a mouse, can't you select an axis and hit the home key?
jmkasunich: use the menu
even without a mouse I bet
menu menu menu
the home button is home all, lemme look at the menues that I never normally see
cradek to the rescue
SWPadnos: maybe homing both encoders is going to be the hard part
sometimes I'm an idiot
I started running the program again - corrected on disk, but not reloaded
realized it before it crashed again tho
cradek, hmmm - could be. especially if they both have index marks
we'd just have to pick one as the master
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
so they both reset at the same time (though there could still be one count or so of gating error)
you guys going to play with the 5 axis machine also?
what might be "interesting" would be watching one encoder change, but not the other, as the table moves from thermal expansion
though there may be no indication of that if the scale is matched to the expansion coefficient of steel
driving home. Have a good trip you guys.
thanks - drive safely
that was fun - rough turn and face, drill, bore, ream, finish turn and face, part off
the joys of CNC :)
now I run it one more time, then do another (differnt) part
thanks jmk i'll check
jmkasunich: sorry to hear about your divorce... hopefully things are better now
about epp vs pci: yes they're very different, in bandwidth, latency, and addressing mechanism
but i'm still holding out hope that the i/o differences can be hidden behind clean interfaces
that allow efficient, dma-based io over pci, and the dog-slow annoying transfers you have to do over epp
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
you can DMA from EPP as well ;)
but it's still dog slow
from ecp, but not from epp (iirc)
2nd run done, looks like about 9 mins per part
or at least over ECP
here's what i'm thinking: split the code into a "interface the firmware to HAL" part and a "talk to the hardware" part
the first part has an internal representation of what it wants to communicate to the firmware
the "firmware" part tells the "io" part things like: read encoders count registers
the "io" part does the appropriate I/O and updates the values in the struct shared with the "firmware" part
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)
there would be a little API between them, and different i/o drivers would implement the same functions, but with totally different behaviods internally
brb, gotta go read bedtime stories...
the "consumer code" would need to strictly control when those reads/writes occur
swpadnos: i agree the "consumer code" needs to control when the i/o happens, but isn't that easily accomplished with a synchronous api?
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
yes, but you really don't want EPP to be synchronous - that implies an address cycle for every transfer
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)
one EPP address write cycle for each firmware function, then N data read (or write) EPP cycles to do the transfer (using address autoincrement)
how would an asynchronous epp interface work? run the io in a different thread?
well, I used the word synchronous when I meant something else ;)
buffered, most likely
hm, i still dont understand what you mean by buffered epp
afaik epp is byte-at-a-time (or u32-at-a-time if you're lucky) with no fifo or dma or buffering anywhere
ecp does those things, but no motion control hardware I know of implements ecp
maybe the firmware could be rewritten to do ecp... hmmm
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
a nice margin in the timing
seb_kuzminsky, look at the USC driver
there's a single read command and a single write command
err - function
each of those functions reads/writes a set of addresses to/from a RAM buffer
the RAM buffer mirrors the register set on the USC
the list of registers to transfer is set by the "consumer" functions (HAL functions)
each says "I need this set of registers", and the buffering code extends the list as necessary
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
so the consumer code uses a set of RAM locations that mirror the USC registers
yes, that sounds perfect
that's the problem ;)
with some functions, you may want to read/write a specific register at a specific time, so you still need a "direct access" mode
I think we can do it, but jmk's point is something to be taken into accound
you and jmk have way more experience in this area than me, i appreciate your advice on this
it always helps to have several (dozen) points of view :)
i'm trying to understand what's wrong with how I'm thinking of it
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?
not looking it as a PCI thing - more of a functionality thing
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?
the consumer code needs to be able to access data (easy using a buffer)
it also needs to be able to access registers directly for other reasons
what i'm thinking is this:
synchronization was one of those
(write a register to tell the FPGA to load all velocity settings, for example)
each function that the firmware exports (and that the consumer code wants to use) gets its own read() and write() functions (if applicable)
the consumer code then calls those when appropriate
those functions get stuff out of the ram buffer and send it to the device over whatever communication medium it uses
the consumer code thus gets to say things like pwmgen.write() or encoder.read()
makes for reasonably low latency between when the consumer code wants something to happen and when it happens
while still letting the api hide funny i/o behaviors behind a clean interface
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
unless the assumption is that the reads and writes just happen when the function is called, regardless of the inefficiency of EPP
well, as fast as possible, as fast as the i/o driver can make it happen given the limitations of the io medium
fast on pci, slower on epp
the i/o driver doesnt have anything else to do, just io
all the smarts is in the consumer code
when the crazy ethercat drivers come online all it is is a new io driver
so far you mentioned latency between i/o request and the actual transfer, and "synchronization"
i think i understand the first one and i think it's not a problem if the api is designed right
i dont understand the synchronization issue
I don't think latency is an issue - it's the CPU cycles that get burned doing EPP transfers including address cycles
there may be cases when you want to start some things going at a specific time
like you cycle-count or use the TSC for timing something, then write to a register to get the FPGA to "start"
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
that sounds like a cause/effect latency issue, which i think is totally doable in an i/o agnostic interface
(that's an illustrative example only)
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
(probably less, like 3.5 us, but still a lot)
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
with PCI, it could be 0.3 us
you could do the address cycles before the wait
but in any case, this is simply a limitation of epp, not something that can be fixed in software
the pci i/o driver will still be running at bus speed
I guess the idea is that the slug that is EPP shouldn't burden the eagle that is PCI ;)
just so there's a common (least common denominator) interface
i would agree, if i could understand how pci is burdened by this :-)
it's not PCI, it's the API
the api is too slow for pci?
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
if you limit the scope of the driver to pci, then you dont need the api and it feels unnecessary
hm, should the HOME_TAINTS_EASILY ini option be categorized with the rest of HOME_IGNORE_LIMITS, HOME_IS_SHARED, etc?
it should probably be per joint like those
swpadnos: i'm thinking something like write_MyRegister(device_t *dev, u32 val)
I had considered something with a function pointer, where the read/write functions are called like busStruct->write(addr,value)
ahd the write function can be different for the various buses, buffered/nonbuffered, etc.
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
or a code pointer in the device_t, sure
it still adds inefficiency, but since it 's cycles at ns scales doign I/O at us scale, it probably doesn't matter
it's an axiom of computer science: all problems can be solved by adding a level of indirection, except inefficiency :-)
actually, I need to run - I've got an early flight tomorrow
we'll be able to continue this weekend though, if you're abvailable
ok, have fun
are you going to cabin fever?
no, Wichita ;)
no, was just there
heh - don't need to go back for a couple of months ;)
cradek_ is now known as cradek
johns site is down.
from mdi tab, ctrl-+ and ctrl-- start a jog but then it keeps going
that falls under the category don't do it
fenn: is that AXIS?
2.2.x ? or TRUNK?
pre-2.3 from some date
i can recompile and see if it's still there
I doubt it makes a difference, but that would be nice