Back
[00:11:23] <SWPadnos> mozmck, yes, you need to blend even tangent arcs. Imagine two arcs that form an S curve - still tangent, but the accel on one axis has to completely reverse
[00:21:16] <mozmck> SWPadnos: yes, but the accel is constantly changing on an arc anyhow isn't it?
[00:21:38] <SWPadnos> sure
[00:31:25] <cradek> blending the paths and transitioning from one segment to the next without stopping are currently both side effects of the same algorithm
[00:31:57] <cradek> it's true that with tangency you could transition without blending the path, if the planner knew how to do that
[00:32:45] <cradek> what SWPadnos says about accel changing direction is true but not important unless you want to limit jerk (which we don't do currently)
[00:35:14] <mozmck> I see. (something through the fog I think :) )
[02:54:51] <mozmck> in HAL do components pins get updated in the order they are added to the thread?
[03:30:01] <cradek> they are executed in thread order - yes - but you can specify an order when you add them, so if being pedantic the answer to your question is no
[03:30:13] <cradek> I think halcmd show thread will show the resulting order
[13:52:18] <SWPadnos> mozmck, HAL pins read/written by a single function may update in any order, but the order the functions execute is specified by how they're added to the thread
[13:53:18] <SWPadnos> the "within a function" order is irrelevant for pins that are used in the same thread as the function that changes them, but could be important if there are pins that are also used in a faster thread since the faster thread may "see" a partial update
[13:55:19] <mozmck> Thanks for the information. We have a muxed input circuit we are playing with and it's not working. 99% sure it's hardware timing issues...
[13:58:25] <SWPadnos> just stick the input bytes on an S32 for debugging
[13:58:40] <SWPadnos> that would eliminate any number -> pin conversion or pin update issues
[13:58:51] <SWPadnos> err, number -> array of pins
[13:59:43] <mozmck> hmm, hadn't thought of that. my problem is that the pin numbers are coming in at the wrong places.
[14:00:14] <SWPadnos> ?
[14:00:50] <SWPadnos> signals on physical pins aren't showing up where you expect them?
[14:02:46] <mozmck> no, they are in the wrong place in the internal array, most likely because of timing issues between the control lines, optos, and input pins.
[14:03:11] <SWPadnos> ok
[14:03:55] <SWPadnos> so you output some bit pattern on the control port to select the address, then read the data port to get the input data (or similar)?
[14:05:11] <mozmck> similar. 4 inputs from the parport, two control lines which switch between 4 banks of physical inputs
[14:05:52] <mozmck> actually, 2 banks of 2 banks each if that makes sense.
[14:06:03] <SWPadnos> you might try sticking a phantom write in there - write the control port twice, or write to a different port
[14:06:05] <SWPadnos> ok
[14:06:24] <CIA-2> EMC: 03jthornton 07v2.4_branch * r0074a4789679 10/docs/src/gcode/ (4 files in 2 dirs): add a bit more to the g76 section and markup fixes
[14:07:33] <SWPadnos> you've got to assume that (1) the parport pins actually update near the end of the 1us output cycle (and of course that the input cycle reads at the beginning ...), and (b) that the output timing is not symmetric - that is that going 0->1 may take a different amount of time than 1->0
[14:08:06] <SWPadnos> so when you output then input immediately, my assumption would be that there's no significant time between those events
[14:15:50] <SWPadnos> oh, the other idea is to only do one read per base thread - you read first, then output the next mux configuration. That way, the electronics have a full base period to settle, since you'll read the next bank several microseconds later
[14:16:07] <SWPadnos> (that's better when you have fewer banks)
[14:16:33] <mozmck> 1us? My base period isn't that fast!
[14:16:47] <SWPadnos> several microseconds :)
[14:17:30] <SWPadnos> it depends on the hardware though, if there's a latch involved, you don't want to use the multi-period approach
[14:18:20] <mozmck> That's why I asked about update order on a thread. if the components get updated in the order that they are added to the thread, then the parport inputs get updated before my code runs which is what I needed to make sure about.
[14:18:42] <SWPadnos> ?
[14:19:05] <SWPadnos> are you using the normal parport driver and then "reinterpreting" the data?
[14:19:23] <mozmck> there's no latch, and I did try just what you suggest. change the control lines on one cycle and read the inputs on the next.
[14:19:43] <SWPadnos> by the way, it's not the order they're added, you can specify where to put a function when you "addf" it
[14:19:51] <SWPadnos> addf function thread 1
[14:19:55] <SWPadnos> puts it first
[14:20:04] <SWPadnos> addf function thread -1 makes it last
[14:20:18] <SWPadnos> +2 means second, -2 means second from last ...
[14:21:06] <mozmck> I guess "reinterpreting the data" is what I'm doing. I read the same 4 inputs but put them in different places based on the state of the control lines.
[14:21:31] <SWPadnos> output then read on the next cycle is the natural way for things to work, if you use the parport driver and the normal "read / process / write" sequence
[14:21:32] <mozmck> My hal file just has addf function thread with no order specified.
[14:21:37] <SWPadnos> ok
[14:21:47] <SWPadnos> in that case it is the order you add them :)
[14:22:40] <mozmck> the other way I do it is read the inputs just before I change the outputs in the same cycle. but if those outputs don't actually get changed until the next cycle that could be causing me problems...
[14:22:59] <SWPadnos> sure
[14:23:00] <mozmck> although it didn't seem to change things either way.
[14:23:09] <mozmck> I'll have to try that again.
[14:23:39] <SWPadnos> parport.read / mozmck.fiddle / parport.write that's all you should need :)
[14:24:46] <mozmck> :) thanks for the help and ideas.
[14:25:19] <SWPadnos> you know, a generic demux HAL component could be of value
[14:25:48] <SWPadnos> a couple of selector inputs, several outputs, only the selected output gets changed whenever the function runs
[14:27:42] <mozmck> I think jepler actually wrote the first version of this code to do 8 inputs, now Tom wanted to try 16.
[14:28:05] <SWPadnos> ok - I remembered him working on something at Fest last year
[14:28:34] <mozmck> the first version worked fine because our circuit was fast
[14:28:36] <SWPadnos> he was also trying to help Steve S with a similar driver issue
[14:29:02] <mozmck> this switches some optos and is not as cooperative
[14:29:22] <SWPadnos> hmmm
[14:29:59] <SWPadnos> the "machine side" should have always-active electronics (optos, whatever), and the thing you switch should only be the (preferably buffered) data
[14:30:41] <SWPadnos> have you been following Slavko Kocjancic's thread about his parport mux hardware?
[14:31:35] <mozmck> I think I saw it but haven't read it carefully.
[14:31:57] <SWPadnos> take a look at the schematic - you may have similar hardware :)
[14:32:35] <mozmck> I know about the switching stuff :) That would require more changes to our main board that we were trying to avoid if this would work.
[14:32:36] <skunkworks> he is trying to use the epp protocal though.. other than that,,
[14:32:36] <SWPadnos> he's got the optos between the parport pins and the buffer ICs on the board, which may be causing some timing issues (IMO)
[14:33:11] <SWPadnos> yes, he is using EPP cycles
[14:33:44] <mozmck> what is different with that? is he writing his own parport driver for that?
[14:34:05] <SWPadnos> way way faster
[14:34:17] <SWPadnos> yes, he's writing his own driver
[14:34:49] <SWPadnos> ok, time to go for breakfast. bbl
[14:35:38] <mozmck> here's the code jepler wrote and I modified
http://pastebin.com/r6Zd2edH
[14:37:36] <SWPadnos> don't you need 16 out pins?
[14:38:10] <SWPadnos> I guess you'd need to call it "iquadriplier" too :)
[14:38:26] <mozmck> hang on...
[14:38:37] <mozmck> http://pastebin.com/ApzvHrw1
[14:38:50] <mozmck> that's the new one.
[15:07:54] <SWPadnos> mozmck, just for the heck of it, change line 32 to b += (select ? 4 : 0);
[15:08:31] <SWPadnos> and for testing timing, you can change the base thread period - make it 100 us or something
[15:20:59] <mozmck> I'll try the parentheses. I have done the timing as you suggest. What I'm seeing is that one set of 2 banks (8 inputs) gets read into out[0] - out[3] and out[12] - out[15], and the other set of 2 banks gets read into out[4] - out[11].
[15:21:31] <mozmck> back to the other computer to do some more testing...
[16:21:00] <mozmck2> SWPadnos: when I put my scope leads on the lines controlled by select and select2, and trigger on the fast line (select), select2 periodically inverts in relation to select. But if I trigger on select2, it looks rock solid. any idea why? This is on an old HP 54510B scope...
[16:22:45] <mozmck2> I'm guessing the signals are not actually inverting in relation to each other, but it's just some oddity with the scope or something.
[17:56:50] <SWPadnos> mozmck, if you trigger on the falling edge (for example) of the select line, there's a 50/50 chance of the select2 line being high or low
[17:57:33] <SWPadnos> but since there's only one time when select2 has a falling edge (it's always at the same time as the select falling edge), you'll always see select in the same state when you trigger from select2
[18:03:51] <mozmck> hmm, I think it's triggered on the rising edge but not sure. so my "or something" was probably IO error (ignorant operator) :)
[18:03:59] <SWPadnos> heh
[18:04:07] <SWPadnos> either edge works though, it's the same
[18:04:32] <mozmck> I see what you're saying.
[18:04:41] <SWPadnos> the lower frequency signal (select2) is locked to the higher frequency signal (select), so you have a 50/50 shot at seeing it one way vs the other
[18:04:51] <SWPadnos> err, you know :)
[18:05:16] <mozmck> yah, and that's what I saw.
[18:05:47] <mozmck> still haven't gotten the whole thing to work right yet. it boggles my puny brain.
[18:05:55] <SWPadnos> did you try making the base period really really long, to see if it's a timing problem?
[18:06:02] <mozmck> tried again all the stuff you mentioned.
[18:06:28] <mozmck> I didn't try that, but I tried reading on one cycle and writing the next.
[18:06:41] <mozmck> that gives a period of about 100 us or so
[18:06:42] <SWPadnos> is the hardware combinatoric? (ie, the data lines will show a set of inputs based only on the state of the select pins, no other latch / strobe or other handshake needed?)
[18:06:58] <mozmck> combinatoric, yes
[18:07:10] <SWPadnos> it still gives only one base period (which I'll now assume is 50 us) between select write and data read
[18:07:15] <SWPadnos> ok, that makes it easy
[18:07:55] <SWPadnos> have you verified with certainty that the hardware is doing what you expect, aside from timing issues?
[18:08:00] <mozmck> I think it is a timing issue in the hardware but I can't find it. We changed the circuit and got the signal squared up really nice - still does the same thing.
[18:08:10] <mozmck> no. I need a four channel scope.
[18:08:14] <mozmck> or more brains.
[18:08:18] <SWPadnos> well, you have halmeter :)
[18:09:06] <SWPadnos> this is what I imagine for the hardware, correct me if I'm wrong: you have the 8-bit data port split up into a 4-bit section that always gets read, and a 4-bit section that's muxed by the two select outputs, right>
[18:09:08] <SWPadnos> ?
[18:10:28] <micges> SWPadnos: when 2.4.0 will be released?
[18:10:45] <SWPadnos> um. well I was thinking that it may not be on April 15, but we'll see
[18:11:08] <SWPadnos> right now the wiki page with the schedule still says that
[18:12:30] <micges> ok
[18:12:32] <mozmck> hmm, there are 4 inputs to the parport. on the input hardware there are two banks of 8 inputs, switched by the select2 line, and then those are broken into 2 sets of 4 that are muxed into the parport by the select line.
[18:12:47] <SWPadnos> ok, that's fine
[18:12:54] <micges> SWPadnos: you will release it?
[18:12:56] <SWPadnos> here's what you do to test the hardware
[18:13:34] <SWPadnos> micges, yes, I signed up to be the 2.4 release manager, but since I don't know what I'm doing yet, and I'm pretty busy with work, I don't know exactly what's going to happen :)
[18:14:09] <micges> we will help you :)
[18:14:15] <SWPadnos> mozmck, make yourself a hal file that loads the parport driver, sets up a thread (1 ms is fine), and adds the read and write functions to that thread
[18:14:36] <SWPadnos> make two signals if you like, called select and select2, and connect those to the parport output pins for the select lines
[18:15:00] <mozmck> read and write functions? you mean my component?
[18:15:09] <SWPadnos> also have the hal file load 4 halmeters connected to the data input lines (halmeter -s pin parport.0.xxx)
[18:15:14] <SWPadnos> no, just the parport driver
[18:15:27] <mozmck> ok.
[18:15:38] <SWPadnos> hook up physical wires to make different bit patterns on the 4 banks of inputs
[18:15:54] <SWPadnos> you should see the halmeters change when you manually change the select and select2 signals
[18:16:12] <SWPadnos> if that doesn't work, stop working on software and look at the hardware again
[18:16:20] <SWPadnos> micges, I'm counting on it ;)
[18:16:59] <mozmck> ok. hadn't thought of that. I haven't been looking at the software too much, because we figured out we had hardware problems for sure. Now those look better though.
[18:17:01] <micges> :)
[18:17:52] <SWPadnos> you may want to pop up halmeters for all 8 parport inputs, just to make sure that nothing weird is going on on the other pins
[18:18:26] <SWPadnos> timing can't be an issue if you manually change output bits and look at the results in userspace :)
[18:18:39] <SWPadnos> (remember to put "start" in the hal file)
[18:18:50] <SWPadnos> oh, and of course use halrun to load it :)
[18:18:51] <mozmck> ok.
[18:19:15] <SWPadnos> no messing with emc or anything - just bare HAL "are the wires doing what I think they should?"
[18:19:49] <mozmck> got it. I've done a little of that with another component I'm writing.
[18:28:43] <SWPadnos> oh, and while you have select and select2 in some state, mess with the physical connections (all of them, on all "ports") and see what changes and how long it takes
[20:20:30] <mozmck2> is there a list of packages needed to build the docs?
[20:28:13] <mozmck2> I kept running make and installing what it said was missing until it quit complaining and went to compiling, but it craters trying to build ../docs/src/Master_HAL.pdf
[20:28:35] <mozmck2> Here's the error: make: *** [../docs/src/Master_HAL.pdf] Error 1
[20:31:51] <JT-Hardinge> you might be missing a file for that doc
[20:38:05] <JT-Hardinge> mozmck also try a make clean
[20:38:47] <mozmck2> what file might be missing? I'm running from a fresh git download.
[20:39:04] <mozmck2> I did a make clean and tried again and get the same message.
[20:39:41] <mozmck2> seems like the first time it did it there was some mention of a ec*1000 file missing...
[20:39:45] <JT-Hardinge> a file that master_hal.lyx is wanting I guess
[20:40:38] <JT-Hardinge> you might refresh your checkout to make sure you didn't loose a file during the download
[20:40:39] <mozmck2> this is on 10.04 with lyx 1.6.5 - if that makes a difference...
[20:41:23] <JT-Hardinge> let wander down to the beer cave and see what I'm using and if it is not the same then yea it matters
[20:41:50] <mozmck2> ok, I just figured out groff is missing. I'll see if that helps
[20:42:16] <mozmck2> surely lyx will work with older lyx files?
[20:44:44] <JT-Dev> mozmck lyx 1.5.3 here
[20:45:52] <JT-Dev> I show 79 items in my emc2-dev/docs/src/hal folder and 56 items in the images folder under that
[20:47:25] <mozmck2> Hmm, I show the same
[20:47:47] <mozmck2> so lyx won't handle older versions of it's own files?
[20:48:21] <JT-Dev> I'm not sure but I know I can't use anything else for editing them
[20:49:01] <JT-Dev> the docs folder properties is 1,349 items totalling 42.4 MB
[20:49:07] <mozmck2> huh. it gives me the same error. no explanation - just "Error 1"
[20:49:58] <JT-Dev> I usually get that when some reference is missing... not much of a clue I know
[20:50:00] <mozmck2> that must be before a make clean? I have 721 items 15.1 MB
[20:50:33] <JT-Dev> ah, that must be after a successful make
[20:51:15] <mozmck2> I guess I'll build without docs for now. I was trying to make packages and that builds the docs.
[20:51:51] <JT-Dev> ok
[20:51:58] <mozmck2> I guess we'll have to get this working soon though if we're going to support ubuntu 10.04
[20:52:05] <JT-Dev> * JT-Dev wanders back out to the shop
[20:52:10] <JT-Dev> yep
[20:52:21] <JT-Dev> is 10.04 out now?
[20:52:43] <micges> will be in 25 days
[20:52:50] <JT-Dev> ok
[20:52:52] <micges> more less
[20:52:54] <mozmck2> no, but I'm working in advance on it
[20:53:07] <mozmck2> using beta1+ right now
[20:56:25] <micges> mozmck2: is it possible to change position of (minimize, close ) button of window manager from left to right?
[20:56:32] <micges> (in 10.04)
[20:56:51] <mozmck2> heh, yes - first thing I did!
[20:56:56] <mozmck2> hang on
[20:57:57] <mozmck2> gconftool-2 --set /apps/metacity/general/button_layout --type string “:minimize,maximize,close,”
[20:59:05] <micges> thanks :)
[20:59:16] <mozmck2> I may go back to debian if ubuntu keeps up their current trend. From what I've seen I don't think the gnome3 desktop coming in 10.10 will be a step forward either.
[21:01:56] <micges> I saw they have few hundred bugs
[21:02:31] <micges> so maybe gnome3 will be HEAVY bugfix release :)
[21:04:13] <mozmck2> I don't know. There's a whole new interface called gnome shell, that I'm not sure I'll like at all.
[21:05:11] <micges> I don't saw 10.10 also
[21:05:22] <micges> only 10.04
[21:06:06] <micges> next week I must see if it have driver what I need (usb CCTV)
[21:06:39] <mozmck2> 10.10 is the next release coming later this year.
[21:06:53] <mozmck2> I have to reboot now, bbl.
[21:20:18] <alex_joni> mozmck2: save that gconftool incantation
[21:20:54] <alex_joni> that's something we _absolutely_ must do on the LiveCD
[21:21:03] <alex_joni> so is disabling desktop effects
[21:21:08] <alex_joni> http://linuxcnc.org/hardy/livecd.errata
[21:21:11] <mozmck2> yeah, I need to. it messes up the buttons so I also changed the theme to clearlooks (which I like better anyhow)
[21:21:13] <alex_joni> (from last time..)
[21:21:39] <mozmck2> ah. I have a number of notes for compiling etc already.
[21:21:46] <alex_joni> great
[21:22:14] <alex_joni> maybe we should start setting up linuxcnc.org/lucid/
[21:23:12] <mozmck2> yeah. I got emc2 compiled now, but when I try to run latency-test it says: insmod: error inserting '/home/moses/Projects/emc2/rtlib/rtapi.ko': -1 Unknown symbol in module
[21:23:24] <mozmck2> same for thread.ko
[21:23:35] <mozmck2> (run-in-place)
[21:26:06] <mozmck2> ERROR: Module rtapi does not exist in /proc/modules
[21:26:20] <mozmck2> is that a normal error?
[21:28:05] <mozmck2> looks like
[21:29:59] <mozmck2> oh, it's complaining about "no symbol version for xxxxxx" I guess I didn't turn off module versioning when I compiled the kernel.
[21:30:01] <alex_joni> dmesg output?
[21:30:53] <alex_joni> actually you shouldn't turn it off
[21:31:18] <alex_joni> but rtai and emc2 modules need to have versions too
[21:31:49] <mozmck2> http://www.pastebin.ca/1856101
[21:33:41] <mozmck2> hmm, I think we used to have to turn off module versioning...
[21:34:23] <alex_joni> yes, up to 2.6.20 or so
[21:35:03] <alex_joni> this looks like an emc2 compile problrm though
[21:35:11] <alex_joni> not rtai
[21:35:27] <alex_joni> I assume rtai tests are ok?
[21:35:38] <mozmck2> hmm. this is the 2.4 branch, fresh git clone.
[21:35:53] <mozmck2> I don't know, how do I run them?
[21:36:08] <mozmck2> seems like I did that once but I forgot.
[21:37:38] <mozmck2> hmm, runtests? looks like they all fail :)
[21:37:53] <alex_joni> not emc2 runtests
[21:38:01] <alex_joni> rtai ones..
[21:38:33] <alex_joni> cd /usr/realtime*/testsuite/latency/kern
[21:38:44] <alex_joni> sudo ./run.sh
[21:38:50] <alex_joni> or similar
[21:39:56] <mozmck2> ok, that's running....
[21:40:51] <mozmck2> looks like a few latencies around 20000
[21:42:58] <mozmck2> when compiling I got a number of warnings like this: ‘rtai_lxrt’ is static but used in inline function ‘rt_set_period’ which is not static
[22:05:29] <alex_joni> mozmck2: from emc2? sounds more like rtai warnings to me
[22:09:52] <alex_joni> mozmck2: crashing here.. good night
[22:10:09] <alex_joni> btw, I might have monday off, so I'll look into lucid
[22:10:29] <alex_joni> if you have some pointers online to the things you've done already, it could save me some trouble
[22:10:41] <alex_joni> (maybe a wikipage or something)
[22:24:46] <mozmck> I'll try and put a wiki page up or something. For rtai I used the debian directory from hardy and modified the files just a little. It worked fine for rtai 3.8, but maybe there are some more changes needed for magma.
[23:00:29] <JT-Dev> mozmck did you ever get the docs to build?
[23:04:08] <mozmck2> nope. I quit trying and built without them, now still trying to get emc2 to run...
[23:05:25] <JT-Dev> ok, just wondering
[23:57:05] <mozmck2> JT-Dev, JT-Hardinge: what font packages are needed for the docs?
[23:59:03] <JT-Hardinge> mozmck I don't know sorry
[23:59:18] <mozmck2> I enabled debug messages and I get a lot of errors about there not being any letters in 'nullfont'
[23:59:39] <JT-Hardinge> that's weird