OT but .... I'm running 8.04 rt as my standard desktop, .... just tried a c compile and all the incudes seem to be missing
no math libs etc. as far as I can tell
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/stepconf.lyx: add note about lathe tool table
do I need to apt-get some more stuff
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ (docs.xml index.tmpl): add linux faq to html
hi dave_1 normal EMC questions should be asked in #emc not #emc-devel which is a place to discuss development stuff
did you do a live cd install?
yep ... off linuxcnc site
I would have used a non-rt but none of them would boot off the CD .. just hung on the ram-disk install
the livecd should install without any other things needed
I'm pretty sure I have no idea what you said :O
did you boot from the LiveCD?
I would think so but then what is the path to ....include/math.h etc. even stdlib.h and stdio.h are missing
Boot from live CD then install ....
did you read the Getting Started Guide?
me read??? guess I should do that
that is the place to start :)
did check the help stuff and that was no help at all
what "help stuff"?
the search for help .. pretty shallow
you must mean the Ubuntu help...
be back after I learn to read ...
start here > http://www.linuxcnc.org/docs/EMC2_Getting_Started.pdf
* BigJohnT heads up where it is warm
I don't see anything wrong with stepconf's charge pump configuration
(but I don't have realtime to really test it right now)
I know using estop-in has some suckage but I can't remember the details
on mine it ended up hooked to user-neable-out
net estop-out charge-pump.enable iocontrol.0.user-enable-out
I can't see what would make it not work
EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/serial_linux.c: preliminary work for adding options to the way the serial port is set up eg length of data bits, parity. right now 8 N 1 is still hard coded
next day of implementing tool changer...
now current tool number isn't stored to var file ?
ok I'm on new machine
first thing: table is from -1 to 1600
when I'm on -1 and F2 then two Exceed soft limits error I have
joint-pos fb is 1.0007
that is outside the limits.. yes
what is precision of that check ?
about 24 decimals or so
hm I have striaght x move, have F500, vel is show 500 but axis.0.joint-vel-cmd is 417.2
ddt also show 417
what's your max vel?
also FO and AF?
max vel 4800
fo = 0
sorry fo = af =1
[traj]max_vel = 4800
what is [AXIS_0] max_vel ?
[axis_0] max_vel = 4080
micgesEMC: seems ok
try to print some debug messages and see what the feedrate is that reaches motion
Issuing EMC_TRAJ_LINEAR_MOVE -- (+220,+116, +0,384.178500,270.805300,57.464000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000, +2,8.333333,68.000000,260.000000, +0,)
Outgoing motion id is 112.
vel sended is 8.33*60 = 499,8 and its ok
changing [AXIS_0]max_vel doesn't change that vel, it's still 417 for commanded 500
micgesEMC: echo 5 > /proc/rtapi/debug
and look in dmesg for the speed received by the motion controller
there is no info about speed
only like this:[113470.412780] 3049955: CMD 774, code 29 SET_LINE
hmm.. then maybe wait for cradek if he has other ideas
thanks for help, beside this machine works great
micgesEMC: you know, for simply talking about setting up emc, the #emc channel is more appropriate
KimK is now known as KimK_afk
EMC: 03seb 07TRUNK * 10emc2/src/emc/usr_intf/emcrsh.cc:
EMC: check the return value of read()
EMC: This fixes a bug, but probably not the one that bit Eric Johnson.
seb_kuzminsky: can I currently use e.g., qcount 1-4,7 (and not 5,6)? just thinking about how the direction of those is not the same as the isolated I/O card...
I think that 7 matches up to "I" pins on the isolated I/O card but 5,6 don't (I'm not 100% sure of that though)
I don't think you can choose which ones to use, only the quantity
it may be possible to disable some though, and then use those I/Os (though the pin directions will be set by the encoder or other function that connects to them)
that's all AFAIK though
and that's not always much
well, it's often a lot, but not very valuable ;)
although, I must admit
you get lucky
coo coo cachoo?
goo goo g'joob
I think I liked PeterDumbassW better :)
* alex_joni likes PeterWalrus
well, it's good too
I thought I wore that one out
PeterWalrus, jmkasunich: where's the spec2bit project at? is there some way I can help at this point?
I think it sort of works, but the approach I took isn't compatible with the GUI
peter suggested some other ideas, but they are mostly built around the VHDL - the python part (the part I can do) is relatively minor and can't be done till the vhdl dust settles
or at least, that's where I think it stands
PeterWalrus: is that how you see it too?
What I would like to do before this gets too far is:
1. Split all the pinout/moduleID pairs into individual fiiles
2. make a per card top level (5i23hotmot2,5i20hostmot2 etc etc)
Just to avoid requiring all the substitutions
Once this was done, the pinout association would be done in the .PRJ file
by including the appropriate pinout/moduleID file
can .PRJ files be modified relatively easily by command-line tools
either ones provided by Xilinx or ones that we write
Its just a list of files
yes, right now spec2bit writes a prj file itself
PeterWalrus: so you can list a ucf file in a prj file, for instance?
the .prj files I've been generating only list .vhd files
the .ucf is passed to a somewhat later tool in the chain, on the command line
Rigth, the UCF files are used later by map
I don't know if there are GUI specific .prj files that have different stuff in them?
or is there some other "project" file that the GUI uses?
the tcl import script I looked at seemed to have a bunch of stuff other than a list of files
I dont know is really screwed up now the project file a binary mess
even the old tcl files (which apparently 10.whatever can't import) had lots o' crap in them
I would just like to clean up the VHDL, so it doesn't need as much massaging to autobuild
ok, so we have some binary mess that the GUI uses, some weird tcl script provided by xilinx that supposedly can extract some bits of that file
and we also have the list of stuff that we actually need
which is, all the neccessary vhd files, a device name, a ucf file, and some bitgen options
Thats right the actual required data is not that big
and if I understand correctly, we want to build different things by mostly altering that "list of all the neccessary vhd files"
the device name, the ucf file, and the bitgen options are all board specific, so for command line builds, they could be embedded in the board specific vhdl file as comments, and extracted by the python tool, then passed to the appropriate stages of the process automatically
got GUI builds, they probably need to be selected from some menu or something
Yes that would work with no mode for GUI or command line biulds
I was thinking of just changing the pindesc and module ID names to generic names in each file
Yes for GUI they are "properties"
s/got/for (weird typos there)
(no changes) What the heck did I type?
"got GUI builds" -> "for GUI builds"
anyway, we'd wind up with maybe 20 .vhd files that all define the same two entities - the generic pindesc and moduleID ones
Yes, that was my thought
and the .prj would tell the toolchain which one to use, right?
So I have some work to clean this up before anyone spends more time on it
one step of that will be splitting the big IDParms.vhd
jepler has done that (at least twice), I dunno if the second one with records is what you want, or if it wants to be reformated somewhat
if it does, it probalby makes sense to modify the splitter program and do the split again, instead of editing the individual files
I hate to even look at that file its got so many phase errors
Well improvements that are only partially implemented
that is a much nicer way to say it ;-)
(like constants for pin functions and moduleID revs instead of bare numbers)
(some pindescs have them some dont)
ah - I had noticed that you have constants defined, but use numbers a lot
Started with numbers...
to be honest, what drives me nuts about that file (and many others) is that the lines are so damned long
Well if I had a VHDL pretty-printer I could reformat it but the big concatenations that try to align fields
are pretty wide.
Maybe they would be better formatted with one field per line (especially if they were only one moduleID/Pindesc
pair per file
I think what makes them really wide is the GUI's three-space tabs
they become 8 spaces here
and then things don't line up
gotta go, I'll read back later
Yes thats a problem
I could put them through EMACSs VHDL mode reformat
if needed but its a fair amount of work
jmkasunich: it seems very likely that there's a way to teach your editor to default to 3-space tabs in .vhd files
"if you can't beat 'em, join 'em"
Jepler: I had a question about timing:
For some (SPI Serial SSI Ethernet etc) interfaces
read-ahead seems like a good thing
By this I mean do a read request in hardware before the data is required
So say you have a servo thread of 1 ms and reading remote encoders takes 200 uSec
the hardware would issue the read request ~800 usec from the last
servo thread access so the data would be available when the servo thread needs access
Has this ever been tried? I remember reading somewhere in
EMC suggested hardware designs philosophy or some such that read-ahead was
it seems fine to me if the hardware does 'stuff' to 'get ready' for the upcoming read
read-ahead as in queueing of commands or feedback is undesirable
it would be fine, but the time delay would need to be settable, and needs to be based on not only the data transfer duration, but also latency
(assuming that there's no flag that tells the software that new data is ready)
PeterWalrus: the "externally initiated reads" I was referring to are when the external device is on a free-running clock
PeterWalrus: if it's got some method to stay synced to the HAL thread invocations I think it'll go fine
OK I was no talking about queing, just avoiding having to use the base thread or some other scheme
so that you would not have to wait for returned data
For timing simplest would just be a delay from last access, More complicated would be a DPLL
synced to the servo thread
that page ranges from overgeneralization to speaking about things as though I understood more than I do :-P
generally its hard to talk about things in general :-)
OK, Im worjking on the "autosend" part of my buffered SPI interface, Ill add the ability to start autosend from a timer
I mostly wanted a document to point at for people-who-aren't-even-users-but-want-to-develop-a-usb-interface-for-some-reason
while you have the chops to actually try this stuff out and determine for yourself whether it's reliable and whether it improves things
I think that there are probably some things you can do to reduce jitter in the fpga, without increasing phase shift much. overall that could sure improve things
For example one our 7I65 analog servo interface, you may have as many as 8 analog inputs which are all read via SPI
Might take 50 or to finish reading all channels, migh as well have the pre-read
Yikes! what terrible typing
analog inputs on mesa hardware would be a breakthrough
I'm wondering how long "all other reads" take -- if "start reading spi now", then the rest of the reads, then the servo analog reads, would take up that 50uS
a few people use motenc now because of that - like for edm current feedback
Yes One way to do this is to have a 32 bit or so DPLL thats phase locked to the servo thread
and has a series of comparators to get hardware actions at any desired place in the cycle
what if the DPLL is late compared to emc requesting a read -- will emc read data that's one cycle old?
Jepler: That may be ok as a start Ive also been thinking about whats required to
support a fast serial interface that may take 200 usec or so to respond
is servo position feedback also coming from this spi source?
Late? I think only maximum latency need be accommodated, you can also read the FIFO status to see if enough data is available
well, what if emc is early
On the 7I65 , no its direct, but for thing like SSI (say Austria micro absolute magnetic encoders) theres a delay
perfect intervals on the pc would be 1000us 1000us 1000us; but jitter might make it 1200us 800us 1200us 800us (if you have 200/400us jitter; we're never consistent about how we describe it)
Can EMC be early? If so it would have to wait for the data
(hopefully your jitter isn't that big compared to the servo cycle, of course)
Sure, jitter needs to be in the timing setup, but since the main point of this is efficiency, having to wait occasionally
* jepler hopes the 2nd CD he writes will work
is a minor cost.
yeah, I can see that
having the ability to wait seems like an increase in driver complexity, but with seb_kuzminsky on the job I'm sure that's tractable
off to try again to install linux on this new machine -- first boot cd burn was bad
grr, second disc doesn't even spin up!
not my night :(
I thought it's only night over here
Uh oh Bad blanks?
hopefully not bad drive ;)
PeterWalrus: I'm afraid they are
the prospect of going to an electronics store between now and christmas chills me to the core
That _is_ a scary thought