-
- 1. Things I would like to do
-
-
- 1.1. Implement an interface to machines not requiring realtime capabilities
-
-
- 1.1.1. Todo
-
- 1.1.2. Random notes
-
1.2. Adding true milling visualization capability to [AXIS]-
-
- 1.2.1. What is this?
-
- 1.2.2. Todo
-
1.3. Document/understand the main dataflows and data structures used in EMC2-
-
- 1.3.1. Todo
-
- 1.3.2. Random notes
-
- 1.3.3. Related links
-
1.4. Other stuff...-
2. Personal motivation-
- 3. Contributed stuff
-
- 4. Other links
-
1. Things I would like to do
1.1. Implement an interface to machines not requiring realtime capabilities
1.1.1. Todo
- Where do I add hooks to motion and io modules the easiest way?
- How do I sync time between EMC2 and user-space driver controlling external machine
1.1.2. Random notes
- Named pipes is probably the easiest interface to a user-space driver for now
1.2. Adding true milling visualization capability to [AXIS]
1.2.1. What is this?
[AXIS] is a GUI frontend to EMC2.
Currently
[AXIS] only displays the path as a line. It would be nice to have it show the actual milled object instead. For 3D milling (i.e. with no angular movement of the spindle or object) this is relatively easy for smaller objects with limited accuracy as it can be done by a 2D set of "rods" which are then shortened based on the traversed path (20 um accuracy on a 100 mm x 100 mm x 100 mm object would take up ~50 MB memory which is not a problem on a modern PC; larger object however drastically increases memory consumption). However in 6D (i.e. with angular movement of the spindle/object) this brute-force approach is way to memory consumption.
1.2.2. Todo
- It seems that AXIS is currently polling the EMC2 subsystems for current position (verify that this is correct!); this however means that the visualization accuracy is limited no matter what kind of cool interface AXIS will be extended with. Thus somehow the actual traversed path will need to be accessed by AXIS. How to do?
- A brute-force approach for this task would be to use [GTS] to compute an internal representation of the milled surface by using binary subtraction of the tool wrt. the object. The performance will however need to be assessed.
- Visualization of the surface using openGL will hopefully not be a problem, although some housekeeping will need to performed in order to avoid all details/triangles to be shown at each redraw
1.3. Document/understand the main dataflows and data structures used in EMC2
I only use simulated EMC2 (as I don't need the realtime stuff myself) so the following is only applicable to this; however the main dataflows for non-simulated runs should be similar I guess. EMC2 is compiled in simulated mode by using the command-line argument
--enable-simulator during the configure step as described in
[Installing EMC from source].
1.3.1. Todo
In no particular order:
- How is motion.c simulated (and where)?
- Partial answer from IRC: It's done pretty much like in RT, there is a HAL thread (that runs like a pthread iirc) and there are functions added to that thread, the functions get executed in order so you would have to add your function to that thread, I'd suggest you start reading the HAL docs first
1.3.2. Random notes
- The user-space "trajectory planner" (actually just the output of the canonical functions) stops interpreting when the RT motion.c buffer gets full, xxx link to source
- motion.c takes care of actual trajectory computation, according to IRC chat (21/7-2008, emc-devel), xxx link to source
- emc typically uses two RT threads, servo and base, according to IRC chat (20/7-2008, emc), xxx link to source
- Shared memory I/F (which is one struct, no queue) is only used to transfer low-rate (<< servorate) data to motion.c; motion.c queues the commands in internal buffer (xxx link to source), which is currently 2000 structs long according to emc/motion/emcmotcfg.h:#define DEFAULT_TC_QUEUE_SIZE 2000
- Links from IRC chat from jepler to be tested:
- Other stuff:
from emctaskmain.cc:
emcTaskPlanRead?() (emctask.cc) makes the RS274 interpreter read the next line in the gcode file
emcStatus->task.readLine is updated with line number as well as interp_list
emcTaskPlanCommand?() is called, however this seems to do almost nothing
emcTaskPlanExecute?() (emctask.cc) is then called, which in turn calls Interp.execute() however I have no idea what this does; does not really seems to do much although the description states that machininng functions are actually called...
emc_nml.hh:
EMC_TRAJ_STAT
EmcPose? position
EmcPose? actualPosition
EMC_MOTION_STAT
EMC_TRAJ_STAT traj
EMC_STAT
EMS_TAK_STAT task
EMC_MOTION_STAT motion
EMC_IO_STAT io
emctasmain.cc:
EMC_STAT *emcStatus
struct EmcPose?
PmCartesian? tran
double a, b, c
double u, v, w
struct PmCartesian?
double x, y, z
taskintf.cc
emcmot_status_t emcmotStatus
--enable-simulator:
SIMULATOR=yes
RTS=simulator
BUILD_SYS=sim
1.3.3. Related links
Note that some of these are rather old, but they are still useful. Some of the file locations are not correct though; but using
find on linux is easy...
You may have noticed that I havn't referenced
[Developers manual]; for me it was impossible to use this to get started doing some programming on EMC...
1.4. Other stuff...
- Ellipse implementation could be interesting (although probably not really useful)
- Time-optimal realtime feedrate computations, see e.g.
2. Personal motivation
I currently have a crude interface running for a homebuilt Hexapod. I would like to use EMC2 for controlling it, due to its G-code interpreter and nice GUI. However I have no need for hard realtime control; all servos are controlled by specialized electronics which only needs an EIA-422-B (formerly known as RS-422) interface to a PC. All error checking and safety critical parts are thus completely separated from the PC (which I personally see as a plus given the overly complex nature of modern PCs).
3. Contributed stuff
Currently I have only made a few minor changes to the wiki; hopefully this will change in the future... :-)
4. Other links
[Wiki help]
![[Home]](/chips.gif)