I think its useful to have a simulated spindle encoder in the sim configs so
G33.1 (and eventually G84) work in sim, too - currently executing a G33.1 in
sim/axis.ini just blocks execution which is counter-intuitive
It turns out all is needed for axis.ini to have a simulated spindle encoder is:
well, I go for usability, so I take 6% overhead and working over 1% and broken
any time.
Anyway let's give it a try with your approach:
the sim_spindle.comp didnt compile and needed a bit of polish
I created a sim config to integrate it which 'runs' - speed rampup/rampdown and
at-speed work
ok, this looks like it works now, I missed the rps/rpm scaling:
http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/sim-spindle
this probably needs a bit of polishing for multiple instances
-m
Am 05.01.2012 um 08:47 schrieb Michael Haberler:
well, I go for usability, so I take 6
but I get an error when I run git am.
error: patch failed: src/emc/rs274ngc/interp_cycles.cc:347
I think Rob also had a problem but he didn't spell it out but mentioned
git so I suspect it might be the same.
Thanks
John
On 1/6/2012 2:18 AM, Michael Haberler wrote:
I worked
Jeff,
that 'proposed change' sort of escaped into the wild in a wash of commits from
a 'mhaberler only' state of affairs.
I'll clean that up eventually.
- Michael
Am 11.01.2012 um 15:34 schrieb Jeff Epler:
I belatedly took a look at this proposed change.
The added file backtrace.cc
Hi Rob,
this was due to a missing K word and not properly testing for it, your example
now works for me if I add a positive K word to the G84.1 line
http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/g84-dev
this is rebased on master; you might want to
git reset --hard
Hi Rob
I think you should try G84.1 and G74.1 (left-hand)
G84 is as it was - defunct
see the nc_files examples
-Michael
Am 19.01.2012 um 00:16 schrieb Robert Harpham:
got it thanks
sorry did not try sooner
if u do a G84 with no spindle commanded u get
K word with no G2, G3, G33,
Am 19.01.2012 um 18:43 schrieb Jon Elson:
Michael Haberler wrote:
Hi Rob
I think you should try G84.1 and G74.1 (left-hand)
What is the difference between G84.1 and G33.1 ?
G84.1 and G74.1 are cycles, so you can do
G84.1 x0 y0
x1 y1
x2 y2
... etc
you cant do that with G33.1
-mah
these were dead before the rename already. Maybe somebody in the know can fix
them.
IRC: #LinuxCNC and #LinuxCNC-devel on irc.freenode.net
• Searchable IRC archives: [Austria] [Russia] working
• #LinuxCNC [IRC Archive] -- returns 404
back to normal.
-m
Am 21.01.2012 um 12:53 schrieb Michael Haberler:
I accidentially pushed a development tree to master
can someone help me with damage control?
-Michael
--
Try before you buy = See our experts
Dear EMC Board,
you recently announced the decision to rename EMC2, see below.
I do not take issue with the renaming decision per se - legal conditions are
what they are, and while I don't hear the 'buzz' just yet, I believe a unique
term will help, for instance better search engine results
Hi Davide,
why dont you just do this for edge detection (adapted from
configs/gladevcp/complex/complex.py):
def on_led_pin_changed(self,hal_led,data=None):
if hal_led.hal_pin.get():
print LED changed to true
else:
print LED changed to false
-
[this should move to emc-developers, which is why I'm cc'ing there]
it just occured to me that a decent parser would give us the opportunity for a
significant language simplification while retaining backwards compatibility.
An example for the current RS274NGC language with variable references,
Am 25.01.2012 um 23:46 schrieb Spiderdab:
On mer, 2012-01-25 at 20:39 +0100, Michael Haberler wrote:
Hi Davide,
why dont you just do this for edge detection (adapted from
configs/gladevcp/complex/complex.py):
def on_led_pin_changed(self,hal_led,data=None
Am 26.01.2012 um 09:58 schrieb Spiderdab:
Il giorno gio, 26/01/2012 alle 07.48 +0100, Michael Haberler ha scritto:
Am 25.01.2012 um 23:46 schrieb Spiderdab:
On mer, 2012-01-25 at 20:39 +0100, Michael Haberler wrote:
Hi Davide,
why dont you just do this for edge detection (adapted from
Am 25.01.2012 um 22:27 schrieb Kenneth Lerman:
On 1/25/2012 3:22 PM, Michael Haberler wrote:
[this should move to emc-developers, which is why I'm cc'ing there]
it just occured to me that a decent parser would give us the opportunity for
a significant language simplification while
and the link to linuxcnc.org/handbook is dead too
Am 19.01.2012 um 20:50 schrieb Michael Haberler:
these were dead before the rename already. Maybe somebody in the know can fix
them.
IRC: #LinuxCNC and #LinuxCNC-devel on irc.freenode.net
• Searchable IRC archives: [Austria
[I guess this better belongs here]
ok, while this wonderful discussion was raging on, I built a working parser for
the current linuxcnc dialect, as an experiment in feasability (this is NOT an
end-user tool!)
http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/parser-v2-dev
-
different interpretations of the rs274*...
EBo --
On Wed, 1 Feb 2012 00:10:04 +0100, Michael Haberler wrote:
[I guess this better belongs here]
ok, while this wonderful discussion was raging on, I built a working
parser for the current linuxcnc dialect, as an experiment in
feasability
Am 25.01.2012 um 06:52 schrieb Sebastian Kuzminsky:
Are you proposing a way to stop petting the watchdog from HAL, so that a
HAL circuit can cause a watchdog bite?
actually it would be useful to be able to trigger a watchdog bit from other
places than HAL, for instance a task crash.
and so are 3 out of 5 links under Documentation/The manuals---PDF style
who can fix this?
-m
Am 28.01.2012 um 17:20 schrieb Michael Haberler:
and the link to linuxcnc.org/handbook is dead too
Am 19.01.2012 um 20:50 schrieb Michael Haberler:
these were dead before the rename already
Am 08.02.2012 um 16:38 schrieb andy pugh:
On 19 January 2012 21:50, Michael Haberler mai...@mah.priv.at wrote:
these were dead before the rename already. Maybe somebody in the know can
fix them.
IRC: #LinuxCNC and #LinuxCNC-devel on irc.freenode.net
• Searchable IRC archives
I'd look at referring to an external package only if it is big, changes a lot
or something breaks; and in the case of the VFD modbus library (really just two
files) I think including them is sufficient
I dont think its worth the extra dependency and seeing what has changed -
modbus looks like
Am 13.02.2012 um 10:14 schrieb Spiderdab:
I'm sure with my pc i can have an higher recording rate. The problem is
that when i've tried to record every 1/10 of sec doing rapid 3D
movements (let's say 1 m/s) the curve is recorded in little lines (one
every 1/10s..) so when i reproduce the
13.02.2012 um 12:49 schrieb Spiderdab:
Il giorno lun, 13/02/2012 alle 11.48 +0100, Michael Haberler ha scritto:
Am 13.02.2012 um 10:14 schrieb Spiderdab:
I'm sure with my pc i can have an higher recording rate. The problem is
that when i've tried to record every 1/10 of sec doing rapid 3D
here are a few addenda for gladevcp:
http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/gladevcp-touchups
- reworked reading gtkrc files as per cmorley's recommendation
- assure that Ctrl-C/SIGTERM can be caught and persistent state saved
- document fixes
Psha reviewed it, and
@docbook:'ini':ini}
:hal: {basebackend@docbook:'hal':hal}
:ngc: {basebackend@docbook:'ngc':ngc}
Maybe some kind soul can help on integrating this.
- Michael
for /usr/share/texmf-texlive/tex/latex/listings/lstlang1.sty:
%%% begin LinuxCNC
%%%
%%% INI files - Michael Haberler 2012
\lst
test.
On Feb 17, 2012, at 16:31 , Michael Haberler wrote:
interp/python: drop reference to shared_ptr, use boost::cref
Using cref ensures that a call from C++-Python does not instantiate a
new wrapper object for 'self'.
Adapt interpreter calls to changed pythonplugin interface.
http
Am 18.02.2012 um 10:33 schrieb Chris Morley:
I notice that active g-codes and active m-codes are not updated
during auto mode (running a program).
Is there a good reason for this?
I want to detect when m7 and m8 are active and do something.
what's the flow you want to have?
-m
It
Am 18.02.2012 um 23:34 schrieb andy pugh:
On 18 February 2012 21:56, tuxcnc tux...@gmail.com wrote:
/usr/bin/ld: objects/hal/classicladder/socket_modbus_master.o: undefined
Possibly linked to:
http://thread.gmane.org/gmane.linux.distributions.emc.devel/5879/focus=5915
no, I dont think
Am 23.02.2012 um 10:22 schrieb Frank Tkalcevic:
I'm new to git so I may have completely misunderstood what git can do,
but...
I have more than one linuxcnc machine now, and they all have customisations
to the source.
As I understand it, I should be able to up my own main repository
Am 23.02.2012 um 21:41 schrieb Frank Tkalcevic:
Second question, can this main repository be set up on github? Given
that github is free, it seems like a good place to store it.
Any idea how? I've read about fork on github, but that only seems
to apply to repositories hosted on github.
oh, good - I wasnt sure at first what to make of the question.
docs examples clear enough?
-m
Am 15.03.2012 um 07:05 schrieb Chris Morley:
Is there a way to leverage gladevcp ( eg hal_widgets) to be able to register
my own HAL pins and call my own functions?
In this case the HAL pin
at this point largely a theoretical question, nevertheless:
besides HAL pin function, and NML channel naming - are there any strong
reasons why motion is a singleton module?
(unique externs for instance?)
I'm not talking about the status quo where (I think) you cant run more than one
task
One of the glaring interpreter issues I consider repairing is the current state
of affairs of line numbers.
I have laid out the issue, and a sketch for a solution here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LineNumbers
I plan to do something about it - but only after the requirements have
Kirk,
Am 21.03.2012 um 21:30 schrieb Kirk Wallace:
On Wed, 2012-03-21 at 18:57 +0100, Michael Haberler wrote:
One of the glaring interpreter issues I consider repairing is the current
state of affairs of line numbers.
I have laid out the issue, and a sketch for a solution here:
http
Kim,
this shouldnt be hard to do (where's the linuxcnc volunteer force when we need
them ;)
however it's strictly an interpreter lexical issue since the N-numbers are
ignored anyway, and have no bearing on the semantics of sloc's/source context
-m
Am 23.03.2012 um 06:56 schrieb Kim Kirwan:
please try this and let me know if this is what you want:
http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/fractional-linenumbers
-m
Am 23.03.2012 um 06:56 schrieb Kim Kirwan:
Hi Michael,
This is probably the wrong place to mention this, but...
It would be great if at some
this was recently discussed on emc-devel
as for 2.5 - at least I have no plans to do that and its a bit late in the game
master: there is configure support to detect libmodbus2 or libmodbus3
installation, the vfs11-vfd driver will only be built if libmodbus3 is detected
I dont think including
Hi Fabio,
since I dabbled with Eclipse for a while, and switched back to using Emacs:
I found Eclipse not worth the effort and overhead except for a few rare cases,
which are:
- the Python debug plugin by Aptana is great
- refactoring support for some basic tasks, like renaming global
looking at the very nice Zguide manual (http://zguide.zeromq.org/page:all) and
how it was built I stumbled over http://code.google.com/p/wkhtmltopdf/, which
converts html to pdf.
I thought I give it a stab and see how the online docs come out in pdf if
processed with wkhtmltopdf.
I ran those
I think some features in Yishin Li's code would be an interesting addition to
linuxcnc, in particular those:
..Just want to let you know that we've implemented NURBS motion and S-Curve
velocity profile for TRAJ and JOGGING on our git repository at
https://github.com/artek/emc2
I plan to
I've made some progress on RFL on steroids by introducing a new concept,
Interpreter watchpoints.
I've laid out idea, proof-of-concept and usage ideas here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?WatchPoints
- Michael
Am 21.03.2012 um 18:57 schrieb Michael Haberler:
One of the glaring
Am 01.04.2012 um 06:54 schrieb Jon Elson:
Yishin Li wrote:
...
All you need is an encoder with index on the spindle.
which might even be a simulated one to start with; Jeff came up with one and I
merged it, also all the sim configs use this simulated encoder:
08:12 schrieb Michael Haberler:
Am 01.04.2012 um 06:54 schrieb Jon Elson:
Yishin Li wrote:
...
All you need is an encoder with index on the spindle.
which might even be a simulated one to start with; Jeff came up with one and
I merged it, also all the sim configs use this simulated
Michael Haberler:
One of the glaring interpreter issues I consider repairing is the current
state of affairs of line numbers.
I have laid out the issue, and a sketch for a solution here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LineNumbers
I plan to do something about it - but only after
I regularly see folks reinventing stuff which has been done, and implemented
and documented, including myself ;). No wonder, because the manuals are big,
and we have no change bars or such in place.
Looking around I found this, and is very useful to quickly view the difference
of two html
-
Von: Michael Haberler [mailto:mai...@mah.priv.at]
Gesendet: Donnerstag, 5. April 2012 00:49
An: EMC developers; Enhanced Machine Controller (EMC)
Betreff: [Emc-developers] manuals: what has changed? viewing the difference
of two versions of a HTML page
I regularly see folks
Viesturs -
Nothing is impossible to the determined coder!
Here is your starting point to realize your dreams:
http://static.mah.priv.at/public/walk.py
and here is how output currently looks:
http://static.mah.priv.at/www.linuxcnc.org/docs/devel/html/changes.html
You wont fail to note the
family, it is
hard at times.
So I am jealous . . .
Cheers
j.
On Thu, Apr 5, 2012 at 6:45 PM, Michael Haberler mai...@mah.priv.at wrote:
Viesturs -
Nothing is impossible to the determined coder!
Here is your starting point to realize your dreams:
http://static.mah.priv.at
I've threatened to do this, and since it is slowly moving towards master, I
thought I'd reduce the surprise factor by laying out plan and status:
The rundown of what it aims to fix:
• GUI's will be able to highlight source location wherever it comes from:
main.ngc, an oword subroutine, Python
/selfesteem.html
-m
Am 09.04.2012 um 19:21 schrieb Jon Elson:
Michael Haberler wrote:
I've threatened to do this, and since it is slowly moving towards master, I
thought I'd reduce the surprise factor by laying out plan and status
Wow, impressive list! Run from line sure has some deficits, so any
sure that whatever changes you
make will be an improvement.
Regards,
Ken
On 4/9/2012 8:13 AM, Michael Haberler wrote:
I've threatened to do this, and since it is slowly moving towards master, I
thought I'd reduce the surprise factor by laying out plan and status:
The rundown of what
. Some
of us might have to upgrade to five year old computers :-).
Thank you taking this on, Michael. I'm sure that whatever changes you
make will be an improvement.
Regards,
Ken
On 4/9/2012 8:13 AM, Michael Haberler wrote:
I've threatened to do this, and since it is slowly moving
Ken,
...
lets look at 1): Interp state as per _setup currently has some 140+
variables, including maps, sets and arrays. Plus, there's some implicit
state in canon static variables, the CRC canon queue, and probably some
other places I havent thought of. keeping state differences for all
(I'm impressed !)
Now I know this isn about simulation, still:
I suggest anybody interested in interpreter issues give the source a strong
look, there's some fresh ideas here (plus style ;-):
- the interpreter lexically and syntactically understands pretty much all of
the current Linuxcnc
that be critical mainly for the TP queue I guess, the rest of them (1,2,4 in my
list) is quite macroscopic
actually some of the ideas floating around could result in improvements:
- multithreading: interpreter in its own thread without being lockstepped by
task has upside potential (on modern
in following the venerable tradition if everything else fails, look how Fanuc
does it:
here's what I found on valid operations during feedhold on some Fanuc controls,
I wasnt aware of those features, and I summarize them to encourage thought
about this sore spot in linuxcnc.
during a feed
I decided to ignore the conventional wisdom that it cannot be done, and gave it
a try.
here are some prelimary results:
http://www.youtube.com/watch?v=yJPLJGdiQWwfeature=plcpcontext=C494ebbdVDvjVQa1PpcFOUhIqfm3XcEJtse1eR8fqk7sO0WffoNSU%3D
Obvious use: retract tool, clean swarf, continue
Am 25.04.2012 um 00:42 schrieb andy pugh:
On 24 April 2012 23:16, andy pugh bodge...@gmail.com wrote:
git remote add mah git://git.mah.priv.at/emc2-dev.git
git checkout -b mah/fanuc-general-purpose-retract
for the instoppably determined, the video demo branch is:
Unsure how to adress this: Jogging assumes free mode.
during the 'jog while paused' thing I posted yesterday motion is in coordinated
mode, so jogging normally wouldnt work.
to make it work, I see the following options:
1. just jog in cartesian space (any obvious reason why this shouldnt be
Thomas Powderly:
Michael Haberler,
re: the interrupt,retract, recover, continue
Hello,
extremely interesting
can i try the code?
or
could you try retreating from a circle to the apex of a cone?
( that is equivalent to the 'safe position' in sink edm orbits )
( or, apex of a pyramid while
Am 25.04.2012 um 12:43 schrieb andy pugh:
On 25 April 2012 07:36, Michael Haberler mai...@mah.priv.at wrote:
2) assumes forward kins is available which might not be the case.
What are the other limitations of an inverse-only kins machine?
I wish I fully understood; there's a bit
Here's Ken Lerman's idea worked in: jog in coordinated mode during pause
http://www.youtube.com/watch?v=2wabcOH9YAA
I'm entertaining feedback on the principle; this is not a patch yet; it's still
shaky on abort and limit checking.
The nice thing is that it's fairly unintrusive - all through
so what's the idea?
Do you want to have the option to jog in coordinated mode in manual?
- Michael
Am 26.04.2012 um 12:53 schrieb Viesturs Lācis:
2012/4/26 Michael Haberler mai...@mah.priv.at:
The only gotcha I see is - this is coord mode, so its axes not joints input,
this might
Am 30.04.2012 um 11:44 schrieb Viesturs Lācis:
2012/4/30 Michael Haberler mai...@mah.priv.at:
I've integrated the jog-while-paused with the normal Pause,Step and Resume
handling and it approaches usability:
A writeup: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Jog-While-Paused
Branch
on #linuxcnc-devel there's currently a discussion (mostly cradek and me in the
last few days) about a future linuxcnc design. In that context, 'queuebusters'
and the synchronization of interpreter state came up.
I think I came up with a more elegant, flexible and language independent
solution
Am 01.05.2012 um 22:35 schrieb Viesturs Lācis:
2012/5/1 Michael Haberler mai...@mah.priv.at:
on #linuxcnc-devel there's currently a discussion (mostly cradek and me in
the last few days) about a future linuxcnc design. In that context,
'queuebusters' and the synchronization of interpreter
Am 01.05.2012 um 23:22 schrieb Viesturs Lācis:
2012/5/2 Michael Haberler mai...@mah.priv.at:
The background was the following: we discussed changes which would permit
changing tool offset and cutter radius during a pause operation.
Under the current scheme, this would mean
Am 02.05.2012 um 08:22 schrieb Viesturs Lācis:
2012/5/2 Michael Haberler mai...@mah.priv.at:
Assuing that existed: when you hit 'Pause' and 'switch to MDI', the
following things need to happen:
- The currently executing trajectory planner queue in motion is put to rest
Am 02.05.2012 um 10:30 schrieb Viesturs Lācis:
2012/5/2 Michael Haberler mai...@mah.priv.at:
So, 'changing to MDI, fiddling some parameters and returning to auto with
the new parameter settings' in the general case isnt what you want because
of the side effects. What is probable doable
Am 02.05.2012 um 11:08 schrieb Viesturs Lācis:
2012/5/2 Michael Haberler mai...@mah.priv.at:
The only change wrt to the interpreter is the access modality for tool
length offset and tooldiameter parameters (#54xx): so far those were
considered untainted because no entity except
for a line is
a constant.
Thanks for your work on this.
Regards,
Ken
On 5/1/2012 4:14 PM, Michael Haberler wrote:
on #linuxcnc-devel there's currently a discussion (mostly cradek and me in
the last few days) about a future linuxcnc design. In that context,
'queuebusters
.
Ken
On 5/2/2012 11:23 AM, Michael Haberler wrote:
Ken,
you're perfectly right.
I'll update the note with a rundown of per-parameter, per-block, and global
memory and processing 'cost'. I guess I was carried away when I wrote up
what looks like a CS101 homework in style
to execution states.
The above reflects my understanding of IRC discussions with Chris, I hope this
matches his. We still need to write this down, this is very early into the
shakeout process.
- Michael
Regards,
Ken
On 5/2/2012 4:57 AM, Michael Haberler wrote:
Am 02.05.2012 um 10:30 schrieb
Am 02.05.2012 um 18:24 schrieb Michael Haberler:
Am 02.05.2012 um 16:07 schrieb Kenneth Lerman:
Michael,
It appears that there might be a problem with cutter radius
compensation. Whenever that mode is on, lookahead will be effectively
disabled because any pause can cause
Gene reported that 'queuing MDI commands in master does not work since MDI tab
is greyed out while last command running' (btw a bug report would still help if
to aggregate tracking)
this is due to
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commit;h=81f105b477699060d6c721a06034aceea31cb964
, for instance MDI-queue not full, if it were to have a
limited size).
I forgot to mention that an interpreter abort should flush the UI side MDI
queue to prevent damage
- Michael
John
On 5/2/2012 8:33 PM, Michael Haberler wrote:
Gene reported that 'queuing MDI commands in master does not work since
Am 03.05.2012 um 17:35 schrieb Chris Radek:
On Thu, May 03, 2012 at 01:35:13PM +0200, Michael Haberler wrote:
note I proposed handling proper queuing of MDI commands by modifying
Axis to have a queue of MDI commands, and feed them to task one by one
within the interpreter state constraints
.
On Thu, May 3, 2012 at 9:14 PM, Michael Haberler mai...@mah.priv.at wrote:
Am 03.05.2012 um 17:35 schrieb Chris Radek:
On Thu, May 03, 2012 at 01:35:13PM +0200, Michael Haberler wrote:
note I proposed handling proper queuing of MDI commands by modifying
Axis to have a queue
here's a first cut for 'queued MDI' which actually has a queue and doesnt only
work by accident:
http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/queued-mdi
The basic idea is:
- a queue in task to serialize MDI commands
- feed interp on pertinent state change
- mirror the MDI
Am 26.05.2012 um 02:23 schrieb andy pugh:
On 26 May 2012 01:08, Michael Haberler mai...@mah.priv.at wrote:
has a queue and doesnt only work by accident:
We call it Serendipity not Accident :-)
well, whether it's the former or the latter really depends on the type of
command which one
I added support for queued MDI execution; thanks to Jeff for helping.
queued MDI is implemented in Axis
to enable support for other UI's:
-
pre-55d93a8f 'queueing worked' due to improper state tracking by task -
interp_state would always be reported as
the current manual describes:
http://www.linuxcnc.org/docs/devel/html/gcode/overview.html#_numbered_parameters_a_id_sub_numbered_parameters_a
5420-5428
Current Position including all offsets and in the current program units for X,
Y, Z, A, B, C, U, V W. In absolute machine coordinates,
John
On 5/29/2012 8:57 AM, Michael Haberler wrote:
the current manual describes:
http://www.linuxcnc.org/docs/devel/html/gcode/overview.html#_numbered_parameters_a_id_sub_numbered_parameters_a
5420-5428
Current Position including all offsets and in the current program units
Am 29.05.2012 um 16:56 schrieb Kenneth Lerman:
On 5/29/2012 10:39 AM, andy pugh wrote:
On 29 May 2012 14:57, Michael Haberlermai...@mah.priv.at wrote:
that said: there is still no way to retrieve the current *absolute* machine
position, that is, without any offsets.
Actually, there is,
schrieb John Thornton:
The only part that is confusing to me is In absolute machine
coordinates it might be more intuitive to say In relative machine
coordinates
John
On 5/29/2012 8:57 AM, Michael Haberler wrote:
the current manual describes:
http://www.linuxcnc.org/docs/devel/html
Am 30.05.2012 um 16:51 schrieb Viesturs Lācis:
2012/5/30 Łukasz Prymula luk...@cs-lab.eu:
For me, most interesting thing is that in what method planner transfers
trajectory to HAL layer. As you see I need points buffer.
AFAIK it is done with NML messages. I think that Michael Haberler
Lukasz,
Am 30.05.2012 um 15:30 schrieb Łukasz Prymula:
http://www.cs-lab.eu/en/index.php http://www.cs-lab.eu/en/index.php
It work over Ethernet with Mach only but we want to write the driver for
EMC2 software.
I think you need a HAL component which can talk to your device over UDP or TCP
Am 31.05.2012 um 14:35 schrieb andy pugh:
On 31 May 2012 12:19, Michael Haberler mai...@mah.priv.at wrote:
I think it is about time this community considers and decides what to do on
RT network I/O devices - a plethora of special-case contraptions is
undesirable IMO.
I see a mention
I wanted to learn about Fuse (http://fuse.sourceforge.net/) and did a prototype
halfs which makes the HAL namespace visible in the Linux filesystem.
To convey the idea, a usage example:
$ halfuse /tmp/hal
$ cd /tmp
$ ls hal/
components functions params pins signals threads
$ ls
Am 25.06.2012 um 15:13 schrieb andy pugh:
On 25 June 2012 12:11, Michael Haberler mai...@mah.priv.at wrote:
I wanted to learn about Fuse (http://fuse.sourceforge.net/) and did a
prototype halfs which makes the HAL namespace visible in the Linux
filesystem.
components functions params
Am 25.06.2012 um 17:56 schrieb Joachim Franek:
On Monday 25 June 2012 16:26:45 Michael Haberler wrote:
I would guess the more direct way to do this is a Python userland HAL
component (http://www.linuxcnc.org/docs/devel/html/hal/halmodule.html)
- use pyserial to access the port
- suffer
Am 25.06.2012 um 18:03 schrieb Michael Haberler:
Thanks for the hint.
Is there a plain c equivalent for
import hal ?
yes, make it a userland (non-RT) .comp component
or if you shy comp, see the userland HAL components under src/hal/user_comps -
those dont use .comp but the hal C api
helpful).
- Michael
On Mon, 25 Jun 2012 16:17:17 +0200, Michael Haberler wrote:
Am 25.06.2012 um 15:13 schrieb andy pugh:
On 25 June 2012 12:11, Michael Haberler mai...@mah.priv.at wrote:
I wanted to learn about Fuse (http://fuse.sourceforge.net/) and did
a prototype halfs which makes
will see.
If possible I would love to take a look at your code when available.
Best regards,
EBo --
On Mon, 25 Jun 2012 13:11:55 +0200, Michael Haberler wrote:
I wanted to learn about Fuse (http://fuse.sourceforge.net/) and did a
prototype halfs which makes the HAL namespace visible
Am 20.07.2012 um 08:06 schrieb Philippe Frossard:
Hi,
We are writting a little application in C inspired from different sources,
We are create an Hal structure with hal_malloc,
I would like to know if I need to use hal_set_lock or hal_get_lock to
access this structure ?
or if I can access
since I got interested: here's an example of using
__attribute__((cleanup(variable))) in HAL locking
http://git.mah.priv.at/gitweb/emc2-dev.git/commit/e121c0fb82f8ea408b9d3ddbb1eb6189e9caed4d
-m
Am 20.07.2012 um 08:49 schrieb Michael Haberler:
Am 20.07.2012 um 08:06 schrieb Philippe
looking at hal_lib.c some more:
the hal_set_lock() and hal_get_lock() functions are kind of misnomers IMO, all
they do is set a global *flag* which is NOT a mutex or atomic for that matter,
so it is advisory in nature and some of the routines in hal_lib.c report an
error if some lock bit is
a few semi-related notes:
I'd been looking into potential alternatives to the RCS/CMS/NML code in
Linuxcnc for different reasons:
- the restrictions are substantial: fixed message size, a very limited
interaction model (no really usable remote procedure call, no publish/subscribe
interaction,
1 - 100 of 832 matches
Mail list logo
