>
> What changes is:
>
> 1. how a HAL component is created - check if comp exists, yell if it does etc.
> 2. how a pin is created - checking if the name exists, tell HAL to create a
> pin of a certain type and direction.
> 3. how the current pin value is is read
> 4. how a pin value is set
> 5. how notification of pin value change is processed.
>
> Now going through the list in turn:
>
> 1,2 and 4 are going to be a HAL messsaging RPC (remote procedure call)
> operation into machinekit.
> 3 could be the same, but see below.
> 5 could be based on 3.
>
> So instead of accessing methods in Python 'hal', it will ask machinekit for
> operations which look like a function call at the using level. See footnote
> how such an RPC could look in Python _in principle_. The lowest level
> machinekit API will look rather similar.
>
> So 'all that is to be done' is replacing one function call by another, and if
> we're lucky it is all contained in hal_glib.py. That code could actually
> autodetect or ask for configuration information if running 'locally' (shared
> memory access) or remote (HAL messaging).
>
> Is that going to work? Yes. Is it going to work fast? Not yet.
>
> The update network traffic of constant polling for changed values will be
> considerable, and given the above, will scale linearly with the number of HAL
> widgets.
>
> This can be fixed with a slight twist in the API - by replacing polling
> through change notifications. Instead of constantly polling for the current
> value just to detect a change, the HAL messaging API will provide a way to
> express 'please notify me if the value of pin X changes'. The machinekit
> server will do that change detection for all clients, and all pins with
> expressed update interest. It will notify the client by a message if a pin
> changes. This message will hook into the GPin update method, and cause a UI
> display update.
>
> In essence the clients declare interest in a certain object, and the server
> will notify of updates. That is exactly what the publish/subscribe
> interaction model is about, regardless whether it'd be HAL pins or stock
> quotes. So we need a messaging layer which supports RPC and publish/subscribe.
>
> This removes the network traffic of constantly polling for changed values; so
> in effect we have network traffic only when setting a pin from the GUI, or
> when a pin we declared interest in changes value.
>
> Note that the change detection code in the machinekit backend is completely
> generic - it need not be aware of any specific machine configuration, just of
> the list of 'interesting pins', and the clients will declare that interest in
> the startup phase. The only client-specific parameters I could conceive are:
> a) an epsilon value for HAL float change detection, b) a change detect timer
> value, but that's conceptually not different from the local case.
>
> ----
>
> coming back up the stack to actually answer the question:
>
> I dont think it is necessary, or desirable, to change the UI programming
> paradigm at all as far as HAL/GladeVCP goes. In fact I think the changes can
> be contained to a single Python file, and they can be made such that the
> using code sees no difference whether shared memory mode or messaging mode is
> used.
>
> I still hope I can drag Pavel into advising us on this, but it seems he's
> currently busy with family enlargement work;)
>
>
Michael
Thanks for explaining it.
So if I understood right, for a relatively small code change (maybe a
relatively large ideology change)
it's an incremental change.
it switches from polling to signals
it allows us to easily separate the UI from the realtime computer. Which is a
huge bonus.
more then likely all the UIs could use the same calls, so setting up UIs is
less of a pain for a user.
we have to fix the licensing problem - this could be considered negative or
positive.
Is ZeroMQ available for windows eg windows UI, linux embeded cnc controller?
Chris M
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
