Am 06.02.2013 um 16:22 schrieb Chris Morley: > > > > >> >> 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.
yes, to all of the above > more then likely all the UIs could use the same calls, so setting up UIs is > less of a pain for a user. I hope so. It is unclear to me how TCL-based code would be affected. There is a ZeroMQ TCL binding, no idea what the status is. The ZeroMQ language bindings list is worth a look: http://www.zeromq.org/bindings:_start (see here for the language bindings of a liberally licensed potential future alternative (nanomsg): https://github.com/250bpm/ - that's why I'm a royal PITA on pressing for ZeroMQ as an option for LinuxCNC) > we have to fix the licensing problem - this could be considered negative or > positive. yes - the work: negative, the result: positive > > Is ZeroMQ available for windows eg windows UI, linux embeded cnc controller? Andy's list: Windows, OSX, Linux, plus OS X, Android and probably then some - the latter two I'd see as rather interesting touch GUI candidate platforms. Also the kivy GUI platfrom which was recently mentioned on IRC, but the latter is 'just' a licensing and not a platform problem. Not that I will do any GUI's for those, it'd just be nice to have the option - Michael > > 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 ------------------------------------------------------------------------------ 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
