cradek: you around?
try emc -v, and pick you favorite config
then look at the output
for a line "Running HAL config file <blah>
are there two slashes in a row before the filename?
* alex_joni noticed that a while ago..
Running HAL config file /etc/emc2/sample-configs/sim//core_sim.hal
yet it doesn't hurt
well, that is where dave's goes south
I think it's the trailing / on the dirname
it says "can't find <name with 2 slashes>
the slashes are a red herring
extra slashes don't hurt anything
but thats still the spot where hes going south
then the path (not the slashes) is wrong
yeah, I've got him looking at that
I have to admit I missed the diffs in the emails
Lerneaen_Hydra_ is now known as Lerneaen_Hydra
SWPadnos, what conclusions did we come to concerning halconfig if any yesterday/
I don't think we got as far as conclusions
but we can try now, if you like
actually, I think there were some things that came out of the discussion yesterday:
1) halconfig needs to be able to deal with HAL as it is now, because it isn't going to change before release
2) things will be better once everything is changed to comply with the new naming conventions
I can see this.
I figured as much ;)
The only thing that bothered me about the new naming conventions was the ambiguous use of -
in the new scheme, - is just part of a word
can you use - in tcl names, or does that cause problems?
to separate words within a field and to designate a range of
no problems with tcl.
no ranges in HAL
yes 0-3 is a range over which the parameter operates.
but there would be 4 separate pins for that
no in the hal_introduction jmk shows an example of a single parameter frequency which does that.
that's fine, because that's only one parameter, which affects all 4 outputs
but the dash means something else in that context.
stepgen.00-03.pulse-width, for instance
than it does in other contexts.
ok - I thought you were talking aboiut the new scheme, not "what we got now"
I am talking bout the new
but enough of my nit picking.
in the new scheme, you would ignore dashes
so you'd end up with something like 00-03 as a "word part" of some HAL parameters
that could, of course, be problematic
since 00-03 is actually "minus three"
Not if I am trying to explain the language of hal. Only if I am building a tree widget.
hmmm - those do throw a wrench in my plans though
As HEAD is, halconfig can save tuning values in the ini,
and it can save a netlist of current hal
it can not save hal changes to existing hal files.
It can also read a netlist for writable parameters.
I can't load my univstep config for testing.
I don't believe that I can build a hal change saving system using current variables.
right. that part is broke till we/i figure out how to handle ppmc names.
I guess that is the first task.
are you thinking of something that could for instance add pins to a signal, in the hal file where the signal is created?
no - I mean I can't run emc with that config
pin "axis.0.index-pulse-in" not found
oh. that was aparently changed in a lot of places.
heh - not in my USC config ;)
I commented them out in m5i20
said I'd deal with em later but never did.
* rayh goes looking for the change
hmmm - those are the same in both the stock univstep and my config
strange - I thought the tool prep loopback was added to all the configs
axis.0.index-enable is the only index pin available today in head.
It may be that jmk changed the name of the pin when he got it working last week.
I'm looking for the change that removed index-pulse-in from all the axes
yep - removed index-pulse-in, added index-enable
okay that explains it. is it grep -r time on the configs directories
I'm not sure. it seems weird to have index-enable, but no index
nothing to enable
I though it a bit strange which is why I simply commented out the links.
yep - just did that in my config. I'll ask JMK about it tonight
not sure what he was thinking (and I haven't read the encoder canonical interface yet)
ok - so back to the tree building problem
hey wait. it looks like the problem with univstep is that the stepgen and encoder both get INPUT_SCALE from the ini file
I get blinking limit switches here. Drives me nuts.
Guess I'll have to shut down and add a parport card.
stick in a bunch of pull-upts
only happens on three and four axes. looks like a com failure.
the inputs are all in the same two bytes
I ran this for weeks without any pull up.
ok. now I'm confused about this.
I commented out all references to input_scale in the .hal files
there is no pin or parameter that contains input_scale in its name
and I still get the same error when trying to run halconfig on my univstep config
Error in startup script: window name "label-0-input_scale" already exists in parent
That is the same message I get.
the only thing I didn't comment out was the actual INPUT_SCALE settings in the ini
I think halconfig get's the list of tuning widgets to make from reading [ in the hal files.
halconfig does ignore lines with # at the start, right?
Um, I don't think so.
that would be a good thing ;)
I didn't think there were # in any of the varibles in axis sections.
I've never seen em.
but then I guess someone should be able to put them in there if they want.
if I comment out a setting, halconfig shouldn't try to set it
halconfig tries to set any ini var that it finds a reference to in a hal file.
right, but a commented line in the hal file means it's not actually referenced
yep. and those would show up still.
I think that's what I'm seeing. I was trying to comment out some lines for testing, but they still acted like they're there
okay. I can fix that so it ignores # in hal
ok. I was just trying to figure out how to do that (using regexp or something)
ah - lsearch -regexp is probably what I want
(just like you have it)
ok. the problem here has nothing to do with HAL pin naming
it's a problem with how things are set from the ini file
the issue is that halconfig doesn't deal with multiple HAL parameters that are set from the same ini variable
darn can load it now.
in the case of the PPMC, both stepgen.xx.scale and encoder.xx.scale are set from [AXIS_nn]INPUT_SCALE
so if there are more than one, it should simply ignore the extra.
yes, or group the variables together, and only show one edit box
it's not a simple question
but it is the same variable as long as we are reading and writing to the ini file.
right, but the user doesn't have the ability to "unlink" the two (which may be fine)
but it should have multiple calls to halcmd
we should just change the ppmc / univstep to use separate vars for those
that would solve the problem
What would happen if someone used different values for these.
it was just easier to make the input and output use the same value
using a gecko, it probably wouldn't work, but it's conceivable that it could work with some other driver
one way of thinking about it (in the context of halconfig) is to have a list of ini vars, each of which has a list of all the HAL parameters that are set from that ini var
so loop through hal files and make a list
then loop again looking for params
then foreach param issue the value.
or jus add any params to a list in the first loop, using the ini var name as the list index (or array - sorry)
crappy pseudocode: array add bigfatarray(ininame) new_param_name
damn - what a red herring that naming thing was
at least we'll have a standard for the next version, and people like jmk know what's needed for the tillie crowd
If you look at the existing tree,
you'll see that what now shows as pin -> axis ->0 through 7 will then show as eight separate lines.
at the level immediately below pin.
It will make traversing a bitch.
when wioll it look this way? (would I find the answer if I'd read the canonical naming convention document?)
I was reading hal_intro in head.
ah. maybe I should do that as well
not needed for this today.
weird - I have neither latex nor lyx on this (BDI-4.30) install
No paul abandoned them a while back.
In the interest of space.
damn - 38M to download
jmk made a pdf last night though, right?
how far progressed are the thread-turning cababilities in emc as of now? (AFAIK all other regular 2d operations (things that don't rely on the spindle's position) work perfectly).
threads look perfect to me, but I'm sure there are still some little things to be straightened out
is the specific
[14:27:44] <SWPadnos> http://www.timeguy.com/cradek-files/emc/thread-cutting.jpg
[14:27:49] <SWPadnos> http://www.timeguy.com/cradek-files/emc/thread-done.jpg
[14:27:52] <SWPadnos> http://www.timeguy.com/cradek-files/emc/thread-check.jpg
err. sorry, are the specifications in the standard NIST Gcode files?
darned good question
Yes there is a new pdf in head.
damn. I can't get everything lyx depends on without doing an apt-get update
[14:29:36] <cradek> http://www.timeguy.com/cradek-files/emc/nut-test.jpg
yuck. I killed several bdi-4.30's that way.
How would I get a copy of the lathe-version of EMC, or does the current version support both mill and lathe specific codes? (by current version I mean the ones that I get from cradeks apt repositories)
yeah - me too
There is no lathe spec in the NIST work.
Lerneaen_Hydra: the 4/29 testing has basic lathe functionality in it, but there are a few fixes since then in HEAD
threading really isn't intended to be in emc 2.0.0
rayh: how do you get the encoder on the spindle to adjust the motor speed if ther is no lathe-specific code?
spindle motor speed in the old emc was open loop.
cradek: I will possibly get hold of a smaller cnc lathe sometime this week, and will hopefully be able to play around with it
Lerneaen_Hydra: sounds fun
rayh: by motor speed I meant the stepper/servo motor speed so that it takes into account the non-uniform spindle rotational speed (as can be heard in the movie that cradek posted on the mailing list)
I'll brb myself too
rayh, would you like me to commit the change that ignores comments in hal files?
just did commit
also added it to emccalib.tcl but didn't commit yet.
want to put in the ignore second instance.
Lerneaen_Hydra, We may be speaking of different EMC's here.
I am thinking of the documents from NIST that describe and build the last EMC that they worked on.
All of the spindle encoding, speed control is a recent addition to that work by NIST.
Lerneaen_Hydra: I think I didn't understand your original question, could you ask it again please?
cradek: what is needed (software-wise) to get thread-turning to work (which version of emc, special configs, and so on). Or is such functionality still in a pre-release state
rayh: what I meant was the Gcode specification at linuxcnc.com, that appeared to be from NIST.
for software version, you will want to use the cvs head, because there are some bugfixes to threading there now, and lots of work will be done on it in the next few weeks
there is currently only one gcode command that does threading, and it is not mentioned in the rs274ngc specification.
cradek: that sounds.. intuitive, I take it that it will be added to an EMC-specific derivative later on? (is that code in the wiki somewhere?)
[15:12:51] <cradek> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?SpindleSynchronizedMotion
very basic documentation here
cradek: how do I set EMC up to use the cvs head version? (prefferably alongside an existing version (in this case the standard apt-get version, that uses your apt reps)
[15:14:10] <cradek> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?Installing_EMC2
cradek: from that code I take it conical threads are not possible at the moment?
or are they?
that's described in sections 1.1 1.2 1.3 1.4 of this page
will it b0rk my current installation?
you can make multiple synchronized moves together, so you could write a conical thread with a series of G33 commands
no you can build and run HEAD separate from your installed version.
cradek: would something like this work (x is the diameter and z is the axis along the spindle)?
G21/G20 (whichever is MM)
g0 x10 z0
g33 x20 z-40 k2
g33 x19.9 z-40 k2
oh hey .. how are you guys?
and if so where is K measured across, the hypotenuse of the movement (in this case the step/turn would be 1/sqrt(2))?
yes you should be able to do a cone that way
yes the feed is distance along the path per revolution, so if you're moving at 45 degrees you often want pitch * sqrt(2)
cradek: wouldn't is be pitch*(1/sqrt(2))?
I intend to change the K to F because K implies that the feed per revolution is the projected feed along Z, which it's not
cradek: F sounds more intuitive to me
no, because you want to move farther per revolution, so multiply by sqrt(2) (which is >1)
beware I'm only guessing what you want here
cradek: then I must be confused, is K/F measured along the hypotenuse or one of the axes?
cradek: Do I need to rebuild AXIS?
the hypot (the programmed path)
cradek: then I understand what you meant wrt 1/sqrt or not
in threading.ngc in cvs, you can see my multi-pass compound feed threading program with 45 degree synchronized exit cut
cradek: do I need to rebuild axis?
to run axis in your cvs version, you should untar the axis source under emc2/src, it will build automatically when you build emc
untar to the same dir?
it should end up in a subdir, called emc2/axis
oops - emc2/src/axis
you can also make that a link to another directory that contains axis
(just to clarify, should this discussion be in emc-devel or emc, or is it irrelevant?)
re-run configure and read the messages to see whether it detected axis.
SWPadnos: so you've been building axis in this way? Any problems, except for the occasional verbosity?
hmm, using F in G33 messes with F modality, maybe that's a bad idea
jepler, yep, and I haven't noticed any problems
though I did notice that the revision is up to 1.4a(something)
yeah that's what you get if you're using HEAD
Lerneaen_Hydra: about your sample program: are the start and end of the angled g33 cuts both outside the work? if not you need synchronized entry/exit cuts
yep - new checkout as of a day or two ago
cradek: I wasn't really envisioning any material at all in that example, just testing the way to input parameters (if that was a real program I would need lead in/out)
cradek: does emc keep sync when going from one line to another?
do you mean adjacent g33 lines, or multiple passes with jogs in between?
SWPadnos: nothing new is happening on HEAD so far, but if it gets unstable you might want to switch over to the main1_3 branch.
for adjacent g33 lines in a program it maintains synchronization and blends the moves
multiple passes with jogs in between resynchronize using the encoder's index pulse
exactly like how you would use a threading gauge on a manual lathe
so it's not possible to have multiple thread leads at the moment?
sure, for two starts, offset one of them half the pitch in Z
maybe I should make some more complex demo programs
cradek: that may be good, reading a test program is (IMO) an easy way to learn how to do things
this existing g33 command that can sync in any direction lets you do almost anything you want, with clever enough gcode programming
the only thing missing is the ability to stop/start the spindle while still synced
cradek: so in actuality the thread turning cababilities are well progressed?
cradek: any idea when thread turning is released to testing-branch?
Cradek: - scroll would be cool - or threads on a arc. :)
definitely no sooner than late may
threads on an arc should be possible with a CAM app
as far as I know, I'm the only one who has cut threads, but it works well. I'll let you decide if you want to call that well-progressed
if it uses line-interpolated-curves
LH is right, you could thread an arc approximation if you want, but I have no idea why you would do that
however a thread-on-a-curve would be rather hard to attach to a bolt/nut ;)
a tapered thread is useful, and is easy to do already
cradek: is it possible that there would be the same bug when doing line-interpolated-cruves when doing threads in the same manner (bad accel. when going from one line to another)
hmmm - freqgen is actually a frequency generator, rather than a "step generator", right? (ie, takes a rate as input, not a position)
but like the other glitch you saw, in practice it probably won't affect the finish of the work
I was thinking that it would affect the surface much more as now we want a very even spacing between the threads?
talking about line-interpolated threading, I may try to cut a fusee: http://mvheadrick.free.fr/photos/uklf.html
that would be a real PITA to make manually...
ok. I'm editing hal_introduction, and was considering changing the short description to "frequency generator"
Lerneaen_Hydra: the english made them for 200 years by hand using a "fusee engine"
cradek: A machine made for just making them? well then it's probably far easier (I was thinking manual lathe and hard tools)
right, a special machine
cradek: EMC2 dies and says "Can't execute DISPLAY program /home/emc/cvs/emc2/bin/axis", it seems axis didn't compile. (I tried to run axis sim)
Lerneaen_Hydra: did you put the axis source tree inside emc2/src?
did you run configure after that?
in a directory called emc2-axis-1.2rc3
I think you have to call it axis.something
[15:53:20] <cradek> http://www.makingthemodernworld.org.uk/stories/manufacture_by_machine/03.ST.01/img/IM.0424_zp.jpg
oh, is that the newest version of axis or is it outdated?
(fusee engine and a huge clock fusee)
what were fusee's used for?
in that image the clock's spring is wound inside the barrel on the right. As you wind it, the string pulls harder, and the chain winds up the fusee (decreasing the radius) to equalize the force
err sPring pulls harder
so as the clock runs down, the force coming from the spring stays just the same
the english used these in pocket watches with hand-made chains so fine they fit through a needle eye
oh.. that's rather complex. *me really hopes that the inclination is linear and not logarithmic or something)
spring force is a square law
cradek: how does one make a chain that size in the 1800's, I wonder
I think it was usually matched to the spring experimentally
very small files and a magnifying glass
Lerneaen_Hydra: one link at a time, I think usually women made them
and endless hours of labor
probably the links were stamped and finished by hand, but I don't know for sure
cradek, have you seen the big catalog of exceedingly expensive watches?
I don't remember what it's called
SWPadnos: I'm sure I've seen many of those :-)
these were in the $200k and up range
that's a bit out of my league
mine too, but the book was at a local coffee shop
nice pictures I bet
I'll look up the name the next time I go there
the book is pretty impressive
somewhere I have a picture of a chain out of one of my watches under the microscope, but I can't find it
I put it through a needle and set it on a dime for scale
cradek: scroll would be a lead cut from say the senter of a disk out. (you would see them in a 3 jaw chuck - what you turn to make all of the teeth move in and out the same)
right, of course
so a thread just along the X axis?
sure, you can already do that
that should be very possible at the moment, assuming i've understood that
*understood everything so far
but doing that on a cnc mill is probably better if your diameter is very big
Lerneaen_Hydra: To put the axis source directory inside the emc2/src directory requires axis 1.3a2 or newer
Lerneaen_Hydra: it won't work with 1.2
Lerneaen_Hydra: if you have axis 1.3a2, what message did you get when you re-ran configure? It should say something like
checking for AXIS source... will build axis from axis
or "from axis-1.3a2"
whatever the directory name is
oops I forgot about that
[16:16:17] <cradek> http://timeguy.com/cradek-files/emc/fusee.jpg
this is a watch I repaired
[16:16:31] <cradek> http://timeguy.com/cradek-files/emc/dime.jpg
picture of the chain, needle, dime
[16:17:51] <cradek> http://timeguy.com/cradek-files/emc/fusee2.jpg
after repair, running
what do people think about me adding siggen.0.time and siggen.0.tmax to the hal demo section? (I'm not sure if they were left out on purpose)
hal demo section of hal_introduction.lyx
err - "A Simple Example" section
I doubt much of anything is left out on purpose
I think the time and tmax parameters are optional though, through some compile-time switch
jepler: Ah, ok. I had a 1.2 version
hey - I could just read the notes about that ;)
where would I get 1.3a2 or newer?
the axis website axis.unpy.net
is the cvs snapshot semi-stable, runnable, or completely dead (in genereal)
(by dead I mean not-able-to-run)
we never leave it broken
.. for long
it's generally quite good
but right now there's nothing in the CVS snapshots that's not in 1.3a2
soon I want to do some destabalizing things in the HEAD of axis cvs, so it may be not very usable for awhile
is it usable right now?
works for me (tm)
which reminds me .. I should release 1.2.3 since it does have one important bugfix (the 0 vs 360 degree arc thing)
jepler: is there a gui-to-change-toolpath-color-tool in the axis roadmap?
Lerneaen_Hydra: No. You have to use the X Resource Database
X Resource Database? What is that?
It's a very old way to configure X programs.
from the 1.3a2 release notes:
The colors used in the the plot area can be modified by the X Resource
Database. For an example light-background configuration, execute
xrdb -merge doc/axis_light_background
before starting emc.
that sounds like a very bulky way of changing the colors
the biggest problem with the X Resource Database is that the creators of every widget set more modern than Motif and Tk either didn't know about it or pretended it didn't exist.
so the X rescource is old/outdated?
you know, it would be nice if halcmd would let you link a signal to multiple pins with the linksp command
liek linksp X-Vel siggen.0.cosine stepgen.0.velocity
cradek: the threading-ngc doesn't do much for me, it just runs to line 6 then stops (line 6 is the one prior to the G33 movement, could it be waiting for the index signal?) I am running sim/axis as my config
I think we determined that the HAL naming convention would use <device-name>.<device-num>.<io-type>.<chan-num>.specific-name (ie, dots between each section, rather than dashes in some and dots in others)
does anyone think that's not true?
Lerneaen_Hydra: yes, it's waiting for the spindle, try running "max" which has a simulated spindle encoder
SWPadnos: I'm sure in favor of regularity
I'm editing the hal book, and wasn't sure if the canonical naming section should be changed
I'll wait for jmkasunich to pop on before I change it
random cool program of the day - Baudline (www.baudline.com)
cradek: in your MAX config, it says there are three axes, what are they? I can only think of two
is spindle an axis?
oh, that may be
Lerneaen_Hydra: just ignore Y, it will be hidden eventually
no, the spindle is not an axis
ah - once COORDINATES is actually used ;)
yeah I think there are a lot of assumptions about the axes going in order XYZABC that should be fixed eventually
cradek: there are some lathes with a physical Y axis though (though such lathes are probably out of EMCs scope for a long while)
Lerneaen_Hydra: there's no reason why you couldn't use Y
assuming it's orthogonal to X/Z
tool offset comes to mind, but I know 0 about lathes (especially CNC)
bummer, since you're writing all the code ;)
cradek: I'm thinking that EMC isn't developed to be able to do c-axis work. (slowly rotate the spindle, sub 10rpm speeds, and let a separatly powered endmill remove material (running on a subspindle))
that's part of what fest is about - getting people with different kinds of expertise together
I've done quite a bit in CNC-lathes
C axis is there already, it's just a sideways mill
oh? that sounds very nice
then there shouldn't be much left WRT turning with EMC
constant surface speed and lots of gcodes
G95/G96 comes to mind though (constant rotational speed/constant surface speed)
also possibly "radius" control, for those lathes that have Z (or is it X?) and Y
I intend to do that at fest
what's radius control?
my made-up name for this:
typically a lathe will have a Z axis (along the spindle) and an X axis (paralell to it)
if you can move the tool horizontally and vertically, then you may want to know how far from the spindle axis you are
oh, you mean if you have two axes that are perpendicular to the spindle axis
yes - X and Y in this case (as you were wondering for the milling scenario)
AFAIK though it's rare to have a secondary paralell axis
actually, R or D words would be great for turning
(radius or diameter)
unless it's a mill with a rotating table (table rotation is C axis)
oh, btw, how good is the support for a 3+2 mill?
good question. send me a couple of motorized rotary tables, and I'll let you know ;)
(along with nice Bridgeport motor mounts)
sure thing ;)
cradek: do you know how well advanced 3+2 milling is?
combined linear/rotary moves work as described by the kramer doc, other than that I don't know how to answer your question
what is the kramer doc?
a document describing RS274-NGC
in summary it says that in coordinated linear/rotary moves, abc follow xyz so they start and end together, feed rates being described along the xyz path
all constraints being are during the move, of course
uh, all constraints are honored during the move
by feed rates along the xyz path, does that mean that you may get moves that have higher feedrates than specified?
if doing xyz and abc moves?
it means that you specify feedrates only for XYZ (Fxxx)
and the ABC moves will start and stop along with the XYZ moves
if I was to do:
g0 x10 y0 z0 a0 b0 c0
g1 z-20 c360 f100
it would go from z0 to z-20 with F100
that would mean a certain time
that would give you a higher feedrate
and in that time it would want to move c from 0 to 360
or well, the tool would experience a higher feedrate
but if the resulting C-move would be higher than the limits specified
then the whole moved will be rescheduled, so the max C-feed is not exceeded
you would have to take into account the radius when programming the feed if you want a certain tooltip feed
max c-feed could still be more than the tool can take
* Lerneaen_Hydra hopes that edgecam can compensate for that
emc can't do what you want unless it knows the radius, and it doesn't
you have one axis in mm and one in degrees, that's not enough information to calculate tooltip velocity
shouldn't it be able to calculate velocity?
or rather, radius, and from that velocity
if I go to X10 then emc knows that the diameter at tooltip is 10mm
IF the C axis is centered around XY
and from that line I guess C isn't always
the spec only says they are parallel
that makes things more difficult
I don't think the spec specifies that it's the work that rotates, either. I think you can have a pivoting head (like a Bridgeport), and still be "within spec"
that's just a matter of switching a few signs around
jepler: yes, but you need some knowledge to do that
you can't just feed some g-code to emc and assume it will do what is needed, without knowing how the machine is set up..
it also changes the tooltip speed equation a lot, as well as changing how the linear axes should be handled