Alex Joni wrote:
> Possible, maybe.
> Easy, certainly not.
>
> You would probably need to split emc2 (and all the dataflows) in half.
> Probably somewhere in the emctask/emccanon level.
>
> Basicly you have task which calls the interpreter to read the g-code and
> convert to canonical commands.
> Those get sent to the emc2 motion controller now, and should be converted to
> your format and sent to your usb device.
> The general idea is not that complicated, but as usual the problem lies in
> the details.
> How often do you want to communicate with the USB hardware?
> Do you plan to support feedrate override? If you do, how should the user
> interface send that to the USB device? And what happens to the current,
> active, motions?
> How often do you read feedback from the USB device?
>
> These are all questions that should be answered by a proper
> protocol/function design. Attempting to code something before you have a
> valid design, will more than definately fail.
>
Thanks very much for the clarification. Now the issues involved are
clear to me.
In truth, I thought it was possible to work around this problem by
manipulating the output of a hal-dirver ("open loop driver") to a user
application which then sends the data to the external dirver. With the
only sconvegnete a jitter in the display.
I realized that this was a simplistic vision.
Gianluca
------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
