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 > less deterministic when it comes to real-time operation. (Modern office > machines MUST play games with their clock speed to use power efficiently.) > > -- Does our future architecture include a PC? > > Ken > > > On 4/23/2013 11:03 AM, Charles Steinkuehler wrote: >> On 4/22/2013 11:40 AM, Matt Shaver wrote: >>> On Sun, 21 Apr 2013 19:30:23 +0200 >>> Michael Haberler <mai...@mah.priv.at> wrote: >>> >>>> We'll have a ready-to-go SD card image with xenomai, all prerequisite >>>> packages and linuxcnc installed in a week or two; that will include >>>> Charles' PRU stepgen and Sergey's/GP Orcullo's emcweb, and should >>>> reduce the guru requirements to get things going >>> So, I'm ordering a new Beagle Bone Black this morning & I was wondering >>> what you guys are doing for a field I/O interface for this computer. Is >>> there a cape I should get? Or are we at the perfboard and wire-wrap >>> wire stage? :) >> The BeBoPr board is available now and has support for both the Pololu >> drivers common in the 3D printer world and a header to drive out-board >> stepper drivers with a more "oomph". From the BeBoPr maunal: >> >> J5 – all stepper signals are present on this connector. It connects >> directly to the 15 pin sub-D connector of a TB6560-4V5 3A stepper >> driver board sold on e-Bay. >> >> There's also the Replicape, but AFAIK it's on-board stepper driver only >> (Pololu class, but using TI driver chips). >> >> There's nothing I'm aware of yet that works for analog servos, but it >> should be possible, at least for a few channels (the CPU has 3 hardware >> encoder inputs, and the PRU could support more in "software" at lower >> pulse rates). >> > > ------------------------------------------------------------------------------ > 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
