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 Am 15.08.2012 um 21:15 schrieb SourceForge.net: > Feature Requests item #3558022, was opened at 2012-08-15 12:15 > Message generated for change (Tracker Item Submitted) made by drogge > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=356744&aid=3558022&group_id=6744 > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: None > Group: None > Status: Open > Resolution: None > Priority: 5 > Private: No > Submitted By: Daniel Rogge (drogge) > Assigned to: Nobody/Anonymous (nobody) > Summary: Python gui-land access to set and get emc.var parameters > > Initial Comment: > The attached patch adds methods to emcmodule that allow getting and setting > parameters (#5000 and up) from python. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=356744&aid=3558022&group_id=6744 > > ------------------------------------------------------------------------------ > 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
