EMC: 03cmorley 07v2.4_branch * r49cf0fac9873 10/src/emc/usr_intf/pncconf/pncconf.py: Add more firmware fix problem it creates
has anyone seen latency-test just show 0 for everything?
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.
ok. I had the hard memlock 20480 line in limits.conf, but I was getting errors saying there was only 64k available.
So I added a line with soft memlock 20480 and now it runs but just shows 0
I've rebooted (more than once) and that hasn't helped. Any ideas?
why would my package of emc2 here depend on nvidia-current?
hmm, looks like the rtai kernel latency test runs... brb
mozmck-6core: maybe nvidia-current is an auto dependency because of your gl shlibs
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.
yeah it's definitely wrong to have that dependency
nope latency-test still just show 0's
we have libgl1-mesa-dev | libgl1-mesa-swx11-dev
maybe that needs another | for nvidia-*
oh, that could be.
(I'm just guessing)
nvidia-current for ubuntu 10.04 anyhow.
I think there are several nvidia-* that might be encountered
any guesses why the realtime stuff won't start here?
doing rtai's own tests?
hmm, I could run rtai's kern latency test, but user latency says CANNOT INIT MASTER TASK
heh, computer locked up.
looks like neither kern nor user tests work now.
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.
oh it's just one machine that doesn't work?
looks like. my new 6core machine.
I can run the kernel, but the realtime stuff seems to fail.
yeah. at first it was giving errors about shmem like it didn't have the hard memlock set in limits.conf.
but it was there and I had rebooted. So I added soft memlock 20480 and then latency-test would run, but everything shows 0
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.
is it wrong of us to have a libgl1-mesa-dev | libgl1-mesa-swx11-dev dependency?
as a build dependency? absolutely not. you have to have the headers provided by those packages
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.
I'm going to disable/remove the nvidia driver and see if that helps anything.
Ok, there are some packages at http://www.linuxcnc.org/mozmck/
if anyone is brave enough to try them.
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...
...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.
Dave911, that actually sounds like correct behavior, if the select is working correctly
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)
maybe there should be a loop that repeats as long as the number of bytes received is >0
(and concatenates the received bytes, of course)
The program was doing what it was programmed to do .. just wasn't right
The loop thing is what I put in ..
well, it kind of was right
the timeout is how long it waits for a response
if the response hasn't arrived (in full) in that amount of time, it's too late
It was worse than that ...
so you should have been able to fix it by increasing the timeout
If the time delay wasn't in there so the full response was in the buffer it would not grab the message
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
I tried increasing the timeout .... didn't work
oh, well that's a bug for sure :)
Everything is less than 1 second ..
Some of the termios stuff is not well documented ..
yeah, the default was 500ms or something
you noticed :)
it's also not needed, I think
I found different explanations for select that were really different
The man pages are really not complete IMO
that doesn't seem right
Yeah .... I
couldn't really find one definitive source for termios info
I wonder if that is because it was unix ported to linux etc
select isn't part of termios though
Oh .. you are right ... very true
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 ...
I have a hard time telling you why .... as I haven't quite figured it out myself ..
yeah, I've used Windows and DOS comms libraries a lot as well (greenleaf, WIN native, direct to port ...)
take a look at the modbus.h/c that's used for gs2_vfd. it seemed pretty simple and clear
only problem with that library was that it liked to print errors when there were timeouts, a big no-no in my book
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..
(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)
I think so
there were two "major" free modbus libraries, I think CL may have based off the bad one :)
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 ..
I didn't know that ..
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 ..
ah yes. both called "libmodbus", of course :)
one from pes.free.fr, which is the bad one
one that's now on launchpad: https://launchpad.net/libmodbus
that's the one I used for gs2_vfd
(after making the stupid printing optional and not chosen)
there's another one that's more commercial, but I think still free
oh wait, maybe not
[03:52:48] <SWPadnos> http://www.modbus.org/tech.php
lots of info there
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.
90% of it is ok I think..
it's actually pretty hard to get all the details of serial communications working well
working at all is easy, but detecting and responding to errors is another story
so a lot of peopl;e probably stop shortly after "barely working" :)
That is where the Modbus in CL was ...really..
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
anyway, glad you found a fix
I think he thought that the modbus might not be worth fixing
I can imagine
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 ..
oh jesus christ. can't you look at code on sourceforge any more?
how so ..
maybe the CL folks have disabled CV/SVN browsing or somethign
I pulled a tarball off of sourceforge for the latest
Looks like the work on CL has slowed down a lot
is the license still LGPL V2?
I think I saw LGPL but don't know about version
hmmm. wouldn't hurt to check.
one moment and I will look..
I think GPL3 is (a) super-viral and (b) not what we want
which is why I skipped libmodbus 2.x
v2.1 of the LGPL
ok, that's good
what do you mean by super viral - popular?
that you can't use GPL3 code in a GPL2 project, the whole project (or all affected code or something) has to be GPL3
gpl3 and gpl2 are incompatible
wow, that is bad ....
intentional, I think
I think they're saying "pick one"
I need to study those license further ..
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:07:16] <SWPadnos> http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
what is the point of the LGPL licenses versus the GPL licenses ??
it may be possible to make the things that use lgpl3 code "GPLv2 or later" (like gs2_vfd)
libraries (or lesser) vs. programs
slightly less restrictive, but you'd have to read them for yourself to find out how ;)
Well I think I will do some more testing and try and break this code .. :-)
and good night :0
Thanks .. good night :-)
EMC: 03cmorley 07v2.4_branch * rc26a08d1535a 10/src/emc/usr_intf/pncconf/pncconf.py: fix clearing of mesa components
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
that is cheap, but I curse the recent reduction from 1200 to 1080 lines on monitors
yes, it is an annoyance
I'm also bummed that the 2048x1152 resolution didn't take off
the Samsung 23" I got at that resolution is a very nice monitor
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
not cheap though :)
EMC: 03jepler 07v2.4_branch * r41c8ee3e19ff 10/ (2 files in 2 dirs): Fix hm2 stepgen.enable=0 behavior
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
arg, what have I done to my git? http://pastebin.com/YasWFnVT
$ git cat-file -t b78532ff405a29b11f8122596eabcd50a3e51e28
that is something that is in the shared history so if only I could figure out how I could send it to you
of course that git-fsck error may just be the first of many :-/
do you also have 63426a55566a9fa535fd62cc627e080e8d9c3494
[20:55:10] <jepler> http://emergent.unpy.net/files/sandbox/objects.tar.gz
any idea what happened? full drive? weird shit?
not a full drive. I don't know of anything weird that I did.
you done 2.4 on your lathe yet?
seems like only those two objects were bad.
git fsck / git repack succeeded
that's pleasant news
chris@rover2:~/emc2.trunk$ git --version
git version 18.104.22.168
this is now a version I don't trust
Author: Michael Geszkiewicz <email@example.com>
Date: Sat Dec 12 12:46:41 2009 +0100
Fix Axis to load programs with G43 and G43.1
and tree b78532ff405a29b11f8122596eabcd50a3e51e28 is a directory of src/libnml/inifile of unknown vintage
well I ruined any evidence I had...
[153913.917223] ecryptfs_read_and_validate_header_region: Error reading header region; rc = [-4]
[153913.917255] Valid eCryptfs headers not found in file header region or xattr region
[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
might be my encrypted home directory and/or ext4
it's called evolution
not a day goes by that we understand PCs less
[21:09:08] <jepler> https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/372014
well, dozens of people get errors like those
This situation occurs when 0-byte files are created in the underlying filesystem.
well I take some of the facts presented there with grains of salt
I do have a single 0-byte file there
interesting, Looks like dgarr had to add the line: * soft memlock 20480 to his limits.conf file to get emc to run.
I had to do that on one machine, but not a couple of others. why could that be?
do they have a different amount of ram? maybe the default is proportional, not fixed