Hi Michael, On Sat, 17 Nov 2012 10:31:44 +0100 Michael Haberler <[email protected]> wrote:
> 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 > Thanks for reviewing my changes I'm trying to answer your 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 > 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. > 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 - 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. > 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. 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. > > 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. 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? > > >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. 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. > > to summarize: > > - I think interfacing to other programs is a valuable line of thought and might have use cases Thanks :) > - 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. > - 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? > - 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). > > -- > > 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 > 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 > > > > 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 -- -------------------------------------------------------------- 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 -------------------------------------------------------------- ------------------------------------------------------------------------------ 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
