Back
[01:31:45] <KGB-linuxcnc> 03Kim 05v2.5_branch 3612017 06linuxcnc 10docs/src/hal/ 10halui_examples.txt 10halui_examples_de.txt 10halui_examples_es.txt 10halui_examples_pl.txt * Docs: Fix a typo left over from rebranding
[01:31:45] <KGB-linuxcnc> 03Kim 05v2.5_branch de7f668 06linuxcnc 10src/Makefile * Docs: Fix typo left over from rebranding
[01:32:57] <KimK> Oops, that wasn't "docs". Sorry, force of habit.
[09:40:53] <mhaberler> I might have missed something in master: is the new method of runtests to run 'linuxcnc -r' ?
[10:49:32] <seb_kuzminsky> mhaberler: no, but when runtests runs a test that runs linuxcnc (such as the linuxcncrsh and custom-python-ui tests), the test can start linuxcnc with -r to make it not mess with stdout/stderr quite as much
[10:49:36] <seb_kuzminsky> helps with debugging
[13:39:42] <KGB-linuxcnc> 03elson 05v2.5_branch 0f35a67 06linuxcnc 10docs/src/drivers/pico_ppmc.txt * keep 2.5 in synch with master docs
[20:31:10] <gabewillen> Anyone on here?
[20:31:57] <memleak> me!
[20:32:00] <cradek> I count 33
[20:32:22] <gabewillen> lol, well i can't always go by the numbers
[20:32:44] <memleak> yep, you never can.
[20:33:05] <memleak> unless it's a busy channel such as #defocus etc.
[20:33:11] <gabewillen> So i have been secretly writing a new halcmd type program, and have been following the devel mailing list
[20:33:47] <gabewillen> with a better license and more dynamic, i have completely wrapped all of rtapi, and hal in python
[20:34:56] <gabewillen> I have been reading about doing a universal module loader, as for my rt-preempt test bench uses, rtapi_app and the distributed linuxcnc uses the module helper
[20:35:12] <memleak> Oh that sounds lovely!
[20:35:31] <gabewillen> i have it working on both rt-preempt and the distributed version
[20:35:53] <gabewillen> it will have a gui interface with circuit style component and pin linking
[20:36:03] <memleak> I'm so glad someone else is working on PREEMPT_RT now. Are you testing this on x86? please tell me not ARM..
[20:36:49] <memleak> also rtapi_app and hal needed a serious overhaul for quite sometime ever since the control types started working on it.
[20:37:01] <gabewillen> I use it on my laptop as a daily kernel
[20:37:09] <gabewillen> ubuntu 12.04
[20:37:14] <memleak> perfect!
[20:37:15] <gabewillen> 64 bit
[20:37:27] <gabewillen> have been using it for about 6 months now
[20:37:36] <memleak> oh nice! I've been working on 64-bit RTAI support for modern x86 hardware.
[20:37:48] <memleak> only two or three months though..
[20:38:07] <memleak> What kind of hardware?
[20:38:08] <gabewillen> Well i haven't mention this yet because it was a huge undertaking
[20:38:21] <gabewillen> and i am known to not complete things
[20:38:23] <memleak> CPU and GPU.
[20:38:58] <gabewillen> i have a Pentium i7 with nvidia geforce GT 635m
[20:39:01] <memleak> I'll try and complete whatever is left if it isn't too much.
[20:39:10] <memleak> You mean Core i7, yes?
[20:39:15] <gabewillen> yes sorry
[20:39:26] <memleak> kernel version? 3.x based, yes?
[20:39:44] <gabewillen> also have bumblebee working for switching between the low power gpu and the nvidia
[20:40:02] <gabewillen> That was the first thing, otherwise battery life was non existent
[20:40:51] <memleak> heh, yeah AMD just pushed DPM (display power management) for their radeon cards recently in kernel 3.11 that will automatically adjust the GPU clock speeds based on load.
[20:40:51] <gabewillen> Linux Gabe-Personal-PC 3.4.27-rt39 #1 SMP PREEMPT RT Tue Jan 29 13:31:39 CST 2013 x86_64 x86_64 x86_64 GNU/Linux
[20:41:06] <memleak> Everyone's laptop was dying nearly instantly with a brand new GPU
[20:41:31] <memleak> That was supposed to say dynamic power management...
[20:41:52] <gabewillen> I used a new module for python called cffi, its a foreign function library, that allows for compiling
[20:41:54] <memleak> gabewillen, you getting any page faults?
[20:42:32] <memleak> latency-test sparking up into the few hundred thousand nanosecond range?
[20:43:08] <gabewillen> Yes latency isn't the greatest i haven't ran the test in a while
[20:43:44] <memleak> yeah there is a potential false positive page fault error that linuxcnc throws, its messing up virtually everyone's PREEMPT_RT system
[20:44:10] <memleak> one of the main devs I'm working closely with to fix it, has about 30 machines, and only one of them didn't have catastrophic latency issues.
[20:44:42] <memleak> Lately I've been revamping the RTAI side of things since PREEMPT_RT support is dragging slower than a snail on heroin.
[20:46:41] <gabewillen> Sorry :) ran latency-test -80
[20:46:44] <gabewillen> and Locked it up
[20:46:50] <memleak> Heh!
[20:46:54] <memleak> that happens..
[20:47:10] <gabewillen> rt-preempt has some ways to go
[20:47:15] <memleak> Indeed it does.
[20:47:19] <gabewillen> compared to xenomai and rtai
[20:47:40] <memleak> eh xenomai has a ways to go too, at least on x86
[20:48:04] <memleak> RTAI is the only thing i have working, and that's after forking the entire RTAI project myself, with some help from one other dev.
[20:48:10] <gabewillen> I had to re-write allot the #define macro's into actual C functions
[20:49:09] <memleak> We need more people like you on the job..
[20:49:33] <memleak> I'm working with someone now to implement ftrace into latency-test to fully debug any latency jitter.
[20:49:41] <gabewillen> I am a bit of a python lover, I mainly use C, C++ , and Pytho
[20:49:45] <gabewillen> Python*
[20:50:01] <gabewillen> Wrapping this in python seemed the logical choice
[20:50:15] <memleak> a mix of kernel hacking and linuxcnc hacking, we might just be able to put gdb into serious use.
[20:50:37] <memleak> problem is, linuxcnc doesn't have a whole lot of debugging implemented in linuxcnc.
[20:50:54] <gabewillen> You will be able to write component's dynamically and using JIT compilation load them in, unload and change them, then reload them
[20:50:59] <memleak> it's basically just at a stub right now.
[20:51:17] <gabewillen> I implemented pythons logging module
[20:51:26] <memleak> oh perfect!
[20:51:52] <gabewillen> Color coded with 4 types, info, debug, error, and critical
[20:52:27] <memleak> that's exactly what we need i think.. do you have any of the source published or is it 100% private?
[20:52:55] <memleak> you can upload it onto github if you like so me and a few other devs can look at it and build upon it. i know some people that would be really interested in it.
[20:52:56] <gabewillen> Im really close, i would say by the end of this week i will have it mostly documented, and push it
[20:53:09] <memleak> into rtos-master-v0 ??
[20:53:18] <memleak> or something.?
[20:53:34] <gabewillen> It doesn't matter to me, where ever you all would like me to
[20:54:12] <memleak> well some of the devs don't really want the rest of the world to know how it all works, just so you're aware, you might have to resort to pushing it to a 3rd party site.
[20:54:32] <gabewillen> I wrapped rtapi_mutex_get and rtapi_mutex_release, and implemented python's with statement
[20:54:45] <memleak> they enjoy keeping the code obscure, just a heads up, so github might be your only option.
[20:54:46] <gabewillen> you can use with mutex:
[20:55:45] <gabewillen> I would have to agree debugging should be a main issue, this was a challenging task . Most of the time i had to guess at what was causing the seg faults
[20:56:23] <memleak> I'm sure it was meant to be challenging.
[20:56:46] <gabewillen> I'm interested in seeing what happens if i change pointer locations in some of the hal structs
[20:56:57] <memleak> "How far can I go here without violating the GPL" is how I see most of the rtapi code now. *shrug*
[20:57:02] <gabewillen> i want to be able to monitor the hal pins without polling
[20:57:35] <gabewillen> RTAPI is lgpl
[20:57:41] <gabewillen> LGPL*
[20:58:19] <gabewillen> Not as bad... How far should i go? should i attempt to re-write more than what i have?
[20:58:58] <memleak> I think if you could debug whatever it is using backtraces and gdb, you're fine.
[20:59:22] <gabewillen> How much has to change to re-license it
[20:59:44] <memleak> It's just a very old fashioned, tried and tired method of debugging things, and it never really fails.
[21:00:00] <memleak> I have no idea..
[21:00:11] <gabewillen> google just re-wrote the java-vm almost verbatim and won there lawsuit
[21:00:24] <gabewillen> Simply by retyping the code
[21:00:28] <memleak> I would assume a lot but I'm not a lawyer.
[21:00:54] <memleak> Maybe #gnu might be able to help, not sure. What do you want to license it under? GPLv3?
[21:01:06] <gabewillen> Public Domain
[21:01:15] <gabewillen> or apache
[21:01:44] <gabewillen> I want people to do with it what they please
[21:02:04] <gabewillen> I guess i will look into this week
[21:02:22] <memleak> GPLv3 would be a stronger benefit at least to me and some other people I'm working with.
[21:02:43] <gabewillen> i was just mainly coming on to ask about the plans of loading and unloading components
[21:03:27] <memleak> the usual way right now is through what? halcmd?
[21:03:47] <gabewillen> No this will replace it but, there is either the module_helper, or rtapi_app
[21:04:08] <memleak> well if rtapi_app gets re-written and isn't an absolute trainwreck, rtapi_app
[21:04:16] <gabewillen> that is what halcmd uses, it forks and executes one of those two binaries
[21:05:02] <memleak> module_helper i haven't looked into enough.. i would assume newer and more unstable.
[21:05:15] <gabewillen> No older for sure
[21:05:28] <memleak> hmm... not sure then.
[21:05:32] <gabewillen> its been around since i have been using LCNC for about 4 years
[21:05:52] <memleak> whatever one you believe would be more stable and cause less issues.
[21:06:19] <memleak> if it's going to be rtapi_app it'll need a lot of re-writing. module_helper might need less work.
[21:06:32] <memleak> since it's older then, it should be more stable as well.
[21:06:42] <memleak> unless of course you have a bad experience with it..
[21:07:03] <memleak> I'm new to LCNC so i'm not really the one to ask.
[21:07:17] <gabewillen> No works flawlessly, i believe its just a hack to allow loading kernel modules without root
[21:07:41] <memleak> gabewillen, it can't be more of a hack than rtapi_app
[21:07:41] <gabewillen> if cradek could chime in and correct me if im wrong
[21:08:07] <memleak> unless it causes a huge security risk, who cares.
[21:08:24] <memleak> The idea is to have something that works..
[21:08:47] <gabewillen> I just quickly read module_helper.c.
[21:08:55] <gabewillen> its just a script to invoke insmod
[21:09:16] <memleak> so it's small and easy to work with basically.
[21:09:21] <gabewillen> yes
[21:09:29] <memleak> i don't see why you'd not want to use that then.
[21:09:34] <gabewillen> just using execve
[21:10:07] <memleak> technically rtapi_app loads modules too without root (make setuid) since you aren't running sudo latency-test and sudo linuxcnc
[21:10:09] <gabewillen> very small... i have been testing using linux rt signals
[21:12:09] <memleak> If anything breaks it means a person won't need to open up 20 folders and separate .c files to fix anything either.
[21:12:35] <memleak> like how rtapi_app is right now... hence why i don't want to touch that with a 10 foot pole.
[21:12:52] <gabewillen> rtapi_app uses dlopen i believe
[21:13:26] <memleak> dlopen has its issues too.
[21:14:03] <gabewillen> well unfortunately its what i am using to manipulate libpyhal
[21:14:17] <gabewillen> Haven't had any issue's that i didn't cause
[21:14:42] <memleak> perhaps its how rtapi_app uses it then
[21:14:55] <memleak> your code is obviously much better :P
[21:15:35] <gabewillen> Its actually very small as of right now
[21:15:42] <gabewillen> if you don't count the gui
[21:16:03] <memleak> KISS -> Keep it simple, stupid :)
[21:16:19] <gabewillen> I try to write as efficiently as possible
[21:16:19] <memleak> a great principle really
[21:16:44] <gabewillen> I re-wrote the rip-environment
[21:17:03] <gabewillen> implemented it directly into this. It can tell what build your using
[21:17:11] <memleak> gabewillen, I congratulate you on a job well done..
[21:17:22] <memleak> like seriously, THANK YOU!
[21:17:59] <gabewillen> Don't thank me yet, it needs some serious testing and more experienced coder's opinions
[21:17:59] <memleak> I'll be glad to test it and build upon it!
[21:18:01] <gabewillen> I have only been programming for about 2 years
[21:18:21] <memleak> No matter how far it is behind, I'll try my hardest to get it to where it needs to be.
[21:19:05] <gabewillen> Okay i need to get back to it... writing decorators for wrapping pins
[21:19:07] <memleak> I much rather work on your stuff than what mhaberler and zultron have been doing lately. I really appreciate someone taking the time to clean up their mess.
[21:19:20] <memleak> It means a lot! :D
[21:20:02] <memleak> I'll try and help with whatever you need too, once it's published I'll start working away on it.
[21:20:17] <memleak> You got me on your side :)
[21:20:21] <gabewillen> Those two have been doing great, really pushing the new kernels
[21:21:11] <memleak> Rather a concept of new kernels ;)
[21:21:53] <gabewillen> True... I think when i finish this up im gong to jump on improving rt-preempt
[21:22:16] <memleak> 3.x kernels with RTAI already work on the master branch and v2.5_branch
[21:22:33] <memleak> all they really did was add a stub to preempt_rt and some xenomai work for the beaglebone,
[21:22:55] <gabewillen> I couldn't get rtai to work on any 3.x kernel, as of 6 months ago
[21:23:00] <cradek> memleak: that is news to me. do you have it written up somewhere?
[21:23:09] <gabewillen> I haven't checked since then
[21:23:20] <memleak> cradek: what did i say?
[21:23:35] <cradek> the part about 3.x kernels with RTAI already work on the master branch and v2.5_branch
[21:23:44] <memleak> ah, yeah it works with my fork of RTAI.
[21:23:54] <gabewillen> link?
[21:23:59] <memleak> havent tested the official magma branch, seb_kuzminsky did though back in feb of this year
[21:24:14] <cradek> yeah, he crashed his machine with it :-/
[21:24:24] <memleak> it did?
[21:24:27] <memleak> weird..
[21:24:29] <cradek> yeah, it was weird in some way
[21:24:32] <gabewillen> cradek, how do you feel about module_helper vs rtapi_app?
[21:24:37] <memleak> gabewillen:
https://github.com/ShabbyX/RTAI
[21:24:45] <gabewillen> vs something completely new
[21:24:54] <memleak> It's a work in progress, hasn't been tested on 64-bit in a few weeks.
[21:25:16] <memleak> if you get a build error let me know, I'm the lead maintainer essentially of that branch.
[21:25:41] <cradek> gabewillen: I don't have a useful answer to that question
[21:25:57] <memleak> gabewillen, module_helper please :)
[21:25:59] <cradek> memleak: awesome, what kernel versions are known to work?
[21:26:16] <memleak> 3.4.53 is the most stable atm
[21:26:33] <gabewillen> maybe i'll take that question to the mailing list
[21:26:34] <memleak> 3.5.7 might work but hasnt been tested with that branch in about a month.
[21:27:06] <memleak> avoid 3.8.13 it's not for linuxcnc, just raw RTAI support.
[21:27:40] <gabewillen> I feel what i have done, will be not adopted by most, when i asked if i should do this most people said not to "re-invent the wheel"
[21:27:56] <gabewillen> will not be* sorry im talking like yoda
[21:28:00] <memleak> who said that?
[21:28:25] <memleak> in my opinion, the current wheel sucks..
[21:28:39] <gabewillen> i personally can't stand the expression
[21:28:56] <gabewillen> If we all had that attitude we would be writing stone wheeled wagons
[21:29:02] <gabewillen> riding*
[21:29:06] <memleak> exactly!
[21:29:40] <gabewillen> Im a firm believer in if it aint broke, break it and make it better
[21:30:00] <memleak> and what you have done, even though i haven't seen the code myself, sounds a lot better than where the current RTOS code is at
[21:30:17] <memleak> gabewillen, that's the mentality you need with a project like this.
[21:30:53] <memleak> Note that a few devs might advise against your efforts, but just tell yourself that they're wrong, and you're doing the right thing.
[21:30:54] <gabewillen> i haven't touched any of the rtapi code to be honost, besides wrapping a few __inline__ functions that i needed
[21:31:21] <gabewillen> Mainly the hal/halcmd code
[21:31:29] <memleak> so it's not too late to use module_helper then.
[21:31:53] <memleak> if you want code efficiency and ease, go with that.
[21:32:04] <gabewillen> its never to late to do anything... i delete stuff and start over very effeciently
[21:32:15] <gabewillen> and frequently
[21:32:42] <gabewillen> i'm sorry my grammer and spelling is horrible, i can't focus on two things at once
[21:33:11] <memleak> Not many grammar nazis in #linuxcnc-devel
[21:33:26] <memleak> you're fine :)
[21:34:02] <gabewillen> Whats nice about python is a segfault usually won't take down the entire system... just the python vm
[21:34:38] <gabewillen> Also since the gil is released for every C call
[21:34:51] <memleak> is module_helper and rtapi_app both in C?
[21:34:53] <gabewillen> It performs nicely
[21:35:00] <memleak> i never really looked at the linuxcnc code.
[21:35:01] <gabewillen> yes
[21:35:11] <gabewillen> i have been staring at it for way to long
[21:35:16] <memleak> heh!
[21:35:45] <gabewillen> i am addicted to programming
[21:36:13] <memleak> this is why we need simplicity, so people such as yourself can look at the code, and not get insta-migraine
[21:36:54] <gabewillen> Most of the hal stuff is very well written, and easy to understand... Plus there is nothing i can't figure out
[21:37:11] <memleak> i was referring to rtapi_app
[21:37:28] <memleak> trying to convince you to use module_helper :P
[21:38:12] <gabewillen> well rtapi_app is written in c++
[21:38:47] <gabewillen> I will probably just write a new one entirely
[21:39:04] <memleak> or that.. :)
[21:39:08] <gabewillen> since module_helper is just passing commands to os.execve
[21:39:19] <gabewillen> and rtapi_app is using dlopen
[21:39:25] <memleak> just avoid rtapi_app please, whatever you do.
[21:40:57] <memleak> cradek: if you have a specific 3.x kernel you'd like to have working, let me know and i'll write a kernel patch.
[21:41:32] <memleak> cradek: I've added about 10 kernels total to the RTAI tree since I started working on it.
[21:41:41] <memleak> I'm up for suggestions.
[21:42:25] <gabewillen> What kernel should i use on your rtai branch? im going to install it on kvm
[21:42:43] <memleak> 3.4.53
[21:43:06] <memleak> i dont think RTAI works with kvm though.. terrible latencies might occur.
[21:43:38] <memleak> no virtualization works the best for RT systems, plus my branch has simlation support removed.
[21:43:49] <memleak> *simulation
[21:44:10] <gabewillen> Im just testing it, not using it in a production environment
[21:44:25] <memleak> this freaking U key is broken on my keyboard.. trying not to smash it with a sledge hammer
[21:44:51] <gabewillen> my j key broke a few weeks ago
[21:44:56] <gabewillen> so i took my z key
[21:45:02] <memleak> HEH!
[21:45:30] <memleak> yeah you never really need to use the z key.. i hardly ever press it..
[21:45:32] <gabewillen> but i now i have a wireless keyboard on top of my laptops, i just used xinput and floated the laptop keyboard
[21:45:41] <gabewillen> you do i C programming lol, for size
[21:46:21] <memleak> use a macro, change size to matter
[21:47:05] <memleak> or auto-replace or sed
[21:47:16] <gabewillen> So what do you use lcnc for?
[21:47:58] <memleak> i personally don't use it, i just get it working with other distros so i can provide it to businesses without having to ship an ubuntu box.
[21:48:47] <memleak> i don't do any kind of machining or hardware work at all, i just do the software and send it off
[21:49:06] <memleak> i'm a software contractor. :)
[21:49:09] <gabewillen> ah, i am working on a directfb thin client gui for linux. To allow shipping lcnc with no X
[21:49:35] <memleak> isnt there a replacement for directfb?
[21:50:05] <memleak> vmwgfx, libkms or something?
[21:50:59] <memleak> actually i think GPU KMS can do the same things as directfb using fbcon.. not sure
[21:51:20] <gabewillen> They all use fbcon
[21:51:32] <gabewillen> I actually am a machinist by trade
[21:52:05] <memleak> gabewillen, do you use gpm for X-less LCNC?
[21:52:11] <memleak> or tab and arrow keys?
[21:52:57] <gabewillen> about 4 years ago i was trained on cnc's, started writing macro's for them. Taught my self how to use solidworks, designed and built my own cnc milling machine from scratch, started a custom machine design company, started programming to write interfaces. Once i started programming everything else went to the way side
[21:53:20] <gabewillen> All i want to do now is write software
[21:53:50] <memleak> heh, and after working on software for the past few years I want to work on cars and never touch a computer again except for an OBD II reader..
[21:54:22] <gabewillen> But i still work as a machinist im converting machines at my company to cnc's to save on cost. So i use lcnc in a non traditional since
[21:54:25] <gabewillen> mostly use hal
[21:54:32] <gabewillen> sense*
[21:55:15] <gabewillen> Good ol obd2, i went through my car phase
[21:55:39] <gabewillen> had an 85 z28, rebuilt and stroked a 1994 z28 camaro, then owned a 2000 ss
[21:56:25] <memleak> my favorite out of those three is probably a 2000 SS
[21:56:39] <gabewillen> Yeah the ls1 was and still is a great motor
[21:56:53] <memleak> I'll be working on a 99 vw passat in the next few weeks.
[21:57:02] <gabewillen> now i have an suv :) and for speed i just drive my r6
[21:57:52] <gabewillen> i don't have to much time left with the bike since, my wife and i agree'd i would sell it when we have kids.
[21:58:07] <gabewillen> luckily i keep pushing that off :)
[21:58:50] <memleak> I like the YZF-R1 better :P
[21:59:11] <gabewillen> couldn't afford that when i bought this one... hell i couldn't afford this one when i bought this one
[21:59:49] <gabewillen> Okay i need to get back to work on this... whats your email
[21:59:51] <memleak> I'm more of a ducati fan than anything. the 1198 Panigale.. mmmmmm
[22:00:08] <gabewillen> i'll shoot you an early release of this, and see if you think im going in the right direction
[22:00:29] <memleak> Check your PM :)