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