Ralph, Am 26.04.2013 um 15:43 schrieb Ralph Stirling <ralph.stirl...@wallawalla.edu>:
> This is fantastic, Michael! I am eager to work with this new > scheme this summer. let me manage expectations a bit here. What is currently winding through the buildbot at least partially, and sucessfully has been built and used are the rtos-integration-preview3 (v2.5_branch based) and rtos-integration-preview3-merged-into-master (master based). This is +/- some minor cleanups the codebase as we have it since late November, and provides the capability to build and run on all of the RT Linux variants; one build per variant, and stable. based on that John and me have worked on the unified binary branch, which is feature complete but not ready for downloading and building since some build work remains to be done. This code base will run unchanged on several RT Linux variants, and adapt as needed by investigating the environment. It has - basically as a side effect of going over the code - the multi-instance capability. However, it does not have the instance cross-linking capability I outlined; that I am still working on. The remote HAL components support code is ready and benign in nature, so I will likely include that once that branch matures; the crosslinking feature required some new RTAPI functionality, including a unified approach to managing shared memory, which is new. I therefore look at having this unified branch ready for test say end of May; however, it will bring few new features per se. It should, however, eventually simplify build and upgrade logistics significantly. There will be a set of features at the HAL/RTAPI level in a sequel branch which includes all the support for doing the 'realtime split' - separating the backend from any UI, interp, task etc blobs. I am looking at fall for this; I would think it has some NML-to-zeroMQ/Protobuf migration started but likely not complete; this is a lot of work. Plus, the namespace crosslinking feature requires some heavy lifting and careful sequencing of operation, so I wont rush that until I am sure it is reasonably bullet-proof. In summary, one could expect the HAL plumbing for HAL pipes (remote components) in place early this summer, including an example HAL pipe; I wont commit anything further out yet until it's safe ground. Meaning: realistically one could play with remote HAL links between machines this summer, provided it's a sufficiently rainy summer ;) - Michael > It opens up many new avenues that are > going to take some time to explore. I don't quite follow your > "semi-OT" statement at the end, but I do think this new code > will enable a lot of solutions to long-standing complaints and > wishes. > > Thanks for your hard work. > > -- Ralph > ________________________________________ > From: Michael Haberler [mai...@mah.priv.at] > Sent: Thursday, April 25, 2013 10:47 PM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] LinuxCNC would be very nice on the UDOO board. > > Ken, > > Am 25.04.2013 um 01:11 schrieb Kenneth Lerman <kenneth.ler...@se-ltd.com>: > > I'm only addressing this question here: > >> -- How can we distribute HAL (and should we) among multiple components? > > Just noting that the work on RTAPI/HAL has brought with it two capabilities > which relate to the theme; most of this has been discussed and done off-list, > but since the them comes up I respond to it even if it isnt completely done > yet: > > first, RTAPI is now multi-instance capable (several RTAPI instances on _one_ > machine); instances being identified by an integer id (NB this doesnt make > NML multi-instance but I hope NML will be history this year in this branch so > I dont bother anymore) > > this suggested to enable cross-linking of pins between instances, and that is > something very close to working; as an example, it will work like so: > > Assume there is HAL instance #1 (eg started with 'INSTANCE=1 linuxcnc > config.ini') > Also assume it has signal foo of type bit, so say 'newsig foo bit' executed > in #1 > > in another HAL instance (say #3) you can do this (halcmd script): > > attach other 1 # make instance #1 accessible under prefix 'other' > loadrt or2 > net other:foo or2.0.in0 # cross-link signal foo/instance #1 to pin > or2.0.in0/instance #3 > > this will enable instance coordination at the HAL pin level - providing the > instances are on the same CPU (shared memory assumption here). Linking will > be possible for pins linked to remote signals, and named ring buffers > (=queues) between instances. > > --- > > second, there will be a new variation of HAL components, called remote > components, which address the remote (=non-shared-memory case). This is based > on a long discussion I had with JMK and others off-list under the working > title 'HAL pipe' to enable linking separate HAL instances over a network > link; obvious use cases include multi-spindle setups and remote UI's: > > A 'remote component' is basically a proxy for another component in a > different HAL instance; meaning it has a name, pins with a type etc. It also > has additional state - it can be 'bound' (network link up) or unbound (no > network link). You can actually define a remote component in halcmd like so > (this is from an actual example): > > # declare a new remote component > > newcomp gladevcp > newpin gladevcp gladevcp.hal_button1 bit in > newpin gladevcp gladevcp.hal_label1 float out > ready gladevcp > > # at this stage, the component and its pins exist > # and can be linked to > > net toggle gladevcp.hal_button1 > net range gladevcp.hal_label1 > > # wait until remote is connected, for instance 'reown gladevcp' > # is run from a separate window > waitbound gladevcp > > What is not shown here is: a proxy process needs to be started; it will > attach to this predefined component, investigate pin names and types, connect > to its remote peer, and start exchanging update messages. it will also change > the comp state to 'bound' once connection is sucessfully established and pins > are linked remotely with proper type checking. > > --- > > as I said, this is in an early state so please be patient a bit, but comments > welcome anyway. > > With respect to the original question, I think that both concepts could be > helpful; one way the first concept (cross-linking of HAL pins and queues) > could come in is to enable complete HAL/RTAPI subsystems which are glued > together on the pin+queue level. An example could be say a Soc/FPGA > combination like the one Altera is coming out with; assuming the ARM core(s) > on-chip are taught to speak HAL to the outside world, such a subsystem can > then be integrated at the cross-linking level. It could very well have its > own threads, modules etc. > >> >> We KNOW we will lose the parallel port. We know that PCs will become > > semi-OT: I am absolutely baffled by the inertia in this community dealing > with such issues - the vanishing parport being just one of the more glaring > ones. > > Nothing happening on this front, you'd be able to run LinuxCNC on hardware > salvaged from dustbins and yardsales some time down the road, while hoping > the RT operating system - an academic one-man show with no community worth > speaking of and no tangent to become mainline ever - didnt keel over > meanwhile instigated by change of research interests or funding cuts. > > I simply dont get it - sorry guys, this is reckless driving at the software > architecture level. Nevermind how 'ready' the product seems to be. > > - Michael > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
