Back
[07:16:18] <KGB-linuxcnc> 03John Thornton 052.7 d315896 06linuxcnc 10docs/src/getting-started/updating-linuxcnc.txt Docs: add link to upgrade page from 2.5 to 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d315896
[08:09:15] <linuxcnc-build> build #69 of 4022.deb-jessie-amd64 is complete: Failure [4failed shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4022.deb-jessie-amd64/builds/69 blamelist: John Thornton <bjt128@gmail.com>
[09:27:13] <skunkworks> Crap.
[09:27:52] <skunkworks> So - max velocity doesn't cap rotory axis motion. (saw a bug in pathpilot)
[09:28:08] <skunkworks> feed override does
[09:28:31] <cradek> you mean pure rotary moves (ABC only)?
[09:28:34] <skunkworks> yes
[09:28:59] <cradek> not sure how it could do that, since those have different units from the ones the maxvel slider has
[09:29:38] <skunkworks> Combined moves MV does effect
[09:29:46] <cradek> yeah I'm not surprised by that
[09:29:52] <cradek> did this change from 2.6?
[09:30:02] <skunkworks> oh - is this something that was always an issue?
[09:30:07] <cradek> I don't know
[09:30:13] <skunkworks> let me check
[09:30:33] <cradek> it's not clear to me what a coherent design would be, so I'm not surprised that ... someone is surprised
[09:31:12] <skunkworks> I didn't even think of that. (MV is in units)
[09:31:38] <skunkworks> 2.6 does the same thing
[09:31:45] <skunkworks> ok - whew
[09:34:44] * skunkworks whistle softly and walks away
[09:39:25] <seb_kuzminsky> morning
[09:47:42] <skunkworks> This is interesting..
[09:47:43] <skunkworks> https://www.youtube.com/watch?v=GFGsP0dniwU
[09:48:18] <skunkworks> it seems as though the feedrate goes from 7.8 (111%FO) to 23..
[09:48:53] <skunkworks> I asked him if he could post the gcode
[09:51:17] <skunkworks> I wonder if it is displaying the A axis feed rate when only A is moved maybe..
[09:51:22] <cradek> I see alternating combined-XZ moves and A-only moves and it's stuck always saying 23.5. that seems like it's probably a gui or state tagging bug.
[09:51:47] <cradek> yeah it's hard to tell what the program is doing, but you can see the DROs doing XZ and A and that feed display doesn't change
[09:51:52] <skunkworks> That was my thought
[09:53:12] <cradek> and I don't hear the motion changing from 7.8 to 23.5
[09:53:14] <skunkworks> 7 seconds to move about 2.2 inches
[09:53:46] <skunkworks> hmm - that is close to 20in/min...
[09:54:17] <skunkworks> oops
[09:54:43] <cradek> 18.9 ipm
[09:55:03] <skunkworks> that was me counting.. But it looks like it is going at the stated feedrate.
[09:55:39] <skunkworks> definatly not 7.8ipm
[09:56:14] <skunkworks> does he talk on the video?
[09:56:20] <skunkworks> (no sound here)
[09:56:50] <archivist> not for the 4 minutes I looked at
[09:57:05] <pcw_home> is that just because of fallback to the old TP when doing moves that combine rotary axis with linear?
[09:57:50] <skunkworks> (assuming we are not seeing the feedrate change in gcode - I only see the 7ipm...)
[09:57:53] <cradek> hm, if he's doing G93 F7.8 the move should take 7.69sec
[09:57:59] <skunkworks> right
[09:58:23] <skunkworks> it seems to be going close to the 23ipm stated
[09:58:55] <cradek> I'm saying I wonder if he's in inverse time mode
[09:59:23] <cradek> eh, this is stupid, guessing without the gcode
[09:59:30] <cradek> ... or the software he's running
[09:59:42] <skunkworks> heh - what is inverse time gcode?
[09:59:52] <cradek> http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g93-g94-g95
[09:59:54] <cradek> G93 mode
[10:00:06] <skunkworks> G90 at the begining of the gcode
[10:00:22] <cradek> G90 is unrelated
[10:00:32] <cradek> this is G93 vs G94
[10:00:38] <skunkworks> sorry
[10:00:57] <skunkworks> not seeing either
[10:01:03] <skunkworks> so - unknown
[10:02:05] <cradek> guess he should try his gcode on linuxcnc, and submit a bug in the appropriate place
[10:02:53] <skunkworks> If I get the gcode - I will try it here
[10:02:57] <cradek> cool
[11:22:17] <JT-Shop> if one was to start from scratch would Axis II be written in C++ with QT or Python with GTK?
[11:25:41] <micges> python + qt
[11:25:44] <archivist> one hopes a compiled language
[11:27:05] <cradek> thanks to both of you for so quickly demonstrating how different people would make different choices
[11:27:58] <archivist> :)
[11:29:51] <archivist> I hate the current need to throw bigger machines at slower languages
[11:30:29] <cradek> it sure mixes weirdly with the urge to use silly underpowered machines
[11:32:02] <archivist> yes but those that can afford PC replacement dont realise what that forces on those users
[11:37:24] <JT-Shop> the thing I don't understand about QT is why they subclass things you can already do in C++
[11:46:06] <mozmck> subclass?
[11:47:23] <mozmck> toolkits such as QT have been around for years, and things that now have better support in a language did not always have that support. So the toolkit had to implement it themselves.
[11:48:21] <mozmck> Then they also are cross-platform, and things that are on one platform, may not always be on another platform - and so on.
[11:54:41] <mozmck> QT is also more than just a GUI toolkit and has cross-platform libraries for file IO, networking, printing and etc.
[11:56:05] <JT-Shop> ah ok, I was wondering about things like Qfile (maybe spelled wrong) vs using native C++ file I/O
[11:57:44] <mozmck> Yeah, take a look at the supported platforms:
http://doc.qt.io/qt-5/supported-platforms.html
[11:58:13] <JT-Shop> for us all we care about is Linux right?
[11:58:36] <mozmck> In c++ there are a number of things that are supported through the boost libraries, but those can come with their own set of issues.
[11:58:57] <mozmck> I would think so.
[11:59:28] <seb_kuzminsky> JT-Shop: there are many obstacles to running linuxcnc guis on non-linux platforms, the gui toolkit is just one of them
[11:59:49] <JT-Shop> and real time the other issue?
[11:59:51] <mozmck> You don't have to use the QT libraries for things just because they are there. So you can use std::string and c++ file I/O if you want.
[12:00:05] <JT-Shop> I'm not thinking of running LinuxCNC on anything else
[12:05:14] <seb_kuzminsky> JT-Shop: the gui is currently tied to the controller via NML (shared memory), HAL (shared memory), and the interp parameter file (shared filesystem)
[12:06:13] <seb_kuzminsky> so either all of the controller+gui would have to run on the same host, or we'd have to uncouple each of those three ties into some network-transparent alternative(s)
[12:07:15] <seb_kuzminsky> we started hacking on a cleanup of the NML interface at the last hackfest, as a first step towards providing a network-transparent replacement for the GUI-Task NML interface
[12:07:35] <seb_kuzminsky> but it's far from finished (it's in the liblinuxcnc-ui branch if anyone wants to look and/or hack on it)
[12:08:26] <seb_kuzminsky> i guess this is my long-winded way of saying, i think we're a long way away from being able to run the gui on a different machine than the rest of the controller
[12:08:33] <jepler> the language and gui toolkit used in axis is not in the list of top items that prevent it running on Windows. Python and Tkinter are both available there.
[12:09:47] <seb_kuzminsky> so cross-platform gui toolkits are certaintly cool and good, and it's good to consider using them in new work, but they're not on the short list of things that prevent us running GUIs on Android or Mac OS X or whatever
[12:11:58] <jepler> right now today you can use linuxcncrsh as a building block for a remote UI. you may discover that linuxcncrsh needs "more stuff", who knkows.
[12:12:59] <seb_kuzminsky> yep
[12:13:43] <jepler> there's also code in machinekit that uses the python linuxcnc module and presents some sort of network API, there's probably some revision of that you could lift wholesale and use on top of linuxcnc
[12:13:46] <seb_kuzminsky> there's also the "ssh + python + linuxcnc.so" option
[12:14:08] <jepler> mostly the problem is that the intersection of "people who are expressing public interest in remote UIs" and "people who have the expertise to implement remote UIs" is a small or empty set
[12:14:50] <mozmck> I'm not sure how much use a remote UI is except to reduce load on the machine controller?
[12:15:10] <seb_kuzminsky> i'm not sure it's useful for that ;-)
[12:15:15] <mozmck> Seems like the 3D printer folks like the idea of running their machine with a cell phone.
[12:15:52] <cradek> gross, seb's bugfix showed up in machinekit with some other person named as author, and reference to our bug report clumsily removed
[12:16:06] <jepler> never ascribe, etc
[12:16:14] <cradek> yeah, probably not evil, just very clumsy git usage
[12:16:36] <mozmck> Yeah, I don't know. With something like the BeagleBoard, the graphics are apparently not up to the job while running a machine.
[12:16:45] <seb_kuzminsky> cradek: which fix?
[12:16:54] <ssi> mozmck: a better solution would be to make the ui lighter if possible
[12:16:55] <cradek> someone with the xhc should see if we want their two bugfixes 80f4db0 and bb2f773
[12:17:06] <cradek> canon: fix bug , non-NCD arcs on machines with ABCUVW axes
[12:17:08] <mozmck> ssi: I agree - using c++ ;)
[12:17:11] <jepler> xemc, tkemc, touchy (without added preview window) will all work dandy
[12:17:18] <ssi> I like the idea of being able to use something like BBB with an fpga board for machines, cause managing a bunch of pcs starts to suck whben you have 5-10 machines
[12:17:20] <cradek> was: canon: fix bug #439, non-NCD arcs on machines with ABCUVW axes
[12:17:25] <jepler> AXIS is not slow on those ARM boards because of Python
[12:17:37] <ssi> jepler: more like because opengl, yeah?
[12:17:38] <jepler> it is slow because the OpenGL API that AXIS/gremlin use is not accelerated
[12:18:08] <ssi> it'd be nice if there were options for lighter, less 3d-shiny previews
[12:18:33] <jepler> some of them accelerate a different incarnation of OpenGL (opengl es) but nobody has cared enough to contribute changes to gremlin to let it switch to the right OpenGL API depending on the local system details
[12:18:51] <jepler> this is -devel, so I feel free to say "if you want it, write it"
[12:19:09] <ssi> naturally :)
[12:19:20] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 1c56b4e 06linuxcnc 10(6 files in 2 dirs) axis/xhc-hb04 configs update for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1c56b4e
[12:19:20] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 446507f 06linuxcnc 10(12 files) axis/ini_with_includes/: update for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=446507f
[12:19:20] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs e1421cd 06linuxcnc 10(6 files in 2 dirs) axis/simtcl/ configs: update for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e1421cd
[12:19:22] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 8886e16 06linuxcnc 10(19 files in 2 dirs) axis/moveoff/ configs update for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8886e16
[12:19:26] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs b1d3a57 06linuxcnc 10(15 files in 2 dirs) axis/axis/ sim configs update for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b1d3a57
[12:19:29] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 5081850 06linuxcnc 10configs/sim/axis/lathe.ini 10lib/python/rs274/glcanon.py axis/lathe.ini update for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5081850
[12:19:34] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 5264a1a 06linuxcnc 10(13 files in 6 dirs) axis/ sim subdirs update for joints_axes(partial) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5264a1a
[12:19:38] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs a6573a5 06linuxcnc 10(17 files in 8 dirs) axis/vismach sim configs update for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a6573a5
[12:19:42] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 67401d3 06linuxcnc 10(7 files in 7 dirs) axis/remap configs update for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=67401d3
[12:19:45] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 06187ca 06linuxcnc 10configs/sim/axis/spindle_orient/orient.ini axis/spindle_orient update for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=06187ca
[12:19:49] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs a7baa34 06linuxcnc 10(6 files) axis/ngcgui configs update for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a7baa34
[12:19:53] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 7f3fb19 06linuxcnc 10lib/hallib/sim_lib.tcl lib/hallib/sim_lib.tcl: enforce reqmt for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7f3fb19
[12:20:48] <cradek> sweeeet
[12:22:29] <seb_kuzminsky> yay!
[12:26:05] <seb_kuzminsky> something's fishy in master on arm:
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1676
[12:26:22] <seb_kuzminsky> 2.7 builds without any warnings:
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1677
[12:26:43] <jepler> there's not really in*/out* on ARM
[12:27:05] <seb_kuzminsky> but there wasnt on 2.7 either, right?
[12:27:19] <jepler> probably to do with "rtapi: accomodate systems without sys/io.h"
[12:27:22] <JT-Shop> I was talking more about an Axis that is not in Tkinter, not porting to other OS or remote
[12:28:11] * JT-Shop needs to try and understand NML (shared memory), HAL (shared memory), and the interp parameter file (shared filesystem)
[12:28:34] <ssi> JT-Shop: when you start getting into it let me know and I'd like to help
[12:28:50] <ssi> I would definitely contribute to this but it's hard to dive into
[12:29:08] <seb_kuzminsky> JT-Shop: i figured you weren't talking about other OSes ;-)
[12:29:30] <jepler> afk
[12:29:49] <seb_kuzminsky> JT-Shop: those three are the ways i can think of in which the UI and the controller core talk to each other
[12:30:07] <jepler> .. part programs are also in the shared filesystem
[12:30:16] <seb_kuzminsky> jepler: for gremlin, right
[12:30:22] <seb_kuzminsky> without gremlin that's not needed
[12:30:40] <jepler> how do you present the user with a list of part programs to open?
[12:30:42] <ssi> not even for the code panel?
[12:30:51] <jepler> yeah source listing too
[12:30:59] <seb_kuzminsky> JT-Shop: the NML stuff is somewhat described and confined to src/emc/usr_intf/shcomm.cc
[12:31:14] <seb_kuzminsky> jepler ssi : oh yeah good point. durr
[12:31:21] <seb_kuzminsky> i forgot about that little detail
[12:31:54] <JT-Shop> seb_kuzminsky, thanks
[12:32:26] <seb_kuzminsky> JT-Shop: shcomm is icky to me because it does a poor job of encapsulating the functionality it puports to provide, and places a large burden on the calling application to manage things
[12:33:31] <seb_kuzminsky> it's also available in the python module named "linuxcnc", which is implemented (somewhat confusingly) in src/emc/usr_intf/axis/extensions/emcmodule.cc
[12:33:46] <seb_kuzminsky> so, that's the C++ and Python NML interfaces to Task
[12:34:05] <JT-Shop> I've done some work with the python interface before and created a few basic GUI's
[12:34:34] <seb_kuzminsky> cool
[12:34:51] <seb_kuzminsky> i've written some tests using the python interface and i quite like that (over C++)
[12:35:15] <seb_kuzminsky> huh, our lib/python/linuxcnc.so links against a bunch of X libraries, that's surprising to me
[12:35:27] * seb_kuzminsky wanders off to lunch
[12:36:35] <JT-Shop> I remember reading some chatter about getting rid of NML how would that be done?
[12:39:34] <seb_kuzminsky> JT-Shop: it'd be a long and laborious process, which jepler sketched out as follows:
[12:39:51] <seb_kuzminsky> 1. make a nice clean interface for the GUIs to use to talk to Task, that hides all the NML stuff
[12:40:16] <seb_kuzminsky> 2. promote the new interface, and deprecate the raw NML interface
[12:41:01] <seb_kuzminsky> 3. design a new network protocol to do all the things that NML does
[12:41:24] <ssi> there are some light network protocols that would be worth looking at
[12:41:30] <JT-Shop> didn't mean to interrupt your lunch
[12:41:31] <seb_kuzminsky> 4. replace the guts of the new interface library and the guts of Task to use the new network protocol (while maintaining the library's API so the GUIs dont notice)
[12:41:47] <ssi> like protobuf
[12:42:00] <seb_kuzminsky> 5. git rm src/libnml ;-)
[12:42:15] <ssi> protobuf has c++ and python support fwiw
[12:42:38] <seb_kuzminsky> ssi: yeah, protobuf or something like it would play a part in the serialization/deserialization
[12:42:48] <JT-Shop> would golang fit anywhere for low level stuff?
[12:43:06] <ssi> moving IPC from nml to something like protobuf would make it easier to abstract it to network
[12:44:23] <seb_kuzminsky> JT-Shop: one of the hopes of this project would be to make it easier to support new languages, like Go, because it's generally easier to implement well-defined network protocols than ill-defined shared-memory interfaces ;-)
[12:44:39] <ssi> seb_kuzminsky: :D
[12:44:45] <seb_kuzminsky> really lunch now :-)
[12:44:51] <ssi> I hope we can get into some golang... that's my jam these days
[12:44:53] <JT-Shop> me too
[12:44:54] <seb_kuzminsky> nobody say anything interesting for one hour
[12:45:01] <JT-Shop> ok
[12:45:06] * ssi talks about airplanes for an hour
[13:36:54] <jepler> seb_kuzminsky: stuff pertaining to the backplot is swirled into linuxcnc.os
[13:36:59] <jepler> linuxcnc.so
[13:43:47] <jepler> I don't know whether we should prefer to eventually say (A) the official "linuxcnc API" is this wire protocol *OR* (b) the official "linxucnc API" is this pure C API. Any language worth programming in can wrap a pure C API.
[13:45:51] <seb_kuzminsky> i guess i have a slight preference for the wire protocol, with the C library as a reference implementation of sorts
[13:46:28] <jepler> I suspect a C library will be easier to change compatibly than a wire protocol
[13:46:52] <cradek> strikes me that the gpl feels very differently about those two things
[13:46:53] <seb_kuzminsky> the wire protocol should have one of those version numbers in the handshake
[13:47:35] <jepler> cradek: GPL *can't* encumber a wire protocol
[13:48:03] <cradek> right, that's exactly what I mean
[13:48:55] <ssi> mesa pins rs422 as tx+/tx- rx+/rx-
[13:49:00] <ssi> your pinout says X Y A B
[13:49:03] <ssi> how does that correlate?
[13:49:14] <ssi> er Y Z A B rather
[13:49:18] * seb_kuzminsky points at the channel name
[13:49:24] <ssi> dangit sorry
[13:49:27] <seb_kuzminsky> heh
[13:55:53] <jepler> seb_kuzminsky: those components with warnings probably shouldn't be built on ARM...
[13:58:14] <seb_kuzminsky> jepler: surely there's pci on arm?
[13:58:21] <seb_kuzminsky> hm2_pci has warnings too
[14:01:40] <jepler> 227 * The ARM doesn't have special IO access instructions; all IO is memory
[14:01:43] <jepler> 228 * mapped. Note that these are defined to perform little endian accesses
[14:01:46] <jepler> 229 * only. Their primary purpose is to access PCI and ISA peripherals.
[14:03:18] <jepler> it looks like arm's <asm/io.h> has inb() etc macros that turn the operations into memory-mapped operations under some assumptions about PCI I/O space being mapped at a certain spot in the virtual address space (PCI_IO_VIRT_BASE)
[14:03:20] <seb_kuzminsky> so rtapi_{in,out}* should become memory access on ARM
[14:03:23] <jepler> I bet this doesn't work
[14:03:29] <seb_kuzminsky> ah
[14:03:33] <jepler> we don't have any code to create this mapping...
[14:03:53] <jepler> and I don't have any ARM with a PCI bus to check
[14:05:26] <jepler> if somebody sends me one I'll make it work or send back a vial of salty, salty tears in compensation.
[14:05:37] <ssi> lol
[14:06:07] <Tom_itx> what arm board do you need?
[14:06:12] <jepler> Tom_itx: one with PCI slots
[14:06:17] <Tom_itx> i've got an stm32f i've never used
[14:06:28] <Tom_itx> stm32f4
[14:07:01] <Tom_itx> no idea what it has on it
[14:09:40] <jepler> hm, potentially this could be tested using qemu-system-arm with PCI pass-through on any old x86
[14:10:27] <jepler> and a mesa card with plx9054 or plx9030, which I have one of (5i20)
[14:10:55] <jepler> Tom_itx: thanks for the offer, but I don't think that's what I need.
[14:11:12] <Tom_itx> np, if you ever do it's sitting collecting dust
[14:14:16] <jepler> hm it also requires an intel cpu with advanced virtualization features so maybe not
[15:37:28] <KGB-linuxcnc> 03Dewey Garrett 052.7 efe3ac1 06linuxcnc 10lib/python/gremlin_view.py 10lib/python/pyngcgui.py pyngcgui.py, gremlin_view.py regression * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=efe3ac1
[15:37:28] <KGB-linuxcnc> 03Dewey Garrett 052.7 730af77 06linuxcnc 10configs/sim/axis/ngcgui/fullscreen.tcl pyngcgui fullscreen, regression * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=730af77
[15:45:26] * jepler wows at get_linuxcnc_ini_file
[15:45:44] <jepler> somebody was clearly writing expedient code, but I don't know how you can call it "right" code
[15:47:21] <cradek> and we have two copies of that
[15:47:22] <jepler> export INI_FILE_NAME="$INIFILE"
[15:47:22] <jepler> $EMCSERVER -ini "$INIFILE"
[15:47:41] <jepler> You can find this value in the environment as long as you're launched from inside the linuxcnc script
[15:47:54] <jepler> $EMCDISPLAY -ini "$INIFILE" $EMCDISPLAYARGS $EXTRA_ARGS
[15:48:02] <jepler> the value is also aways given on the commandline of the $EMCDISPLAY
[15:50:34] <jepler> $ ps -C linuxcncsvr --no-header -o args
[15:51:01] <jepler> if you really think you need to do this, this is a better way to get just the argument list of the process linuxcncsvr
[15:51:21] <cradek> but it's in the environment!?
[15:52:34] <seb_kuzminsky> it's only in the environment if you're a descendant of the "linuxcnc" process
[15:52:43] <seb_kuzminsky> which you probably are
[16:38:02] <mozmck> seb_kuzminsky: it would certainly be nice to have a common interface to INI values. It would need to read and write any value - not just ones Task knows about though.
[16:38:20] <KGB-linuxcnc> 03Dewey Garrett 052.7 faf9e11 06linuxcnc 10lib/python/gremlin_view.py 10lib/python/pyngcgui.py pyngcgui.py, gremlin_view.py improve ini file find * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=faf9e11
[16:38:43] <seb_kuzminsky> mozmck: write?
[16:39:03] <mozmck> maybe not write, but that would actually be nice.
[16:39:58] <mozmck> Then a gui can have dialogs to edit the config or part of it while running.
[16:40:15] <seb_kuzminsky> that would be cool
[16:41:36] <mozmck> Yes, and with a little work should be do-able. HAL pins can be linked and un-linked on the fly, etc. I don't know if other parts of linuxcnc can be re-configured at run time or not.
[16:50:08] <micges> mozmck: what about hal pins reflecting configs? I don't know if they're able to be updated on the fly
[16:51:35] <mozmck> a pin for each ini value?
[16:52:08] <micges> yes, they are in 2.7 now
[16:52:40] <mozmck> The problem is that you can have custom ini values - I have quite a few in my setup. You need to have an api to request the value of "MY_CUSTOM_GUI_TWEAK" if it exists.
[17:20:07] <skunkworks> https://www.youtube.com/watch?v=QQO2t6NocmA
[17:20:10] <skunkworks> comments
[17:44:50] <micges> pkg-config should be checked in ./configure before libudev libmodbus and libusb, without pkg-configs all three lib checkings are always false
[17:45:09] <micges> 2.7 uspace under debian 8.2
[17:50:08] <jepler> I don't understand what you mean. Are you saying that a bug in configure is giving incorrect results?
[17:51:22] <micges> yes
[17:51:48] <jepler> do you have a proposed patch?
[17:52:28] <micges> I could try to bake one
[17:53:49] <jepler> http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/117/steps/configuring/logs/stdio
[17:54:00] <jepler> checking for libudev... yes - version 215
[17:54:21] <jepler> the problem is not affecting buildbot
[17:54:29] <jepler> unless I misunderstand
[17:56:04] <micges> on 8.2 fresh install you don't have pkg-config
[17:56:10] <jepler> are you saying that on your system, the program pkg-config is not even installed?
[17:56:20] <jepler> and you would like configure to detect that problem and issue a good error?
[17:57:12] <micges> yeah, before all checks that uses it
[17:58:20] <jepler> I don't mind if a check like that is added to configure.
[17:59:46] <jepler> untested: AC_CHECK_PROG(PKG_CONFIG, pkg-config, [], [AC_MSG_ERROR([a helpful error message]))
[18:02:17] <jepler> no, something about my syntax is wrong
[18:06:20] <jepler> AC_PATH_PROG([PKG_CONFIG], [pkg-config])
[18:06:20] <jepler> if test -z "$PKG_CONFIG"; then
[18:06:20] <jepler> AC_MSG_ERROR([pkg-config is required to build LinuxCNC])
[18:06:20] <jepler> fi
[18:09:03] <micges> its working
[18:18:46] <jepler> ok, as far as I am concerned you can push it if it is helpful to you
[18:19:57] <micges> patch:
http://pastebin.ca/3183210
[18:20:32] <micges> who's in charge on 2.7?
[18:22:23] <jepler> seb
[18:38:00] <micges> jepler: thanks for help, I'm slighty more confident now with configure stuff
[19:06:36] <jepler> micges: you're welcome
[19:30:20] <seb_kuzminsky> micges: feel free to push to 2.7 when you have something working
[19:35:45] <micges> ok
[19:38:02] <skunkworks> zlog
[20:47:09] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 7c51d47 06linuxcnc 10configs/sim/low_graphics/keystick.ini 10configs/sim/low_graphics/mini.ini 10configs/sim/low_graphics/xlinuxcnc.ini 10tcl/mini.tcl low_graphics/ update for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7c51d47
[20:47:09] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 846b537 06linuxcnc 10configs/sim/tklinuxcnc/servo_sim.ini 10configs/sim/tklinuxcnc/tklinuxcnc.ini 10configs/sim/tklinuxcnc/tripod.ini 10lib/hallib/servo_sim.hal tklinuxcnc/ update configs for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=846b537
[20:47:09] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 82ef0cd 06linuxcnc 10configs/sim/pyvcp_demo/pyvcp_demo1.ini pyvcp_demo/ update for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=82ef0cd
[20:47:13] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs a471f36 06linuxcnc 10(7 files in 3 dirs) touchy/ update configs for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a471f36
[20:47:17] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 01b65b8 06linuxcnc 10(13 files in 4 dirs) gscreen/ update configs for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=01b65b8
[20:47:21] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs a7d82db 06linuxcnc 10(13 files in 2 dirs) gmoccapy/ updates for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a7d82db
[20:47:24] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 4903748 06linuxcnc 10(13 files in 2 dirs) axis/ cleanups for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4903748
[20:47:28] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 21f5666 06linuxcnc 10lib/python/gremlin_view.py 10lib/python/pyngcgui.py pyngcgui.py, gremlin_view.py regression * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=21f5666
[20:47:32] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 79c812f 06linuxcnc 10lib/python/gremlin_view.py 10lib/python/pyngcgui.py pyngcgui.py, gremlin_view.py improve ini file find * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=79c812f
[20:47:37] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja_configs 51b5e43 06linuxcnc 10configs/sim/axis/ngcgui/fullscreen.tcl pyngcgui fullscreen, regression * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=51b5e43
[20:49:36] <cradek> awesome!