Best way to drive EMC2 from external program?

Hi,
I'm tinkering on designing an open-source, Python-based pick-and-place system for automated circuit assembly, and planning to use EMC2 as the motion backend to physically drive the machine. I did a quick experiment using 'emcrsh' and Python's telnetlib to poke MDI commands into a running EMC instance successfully, but this seems a bit crude and I was wondering if there is a better / more recommended way to go about this. The ability to drive the machine interactively in realtime (not canned g-code files) is important, as the pick n place script will potentially use a vision system (good webcam + opencv is showing promise) to identify part pick-up locations and orientation. So my questions are:

1) Is emcrsh the best (or at least a good) way to go? What are the alternatives? (I saw mention of poking 'NML' packets into EMC's shared memory, but this seems even more cumbersome and it sounds like this feature may be deprecated soon.) I like the simplicity of the emcrsh approach, but expert (or enthusiastic amateur!) opinions are welcomed.

2) In my emcrsh/MDI test, sending several (tested up to 4) MDI commands back-to-back, i.e. before the first MDI move had completed, seemed to work OK: the commands were queued and occurred in the order they were sent. Assuming the emcrsh/MDI approach is sane, can this 'queueing' behavior be relied upon, e.g. to perform smooth multi-step motions? Is there a well-defined limit (lines, bytes, etc.) to the MDI moves which may be queued in this way?

Thanks!

Drmn4ea wrote:
> The ability to drive the machine interactively in realtime (not canned g-code files) is important, as
> the pick n place script will potentially use a vision system (good webcam + opencv is showing promise) to identify
> part pick-up locations and orientation.
Have you examined this thread?
Personaly I'll advice you not to stick with opencv for capture/display You'll get more headache with it and have to
deal with lot of hidden issues OpenCV is unbeatable in image processing but IO is not it's strong side...

> 1) Is emcrsh the best (or at least a good) way to go? What are the alternatives? (I saw mention of poking 'NML'
> packets into EMC's shared memory, but this seems even more cumbersome and it sounds like this feature may
> be deprecated soon.) I like the simplicity of the emcrsh approach, but expert (or enthusiastic amateur!) opinions
> are welcomed.
emcrsh a) exists b) tested solution Even if you want to design another one you'll get something very similar to emcrsh
But it also possible to route NML commands over network. Consult documentation for proper config variables.
So you may have simple GUI on one host and rely on NML layer to do all network communications. I'm not confident
what's current state of NML networking but give it a try.

> 2) In my emcrsh/MDI test, sending several (tested up to 4) MDI commands back-to-back, i.e. before the first MDI move
> had completed, seemed to work OK: the commands were queued and occurred in the order they were sent. Assuming
> the emcrsh/MDI approach is sane, can this 'queueing' behavior be relied upon, e.g. to perform smooth multi-step motions?
> Is there a well-defined limit (lines, bytes, etc.) to the MDI moves which may be queued in this way?
It seem that you are using development version of emc2? If yes then there are no limits on submited commands. There is internal
queue which stores all received commands and executes them in order.

Thanks for the info!

>It seem that you are using development version of emc2? If yes then there are no limits on submited commands.

Currently using the released 2.4.4 version installed from the Ubuntu 10.04 livecd. Sounds like this is a new feature?

>There is internal queue which stores all received commands and executes them in order.

Even "SET ESTOP ON"? Is there any mechanism to bypass the queue and stop the machine immediately if needed? (Maybe this is better done through halrmt?)

> Currently using the released 2.4.4 version installed from the Ubuntu 10.04 livecd. Sounds like this is a new feature?
Not feature but bugfix. I suspect it won't go into 2.4 branch

>>There is internal queue which stores all received commands and executes them in order.
> Even "SET ESTOP ON"? Is there any mechanism to bypass the queue and stop the machine
> immediately if needed? (Maybe this is better done through halrmt?)
I mean internal queue of MDI commands besides one for ordinary NML commands