Michael,
I have something similar to this working right now. I wanted to seperate
the UI from hal realtime, so i wrote a pin driver in python titled
"Pypins". It uses the Zeromq framework. If you are familiar with python,
You register a pin in a class similar to a property i.e:
class Foo(object):
pin1 = Pin(addr=0x13) # can be up to a 64bit address
def on_pin1(self, value):
'''This is a callback when the value changes'''
or
@Pin(addr=0x13)
def pin_changed(self, value):
'''This wraps a method to use as a callback on value change'''
I choose to use this method so that it is not tied to any specific GUI
library.
The driver creates a socket with the address followed by .0 for output .1
for input. The .0 is the published pin state that can be subscribed to by
several applications at once. The .1 is an input socket to change the
value of the pin, this uses the request/reply message pattern to verify the
packet integrity and returns a status code upon completion.. I wrote my
own packeting protocol in C for communicating with a library i wrote called
Pins in C++. I currently use this on a cnc hob sharpener. Using a NXP1768
Arm processor that is not able to run linuxcnc. I would be happy to help
in writing UI's or implementing a Driver. I could rewrite the pypins
driver in C without a problem if python isn't the language you wanted to
use.
Gabe
On Nov 5, 2013 10:22 AM, "Michael Haberler" <[email protected]> wrote:
>
> Am 05.11.2013 um 16:27 schrieb andy pugh <[email protected]>:
>
> > On 5 November 2013 09:34, Michael Haberler <[email protected]> wrote:
> >
> >> I have created a document describing the HAL remote component protocol
> design, overview, and specification based on zeroMQ sockets and protobuf
> messages.
> >
> > This sounds interesting, though seems like a lot of work for what may
> > be a rather rare usage case.
>
> maybe I wasnt sufficiently clear in the first paragraph: this is about
> separating UI from realtime.
>
> For me your suggestion about 'rare usage case' doesnt hold water. I agree
> this is by definition a zero usage case today, but simply because it is
> impossible (disregarding remote X, vnc and related techniques, which are
> terminal technologies and do not remove the fundamental problems).
>
> Rather to the contrary, I believe decoupling realtime from the rest of
> LinuxCNC - and while at it, define necessary API's like this one - will
> open a whole new range of use cases, and give more freedom in the selection
> of components.
>
> But then nobody is forced to use this, and if one is happy with
> everything-on-a-single-motherboard-of-a-given-vintage then continue to use
> that. Just make sure you have enough of them ;) I say this because I
> visited the second company today I found stockpiling certain motherboards
> 'known to work' with LinuxCNC, just in case they vanish from the shelves.
>
> This is where we stand with the current architecture, and it doesnt look
> very posh, at least to me.
>
>
> > I mention this as it recently became obvious that nobody has ever, in
> > the history of the world, run a VW-plane canned cycle in LinuxCNC. Is
> > there a danger here of adding a feature that never gets used?
>
> dont worry, those users are ante portas. I dont opine here, I know that
> for sure - from talking to quite a few of them.
>
> > (Probably not in this case, as we have seen enquiries about how to do
> > this).
> >
> > One issue is that the NIST design is very specific that only one thing
> > can ever change another thing, ("NIST logic") and you are proposing to
> > change that. I am not sure that is a bad thing (and could be a very
> > useful thing) but I would like to understand the logic behind the NIST
> > policy.
>
> Nobody _forces_ you to associate two buttons with an output pin just
> because the protocol supports this, and it would not have made sense to
> design things differently in view of this consideration. But I would think
> in process control several monitors of a single process is a standard use
> case. Again, this is not possible today but will become possible.
>
> How does your reference to "NIST Logic" add up with the fact that we can
> run several NML-based UI's in parallel today? and how would that be
> different to this proposal?
>
> could it be that this is just some major misunderstanding what this is
> about?
>
> -m
>
> > Curiously, I can't find any definition of "NIST logic" so might have
> > completely the wrong end of the stick.
> >
> > --
> > atp
> > If you can't fix it, you don't own it.
> > http://www.ifixit.com/Manifesto
> >
> >
> ------------------------------------------------------------------------------
> > November Webinars for C, C++, Fortran Developers
> > Accelerate application performance with scalable programming models.
> Explore
> > techniques for threading, error checking, porting, and tuning. Get the
> most
> > from the latest Intel processors and coprocessors. See abstracts and
> register
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Emc-developers mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Emc-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
