This is fantastic, Michael! I am eager to work with this new scheme this summer. 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
