yay, frank committed his AXIS fix on trunk
I saw that
I should test it
.. but not tonight
I should sleep a full night for once
gdepth ate my energy
sounds nice, me too
gdepth is cool
that gdepth6-arcspiral looks JUST like the aluminum one
I was just getting a bit tingly looking at the screenshots on the axis blog
it's even cut off the side on two sides like that
I'll bring it to work
well, all 4 sides
we will have to get a preview "right"
yeah it would be funny to show it that way (with a photo)
hmm, I/we desperately need to get g76 docs in the manual
you are in print!
I just got a copy of "Digital Machinist", a new mag
I've seen #2 I think
Ray had an article in there about tool diameter comp, and used an Axis screenshot
is this online?
and SWPadnos had an article too
dunno, doubt it
yeah that's the one I saw
fell out of the sky, wasn't addressed to me
the magazine folks like to sell the deat tree version, so they don't give nuttin away
mine was addressed to me - didn't request it or anything
but at one time I had a home shop machinist subscription, maybe they sent copies to former subscribers
either that or Roland shared his list from the workshop
that may/would explain it
(roland is involved in the mag too...)
did you get episode 1?
heh, I managed to do something usefull sitting in the airport this evening
(finished the pid manpage)
you home already?
that was fast
one day trip
left home at 5:30am, back at 10pm
hope work doesn't start at 8 tomorrow
I usually wander in around 8:30-8:45 (flextime)
I usually wander in around 8:15 (late)
although I don't really recall ever leaving on time either...
strange - I have a file called "e ???q?" in my docs/man directory
well, I'm tired
I think I'll go to bed before midnight just this once
I haven't tested it yet, but the patch from Frank Jungclaus looks plausible except for one accidental change (default DTG to on)
usrmotintf: ERROR: could not open shared memory
hm, my emc2 isn't running
what's the patch about?
ie, setting them from the ini (or so I gathered from the commit message)
apparently I got bored implementing it halfway through, pressing "i" to change increments didn't work right anymore
question: now that AXIS is part of the emc2 release.. I wonder if we shouldn't have some of the default configs with AXIS as the interface.. or is sim/axis enough to show it off?
if you ask me, AXIS could and should be the default ui for all configs
* alex_joni wonders if this was the wrong box to open
you think there are vocal opponents to this idea?
lots of people are used to the other interfaces, specifically tkemc and mini
yes, that's my concearn
axis is somewhat more demanding on the CPU and video subsystems as well
SWPLinux: so is ubuntu..
(since it basically always does a backplot)
we can't expect users running on 100MHz puters anymore
or if they do, they know how to fix it :)
it may make sense to have some "minimal" sample configs but switch the others to AXIS
* alex_joni sees there can't be a real answer
here's a tricky thought. (unrelated) can configure run the latency tests and choose a lower BASE_PERIOD based on the results?
hmmm - nevermind. that would only help people who compile for themselves
yes and no
the numbers in BASE_PERIOD and latency test are not really equal
I mean I ran with BASE at 6500 and latency at 12000
no, but 2x max_latency should be safe
sure. latency and tmax aren't really related
I mean a really well tuned system can be below latency
yes, though the error bar is wider than the execution time
but lets leave this to people who need the extra steps/sec
ok. 50000 is very safe but not very fast (and has bad resolution)
25000 is probably pretty safe, but has better speed and resolution ...
For M2CW we are rapidly approaching a need for a do-it-all config program that saves it's result in XML.
has anyone tried how low TRAJ_PERIOD and SERVO_PERIOD can be set?
hi ray :)
Then each subsystem has it's own parser to produce a result for that subsystem.
My Two Cents Worth.
that would be nice.. but it's a long way till there I think
The pyvcp already has the XML parser in place and makes a good system.
pyvcp might be a small step in that direction :)
How much work would it be to add a second subsystem, say HAL?
the parser is included as a standard python module, I wrote zero lines of actual parsing code - just learned to use the api
there's going to be at least one issue with that (I agree with the need though)
* rayh is all eyes
jmkasunich wants to keep HAL as generic as possible. that implies that soem things will need to be in two places in the config file
or, EMC will need to read from the HAL data areas
or, EMC will need a fork of HAL
(ie, generic HAL will need to become a separate project)
or two parsers will need to read the same XML data.
it's not the parser that's the problem. consider INPUT_SCALE (which should be OUTPUT_SCALE for stepper systems ...)
EMC needs to know about it, and HAL needs to know about it
so either the number is in two areas, or something has to tell everyone where to get it (which is non-generic in the HAL case, I think)
my terminology might be off, but lets try anyway: I think XML is really good at representing directed graphs ("trees"), but might be less good for cyclic graphs ("circuits" "loops")
I think everything we need can be in tree form
a HAL/XML configuration program would probably be about 30 lines of python, like vcpparse
There will certainly need to be some sort of knowledge base.
(not a GUI, just the thing that reads the XML and does HAL configuration)
SWPLinux: yes, it would use the existing linksp, newsig, etc. commands to build the HAL connections/blocks
That XML to HAL would be a great second step.
actually, the ideal is to have the parser need no knowledge
read the HAL subtree (or one specified on the command line)
ore one specified on halgui
But some knowledge file will be needed before we finish up a complete configurator...
I hope not :)
just blindly try things, and report errors
xylotex pinout could be considered such a knowledge file
that might be a problem with the way emc runs now
restarting emc a lot is not nice
that's Hal -> stepgen -> 0 -> param -> "maxvel" set to 50
the only thing the parser needs to know is how to put those parts together, and that's pretty generic
SWPLinux: and how is this better than what halcmd save outputs?
I would like to see a sample XML file that built both a pyvcp and a HAL.
it can go in the same file as a pyvcp panel ...
I think ray was thinking about the utility to create/adapt the XML config
so we are reducing the number of required 'ini' files
I tried halcmd save outputs with halconf so I've had a bit of experience.
the XML parser should be able to ignore sections of the data that aren't relevant to a particular function
yes - ideallly to one
that is easy, vcpparse now ignores anything not inside <pyvcp>
Once you save a netlist, it no longer looks for variables in the ini file.
awallin: That's the trick, section with pyvcp, hal, ini
awallin: right, and the halxml reader would ignore aything not in <HAL>
then there's <EMC>
still I think defining aribitrary signal topology with a tree-like model is not the easiest thing
Eventually we could get clear up to Interpreter pre and post conditions.
it's all flat connections though
SWPLinux: but if you want to make the XML a bit 'smart' not just a series of "halcmd xx", it would use the XML tree topology for connections somehow?
hmmm - I don't know about that at first
maybe you are right...
you could have a series of signals, and each pin can have a connection to some signal (and the parser ignores signals that have no pins connected)
The tree typology could be a part of the graphical front end.
or the other way around..
you have components, pins and connections
alex_joni: no - I think you want to name signals
rayh: but there are no good tree-widgets for tkinter...
that was the problem with linkpp
SWPLinux: this doesn't prevent it
then don't use tkinter
* rayh knows nothing of tkinter
you can use kate to edit an XML file
that means one more dependency
rayh: tkinter = python <-> tk interface
gedit may also do it
even cat does it
AXIS uses bwidget and there is a tree there.
yes, but it's not easy to use, wxpython is probably the best python ui toolkit
although I'm leaning toward qt4 for a commercial project.
qt is a bit of a dependency for the standard gnome-based Ubuntu
Are we thinking of replacing graphical front ends like axis, tkemc, mini with some sort of py-gui that is XML generated and manipulated.
I don't think so
but axis has the ability to load up a pyvcp panel and integrate it onto the main screen
so having all the info in one place would be a good thing
I'm going now, might look into creating HAL stuff with XML during the weekend...
see you ...
rayh: seems like jon E feels that the tkemc work offset solution is still not very good. do you have any thoughts about what we should do?
ask Tom H
* SWPLinux runs for shelter
ask Ray at Fest ;)
wish I could say something about that..unfortunately I only used offset once a couple of days ago :D
SWPLinux: I sense I'm missing an inside joke here, but that's ok
let's just say they have a very heated difference of opinion on how offsets should work and how they should be used
I was really dissatisfied with the tkemc solution as well.
oh, I don't want any heat
we need a peltier element
It is not a display specific issue. It is a problem of pre and post abort things.
get the heat out of here .. put it somehwere else :)
rayh: me too actually. but it is consistent now which is good (I think the offset display is always right)
just bring your coffee cup near, and it'll never get cold :)
IMO we would still have the issue if there were a way to get to g92 in mini.
mini uses something else?
if M2 and abort unapply G92, the gui offset jump is disorienting
yes what does mini do?
rayh: excuse our ignorance :)
and for that matter how do you teach people to use tkemc? I think I've heard you say jon is using it wrong :-)
excludes the operator from getting to g92 easily.
does that work because mini is often used without home switches (so you can just hit home?)
When Matt and Fred implemented g92 it was late at night and the machine was do to be delivered the next day.
(if you don't need a real home position using home probably works great)
Short answer, g92 was not real well thought out.
I'm afraid I agree
IMO the coordinate systems handle offsets correctly.
set em turn em on or off.
Probably abort ought to preserve the current g92 values so that they can be re-asserted.
part of me thinks M2 (and abort) should not nuke G92
but it bothers me that the spec says so
cradek: but remember it's not just M2/abort that are the problem
we have departed from the spec in other places where we think it's bogus though.
they should, from the perspective that it's a modal thing that will modify where the machine goes with normal commands (such as G0-G3)
jepler_: the base problem is the offsets are combined so the gui can't tell them apart?
cradek: the GUIs will be out of synch if a G55 is in the middle of the program and has been parsed but not reached in movement
cradek: the problem is that time the offset changes in the interpreter differs from the time it changes in the stat buffer
(the former happens at parse time, the latter happens when that point is reached for motion)
a g92 offset was supposed to be very temporary.
sort of a one-shot that reset whenever the program ended or quit for some reason.
rayh: so using it in the gui for things like touch-off or edgefinder is just a misuse?
I think so.
But for folk that use it, like jon, it would be a lot simpler to make it persist.
and simply change the spec.
I think Jon only uses it because tkemc uses it
using a 92 with other offsets is a real problem.
right click is easy.
yes I'm pretty sure he only wants to rightclick and doesn't really care what it does
* alex_joni obviously doesn't know squat about offsets.. but I head G54 is somehow better
menu ->scripts->SetCoordiantes is hard.
to be honest I'm not entirely happy with tkemc or AXIS's schemes
alex_joni: that's probably FUD from the AXIS camp, since they use G54 and not G92
* alex_joni goes back to blissfull ignorance
jepler_: the fear/distrust of G92 predates AXIS by many years
<jepler> whatever we do in AXIS is 100% right
jepler_ is now known as jepler
There is a slightly larger issue of EMC global var vs var file values.
jeppler is know known as JEPPLER?
I've called him many things, but not that
I've never been known as JEPPLER
The issue of 92 has been around for a long time.
The reason jon falls into it is that he's only used tkemc and used it since it was born.
He doesn't use the coordinate system offsets at all.
jepler: How does axis handle coordinate offsets?
just like the tkemc right click, except it's a button "Touch Off" and it moves G54
rayh: axis uses g54 for everything.
so among other advantages, it's not affected by M2 or abort
it calculates the right number so it works just like G92 (you give the new desired value)
Okay I've got axis 2.0.5 running and see just an offset button.
you'd need to try it in 2.1
"touch off" was later than 2.0.5/axis 1.4alpha
"Offset" sets it to 0 instead of a specified value
That changes the g54 value for the axis that is active?
just jog over a ways and push it
you'll see both origins in the preview (machine origin and G54)
if you have a program loaded, you'll see the whole program move
Got it and starting trunk as well
I see the intermediate popup
the 0.0 in there is relative to the current axis position?
that's what you want the current value to become
you can put an expression in that popup too. if you have a .1" edgefinder you could put .1/2 (but only if you suck at math)
axis works with g54 only in the interface
yes to set the other coord systems you would have to use mdi
like jon E, I never used them, so we didn't write it
And the offsets that you set with the touch off button are only written to the var file when emc shuts down?
I think we use some kind of trick to make them be written out immediately
the var file is written out "often"
Ah good. That matches the way that mini and the set coordinate scripts work in tkemc.
only sort of, AXIS sends mdi to the interp to set the offset, then causes the interp to write the varfile itself
I don't think that emcsh offers that option to tcl.
I forget what cuases the write - some kind of interp_synch command
it happens pretty often - when you switch modes for instance (I think)
I restarted axis and don't see the offset it saved in the var.
Is it still there?
ah sure. I see it with machine position.
sim/axis.ini saves the last machine position and restores it when you restart
this is a new feature available in emc2.1.
maybe that's what you saw that surprised you?
Must be. I'm using today's checkout.
rayh: we thought it's nice for machine without home switches to just remember the last position
I see that g92 persisted in axis after an abort.
it didn't really
rayh: it's probably tricking you
it just looks like it
issues a g1 command and see if it goes to the right place
Now I'm really confused.
did you abort a program ending in m2?
I think that's what messes things up in jon's case
Is there an m2 at the end of your splash?
That is odd. I saw the 92 offset and was able to reset it with g92.3 after abort but it is gone now that I switched to machine actual position display
rayh: I don't know - all I can say is we recommend you not use G92 with AXIS :-)
I recommend that folk not use g92 at all.
Great job with axis, guys.
* alex_joni agrees
SWPadnos_ is now known as SWPadnos
kde had a man page lister/reader. Is such a thing available with ubuntu without the whole kde system.
the system help will do that on gnome
system -> help -> system documentation
click "command line help", then "Manual Pages" (or Info pages ...)
out of curiosity, does anyone have an idea of how much more work it would be make an EMC2 live DVD?
specifically, so there would be room for all the compilers and other packages needed for development, plus other conveniences ...
why would we do that if it fits on a CD?
probably no harder than the CD, assuming it's not tricky to make them bootable
grab the iso, set up the chroot
rebuild the iso
burn on dvd
ok - that should be easy enough
the one I made has nearly 50MB available
SWPLinux: I skipped a few steps.. but that's it
the build tools should probably be added then, if they fit
I bet they don't :-/
they won't fit in 50MB
they can be squeezed in there.. but I wouldn't want to start tweaking the CD
as in removing some tools/apps
hence the DVD idea :)
I saw some ubuntu DVD's distributed with magazines
I noticed that as well
that means even more hosting
wonder what's on those (size, packages, etc)
hosting is no big deal
there's one reason I'm interested in this..
besides, I think ray is the only one in the US without broadband :-)
my mother also has no broadband
though that's irrelevant to the EMC discussion :)
I already have the DVD.. just need to write some data on it :D
you can do that on CDs as well
yeah, I know..
but I only have DVD blanks now
with lightscribe I mean
I see you got it to work :)
my computers generally don't have DVD drives - I would hate for that to be a requirement (say for the discs we hand out at fest)
I don't think it's a good single option, but in addition to the CD, it would be good
SWPLinux: it's way easier to make a second CD with the needed apps
user only needs to sudo apt-cdrom add
very good idea
SWPLinux: the instructions I put on the EMC2.1.0 wiki page would work for a custom CD too
good, but loses the ability to have extra things on the menu for a CD boot
it won't boot..
sorry - typed too slowly :)
it's only a CD with a repo on it
meant that a second CD lets you install, but not try other apps
what other apps?
anything elst that may be of interest: qcad, eagle, synergy, gcam, ($whatever)
nothing stops you from packaging those :D
devel packages is one advantage. extra apps is another
(on the live CD/DVD)
I'll fiddle with a live DVD someday
I wouldn't want to redistribute any of that non-Free software without a lot of research
sure - those were jus what I could think of off the top of my head
having KDE available on the same disc might also be good (for qt apps, plus for the choice)
I think this is where I stop being interested
I don't want to be in the business of repackaging OSes any more than necessary
it can be called the EMC Bloatware edition
IMO we should concentrate on EMC, not EMbuntuC
the more we repackage, the more we risk people misunderstanding and thinking we have our own OS distribution
I have not heard of someone who wants to help development who is not resourceful enough to get the necessary software installed
(not that one can develop without a connection)
nuff for today
good night all
see you Alex
[21:59:22] <alex_joni> http://bash.org/?10937
SWPadnos_ is now known as SWPadnos
I wish I'd stop leaving like that
* cradek hands SWPLinux a real irc client
SWPLinux has one, apparently :)