Am 16.08.2012 um 00:12 schrieb Daniel Rogge: > Michael, > > I appreciate your analysis. I hadn't given much thought to the potential > race condition between the interpreter and the parameters, nor had I really > considered preventing access to parameters that didn't make much sense to > access (e.g. #5399). I worked on this in the hope of using parameters in a > currently unused range (>5600) to store persistent machine settings similar > to the preferences.py implementation used by Chris in Touchy. I had not > considered, for instance, using this to display all the G5x work offsets on > one screen as suggested by Chris on IRC earlier today. The contents of that > patch work for my current need, but if people feel that the code should > prevent access to nonsensical or interpreter-sensitive parameters then I'm > happy to put in the extra effort to make something useful for the community. > >> As for persistent parameters (stored in emc.var) I think the eventual >> solution is to have the persistent parameters in a Redis store and make the >> >interpreter query/set it as needed; this store then can be queried/set by >> other processes as well. single location, no consistency issues. > > I'm all for it.
ok, let me restate the use case: - there shall be a class of persistent parameters which serve interaction with UI's (not necessarily limited to numbered params) - these params shall be accessible by arbitrary processes - setting a parameter updates the interpreter's current view of the param - getting a parameter retrieves the params current view is that it? (btw I think it is useful). is this for master? If so, I have an alternative proposal. I would like to take the opportunity to solve this through redis, with the intent of warming up folks to the actual use of redis instead of me just musing about it. this will involve a new package dependency (redis-server) and the hiredis and redis-py C and Python bindings, and a bit of configure support so we have a conditional dependency on redis etc availability. -- It will also mean that if redis is used, emc.var contents will live in the redis store (a file), a redis shell client is available. I'm happy to work with you on that, but I would hesitate to merge this patch - it's going down the wrong lane (just look at the contortions you needed to do to get a *single* remote procedure call done, and we're not moving any closer to clean distributed state management; not your fault, NML is next to useless for the job). to get an idea how this could pan out, have a look at http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/redis-iocontrol - I created this as a simple example to store the current tool table in redis, and show how UI's could work with it (read only). And to sell jepler on the idea;) The relevant part is the patch to iocontrol-v2. -Michael > > Rogge > > > > -----Original Message----- > From: Michael Haberler [mailto:[email protected]] > Sent: Wednesday, August 15, 2012 4:06 PM > To: EMC developers > Subject: Re: [Emc-developers] [ emc-Feature Requests-3558022 ] Python > gui-land access to set and get emc.var parameters > > Hi Daniel, > > I looked over this patch and having dabbled with Python drving LinuxCNC I > understand where you're coming from. > > reading: that's probably harmless, disregarding the fact that a parameter > read might change locally during an interpreter run, so the reported and > actual value might be inconsistent. > > setting: the semantics of 'setting a parameter of #5000 and up' makes only > sense for certain parameters. > > See > http://www.linuxcnc.org/docs/devel/html/gcode/overview.html#_numbered_parameters_a_id_sub_numbered_parameters_a > > In first reading, it would be those tagged as 'Persistent', but that isnt > concise enough: > > for example: > - 5161-5169 "G28" Home - makes sense > - 5061-5069 Coordinates of a "G38.2" Probe result - makes no sense > - 5399 Result of M66 - Check or wait for input - makes no sense > - 5400 Tool Number. Volatile. what would the semantics of that be? > > IMV this makes sense for parameters a) where the interpreter is the exclusive > driver of the value and b) the parameter drives the interpreter and is not > just an observer of some other internal process, like toolchange (setting > #5400 probably changes its value for now, but doesnt influence any flow of > control, or change interpreter state) > > This is the consequence of the existing state model, which doesnt > differentiate between readonly and read/write parameters, and between driving > and reporting parameters. Maybe a bit mask of changeable parameters in > interp_array.cc is a stopgap measure. > > potential grey area: race conditions during interpreter run and setting > operations: > the way I understand it the NML set param message could be processed anywhere > during an interpreter run, leading to a spontaneous change of a parameter, > and exact G-code line where that happens likely time dependent. A way to deal > with this is to restrict param changes to interpreter idle state. That could > either be in task, checking interp state and reporting an error if > interp_state != idle. > > --- > > I think the parameter code needs to be redone eventually - direct array > access in the interpreter plus canon synch() was great for the research > protoype back then, but is completely inadaequate for a distributed system > with several setters and observers we have now (or rather would like to have > :-/). > > I outlined some ideas here: > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?QueuebustersRevisited. Part of that > work will be to give each parameter a set of attributes, among them the taint > category, and also readonly vs read/write, as well as persistent or not. It > will also encapsulate parameter access into getter/setter methods which > enables better handling of different parameter classes. > > As for persistent parameters (stored in emc.var) I think the eventual > solution is to have the persistent parameters in a Redis store and make the > interpreter query/set it as needed; this store then can be queried/set by > other processes as well. single location, no consistency issues. > > - Michael > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
