Back
[04:43:19] <tinkerer> yeah, packages created and installed on real raspi.
[05:42:21] <tinkerer> sandbox compiling of my driver with halcompile works too! STRIKE!
[06:02:57] <tinkerer> Hmmm, fd = open("/dev/mem", O_RDWR | O_SYNC); => can't open /dev/mem
[06:03:35] <tinkerer> any clues?
[06:10:09] <archivist> http://man7.org/linux/man-pages/man4/mem.4.html kernel dependent ?
[06:12:47] <tinkerer> hmmm, I've thought halcompile --install sets the suid
[09:48:13] <jepler> tinkerer: in uspace realtime, it runs most of the time without root access to the filesystem, including /dev.
[09:48:30] <jepler> tinkerer: the way to temporarily access the filesystem as root is unfortunately not exposed in the RTAPI "C" API
[09:49:44] <jepler> the way this is accomplished is in rtapi_uspace.hh, class WithRoot
[09:49:48] <jepler> WithRoot() { if(!level) setfsuid(geteuid()); level++; }
[09:49:48] <jepler> ~WithRoot() { --level; if(!level) setfsuid(getuid()); }
[09:53:11] <jepler> so untested, you could implement rtapi_open_as_root in "C" as
[09:53:13] <jepler> int rtapi_open_as_root(const char *filename, int mode) {
[09:53:13] <jepler> setfsuid(geteuid());
[09:53:13] <jepler> int r = open(filename, mode);
[09:53:13] <jepler> setfsuid(getuid());
[09:53:15] <jepler> return r;
[09:53:18] <jepler> }
[10:33:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-temporary-root e4030c8 06linuxcnc 10(6 files in 3 dirs) uspace: provide new APIs to access filesystem as root * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e4030c8
[10:35:26] <linuxcnc-build> build #2309 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/2309 blamelist: Jeff Epler <jepler@unpythonic.net>
[10:36:02] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-temporary-root 798236c 06linuxcnc 10(7 files in 3 dirs) uspace: provide new APIs to access filesystem as root * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=798236c
[10:36:17] <linuxcnc-build> build #1819 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/1819 blamelist: Jeff Epler <jepler@unpythonic.net>
[10:36:23] <linuxcnc-build> build #1303 of 1903.clang-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1903.clang-wheezy-amd64/builds/1303 blamelist: Jeff Epler <jepler@unpythonic.net>
[10:36:29] <linuxcnc-build> build #2309 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/2309 blamelist: Jeff Epler <jepler@unpythonic.net>
[10:37:08] <linuxcnc-build> build #777 of 1520.rip-jessie-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1520.rip-jessie-amd64/builds/777 blamelist: Jeff Epler <jepler@unpythonic.net>
[10:37:23] <linuxcnc-build> build #4150 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/4150 blamelist: Jeff Epler <jepler@unpythonic.net>
[10:37:39] <linuxcnc-build> build #777 of 1530.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1530.rip-jessie-rtpreempt-amd64/builds/777 blamelist: Jeff Epler <jepler@unpythonic.net>
[10:38:02] <linuxcnc-build> build #2343 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/2343 blamelist: Jeff Epler <jepler@unpythonic.net>
[10:38:06] <linuxcnc-build> build #777 of 1500.rip-jessie-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/777 blamelist: Jeff Epler <jepler@unpythonic.net>
[10:38:14] <linuxcnc-build> build #777 of 1510.rip-jessie-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1510.rip-jessie-rtpreempt-i386/builds/777 blamelist: Jeff Epler <jepler@unpythonic.net>
[10:38:27] <linuxcnc-build> build #4148 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/4148 blamelist: Jeff Epler <jepler@unpythonic.net>
[12:05:33] <jepler> seb_kuzminsky: looks like the build is stuck because the builder for 1404.rip-wheezy-rtpreempt-amd64 is offline
[12:05:41] <jepler> http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/2507
[13:09:05] <dgarr> bug reported to me: master branch bisected to ad06db2, start configs/sim/axis/axis.ini, F1,F2,Home-All, click Reload Icon twice-->"A file is already open; can'topen ...
[13:21:10] <jepler> dgarr: thanks, noted
[13:38:45] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened issue #62: linuxcnc.stat.program_open() errors if called twice in a row 02
https://github.com/LinuxCNC/linuxcnc/issues/62
[13:43:27] <tinkerer> jepler: Thanks!! that works.
[13:44:35] <jepler> tinkerer: thank you for the feedback. I will plan to add rtapi_open_as_root to our master branch soon, as you may have seen it is already on branch jepler/master/uspace-temporary-root
[13:46:04] <tinkerer> no, I've made hardcore hacking :)
[13:46:25] <tinkerer> the pragmatic way
[13:47:18] <tinkerer> bbl, I hear the voice of my wife... ;)
[13:47:46] <tinkerer> more later
[13:52:34] <skunkworks> 'looks' like the backlash in z is the end support bearing. I think it was really hard to get to - so no one adjusted it. the other axis have peen marks where the nut had been adjusted.
[13:59:33] <skunkworks> you can't even see the rotation of .0001 inch.. scary how this all works. .001 is just see-able
[15:32:14] <skunkworks_> zlog
[15:33:06] <Tom_itx> at least one pc is still working here :D
[16:35:49] <KGB-linuxcnc> 03Jeff Epler 05jepler/2.7/repated-program-open 3c4c908 06linuxcnc 10src/emc/usr_intf/axis/extensions/emcmodule.cc linuxcncmodule: fix repeated calls to program_open() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3c4c908
[16:36:51] <tinkerer> is pcw around?
[16:37:17] <tinkerer> or jepler?
[17:00:37] <tinkerer> where can I found the 7I90HDIO.PIN file.
[17:07:25] <tinkerer> err: find
[17:12:43] <jepler> http://mesanet.com/software/parallel/7i90.zip has the files that mesa ships for the 7i90 card. I don't know if any of them are called "7I90HDIO".
[17:14:07] <jepler> looks like linuxcnc.org doesn't ship any firmwares for the 7i90
[17:15:05] <jepler> usually it's the .bit file you're interested in, you can run mesaflash to get the .pin file which is just metadata, or read it out when starting linuxcnc
[17:15:32] <jepler> (of course you may not be able to do that with mesaflash since like hm2_spi in linuxcnc, it uses /dev/spidev for access to the card)
[17:18:33] <tinkerer> no the PIN file describe more then the firmware pins
[17:18:56] <tinkerer> for instance the usr leds
[17:19:49] <tinkerer> from the manual: See the 7I90HDIO.PIN file for FPGA pin locations of the LED signals.
[17:20:18] <tinkerer> because I have big troubles with the card
[17:21:02] <tinkerer> the outputs suddenly stops working
[17:23:09] <tinkerer> I can communicate with the card and step around with axis but just virtual. the outputs of the card are staying high.
[17:23:22] <tinkerer> very strange
[17:24:08] <tinkerer> so I will try to debug with the leds
[17:24:09] <pcw_home> all I/Os high suggests that the watchdog has bitten
[17:24:28] <tinkerer> suddenly
[17:26:00] <tinkerer> it works the half night without any problems
[17:27:15] <tinkerer> I have to configurations on different raspis. one with machinekit and one with lcnc
[17:28:33] <tinkerer> the machinekit config has been unchanged since 2 days
[17:30:08] <tinkerer> and nevertheless the card stops working here too
[17:31:08] <tinkerer> so, when bites the watchdog?
[17:32:31] <tinkerer> or how can I serve the watchdog
[17:32:45] <tinkerer> or feed :)
[17:33:53] <tinkerer> pcw: can you tell me the pins of the usr leds?
[17:35:54] <tinkerer> suddenly lacks a "?"
[17:38:43] <tinkerer> jepler: it's not in the 7i90.zip
[17:40:04] <tinkerer> btw: I got some strange messages from lcnc " libGL error: failed to open drm device: No such file or directory
[17:40:05] <tinkerer> libGL error: failed to load driver: i965
[17:40:05] <tinkerer> "
[18:03:06] <cradek> that's not a linuxcnc error. try running any other opengl program.
[18:08:11] <tinkerer> ah ok
[18:08:54] <tinkerer> strange i965 on arm
[18:11:26] <tinkerer> pcw or jepler: no clues? I cant found any examples in the source for petting the watchdog
[18:11:48] <tinkerer> arg... find
[18:13:25] <jepler> it happens automatically as part of the "write" function
[18:14:03] <tinkerer> True if the watchdog has bit, False if the watchdog has not bit. If the watchdog has bit and the has_bit bit is True, the user can reset it to False to resume operation.
[18:16:07] <tinkerer> so I would like connect the has_bit pin to the usr led for checking if the wd has bit.
[18:16:54] <tinkerer> but I dont know name or number of the led pin
[18:21:14] <cradek> if the watchdog bites I think you can't control the LEDs on the board anymore - along with all IO they do a predefined thing
[18:22:36] <cradek> see the Watchdog section in the hostmot2 manpage
[18:23:37] <pcw_home> you can control the LEDs (they are not like the GPIO pins that are all floated on WD bite)
[18:23:51] <cradek> oh!
[18:24:09] <cradek> heh reading the manpage is still good advice even though I'm wrong, right?
[18:24:12] <tinkerer> yes I have assumed this
[18:24:41] <tinkerer> cradek: what does thet mean?
[18:24:45] <tinkerer> that
[18:24:57] <cradek> what?
[18:25:36] <pcw_home> The hal LED pins will be CR01,CR02,CR03 and CR04
[18:26:58] <tinkerer> I have read the manpage!
[18:29:42] <tinkerer> usr1 = cr03 & usr0 = cr04 ?
[18:32:24] <pcw_home> Oh yeah I forgot, the 7I90 only has 2 user LEDS so they will be named CR01 and CR02 in hal
[18:33:36] <tinkerer> ah, its labeled on the board: cr04 and cr05
[18:34:01] <tinkerer> thanks
[18:34:31] <pcw_home> Yeah theres no correspondence between silk screen art and hal names for user LEDs
[18:36:00] <tinkerer> I assume the gpios are disabled through the drivers (pi5c 16211a)?
[18:38:20] <tinkerer> silk screen art :D
[18:46:20] <tinkerer> The pins are numbered from CR01 upwards with the name corresponding to the PCB silkscreen.
[18:46:28] <tinkerer> :)
[18:47:04] <tinkerer> but: hm2-stepper-7i90.hal:64: Pin 'hm2_7i90.0.CR01' does not exist
[18:58:06] <pcw_home> The GPIOs are disabled by setting all DDRs to 0
[18:59:34] <tinkerer> ok
[19:01:08] <tinkerer> the led pin surprisingly the word led in the bin name... ;)
[19:01:17] <tinkerer> has
[19:11:34] <tinkerer> a slightly weired question: does the card store/remember the has_bit value for a certain time? despite disconnecting the card from power?
[19:20:00] <tinkerer> :D after putting the following line in the hal file the watchdog never bites: setp hm2_[HOSTMOT2](BOARD).0.watchdog.has_bit FALSE
[19:20:05] <tinkerer> very funny
[20:20:35] <tinkerer> and the cherry on the top: the image works very well on the raspi3!