Re: [Emc-users] Tool change question
Am 22.03.2012 um 10:09 schrieb Erik Christiansen: It is my (limited) understanding that LinuxCNC cannot intrinsically test the current state of its many modalities, so we don't seem to have anything that can be checked, AIUI. ... But LinuxCNC doesn't know its current state in an exportable way, so has nothing to put on a stack, AIUI. As for introspection on state at the gcode level, see http://www.linuxcnc.org/docs/devel/html/gcode/overview.html#_predefined_named_parameters_a_id_sec_predefined_named_parameters_a . If that doesnt suffice, go to the embedded Python level which has practically all of the interpreter state exposed, and then some (task). See tests/remap/introspect/oword.py for state access. Exporting state from Python is left as an exercise for the reader;) -m -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] A fixed example, and a question. [Was: Tool change question]
On 23.03.12 16:47, Erik Christiansen wrote:
Sub drill_em_there (123.456, 789.012) {
Rel Drill X#1 Y#2 Z1.5 Retract 2.8 Repeat 3 // Drills 3 holes.
}
Ugh, too much typing of grammars and emails, and not enough observation.
Those parameters shouldn't be there ... unless we keep something like
(a, b, c) or (3), to allow checking the number of parameters in each
invocation, throughout the program. It's just a matter of adding the
parameter count to the symbol table entry. Is such checking valuable?
For now, I've cut back the grammar to take:
Sub drill_em_there {
Rel Drill X#1 Y#2 Z1.5 Retract 2.8 Repeat #3 // Drills N holes.
}
...
Call drill_em_there (123.456, 789.012, 4)
to generate:
O100 sub
G91 G81 X#1 Y#2 Z1.5 R2.8 L#3 ; Drills N holes.
O101 if [#abs_modality EQ 1]
G90
O101 endif
O100 endsub
(More code, running O-numbers up to 106 in here.)
O100 call [123.456] [789.012] [4]
It also dawns on me that those squiggly brackets can serve as a reminder
that we're in a new gcode scope, with local copies of #1 to #30. Endsub
doesn't do that for me.
Erik
--
Chinese Proverb: He who is willing to work will always find employment.
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] OT - Re: Tool change question
On 03/22/2012 04:35 PM, Dave wrote: Now really OT! My tech book says: Case LA: 6516 lbs 4 cylinder engine 403 cu inches displacement!! 34 SAE drawbar HP My Case 400 is actually a model 411, but they were known as 400's. Case made a 400B model in the 60's that was a small tractor. 6144 lbs 4 cylinder engine 251 cubit inch displacement 35 SAE drawbar HP Yes, I am a tractor nut also... ;-) Case used a lot of cast iron and steel in the old tractors. Most of them are crazy heavy. John Deere's are green because you need a lot of green to buy and maintain them. They are good machines but expensive. Dave Nothing runs like a Deere, nothing smells like a John... ;-) Mark -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Tool change question
On 23.03.12 08:53, Michael Haberler wrote: As for introspection on state at the gcode level, see http://www.linuxcnc.org/docs/devel/html/gcode/overview.html#_predefined_named_parameters_a_id_sec_predefined_named_parameters_a Many thanks for that link, Michael. And I thought that: http://www.linuxcnc.org/docview/html/gcode_overview.html#sub:Named-Parameters was the definitive reference on the subject. There are more hidden gems in the LinuxCNC documentation warren than any single human knows about, I suspect. I'll update the code generation to exploit those predefined named parameters which you've revealed. Although it'll only save a gcode assignment at each G90/G91, it'll be more canonical in its machine state testing. If that doesnt suffice, go to the embedded Python level which has practically all of the interpreter state exposed, and then some (task). See tests/remap/introspect/oword.py for state access. Seeing there, things like: self.params[a_new_local] = 321.0 I'm tempted to guess (based on zero prior exposure to python), that that's probably a hash.¹ Having that available in bison would have made the symbol table much easier to implement. ;-) Exporting state from Python is left as an exercise for the reader;) Since the translator could be run as a filter or off-line, tests need to be executed in gcode, so that they're real-time. I don't know of a method to run in-line python in gcode, and have yet to see a need for it, anyway. The predefined named parameters you've shared do it for me, AFAICT. My belief that LinuxCNC was limited was largely based on a post from: Date: Mon, 6 Feb 2012 13:27:12 +0200 » if (SpindleMode=CSS) uimessage some relevant message That can't be converted to generic G-code because generic G-code is bad at strings and has no mode introspection. « and the absence of any contrary thoughts on the list in the last several years. But it turns out that even #_spindle_css_mode is available. Thanks again for finding the treasure. Erik ¹ Or associative array to awk fans. -- We shall not cease from exploration, and the end of all our exploring will be to arrive where we started and know the place for the first time.- T.S. Elliot -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Tool change question
'squiggly' brackets are technically braces. [=left bracket, {=left brace,
and (=left paren for anyone tempted to call it a curvey bracket.
--- On Thu, 3/22/12, Erik Christiansen dva...@internode.on.net wrote:
From: Erik Christiansen dva...@internode.on.net
Subject: Re: [Emc-users] Tool change question
To: emc-users@lists.sourceforge.net
Date: Thursday, March 22, 2012, 10:47 PM
On 22.03.12 11:24, gene heskett
wrote:
On Thursday, March 22, 2012 09:59:01 AM Erik
Christiansen did opine:
But LinuxCNC doesn't know its current state in an
exportable way, so has
nothing to put on a stack, AIUI. And we don't have
gcode interrupts. For
the moment, we seem to only have the recommended
good practice of
starting each file with explicit modality
settings.
When axis is in the MDI (F5) mode, it does display the
machine and LinuxCNC
state. To me that says either axis is tracking it
in real time, or
LinuxCNC does have the ability to export that state.
Ah, but does it follow that just because AXIS knows its
state, we can
export it for Kirk's checking (if we still want to do that),
or even
test modalities directly in gcode?
If there is a way, then I could simplify the gcode generated
for the
following HR subroutine. The gcode needs to use relative
distance mode
for the three-hole G81 to work, but the sub might be invoked
in a run of
absolute code. BANG! Things go crunch if we don't restore
whatever was
the distance mode before the sub was called.
Sub drill_em_there (123.456,
789.012) {
Rel Drill X#1 Y#2 Z1.5
Retract 2.8 Repeat 3 // Drills 3
holes.
}
That currently translates to gcode which tests for the
previous distance
mode, and conditionally restores it before returning:
O105 sub [123.456] [789.012]
G91 G81 X#1 Y#2 Z1.5 R2.8
L3
; Drills 3 holes.
O106 if [#abs_modality EQ 1]
G90
O106 endif
O105 endsub
Which in turn relies on the HR mode settings:
Motion = Absolute
Motion = Relative
generating this gcode, to make the current state known in
gcode:
G90 #abs_modality=1
G91 #abs_modality=0
If there's a way to know current modes at any program point,
using only
existing gcode capability, then I'd be quite keen to know,
because
there's no point doing extra stuff if there's a simpler
way.
Each file can then explicitly reassert anything
non-standard that it
needs. It might be good practice to only break
programs between
self-contained processes. If that is done, then
including a common file
may be a workable solution.
It sounds good to me. But might turn into a bookkeeping
problem for the
operator who is assembling all these bit
pieces. He would probably like
to have each #nextfile have the ability to #include a
header file that sets
up the machine state to properly do the code in
#nextfile.
Yes. Alternatively, we could let the user put as many
#includes as he
needs at the start of each file. Then #nextfile only needs
to close the
previous file, and the includes are together with the code
which relies
on them.
But would that not lead back to the open file
limit? Maybe by closing
all files before opening #nextfile this scenario could
be avoided?
Ah, my previous post was long, and it didn't say clearly in
one place
that the purpose of adding #nextfile is to close the
unneeded descriptor
for the previous file.
But I hadn't checked whether the flex infrastructure used to
manage
multiple input files for #include, closes the file as well
as freeing
the buffer ... and it doesn't. So I'll go in now and fix
that one too.
Thanks for sending me off to check.
[...]
We didn't even have one of those, just King
Colonel, 4100 lbs of
Percheron between them. Best team of horses ever
AFAIWK.
And now we're down to burning 30% of the world's tar sands,
to make oil
of the rest, and fraccing under our farmlands to grab a bit
of gas, and
never mind whether you'll ever again be able to use the
water from your
well to slake the thirst of the Percherons when we're back
to them in a
couple of generations. (This week's farming paper reveals
that our farm
is in the largest region in the state opened for fraccing.
Ah well, the
water table is already declining a meter per year, due to
the offshore
oil extraction, according to the local water authority.
What's next?)
Erik
P.S. Question: Are those squiggly brackets on the Sub better
eye candy
than an Endsub instead?
--
The assessment by UN-Habitat said that the world's cities
were
responsible for about 70% of [greenhouse gas] emissions, yet
only
occupied 2% of the planet's land cover.
- http://www.bbc.co.uk/news/science-environment-12881779
Re: [Emc-users] Total OT - TV signal
Ok Viesturs! As a former RF-engineer and a radioamateur hunting RF signals in the woods I believe your first job still is to find a better antenna-position. This is after you have made sure the cabling is in order so that is not the real cause of your problems. It's not certain you need a 30 meter mast, you just have to check up that your antenna points in the right direction who should almost always should be in the direction of the transmitter. Next is to select an antenna with the right antenna gain, that´s how focused your antenna is, higher gain makes it more important to put it in the right direction. Om the other hand, if yo have forest beteween your site and the transmitter you will probably have a scattered signal with the incoming wavefront components coming from different directions. That makes a high RF gain antenna useless. Anyway, the antenna gain is defined in dB, higher dB makes it more important to adjust your antenna to the source, your RF signal strengh reading should vary depending on your alignment. A realtime RF signal meter function is most often integrated in modern receivers. This leaves you with some options: 1) Raise the antenna level as high as possible/needed. 2) If you have a mountain/ high forest wall behind you, it might be possible to direct your antenna at the reflected signal, but that is an unusual situation. 3) Trying to insert an amplifier in the downlink is most often useless unless you have a very long RF transmission cable to the receiver because then it will compensate for transmission line losses in the cable. Some RF amplifiers also have filtering included which helps if you have an interfering unwanted signal in the vicinity. Local resellers might know about such sources. / Roger -- - abCNC --- Roger Holmquist Bockarp villa Tallebo 59592 Mjölby +46-706-250123 +46-768-788477 +46-142-20542 ro...@abcnc.se http://abcnc.se -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] CAM / G-code Generation
Hi Anders, Do you have the link for the forked currently developed version? Thanks! Playing with PyCam right now. Seems to come a long ways since I last played with it. There's a group of projects on github. https://github.com/Heeks They will differ, more or less, from the corresponding ones on googlecode... For getting g-code and machining done _now_, HeeksCAD/CNC, with possible python mods/hacks, may be the better choice. For the _long_term_ FreeCAD may be the better choice, but generating toolpaths+g-code is very hackish right now afaik. FreeCAD uses OpenCascade+Qt, while HeeksCAD is OpenCascade+Wx. So in theory most HeeksCNC work should transfer over easily. There's a FreeCAD forum at http://sourceforge.net/apps/phpbb/free-cad/ , but I'm not very good at following forums myself so I'm not sure if there's much CAM discussion there.. Anders -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Tool change question
Am 23.03.2012 um 10:30 schrieb Erik Christiansen: On 23.03.12 08:53, Michael Haberler wrote: As for introspection on state at the gcode level, see http://www.linuxcnc.org/docs/devel/html/gcode/overview.html#_predefined_named_parameters_a_id_sec_predefined_named_parameters_a Many thanks for that link, Michael. And I thought that: http://www.linuxcnc.org/docview/html/gcode_overview.html#sub:Named-Parameters was the definitive reference on the subject. There are more hidden gems in the LinuxCNC documentation warren than any single human knows about, I suspect. yes, here is this 'hidden manual';) - it describes the embedded Python environment in boring detail: http://www.linuxcnc.org/docs/devel/html/remap/structure.html I admit the canon and interpreter internals aspects are not as detailed as they could. Plowing the testcases and the source helps. The best references for the embedded Python exposure are: Interpreter internals: http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=src/emc/rs274ngc/interpmodule.cc;h=3cb2ed7ede7bce140ed284c426c3ca209cf236d9;hb=f1d4b33a6b3a6c10b8220d1e0533075b60fa0e79 Canon: http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=src/emc/rs274ngc/canonmodule.cc;h=edba3cb5147684feac0e89143fc3df465e1d247d;hb=f1d4b33a6b3a6c10b8220d1e0533075b60fa0e79 the experimental Task Python plugin: http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=src/emc/task/taskmodule.cc;h=d3ae25a16c892c346d48d4e703161d3ec868508b;hb=f1d4b33a6b3a6c10b8220d1e0533075b60fa0e79 See tests/remap/introspect/oword.py for state access. Seeing there, things like: self.params[a_new_local] = 321.0 I'm tempted to guess (based on zero prior exposure to python), that that's probably a hash.¹ This is standard Python dictionary syntax, see http://www.tutorialspoint.com/python/python_dictionary.htm Having that available in bison would have made the symbol table much easier to implement. ;-) it is, use std::map or std::unordered_map, see http://www.cplusplus.com/reference/stl/map/, http://en.cppreference.com/w/cpp/container/unordered_map The interpreter uses std::map for all globals and locals, and lots of other data. That is, in master - it got rid of all the home-grown symbol table routines when I merged the remapping changes last fall. Exporting state from Python is left as an exercise for the reader;) Since the translator could be run as a filter or off-line, tests need to be executed in gcode, so that they're real-time. I don't know of a method to run in-line python in gcode, and have yet to see a need for it, anyway. The predefined named parameters you've shared do it for me, AFAICT. The manual shows how to do exactly this here: http://www.linuxcnc.org/docs/devel/html/remap/structure.html#remap:Python-O-word-procs You will find lots of examples for embedded Python usage in the canned demos under configs/sim/remap, and regression tests using these features, like under tests/remap and tests/interp. -m -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Total OT - TV signal
2012/3/22 Peter Blodow p.blo...@dreki.de: First: are you sure the dish is directed correctly to the satellite? My apologies for not stating it clearly - it is DVB-T signal, terrestrial, not satellite. Thanks, Kirk and Gene! The antenna is ~2m long, its orientation is the same as previous antennas. I guess I might try another session of catching better signal, once it will get little warmer. Now the sun is really warm, but wind is nasty cold already on ground, so I do not want to know, what is it on the roof (although it is only 3-4 m higher:) ). 2012/3/22 Jan de Kruyf jan.de.kr...@gmail.com: But, who has time to watch TV anyway? I cannot resist the temptation: Viesturs' parents!! Yes, I mostly watch hockey (there is one Latvian team playing in KHL), but other than that - not really much. And now the KHL season is over... For me the internet is main source of news and information etc. Thank You, Roger, for the explanation! I finally understood, what do those dB mean. Ok, seems that there are not much options, but to think, where and how to replace the antenna. The thing is that there is a hill with trees on one side of the house. It is very nice, because to large extent it protects the house from western winds (statistically wind from west is most common in LV, as it blows from sea/ocean to continental inlands), but it is exactly on the transmitter - house roof path. The remaining 3 sides of the yard are open in terms of hills, trees etc. Viesturs -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Total OT - TV signal
On 23.03.12 15:24, Viesturs Lācis wrote: The thing is that there is a hill with trees on one side of the house. It is very nice, because to large extent it protects the house from western winds (statistically wind from west is most common in LV, as it blows from sea/ocean to continental inlands), but it is exactly on the transmitter - house roof path. The remaining 3 sides of the yard are open in terms of hills, trees etc. That hill and its trees are casting a signal shadow. Do you have a friend living on the top or side of the hill? Radio amateurs have sometimes made a passive repeater by cabling two Yagi antennas back-to-back, and mounting them on a pole (or two) on top of the offending hill, one pointed at the transmitter, and one pointed at the receiver. I don't have first hand experience of how much they help, but it would be interesting to try. As explained by others, high-gain antennas will work best, but need to be fairly well aimed at both targets. The set-up might bend local regulations, since it's re-radiating the TV signal, but since the only measurable outcome is an improved TV signal behind the hill (at least around your house), it could be worth trying, especially if the hill is fairly close, and you're in a rural setting where there are few neighbours to notice. Erik -- A computer is like an air conditioner, it works poorly when you open Windows. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Tool change question
On Friday, March 23, 2012 10:23:48 AM Erik Christiansen did opine:
On 22.03.12 11:24, gene heskett wrote:
On Thursday, March 22, 2012 09:59:01 AM Erik Christiansen did opine:
But LinuxCNC doesn't know its current state in an exportable way, so
has nothing to put on a stack, AIUI. And we don't have gcode
interrupts. For the moment, we seem to only have the recommended
good practice of starting each file with explicit modality
settings.
When axis is in the MDI (F5) mode, it does display the machine and
LinuxCNC state. To me that says either axis is tracking it in real
time, or LinuxCNC does have the ability to export that state.
Ah, but does it follow that just because AXIS knows its state, we can
export it for Kirk's checking (if we still want to do that), or even
test modalities directly in gcode?
If there is a way, then I could simplify the gcode generated for the
following HR subroutine. The gcode needs to use relative distance mode
for the three-hole G81 to work, but the sub might be invoked in a run of
absolute code. BANG! Things go crunch if we don't restore whatever was
the distance mode before the sub was called.
Valid point, and one that has bitten me in one form or another several
times.
Sub drill_em_there (123.456, 789.012) {
Rel Drill X#1 Y#2 Z1.5 Retract 2.8 Repeat 3 // Drills 3
holes. }
I just got lost, 3 holes but only one XY specified? I came into this scene
after it was outlined obviously. :)
That currently translates to gcode which tests for the previous distance
mode, and conditionally restores it before returning:
O105 sub [123.456] [789.012]
G91 G81 X#1 Y#2 Z1.5 R2.8 L3 ;
Drills 3 holes. O106 if [#abs_modality EQ 1]
G90
O106 endif
O105 endsub
Which in turn relies on the HR mode settings:
Motion = Absolute
Motion = Relative
generating this gcode, to make the current state known in gcode:
G90 #abs_modality=1
G91 #abs_modality=0
If there's a way to know current modes at any program point, using only
existing gcode capability, then I'd be quite keen to know, because
there's no point doing extra stuff if there's a simpler way.
Each file can then explicitly reassert anything non-standard that it
needs. It might be good practice to only break programs between
self-contained processes. If that is done, then including a common
file may be a workable solution.
It sounds good to me. But might turn into a bookkeeping problem for
the operator who is assembling all these bit pieces. He would
probably like to have each #nextfile have the ability to #include a
header file that sets up the machine state to properly do the code in
#nextfile.
Yes. Alternatively, we could let the user put as many #includes as he
needs at the start of each file. Then #nextfile only needs to close the
previous file, and the includes are together with the code which relies
on them.
But would that not lead back to the open file limit? Maybe by closing
all files before opening #nextfile this scenario could be avoided?
Ah, my previous post was long, and it didn't say clearly in one place
that the purpose of adding #nextfile is to close the unneeded descriptor
for the previous file.
But I hadn't checked whether the flex infrastructure used to manage
multiple input files for #include, closes the file as well as freeing
the buffer ... and it doesn't. So I'll go in now and fix that one too.
Thanks for sending me off to check.
Glad I could help, even if it wasn't my intention. Serendipity ;-)
[...]
We didn't even have one of those, just King Colonel, 4100 lbs of
Percheron between them. Best team of horses ever AFAIWK.
And now we're down to burning 30% of the world's tar sands, to make oil
of the rest, and fraccing under our farmlands to grab a bit of gas, and
never mind whether you'll ever again be able to use the water from your
well to slake the thirst of the Percheron's when we're back to them in a
couple of generations. (This week's farming paper reveals that our farm
is in the largest region in the state opened for fraccing. Ah well, the
water table is already declining a meter per year, due to the offshore
oil extraction, according to the local water authority. What's next?)
Maybe, and maybe they are just passing the buck blaming it on the current
whipping boy. The Morrison Aquifer, runs ISTR from SD to Texas, has been
sucked down to about 10% of its former volume by all those center pivot
rigs, which are in turn being shut down now, either because the cost of
deepening the well to reach water is too high, or the energy cost to push
it up a 1000' pipe takes all the profit. I could see that coming when they
drilled one such well on the property adjacent to KXNE in the 70's. That
rig was pulled in, drilled a 36 hole 370' deep, cased installed a 500 hp
Re: [Emc-users] Tool change question
fanuc controls offer the current state of the controller modes via their
current parameter values, including the current values of the various axes.
so, for example, a g28 x0 command could equivalantly be g#2002 x-#5030, where
parameter 5030 is the axis position, and parameter 2002 is 0, 1, 2, or 3,
reflecting the presiding state of the modal group for axis interpolation.
maybe this is not the best example, but machine mode condition being registered
in program accessible space comes in handy in many places, like in a tool
change routine.
another controller feature that is nice is the ability to overwrite controller
words with customized subroutines. for example, commanding T6 will invoke a
subroutine (number defined by the T overwrite parameter setting) that will move
the machine to the toolchange position, set up the spindle, change to the
called tool number (T's input value), and maybe even set up the appropriate
offset from the tool height offset table (which is another section of the
controller's parameter space).
i seem to remember linuxcnc looking like it had alot of those type of things
analogously accessible through parameter space. i'm sure i saw stuff about the
work coord params, and tool offsets i think. ..sections 12.5 and 12.13 of emc2
user manual talk about parameters and machine modes, but i dont see any
comprehensive listing of numbered params.
12.5 Numbered Parameters
A numbered parameter is the pound character # followed by an integer between 1
and 5399. The
parameter is referred to by this integer, and its value is whatever number is
stored in the parameter.
then it says something about a few params that are read only based on current
tool number. i'm guessing the other several thousand should logically have all
the other relevant info in them, but there is no documentation. no
documentation = might as well guess the cost of a fully specified device. or
bust out your fishing gear and all of your spare time, and maybe you'll get
luckey.
--- On Fri, 3/23/12, gene heskett ghesk...@wdtv.com wrote:
From: gene heskett ghesk...@wdtv.com
Subject: Re: [Emc-users] Tool change question
To: emc-users@lists.sourceforge.net
Date: Friday, March 23, 2012, 7:59 AM
On Friday, March 23, 2012 10:23:48 AM
Erik Christiansen did opine:
On 22.03.12 11:24, gene heskett wrote:
On Thursday, March 22, 2012 09:59:01 AM Erik
Christiansen did opine:
But LinuxCNC doesn't know its current state
in an exportable way, so
has nothing to put on a stack, AIUI. And we
don't have gcode
interrupts. For the moment, we seem to only
have the recommended
good practice of starting each file with
explicit modality
settings.
When axis is in the MDI (F5) mode, it does display
the machine and
LinuxCNC state. To me that says either axis
is tracking it in real
time, or LinuxCNC does have the ability to export
that state.
Ah, but does it follow that just because AXIS knows its
state, we can
export it for Kirk's checking (if we still want to do
that), or even
test modalities directly in gcode?
If there is a way, then I could simplify the gcode
generated for the
following HR subroutine. The gcode needs to use
relative distance mode
for the three-hole G81 to work, but the sub might be
invoked in a run of
absolute code. BANG! Things go crunch if we don't
restore whatever was
the distance mode before the sub was called.
Valid point, and one that has bitten me in one form or
another several
times.
Sub drill_em_there (123.456,
789.012) {
Rel Drill
X#1 Y#2 Z1.5 Retract 2.8 Repeat 3 //
Drills 3
holes. }
I just got lost, 3 holes but only one XY specified? I
came into this scene
after it was outlined obviously. :)
That currently translates to gcode which tests for the
previous distance
mode, and conditionally restores it before returning:
O105 sub [123.456] [789.012]
G91 G81 X#1 Y#2 Z1.5 R2.8
L3
;
Drills 3 holes. O106 if
[#abs_modality EQ 1]
G90
O106 endif
O105 endsub
Which in turn relies on the HR mode settings:
Motion = Absolute
Motion = Relative
generating this gcode, to make the current state known
in gcode:
G90 #abs_modality=1
G91 #abs_modality=0
If there's a way to know current modes at any program
point, using only
existing gcode capability, then I'd be quite keen to
know, because
there's no point doing extra stuff if there's a simpler
way.
Each file can then explicitly reassert
anything non-standard that it
needs. It might be good practice to only
break programs between
self-contained processes. If that is done,
then including a common
file may be a workable solution.
It sounds good to me. But might turn into a
bookkeeping problem for
the operator who is assembling all these bit
pieces. He
Re: [Emc-users] Tool change question
On Mar 23, 2012, at 10:16 , charles green wrote: i seem to remember linuxcnc looking like it had alot of those type of things analogously accessible through parameter space. i'm sure i saw stuff about the work coord params, and tool offsets i think. ..sections 12.5 and 12.13 of emc2 user manual talk about parameters and machine modes, but i dont see any comprehensive listing of numbered params. http://linuxcnc.org/docs/2.5/html/gcode/overview.html#sec:parameters Our docs are a bit unwieldy to search… I usually use the google and prefix my search with site:linuxcnc.org/docs, for example like this: site:linuxcnc.org/docs numbered parameters Another gotcha to watch out for is to make sure you're looking at the right *version* of the docs. We currently publish docs for 2.4, 2.5, and master (the bleeding edge development branch). -- Sebastian Kuzminsky -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Total OT - TV signal
2012/3/23 Erik Christiansen dva...@internode.on.net: That hill and its trees are casting a signal shadow. Yupp, exactly! Do you have a friend living on the top or side of the hill? No, it is relatively small - less 10 m high, pretty close to house. There are only trees on it, no buildings or anything else, and the trees are the main shield that block signal. It is right next to the yard, trees are 30-40 from house. Radio amateurs have sometimes made a passive repeater by cabling two Yagi antennas back-to-back, and mounting them on a pole (or two) on top of the offending hill, one pointed at the transmitter, and one pointed at the receiver. I don't have first hand experience of how much they help, but it would be interesting to try. Now this sounds interesting! Is there a place, where I can read, how are such things set up? I am thinking that such a repeater could be placed on the roof of barn (very far end of it is not blocked by the trees on the hill), which is not the place, which could be conveniently reached with a coaxial cable. Are the Yagi antennas mandatory or could I use normal TV antennas (I think there must be several more smaller antennas lying around)? The set-up might bend local regulations. Who cares? Good picture in TV is what matters :)) Viesturs -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Total OT - TV signal
If your terrestrial receiver is 3 years or so old, you may want to look into a newer tuner. The chip sets in the newer tuners have better multipath rejection/equalization, and can pick out the digital signal better from the ghost signals. In digital more signal is not necessarily better if you have multipath. In multipath, the signals that arrive from an indirect path can cancel some bits when mixed in with the signal from the direct path, making the decoding very difficult. This is called the digital cliff. It either works, and you get a clean picture, or not picture. I fyou are looking over trees hills, you have multipath! I am in the L. A. Ca area and have a clean view of Mt. Wilson (the main broadcast point here), yet with the early tuners only could receive 3 or 4 channels, due to multipath. A new tuner two years ago, and now get 28+ channels with no change to my antenna. Good luck! Ray On Fri, Mar 23, 2012 at 7:14 AM, Erik Christiansen dva...@internode.on.netwrote: On 23.03.12 15:24, Viesturs Lācis wrote: The thing is that there is a hill with trees on one side of the house. It is very nice, because to large extent it protects the house from western winds (statistically wind from west is most common in LV, as it blows from sea/ocean to continental inlands), but it is exactly on the transmitter - house roof path. The remaining 3 sides of the yard are open in terms of hills, trees etc. That hill and its trees are casting a signal shadow. Do you have a friend living on the top or side of the hill? Radio amateurs have sometimes made a passive repeater by cabling two Yagi antennas back-to-back, and mounting them on a pole (or two) on top of the offending hill, one pointed at the transmitter, and one pointed at the receiver. I don't have first hand experience of how much they help, but it would be interesting to try. As explained by others, high-gain antennas will work best, but need to be fairly well aimed at both targets. The set-up might bend local regulations, since it's re-radiating the TV signal, but since the only measurable outcome is an improved TV signal behind the hill (at least around your house), it could be worth trying, especially if the hill is fairly close, and you're in a rural setting where there are few neighbours to notice. Erik -- A computer is like an air conditioner, it works poorly when you open Windows. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Tool change question
nicer, but still only a handful of documented params. i was looking at a document dated a little over a year ago (11jan2011). do you know if the params #31 to #5000 contain useful info? like g90/g91 state, for example, or any registration of the other groups apart from group 12? you started this. show me everything. - ellen ripley --- On Fri, 3/23/12, Sebastian Kuzminsky s...@highlab.com wrote: From: Sebastian Kuzminsky s...@highlab.com Subject: Re: [Emc-users] Tool change question To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Date: Friday, March 23, 2012, 9:23 AM On Mar 23, 2012, at 10:16 , charles green wrote: i seem to remember linuxcnc looking like it had alot of those type of things analogously accessible through parameter space. i'm sure i saw stuff about the work coord params, and tool offsets i think. ..sections 12.5 and 12.13 of emc2 user manual talk about parameters and machine modes, but i dont see any comprehensive listing of numbered params. http://linuxcnc.org/docs/2.5/html/gcode/overview.html#sec:parameters Our docs are a bit unwieldy to search… I usually use the google and prefix my search with site:linuxcnc.org/docs, for example like this: site:linuxcnc.org/docs numbered parameters Another gotcha to watch out for is to make sure you're looking at the right *version* of the docs. We currently publish docs for 2.4, 2.5, and master (the bleeding edge development branch). -- Sebastian Kuzminsky -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Total OT - TV signal
In case anyone might be interested. I want to get a receiver for HD Radio, http://en.wikipedia.org/wiki/HD_Radio but would also like to have the receiver in my attic and stream the audio through my LAN. I found this chip: http://www.silabs.com/products/audiovideo/automotive-tuners/Pages/Si4768-69.aspx It seems these and other Silabs chips do some pretty nifty things with all kinds of radio. Sparkfun has boards for a similar chip but no HD. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Total OT - TV signal
Viesturs, I should have read your message more investigatively. In our area, DVB-T is no problem because everybody still have the old antennas on the roofs and the transmitted channels are the same, to. If you don't have the rakes anymore, try to get one from people who have gone satellite. Identify from which direction the signal is coming (or find out where the transmitters are) and try to find out their frequency for maximum gain. Here in our village home, in the open on the back terrace, I get about 20 programs with a 8 cm antenna plugged directly into the back of the TV set. Even better is an old room antenna, the sort we put on top of the living room closet, from way back when. Peter Viesturs La-cis schrieb: 2012/3/22 Peter Blodow p.blo...@dreki.de: First: are you sure the dish is directed correctly to the satellite? My apologies for not stating it clearly - it is DVB-T signal, terrestrial, not satellite. Thanks, Kirk and Gene! The antenna is ~2m long, its orientation is the same as previous antennas. I guess I might try another session of catching better signal, once it will get little warmer. Now the sun is really warm, but wind is nasty cold already on ground, so I do not want to know, what is it on the roof (although it is only 3-4 m higher:) ). -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Total OT - TV signal
On Sat, 24 Mar 2012 01:14:19 +1100 Erik Christiansen dva...@internode.on.net wrote: On 23.03.12 15:24, Viesturs Lācis wrote: The thing is that there is a hill with trees on one side of the house. It is very nice, because to large extent it protects the house from western winds (statistically wind from west is most common in LV, as it blows from sea/ocean to continental inlands), but it is exactly on the transmitter - house roof path. The remaining 3 sides of the yard are open in terms of hills, trees etc. That hill and its trees are casting a signal shadow. Do you have a friend living on the top or side of the hill? Radio amateurs have sometimes made a passive repeater by cabling two Yagi antennas back-to-back, and mounting them on a pole (or two) on top of the offending hill, one pointed at the transmitter, and one pointed at the receiver. I don't have first hand experience of how much they help, but it would be interesting to try. As explained by others, high-gain antennas will work best, but need to be fairly well aimed at both targets. The set-up might bend local regulations, since it's re-radiating the TV signal, but since the only measurable outcome is an improved TV signal behind the hill (at least around your house), it could be worth trying, especially if the hill is fairly close, and you're in a rural setting where there are few neighbours to notice. Erik Since it is passive I'm not certain it breaks any regs. Besides what proportion of the population would recognize one if they saw it? Dave -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Unhoming when powered off.
My gantry still has some spring in it. If I manually cut power, or fault, the slaved axis move slightly, so when I try to power on again (F1/F2), it immediately faults. I need to unhome, go back to joint mode and rehome, but I can't because Axis disables the unhome menu options. Is there any technical/safety reason I shouldn't be able to unhome when powered off? I've still yet to look at the code to see if it is possible. Frank -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Unhoming when powered off.
On Mar 23, 2012, at 13:17 , Frank Tkalcevic wrote: My gantry still has some spring in it. If I manually cut power, or fault, the slaved axis move slightly, so when I try to power on again (F1/F2), it immediately faults. I need to unhome, go back to joint mode and rehome, but I can't because Axis disables the unhome menu options. Is there any technical/safety reason I shouldn't be able to unhome when powered off? I've still yet to look at the code to see if it is possible. This feature is already there, check out [AXIS_*]VOLATILE_HOME -- Sebastian Kuzminsky -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] C Compiler
On Tue, 20 Mar 2012 06:51:38 -0400 Erik Friesen e...@aercon.net wrote: I don't know whether you'll have to switch or not. You can still try mplabx, but it may take some effort to get everything going. You can turn in a support ticket now, its just whether or not you want to spend the time getting it going. Personally, after an initial test, I am letting others go through the headache before I try again. The IDE is much better though, so I am using the IDE and debugging with 8. Why did you pick the 30 series? I prefer the 33 series, although they are 3.3 volts. The ADC's on the 30 series don't seem very linear to me. Most new development seems to be with the 33 series. Hi Erik: I may just load this stuff up on my xp machine and do what I need. Your dealing with a complete amateur here. I am not a programmer, yet, at least with the dspic's. I am building a servo board that someone else designed and wrote a c program for. While I have wrote several programs, long ago. Back then, I was writing instructions for a coordinate measurement machine called a cordex. These instructions were in the form of very early numerical control format. The numerical controlled milling centers, that were in the shop, used the same type of punched paper tape my machine did, for recording the program, but the commands for their machines were g code and mine was not. A few years after I moved to Florida and opened my art studio, I realized that the stuff I was writing was not much different than basic. Bendex corp. changed the format of the commands, but I think that is all it was. If I wanted to read the code for errors, I had to have the terminal print it, no monitor. I am a man in a cardboard box, in the middle of the river, without a paddle! Bill -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] PM - Re: OT - Re: Tool change question
On 3/23/2012 4:11 AM, Mark Wendt wrote: On 03/22/2012 04:35 PM, Dave wrote: Now really OT! My tech book says: Case LA: 6516 lbs 4 cylinder engine 403 cu inches displacement!! 34 SAE drawbar HP My Case 400 is actually a model 411, but they were known as 400's. Case made a 400B model in the 60's that was a small tractor. 6144 lbs 4 cylinder engine 251 cubit inch displacement 35 SAE drawbar HP Yes, I am a tractor nut also... ;-) Case used a lot of cast iron and steel in the old tractors. Most of them are crazy heavy. John Deere's are green because you need a lot of green to buy and maintain them. They are good machines but expensive. Dave Nothing runs like a Deere, nothing smells like a John... ;-) Mark Obviously you are not a John Deere lover. I have been at farm auctions and one 4 bottom plow by Allis Chalmers will go for $200, the next plow is a 4 bottom John Deere of similar specs - it sells for $800. Seriously. Some John Deere fans are more like John Deere fanatics. Dave -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Tool change question
On 03/23/2012 11:42 AM, charles green wrote: nicer, but still only a handful of documented params. i was looking at a document dated a little over a year ago (11jan2011). do you know if the params #31 to #5000 contain useful info? like g90/g91 state, for example, or any registration of the other groups apart from group 12? you started this. show me everything. - ellen ripley Oh... I don't think you want to mess with that... - Hicks Parameters 31-5000 are deliberately unused by linuxcnc, and thus available for the g-code programmer to use. Ah yes, that's even what the docs say (somewhat cryptically, focus on the user parameters part): * /1-5000/ - G-Code user parameters. These parameters are global in the G Code file. The (slightly) improved docs in the master branch (http://linuxcnc.org/docs/devel/html/gcode/overview.html#sec:parameters) say this: 31-5000 G-Code user parameters. These parameters are global in the G Code file, and available for general use. Volatile. Oh hey look! In master (aka devel), there are some predefined named parameters that carry the g90/g91 state: http://linuxcnc.org/docs/devel/html/gcode/overview.html#_predefined_named_parameters_a_id_sec_predefined_named_parameters_a I think those variables are new in the master branch, and not available in the 2.5 branch. -- Sebastian Kuzminsky -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
