hm -- I bet emc2-sim + emc2-dev built for RT don't play well together
they both have the same source package too, it's a bit of a mess
maybe I didn't adequately think it through
seems like it should build both from one source package
should I not distribute the emc2-sim packages since there isn't 100% exact corresponding source?
well it IS the exact source, but it will build for realtime, not sim, if you apt-get -b source
can there be a "package config" kind of file that gets copied to the build dir (and contains options for ./configure)?
with the first question being - can that boe done with configure (look for a file, and add any options listed in the file as though they had been supplied on the command line)
I've taken those two -sim packages out of the repos
anyone can build them if they want
but I'm not happy distributing a binary package unless apt-get -b source reproduces it
it can be built with one command by making a script do the work. if the two packages can have different scripts (or none for the RT version), then that should work? (shouldn't it?)
so they would be the same source, but slightly different source packages
different source packages (tars) with the debina/ directory configured properly in each, would be fine
it's just not set up to generate that right now
and I don't think it's a big enough deal to risk messing with it
sim is nice for developers. I don't see much need for anyone else.
well, preview is nice for anyone
other architectures, maybe, but our packages are useless for them anyway
be it toolpath or metal remaining
you can preview with the realtime system just as easily as the sim
right, but sim is better for previewing on non-machine-controller computers
I don't see why
unless they are a different platform, making our debs useless
consider SWP's quadricle 128
well, for one thing, I can do it on amd64 / SMP / edgy computers ...
but I guess you just said you don't build a package for him
he's gonna have to compile it anyway
the package wouldn't run on edgy, either
no problem - it only takes 20 seconds ;)
he can build sim on his neganon 6000 if he wants, or I'll build it for him if he buys me one
I guess the number of people running Ubuntu, not on their controller PC, who want to do G-code preview is small
there's little to no drawback to installing the realtime stuff
for better or worse, I bet people tend to get it anyway, since they use our cd
availability is the main one, but since there are no packages for Edgy / Feisty / RH, Suse, Slackware ..., it doesn't really matter
you might lose your wireless network card, you'll get an ugly pop-up since your machine can't handle realtime, ...
you can't shut down
the RT kernel is a complete PITA on any laptop
or tell battery remaining ...
that's not "little"
mr. non=laptop-user :)
no, on my laptop
it's the noptetrons that are the problem
his laptop sucks anyway
my P3 laptop doesn't do so well either
well, if someone wants to fix emc2-sim in trunk, maybe we can backport it
I'm hesitant to mess with it
Hi. Internet is back up here
I may look at it, but I won't campaign for a back-port unless I'm very confident
* jepler wanders off
jepler: that's great by me
see ya later
what about having a different repo: deb http://www.linuxcnc.org/emc2/
I could sure do that as-is
I think a single repo is better, but I'm not the one doing the work ...
this would let us do it wihtout messing with the packaging stuff
Oh, it's silent night here :-) Every one tired from the last busy emc weekend??? :-)
yes I think so
But (since we have 02:30 AM local time here) I'm on the way to bed, too ...
Ah, yes, one more question :) Is it possible to explain in a short sentence what was the (historic) reason for having axis.tcl beside of axis.py???
Or do I have to ask this to Jeff?
we started by trying to use a screen builder. when that didn't work out, we kept them separate
also tk still seems most easily/naturally programmed in tcl
jepler may have other reasons
Ok, someday I ask jepler, too. I would have choosen something like Python together with one of QT / wxWidgets / GTK ...
ok, I think he'll just tell you he's most comfortable with tk
TK (with it's look and feel + amount of widgets) is to old fashioned (from my point of view)
it's true that it does look older
I programmed some thousand line Tcl/TK, but this was 13 (!!!) years ago ...
But it's still doing it's job and processors are now fast enough ...
My TCL/TK application 13 years ago was horribly slow on a amd486 :-)
aha, they are a little faster now.
even a few years ago, Tkinter was standard and advanced bindings like pygtk were not easily available. that's another reason I chose Tkinter
(on redhat 9; people on debian systems probably had it available)
I tried wxpython for a bit, but never grew to like its API.
Ok. So QT/GTK or something like that is for the next generation axis, 5 years in the future ....
if I was doing it again, I think I'd take a crash course in pygtk and use that
I doubt either of us has any energy left for a rewrite
I think I will just use it as-is for a long time, now that it's fairly functional
fairly functional: yes, indeed, I agree to that!!! you both did a good job!
and thanks again for your improvements
Are there planning to integrate gdepth to axis?? Or do you think this does not really match into axis?
I think the gdepth preview could not be a replacement display, but it could be run from a menu as a secondary program
I have a feeling gdepth would make the refresh rate too slow on most computers to be useful
yeah it can't replace the (very fast) line preview
So, how slow is gdepth? Did give it a try yet. Only have seen the very promising screenshots ...
So, how slow is gdepth? Did NOT give it a try yet. Only have seen the very promising screenshots ...
something like a minute to generate the view
1 minute oh .... no, then we have o wait for faster CPU :-)
I think it's ok to wait a minute for a nice preview.
imagine File/Preview on the menu
you would only use it when you want to
But if see how fast some cam tools can draw such previews, I think there's some space left for optimisations to the gdepth code?
Or is this just the tribute for using interpreted python code?
however with a machine that runs EMC, you are probably not going to have accelerated opengl.
File/Preview sounds good!
so there's a fundamental problem.
No acc. opengl here ... simply a good old matrox 450 ...
yeah something like gdepth will be slow then. lots of triangles.
BTW, the matrox xorg-driver is causing interference with rtai ... I sometimes get somewhat like "unexpected realtime delay" when heavily moving around windows ...
So this problem is well known!?
yes lots of hardware causes that problem
there is more detail in your dmesg, so you can see how bad it is
I think this is definetly not an emc problem ... running rtai latency without emc and moving around any windows in a fast manner show some problems too ...
that's good to know
The solution is not to move around windows while my machine is running :-)
that's one solution I guess!
it can be hard to get a machine to work perfectly with realtime
cradek: no, not emc-2.1 ... I'm on "pre-2.2 CVS HEAD" on edgy eft
I would have given emc-2.1 a try, so test out your very hard work from the weekend, but I fear it won't work with edgy ...
you could compile the release yourself from cvs, but since you're doing development, I think you're better off using the trunk anyway
a few hints about latency problems here: http://rtai.dk/cgi-bin/gratiswiki.pl?Latency_Killer
Not using the matrox driver and simply using the standard vesa xorg-driver doesn't show the problem to ... but the vesa driver is slow compared to the matrox one
jepler has to use the vesa driver too, and it is slow
cradek: ok, I'll check your link and hope the xorg-guys will fix this problems sooner or later ...
[02:08:03] <cradek> https://mail.rtai.org/pipermail/rtai/2005-January/010050.html
On my opinion this one this biggest problems with linux: no fixed binary interfaces for kernel stuff and others ... new API's for everything and every month ... they're still adapting old drivers to these
I wonder if this is slower or faster than the vesa driver
new API's but they aren't carefully enough with testing these old drivers
The maxtrox driver is defnitely faster then the vesa driver!!!!
yes but someone else said the framebuffer X driver (??) also lets RTAI work right
I wonder if FB or vesa is faster
FB will also be unaccelerated, won't it?
Did not test frame buffer yet ...
Before my head will punch on the keyboard and I fall asleep, I'll start a second attemp to find my bed now :-) ... 03:10 AM localtime now ...
If someone of you is bored, he can try my latest history changes on trunk :-) The also copy/past (special feature for SWP)
good night! CU
If someone of you is bored, he can try my latest history changes on trunk :-) There's also copy/past (special feature for SWP) .... I definetly need a spell checker for my irc-client :-))))
Grrrr ... If someone of you is bored, he can try my latest history changes on trunk :-) There's also copy/paste (special feature for SWP) .... I definetly need a spell checker for my irc-client :-))))
fjungclaus__ is now known as fjungclaus
fjungclaus__ is now known as fjungclaus
fjungclaus_ is now known as fjungclaus
jepler: tristate_bit seems fine to me - as cradek said, its not something we need now, but it could easily have uses in the future
tristate_float might be even more usefull
then you could make an N input mux kind of thing
actually I did like 'conv' and wrote a template that can be replaced by the individual type names
I'd probably drop the params for the float version
just base it on 'enable'?
I am not sure if those params are the most useful
actually, I already have a use for the float version
suppose you want three buttons to select x1, x10, x100 for jogwheel increments
let the butttons enable three tristate-floats, each with its input set to the relevant scale factor
wires the outputs together and send to the jogwheel-scale pin
(use radio buttons)
I guess that saves the decoding in HAL
yeah - otherwise you need to decode the three buttons to a pair of bits for a mux4
and what if you want to use 5 settings, from x1 to x10K?
here's the code for the 'float' version, with enables: http://emergent.unpy.net/files/sandbox/tristate_float.comp
it gets very simple if you want only the explicit enable pin
if(enable) out = in_;
the idea of detecting change and/or zero on an analog signal bugs me
yep -- it is a bad generalization
because real analog signals are always changing and never 0.00000000.....
so for float I have a moderately strong preference for the enable only version
I don't think those enable params even match what you really want for bit, let alone the other types
for bit I can see the merit of the params
you can make an open collector (sort of)
IMO you're more likely to want enable-on-positive-edge or enable-on-negative-edge
I'm tempted to say leave the params out
and make an open-collector-bit that writes to out when in is low
or something like that
maybe start with 2 tristate components with only the one explicit enable -- bit and float
on the "streamer as toolchange" thing
I'm 100% in favor of the handshake option for streamer
the larger part of that idea is gonna need some hashing out
I suspect many folks will rebel at the idea of doing it on HAL
and there are other complexities
yeah there are bound to be a lot of complexities
for instance, the "grid of tools" toolchange, will need a different position (or a couple) in the sequence, depending on the tool number
so either multiple streamer files, or on-the-fly ones
that's why I say that I expect the integrator will have to write a special-purpose component
I suspect that a lot of the logic for a changer will be done in CL
and cl bits might be used to send one of N target positions to the motors
yeah that sure would be one way
everybody is gonna have their own approach
depending on the tools they like
lerman is an interp guy, so of course he favors g-code
I'm a hal guy, so I like a hal approach
I hope we can get some good discussion going
but I have a feeling the entire thing is complex enough that it will kind of peter out
I think I started back at preferring the g-code approach, but on the other hand I fear that the current interp is not set up to make stuff like "wait for pin to go TRUE" easy
and we'll wind up with several incompatible ad-hoc solutions
you are familiar with the free planner (is that the right term?) -- what is your guess about whether it can be used during the middle of running a g-code program?
(the planner itself is unused at that time
that planner is the only piece of the "tp" that I understand well
quotes, because it isn't really part of the tp
I think I I heard a rumor that you wrote it
recently I was second guessing my decision to pull free mode out of the main TP though
what happens with the free planner if its goalposts keep moving -- does it do a nice within-machine-limits attempt to reach the goal position?
hmm, the link to the hal manual at linxcnc.org is busted
[03:46:15] <jmkasunich> http://linuxcnc.org/docs/HAL_Documentation.pdf
I'll look into that, then I'm away for the night
actually, thats the wrong doc anyway
I think I want the dev manual
where are the autobuilt docs again?
[03:47:26] <jepler> http://linuxcnc.org/docs/2.1/
(seems like a link to those otta be on the main docs page)
ah, I see the problem with the hal link
and HAL_Documentation vs. HAL_User_Manual
actually I created a symlink to fix it up
have you looked at fig 3.1 in the dev manual?
take a quick look - its relevant to the "can we use the free mode planner" thing
hm -- "free mode" implies working in joint space?
that whole "joint controller" is a joint mode thing
I guess I mean "teleop" then
every axis is independent at that point
I don't think I want joints
oh, you're right... because they're gonna want tool coords in cartesean space
you need to do the moves upstream of the kins, so they are coordinated
* jepler wrinkles his nose
darn it's not simple like I thought
anyway -- goodnight
man you wrote a lot of good documentation, I'm sure I still haven't read it all
I just scratched the surface though - I only documented the parts I know, which ain't all that much in the big picture
damn I wish I had called the motmod axis.N.foo pins joint.N.foo.....
any reason not to change it today?
busting everybodys configs when 2.2 comes out?
plus busting everybody who's running CVS head?
wonder if 2.2 will be a long or short release - and whether we'll bust configs in a dozen other ways too
I'd certainly consider making the change for 2.2
but not literally "today" as in without a discussion or anything
today, unlike a week ago, we can be a lot more bold adding new features and breaking things
I do hope to bust things for 2.2
I'd like to move to the instance model for hal
heh that's an easy goal
I'd actually like a summer 2.2 release - maybe right after fest
where you don't do "loadrt foo cfg_array="bunch,of,data"
that would be nice
instead you do loadrt foo; newinst foo cfg=bunch; newinst foo cfg=of
with options, so when you do newinst not, you by default get "not.N", where N autoincrements
but you can specify a differnet name
did jepler put in newinst and then take it out? I remember seeing something like this
did it not work right?
the implementation only worked in sim, IIRC
and there were other issues - it wasn't fully thought out
so we agreed to defer it
you know that big electrical box I got for the shoptask?
its filling up scary fast
I remember you knew that would happen
is everything going to fit?
I just laied it on its back and started sticking things in there, sliding them around, etc
I'll make it fit
but I'm afraid it won't be pretty
I gotta grind off the other two panel mounting studs, that will help a little
(but its late and my wife is asleep - dremeling thru a 3/8" stud mounted to a sheet metal resonator won't make her happy
hmm... wish I had a way to measure airflow
man.. the internet is more than willing to sell me junk exactly the same as the junk I already have... but specs for the junk? forget it.
"OK if that's what you really want" </emc>
it looks like me trying to do a coloring book
Stay inside the lines.
my 1995 era potential spindle VFD is 3/8" too wide to mount edgeways in the cabinet (which would save a ton of space)
9.25 x 16 x 4
it it was 8.9 it would fit
did you say you got your motors?
if it was
the steppers - yes
have geckos yet?
yeah, had those for several months
its tempting to wire everything up on the bench and spin them
yeah no kidding
I wouldn't be able to resist
I'll do it sooner or later
heck I'd probably never finish the box
maybe your way is better :-)
but I know that slapped together wiring leads to blown up drives
and I don't have enough bench space
how the heck does that happen
time flies when you're having fun
I'm having fun playing with the (perfectly working) 2.1 emc
I think this is going to be another good run.
I hope so
well goodnight, morning comes fast
I should be going to be soon too
nice post there, Ray
someone had mentioned the idea of making most (if not all) g-codes into "macro calls" - that may be a good solution for a number of problems
and of course the source for a gunch more :)
bunch, that was
at least everyone agrees my approach to toolchange movement is the wrong one
actually, I like your approach also
though I see a possible problem with glitches on changeover to HAL / external control
jepler: not exactly
it's an ecellent solution to a different problem, I think
gah - excellent
jepler: I was impressed with the creativity of your suggestion.
I think that there would be a lot of applications that can use it easily.
I also like your idea about timing next read.
jmk seemed to think that the halstreamer change I proposed was a good one, whether or not it is to be used for changing tools. Is that what you mean?
It should make those modules work much more like I was imagining when we talked about serial communication the other day.
oh. interesting promotional for dr dobbs. mind if I share here?
Please join Dr. Dobb's Journal and Electric Cloud for this informative NetSeminar:
Managing the software build process with geographically distributed teams
Date: Thursday February 22, 2007
Time: 11:00 AM PT / 2:00 PM ET
To bad my connections is slower than they require.
it could be interesting
I presume that electric cloud is a software solution but the issues they bring up should be of value.
"With Electric Cloud, software development teams can now significantly reduce the time they waste waiting for builds to finish, and shorten the overall development cycle. As it stands many builds can take over eight hours to complete. With Electric Cloud those hours literally shrink to minutes."
this is really not a problem we face at all
[17:28:59] <cradek> http://en.wikipedia.org/wiki/Electric_Cloud
haha - See also: distcc, ccache
(wonder if this "NetSeminar" might just be an infomercial)
it really does sound interesting "[Electric Cloud] deduces dependencies on the fly by monitoring file accesses during the build, so that it knows when it is or isn't safe to run build steps in parallel."
but we've already got a build system with correct dependency information that can perform many steps in parallel
most people don't have that
no, and it can be a big PITA to get it
only because of legacy setups. You'd think over these decades people would have learned to use make.
"Recursive Make Considered Harmful" (Miller) is 10 years old now
It's crazy, but systems like GNU automake *still* do not assume gmake, so they can't do things like use %-style implicit rules or assume that Make will restart after building its dependencies
yes that is crazy.