Back
[00:41:05] <CIA-38> EMC: 03cmorley 07v2.4_branch * r49cf0fac9873 10/src/emc/usr_intf/pncconf/pncconf.py: Add more firmware fix problem it creates
[01:24:29] <mozmck-6core> has anyone seen latency-test just show 0 for everything?
[01:27:20] <jepler> mozmck_work: that means it's not working. the rtai latency test works by writing some numbers to a shared memory, which the userspace program reads and prints from time to time. If it's all zeros, the realtime part isn't running at all.
[01:29:02] <mozmck-6core> ok. I had the hard memlock 20480 line in limits.conf, but I was getting errors saying there was only 64k available.
[01:29:33] <mozmck-6core> So I added a line with soft memlock 20480 and now it runs but just shows 0
[01:29:59] <mozmck-6core> I've rebooted (more than once) and that hasn't helped. Any ideas?
[01:45:56] <mozmck-6core> why would my package of emc2 here depend on nvidia-current?
[01:56:34] <mozmck-6core> hmm, looks like the rtai kernel latency test runs... brb
[02:06:04] <cradek> mozmck-6core: maybe nvidia-current is an auto dependency because of your gl shlibs
[02:07:12] <mozmck-6core> interesting. I'll have to figure out how to prevent that. I rebuilt packages on another computer and will try them here. They run fine there.
[02:07:32] <cradek> yeah it's definitely wrong to have that dependency
[02:08:04] <mozmck-6core> nope latency-test still just show 0's
[02:08:13] <cradek> we have libgl1-mesa-dev | libgl1-mesa-swx11-dev
[02:08:32] <cradek> maybe that needs another | for nvidia-*
[02:09:06] <mozmck-6core> oh, that could be.
[02:09:17] <cradek> (I'm just guessing)
[02:09:32] <mozmck-6core> nvidia-current for ubuntu 10.04 anyhow.
[02:09:49] <cradek> I think there are several nvidia-* that might be encountered
[02:09:54] <mozmck-6core> any guesses why the realtime stuff won't start here?
[02:10:18] <cradek> doing rtai's own tests?
[02:12:10] <mozmck-6core> hmm, I could run rtai's kern latency test, but user latency says CANNOT INIT MASTER TASK
[02:14:30] <mozmck-6core1> heh, computer locked up.
[02:14:35] <cradek> yuck
[02:15:47] <mozmck-6core1> looks like neither kern nor user tests work now.
[02:19:27] <mozmck-6core1> I think I'll upload the kernel and packages I have right now, and others can start testing them. I'll troubleshoot this computer some more later.
[02:19:43] <cradek> oh it's just one machine that doesn't work?
[02:20:10] <mozmck-6core1> looks like. my new 6core machine.
[02:20:46] <mozmck-6core1> I can run the kernel, but the realtime stuff seems to fail.
[02:21:02] <cradek> weird
[02:22:05] <mozmck-6core1> yeah. at first it was giving errors about shmem like it didn't have the hard memlock set in limits.conf.
[02:22:52] <mozmck-6core1> but it was there and I had rebooted. So I added soft memlock 20480 and then latency-test would run, but everything shows 0
[02:32:51] <jepler> cradek: no, the solution is that if building with nvidia installed makes a broken package, you add build-conflicts: nvidia and too bad for anybody that inconveniences.
[02:33:57] <cradek> is it wrong of us to have a libgl1-mesa-dev | libgl1-mesa-swx11-dev dependency?
[02:34:37] <jepler> as a build dependency? absolutely not. you have to have the headers provided by those packages
[02:35:19] <jepler> it sounds like merely as a consequence of having the nvidia drivers installed, dh_shlibdeps found a bogus dependency on the nvidia drivers on mozmck's system -- i.e., having nvidia installed generated a broken package.
[02:35:23] <jepler> that's build-conflicts
[02:36:08] <mozmck-6core1> I'm going to disable/remove the nvidia driver and see if that helps anything.
[02:36:14] <mozmck-6core1> bbl
[03:13:57] <mozmck-6core1> Ok, there are some packages at
http://www.linuxcnc.org/mozmck/ if anyone is brave enough to try them.
[03:22:38] <Dave911> I was able to get the ClassicLadder Modbus RTU serial working without needing any delays in the comm routines. The delay setting "pause after transmit" was covering up some programming errors as I suspected. If the read () from the comm port did not grab a complete Modbus response frame, the response was incomplete and failed the CRC check. No attempt was being made to read the...
[03:22:40] <Dave911> ...unreceived part of the frame via subsequent read () s. I found several other errors also. I need to test all of the read and write functions still.
[03:34:39] <SWPadnos> Dave911, that actually sounds like correct behavior, if the select is working correctly
[03:35:29] <SWPadnos> though in that case the timeout is from the time the read attempt is started, rather than between bytes (which is more common, I think)
[03:36:36] <SWPadnos> maybe there should be a loop that repeats as long as the number of bytes received is >0
[03:36:49] <SWPadnos> (and concatenates the received bytes, of course)
[03:40:17] <Dave911> The program was doing what it was programmed to do .. just wasn't right
[03:40:27] <Dave911> The loop thing is what I put in ..
[03:40:32] <SWPadnos> well, it kind of was right
[03:40:39] <SWPadnos> the timeout is how long it waits for a response
[03:40:46] <Dave911> Kinda ;-)
[03:40:52] <SWPadnos> if the response hasn't arrived (in full) in that amount of time, it's too late
[03:41:03] <Dave911> It was worse than that ...
[03:41:11] <SWPadnos> so you should have been able to fix it by increasing the timeout
[03:41:31] <Dave911> If the time delay wasn't in there so the full response was in the buffer it would not grab the message
[03:41:44] <SWPadnos> but I don't know if you could have gone past 1 second, due to the way it handled the conversion from deciseconds to the tv struct
[03:41:46] <Dave911> I tried increasing the timeout .... didn't work
[03:41:58] <SWPadnos> oh, well that's a bug for sure :)
[03:42:10] <Dave911> Everything is less than 1 second ..
[03:42:23] <Dave911> Some of the termios stuff is not well documented ..
[03:42:26] <SWPadnos> yeah, the default was 500ms or something
[03:42:28] <SWPadnos> heh
[03:42:31] <SWPadnos> you noticed :)
[03:42:37] <SWPadnos> it's also not needed, I think
[03:42:45] <Dave911> I found different explanations for select that were really different
[03:43:03] <SWPadnos> hmmm
[03:43:04] <Dave911> The man pages are really not complete IMO
[03:43:10] <SWPadnos> that doesn't seem right
[03:43:38] <Dave911> Yeah .... I
[03:43:59] <Dave911> couldn't really find one definitive source for termios info
[03:44:16] <Dave911> I wonder if that is because it was unix ported to linux etc
[03:44:19] <SWPadnos> select isn't part of termios though
[03:44:33] <Dave911> Oh .. you are right ... very true
[03:44:48] <Dave911> Huh ..
[03:46:00] <Dave911> Well .. all I can say is that I have worked with comm routines in Windows, and dos using libraries etc .. and seems like there are more flavors/variations of either understanding of the functions or I don't know ...
[03:46:50] <Dave911> I have a hard time telling you why .... as I haven't quite figured it out myself ..
[03:47:06] <SWPadnos> yeah, I've used Windows and DOS comms libraries a lot as well (greenleaf, WIN native, direct to port ...)
[03:47:41] <SWPadnos> take a look at the modbus.h/c that's used for gs2_vfd. it seemed pretty simple and clear
[03:48:02] <SWPadnos> only problem with that library was that it liked to print errors when there were timeouts, a big no-no in my book
[03:48:29] <Dave911> I looked at that one and stole some ideas out of that .. but that code is a lot different still better than the classic ladder modbus I think..
[03:48:30] <SWPadnos> (and later versions are GPL3, so I didn't want to update to those since I don't know what it does to other emc2 licensing)
[03:48:40] <SWPadnos> I think so
[03:49:10] <SWPadnos> there were two "major" free modbus libraries, I think CL may have based off the bad one :)
[03:49:55] <Dave911> The classic ladder code ... some of it looks like he wrote a lot ... added code until it worked .. and then stopped without really completing parts of it ..
[03:50:03] <Dave911> I didn't know that ..
[03:51:31] <Dave911> Oh well .. I'll fix this up and send a patch to whoever can review it .. Perhaps Chris Morely and perhaps we can just fix it ..
[03:51:33] <SWPadnos> ah yes. both called "libmodbus", of course :)
[03:51:39] <SWPadnos> one from pes.free.fr, which is the bad one
[03:51:54] <SWPadnos> one that's now on launchpad:
https://launchpad.net/libmodbus
[03:52:00] <SWPadnos> that's the one I used for gs2_vfd
[03:52:10] <Dave911> ok..
[03:52:15] <SWPadnos> (after making the stupid printing optional and not chosen)
[03:52:26] <SWPadnos> there's another one that's more commercial, but I think still free
[03:52:44] <SWPadnos> oh wait, maybe not
[03:52:48] <SWPadnos> http://www.modbus.org/tech.php
[03:52:54] <SWPadnos> lots of info there
[03:53:38] <Dave911> I've done Modbus drivers before and there isn't that much to them, that is why I was surprised that the CL one was screwed up like it is/was.
[03:53:53] <Dave911> 90% of it is ok I think..
[03:53:59] <SWPadnos> it's actually pretty hard to get all the details of serial communications working well
[03:54:12] <Dave911> Very tedious
[03:54:18] <SWPadnos> working at all is easy, but detecting and responding to errors is another story
[03:54:28] <Dave911> very true
[03:54:46] <SWPadnos> so a lot of peopl;e probably stop shortly after "barely working" :)
[03:55:20] <Dave911> That is where the Modbus in CL was ...really..
[03:56:23] <Dave911> I'd like to port over the newer CL and get that into EMC2. The newest graphics for the ladder are much nicer. I think that Chris started on it, but probably wore out on it for a while
[03:56:30] <SWPadnos> anyway, glad you found a fix
[03:56:42] <Dave911> I think he thought that the modbus might not be worth fixing
[03:56:43] <SWPadnos> I can imagine
[03:57:32] <Dave911> Yeah, I need to do more testing but it is getting there pretty quickly. I need it for a project and I want it to be bullet proof ..
[03:59:55] <SWPadnos> oh jesus christ. can't you look at code on sourceforge any more?
[04:00:18] <Dave911> what ??
[04:00:40] <Dave911> how so ..
[04:00:40] <SWPadnos> maybe the CL folks have disabled CV/SVN browsing or somethign
[04:00:42] <SWPadnos> ng
[04:01:15] <Dave911> I pulled a tarball off of sourceforge for the latest
[04:01:34] <Dave911> Looks like the work on CL has slowed down a lot
[04:01:43] <SWPadnos> is the license still LGPL V2?
[04:02:11] <Dave911> I think I saw LGPL but don't know about version
[04:02:25] <SWPadnos> hmmm. wouldn't hurt to check.
[04:02:29] <Dave911> one moment and I will look..
[04:02:38] <SWPadnos> I think GPL3 is (a) super-viral and (b) not what we want
[04:02:48] <SWPadnos> which is why I skipped libmodbus 2.x
[04:03:00] <SWPadnos> (possibly erroneously)
[04:03:35] <Dave911> v2.1 of the LGPL
[04:03:51] <SWPadnos> ok, that's good
[04:04:14] <Dave911> what do you mean by super viral - popular?
[04:04:19] <SWPadnos> no
[04:04:46] <SWPadnos> that you can't use GPL3 code in a GPL2 project, the whole project (or all affected code or something) has to be GPL3
[04:04:49] <cradek> gpl3 and gpl2 are incompatible
[04:05:11] <Dave911> wow, that is bad ....
[04:05:38] <SWPadnos> intentional, I think
[04:05:49] <SWPadnos> I think they're saying "pick one"
[04:06:07] <Dave911> OK ...
[04:06:26] <Dave911> I need to study those license further ..
[04:06:26] <morfic> just means you may lose out on libraries that would be good for you if your project use one and the lib the other
[04:06:58] <Dave911> that sucks
[04:07:16] <SWPadnos> http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
[04:09:03] <Dave911> what is the point of the LGPL licenses versus the GPL licenses ??
[04:09:11] <SWPadnos> it may be possible to make the things that use lgpl3 code "GPLv2 or later" (like gs2_vfd)
[04:09:22] <SWPadnos> libraries (or lesser) vs. programs
[04:09:49] <SWPadnos> slightly less restrictive, but you'd have to read them for yourself to find out how ;)
[04:12:34] <Dave911> Well I think I will do some more testing and try and break this code .. :-)
[04:12:51] <SWPadnos> good luck
[04:12:53] <SWPadnos> and good night :0
[04:13:13] <Dave911> Thanks .. good night :-)
[05:04:52] <CIA-38> EMC: 03cmorley 07v2.4_branch * rc26a08d1535a 10/src/emc/usr_intf/pncconf/pncconf.py: fix clearing of mesa components
[16:04:12] <SWPadnos> wow, how cheap for a touchscreen:
http://accessories.us.dell.com/sna/products/Displays/productdetail.aspx?c=us&l=en&s=dhs&cs=19&sku=320-1172
[16:07:57] <cradek> that is cheap, but I curse the recent reduction from 1200 to 1080 lines on monitors
[16:08:16] <SWPadnos> yes, it is an annoyance
[16:08:37] <SWPadnos> I'm also bummed that the 2048x1152 resolution didn't take off
[16:08:55] <SWPadnos> the Samsung 23" I got at that resolution is a very nice monitor
[16:09:53] <SWPadnos> strangely, Dell has on e that's 2560x1440 (the 16:9 version of 2560x1600)
[16:10:37] <SWPadnos> http://accessories.us.dell.com/sna/products/Displays/productdetail.aspx?c=us&l=en&s=dhs&cs=19&sku=224-8284
[16:10:46] <SWPadnos> not cheap though :)
[16:26:57] <CIA-38> EMC: 03jepler 07v2.4_branch * r41c8ee3e19ff 10/ (2 files in 2 dirs): Fix hm2 stepgen.enable=0 behavior
[16:49:50] <dgarr> mozmck: positive test of your lucid kernel on two machines:
http://www.panix.com/~dgarrett/stuff/sl510.rtai.lucid.txt
[16:50:08] <dgarr> http://www.panix.com/~dgarrett/stuff/k9mm-v.rtai.lucid.txt
[20:25:55] <cradek> arg, what have I done to my git?
http://pastebin.com/YasWFnVT
[20:34:51] <alex_joni> oops
[20:39:34] <jepler> ow indeed
[20:39:57] <jepler> $ git cat-file -t b78532ff405a29b11f8122596eabcd50a3e51e28
[20:39:57] <jepler> tree
[20:40:33] <jepler> that is something that is in the shared history so if only I could figure out how I could send it to you
[20:42:57] <jepler> of course that git-fsck error may just be the first of many :-/
[20:53:35] <cradek> do you also have 63426a55566a9fa535fd62cc627e080e8d9c3494
[20:55:10] <jepler> http://emergent.unpy.net/files/sandbox/objects.tar.gz
[20:55:25] <jepler> any idea what happened? full drive? weird shit?
[20:55:50] <cradek> not a full drive. I don't know of anything weird that I did.
[20:56:12] <jepler> you done 2.4 on your lathe yet?
[20:56:17] <cradek> nope
[20:56:24] <cradek> bad me
[20:56:54] <cradek> seems like only those two objects were bad.
[20:57:12] <cradek> git fsck / git repack succeeded
[20:57:30] <jepler> that's pleasant news
[20:57:46] <cradek> chris@rover2:~/emc2.trunk$ git --version
[20:57:47] <cradek> git version 1.7.0.4
[20:57:53] <cradek> this is now a version I don't trust
[20:58:05] <jepler> commit 63426a55566a9fa535fd62cc627e080e8d9c3494
[20:58:05] <jepler> Author: Michael Geszkiewicz <micges@wp.pl>
[20:58:05] <jepler> Date: Sat Dec 12 12:46:41 2009 +0100
[20:58:05] <jepler> Fix Axis to load programs with G43 and G43.1
[20:58:51] <jepler> and tree b78532ff405a29b11f8122596eabcd50a3e51e28 is a directory of src/libnml/inifile of unknown vintage
[20:59:45] <cradek> well I ruined any evidence I had...
[21:00:07] <jepler> oh well
[21:02:28] <cradek> [153913.917223] ecryptfs_read_and_validate_header_region: Error reading header region; rc = [-4]
[21:02:32] <cradek> [153913.917255] Valid eCryptfs headers not found in file header region or xattr region
[21:02:35] <cradek> [153913.917267] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO
[21:02:38] <cradek> uh wut
[21:02:57] <cradek> might be my encrypted home directory and/or ext4
[21:03:01] <jepler> great
[21:03:10] <cradek> or hardware
[21:03:13] <cradek> who knows
[21:07:15] <alex_joni> it's called evolution
[21:07:26] <alex_joni> not a day goes by that we understand PCs less
[21:09:08] <jepler> https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/372014
[21:09:15] <jepler> well, dozens of people get errors like those
[21:11:10] <cradek> This situation occurs when 0-byte files are created in the underlying filesystem.
[21:12:40] <jepler> well I take some of the facts presented there with grains of salt
[21:12:49] <cradek> I do have a single 0-byte file there
[23:12:07] <mozmck> interesting, Looks like dgarr had to add the line: * soft memlock 20480 to his limits.conf file to get emc to run.
[23:12:39] <mozmck> I had to do that on one machine, but not a couple of others. why could that be?
[23:19:35] <cradek> do they have a different amount of ram? maybe the default is proportional, not fixed