Back
[07:34:04] <jepler> pcw_home: is 'ssremote' different than 'sslbpfw'? yes, very soon I need a source and tasm-assembled hex output to really check the rightness of pta
[07:34:33] <jepler> at a minimum I still need to implement #include though
[07:49:54] <pcw_home> ssremote is a implementation of a sserial remote I/O device on a 7I90
[07:49:56] <pcw_home> (SSLBP is the host side sserial controller)
[07:52:37] <pcw_home> ssremote is a good test example because it uses the
[07:52:39] <pcw_home> latest processor but no macros
[08:00:28] <pcw_home> http://pastebin.com/pwZBfimn
[08:00:30] <pcw_home> is the build batch file for ssremote
[08:02:32] <jepler> pcw_home: OK, will this be somewhere inside 7i90.zip?
[08:04:16] <pcw_home> all the source is but the build files are not since they are pretty specific to our environment
[08:05:15] <jepler> I see this invokes the makeinc and makeram commands you had mentioned a few days ago
[08:05:40] <pcw_home> makeinc is not needed (the equ files are there)
[08:05:53] <jepler> and I can squint instead of using makeram
[08:06:04] <pcw_home> Yep
[08:06:33] <pcw_home> well makeram just includes the appropriate vhdl boilerplate
[08:08:18] <pcw_home> and makeinc is only if you want to say make .h files from the same equates
[08:10:36] <pcw_home> (for host access to internal attached processor variables for example)
[08:15:46] <jepler> actually SSREMOTE.ZIP only has SSREMOTE.INC
[08:17:42] <jepler> but I think I can make a plausible .EQU
[08:21:01] <pcw_home> freeby.mesanet.com/SSREMOTE.EQU
[08:23:33] <jepler> hm, to be compatible with tasm I need to not have operator precedence
[08:26:04] <pcw_home> its just left to right? (I would not notice since I dont use any fancy macros or assembler math)
[08:26:12] <jepler> the manual says:
[08:26:14] <jepler> > No operator precedence is in effect. Evaluation is from left to right unless grouped by parenthesis (see example below).
[08:27:12] <pcw_home> ahh
[08:27:21] <jepler> obviously pretty easy to write
[08:27:41] <jepler> except, with me coding in python, it's easier still to code 'just evaluate this expression with python'
[08:30:20] <pcw_home> probably the only place where this might matter is SSLBP (and maybe could be made compatible with normal
[08:30:21] <pcw_home> operator precedence with parens if not already there)
[08:45:39] <jepler> after hand-preprocessing ssremote, I can assemble it with two differences
[08:46:08] <jepler> one I am confident is my fault -- I assemble dw with a different byte order than tdasm
[08:46:40] <jepler> the other is a missing 'ret' instruction which I suspect is because the source doesn't quite match the .vhd
[08:46:59] <jepler> stab hm2startwrite
[08:46:59] <jepler> ret
[08:46:59] <jepler> debug8
[08:47:39] <jepler> my output has a 1800 instruction (ret) but the .vhd doesn't
[08:47:41] <jepler> bbl
[08:55:40] <pcw_home> Thats a mistake in the debug .asm source
[08:58:26] <pcw_home> (ret in wrong field) it worked because it fell through to debug8
[08:58:27] <pcw_home> (always wondered why debug init turned on my test leds)
[08:59:24] <pcw_home> (that code is not actually used)
[09:07:58] <pcw_home> so your assembler is already better than Tasm!
[09:19:30] <jepler> oh I see now that it is a label
[09:20:43] <pcw_home> well its not _supposed_ to be a label
[09:21:01] <jepler> yes
[09:21:18] <jepler> but I had actually read the part of the tasm documentation that explained that without the leading space it defines a label
[09:21:30] <jepler> I'll "fix" my bug :)
[09:21:54] <pcw_home> but your bug fixes my typos
[09:22:35] <jepler> I think what I had written causes anything that starts in the first column to be parsed as an instruction if it can be, but otherwise to be parsed as a label
[09:22:55] <jepler> anyway, this is pretty cool
[09:23:29] <jepler> depending how I split my weekend time between working on spi 7i43 and this, I should be able to do the preprocessor part in under a day's work..
[09:23:35] <pcw_home> Thats is cool
[09:24:17] <pcw_home> Ill fix twiddler to use the latest processor and fix the example code since thats a lot easier to actually test
[09:24:33] <jepler> by the way, I don't know if you were inclined to try running any of this, but it requires pyparsing 2.x, which is newer than what is packaged in debian 7 and ubuntu 12.04.
[09:25:20] <pcw_home> is that in ubuntu14.04?
[09:25:30] <jepler> it looks like the version in ubuntu 14.04 should be compatible
[09:25:57] <jepler> they have 2.0.1. I was on debian testing, which has 2.0.2; I know that one works
[09:26:38] <jepler> or, you can just copy pyparsing.py into the directory with pyasm.py
[09:27:23] <pcw_home> Yeah ( is that for python 3.x? )
[09:28:54] <jepler> apparently pyparsing 2.x is compatible with python3. I still write python2.
[11:27:01] <cradek_> in response to gene's report:
http://timeguy.com/gitweb?p=linuxcnc.git;a=commitdiff;h=679045
[11:28:15] <jepler> cradek: I believe initializing a pin or parameter to zero in a comp should never be necessary
[11:28:37] <cradek> hmm. I wonder how he got nan, then
[11:29:00] <jepler> it's possible that comp isn't behaving as expected
[11:29:16] <jepler> struct __comp_state *inst = hal_malloc(sz);
[11:29:16] <jepler> memset(inst, 0, sz);
[11:29:37] <jepler> so for parameters, they should all read as zero
[11:29:47] <jepler> without additional initialization
[11:29:48] <cradek> it's the pin
[11:29:53] <cradek> the out pin
[11:30:20] <jepler> yes
[11:30:33] <cradek> does that get zeroed somewhere else?
[11:30:39] <jepler> I'm double-checking on that now
[11:30:58] <jepler> a pin's "dummy signal" gets zeroed:
[11:30:59] <jepler> memset(&new->dummysig, 0, sizeof(hal_data_u));
[11:31:21] <jepler> and a signal gets initialized
[11:31:21] <jepler> *((hal_float_t *) data_addr) = 0.0;
[11:31:33] <cradek> an out pin doesn't have a dummysig does it?
[11:32:10] <jepler> I think all pins do
[11:32:17] <jepler> they have to be internally connected to something so that *pin is not a segfault
[11:32:48] <cradek> oh I see
[11:33:42] <jepler> should I go actually read gene's report?
[11:33:57] <cradek> does that ever bring you clarity?
[11:34:19] <cradek> Switch the halmeter to lowpass.spindle.out and it displays -nan.
[11:35:40] <jepler> btw a nonzero default gain is probably a reasonable change
[11:36:40] <cradek> well I can't reproduce his problem, but I'm on sim
[11:37:04] <cradek> his nan could have come from some other place
[11:37:06] <jepler> personally, I'd like to blame hm2 encoder velocity
[11:37:17] <cradek> fair enough
[11:37:25] <jepler> if lowpass ever gets a nan input its output would stick at nan forever
[11:37:42] <cradek> sure
[11:44:15] <jepler> // FIXME: There's a bug somewhere in this code that
[11:44:16] <jepler> // sometimes makes encoder.velocity NaN. Observed by
[11:44:16] <jepler> // micges, but never reproduced.
[11:44:41] <pcw_home> There were complaints about nans in the hm2-encoder data somewhere but I have not heard a complaint in years
[11:44:56] <archivist> a lowpass should never give a nan that would be another bug
[11:46:39] <archivist> throwing an error if any input sees a nan may be a sensible thing to do
[11:46:54] <jepler> archivist: what should a lowpass filter output in the case that its input is nan?
[11:47:26] <archivist> I am thinking it should be caught earlier
[11:47:42] <cradek> sure, wherever it was generated
[11:48:42] <cradek> I thought it was a bug in lowpass, because I thought it started with an uninitialized value, which could have been nannish. but I was wrong.
[11:50:49] <jepler> like all who have come before me, I can't see how hostmot2 encoder velocity could end up as nan
[11:52:05] <jepler> 0./0. -> nan, but it sure looks like the divisor dT_s can never be zero (though the test is indirectly via dT_clocks)
[11:53:15] <archivist> should they all recover from nan too
[11:58:53] <cradek> if the old value is nan and the new value is 13, and the gain is .1, it's not clear what the new value could be other than nan
[11:59:18] <cradek> that's how FP math works by definition
[11:59:33] <cradek> I think tracking down the source is the only sane answer
[12:00:23] <archivist> an electronic lowpass would never get a nan output
[12:01:00] <archivist> therefore it would recover from a bad input
[12:04:27] <jepler> if nan is not a permitted output, then why should lowpass be modified to handle it? on the other hand, if it is a permitted output, then why should lowpass do anything but what it does now?
[12:05:04] <jepler> (actually, I could see arguing that for a nan input, lowpass should hold its output, but since nobody's saying it's valid to transport nans on hal signals it's moot)
[12:07:04] <archivist> I can see a case for lowpass throwing an error, but a system will work better if it stays at the previous valid state until the input nan gas gone
[12:07:18] <archivist> gas has
[12:07:25] <jepler> GIGO
[12:07:26] <seb_kuzminsky> hrm, i should have know you guys would be debugging this on irc before trying to reproduce gene's problem here locally
[12:07:45] <cradek> you can't get it either?
[12:07:59] <seb_kuzminsky> i just verified that 'loadrt lowpass names=lowpass.spindle' wfm
[12:08:11] <cradek> yeah that's probably a red herring
[12:08:19] <jepler> of course I didn't consider it could have been names=
[12:08:20] <seb_kuzminsky> a red geneing
[12:08:30] <seb_kuzminsky> jepler: that's very sensible of you
[12:08:51] <seb_kuzminsky> because names= works fine in lowpass, just like it does in everything else and has for years
[12:09:16] <seb_kuzminsky> oops, i tried to email gene a screenshot of it working, but it's too big and got held up by the mailing list
[12:09:28] <seb_kuzminsky> i'll move the pic to a webserver and send another email with a link instead
[12:15:42] <jepler> well it's clear that most of the time it works
[12:16:43] <jepler> what I did not expect was that googling "nan" would show three borderline NSFW image results in the first plage
[12:16:56] <seb_kuzminsky> i wonder if micges has seen the problem since... feb 2010 when i added that fixme
[12:20:14] <jepler> rtapi_s32 dT_clocks;
[12:20:17] <jepler> dT_clocks = (time_of_interest - e->prev_event_reg_timestamp) + (e->tsc_num_rollovers << 16);
[12:20:52] <jepler> what's the speed of the timestamp? Is it at all likely that dT_clocks can become zero due to integer overflow?
[12:23:57] <pcw_home> default timestamp frequency is 1 MHz
[12:24:18] <pcw_home> so ~65 ms between rollovers
[12:24:44] <seb_kuzminsky> the timestamp divisor register is set in hm2_encoder_parse_md()
[12:25:08] <seb_kuzminsky> judging by th enumber of comment lines i wrote about it, i gave the matter some thought, back in 2007
[12:25:15] <jepler> hee hee
[12:26:54] <jepler> so the default is 1MHz and also you try to set it to 1MHz explicitly
[12:27:07] <seb_kuzminsky> looks like i was aiming for ~1000 encoder-timestamp-ticks per servo period
[12:27:15] <seb_kuzminsky> yeah
[12:27:44] <jepler> (in hal, we need a callback which fires when a function is added to a thread
[12:28:06] <jepler> so that it can recalculate stuff based on the intended period)
[12:28:28] <jepler> (though the difficulty of actually writing to hostmot2 registers at this time would be another wrinkle)
[12:29:10] <jepler> bbl
[12:37:15] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 75fb8bc 06linuxcnc 10docs/src/hal/comp.txt docs: fix a typo in comp(1) docs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=75fb8bc
[12:37:15] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 3eb4239 06linuxcnc 10docs/src/hal/comp.txt docs: clarify comp's usage of count and names * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3eb4239
[12:58:04] <cradek> I wonder what version/build gene is using. it might be uspace...?
[13:01:11] <memleak> why would you search for nan in google images anyway?..
[13:02:30] <archivist> google gives you some images for a normal search
[13:11:31] <linuxcnc-build> build #2298 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2298 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[13:15:46] <linuxcnc-build> build #2304 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2304 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[13:23:36] <cradek> interpreter did not finish
[13:27:57] <seb_kuzminsky> i've seen that subroutine-return error a couple of times lately
[13:49:32] <skunkworks_> https://www.youtube.com/watch?v=oZW4hGbRAhs
[13:52:23] <jepler> that's quite the thing
[13:52:31] <cradek> awesome
[13:54:17] <jepler> https://lh6.googleusercontent.com/-IywgXren2Is/U-N2-Q15skI/AAAAAAAANIw/Nx7mIKKfPMQ/w506-h285/pid.gif
[13:55:00] <jepler> oh is it a touchscreen?
[13:55:33] <cradek> that's neat
[13:55:38] <jepler> https://www.youtube.com/watch?v=j4OmVLc_oDw
[13:55:51] <jepler> yes, resistive touchscreen
[13:57:48] <jepler> I want one as a desk toy now
[13:58:30] <cradek> my pile of old digitizing tablets have got to be good for something like that
[14:00:29] <archivist> but it uses an arrrhguinoooo
[14:33:15] <CaptHindsight> that quilting machine is interesting, and chose to modify AXIS vs Gmoccapy
[17:19:14] <seb_kuzminsky> jepler: we're getting these intermittent failures in the subroutine-return test, you made commit b2b19548 a while back and the commit message makes me think you saw improvement after?
[17:35:14] <skunkworks_> wheezy sure seems fussier with hardware... hmm - I should load the rt-preempt kernel and see
[17:38:50] <seb_kuzminsky> i wonder if just upping the interpreter-idle-check timeout from 2 seconds to like 1 bajillion would fix it
[17:52:14] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 30226cf 06linuxcnc 10tests/interp/subroutine-return/test-ui.py tests: give subroutine-return more time to do its thing * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=30226cf
[19:46:54] <PCW> migces: hi
[19:48:10] <micges> PCW: hi
[19:51:10] <PCW> 7I92 works so will need mMF and linuxcnc collateral
[19:51:26] <PCW> bbl SO yelling
[19:51:52] <micges> ok
[19:52:43] <PCW> ethernet 34 I/O P2 = IO 0..16 P1 = I/O 17..33
[19:53:05] <PCW> (ethernet 5i25 basically)
