Back
[04:19:32] <KGB-linuxcnc> 03Norbert Schechner 052.6 1a54c8d 06linuxcnc 10scripts/githelper.sh Merge branch '2.6' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1a54c8d
[04:19:32] <KGB-linuxcnc> 03Norbert Schechner 052.6 f2ec59a 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.glade 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_3_2 - PAUSE button did not get active on M01 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f2ec59a
[04:22:15] <KGB-linuxcnc> 03Norbert Schechner 05master 33fc3dc 06linuxcnc Merge branch '2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=33fc3dc
[05:02:35] <linuxcnc-build_> build #186 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/186 blamelist: Jeff Epler <jepler@unpythonic.net>, Michael Haberler <git@mah.priv.at>, Robert W. Ellenberg <rwe24g@gmail.com>, Chris Radek <chris@timeguy.com>,
[05:02:35] <linuxcnc-build_> Chris Morley <chrisinnanaimo@hotmail.com>, John Thornton <jthornton@gnipsel.com>, gmoccapy <nieson@web.de>, Norbert Schechner <nieson@web.de>, Michael Geszkiewicz <micges@wp.pl>, Chris S Morley <chrisinnanaimo@hotmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[05:02:37] <linuxcnc-build_> build #147 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/147 blamelist: Jeff Epler <jepler@unpythonic.net>, Michael Haberler <git@mah.priv.at>, Robert W. Ellenberg <rwe24g@gmail.com>, Chris Radek <chris@timeguy.com>,
[05:02:37] <linuxcnc-build_> Chris Morley <chrisinnanaimo@hotmail.com>, John Thornton <jthornton@gnipsel.com>, gmoccapy <nieson@web.de>, Norbert Schechner <nieson@web.de>, Michael Geszkiewicz <micges@wp.pl>, Chris S Morley <chrisinnanaimo@hotmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[09:17:19] <seb_kuzminsky> yay, norbert merged 2.6 into master and resolved the gmoccapy conflict that had me stumped
[09:17:43] <seb_kuzminsky> now i wish i'd been more on the ball and told people about the new 2.7 branch, so he'd have known to merge 2.6 into 2.7, then 2.7 into master...
[11:49:09] <mk0_> +
[12:28:12] <skunkworks> logger[psha],
[12:28:12] <logger[psha]> skunkworks: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-10-28.html
[14:44:53] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui e850496 06linuxcnc 10docs/src/Submakefile 03docs/src/code/liblinuxcnc-ui.txt lui: some overview/motivation/aspirational documentation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e850496
[14:50:34] <seb_kuzminsky> yessss
[14:53:48] <jepler> seb_kuzminsky: feel free to trample on anything you disagree with
[14:54:08] <seb_kuzminsky> jepler: did you deliberately name the type "lui_tool_info" instead of "lui_tool_info_t"? all the other types end with _t i think
[14:55:27] <jepler> seb_kuzminsky: no, must be a msitake
[14:56:44] <jepler> oh huh, it was just a bug in linux that the Intel Quark CPU was recognized as having the F00F bug
[14:57:28] <jepler> .. because Intel Quark identified as family 5 / model 9, and all family 5 (Pentium) CPUs had it historically
[14:59:23] <dirty_d> so I made a very simple embeded stepper motor controller with a usart interface that accepts {step these axes, then wait this many microseconds before executing the next command} type commands. How much work am I looking at getting linuxcnc to interface with it?
[15:00:39] <cradek> dirty_d: for information about what kind of hardware works well with linuxcnc, see
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Emc2HardwareDesign
[15:04:00] <dirty_d> im breaking your rules, my device buffers commands, but thats ok because my machine has no switches or probes etc
[15:04:46] <dirty_d> i really just need access to the step and timing info from linuxcnc
[15:05:46] <cradek> there is no layer of linuxcnc that has motion represented in that particular way
[15:06:06] <cradek> the motion controller generates a desired (absolute) position every period
[15:06:26] <dirty_d> hmm i thought i remember seeing a stepper motor driver in there somewhere
[15:06:29] <cradek> hal components and hardware interfaces track that in various ways
[15:06:57] <cradek> there is stepgen, a hal component that takes those position inputs and generates step/dir in realtime to track the position as best it can
[15:07:44] <cradek> you could try to write an equivalent, but I'm afraid you are not working from a suitable design
[15:09:07] <dirty_d> mesa-hostmot2/stepgen.c?
[15:09:30] <dirty_d> why isnt it suitable?
[15:14:46] <jepler> if you can write a hal component with pins which are sensible to connect to the motor-position-cmd and motor-position-fb pins of an axis/joint then it's suitable
[15:15:42] <jepler> suitable includes things like "is a realtime component", because motor-position-fb has to be updated at each 1ms iteration of the so-called "servo thread", with the current position of the motors
[15:16:26] <jepler> from your description, your device is a thing which likes to buffer positions and reach them at some time in the future. If you do this, and accurately report the motor positions every 1ms, LinuxCNC will trigger following errors because the motors did not go where it requested when it requested.
[15:17:04] <dirty_d> cant I just tell it they are where they should be even though nothing has actually physically happened yet?
[15:18:01] <cradek> can you replace "step these axes and then wait this many microseconds" with a more suitable interface, like realtime position or velocity commands?
[15:18:23] <cradek> it's not clear to me that your chosen interface can even move in aribtrary directions
[15:18:42] <dirty_d> you send it direction and step commands
[15:18:48] <jepler> simulator configurations (those with no motors at all) connect motor-position-cmd to motor-position-fb in hal. but when there are actual motors involved, it's really desirable to know whether they went where commanded.
[15:18:52] <dirty_d> it buffers tehm, and then executes them in real time
[15:19:12] <dirty_d> so the interface to the hardware isnt realtime, but the steps get executed in realtime
[15:19:39] <cradek> why is this a type of interface that is beneficial?
[15:20:09] <dirty_d> easy cheap very accurate timing control with a non-realtime pc
[15:20:42] <dirty_d> the hardware is $10
[15:23:08] <KGB-linuxcnc> 03Norbert Schechner 052.7 329d073 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.glade 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/notification.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_merge changes of 2.6 to 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=329d073
[15:25:28] <linuxcnc-build_> build #2078 of 3002.dsc-precise is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/3002.dsc-precise/builds/2078 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:25:47] <jepler> I updated that wiki page and moved it to
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?HardwareDesign
[15:26:01] <jepler> bbl
[15:36:59] <norbert__> I tried to merge 2.6 into 2.7, but there are two merge conflicts, VERSION contain 2.8.0-pre1, should that not be 2.7-pre2? and the debian/chanchelog does contain also information about 2.8.0, but IMHO should finish with 2.7 in 2.7 branch. What if I do change that two files to solve the conflict?
[15:41:06] <jepler> norbert__: the things you state are surprising to me too.
[15:42:35] <linuxcnc-build_> build #2597 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2597 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:42:48] <jepler> norbert__: you merged 'master' branch into 2.6.
[15:43:18] <jepler> I will resolve this by rewinding history on the 2.6 branch to before this
[15:45:22] <KGB-linuxcnc> 03Jeff Epler 052.6 f318076 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f318076
[15:47:54] <norbert__> Thanks, I am leaving now.
[15:47:56] <norbert__> By
[15:52:03] <jepler> .. what a mess
[15:52:40] <jepler> and what a cluster glade is for git merge
[15:53:04] <alex_joni> ouch
[16:01:50] <KGB-linuxcnc> 03Jeff Epler 052.7 d0ae19e 06linuxcnc 10scripts/latency-test Merge commit 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d0ae19e
[16:01:50] <KGB-linuxcnc> 03Jeff Epler 05master fd255ae 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fd255ae
[16:02:01] <seb_kuzminsky> thanks jepler
[17:47:50] <Tom_itx> nasa rocket just exploded on launch...
[17:51:59] <jepler> heck
[17:53:22] <Tom_itx> ~10 min ago
[17:53:41] <jepler> unmanned, right?
[17:53:50] <Tom_itx> yes
[17:53:56] <Tom_itx> supplies for the space station
[17:54:30] <jepler> I guess they'll have to make the TP last an extra six weeks
[17:59:01] <Tom_itx> Wallpops Island Virginia
[18:01:25] <seb_kuzminsky> nasa doesnt fly manned rockets any more
[18:02:42] <seb_kuzminsky> not until the Senate Launch Systems comes online:
http://en.wikipedia.org/wiki/Space_Launch_System
[18:09:07] <jepler> will they launch all 100 members of the senate?
[18:09:34] <seb_kuzminsky> god i hope so
[18:09:59] <seb_kuzminsky> one at a time because of limitations of the booster, no doubt
[18:10:04] <jepler> it might be enough to launch a 60-member supermajority
[18:17:36] <jepler> launch team be advised maintain position at your consoles
https://www.youtube.com/watch?v=jHMmMgdcOSU
[18:19:15] <jepler> it's astonishing to me how little time it took to go from "going up" to "going down"
[18:22:08] <Tom_itx> it was supposed to go this morning
[18:22:19] <Tom_itx> a stray boat in the area postponed it
[18:50:55] <brianmorel99> pcw: Your around? Went to order my plug & go kit, and it looks like you are out of stock on the 7i76. Was curious if there was an eta on replenishment.
[19:03:54] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui f30ab82 06linuxcnc 10src/liblinuxcnc-ui/linuxcnc-ui.h fixup! lui: structure for tool info * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f30ab82
[19:03:54] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui 40ce223 06linuxcnc 10src/liblinuxcnc-ui/luigetter.py fixup! lui: framework to autogenerate getters * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=40ce223
[19:03:54] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui 00cb23e 06linuxcnc 10docs/src/code/liblinuxcnc-ui.txt fixup! lui: some overview/motivation/aspirational documentation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=00cb23e
[19:03:57] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui 6841c59 06linuxcnc 10tests/liblinuxcnc-ui/lui-test.c fixup! lui-test: introspect some tool information * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6841c59
[19:04:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui 1a89485 06linuxcnc 10docs/src/code/liblinuxcnc-ui.txt fixup! some overview/motivation/aspirational documentation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1a89485
[19:04:05] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui 942093b 06linuxcnc 10docs/src/Master_Developer.txt 10docs/src/index.tmpl fixup! some overview/motivation/aspirational documentation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=942093b
[19:40:20] <PCW> 7I76s will be a couple weeks (7I76e's are available though)
[19:43:05] <PCW> skunkworks_: hm2_eth seems perfectly happy at 3 KHz on a g3258
[20:03:57] <jepler> PCW: am I right thinking that the pin names on a 7i77 come from the firmware on the 7i77 itself? I forget whether we mentioned this before, but at txrx we were briefly confused by the fact that the last analog output had a different enable pin than the rest
[20:04:31] <jepler> I forget the pin names, but the last enable implied it was something to do with a spindle, but it just affected whether the analog out numbered "5" was enabled
[20:04:57] <PCW> All sserial pin names come from the remote device (as does scaling and data packing info)
[20:06:15] <PCW> (and data type)
[20:07:15] <PCW> the manual does note that channel 5 is intended for spindle operation and has a separate enable
[20:09:01] <jepler> yeah I do see that now
[20:09:32] <jepler> and you'd break configs to rename any of the pins
[20:09:49] <jepler> probably nothing for it but to call it a learning experience
[20:12:20] <PCW> I should probably have a pin name list in a distributed file
[20:13:08] <brianmorel99> PCW: Thanks, off hand do you know if backorders are allowed on the webs store?
[20:14:35] <PCW> Probably not a great (theres something that times out at 30 days or so requiring a re-order)
[20:14:45] <PCW> not a great idea
[20:21:44] <brianmorel99> the 7i75 will give access to all 25 pins for I/O and protection of the 6i25 right?
[20:24:20] <PCW> all _17_ pins...
[20:26:04] <zeeshan|2> is it possible to display inches per revolution for velocity in axis
[20:26:14] <zeeshan|2> i notice when im in CSS mode, it still displays ipm
[20:27:57] <PCW> You want to display the circumference?
[20:29:10] <zeeshan|2> when you're milling a feature for example, and you have your feedrate set to 50 ipm in the g-code, the velocity thing shows you actual current speed in inches per minute
[20:29:32] <zeeshan|2> but when im turning something in 'feed per rev' mode, i wish velocity was shown in inches per rev, not inches per min
[20:29:49] <brianmorel99> PCW: Thanks, not in a rush, so I'll wait for the 7i76 so I can get lots of IO pins
[20:31:08] <PCW> No 7I76E?
[20:37:33] <brianmorel99> No, not quite ready to play with the ethernet side of things yet.
[20:46:04] <PCW> Ethernet Seems pretty stable (been running one or another board about 2/3 of a year now 24/7 without incident)
[20:49:58] <brianmorel99> Ya, that will probably be next. I have my mill moving now, so It's time for some real steppers & drivers (Has one of those Chinese Blue boards now). I want to get familiar with the 6i25 on that, and then will probably try ethernet on the lathe.
[20:50:13] <brianmorel99> I think this will be an expensive hobby, but it sure is fun.
[21:03:13] <skunkworks_> PCW, cool!
[22:24:44] <skunkworks_> wow - imagine linuxcnc having a very powerful ethernet solution...