KimK: are you bringing your card and encoders to workshop?
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-05-28.txt
mozmck_work: I gave 10.04 another try and crashed somewhere I forget exactly... but I think it was the rtai part
hmm, it crashed trying to run emc?
trying to install
huh, did you have the rtai kernel installed first?
got vertical lines on screen of different colors about 1/8" wide and a big square for the mouse pointer
rtai was about the 4 thing I think
only way I could recover was to install 10.04 over again
it did that just trying to install the rtai packages?
your packages works fine
rt works fine, just jitter is somewhat large
JT-Work: now that's really odd.
Rob had no problems using your packages
micges: is it a single-core computer? On the single-core I tried the latency was actually somewhat better than 8.04 on the same computer.
but I haven't given it a workout on a multicore yet.
intel 6500 dula core
ok. is that even using isolcpus?
It would interesting to see how much that helps.
I'm planning gather info about jitter decreasing on weekend and start testing on monday
mozmck_work: many thanks for packages
mozmck_work: were are your latest packages for lucid? I have an old machine to try them on.
JT-Work: I don't know what to say on your install problem. Were you running my kernel when you installed the problem package?
no was I supposed to?
JT-Work: no, I was just wondering.
I started at the headers and installed all down to rtai one after another
I can't think of any reason it would do that at all. maybe someone else will have an idea.
cradek: I think according to docs this code should return error: http://www.pastebin.ca/1873400
(it doesn't on v2.4 branch)
I agree that on the first line #<name> is undefined in the scope. Where in the docs does it say that this is an error condition?
which part of that says emc will signal an error in this case?
there are gcode mistakes that simply have undefined results, as opposed to being diagnosed as errors. I don't see that the docs promise this error is diagnosed.
imo variable is undefined on reading
maybe I'm wrong, just learning some subroutines bahaviour
I think the docs don't say that, and the implementation clearly returns 0.0 in this case.
so we should simply add this to docs
I'm not sure what we should do.
the docs don't specify what happens in this case, but maybe the implementation isn't the best one.
there are 4 alternatives: do nothing; make the documentation explicitly say that the value of an undefined named parameter is 0.0; make it say that the result of using the value of an undefined named parameter is undefined; or make it an error and document that it's an error.
the first three mean that we don't have to change any code, but the second one forecloses making it an outright error in the future
the downside to doing the last one is that there is an unknown amount of code that works OK and depends on the current behavior
the upside to the last one is faster debugging perhaps when you do have an undefined variable that you assumed you had defined
option 5 or 6: like option 1 or 3 but also display a message about the detected problem (maybe even saying it will become an error in the future)
but I don't think we have a non-fatal error facility besides what (MSG,) does and so that message probably won't be displayed if for instance the subsequent motion exceeds soft limits
(since execution will stop as soon as the first limit-exceeding move is interpreted)
* jepler just spent a good 10 minutes trying to resolve this error: Makefile:30: missing separator. Stop.
I unintentionally ended up with a 9-year-old version of make (3.62) on my PATH before /usr/bin/make
jepler: we shuld ask others what could we do
I would have spend 10 days and never found it :)
JT-Work: you wouldn't have a 9-year-old make, either
here's the patch to make it an error: http://emergent.unpy.net/files/sandbox/0001-Don-t-let-a-named-parameter-error-pass-silently.patch
it breaks runtests, because flowsnake uses the 'undefined is 0.0' behavior.
or maybe the patch is mistaken; the line where it blows up is assigning to the parameter. so forget my patch..
jepler: we should have place to put those problems to all developers to see
I mean problems like this
we have a choice between an SMP kernel or supporting machines without APIC. [ 68.375908] RTAI[hal]: ERROR, LOCAL APIC CONFIGURED BUT NOT AVAILABLE/ENABLED.
that makes me very sad
so on my dual P3, it might still work?
what's /proc/cpuinfo look like on that system?
oh you mean on the smp one (sorry)
let me see if it's on
cpuinfo on dual p3: http://pastebin.ca/1873414
huh I expected to see apic in there
I see it
oh there it is
can you post full dmesg from the non-working system?
[16:41:42] <cradek> http://timeguy.com/cradek-files/emc/asus-p3-1200-dmesg.txt
[ 0.000000] Local APIC disabled by BIOS -- you can enable it with "lapic"
try putting 'lapic' on kernel commandline
I don't think anything scrolled off, but I can reboot to make sure
locked memory error now... one sec
intel documentation says that everything pentium-75 and up has (L)APIC but the internet suggests that it was unreliable or disabled in hardware in the early days. http://lkml.indiana.edu/hypermail/linux/kernel/0008.2/0161.html
it had placed "* hard memlock 20480", I changed it to "* - memlock 20480" according to the wiki page
yay, latency test runs
ha, only 700,000 ns latency when starting glxgears (nvidia binary driver)
it was 8000 before that
trying to change to vesa...
huh, changing to vesa gave me a 2048x1536 screen by default
... need a bigger mouse pad
I end up using my leg for a mouse pad when I'm at a customers plant
from what I can tell, Windows only supports ACPI on APIC systems, and ACPI is mandatory since Vista (2005). So it seems like 2005+ systems shouldn't encounter APIC problems (though maybe some unknown portion of them will need 'lapic' on the kernel commandline)
well I porked my machine (X)
I installed libgl1-mesa-swx11
(and removed nvidia-*)
cradek: so putting lapic on the boot line allowed rtai to load?
A guy on the rtai list had to build a different kernel for an atom board and geode because of this problem. The one had no apic and the other required it or something like that.
I have an atom 330 I could try to install - this weekend.
I am pretty sure the Intel 330 board (now obsolete) has an apic
Mach3 uses the Apic for it's famed parallel port driver. I've been on the email list for Mach3 for years and virtually no one has an issue with a missing apic. Even so, Art did write a driver version that does not require the apic, but again from what I can tell, virtually no one uses it from what I can tell..
well that was a fun puzzle. Suddenly my system had started generating Release files which were broken due to having an extra blank line in the file. It turns out that this behavior went away when I deleted two unintentional dangling symlinks in the repository.
I almost understand what you said
JT-Work: Did I miss a response from you about my file conversion issues ?
Or are those pesky customers calling you again . ;-)
[18:48:13] <jepler> https://patchwork.kernel.org/patch/37090/
> I wouldn't expect wbinvd to take longer than a ms or two, which
is probably not catastrophic yet.
m66 is very neat, i think the inclusion of this print is unitended: http://www.panix.com/~dgarrett/stuff/0001-GET_EXTERNAL_ANALOG_INPUT-printf-message-only-for-IN.patch
dgarr: glad you like it, yes it is (unintended)
alex_joni: it will be useful for fixed-tool ornamental turning like they did 400 years ago: http://www.getty.edu/art/gettyguide/artObjectDetails?handle=other&artobj=1419&artview=55374
hmm.. I wonder how M66 relates to that cup
external (non gcode) control of lateral (x) feed on a rose engine (xzc)
you can also do that in HAL
but I can understand wh
but I can understand why g-code is easier
yes -- i've been doing joystick offsets in hal, this will allow additional x feed per rev tweaking
[20:29:50] <alex_joni> http://www.pledge.co.uk/pledge_and_aldworth/ref/ch2e.htm
<- cool site
and the some of the best work done today (no cnc): http://www.ornamentalturners.org/forum/gallery2.php?g2_itemId=6996
dgarr: So do you run some type of external control program around emc2 and then feed the offset back into it?
no -- the external offset control is manual from a manual pulse generator or joy stick, it's hard to get the lateral feed right for all conditions, so experimenting is useful.
mozmck_work: after a reinstall (and not screwing it all up with the nvidia driver) your packages work great after I change the hardlock line from "hard" to "-" and boot with "nolapic" added to the kernel command line
mozmck_work: I played daisy.ngc on stepper/sim and it sounds great.
EMC: 03jepler 07v2.4_branch * r6bd5d1ad9fed 10/src/rtapi/rtai_rtapi.c: Restore default message level
jepler: not sure you noticed submittal earlier: http://www.panix.com/~dgarrett/stuff/0001-GET_EXTERNAL_ANALOG_INPUT-printf-message-only-for-IN.patch
EMC: 03jepler 07v2.4_branch * r30369b9501e5 10/src/emc/task/emccanon.cc: GET_EXTERNAL_ANALOG_INPUT: printf message only for INPUT_DEBUG
argh, I know there's a program related to my fpga rng on this hard drive, but I can't find it
aha, here it is
cradek: good to hear! are you using grub2?
mozmck-6core: I didn't do anything special with grub
er, I meant boot with "lapic", not "nolapic"
I get latency of 21knsec on it running opengl stuff