Hi Michael, Am 12.11.2012 um 00:08 schrieb Abel Michael: > Hi 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 First, 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 What 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 - is 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. Please 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. >From 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. to summarize: - I think interfacing to other programs is a valuable line of thought and might have use cases - it would help very much if the mechanism were generic, not special-purpose/fixed set of/fixed types of pins - I think the copying mechanism will be a source of trouble and I would go for a direct access mechanism if remotely possible - 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. -- To clarify what I mean with a 'generic mechanism', here is some line of thought: 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. I 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. That said, looking at the status reporting task: what the mechanisms have in common is: - 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. I 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 the idea is this: - 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. - a group can have members which must be signals. Each member descriptor again carries two parameters for using code interpretation. - the only extensions in HAL are to enable group management, see below for a halcmd example. Now you can create a component which works on HAL groups, for instance: - 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). - 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. Note that this mechanism is completely generic within HAL, and HAL itself does not do anything with groups or members. Using components do. I 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 There'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 The 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. This is unmerged code, but as we are heading for a more distributed setup I plan to clean it up and integrate it. - Michael ---- here is an example of the signal groups usage -- for code see for HAL API usage see: http://git.mah.priv.at/gitweb/emc2-dev.git/blob/4259166865c681017b6009f041ac4d1ed5e16439:/src/hal/halgroups/apiusage.c # 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 # previously exist, so this will fail: # newm meter ison # but this succeeds: 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 # this fails: # delsig amps # to do so, first remove the signal from all # containing groups like so: # delm meter amps # delsig amps # will now succeed > > My 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 > > after compiling start the cnc and the rt-interface tester afterwards: > > cd /src/hal/drivers/shared_memory > make -f Makefile_shm > sudo chrt 90 ./shm_interface_test > > In the end it should look nearly like a year ago :) : > http://www.bitmuster.org/projects/images/emc-shm-rt-gui.png > > Regards, > > Michael > > > On 11/02/2012 04:18 PM, Michael Haberler wrote: >> I 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. >> >> this adds the following scenarios: >> >> ./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] >> >> >> for the RT-PREEMT flavor, please install >> >> 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 >> >> The 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 >> >> >> - Michael >> >> - The userland parport driver needs work - it cant claim the parport yet :-/ >> The nice part is: you can fix it with gdb. >> - runtests with rt-preempt-user shows errors, but that is because stderr >> messages cause it to 'fail' whereas the regression output actually is ok >> >> >> [so here's some drinking from the firehose for the weekend;) ] >> ------------------------------------------------------------------------------ >> LogMeIn 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 >> [email protected] >> 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 > > [email protected] > [email protected] > > www.gsame.uni-stuttgart.de > www.isw.uni-stuttgart.de > -------------------------------------------------------------- > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_nov > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Monitor 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
