Hi Gabe,
Am 05.11.2013 um 22:49 schrieb Gabriel Willen <[email protected]>:
> 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.
good to see you arrived at a very similar solution!
what I have is really just a different form of your results halserver-side; the
missing part is UI integration.
my tasks at hand to get this towards usability so somebody else can replicate
are:
- factor out a branch based which has the HAL API extensions, protobuf support
noise etc (code done, factoring out to be done)
- update the halserver and Python example actor to the current spec (mostly
done)
once this is done (somewhen next week I hope) one could hook this into a
HAL-based UI
I looked into what is needed to make gladevcp run remotely and it looks like
only the lowest level (lib/python/hal_glib.py) is affected, maybe some toplevel
option in gladevcp to pass in zmq URI's; with a bit of luck the HAL widget code
per se isnt affected at all
what would be needed is to optionally change the hal_init(), pin creation,
hal_ready(), and value setting/value update polling code to hook into the
messaging API, and I'd be happy to co-experiment/share the burden with somebody
else! I though about dragging Pavel back into this but he's very busy with
family and job.
the changes would roughly be this (and that would be identical regard if it's
gtk, tkinter or Qt or what have you):
- on startup, rather than using the hal Python comp to connect directly to HAL,
collect all pin names, types and direction, and pass this list to an HALrcomp
API class instance; this would be the basis for the initial bind operation
- forward a value change callback to the API, passing pin name and new value
- accept callbacks for name/value pair updates coming in from halserver
- disable the value change poll loop - it's all event driven from there on *)
what I call 'API' here would translate into a Python class which does the
zeroMQ/protobuf plumbing and the actor side of the protocol if told by a
command line option; not really complex once the prototype is done, we're
looking at a very low triple digit number of lines of Python
enabling this hook in say hal_glib.py could be done independently with a dummy
API class; and generic, i.e. agnostic of actual widgets used
do you think you could take this on?
let me try to extemporate a dummy API class:
class Pin:
def __init__(self, name, type, direction):
self.name = name
self.type = type
self.direction = direction
...
class HALrcomp:
def __init__(self,status_uri, command_uri):
...
def define_pins(self, pinlist): # list of Pin()
...
def ui_setpin(self, pin): # UI event caused value change
...
# callback will be called with Pin() argument on halserver-originated pin
update
def pinchange(self, callback)
...
I'd fill in the rest of the API class - per-method print statements ok for a
start
the goal of the experiment would be to run gladevcp remotely without changing
the actual UI at all, and any of the widgets per se - permitted visible change:
startup options
sounds doable?
- Michael
--
*) btw the CPU usage of HAL UI's should drop since no more polling is needed,
this only happens in one place and that's halserver; I made some measurements
and the method scales very well - two orders of magnitude to go on my weakest
platform
>
> 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
------------------------------------------------------------------------------
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
