Back
[02:11:52] <KGB-linuxcnc> 03Chris Morley 05v2.5_branch 60b3435 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py pncconf -fix an icompatibility between MESA XMLs and linuxcnc XMLs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=60b3435
[02:27:42] <KGB-linuxcnc> 03Chris Morley 052.6 0013e46 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py Merge branch 'v2.5_branch' into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0013e46
[02:48:48] <CaptHindsight> KimK: we're still tracking down the problem with 3.4.55 RTAI on really new AMD hardware and also UNITY desktop on Ubuntu with 14.04 or the Trusty version of Mint
[02:52:04] <CaptHindsight> KimK: let us know how 3.4.55 RTAI works on your systems with those new releases of Mint
[07:57:53] <jthornton> is there a link to the 2.6 online docs?
[08:01:48] * archivist would just put 2.6 where 2.3 ,2.4 was and expect it to just work
[08:04:50] <jthornton> there is no 2.x in the link only docs and master
[08:05:32] <archivist> http://www.linuxcnc.org/docs/2.6/
[08:05:55] * archivist ducks :)
[08:06:51] <jthornton> all I found was
http://linuxcnc.org/docview/html/ and
http://linuxcnc.org/docview/devel
[08:07:03] <jthornton> thanks for the link
[08:07:24] <archivist> I just googled for 2.4 and then edited the url
[08:07:45] <jthornton> youv'e been up longer than me today LOL
[08:07:49] <archivist> hehe
[09:52:26] <jepler> andy/pcw: I think the basic idea of allowing a LBP_BITS to be more than 64 bits big would look something like this:
http://emergent.unpythonic.net/files/sandbox/0001-hostmot2-untested-allow-more-than-64-consecutive-LBP.patch -- but since I don't have a -rtai system handy it's not even compiled (I didn't port sserial to uspace yet, I guess I should)
[09:56:30] <pcw_home> the sserial stuff just worked with uspace-hm2-eth
[09:59:56] <jepler> oh really? I thought I didn't even compile it in.
[10:00:01] <jepler> that's good then
[10:00:03] <jepler> > Given two integer values x and y, the (floor of the) average normally would be computed by (x+y)/2; unfortunately, this can yield incorrect results due to overflow. A very sneaky alternative is to use (x&y)+((x^y)/2).
[10:00:29] <jepler> huh, ^^ that's .. not intuitive
[10:01:14] <pcw_home> say what?
[10:03:48] <jepler> http://webcache.googleusercontent.com/search?q=cache:GdfhQPBQ1iAJ:aggregate.org/MAGIC/#Average%20of%20Integers
[10:06:24] <pcw_home> Thats full of all sorts of neat tricks
[10:11:51] <jepler> oh, it's "setsserial" that is not built for uspace
[10:13:02] <pcw_home> Thats only needed for setting EEPROM constants and updating firmware on sserial remotes
[10:23:36] <pcw_home> I can try the > 64 bit patch on monday
[10:27:02] <jepler> it's probably not right in detail, but I think the basic idea is close to right
[10:45:44] <KGB-linuxcnc> 03Jeff Epler 052.6 c5d6017 06linuxcnc 10src/rtapi/sim_common.h sim: Fix 32-bit truncation of rdtsc on x86_64 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c5d6017
[10:45:45] <KGB-linuxcnc> 03Jeff Epler 052.6 5c18f5a 06linuxcnc 10docs/man/man3/hal_parport.3hal docs: Fix cut&paste errors * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5c18f5a
[10:45:45] <KGB-linuxcnc> 03Jeff Epler 052.6 e8d8465 06linuxcnc 10src/emc/task/taskmodule.cc task: silence a warning with gcc 4.8 + boost 1.55.0 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e8d8465
[10:45:47] <KGB-linuxcnc> 03Jeff Epler 052.6 9a9384a 06linuxcnc 10src/emc/task/taskmodule.cc task: safely format these messages * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9a9384a
[10:56:23] <atom1> what's the deb line to grab master?
[10:56:41] <atom1> i had to reinstall everything here
[10:57:27] <atom1> is it the 2.6 lines at builbot.linuxcnc.org ?
[11:07:21] <atom1> nm...
[11:29:13] <jepler> pcw_home: did you try 7i90 with uspace? It's one I ported but didn't (couldn't) test.
[11:30:23] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 1530584 06linuxcnc 60 commits pushed, 1022 files changed, 031145(+), 041037(-)
[11:31:37] <Tom_itx> where's libmodbus-dev located?
[11:31:42] <Tom_itx> trying to build master
[11:31:51] <jepler> rebased branch. new stuff: setsserial is built (not tested), a few warnings squashed
[11:32:00] <jepler> Tom_itx: it's a package that can be installed by the package manager (apt-get / synaptic)
[11:32:01] <Tom_itx> went to get libmodbus-dev and it returns... not found
[11:32:10] <Tom_itx> ok
[11:32:43] <Tom_itx> not in the package list
[11:33:03] <jepler> what os version?
[11:33:12] <Tom_itx> from the live cd
[11:33:17] <Tom_itx> 10.04
[11:33:31] <Tom_itx> i had to reinstall everything.. so starting over here
[11:34:20] <jepler> have you done "apt-get update" since installing?
[11:34:45] <jepler> for 10.04, the package should come from linuxcnc.org
[11:34:55] <Tom_itx> i get a 'no public key' on the buildbot site
[11:35:33] <Tom_itx> still no luck
[11:35:56] <jepler> it's been a very long time since I used a system installed from the 10.04 live cd
[11:36:19] <jepler> you need to make sure the linuxcnc.org package server is in your lits
[11:36:21] <jepler> list
[11:36:56] <jepler> deb
http://www.linuxcnc.org/ lucid base 2.6
[11:36:56] <jepler> deb-src
http://www.linuxcnc.org/ lucid base 2.6
[11:37:02] <jepler> err not quite
[11:37:13] <atom1> ahh it's pointing to 2.4
[11:37:34] <jepler> maybe it's linuxcnc.org/dists/ lucid base 2.6
[11:38:13] <atom1> http://www.linuxcnc.org/emc2 lucid base emc2.4 is what i have
[11:38:55] <atom1> and added the buildbot stuff
[11:39:49] <jepler> well anyway, if you're not getting libmodbus-dev after apt-get update, then it's a problem with your sources.list lines
[11:40:06] <jepler> unfortunately I don't have the correct lines in my memory
[11:40:14] <atom1> np
[11:40:19] <atom1> i'll keep lookin
[11:41:54] <jepler> found a 10.04 vm
[11:41:55] <jepler> it has
[11:41:56] <jepler> ./sources.list:deb
http://linuxcnc.org lucid base linuxcnc2.5
[11:42:13] <jepler> and it can install package libmodbus-dev from linuxcnc.org
[11:42:40] <jepler> so remove /emc2 from the sources.list line
[11:43:02] <atom1> yeah i just found that
[11:45:09] <atom1> still didn't work
[11:46:06] <atom1> ok apt-get worked
[11:46:14] <atom1> not the package manager
[11:49:12] <atom1> error: boost::python is required to build LinuxCNC
[11:49:21] <atom1> do you know whick package has that?
[11:54:13] <pcw_home> jepler: no I didn't, I just tested uspace-hm2-eth
[11:54:15] <pcw_home> I can try a 7I90 (EPP) on Monday
[11:55:12] <jepler> pcw_home: OK. If you do, and it doesn't work, let me know
[11:55:33] <jepler> atom1: libboost-python-dev I think
[11:56:05] <jepler> looking in the file debian/control.in is often good for trying to figure out what packages are needed
[11:56:11] <jepler> just ignore the documentation-related ones
[12:02:38] <atom1> thanks, that seemed to get it
[13:25:17] <micges-dev> jepler: something special needed to run hm2_7i90 under uspace?
[13:44:38] <jepler> micges-dev: no, it's just hardware I don't have to test
[13:51:05] <micges-dev> jepler: hm2: loading Mesa HostMot2 driver version 0.15
[13:51:05] <micges-dev> hm2_7i90: dlopen: /home/x/PROJECTS/master-rt-preempt/rtlib/hm2_7i90.so: undefined symbol: rtapi_parport_get
[13:51:05] <micges-dev> core.hal:6: /home/x/PROJECTS/master-rt-preempt/bin/rtapi_app exited without becoming ready
[13:51:19] <micges-dev> loadrt hm2_7i90 ioaddr=0x378 epp_wide=1 config=""
[13:53:12] <micges-dev> linux 3.12.16-rt25
[13:53:18] <micges-dev> bbl
[13:54:25] <jepler> hmm :( it looks like I managed to break 7i43 as well
[13:55:06] <micges-dev> got 7i90 setup ready, be back in 1h
[13:58:08] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 753d651 06linuxcnc 10src/rtapi/Submakefile 10src/rtapi/rtapi_parport.h 03src/rtapi/uspace_rtapi_parport.cc uspace: implement rtapi_parport * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=753d651
[13:58:08] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis c59c7b8 06linuxcnc 10(9 files in 3 dirs) hal_parport: Build for uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c59c7b8
[13:58:08] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 8652403 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace: Allow the upper-bound value to be parenthesized * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8652403
[13:58:11] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 58afb61 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace: Report the "corrupt" array type information * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=58afb61
[13:58:15] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis fe417d5 06linuxcnc 10src/rtapi/uspace_common.h uspace: implement rtapi_delay_max for hm2_7i43 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fe417d5
[13:58:19] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 58d1e5f 06linuxcnc 10src/Makefile 10src/hal/drivers/mesa-hostmot2/hm2_7i43.c 10src/hal/drivers/mesa-hostmot2/hm2_7i90.c hostmot2: port 7i43 (tested) and 7i90 (untested) to uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=58d1e5f
[13:58:23] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 6097b4f 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_7i43.c hm2_7i43: Automatically fall back to byte transfers * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6097b4f
[13:58:27] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 9a737df 06linuxcnc 10src/Makefile 10src/hal/drivers/mesa-hostmot2/setsserial.c setsserial: port to uspace and enable (untested) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9a737df
[14:03:20] <CaptHindsight> ran 3.4.55 RTA1 on Mint Mate Debian for half a day and latency stayed <8K, I run the same kernel on Ubuntu Unity 12.04 and it's at 18K after 2 minutes, same kernel, same linuxcnc and RTAI repos, both are using the same Mesa (software rendering) driver
[14:10:35] <CaptHindsight> well same Mesa version shows up in glxinfo, I'll have to actually check how each distro made those packages to be sure it's the same source
[14:14:54] <CaptHindsight> just FYI there are three packages that are generally missing from newer versions of Ubuntu or Mint that are needed to install Linuxcnc: libboost-python1.46.1, libgnomeprint and libgnomeprintui
[14:25:32] <KGB-linuxcnc> 03Chris Morley 05new_pncconf 6ae7a4c 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py pncconf -fix incompatibilty between MESA and LCNC XMLs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6ae7a4c
[14:25:32] <KGB-linuxcnc> 03Chris Morley 05new_pncconf d9e8ccb 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py pncconf -cleanup code a bit * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d9e8ccb
[15:19:18] <Capn_Fish> Anybody know how long the BeagleBone Black version takes to build on the BBB? I made the mistake of doing "make clean"...
[15:23:01] <pcw_home> you will find out (eventually) :-)
[15:40:10] <fenugrec> in stepgen.c : make_pulses() ; when decrementing timer1 timer2 and timer3, wouldn't there be a small gain to be had by removing the ( timer > 0 ) check, like so :
http://www.diffchecker.com/lwtw32dz
[15:41:20] <fenugrec> we check for timerx > periodns right after; as I understand periodns is always >= 0, and (timer < 0 ) is meaningless and should never happen...
[15:41:50] <micges-dev> jepler: hm2_7i90 under uspace works
[15:58:02] <fenugrec> mhh come to think of it, it's almost not a gain after all... It's 2 instructions shorter (test ebx,ebx; jle _skip) when timerX > periodns, but 1 instruction longer when timerX==0 (mov ebx,0)
[16:16:34] <jepler> nobody has tried to optimize linuxcnc components on the level of counting individual instructions. I don't doubt you'll find lots of places where writing slightly different C code might give slightly fewer instructions, but probably not enough of them to make more than 1% difference in the possible step rate
[16:16:53] <jepler> .. because that's almost always more due to hardware latency than the number of cycles spent in realtime code
[16:17:20] <jepler> so basically, it's worth fixing gross algorithmic problems (like avoiding division, or avoiding floating-point) but typically not worth it to eliminate a single register comparison
[16:17:39] <jepler> yes, periodns will always be >0
[16:18:05] <jepler> but so that a few functions can signal an error by returning a negative value, time periods are stored, passed, and returned as signed values
[16:19:13] <fenugrec> jepler: you're right; especially without doing any profiling it's probably not worth the trouble. I was expecting a slightly bigger effect in this case but "gcc -O" does an OK job as it is
[16:56:38] <jepler> micges-dev: thanks
[17:35:48] <cradek> Connection to the other side was lost in a non-clean fashion.
[17:52:48] <CaptHindsight> on this test system Mint Mate Debian has better latency (<8K) with 3.4.55 RTAI then the LiveCD
[17:55:38] <CaptHindsight> quad Phenom II 2.8GHz and 780 chipset (gigabyte MA785GM-US2H)
[18:02:18] <andypugh> cradek: Did yo get the chance to look at the G43.2 + remap config?
[18:02:38] <andypugh> I am not entirely sure whether it belongs under the “remap” tree.
[18:04:10] <andypugh> I have also wondered if it might not be more generic if it included a more elaborate python segment that set g-code params for up to 4 “fields” of the T-word and (for completeness) each corresponding pocket number.
[18:04:51] <andypugh> I tried to make the Python as minimal as possible, puting all the “clever” in the G-code. But I am wondering if perhaps the inverse solution is better.
[18:05:39] <andypugh> Actally, not a complete inverse: give the G-code the info it needs to be even cleverer.
[18:09:39] <andypugh> The Python prologue can query the tool table. The G-code can’t. (AFAIK). It looks like every lathe uses 2-digit data fields. So we could simply pass params to the G-code called #<T1> #<T2> #<T3> #<T4> and (why not?) the corresponding pocket numbers for each #<P1>…. I think that means that the G-code sub would be all anyone needed to change to suit their own preference.
[18:10:52] <andypugh> <digression> Are lathe users unimaginative and resistant to change? I am much more relaxed on a lathe than a mill, but I seem unusual in being perfectly happy with M6 T3 G43 as my toolchange code.
[18:57:55] <andypugh> Oh FFS! Aram thinks every system has exactly the same set of Signals in HAL. He is an imbecile and even Mach3 doesn’t deserve him.
[19:10:08] <cradek> andypugh: I like how the smarts is in gcode, showing the integer division and mod. that seems the most user-customizable to me (you can parse T0102030405 that way if you want without changing the python, right?)
[19:10:20] <cradek> or T001002
[19:10:39] <cradek> I don't know much about the feelings of various users so I decline to comment about that :-)
[19:12:17] <andypugh> The only problem with the demo config is that you get no tool-table info, such as the pocket that corresponds to that tool number.
[19:12:40] <cradek> but for lathes that seems to be what makes 'em happy
[19:12:52] <andypugh> I suspect that the T0101 lathes don’t use pockets, but I don’t know that
[19:13:11] <cradek> I guess it depends what your? our? goal is
[19:13:42] <cradek> my most specific goal is to do what that patch does but without hardcoding silly limitations
[19:14:08] <cradek> if the result is useful as an example for further customization, all the better
[19:14:24] <cradek> but you're doing it and I bet any of your answers is fine
[19:14:43] <andypugh> My goal is to stop superiorroll moaning. A bonus would be something that lets Tormach buyers upgrade to 2.6 seamlessly.
[19:14:46] <cradek> 99% of people will use your sample as-is and if it does what that patch does, perfect
[19:14:59] <cradek> heh
[19:15:08] <cradek> I'm being called to dinner
[19:15:19] <cradek> I trust you - do what you think is best
[19:15:42] <cradek> (stopping moaning is a great goal)
[19:15:47] <cradek> bbl, and thanks
[20:48:03] <fenugrec> I'm trying to understand what happens after the trajectory planner stats a circle (tpAddCircle); how this gets to the motion-controller function running in the servo thread. Does emcmot calculate, every servo period, the next point in the trajectory, making this in effect a linear approximation to a circle ?
[20:49:15] <fenugrec> Or is there some kind of velocity black magic at work ? (although it seems the axes are always used with position commanding, at least for the few sample stepper configs I've checked)
[20:53:18] <pcw_home> With a velocity mode drive you effectively get linear interpolation between servo thread rate position waypoints
[20:53:19] <pcw_home> if the TP handed the external interpolator acceleration numbers, you would a get parabolic approximation
[20:53:45] <pcw_home> would get
[20:58:21] <fenugrec> hmm... so in the case of software stepping, stepgen gets (every servo period) a new position-cmd which is the next point along the requested circle, correct ?
[20:59:40] <pcw_home> and basically the stepgen run a a constant step rate between servo threads (so behaves like a velocity mode servo)
[20:59:52] <pcw_home> at a
[21:00:32] <pcw_home> so you have linear interpolation between position waypoints
[21:01:36] <fenugrec> right, ok. And when using an external step generator (Mesa IO cards, etc) we get the same thing; a STEP pulse train having a constant frequency between each waypoint.
[21:03:34] <pcw_home> Yes,
[21:03:35] <pcw_home> but note that the path deviation at a given acceleration given by this scheme is inversely
[21:03:37] <pcw_home> proportional to the square of the servo thread rate so gets tiny really quickly unless you have very high accelerations
[21:05:01] <pcw_home> I have been meaning to add Accel to our stepgen
[21:05:03] <pcw_home> and see how well it does with slow servo thread rates
[21:06:18] <fenugrec> what do you mean, an accel command input ?
[21:07:14] <pcw_home> yes
[21:07:42] <pcw_home> then it does parabolic interpolation
[21:09:12] <fenugrec> Right
[21:11:15] <fenugrec> Other related topic : the motion controller HAL component has both axis.N.joint-vel-cmd and axis.N.joint-pos-cmd ; how does that work - does it output a desired velocity + target position and hope that whoever is below (like a pos-cmd stepgen) takes care of both ?
[21:29:01] <micges-dev> yes
[21:30:45] <fenugrec> hmm
[21:31:01] <fenugrec> oh crap gotta run; thanks for the info pcw_home and micges-dev