#linuxcnc-devel | Logs for 2014-04-19

[00:00:04] <KGB-linuxcnc> 03Sebastian Kuzminsky 05v2.5_branch 9646f24 06linuxcnc 10(13 files in 5 dirs) tests: add some tests of the edge component * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9646f24
[00:00:04] <KGB-linuxcnc> 03Sebastian Kuzminsky 05v2.5_branch 8b5b7b9 06linuxcnc 10src/hal/components/edge.comp edge.comp: fix .out-invert pin on first invocation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8b5b7b9
[00:00:04] <KGB-linuxcnc> 03Sebastian Kuzminsky 05v2.5_branch c7b617d 06linuxcnc 10src/hal/components/edge.comp edge.comp: fix output pulse width * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c7b617d
[00:19:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 2111b4e 06linuxcnc 10(10 files in 4 dirs) Merge remote-tracking branch 'origin/v2.5_branch' into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2111b4e
[00:19:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 a67be0a 06linuxcnc 10(6 files in 2 dirs) tests: add tests of the new "both" mode of edge.comp * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a67be0a
[00:30:37] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 892bbbe 06linuxcnc Merge remote-tracking branch 'origin/2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=892bbbe
[00:30:38] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 822a3ab 06linuxcnc 10VERSION 10scripts/githelper.sh bump version number of master to 2.7.0-pre0 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=822a3ab
[00:30:38] <KGB-linuxcnc> 03Sebastian Kuzminsky 05signed tags 651ed63 06linuxcnc 03v2.7.0-pre0 LinuxCNC 2.7.0-pre0 (tagged commit: 822a3ab) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=651ed63
[00:37:56] <seb_kuzminsky> whew
[00:38:45] <seb_kuzminsky> some people have to wash their hands compulsively, i have to merge upwards
[01:18:30] <linuxcnc-build> build #175 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/175 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:08:16] <linuxcnc-build> build #176 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/176 blamelist: Chris Radek <chris@timeguy.com>, Chris Morley <chrisinnanaimo@hotmail.com>, elson <elson@pico-systems.com>, Sebastian Kuzminsky <seb@highlab.com>, Frank Tkalcevic
[03:08:16] <linuxcnc-build> <ftkalcevic@users.sf.net>
[04:45:10] <linuxcnc-build> build #177 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/177 blamelist: Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Chris Morley <chrisinnanaimo@hotmail.com>, elson <elson@pico-systems.com>, Bence Kovacs
[04:45:11] <linuxcnc-build> <bence.kovacs@generalmechatronics.com>, Frank Tkalcevic <ftkalcevic@users.sf.net>, Sebastian Kuzminsky <seb@highlab.com>
[14:36:43] <asah> pcw_home: I am still having issues with my 7i80. I can get ssi reading fine, but the PWMgens do not seem to be making it out to the 7i39
[14:37:08] <asah> preempt kernel happy, pushed firmware to the 7i80, it reads nicely the ssi encoder.
[15:03:11] <pcw_home> Thats pretty strange (same bitfile) could be a hm2_eth bug
[15:03:34] <pcw_home> not same bitfile but same pinout file I mean
[15:08:44] <asah> right. I am using the same hal stuff.
[15:08:56] <asah> just changing to hm2_eth
[15:08:57] <asah> etc.
[15:12:27] <pcw_home> This is probably the first time the TPPWM has been tested with hm2_eth
[15:13:31] <pcw_home> does the log say anything interesting? (no dmesg anymore)
[15:14:21] <asah> how do I access log?
[15:17:39] <asah> syslog?
[15:18:29] <asah> “unexpected realtime delay on RT thread 1"
[15:19:41] <pcw_home> var/log/linuxcnc.log
[15:20:04] <pcw_home> what servo thread rate
[15:20:09] <pcw_home> ?
[15:20:57] <pcw_home> you have to enable logging in UBC (theres a script)
[15:21:48] <asah> 1khz
[15:21:56] <asah> not enabled logging
[15:22:02] <asah> in ubc rather
[15:23:34] <pcw_home> 1 KHz should be fine but you have to make sure the interface you are using can have no other traffic/attemped traffic
[15:23:53] <asah> should be only for this
[15:24:17] <pcw_home> manual config IPV4 only
[15:24:25] <asah> right
[15:25:08] <asah> looks like gpio pin 20 (labeled as PWM enable) is false
[15:25:24] <asah> hm2_7i80.0.gpio.020.in
[15:25:48] <pcw_home> thats correct if enabled (active low enables)
[15:25:56] <asah> ok
[15:26:11] <pcw_home> no PWM?
[15:26:42] <pcw_home> maybe the log can shed some light
[15:27:15] <asah> getting pretty high phase-error-us, lots of jitter in that signal.
[15:27:23] <asah> but no pwm
[15:28:28] <pcw_home> Yes the Ethernet jitter (and preemt-rt jitter) is much worse but the DPLL shoud be able to improve that a lot
[15:28:55] <asah> ok, but PWM should still work
[15:28:59] <asah> regardless
[15:29:03] <pcw_home> Yes
[15:29:26] <pcw_home> I think the log needs to be read
[15:29:40] <asah> ok, the linuxcnc one or the ubc log?
[15:29:54] <pcw_home> linuxcnc.log
[15:29:59] <asah> ok.
[15:30:03] <asah> its pretty bland.
[15:30:20] <asah> shows its discovered the device.
[15:30:26] <asah> shows all the pins
[15:30:34] <asah> Ill email it to you.
[15:30:38] <pcw_home> you may have to turn on debugging
[15:30:57] <pcw_home> so it found the TPPWMs?
[15:31:12] <asah> they show up as PWMGen:0
[15:31:18] <asah> 3-Phase PWMGen: 2
[15:31:23] <asah> clock_frequence.....
[15:33:30] <asah> in your inbox is a snippet of start to finish.
[15:33:50] <asah> I have debug_modules=1
[15:33:55] <asah> in hostmot2
[15:36:10] <micges> pcw_home: send me bitfile, I'll test it
[15:36:40] <pcw_home> log looks OK to me
[15:38:21] <pcw_home> micges unfortunately its a 7i80hd-25 bitfile (And I dont think you have a -25)
[15:38:47] <asah> oscilliscope says no pwm coming out of motor UVW pins
[15:38:49] <micges> oh
[15:38:54] <micges> ok
[15:39:00] <pcw_home> but there should be other tppwm bitfiles, let me take a look
[15:39:03] <cradek> memleak: question about 3.4.55-rtai-2: every time I type a key or move the mouse (both keyboard and mouse are ps2 type) I get several lines in the system log that look like: evbug: Event. Dev: input0, Type: 1, Code: 28, Value: 1
[15:39:11] <cradek> well that wasn't a question
[15:39:17] <cradek> the question is do you know how to make it stop?
[15:39:29] <asah> what does tp mean in tppwm ?
[15:39:44] <pcw_home> three phase
[15:39:51] <asah> right.
[15:39:54] <asah> =)
[15:40:42] <pcw_home> micges: 7i80hd_16_svsttp6_6_7i39.bit should do to test
[15:40:51] <micges> but besides jitter tppwm should work like in hm2_pci
[15:41:31] <micges> ok
[15:43:00] <pcw_home> You should be able to check if the tppwms outputs are working fairly easily
[15:44:14] <asah> I do get a couble of messages right when I halrun: rtapi:0 stopped msgd:0 stopped
[15:44:22] <asah> but ssi feedback works fine
[15:44:59] <pcw_home> (watch the correct GPIO bit)
[15:45:01] <pcw_home> If enabled (and default 0 input) the associated GPIO pins should be randomly high/low
[15:45:40] <asah> so in this case gpio pin 21?
[15:45:58] <pcw_home> (random sampling of high frequency 50% duty cycle signal at servo thread rate)
[15:46:12] <micges> ok
[15:46:21] <pcw_home> yeah any the A,B,C outputs
[15:50:35] <asah> show pin hm2_7i80.0.gpio.021 always is false
[15:51:47] <asah> same with 022, and 023
[15:54:41] <asah> is the ubc logging thing a linuxcnc thing or a kernel dev thing?
[15:56:30] <pcw_home> dont know, never used it
[15:56:45] <pcw_home> is the channel 0 or 1
[15:56:51] <pcw_home> is this
[15:56:57] <asah> I am using channel 1
[15:57:50] <pcw_home> when you have linuxcnc running can you read hm2 register 0x4604?
[15:58:06] <pcw_home> (I think mesaflash can do that)
[15:59:25] <asah> —rpo ?
[16:02:21] <asah> if I do it while its running I get no 7i80 board found
[16:02:43] <pcw_home> it should work
[16:02:47] <asah> mesaflash —device 7i80 —addr —rpo 0x4604
[16:04:41] <asah> when its not running, result is FFFFFFFD
[16:04:49] <asah> (when linuxcnc is not running)
[16:05:49] <pcw_home> weird linuxcnc running or not should make no difference
[16:08:01] <asah> seems to.
[16:08:04] <asah> def repeatable
[16:09:25] <pcw_home> can you ping the 7i80 with linuxcnc running?
[16:09:46] <asah> yes
[16:10:58] <pcw_home> Hmm maybe something in mesaflash changed
[16:11:46] <micges> I don't think so
[16:11:48] <asah> is there another way to read that reg
[16:11:49] <asah> ?
[16:12:11] <pcw_home> not sure how mesaflash could even detect that another device was accessing the 7I80
[16:13:37] <pcw_home> anyway looks like the tppwm is enabled (LSB is '1')
[16:14:48] <asah> pretty weird.
[16:15:13] <pcw_home> I would like to look at 0x1104 but its likely cleared by linuxcnc as it exits (and by the watchdog)
[16:15:44] <pcw_home> I would try reading 0x1104 in linuxcnc (via raw-read)
[16:17:33] <asah> ok, have raw mode enabled.
[16:18:14] <asah> like dump_state ?
[16:19:03] <pcw_home> see raw_mode in the hostmot2 man page
[16:19:07] <asah> setp raw.read_address 0x1104
[16:20:38] <pcw_home> then just show/watch the read_data pin
[16:21:08] <pcw_home> and hope its not in decimal
[16:21:19] <asah> all zeros
[16:21:47] <pcw_home> ok that would be why PWM does not work
[16:22:19] <cradek> memleak: [blacklist evbug fixes it]
[16:22:33] <cradek> I don't know what evbug's supposed to be
[16:22:36] <pcw_home> well wait a second the SSI cannot work with all 0 DDR
[16:22:52] <asah> pcw_home: how to fix?
[16:23:00] <asah> SSI def working
[16:23:16] <pcw_home> still?
[16:23:19] <asah> yes
[16:23:35] <asah> just checked 0x4604 and got FFFFFFFD
[16:23:44] <asah> so I think my process is correct
[16:23:49] <asah> for reading registers
[16:24:01] <pcw_home> try 0x0100
[16:24:28] <asah> 55AACAFE
[16:25:32] <micges> pcw_home: here I can access 7i80 by mf while lcnc is running, like I always could
[16:27:30] <pcw_home> well 0x1104 cannot be all 0s and have ssi working (no outputs would work)
[16:27:45] <pcw_home> so something is funny
[16:27:54] <cradek> seb_kuzminsky: is it on purpose that there's no dists/wheezy/2.6 nonsim?
[16:27:59] <asah> should I reflash?
[16:28:31] <pcw_home> no
[16:28:52] <pcw_home> bitfiles are CRC checked by the FPGA
[16:29:02] <asah> ok.
[16:31:05] <pcw_home> sorry not 0x1104 but 0x1100
[16:31:54] <pcw_home> (got confused by TPPWMGEN1 vs IOport 0)
[16:32:20] <pcw_home> 0x00000000 is correct to 0x1104 (second connector)
[16:33:29] <asah> 00F40F40
[16:33:48] <asah> ah. right. nope first connector
[16:36:08] <pcw_home> GPIO 23,22,21,20,18,11,10,9,8,6 outputs
[16:48:00] <asah> ?
[16:52:50] <memleak> cradek, sorry, i was working on rtai, didnt see your message until now. i've never seen that kind of output before
[16:54:12] <memleak> evbug i would assume would be either xf86-input-evdev or CONFIG_INPUT_EVDEV in kernel
[16:54:22] <memleak> not sure which one it correlates to
[16:54:36] <pcw_home> might be a hm2_eth driver bug and might be a firmware bug
[16:54:37] <pcw_home> The DDR and tppwm enable seem correct, you might try writing
[16:54:39] <pcw_home> 0x20080200 to 0x4504 (set all PWMs on channel 1 to 50%)
[16:58:56] <asah> no effect
[17:00:01] <asah> if I read the data back from 0x4504 I get FFFFFFFF
[17:00:38] <memleak> PS/2 devices in X use the xf86-input-mouse and xf86-input-keyboard drivers i believe, so as far as evdev goes... thats actually really strange.. it should be using the CONFIG_KEYBOARD_ATKBD (AT style keyboard driver) and or CONFIG_SERIO_I8042 (standard AT style keyboard driver / PS/2 serial driver)
[17:02:12] <memleak> looking at kernel kconfig, CONFIG_KEYBOARD_ATKBD automatically selects CONFIG_SERIO_I8042 so they work hand-in-hand, evdev / evbug doesnt make sense to me..
[17:02:38] <memleak> unless ATKBD / I8042 use evbug.. i have no idea actually. i never use PS/2
[17:03:19] <memleak> by "use evbug" i mean use evbug as a report service, kind of like printk
[17:06:37] <pcw_home> do you get any PWM output?
[17:06:39] <pcw_home> "if I read the data back from 0x4504 I get FFFFFFFF" thats expected since the PWM register is not readable
[17:08:36] <pcw_home> bbl
[17:09:20] <pcw_home> I'll check tppwm/7I80 firmware on Monday
[17:10:21] <asah> ok… thanks peter.
[17:23:10] <memleak> does linuxcnc use RTAI watchdog support, RTDM serial driver or real-time userspace interrupts?
[17:23:35] <memleak> from what i see i notice no change when i have all options disabled.
[17:24:49] <micges> memleak: no no and no
[17:25:02] <memleak> heh thanks micges
[17:25:31] <memleak> how about RT IPCs, fifos, shm?
[17:26:32] <micges> now I have no idea ;)
[17:26:53] <memleak> ok ill leave them as modules then to be saf, thanks
[17:26:55] <memleak> *safe
[17:27:16] <memleak> hey micges what part of linuxcnc do you work on?
[17:27:48] <micges> lately hostmot2 hal driver
[17:28:58] <micges> but I touched many parts of lcnc
[17:30:18] <cradek> memleak: I saw bug reports relating to it going back years, so I don't think it's your problem -- sorry, I should have googled first.
[17:30:30] <micges> memleak: I didn't touched rtapi
[18:10:06] <cradek> I'm trying to use pncconf to set up the 5i25 to run my previously-parport-driven mill
[18:10:34] <cradek> pncconf seems like it detected the 5i25
[18:10:46] <cradek> but none of the "firmware" choices match the label on mine
[18:11:03] <cradek> I actually just want to have it in the smart parport mode
[18:11:44] <cradek> aha looks like I want prob_rfx2
[18:13:13] <cradek> I'm not seeing 5i25 firmwares in http://linuxcnc.org/dists/wheezy/base/binary-all/
[18:13:56] <cradek> (my label says 7i74x2.bit -- but I don't have any of those)
[18:14:47] <micges> 5i25 have bitfile in flash onboard
[18:15:13] <cradek> but I need to change it
[18:15:26] <micges> use mesaflash for it
[18:15:27] <cradek> I thought we were going to package up the fimware choices and the flashing utility
[18:15:50] <cradek> mesaflash didn't install as part of 2.6
[18:16:05] <cradek> is there still packaging work to be done?
[18:16:14] <micges> yes we are
[18:16:32] <micges> mesaflash isn't ready yet
[18:16:37] <cradek> ah ok
[18:16:41] <cradek> can I help?
[18:17:35] <micges> not really, few bugs locally and seb created /debian fix for me
[18:18:11] <cradek> I can at least help test then, when you are ready - I now have a wheezy+rtai machine for testing 5i25/pncconf/2.6
[18:18:18] <cradek> thanks for the information
[18:18:27] <micges> I don;t know about firmware packaging progress
[18:18:44] <micges> you can test anytime: https://github.com/micges/mesaflash
[18:22:50] <micges> cradek: any feedback from wheezy could be usefull, I don't know anyone using mf on it
[18:40:22] <memleak> micges, hostmot2? perfect! i have a question for you! what firmware files are required by mesaflash / pncconf for the FPGA? is it the .xml .pin or ?
[18:40:51] <memleak> and as for the location of the files, do they go in /lib/firmware/hm2 specifically?
[18:41:29] <micges> yes they all should go there
[18:42:05] <micges> mesaflash use only bit files (firmware) and can generate pin file (firmware info)
[18:42:21] <micges> pncconf use xml files
[18:42:38] <memleak> ok so everything not just bit goes in /lib/firmware/hm2
[18:43:00] <memleak> is it /lib/firmware/hm2/<your FPGA> or do they just float loosely in hm2 directory?
[18:43:25] <memleak> i.e. /lib/firmware/hm2/5i25/
[18:43:33] <micges> each board have subdir
[18:43:59] <memleak> ok great thanks!
[18:44:37] <memleak> so the .pin files aren't really used for anything?
[18:45:01] <memleak> if bit is the actual firmware binary and pncconf use xmls..
[18:45:48] <micges> they are information only
[18:45:56] <memleak> information for what?
[18:46:14] <memleak> humans?
[18:46:29] <micges> what modules are in firmware and what is pinout
[18:46:54] <memleak> ok
[18:47:11] <memleak> so its just human readable output
[18:47:33] <micges> yep
[18:50:17] <micges> asah: any progress with tppwm?
[19:01:40] <micges> asah: any progress with tppwm?
[19:02:05] <asah> nope. looks like peter is going to do it on monday.
[19:04:21] <micges> I got also strange results with tppwm, so we will see what Peter find
[19:39:08] <asah> cool
[21:58:07] <cradek> micges: packaging for mesaflash: http://timeguy.com/cradek-files/emc/0001-Add-debian-packaging-and-related-minor-fixes.patch