> > EMC2 can output to parallel, or serial, or USB or whatever.
> No, EMC2 can produce software-generated step pulses on the parallel
> port, or use a variety of step pulse accelerators
> and/or servo interfaces in PCI slots or on the parallel port. I don't
> know of any serial interface or USB for motion control,
> that works with EMC2.
> Perhaps then you are unfamiliar with the EMC2 system where you write a
> script to represent a code ( in my case a number of M-codes ), and put
> it in the right folder. When EMC2 comes across the code in a run, it
> executes the script to get the action taken. My my case, these
> script/s forward ( pr perhahs pass-through is a better word ) the (M)
> code out to the (virtual) serial port via USB. Then the device at the
> end of the serial/USB ( which was my arduino ) , would then us it's
> own G/M code interpreter to execute the desired action from firmware.
> With a simple (and identical) pass-through script for every code to
> just pass-through the code to serial /USB, then it no longer needed
> the parallel port at all, and you've just upgraded your EMC2 to
> support USB. :-)
OK, the confusion here is that I thought the "output to .... whatever"
meant MOTION control commands.
I think what I said DOES apply in that case. If you want to do
AUXILLIARY operations, such as start
non-axis motors, valves, lasers, extruders, etc. then you can do nearly
anything, and it is performed at
the user level, not the real-time level, so you don't need a special
real time module to handle it.
BUT, that also means that it is not precisely sync'ed to the real time
motion system, and will usually
cause a hitch in the motion to attempt to sync the two.
There is a special case where certain I/O commands can be done through
the RT side of EMC which DON'T
cause the hitch. It all has to be RT for it to be tightly synched.
Anything that you can do through a HAL
pin can be done this way, but that limits you to what HAL already has
I can guarantee that the motion will either pause during your custom
M-code or that it will not occur at the
exact time it is written in the G-code, ie. exactly between two moves,
since it is not handled by the RT
side of EMC. That may be totally insignificant to you. Some people
have had major fits over it, as they
needed to turn a laser on/off or modulate laser power where the axes are
moving very fast. Any time
error in the aux command puts the start and end of the cut in the wrong