Back
[05:16:31] <ikcalB> hey guys: have there been reported problems resultung from too many hal-pins? seems like I'm running into an issue here...
[05:16:59] <ikcalB> seb_kuzminsky: tested the build the whole week, w/o any problems so far.
[05:55:28] <skunksleep> Awww snap.
http://www.machsupport.com/forum/index.php?topic=32102.0
[07:10:08] <jepler> ikcalB: yes, the hal shared memory segment has a limited size defined at compile time. this memory can be exhausted for large configs
[07:10:11] <jepler> hal_priv.h:#define HAL_SIZE (75*4096)
[07:11:29] <jepler> haltcl: for {set i 0} {1} {incr i} { newsig _$i float }
[07:11:29] <jepler> HAL: ERROR: insufficient memory for signal '_3836'
[07:11:50] <jepler> for instance, without any pins or parameters allocated, the memory is exhausted simply by creating 3836 signals of type 'float'
[07:13:42] <jepler> because of the way they are structured, some components also place their own private data in the hal shared memory area, even if it's not associated with pins, parameters, or signals. that's the difference between hal_alloc and rtapi_kalloc. using hal_alloc is convenient, because the system takes care of eventually freeing it when realtime is shut down; that does not happen for rtapi_kalloc, the p
[07:13:48] <jepler> oint has to be passed to rtapi_kfree at exit or (for rtai realtime) kernel memory is leaked permanently until reboot
[07:41:10] <ikcalB> jepler: tnx for clarifying! That might become helpful in the feature. (Meanwhile, it looks like im losing a pin when emc-ethercat module has to allocate a second block of mem, me & sascha have a look into that)
[08:04:03] <jepler> ikcalB: "halcmd status" reports information about hal shared memory
[08:04:16] <jepler> e.g., it can tell me: used/total shared memory: 312/307200
[08:04:27] <jepler> (this is just after starting halrun with nothing loaded)
[12:34:17] <skunkworks_> zlog
[12:47:18] <solosoft> hi anyone here have some good info on compiling xenomai on arch arm rpi?
[12:57:19] <solosoft> have made mamy atemps now at linux-rpi 3.2.27 and 3.10.y crosscompile and on the rpi itself to elimenate the toolchain but it always fail on the same place
[12:57:23] <solosoft> http://pastebin.com/mY1FzGma
[13:00:51] <solosoft> here is the problem : can't open file "arch/arm/xenomai/Kconfig ... The file is there but its a symbolic lin and when using cat to look at it it says file missing
[13:03:14] <pcw_home> As a general note, currently LinuxCNC does not run under Xenomai,
[13:03:15] <pcw_home> so you might be better off asking this question on a machinekit or Xenomai forum
[13:07:50] <solosoft> ok is there a better solution for rasberrypi?
[13:08:21] <solosoft> did mess whit rtai long time ago
[13:28:08] <cradek> ideally someone would already have built a rt-preempt kernel for it, but I have no idea whether that's true
[13:30:56] <pcw_home> There are Preempt-RT kernels for RPI but 100s of usec latency
[13:31:13] <pcw_home> (used for drones)
[13:31:57] <pcw_home> not sure any RT kernel for RPI is good enough for a decent software stepgen
[13:40:33] <jepler> I think the strategy for step generation on rpi would have to be to calculate the steps in advance and fill out a buffer that will be DMA'd out. This is how e.g., PWM is achieved on rpi outputs, if I understand it.
[13:46:57] <jepler> https://github.com/hzeller/rpi-gpio-dma-demo#using-dma-to-write-to-gpiop
[13:47:26] <jepler> https://www.npmjs.com/package/pi-fast-gpio "waveforms are accurate to a few microseconds"
[13:54:07] <mozmck> The snickerdoodle looks interesting:
https://www.crowdsupply.com/krtkl/snickerdoodle
[13:54:23] <mozmck> especially the 154 I/O
[13:59:50] <jepler> make sure to get the optional heatsink. the one zynq-based device I have (parallela) burns up without heatsink + fan
[14:17:06] <PCW> Thats how we did LCD brightness/contrast PDM and LCD signals for our old flat panel PCs (DMA)
[14:18:24] <PCW> basically 8 bit DMA with 4 data bits, LCD FLM and CLOCK, and PDM "tracks" for brightness and ontrast
[14:21:49] <PCW> There was some guy on the forum doing DMA stepgens with the RPI, not sure what happened to that
[14:27:43] <mozmck> jepler: I guess the snickerdoodle may be the same then - although they don't mention that. The parallela does have another CPU on it as well though
[14:40:08] <jepler> > I think it has been acknowledged by Adapteva here in the forum already that the Kickstarter reward boards with a 7020 SoC use engineering samples of that chip which can have excessively high leakage currents, therefore the higher than expected demands on the cooling. Heat dissipation of regular SoCs should indeed be lower.
[14:40:38] <mozmck> interesting
[14:41:48] <jepler> I should go check if my boards have "ES" chips. I have two, and I think I only ever took one out of the box so the other should be heatsinkless
[14:42:45] <jepler> apparently a board rev also allowed a single larger heatsink to be placed above several components (zync, funky smp chip, and maybe pmic?)
[14:43:51] <jepler> Change #4:
[14:43:52] <jepler> Move the tall 100uF caps to the bottom side
[14:43:53] <jepler> Why: Allow for more efficient heat sinks for the Epiphany/Zynq
[14:43:56] <jepler> Change #6:
[14:43:57] <jepler> Move the reset pin
[14:43:57] <jepler> Why: Get out of the way from the heatsink
[14:45:22] <mozmck> heh!
[14:46:06] <mozmck> They also recommend pointing a fan at the board for early revs
[14:49:02] <jepler> well you have to point the fan because there's no provision to mount one
[15:20:59] <jepler> I thought there were people running grbl on pis who might know how to do step generation, but it seems I was wrong, and people are using an entire rpi to drip-feed the grbl controller with gcode
[15:22:02] <skunkworks> I didn't know grbl worked on the pi.. I thought it was just for the arduino
[15:22:15] <skunkworks> (which requires a way to drip feed the gcode)
[15:23:34] <jepler> skunkworks: right
[15:23:47] <jepler> the pi feeds the avr running grbl
[15:24:11] <skunkworks> I suppose that is one way to do it.. :)
[15:24:40] <jepler> I should stop talking before I say opinions
[15:25:14] <skunkworks> heh
[15:29:09] <skunkworks> I played with grbl for a little bit. It is a pretty poor trajectory planner. It is pretty much and exact stop planner with some magic for making corners that violates constraints usually
[15:48:46] <skunkworks> http://www.cnczone.com/forums/opensource-software/271966-grbl-logging-linuxcnc.html
[15:53:40] <CaptHindsight> nah, the head dev has a PhD, that would make him look silly
[15:56:24] <skunkworks> It is pretty conisistant.. the little I played with it - there was no gross violations
[16:01:47] <jepler> skunkworks: the linuxcnc logging of other systems' step generation is just about the coolest thing, it's so neat that you did that.
[16:02:29] <skunkworks> Thanks - I certainly proves how cool linuxcnc is :)
[16:02:41] <skunkworks> *It
[16:03:07] <jepler> You certainly proves it too
[16:03:13] <jepler> *U
[16:51:58] <skunkworks> zlog
[20:43:50] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp f81cb6d 06linuxcnc 10src/Makefile build: warn about incorrect function overloading * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f81cb6d
[20:43:50] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp baeefe6 06linuxcnc 10src/libnml/buffer/tcpmem.cc 10src/libnml/buffer/tcpmem.hh nml: Fix prototypes in class TCPMEM * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=baeefe6
[20:43:50] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp 57df2a3 06linuxcnc 10src/libnml/buffer/tcpmem.cc nml: tcp: copy serial number back to caller * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=57df2a3
[20:43:52] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp dcca7cf 06linuxcnc 10src/libnml/buffer/rem_msg.hh 10src/libnml/buffer/tcpmem.cc 10src/libnml/cms/tcp_srv.cc 10src/libnml/nml/nml_srv.cc nml: tcp: arrange to transport write_id back to client * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dcca7cf
[20:43:56] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp 25ec531 06linuxcnc 10configs/common/linuxcnc.nml 10tests/linuxcncrsh-tcp/tcp.nml configs: must enable "confirm_write" to get serial number return * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=25ec531
[20:44:01] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp 56d953e 06linuxcnc 10src/libnml/cms/cms.cc nml: trivial typo * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=56d953e
[20:44:05] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp c85e2e7 06linuxcnc 10src/libnml/cms/cms.cc 10src/libnml/cms/cms.hh 10tests/linuxcncrsh-tcp/tcp.nml nml: add 'serial' flag to do command serial-number stuff * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c85e2e7
[20:44:09] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp 7da0af6 06linuxcnc 10src/libnml/nml/nml_srv.cc nml: write the serial number into the command as seen by task * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7da0af6
[20:44:13] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp c77d9d5 06linuxcnc 10configs/common/client.nml 10configs/common/linuxcnc.nml 10configs/common/server.nml fix other nmlfiles * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c77d9d5
[20:44:17] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp 907fb2c 06linuxcnc 04tests/linuxcncrsh-tcp/skip tests: linuxcncrsh-tcp test now passes for me * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=907fb2c
[20:45:03] <skunkworks> nml over tcp?
[20:47:23] <linuxcnc-build> build #3978 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/3978 blamelist: Jeff Epler <jepler@unpythonic.net>
[20:48:38] <linuxcnc-build> build #3189 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/3189 blamelist: Jeff Epler <jepler@unpythonic.net>
[20:49:36] <linuxcnc-build> build #3980 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/3980 blamelist: Jeff Epler <jepler@unpythonic.net>
[20:50:18] <linuxcnc-build> build #2172 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/2172 blamelist: Jeff Epler <jepler@unpythonic.net>
[21:11:37] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp 22978e5 06linuxcnc 10src/libnml/buffer/tcpmem.hh nml: adapt to older compilers * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=22978e5
[21:13:37] <jepler> skunkworks: yeah. using an adapted version of tcp.nml in tests/ I used both tklinuxcnc and axis over the network to home, jog, and mdi. but the text of error messages seems to get lost by axis, and of course you have the age-old problem of opening files when the filesystems "here" and "there" don't agree with each other.
[21:13:44] <jepler> also I failed to touch off in axis for some reason
[21:14:08] <jepler> so it's still not perfect .. but I believe the basics are working again at the level they did in 2.6 plus reliable command reception
[21:14:42] <jepler> oh and this is all 64-bit to 64-bit, no idea about 64 to 32
[21:15:17] <jepler> afk
[21:15:23] <linuxcnc-build> build #3992 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3992 blamelist: Jeff Epler <jepler@unpythonic.net>
[21:16:03] <skunkworks> Cool!
[21:26:23] <CaptHindsight> Allwinner H3 without mali accell is pretty zippy at 1920 x 1080
[21:27:01] <CaptHindsight> windows move pretty smoothly
[21:27:51] <CaptHindsight> still have to build Linuxcnc
[21:41:28] <jepler> hmph, 400us latency on my new computer
[21:41:37] <jepler> running Linux rat 4.4.0-trunk-rt-amd64 #1 SMP PREEMPT RT Debian 4.4.1-1~0.jepler8~1 (2016-02-16) x86_64 GNU/Linux
[21:44:00] * skunkworks channeling pcw - You could probably get by with that latency.... (for a 1ms servo period)
[21:44:44] <skunkworks> with dpll
[21:45:07] <memfrob> hi all is there a way to tell configure to look for boost::python in /usr/lib/minions/libboost* ? I'm on a horribly put together distro and i can't get linuxcnc to find libboost_python-py27 becuase it's not floating in the root dir of /usr/lib