Back
[00:25:50] <zq> jepler: what does your fpga toolchain consist of?
[02:00:57] <NTU> just finished writing a bash script that compiles the kernel, RTAI, and linuxcnc for you
[02:02:02] <NTU> testing big generic rtai kernel right now before pushing
[03:48:57] <NTU> few minor bugs to work out, no biggy.
[03:49:19] <NTU> will look at it the next few days. idea is to have generic 3.14 RTAI support
[04:53:58] <automata> micges-dev: for hostmot2, is there any plan to support pktUart ?
[04:55:57] <micges-dev> probably yes but don't scheduled yet
[04:56:37] <micges-dev> let me see details..
[05:01:48] <micges-dev> automata: internals are easy, I wonder how hal interface should work for it
[07:14:30] <jepler> zq:
http://git.linuxcnc.org/gitweb?p=hostmot2-firmware.git;a=summary is the source; seb_kuzminsky maintains a buildbot which builds packages from it.
[07:14:57] <jepler> zq: xilinx webpack is required -- I think version 13 and either version 10 or 9 is required to build all the firmwares
[08:21:10] <mozmck> jepler: what does that mean? you need two versions of webpack to build all the firmware?
[08:22:33] <jepler> mozmck: xilinx supports different FPGA chips in different versions of webpack
[08:22:49] <jepler> mozmck: so for instance, version 9 is too old to have support for spartan6 devices
[08:22:56] <jepler> while version 13 is so new it drops support for spartan2 devices
[08:24:05] <jepler> luckily, different version numbers are installable at the same time
[08:24:20] <mozmck> ah, I see.
[08:24:28] <mozmck> I just installed 14.7
[08:25:05] <mozmck> I think I still have a working install of 10.1 too
[08:26:32] <jepler> in cards.py you would have to change the iseversions = to include 14
[08:26:46] <jepler> .. for whichever chipse version 14 supports
[08:26:56] <jepler> s/chipse/chips/
[08:27:37] <mozmck> ok, I need to load up some firmware and start learning hdl
[08:27:58] <jepler> if you want just one or a few bitfiles, you probably want to invoke build directoy, like ./build.py i90epp SVST8_4_72
[08:29:03] <skunkworks> I thought pcw said there are issues with some newer versions..
[08:29:25] <jepler> skunkworks: beyond them dropping support for some older family chips?
[08:29:30] <mozmck> ok, I'll look at it in all my spare time :P
[08:29:39] <jepler> mozmck: ah the spare time. hooray for that
[08:30:09] <mozmck> heh, it's getting less and less these days.
[08:31:57] <skunkworks> yes.. but maybe I am not remembering right
[08:55:57] <pcw_home> I think everything after 13.1 or so is OK (for SP3 and >)
[08:56:13] <pcw_home> and >
[09:02:32] <pcw_home> Thought more about the 0 timestamp delta issue and
[09:02:33] <pcw_home> 1. its a correct representation of the encoder signals
[09:02:35] <pcw_home> 2. if you want to calculate velocity you should use 1/2 timestamp rate as time between edges
[09:02:36] <pcw_home> 3. you probably want to just skip velocity calculations since it most likely represents electrical noise or vibration
[09:03:03] <pcw_home> 1/2 timestamp period I mean
[09:20:25] <jepler> pcw_home: is pins-per-connector something that is not in idromv3?
[09:24:40] <pcw_home> there's PortWidth which is the same
[09:45:58] <KGB-linuxcnc> 03Jeff Epler 05master 13bce0f 06hostmot2-firmware 10idrom_tools.vhd 10pinmaker.vhd.in 10xmlrom.vhd.in improve data in .PIN, .xml files * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=13bce0f
[10:19:46] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master de8a3e2 06linuxcnc 10docs/man/man9/hostmot2.9 10src/hal/drivers/mesa-hostmot2/hm2_pci.c Merge remote-tracking branch 'origin/2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=de8a3e2
[10:29:00] <cradek> duel boot
[10:32:40] <seb_kuzminsky> is that when you install another operating system on the same hard drive and it overwrites the mbr so you can boot the first os?
[11:01:58] <jepler> seb_kuzminsky: did you see I have an arduino program that, driving hostmot2 encoder inputs, triggers the "broken with an edge" message several times a minute?
[11:04:22] <jepler> seb_kuzminsky:
http://emergent.unpythonic.net/files/sandbox/quad.ino
[11:04:58] <jepler> I think I was running with a 500us servo period; the longer delay may need to be modified to cause it with a 1ms servo period
[11:05:11] <cradek> wow
[11:05:21] <seb_kuzminsky> i saw it
[11:05:29] <seb_kuzminsky> very cool use of an arduino
[11:06:11] <seb_kuzminsky> i guess someone should fix that bug in the hm2 encoder driver now
[11:06:21] <jepler> possibly so
[11:06:32] <jepler> I think the best solution is to hold the encoder velocity estimate in that cycle
[11:06:54] <jepler> which I think mostly consists of just deleting the message
[11:07:25] <seb_kuzminsky> heh
[11:14:59] <NTU> huh.. so RTAI determines 32-bit or 64-bit from the kernel config in the kernel source directory, not uname -m..
[11:15:27] <NTU> anyone experienced enough with autotools to change this?
[11:15:58] <NTU> cd RTAI && git grep CONFIG_X86_64
[11:16:37] <NTU> main files are configure.ac and various GNUmakefile.am
[11:16:42] <pcw_home> Yeah since getting that error means you have a 1000 to 1 velocity change in one servo period (at 1 KHz) it is probably best to ignore
[12:08:18] <jepler> NTU: you have to delete this and replace it with the correct code
[12:08:18] <jepler> AC_MSG_CHECKING([for kernel architecture])
[12:08:19] <jepler> KERNEL_ARCH="`uname -m`"
[12:08:19] <jepler> AC_MSG_RESULT([$KERNEL_ARCH])
[12:09:06] <jepler> but do you know the steps to find the correct value?
[12:11:11] <jepler> AS_IF([grep ^CONFIG_X86_64 $kconfig], [KERNEL_ARCH=x86_64], [grep ...], ..., [AC_MSG_ERROR([Cannot guess KERNEL_ARCH from config])])
[12:11:14] <jepler> something like this I guess
[12:12:00] <cradek> what's the wrong behavior you're trying to fix?
[12:12:03] <jepler> probably grep -q
[12:12:20] <cradek> I don't understand
[12:12:23] <jepler> cradek: it builds rtai to match the running system (uname -m) not the kernel
[12:12:29] <jepler> not the kernel you pointed configure at
[12:12:39] <cradek> oh ok
[12:12:45] <jepler> it could be you want to build rtai for arm, but your system has `uname -m` -> x86_64
[12:12:57] <jepler> until I looked at the source, I thought he was indicating the opposite
[12:15:01] <jepler> NTU: documentation of AS_IF
http://www.gnu.org/software/autoconf/manual/autoconf.html#index-AS_005fIF-1573
[13:39:33] <micges-dev> jepler: should encoder fix go to 2.6?
[13:49:39] <micges-dev> seb_kuzminsky: propose of encoder fix:
http://pastebin.com/6Wmtye4N
[14:04:01] <seb_kuzminsky> micges-dev: seems sane to me
[14:04:28] <micges-dev> seb_kuzminsky: ok to 2.6 ?
[14:04:29] <seb_kuzminsky> and it matches my understanding of the behavior pcw_home and jepler want
[14:05:27] <seb_kuzminsky> yes please. i'd like jepler and/or pcw_home to sign off on it (figuratively, not with a Signed-Off-By tag!), then please push to 2.6
[14:06:22] <micges-dev> ok
[14:10:05] <pcw_home> looks OK to me
[14:31:03] <NTU> thanks jepler ill give that a shot later on tonigt
[14:34:15] <NTU> the problem is that hal_32.c and *_32.h headers in RTAI are included instead of hal-64.c w/ 64-bit headers if /usr/src/linux/.config is 32-bit
[14:59:55] <seb_kuzminsky> hey Roguish
[15:00:28] <seb_kuzminsky> can you try your tabby ini file with the tip of the 2.6 branch? i think the bug you reported is fixed
[15:01:14] <Roguish> so, i need to do an update? right?
[15:02:11] <seb_kuzminsky> yeah
[15:02:32] <seb_kuzminsky> are you building your own linuxcnc from the git repo, or are you installing debian packages from the buildbot, or are you installing debian packages from www.linuxcnc.org?
[15:04:03] <Roguish> well, i started with the released hybrid.iso
[15:04:27] <Roguish> the executable is in /usr/bin/linuxcnc
[15:04:52] <Roguish> i did a git to get the source.
[15:05:11] <Roguish> but i don't recall if i compiled it
[15:05:52] <seb_kuzminsky> ok
[15:06:46] <Roguish> so, i think if I update with git and then compile, that should get the latest? right?
[15:06:47] <seb_kuzminsky> the the fix is only available via git or the buildbot, not from the normal released packages that the wheezy live+install image accesses by default
[15:06:54] <seb_kuzminsky> yes
[15:07:19] <seb_kuzminsky> you need to update your git clone with "git fetch origin", then check out the 2.6 branch with "git checkout 2.6", the build as usual from there
[15:07:34] <seb_kuzminsky> there are instructions on the wiki for how to build if you're note familiar with the process
[15:16:22] <KGB-linuxcnc> 03Michael Geszkiewicz 052.6 b38797a 06linuxcnc 10src/hal/drivers/mesa-hostmot2/encoder.c hm2: fix long standing encoder velocity estimation error (thanks pcw and jepler) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b38797a
[15:18:51] <seb_kuzminsky> thanks micges-dev
[15:19:25] <micges-dev> welcome
[15:20:15] <cradek> yay!
[15:24:09] <seb_kuzminsky> it's not every day that a 4.5-year-old bug gets fixed
[15:24:34] <seb_kuzminsky> embarrassing that the bug was just a miunderstanding on my part about signal timing :-/
[15:25:47] <jepler> seb_kuzminsky: as software gets older, the mean age of bugs at the time they are fixed also gets larger
[15:27:03] <micges-dev> seb_kuzminsky: you fixed it then, I was then simply not able to give enough data to locate source of divide by 0
[15:31:29] <seb_kuzminsky> micges-dev: are you coming to the hackfest in houston in october?
[15:31:46] <micges-dev> no
[15:32:30] <seb_kuzminsky> bit of a long haul for you
[15:32:32] <seb_kuzminsky> maybe another time
[15:33:08] <micges-dev> yeah few km too far ;)
[15:41:50] <seb_kuzminsky> Roguish: NOO not that button!!
[16:41:59] <micges-dev> jepler: verification time: 1. with your read_page() patch, 2. without it:
http://pastebin.com/Civ1bVtZ
[17:24:47] <skunkworks_> cradek: at 5ipm Y is doing this (audible..)
http://imagebin.org/319386
[17:24:54] <skunkworks_> it happens every rotation of the servo...
[17:25:32] <skunkworks_> (yah - that is only a little over .0001 of error.. :))
[17:26:09] <skunkworks_> it has groaned - since the tuning - but today it is worse..
[17:26:50] <skunkworks_> (server nor amp are getting warm...)
[17:41:18] <skunkworks_> hmm - I wiggled the Y axis brake and it went away....
[17:46:29] <skunkworks_> must have been dragging just enough to cause a groan..
[17:48:26] <seb_kuzminsky> so it works better if you dont apply the brake? :-P
[17:48:34] <skunkworks_> heh
[17:48:37] <skunkworks_> it is loose...
[17:48:46] <skunkworks_> I can wiggle it around and make it groan
[17:48:56] <skunkworks_> maybe it needs a little oil.. :)
[17:49:34] <cradek> interesting
[17:49:44] <cradek> I touched it last, so it's my fault
[17:50:02] <seb_kuzminsky> 10 lashes with a cat5 cable
[17:55:50] <cradek> https://www.youtube.com/watch?v=4nCIzPuLYJA
[17:56:14] <skunkworks_> cradek: well - yah!
[17:59:00] <skunkworks_> dad thinks it isn't adjusted right - it should center itself when deactivated
[17:59:08] <skunkworks_> (shouldn't drag)
[18:00:34] <cradek> that sure sounds like a reasonable position to take
[18:01:06] <skunkworks_> he is usually right
[18:01:19] <skunkworks_> the machine has been running great
[18:02:35] <skunkworks_> I think (knock on wood) the latency issue with the motherboards and the latest live image was the audio.. I disabled it and so far it has been showing good latency (about 30min so far)
[18:03:07] <cradek> are you reinstalling it?
[18:05:07] <skunkworks_> test machine... dad had bought a few of the motherboards in the k&t for extras
[18:05:30] <skunkworks_> (just booting off of usb image)
[18:05:36] <cradek> smart
[18:06:40] <skunkworks_> well - just looked and now the latency went to 70us... (guess I didn't knock on wood
[18:06:42] <skunkworks_> )
[18:06:54] <skunkworks_> going to let it run some more
[19:00:08] <jepler> micges-dev: cool!
[19:03:14] <micges-dev> jepler: most of your pull request is in repo
[19:04:59] <PCW> skunkworks_ I have added some stepgen configs for the 7I80 with DPLL and will put them up a bit later today
[19:11:58] <skunkworks_> pcw, cool!
[19:13:30] <jepler> micges-dev: not spi support itself?
[19:15:37] <micges-dev> not yet, later today
[19:20:55] <jepler> micges-dev: my branch updated on your master branch
[19:22:38] <jepler> micges-dev: if you don't want to apply a form of the last commit in my branch, I don't blame you
[19:23:08] <jepler> also I am sure my first commit doesn't build on windows, since there's no spidev, no ioctl, etc there. perhaps you have a windows machine where you're able to test.
[19:23:41] <micges-dev> jepler: create pr with only two commits with spi support (WIP and layer violations) and I'll merge it
[19:24:31] <PCW> 6i24 works.. jolly good!
[19:24:44] <micges-dev> jepler: no it's rather I can't fully follow your code
[19:26:20] <jepler> micges-dev: I updated my original pull request with just the one commit
https://github.com/micges/mesaflash/pull/3/ no layer violations
[19:26:53] <jepler> micges-dev: I am happy to discuss the code with you, if you have specific questions or specific revision suggestions.
[19:27:13] <jepler> I wasn't sure I understood the structure of mesaflash well enough to add this correctly
[19:27:44] <jepler> .. I was unsure of the division between spi_boards and spilbp, for instance
[19:28:02] <micges-dev> you fit in good
[19:30:16] <micges-dev> spilbp was for hold all protocol details but that idea fade away
[19:30:41] <micges-dev> along with ethernet and lbp16 modifications
[19:32:12] <jepler> I see, but only one thing communicates with the same bit stream as spi
[19:34:11] * jepler realizes he was just running mesaflash and linuxcnc at the same time
[19:34:19] <jepler> .. and nothing was overtly broken by doing that!?
[19:36:06] <jepler> micges-dev: thanks!
[19:36:13] <micges-dev> jepler: I don't understand sentence with 'same stream as spi'
[19:39:15] <PCW> you can get away with running linuxcnc and mesaflash at the same time (sometimes, dont try writing the flash EEPROM for example)
[19:40:09] <jepler> micges-dev: I know that ethernet and serial can use the same byte stream for communication (lbp16), but today only spi uses its byte (word) stream
[19:40:20] <jepler> that's all
[19:40:29] <jepler> it's not a problem to solve
[19:40:45] <micges-dev> ahh
[19:42:03] <PCW> Ether and serial are somewhat fancier protocols since they use a processor
[19:42:04] <PCW> (they share most of the same code)
[19:43:57] <jepler> and is spi different because a processor doesn't fit in the fpga, or because the timing requirements of spi don't lend themselves to an embedded processor?
[19:44:36] <micges-dev> jepler: yeah it was added as a framework for spi code, I wasn't giving it's design much attention then
[20:07:16] <micges-dev> 'nite
[20:11:17] <PCW> I guess mainly because with SPI (and EPP) you have such a low level hardware interface that a processor doesn't add much
[20:11:19] <PCW> and Ethernet for example would be a lot harder to do without a processor (and more FPGA resources)
[20:13:19] <PCW> Serial is somewhere in between, but its was easy to just take the Ethernet code and replace the MAC with a UART, get rid of the UDP
[20:13:21] <PCW> wrapper and other Ethernet support (like ARP) and add CRC checking