[Home]LineNumbers

LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org

Showing revision 11

Line Number handling in Linuxcnc

One linuxcnc defect which I think is due for repair is the current state of affairs with respect to "line numbers".

The issue is quite complex, touches many corners of linuxcnc and has substantial breakage potential. Repair will not be achieved by a casual evening fix - some planning and design is required.

I'm therefore laying out the issue, and a sketch for a solution, and encourage discussion and rough consensus before actually doing anything about it.

The issue

Line numbers are used to correlate canon/motion commands with a program line number, and features like run-from-line. They are also key in control strcuture handling in the interpreter. Since the current abstraction is a single integer , it cannot cope with multiple files, or file types, which explains some of the issues with RFL. One of the consequences is limitations on tracing the current line in UI's, like the current line in an oword sub in Axis. Or generating a callstack for UI purposes.

There was a need for a different type of line number back in the history of Linuxcnc, for instance for indicating 'MDI mode' (which is basically a limited 'execute a string, not a file' operation). However, a shortcut was taken - instead of creating a abstraction for source location, like a tuple (type, source, offsets), the choice was to indicate 'MDI mode' as negative line numbers.

Another defect of line numbers in 'MDI mode' is that they are not idempotent, that is, reexecution of a statement does *not* yield identical line numbers for the same source location, which make comparison of 'line numbers' in MDI mode a bit meaningless. This for instance broke my attempt at better diagnostics of botched oword label handling, and I had to revert http://git.linuxcnc.org/gitweb?p=emc2.git;a=commit;h=73dcf03ed13064416219f2eff7150bb683e53530 .

This method just didnt break run-from-line in MDI mode because nobody ever tried to implement run-from-line in MDI mode, which is a perfectly reasonable feature wrt oword procedures btw. Do a 'grep pseudoMdiLineNumber? src/emc/task/*cc' to see why non-idempotency is the way it is.

Remapping added another type of source location - Python scripts.

Revisiting the original idea of an integer for source location, it becomes pretty clear: correlation of source location based on ints as in current linuxcnc needs work.

Reparing 'line numbers' : introducing 'source location'

To make a terminologic cut, I will name the replacement for line numbers 'source location' (sloc). This will be a new datatype which will encompass the current line numbers, and able to uniquely denote a 'source context'. A 'source context' will likely be a range of characters of some form (a range of bytes in an MDI string, a line or a word in a NGC file, a line in a Python file). Note that a 'line' may contain one or several source contexts.

Preliminary requirements

sloc's shall have the following features:

Note that support for source location and source context are independent of the language being used, be it rs274ngc, canterp, python, any new pluggable interpreter. A good implementation should be able to handle any current or future language.

Please add/change as you see fit.

line numbers and motion id's

Line numbers are used to tag motion commands processed in motion and the trajectory planner. I found out that a zero value motion id obviously means "the motion queue is empty", so that's a value to be careful about.

Motion id's are used to distinguish separate motions when stepping. It is decided here (line 1955): http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=src/emc/motion/control.c;h=d3590a26e969e11777d487d46d3e8711e86b9ac6;hb=2cea8d434c775a3abcc28ac0f61930135b4e86c8#l1955

Through experimentation I determined: valid motion id's better not be zero, and for stepping between motions to work, they need to be different (they need not be in ascending order).

'source location' versus 'source context'

I am distinguishing 'source location' and 'source context' here. Source locations are an execution semantics concept. Source contexts are a UI thing.

I think any canon+motion command should carry an sloc, but it need not necessarily carry everthing that goes with it, like a filename, or a string. Separating the two concepts implies there needs to be a global lookup mechanism to retrieve a source context given a source location. UI's will definitely derive source contexts from sloc's, RT modules might or might not.

Note that the granularity of source contexts impacts the storage and retrieval mechanism and memory requirements. Storing filenames and MDI strings has limited memory requirements; tracing back to words, or other intra-line objects will require more memory. Shared memory is not necessarily a good place to store source contexts, because this will not work nicely if UI and task are on different machines.

This might or might not be an issue or make sense, I'm posing this to discussion. Maybe we have enough memory today to repeat the filename or underlying string in every canon command.

Open questions:

Related bugs + missing features:

http://sourceforge.net/tracker/index.php?func=detail&aid=3440704&group_id=6744&atid=106744

http://sourceforge.net/tracker/index.php?func=detail&aid=2005148&group_id=6744&atid=106744

Note there are several closed bugs with RFL, but some have less-than-optimal solutions.

http://git.linuxcnc.org/gitweb?p=emc2.git;a=commit;h=73dcf03ed13064416219f2eff7150bb683e53530


LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org
This page is read-only. Follow the BasicSteps to edit pages. | View other revisions | View current revision
Edited March 31, 2012 3:03 pm by MichaelHaberler (diff)
Search:
Published under a Creative Commons License