Back
[11:56:36] <jepler> seb_kuzminsky: what do you think about me merging my proposed branch in hostmot2-firmware?
[11:56:52] <jepler> seb_kuzminsky: as far as I know it now all builds again, but of course I can only test a small range of the firmwares
[11:57:37] <jepler> pretty sure at least up to cc2c6707ab422caa32744c334ed38fbd6d3a9cf5 is a good idea to merge; the stuff beyond it might need more testing
[11:58:19] <jepler> but I think the b995924058ec1892450238b0db2c05282e4b1378 refactor is a good one which provides a better starting point for adding the other new cards we'd (I assume) like to build firmwares for
[12:01:50] <seb_kuzminsky> i'll look
[12:02:30] <jepler> from the new lot, I tested 7i80 and 7i90spi firmwares
[12:02:44] <jepler> I intend to test 7i43epp and 5i20 firmwares but I haven't gotten around to it
[12:04:54] <jepler> (/home/jepler/local/src/linuxcnc/bin/halscope+0x443b5a): runtime error: value -2.14748e+09 is outside the range of representable values of type 'int'
[12:05:30] <jepler> clang -fsanitize=undefined gives some interesting items to look at
[12:10:22] <jepler> none from rtapi_app; I wonder if this is (unlikely) because there's no undefined integer behavior, or (likely) something about dynamic linking stops it from working
[12:39:51] <seb_kuzminsky> jepler: up through cc2c looks fine
[12:40:30] <seb_kuzminsky> ooh, and i like b9959
[12:46:44] <KGB-linuxcnc> 03Norbert Schechner 052.6 1be132e 06linuxcnc 10configs/sim/gmoccapy/gmoccapy_plasma/signals.py gmoccapy - missed a bracket, resulting in an exception * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1be132e
[12:46:45] <KGB-linuxcnc> 03Norbert Schechner 052.6 1f74d9d 06linuxcnc Merge branch '2.6' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1f74d9d
[12:49:58] <seb_kuzminsky> jepler: i'll trust you on the rest of that branch, i dont understand it all but i dont see anything that jumps out as being wrong
[12:52:46] <KGB-linuxcnc> 03Norbert Schechner 05master b3262c5 06linuxcnc 10configs/sim/gmoccapy/gmoccapy_plasma/signals.py gmoccapy - added missing bracket in signals.py * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b3262c5
[12:53:25] <seb_kuzminsky> jepler: the version numbers of the debs will be wrong, i'm still (slowly) working on the fix
[12:53:38] <seb_kuzminsky> they'll claim to be 0.8.something
[13:08:53] <KGB-linuxcnc> 03Norbert Schechner 052.6 945cbf4 06linuxcnc 10configs/sim/gmoccapy/gmoccapy.ini 10src/emc/usr_intf/gmoccapy/gmoccapy.glade 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_2_1 - minor layout changes due to change to XFCE * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=945cbf4
[13:08:53] <KGB-linuxcnc> 03Norbert Schechner 052.6 7710ac2 06linuxcnc 10configs/sim/gmoccapy/gmoccapy_plasma/signals.py gmoccapy_1_2_1 - added missing bracket in signals.py * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7710ac2
[13:08:53] <KGB-linuxcnc> 03Norbert Schechner 052.6 7b52705 06linuxcnc Merge branch '2.6' of git://git.linuxcnc.org/git/linuxcnc.git into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7b52705
[13:08:57] <KGB-linuxcnc> 03Norbert Schechner 052.6 a516b2a 06linuxcnc Merge branch '2.6' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a516b2a
[13:09:35] <KGB-linuxcnc> 03Norbert Schechner 05master f94486c 06linuxcnc 10configs/sim/gmoccapy/gmoccapy.ini 10src/emc/usr_intf/gmoccapy/gmoccapy.glade 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_2_1 - minor layout changes due to change to XFCE * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f94486c
[13:09:35] <KGB-linuxcnc> 03Norbert Schechner 05master 4cab0f7 06linuxcnc 10configs/sim/gmoccapy/gmoccapy_plasma/signals.py gmoccapy_1_2_1 - added missing bracket in signals.py * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4cab0f7
[13:09:35] <KGB-linuxcnc> 03Norbert Schechner 05master 11c2c69 06linuxcnc Merge branch 'master' of git://git.linuxcnc.org/git/linuxcnc.git * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=11c2c69
[13:09:39] <KGB-linuxcnc> 03Norbert Schechner 05master bde32c9 06linuxcnc Merge branch 'master' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bde32c9
[13:43:45] <seb_kuzminsky> wow
[13:44:38] <skunkworks> is that bad?
[13:46:03] <pcw_home> stunned or happy?
[13:46:53] <seb_kuzminsky> facepalm
[13:47:08] <seb_kuzminsky> it's... ok. it's just... goofy
[13:48:20] <jepler> I hate glade and the diffs it produces. did they not check to see how it works with version control systems?
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=945cbf4#patch2
[13:48:59] <seb_kuzminsky> there is one commit of content, and then two totally superfluous merge commits
[13:49:17] <seb_kuzminsky> (and then the same thing in master)
[13:51:18] <cradek> I looked through those commits too, and also concluded they are ok, but weird.
[13:52:17] <cradek> but yeah, glade is awful
[13:53:09] <cradek> if changing window managers or fonts or whatever makes you have to change fixed widths of things in your application, something has probably gone wrong along the way
[13:54:50] <norbert__> Sorry for messing you guys up, the mixxing of my commits was caused, because I just changed to a new development PC, so I got now one with Wheesy.
[13:55:46] <norbert__> The changing of the size is caused, because Ubuntu 10.04 takes some time no concern of the settings you put in the glade file, but XFCE seems to be very strikt with that.
[13:57:26] <cradek> the glade stuff is not your fault at all - it's just sad how poorly it works, and how much it breaks from release to release
[13:58:24] <norbert__> Yes, if you change just one setting, sometimes half the file is marked as changed, I did never understood that.
[14:02:00] <seb_kuzminsky> i wonder if there's a tool like 'indent' that you can run on glade files to normalize them
[14:02:38] <cradek> I suspect just taking out all leading whitespace would fix the problem
[14:03:01] <cradek> unless it reorders things? I guess I have no idea without trying stuff.
[14:03:39] <norbert__> Please do not try that, I am pretty sure, that after that the file will be useless ;-) It is glade!
[14:03:53] <seb_kuzminsky> it does reorder
[14:04:22] <seb_kuzminsky> so an hypothetical normalizer would have to parse the glade xml and re-emit it in some kind of deterministic order
[14:11:40] <cradek> yuck.
[14:13:44] <seb_kuzminsky> it apparently sucks for other people too:
http://stackoverflow.com/questions/19137545/dealing-with-glade-files-in-dvcs
[14:15:03] <seb_kuzminsky> several projects are going the "one dialog per glade file" route, in order to simplify diffs & merges
[14:16:54] <seb_kuzminsky> here's someone claiming that glade3 is much better about not inserting all these spurious changes than glade2 is:
https://answers.launchpad.net/bzr-gtk/+question/10443
[14:17:09] <seb_kuzminsky> (that's from 2007...)
[15:15:32] <KGB-linuxcnc> 03Michael Geszkiewicz 052.6 b4402cc 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_pci.c hm2_pci: fix few FPGA names * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b4402cc
[15:21:02] <micges-dev> jepler: read_page fix made 5i25 verification 2x faster
[15:23:43] <PCW> micges-dev : I wonder if encoder issue is an unwarranted assumption in driver that a timestamp change means a count change
[15:23:45] <PCW> (haven't looked at the code, just guessing)
[15:25:16] <micges-dev> may be
[15:25:30] <micges-dev> hold on I'll show you data
[15:26:22] <PCW> timestamp change and 0 count change is certainly possible
[15:27:14] <micges-dev> PCW:
http://pastebin.com/cahQ2psL
[15:27:29] <micges-dev> error is in the middle
[15:28:03] <micges-dev> seems that there was count change without timestamp change
[15:29:10] <micges-dev> it's 99% noise
[15:30:44] <PCW> its possible if the counts happen in less than 1 usec
[15:31:08] <PCW> try setting the filter rate lower
[15:32:17] <micges-dev> ok
[15:33:42] <PCW> looks like very noisy encoder signals but if the encoder allowed count rate is faster than 1 MHz this can happen
[15:34:06] <PCW> may be a reason to set the timestamp faster
[15:34:30] <micges-dev> yeah they still fighting with that noise there
[15:35:06] <micges-dev> seems they put 7kW driver too close
[15:35:22] <PCW> might try our ENC-Y as a re-driver
[15:36:23] <micges-dev> yeah won't hurt to try
[15:36:24] <PCW> (And importantly it has a nice rotating LED quadrature indicator)
[15:37:18] <jepler> so between encoder reads, a <1us pulse into an encoder input would change the timestamp but leave count unchanged at the next read
[15:37:24] <jepler> PCW: this is basically the situation you are outlining? ^^
[15:39:10] <PCW> No that should not happen now that i think about it
[15:42:07] <PCW> it possible to get no count change but timer change with fast vibration or teasing at an edge
[15:42:12] <PCW> its
[15:42:54] <automata> pcw any example code to use pktuart on both host and fpga side?
[15:43:09] <PCW> but it look like theres a count change and no timer change from reading to reading
[15:43:24] <PCW> which should be impossible
[15:45:20] <jepler> during the same 1us tick of the encoder timestamp, you could have (A) hal reads encoder & timestamp (B) encoder edge seen
[15:45:59] <PCW> well not may examples of PKTUART usage (well the 7I90 ssremote config uses it)
[15:47:43] <PCW> as long as the count/timestamp register is read only once there should be no synchronization issues
[15:49:42] <automata_> sorry pcw: got cutoff..
[15:52:17] <PCW> the timestamp register is updated when the count is changed and they are read atomically so I suspect the error is higher up
[15:52:35] <jepler> PCW:
http://pastie.org/9543051
[15:52:49] <jepler> this is the scenario I'm imagining
[15:54:35] <jepler> that gives you a count change with no stamp change
[15:54:57] <jepler> and this gives you a stamp change with no count change:
http://pastie.org/9543058
[15:55:18] <PCW> Yes that is possible if the count occurs < 1 usec after the timestamp was read
[15:56:52] <PCW> wait thats not possible, sine the timestamp will change
[15:57:29] <automata_> I found the file PIN_PktUARTTest_72.vhd in the 7i90 folder...
[15:57:52] <automata_> any pointers on how to use it with hostmot2 driver?
[15:58:45] <PCW> automata_ what are you trying to do?
[15:59:50] <jepler> micges-dev: 2x faster eeprom programming? nice
[16:00:26] <jepler> PCW: OK, revised counter snafus again. the count change without stamp change needs two edges + one hal read all within 1us.
http://pastie.org/9543072
[16:03:13] <jepler> what do invalid quadrature transitions like 00 -> 11 do to the latched timestamp?
[16:08:45] <PCW> invalid transitions neither count nor update the timestamp
[16:23:49] <seb_kuzminsky> wooo, got my plane tickets for the linuxcnc hackfest!
[16:24:27] <micges-dev> jepler: 2x faster verification for now
[16:25:06] <cradek> seb_kuzminsky: yay!
[16:26:22] <seb_kuzminsky> :-)
[16:27:54] <micges-dev> so counter change without timestamp change should be ignored by driver?
[16:30:23] <micges-dev> jepler: did you have uh-oh encoder message while testing 7i80 or 7i90?
[16:32:32] * mozmck plans on going to the houston fest
[16:32:40] <seb_kuzminsky> mozmck: see you there :-)
[16:33:06] <mozmck> good!
[16:34:36] <cradek> I'm going, too
[16:41:56] <mozmck> Good! It's about 4.5 hours driving time from me.
[16:42:28] <cradek> ~ 13 for me
[16:43:49] <ssi> when is it?
[16:44:15] <mozmck> Oct 18-24
[16:44:30] <ssi> hm
[16:44:45] <ssi> I may be able to make that happen
[16:44:57] <jepler> micges-dev: I got some encoder error messages while 7i90spi was badly broken
[16:45:16] <mozmck> ssi: just fly your plane!
[16:45:19] <ssi> thinking about it
[16:45:24] <ssi> where exactly will it be?
[16:45:55] <mozmck> Houston, here:
https://txrxlabs.org/
[16:45:56] <CaptHindsight> near downtown Houston
[16:45:57] <micges-dev> jepler: but no messages when it was ok?
[16:46:34] <ssi> 603nm to hobby
[16:46:48] <jepler> micges-dev: no, but I have not fed encoder signals into it
[16:47:08] <ssi> 630 to executive, which has WAY cheaper fuel :)
[16:47:12] <micges-dev> I see thanks
[16:48:34] <CaptHindsight> I thought you had a VTOL? :)
[16:49:27] <mozmck> ssi: some of the cheapest fuel around here is supposed to be at KSWI
[16:50:21] <PCW> "so counter change without timestamp change should be ignored by driver?"
[16:50:23] <PCW> you do know the time between counts is at least one servo period in this case
[16:50:28] <ssi> mozmck: dang yeah, 4.55
[16:50:45] <mozmck> ssi: stop by on the way :)
[16:51:30] <ssi> dallas isn't exactly on the way to houston from atlanta!
[16:51:57] <mozmck> hmm, guess not.
[16:55:28] <CaptHindsight> what might be the simplest way over the network to keep Linuxcnc in E-Stop?
[16:57:16] <CaptHindsight> say you want the local operator to not be able to run the machine unless authorized over the network
[16:57:51] <jepler> CaptHindsight: a userspace component which outputs 1 whe nthe network says it's OK and 0 otherwise?
[16:58:09] <jepler> and that goes into whatever technology you use for your estop (e.g., classicladder)
[16:58:23] <jepler> or a big AND gate
[16:58:28] <CaptHindsight> yeah
[16:58:51] <jepler> your userspace program gets to decide what to do when the network cable falls out
[16:59:26] <CaptHindsight> I going to have a HAL counter count the number of jobs run as well as have a watchdog if the network drops out
[17:00:04] <CaptHindsight> I just need remote E-stop between runs, not during
[17:07:46] <CaptHindsight> jepler: thanks, I was wondering if I had missed some feature that was already in Linuxcnc
[17:10:22] <ssi> I want to put together something that'll run central shop services, that remote linuxcnc machines can ask to run a task
[17:10:30] <jepler> CaptHindsight: not much about what estop is, is really defined by linuxcnc
[17:10:41] <ssi> the immediate need is something that'll run an electric solenoid on the compressor, and a relay to turn on the air dryer
[17:10:57] <ssi> where any machine, on its own dedicated linuxcnc pc, can ask the central service to turn on the air
[17:12:18] <CaptHindsight> jepler: I need to be able to keep the machine from operating after it completes a preset number of runs. Putting it into E-stop is an easy way to do that.
[17:14:51] <CaptHindsight> disabling Begin executing the current file [R] and Execute next line [T] in AXIS is what it could also act like
[17:16:25] <CaptHindsight> the GO button in MDI would also need to be disabled in case they decided to run a program one line at a time
[17:18:17] <jepler> whenever I hear scenarios like this, I think it sounds like you should fire the people you don't trust and hire ones you do
[17:18:37] <jepler> but it's not like I run a shop, soooo
[17:18:41] <CaptHindsight> it's the guberment
[17:18:51] <CaptHindsight> their idea
[17:18:54] <jepler> but it's not like I run a government, soooo
[17:21:17] <seb_kuzminsky> i am the living god-emperor of my cubicle and i declare sovereignty over all who reside within its felt walls
[17:26:29] <ssi> my buddy who is an air traffic controller has an official reprimand in his file for not taking enough breaks
[17:27:14] <mozmck> heh, after that controller fell asleep probably
[17:28:48] <Roguish> hey all. working away on my 4 motor setup with 7i39's and bldc's using the bldc.comp. all is good, except when I look at 'CALIBRATION' in axis gui, the only things that show are 'deadband' and 'encoder_scale'. not P, I, or D, or ff's ??? what's up with that?
[17:29:23] <Roguish> what the heck have I done wrong now?
[17:29:26] <seb_kuzminsky> Roguish: which version of linuxcnc are you running?
[17:30:01] <Roguish> latest. 2.6.3
[17:30:19] <Roguish> hybid iso with updates.
[17:31:39] <seb_kuzminsky> nice, that should work
[17:31:52] <seb_kuzminsky> your own custom .ini and .hal files, i assume?
[17:32:25] <Roguish> it does work nicely. yes my files. built on the sample and my older files
[17:32:40] <Roguish> and other info from the wiki and here.
[17:32:59] <Roguish> it would just be nice to have that incredibly handy calibration
[17:34:19] <seb_kuzminsky> can you paste one axis frmo your .ini and .hal that's not working in the calibration window
[17:34:22] <seb_kuzminsky> ?
[17:36:06] <Roguish> i don't follow. the 'Calibration' is a popup in AXIS. all axes work.
[17:37:08] <seb_kuzminsky> i want to see the part from your .ini and .hal files that describe something that's not working the way you expect
[17:37:35] <Roguish> Oh, ok.
[17:38:05] <Roguish> [AXIS_0]
[17:38:07] <Roguish> TYPE = LINEAR
[17:38:09] <Roguish> UNITS = inch
[17:38:10] <Roguish> HOME = 0.000
[17:38:12] <Roguish> MAX_VELOCITY = 5.0000
[17:38:13] <Roguish> MAX_ACCELERATION = 100.000
[17:38:15] <Roguish> BACKLASH = 0.000
[17:38:16] <Roguish> #INPUT_SCALE = 1.000
[17:38:18] <Roguish> ENCODER_SCALE = 1024
[17:38:19] <Roguish> OUTPUT_SCALE = 1.000
[17:38:21] <Roguish> OUTPUT_OFFSET = 0.000
[17:38:22] <Roguish> MIN_LIMIT = -100.000
[17:38:24] <Roguish> MAX_LIMIT = 100.000
[17:38:25] <Roguish> FERROR = 1.5
[17:38:27] <Roguish> MIN_FERROR = 0.5
[17:38:28] <Roguish> HOME_OFFSET = 0.000
[17:38:30] <Roguish> HOME_SEARCH_VEL = 0.000
[17:38:32] <Roguish> HOME_LATCH_VEL = 0.000
[17:38:33] <Roguish> HOME_USE_INDEX = NO
[17:38:35] <Roguish> HOME_IGNORE_LIMITS = YES
[17:38:36] <Roguish> #HOME_SEQUENCE = 0
[17:38:38] <Roguish> MAX_OUTPUT = 10.000
[17:38:39] <Roguish> # PID tuning params
[17:38:41] <Roguish> DEADBAND = 0.000001
[17:38:42] <Roguish> P = 20.00
[17:38:44] <Roguish> I = 0.01000
[17:38:45] <Roguish> D = 0.0020000
[17:38:47] <Roguish> FF0 = 0.000
[17:38:48] <Roguish> FF1 = 0.0000
[17:38:50] <Roguish> FF2 = 0.0000
[17:38:51] <Roguish> BIAS = 0.000
[17:39:11] <seb_kuzminsky> that's the info i wanted to see, thanks, but please use a paste service next time
[17:39:26] <seb_kuzminsky> like this:
http://paste.debian.net/
[17:39:29] <jepler> on the wheezy install there's a great program "nopaste"
[17:39:36] <jepler> you can "nopaste somefile.txt" and it'll tell you the url where it pasted it
[17:39:42] <seb_kuzminsky> ooh, nice
[17:39:43] <jepler> you can just copy *that* into your irc client
[17:40:07] <jepler> ditto if you run nopaste, use paste, then press ctrl-d
[17:41:26] <Roguish> try
http://paste.debian.net/120313/
[17:42:13] <Roguish> complete .ini file
[17:42:42] <seb_kuzminsky> we need the .hal file where you set up your pid parameters too
[17:43:45] <Roguish> http://paste.debian.net/120314/
[17:44:00] <Roguish> .hal file for motor 1
[17:44:25] <Roguish> there are a fair number of commented out lines.
[17:45:21] <seb_kuzminsky> hmm
[17:45:53] <jepler> set halcommand [split $tmpstring " "]
[17:45:56] <seb_kuzminsky> just a hunch, try changing the whitespace between "setp" and pid.mumble from tab to space characters and see if that makes it go
[17:46:02] <jepler> I think that the command is only split on spaces, not tabs
[17:46:05] <jepler> it looks like the hal file has tabs
[17:46:07] <seb_kuzminsky> jepler did the responsible thing and looked up the code
[17:46:39] <seb_kuzminsky> deadband has spaces, and it works
[17:46:44] <seb_kuzminsky> the other have tabs and didnt work
[17:46:53] <jepler> or experimentally change that line to say ... " \t" and see if that fixes it
[17:47:15] <seb_kuzminsky> ... and then submit a patch
[17:47:26] <jepler> this is the -devel channel, we can demand that sort of thing
[17:49:46] <Roguish> hey jepler, once again your just too cool. spaces fixed it. THANKS.
[17:50:21] <seb_kuzminsky> awesome
[17:50:24] <Roguish> in my nieve (sp) programming ability, would that be considered a parsing problem?
[17:50:37] <seb_kuzminsky> yep
[17:51:03] <Roguish> and is it easier to fix in the code, or to add a statement in the docs?
[17:51:15] <seb_kuzminsky> definitely we should fix it in the code
[17:51:36] <seb_kuzminsky> the hal file is valid, the calibrator-thingy hal-file parse is broken
[17:51:42] <seb_kuzminsky> *parser
[17:52:22] <Roguish> cool. in the mean time i will loose a few tabs. THANKS. Jepler and seb_kuzminsky
[17:53:31] <seb_kuzminsky> welcome :-)
[18:05:45] <micges-dev> PCW: ok I'll try then to fix driver on place and see what happens
[18:11:56] <PCW> Yeah so if a count occurs within 1 usec of reading the counter, on the next cycle, you could have a
[18:11:58] <PCW> count but no timestamp delta on the next read in which case you need to use the free running
[18:12:00] <PCW> timestamp to calculate the upper bound of the velocity estimation
[18:13:55] <micges-dev> so free running timestamp must be read right after 0x3000
[18:16:02] <PCW> probably read once before or after all the encoder reads
[18:16:47] <PCW> isnt it it read already?
[18:18:56] <PCW> very tricksy getting the velocity estimation correct and worrying about rollovers in both the free running and latched timestamps
[18:18:59] <micges-dev> err yes it is
[18:20:48] <PCW> I think this means you need to use the free running count instead of the latched timestamp for this particular case
[18:22:20] <micges-dev> vel estimation will be worse but we won't get Nan or inf
[18:22:50] <PCW> should not be a lot worse
[18:23:20] <jepler> just holding the prior velocity estimate for one cycle doesn't seem that bad either
[18:23:28] <PCW> it should only happen in the case you would have gotten the NAN anyway
[18:24:35] <micges-dev> yeah it's rare case only on two machines here
[18:27:25] <micges-dev> in 4 years
[18:41:55] <micges-dev> 'nite
[18:51:48] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 0ab1301 06linuxcnc 10tcl/bin/emccalib.tcl fix halfile parsing for calibration dialog * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0ab1301
[19:36:28] <PCW> if the encoder velocity issue is counts without timestamp changes, this should be fixable by setting the
[19:36:30] <PCW> encoder filter such that you cannot get 2 counts in the timestamp period
[19:56:18] <jepler> linuxcnc chooses a pretty conservative reference clock for the timestamp, doesn't it? I'll have to go back and read that comment...
[19:58:15] <jepler> increasing the timestamp clock to 4MHz would also improve things, while still allowing the read to be 60% late on a 10ms servo thread (16.384us)
[20:01:43] <jepler> or maybe set it to be >= the filtered encoder max rate, so that nobody who turns on the filter can fall victim to it
[20:06:47] <jepler> new 5i20 firmwrare works.
[20:21:15] <seb_kuzminsky> that's awesome jepler
[20:22:23] <jepler> seb_kuzminsky: so you thought I should go ahead and merge all of jepler-proposed to master in hostmot2-firmware?
[20:25:29] <jepler> or should I stop deferring to you so much anyway and just do whatever I want?
[20:28:13] <seb_kuzminsky> you know that stuff way better than i (since you did all the work and i just watched from the sidelines), so you should probably just do what you think is right
[20:28:41] <seb_kuzminsky> but fwiw, i looked at proposed-master in hm2.git and it all looks fine to me
[20:29:47] <jepler> you might know more about whether I broke the packaging .. though it did make new packages for the newly supported cards so that's good
[20:29:50] <jepler> anyway, will merge
[20:33:08] <KGB-linuxcnc> 03Jeff Epler 05master f0dee4a 06hostmot2-firmware 10build.py build: allow the build to consider ise version * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=f0dee4a
[20:33:52] <KGB-linuxcnc> 05jepler/proposed-master 220b389 06hostmot2-firmware 04. branch deleted * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=220b389
[20:34:43] <jepler> you might be interested to know that "earthworm motifs" is an anagram of "hostmot firmware"
[20:36:19] <jepler> so's "haw, mom's retrofit"
[20:36:56] <jepler> and so's "whom it reformats"
[20:49:36] <seb_kuzminsky> he's finally lost it
[20:49:40] <seb_kuzminsky> we all knew it was coming
[20:49:41] <seb_kuzminsky> now it's here
[21:03:17] * jepler prefers to assume that seb_kuzminsky is talking about a flameout on the mailing list or something
[21:09:33] <pcw_home> Yeah you can trade-off minimum sample rate for timestam resolution
[21:09:35] <pcw_home> (maybe ~10 MHz would be good as a default)
[21:10:24] <pcw_home> (good downto ~160 hz )
[21:12:57] <jepler> "odroid squeezes plastic" -> ooze discredits Paul Esq or perhaps liquid depresses zoo cat
[21:13:38] * jepler contemplates whether an fpga can help compute anagrams faster. probably not.
[21:29:52] <skunkworks> My soul took a silken (my given name anagram)
[21:31:38] <jepler> ooh hey I can trigger the bug at will
[21:31:42] <jepler> hm2/hm2_7i90.0: (hal/drivers/mesa-hostmot2/encoder.c:999) uh-oh, encoder vel is broken with an edge
[21:38:40] <jepler> arduino program that regularly triggers the 'vel is broken with an edge' message:
http://emergent.unpythonic.net/files/sandbox/quad.ino
[21:44:45] <pcw_home> Its probably more noticeble on the 7I90/7I80 because the default non-muxed encoder sample rate is all the way up (100 MHz)
[21:46:35] <pcw_home> well maybe not, dont know if micges sample frequency setting stuff is there
[21:55:42] <skunkworks> I was seeing that error on the 7i80 when the ethernet comunication wasn't quite there yet.
[21:56:15] <skunkworks> I don't know if I had seen it in a while. (and I had tested reading quad from the printer port)
[21:56:44] <skunkworks> (and step/dir))
[22:29:35] <pcw_home> if you are runninh master you can set the encoder sample rate down and that should eliminate the errors
[23:12:06] -cameron.freenode.net:#linuxcnc-devel- [freenode-info] channel trolls and no channel staff around to help? please check with freenode support:
http://freenode.net/faq.shtml#gettinghelp