![[Home]](/chips.gif)
History of RemappingStatus|
merge could be considered, barring outside review. Note I'm not saying |
|
merge could be considered, barring outside review (done-merged into master; dust still settling). Note I'm not saying |
|
ontop of master. Many of those are cleanups; a few times backing out a |
|
on top of master. Many of those are cleanups; a few times backing out a |
|
Configurations to explore would be under configs/sim/remap . A simulator build is good enough to exercise them. |
|
Configurations to explore would be under configs/sim/remap . Those aren't listed in the configuration selector - cd to the directory of the demo and run 'emc <the ini file>'. |
|
Since this branch (currently at http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/remapping-preview-1) contains several areas of work, here's a rundown and their status. It's also meant as an aide to reviewers (hint, hint, handwave!): |
|
A simulator build is good enough to exercise them. |
|
Update: it's now http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/remapping-preview-2 - rebased on master (wont fast-forward) |
|
If you are building yourself by pulling from git.linuxcnc.org, you need to 'sudo apt-get install libboost-python-dev' . |
|
This is what the example configs do: * getting-started: introduces defining new codes in NGC procedures and Python * extend-builtins: demonstrates remapping builtins T,M6,M61,S,F. This could be a starting point for your own configuration. Also shows how to refer to the builtin behaviour of codes. * manual-toolchange-with-tool-length-switch: extend M6 so it does a tool length probe after the change. * rack-toolchange: this tries to mimic the racktoolchanger patch - without a patch, but with remapping codes * iocontrol-removed: a 'research part' of the remapping branch: It demonstrates removing iocontrol altogether, and replacing it by a Python plugin in task. Other than that, the rack-toolchanger example is used. Also, experimentally use sqlite3 for tooltable storage. Not suggested for production use. Since this work contains several areas of changes, here's a rundown and their status. It's also meant as an aide to reviewers (hint, hint, handwave!): |
|
Remapping basically means 'you can define the behaviour of a code by means of an NGC oword procedure'. |
|
Remapping basically means 'you can define the behaviour of a code by means of an NGC Oword procedure'. |
|
Please note that the current support for user-defined toolchange in master (M6_COMMAND, T_COMMAND in the ini file) is badly broken and must be replaced anyway. It does not deal with queuebusters properly, which I didnt sufficiently understand at the time. |
|
Please note that the current support for user-defined toolchange in master (M6_COMMAND, T_COMMAND in the ini file) is badly broken and must be replaced anyway. It does not deal with queuebusters properly, which I didn't sufficiently understand at the time. |
|
there are several Python *extension* modules (Pyhton is the main |
|
there are several Python *extension* modules (Python is the main |
|
Powers' ;-) but it isnt for the faint of heart. Towards that end I'm looking into some 'standard Python glue' and establish standard |
|
Powers' ;-) but it isn't for the faint of heart. Towards that end I'm looking into some 'standard Python glue' and establishing standard |
|
easier to use. I think in most cases folks wouldnt need to touch upon Python glue code even if its used. |
|
easier to use. I think in most cases folks wouldn't need to touch upon Python glue code even if it's used. |
|
Embdedded Python brings in a new build dependency, |
|
Embedded Python brings in a new build dependency, |
|
The homebrew data structures, in particular named params, oword label |
|
The homebrew data structures, in particular named params, Oword label |
|
std::map is a bit of an overkill because sorted access isnt needed. But that requires compiling with the --c0xx flag and that I |
|
std::map is a bit of an overkill because sorted access isn't needed. But that requires compiling with the --c0xx flag, and that I |
|
probably will be deleted. This is superseded by the '(abort, msg)' |
|
probably will be deleted (done). This is superseded by the '(abort, msg)' |
|
(interp_namedparams.cc). I need to check wether they are all documented. |
|
(interp_namedparams.cc). I need to check whether they are all documented (done). |
|
INI file variables can now be referenced by the interpreter directly, without going through some pathetic HAL cludge (like setting a pin |
|
INI file variables can now be referenced read-only by the interpreter directly, without going through some pathetic HAL kludge (like setting a pin |
|
Some of the features I wasnt sure about, some are potentially |
|
Some of the features I wasn't sure about, some are potentially |
rs274 -i <inifile> optionThe standalone interpreter, aka 'sai' (src/emc/sai), which is used mostly for regression tests, now sports a '-i <inifile>' option. That was was essential for remap regression tests, and reduces the excuse potential for not writing regression tests 'because those can't be tested with rs274'. |
|
That changed by introduction of context-free features, like oword |
|
That changed by introduction of context-free features, like Oword |
|
recognizer. Suddenly, you couldnt read()/execute() by just by looking |
|
recognizer. Suddenly, you couldn't read()/execute() by just by looking |
|
inadaequate at that point. However, either that issue wasnt recognized, or ignored - the consequence was a set of kludges around |
|
inadequate at that point. However, either that issue wasn't recognized, or ignored - the consequence was a set of kludges around |
|
bugtracker and search for oword and MDI bugs - most of those bugs |
|
bugtracker and search for Oword and MDI bugs - most of those bugs |
|
- it is upside down. Instead of reading a block, and trying out to figure what to do next and what the interpreter's state could be at |
|
- it is upside down. Instead of reading a block, and trying to figure out what to do next and what the interpreter's state could be at |
|
'execute it on its own' until done, or some action on the using code |
|
'execute it on its own' until done, or some action on using the code |
|
should signal that by setting a conditon variable like in pthreads, describe its state and wait. This would in effect completely |
|
should signal that by setting a condition variable like in pthreads, describe its state, and wait. This would in effect completely |
|
control structures and queuebusters in the interpreter, with it reducing potential for bugs. |
|
control structures and queuebusters in the interpreter, and with it reduce the potential for bugs. |
|
for handling MDI commands. |
|
for handling MDI commands, or executing a remapped code for that matter. |
|
for hard realtime, but it is severly limited by two issues: |
|
for hard realtime, but it is severely limited by two issues: |
|
* communication between several UI's and task, for instance gladevcp, Axis and milltask. |
|
* communication between several UI's and task, for instance gladevcp, Axis, and milltask. |
|
* classifiying interpreter state into: |
|
* classifying interpreter state into: |
|
** shared config/UI parameter information ** shared interpreter state (modal state) ** per-instance unshared execution state (oword, call stack etc) |
|
** potentially shared config/UI parameter information ** potentially shared interpreter state (modal state) ** per-instance unshared execution state (Oword, call stack etc) |
|
* introduce a 'extensible distributed shared memory mechanism with late binding' to enable sharing of the stuff which isnt currently shared, but should be, and which is not hard-realtime (eg tooltable + extensions, UI parameterization etc). |
|
* introduce a 'extensible distributed shared memory mechanism with late binding' to enable sharing of the stuff which isn't currently shared, but should be, and which is not hard-realtime (e.g., tooltable + extensions, UI parameterization, etc.) |
|
The second to last item sounds complex, but isnt IMV. There is a good candidate, |
|
The second to last item sounds complex, but isn't, in my view. There is a good candidate, |
|
doesnt necessarily mean a lot of code changes to the interpreter; a |
|
doesn't necessarily mean a lot of code changes to the interpreter; a |
|
long way. And it's really fast and low overhead. |
|
long way. And it's really fast and low overhead. Here's a 5-slide introduction: http://www.slideshare.net/jasoncbooth/exploring-redis - a more thorough intro (61 slides) is here http://www.slideshare.net/phpguru/redis-101-10043219 . |
|
;logging: this is a mess, and dysfunctional (eg a separate interpreter log not intertwined with task logging is next to useless). a unified logging approach is overdue. I guess selecting a logging framework is the next step. I'd see Apache's log4cxx as a candidate. Probably a similar decision should be made for Python code. |
|
;logging: this is a mess, and dysfunctional (e.g., a separate interpreter log not intertwined with task logging is next to useless). A unified logging approach is overdue. I guess selecting a logging framework is the next step. I'd see Apache's log4cxx as a candidate. Probably a similar decision should be made for Python code. |
|
;Axis-NG: Axis is a great piece of work. That said, it is extensible probably only by jepler, which is why people come up with desparate extension workarounds like pyvcp or gladevcp. Second, the Tkinter/Tcl? usage was appropriate at the time, but that base is deprecating. It would be great to come up with a direction statement which addresses those two issues: a extension/plugin mechanism, and the Gui software vehicle. IMO for the latter GTK and Qt are candidates; wxWidgets i'd prefer to avoid. If if nobody starts working on this tomorrow, it would be good to have a direction, even if only to read up on the prerequisites. |
|
;Axis-NG: Axis is a great piece of work. That said, it is extensible probably only by jepler, which is why people come up with desperate extension workarounds like pyvcp or gladevcp. Second, the Tkinter/Tcl? usage was appropriate at the time, but that base is deprecating. It would be great to come up with a direction statement which addresses those two issues: a extension/plugin mechanism, and the Gui software vehicle. IMO for the latter GTK and Qt are candidates; wxWidgets I'd prefer to avoid. If nobody starts working on this tomorrow, it would be good to have a direction, even if only to read up on the prerequisites. |
|
I entertaining opinions (especially by the EMC2 Board of Directors), in particular on the work items. |
|
I am entertaining opinions (especially by the EMC2 Board of Directors), in particular on the work items. |