Back
[00:08:57] <micges> good night all
[02:23:03] <jepler> hm, seems I'm late to put emc2.4 "beta release" packages online. I hope the penalties for this are not severe..
[02:47:55] <jepler> well at least it looks like I can get 2.3.5 out tonight; that'll be a relief. and we've got seb's perfectly excellent buildbot packages..
[03:11:15] <jepler> man, watching rsync go upstream on dsl is like watching paint dry :-/
[03:11:25] <jepler> and to think I need to do hostmot2-firmware-0.5 after this
[03:57:41] <ries> jepler: are you at 256Kb/sec like me aswell?? :)
[12:09:13] <JT-QuadCore> JT-QuadCore is now known as jthornton
[12:39:13] <jepler> OK, *this morning* I'll get 2.3.5 out.
[13:05:18] <jepler> jepler has changed the topic to: EMC2 development --
http://linuxcnc.org/ | Latest release: EMC 2.3.5 | channel logged by logger_dev
[13:06:41] <micges_work> yay
[13:07:41] <alex_joni> yay
[13:07:53] <jthornton> yay
[13:11:10] <alex_joni> jepler: I'll do SF and linuxcnc.org announcements
[13:11:10] <alex_joni> (if you don't mind)
[13:11:11] <jepler> alex_joni: thank you
[13:11:11] <micges_work> I'll do wiki
[13:11:14] <micges_work> oh its done :P
[13:11:47] <CIA-2> EMC: 03jepler 07v2_3_branch * r672eb5c88887 10/ (3 files in 3 dirs): paper over a memory leak
[13:12:12] <CIA-2> EMC: 03jepler 07v2_3_branch * r2f587c2e3a33 10/ (VERSION src/configure): bump version after release
[13:12:43] <CIA-2> EMC: 03jepler 07v2_3_branch * r67098763cc77 10/ (VERSION debian/changelog src/configure): bump version number for release
[13:13:39] <CIA-2> EMC: 03jepler 07v2_3_branch * r56ffc174e68d 10/debian/changelog: note sf bug identifier for this fixed item
[13:17:50] <jepler> *facepalm*
[13:19:26] <jepler> oh well, if typing the wrong version number on the announcement is the worst mistake in there, I'm doing well
[13:22:53] <skunkworks_> Awesome! You guys are great!
[13:29:06] <alex_joni> jepler: I think you wanted to say something else: "Change since 2.3.5:
[13:29:58] <jepler> oops
[13:29:59] <jepler> oh well
[13:30:09] <jepler> I won't send out another correction just for that typo
[13:31:03] <ries> jepler: thanks for the releases!
[13:31:32] <jepler> ries: you're welcome
[13:34:46] <jepler> bbl
[14:26:33] <CIA-2> EMC: 03tissf 07master * r32ee3c842212 10/src/po/fr.po: French translation update
[14:43:56] <jepler> Any thoughts on cherry-picking this feature to v2.4_branch?
http://git.linuxcnc.org/gitweb?p=emc2.git;a=commitdiff;h=733af6086347d2e7aec29c87963a8e39cb89b768
[15:03:45] <alex_joni> looks good to me
[15:03:53] <alex_joni> bbl
[15:35:05] <seb_kuzminsky> jepler: should i merge 2.4 into master to get my recent packaging & recent-kernel-support commits into master? or do you (or someone else) manage merging from 2.4 to master?
[15:36:12] <SWPadnos> I think it's supposed to be the other way around: you make changes on master, and the release manager will merge (or let you merge) the changes into 2.4
[15:37:26] <seb_kuzminsky> hmm
[15:38:08] <SWPadnos> unless of course you've already pushed some changes to 2.4, in which case you should probably merge them into master too :)
[15:45:24] <cradek> SWPadnos: you've got it backwards
[15:46:00] <cradek> jepler's sent some workflow-related emails about this. seb did it right if he made the changes on 2.4 first.
[15:51:42] <seb_kuzminsky> i remember now, i asked jeff about this and the workflow he told me to use was: commit bugfixes on 2.4 and he'll merge them into master periodically:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-02-26.txt @ 16:42
[16:01:55] <SWPadnos> ok. I'll re-read those emails
[16:02:05] <SWPadnos> (before I start maintaining 2.4 :) )
[16:03:05] <SWPadnos> oh hmm. I probably missed that seb was talking about bugfixes
[16:18:54] <pcw_home> Hi sebastian
[16:23:41] <jepler> hi pcw_home
[16:26:07] <jepler> as far as I'm concerned, any competent person can merge v2.4_branch into master when it's useful to do so. on the other hand, it's not worth doing after each and every tiny commit, and I don't want each developer to feel he has to do that work
[16:27:06] <jepler> start at tip of v2.4_branch if you're sure the change should go into v2.4. start at the merge-base of v2.4_branch and master if you hope it might be able to go into 2.4 but don't know. start with the tip of master if you know it's not 2.4 material.
[16:34:45] <pcw_home> hi jepler
[16:52:45] <jepler> pcw_home: I'm trying to add a new "function" to hostmot2 (a random number generator based on ring oscillators--unrelated to motion control), but I'm stuck at the very basic step of trying to get my vhdl to drive a simple fixed value on the data bus when it's read. Is there a problem with the address I've chosen?
[16:52:50] <jepler> + constant RNGAddr : std_logic_vector(7 downto 0) := x"0f"; -- seems unused
[16:53:00] <jepler> + if A(15 downto 8) = RngAddr and Read = '1' then --
[16:53:00] <jepler> + ReadRNG <= '1';
[16:53:00] <jepler> + else
[16:53:00] <jepler> + ReadRNG <= '0';
[16:53:00] <jepler> + end if;
[16:54:05] <jepler> reader : process(clk,readdata,bits) begin
[16:54:05] <jepler> if rising_edge(clk) then
[16:54:05] <jepler> obus <= (others => 'Z');
[16:54:05] <jepler> if readdata = '1' then obus <= x"1248fedb"; end if;
[16:54:22] <jepler> I can put the whole thing online as diffs if you're willing to have a look
[16:56:09] <pcw_home> Take out the clk and it should work, HM2 reads are just combinatorial
[16:56:17] <seb_kuzminsky> hi pcw_home
[16:56:28] <pcw_home> Hi sebastian
[16:56:57] <jepler> so remove clk from process() and dump the if rising_edge ?
[16:57:13] <pcw_home> Yep
[16:57:28] <seb_kuzminsky> jepler: ok, i'll go ahead and merge 2.4 into master then, because clytle wants the request_firmware 2.6.29 fix i did to the hm2 driver the other night
[16:57:31] <jepler> thanks, I'll try it
[16:58:24] <jepler> pcw_home: so when I change it to objs <= bits; then bits had better be something that is latched?
[16:58:34] <jepler> er, obus <= bits;
[16:59:48] <pcw_home> Sebastian Ive been wondering if the watchdog should be more paranoid and have a 32 bit cookie
[16:59:50] <pcw_home> Jepler, read data needs to be synchronous (latched by busclock)
[16:59:52] <CIA-2> EMC: 03seb 07master * raa74c5431337 10/debian/update-dch-from-git: fix debian package version numbers on the buildbot
[16:59:53] <CIA-2> EMC: 03seb 07master * rd0645c13ed16 10/debian/update-dch-from-git: let the user specify the branch name
[16:59:54] <CIA-2> EMC: 03seb 07master * rdcb184f33e7c 10/debian/rules.in: Call the debhelper scripts in a better order
[16:59:54] <CIA-2> EMC: 03seb 07master * r5d9bf6e00801 10/debian/emc2.postinst: let the debhelper tools run ldconfig for us on install
[16:59:56] <CIA-2> EMC: 03seb 07master * rfd3c373771a6 10/debian/control.in: fix a lintian deprecation warning
[16:59:56] <CIA-2> EMC: 03seb 07master * r1a48491976d6 10/src/Makefile: remove src/config.{log,status} on "make clean"
[16:59:57] <CIA-2> EMC: 03seb 07master * rf6d12f9bb94b 10/src/Makefile: Dont install the INSTALL file
[16:59:58] <CIA-2> EMC: 03seb 07master * r426da18bd2d9 10/debian/changelog: Switch a changelog entry to cradek's real email address
[17:00:03] <CIA-2> EMC: 03seb 07master * r45e834a34752 10/debian/control.in: fix another annoying lintian warning
[17:00:05] <CIA-2> EMC: 03seb 07master * rf76f7ae53256 10/src/ (6 files in 2 dirs): Support kernels 2.6.29 and newer (ie Lucid Lynx)
[17:00:07] <CIA-2> EMC: 03seb 07master * r0deafa44c9ba 10/ (19 files in 6 dirs): Merge commit 'origin/v2.4_branch'
[17:00:11] <CIA-2> EMC: 03seb 07master * rb87503753dc0 10/configs/ (9 files in 3 dirs): turn off some stray execute bits on config files
[17:00:34] <jepler> seb_kuzminsky: that's fine, and thanks
[17:03:15] <jepler> seb_kuzminsky: do you want a copy of a bitfile that makes hostmot2 oops? I think it oopses because the idrom doesn't have an ioport module. it's not a useful bitfile, but maybe you're interested in fixing the oops anyway..
[17:03:35] <pcw_home> The read data source (that gets muxed either via tristates with Spartan2 or muxes with spartan3 ) needs to be synchronous
[17:06:06] <jepler> yay, now I can read my cookie value
[17:07:56] <SWPadnos> what did you get before? (same value all the time, "random" values, the read address ...)
[17:08:59] <jepler> SWPadnos: 0xffffffff
[17:09:06] <SWPadnos> cool.
[17:09:29] <SWPadnos> I wonder if I had a similar error in the FPGA code that interfaces with my analog boards
[17:09:47] <SWPadnos> since those would read 0xFFFFFFFF randomly
[17:12:23] <jepler> this was all the time (or at least almost all the time)
[17:12:51] <SWPadnos> I may have just been luckier
[17:13:38] <SWPadnos> I papered over the problem by assuming that I wouldn't get a -1 reading (it was a signed value) unless the previous reading had been close to 0, so the driver just ignored samples that "looked odd"
[17:14:07] <SWPadnos> icky, but it seemed to work OK (and is still running 24/7 AFAIK)
[17:15:52] <pcw_home> with the clk the read data would always be presented 1 clock after it was required
[17:15:53] <pcw_home> and "Z" = 0xFFFFFFFF being presented first
[17:33:27] <jepler> cool, now I have random-looking numbers from my ring oscillators.
http://pastebin.ca/1821507
[17:35:47] <skunkworks_> jepler: what are you thinking of doing with that?
[17:35:51] <jepler> or varying numbers anyway
[17:36:05] <jepler> skunkworks_: it's a mount everest sort of project: it (the idea) was there
[17:36:25] <skunkworks_> heh - been there.
[17:40:49] <seb_kuzminsky> jepler: yes i'd like that bitfile
[17:41:22] <seb_kuzminsky> then i'll add that test case to the hm2-idrom tests
[17:42:07] <jepler> seb_kuzminsky: OK, I'll e-mail you the bitfile probably later today
[17:43:25] <pcw_home> bbl
[17:43:53] <seb_kuzminsky> kthx
[17:45:22] <seb_kuzminsky> jepler: when you removed the hm2 firmware source from the emc2 tree, that included the regmap file, which is the only documentation of the firmware/driver interface
[17:45:27] <seb_kuzminsky> is it in the new firmware repo?
[17:45:39] <seb_kuzminsky> should we maybe have a copy in the emc2 tree for convenience?
[17:45:47] <jepler> yes, and sure
[17:46:21] <seb_kuzminsky> i'll revive it from history and put it in... mesa-hostmot2/doc i guess
[18:00:36] <CIA-2> EMC: 03seb 07master * r6af83f29b26d 10/src/hal/drivers/mesa-hostmot2/doc/regmap: revive the firmware/driver interface documentation
[18:37:56] <jepler> how ironic that so soon after removing them, I want some userspace programs for interacting with the 5i20 :-/
[18:39:22] <SWPadnos> heh
[19:21:47] <aystarik> code, seq = gcode.parse(args[0], Canon(), 'G20 G17 G64', '')
[19:21:48] <aystarik> TypeError: function takes exactly 14 arguments (7 given)
[19:21:48] <aystarik> where this error is coming from?
[19:22:39] <micges> aystarik: what you trying to do?
[19:22:53] <jepler> some method of Canon function being called inside gcodemodule
[19:23:05] <jepler> s/function//
[19:23:34] <aystarik> trying to use gcode module... something have changed and old Canon is not compatible any longer... :(
[19:23:59] <aystarik> jepler: this is gdepth.py
[19:24:12] <micges> aystarik: some method about tool table (incompatibile after TLO all axes merge)
[19:24:27] <aystarik> thanks
[19:32:12] <jepler> yeah, it seems likely that it's actually referring to the number of values returned by the get_tool method..
[19:40:28] <aystarik> yep, copy of long return string from current interpreter.py helped
[20:59:37] <CIA-2> EMC: 03seb 07v2.4_branch * r00e0c9ee3b6d 10/src/hal/drivers/mesa-hostmot2/doc/regmap: revive the firmware/driver interface documentation