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. 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
