Hi Michael,
On Sat, 17 Nov 2012 10:31:44 +0100
Post by John MorrisHi Michael,
Post by Abel MichaelHi there,
I've updated my shared memory hal module and LinuxCNC adoption which
enables real time data transfer between LinuxCNC and other real-time
programs running on rt-preempt.
I reviewed your code and I have some questions
Thanks for reviewing my changes
I'm trying to answer your questions
Post by John MorrisFirst, I am a bit fuzzy as to what those 'other realtime programs' are
- could you explain? if it is of general use that would help to sell it
Other real-time programs might be for example the user part of a "user
space io driver" (uio) "https://www.osadl.org/UIO.uio0.0.html" or real
time simulation engines, which simulate machine kinematics.
Especially some fieldbus PCI cards use these uio drivers as they these
are easier to handle for non kernel developers.
In my case, with the sercans card from Bosch Rexroth, we will probably
need a program for the bus-management, that sits between a regular
driver and the cnc.
Post by John MorrisWhat I understand this does is periodically copy from/to a fixed set
of HAL pins and a shared memory segment intended for some other code.
That copy process introduces delay and possibly race conditions -
Well, I hope, that the delay to copy a bit of data is neglectable. The
semaphores are there to have the possibility to avoid race conditions.
By the way, in the example I made the, cnc is never blocked it just
releases the semaphore.
Post by John Morrisis it completely out of the question to extend the other code so it
can access pins directly? the big advantage of that would be: no copy,
no race condition, no extra single-purpose component, no RTAPI changes.
I'm not sure what you mean by "access pins directly"? Is it maybe
possible to read from and to write to hal pins? That might be also a
nice option.
Post by John MorrisPlease clarify what the 'RTAPI semaphores' mean - obviously they are
intended for communication between your external program and your
component, so I do not understand why it has to go into RTAPI to start
with, which is Linuxcnc-internal (btw please note we just removed
semaphore, fifo and irq handling code from RTAPi because that was never
used, and you need a really good use case to reintegrate it). I
understand the new RTAPI semaphore is only used in your code.
Originally, I've put the semaphore handling stuff into rtapi because
the function prototypes have been already there in rtapi.h.
As the semaphores are there to synchronize real-time processses rtapi
seems to be a good place. Moreover, the implementation will probably
look different on different platforms, another point for hiding this
stuff behind an API. But one has also to take into account, that the rt
IPC probably only makes sense on rt_preempt.
In reality it probably doesn't matter where the semaphore management
code is stored.
Is there maybe a better place available?
Post by John MorrisPost by Abel MichaelFrom a comment in the code it seems you were aware of race conditions
and consider blocking EMC2 until your component is done. This is not a
good idea because it will change the RT timing behavior.
Indeed, I have the plan to block linuxcnc while another process writes
to the shared memory. This is important to avoid race conditions, but
this must be done in a few micro seconds.
(It might be also nice to use sem_timedwait to wait only for a small
amount of time.)
Remember, what I like to do is basic support field-buses. You won't
need cycle times of 30us there because you still need to transfer data
through a bus system which is far slower
When you have servo drives that do an interpolation by themselves, you
also won't need a high cycle time. Even a few milliseconds might be
enough. I know these toys are expensive, but they are used in the
industry. And this might even be an option to get ready for such
industrial hardware.
Post by John Morris- I think interfacing to other programs is a valuable line of thought
and might have use cases
Thanks :)
Post by John Morris- it would help very much if the mechanism were generic, not
special-purpose/fixed set of/fixed types of pins
That's also a good point. I'm going to think about that.
The interface description is in the header file and must be known at
compile time. It may be possible to use two structures in the memory
where one is fixed and describes another dynamic one.
Post by John Morris- I think the copying mechanism will be a source of trouble and I
would go for a direct access mechanism if remotely possible
Can you maybe explain what you mean with this mechanism?
Post by John Morris- if you need synchronization primitives, I suggest the existing
non-blocking mutex operations in RTAPI which are based on atomic
operations - blocking is generally not a good idea in RT applications;
rather postpone until next thread invocation instead of blocking.
Well, when I'm right you can't share mutex variables between processes,
that's why I use semaphores. And of course you need to care about
proper real-time programming when you do such things.
It also seems like we need an option to let the user of the interface
choose between postponing, waiting and blocking (Thanks for the hint).
Post by John Morris--
Currently there is a duplicity of mechanism for status reporting in
LinuxCNC. We have shared memory status objects which are communicated
through NML messages, through special purpose code like usrmotif.cc, and
we have HAL, and we have halrmt glued on top of that. Some would call
that a terrible mess lacking style.
Post by John MorrisI think HAL is the strongest foundation of LinuxCNC, and it makes
therefore sense to consider how to tie HAL into messaging without
grafting several incompatible methods on top of HAL or shared memory one
way or the other, which is the situation we have now.
Post by John Morris- the may report typically several values together (like in your code, positions x,y,z)
- they are triggered either by timer expiring, or a change of some
value, for _some_ being dependent on the task.
Post by John MorrisI tried to abstract this functionality into HAL objects and commands,
and I arrived at an idea which I call 'HAL signal groups'. The gist of
Post by John Morris- HAL gets a new object, called 'group'. A group has a HAL name, and
(for now two) integer parameters which are for using code interpretation.
Post by John Morris- a group can have members which must be signals. Each member
descriptor again carries two parameters for using code interpretation.
Post by John Morris- the only extensions in HAL are to enable group management, see below for a halcmd example.
- periodically report a group by some mechanism (I used zeroMQ in the
examples below, but it might be your shared memory thing, or event NML).
Post by John Morris- watch a group for change, and report-if-changed. Now the member
parameters could tell the code *which* of the members are to be
monitored for change.
Post by John MorrisNote that this mechanism is completely generic within HAL, and HAL
itself does not do anything with groups or members. Using components do.
Post by John MorrisI wrote such a generic change reporter, and it can be found (in trial
stage) here:
http://git.mah.priv.at/gitweb/emc2-dev.git/tree/4259166865c681017b6009f041ac4d1ed5e16439:/src/hal/halreport
Post by John MorrisThere's a simple example of monitoring a hypothetical power supply
here:
http://git.mah.priv.at/gitweb/emc2-dev.git/blob/4259166865c681017b6009f041ac4d1ed5e16439:/src/hal/halreport/periodic+change-detect.hal
Post by John MorrisThe idea is: you get group reports containing volts, amps, fuse-ok and
mains-ok always together, but you trigger the update only if the fuse
blows or mains goes away, and you do that by setting member parameters
and have the using component interpret them.
Post by John MorrisThis is unmerged code, but as we are heading for a more distributed
setup I plan to clean it up and integrate it.
Post by John Morris- Michael
---- here is an example of the signal groups usage --
for code see
http://git.mah.priv.at/gitweb/emc2-dev.git/blob/4259166865c681017b6009f041ac4d1ed5e16439:/src/hal/halgroups/apiusage.c
Post by John Morris# declare a couple of signals
newsig volt float
newsig amps float
newsig havepower bit
# declare a signal group with id 12
# and (up to two) optional parameters
# these are no interpreted by HAL
newg meter 12 4711 815
# add some signals
# a member can have an optional integer param
# again, not interpreted, just carried by HAL
newm meter volt # optional param defaults to 0
newm meter amps 2
newm meter havepower 1
# a signal to be added as a member must
# newm meter ison
newsig ripple float
newm meter ripple
# display the group
show group meter
# and memory status
status mem
# if you now delete asignal which is a group member
# delsig amps
# to do so, first remove the signal from all
# delm meter amps
# delsig amps # will now succeed
When I understand right, you are thinking about an kind of eventing
mechanism. There are sources of events and subscribers can register to
receive events.
Do I understand correctly?
This would introduce a new nice kind of execution behaviour. It will
probably also reduce processing power when triggers/events happen seldomly.
But does it really help when things happen in every cycle?
Greetings
Michael
Post by John MorrisPost by Abel MichaelMy work is now put on top of the rtos-integration-preview1 branch from
Michael Haberler.
The functionality was also contained in earlier Versions of the
rt-preempt port I did on the basis of Michael Büschs work. But now, my
patch/adoption is clearer and smaller as the support for rt-preempt is
already there. And of course it's still beta.
Please pull branch shm_interface from
http://gitorious.org/emc-rt-preempt/emc-rt-preempt
cd /src/hal/drivers/shared_memory
make -f Makefile_shm
sudo chrt 90 ./shm_interface_test
http://www.bitmuster.org/projects/images/emc-shm-rt-gui.png
Regards,
Michael
Post by Michael HaberlerI have now integrated the RT-PREEMPT branch as provided by Charles,
added the now-working Xenomai-userland thread style, and massaged
configure to deal with all of this. The Xenomai-kernel branch I reported
about yesterday is fully integrated. If you played with that branch,
it's safe to switch.
Post by John MorrisPost by Abel MichaelPost by Michael Haberler./configure --with-threads=xenomai-user
./configure --with-threads=rt-preempt-user
./configure --with-threads=rtai
./configure --enable-simulator [--enable-drivers for the
hal_parport usermode driver]
http://static.mah.priv.at/public/xenomai-debs/linux-headers-3.4.13-rt-preempt-rt22+_0.1_i386.deb
http://static.mah.priv.at/public/xenomai-debs/linux-image-3.4.13-rt-preempt-rt22+_0.1_i386.deb
Post by John MorrisPost by Abel MichaelPost by Michael HaberlerThe notes from README.xenomai wrt initrd and update-grub apply as well.
Please pull from
http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/rtos-integration-preview1
Post by John MorrisPost by Abel MichaelPost by Michael Haberler- Michael
- The userland parport driver needs work - it cant claim the
parport yet :-/ The nice part is: you can fix it with gdb.
Post by John MorrisPost by Abel MichaelPost by Michael Haberler- runtests with rt-preempt-user shows errors, but that is because
stderr messages cause it to 'fail' whereas the regression output
actually is ok
------------------------------------------------------------------------------
Post by John MorrisPost by Abel MichaelPost by Michael HaberlerLogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
--
--------------------------------------------------------------
Dipl.-Ing. Michael Abel
Graduate School of advanced Manufacturing Engineering
GSaME - Universität Stuttgart
Institut für Steuerungstechnik
der Werkzeugmaschinen und Fertigungseinrichtungen
ISW - Universität Stuttgart
Seidenstr. 36
70174 Stuttgart
Tel.: ++49 (0) 711 685-82532
Fax : ++49 (0) 711 685-82808
www.gsame.uni-stuttgart.de
www.isw.uni-stuttgart.de
--------------------------------------------------------------
------------------------------------------------------------------------------
Post by John MorrisPost by Abel MichaelEveryone hates slow websites. So do we.
Make your web apps faster with AppDynamics
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Post by John MorrisMonitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
--
--------------------------------------------------------------
Dipl.-Ing. Michael Abel
Graduate School of advanced Manufacturing Engineering
GSaME - Universität Stuttgart
Institut für Steuerungstechnik
der Werkzeugmaschinen und Fertigungseinrichtungen
ISW - Universität Stuttgart
Seidenstr. 36
70174 Stuttgart
Tel.: ++49 (0) 711 685-82532
Fax : ++49 (0) 711 685-82808
michael.abel-PvR2ET76y1sL63KmMnjC+***@public.gmane.org
michael.abel-mmWg1XfvUW+***@public.gmane.org
www.gsame.uni-stuttgart.de
www.isw.uni-stuttgart.de
--------------------------------------------------------------
