Ynneb is Benny from now on, and just for your interest zealous, we had a discussion in another thread about Flash hooking into Mach. well it appears we will be able to do this real soon. Here is what Art wrote on the yahoo forum. I recon between you me and a few others we will be able to do some amazing stuff.
Hi Guys:
Ive read it all. Havent quite digested it all , but it will all settle in
in a few days. When traveling, I consider my options. (I dont travel much
anymore. Here's what Ive decided..)
MachIV will no longer be made as a separate program. I needed the
bifurcation while developing, but I dont think I need it any longer. It
occured to me how to fix all this and Ive been puzzlingover it for a long
time. It always been a question of protocol. How best to add more optional
devices has always been the problem.
Since the MachIV code seems to be working fairly well, though still buggy
and incomplete.. I think its time to spin it off to a DLL. Since I intend to
do this, the DLL I spin off will become a framwork for developers to "do
their own device".
The DLL code will be structured to allow it to tell Mach3 as it starts up,
what device characteristics it has. I will continue to keep the printer port
internal to Mach, but other devices will be selected from a menu of device
dll's found. I will add .h files for all Mach3 internals to the DLL and hook
all output and internal fucntions of Mach3 though that DLL.
The DLL will be able to (within constraints) setup various timing
relationships within Mach. It will be a passed pointers to the movement
blocks Mach needs done. This information will be in the form of a buffer of
structures which will give expected movement positions, velocity and
acceleration from point to point. These moves , since there is no standard
for this, will be in the form of an expected move in a set number of ms with
acceleration information and positional information on a per move basis. The
source for these will be available as a Mach3SDK and wil allow any language
capable of DLL creation to take over output completely. The first DLL, will
be mine and will control the G100. Simply adding another DLL will than allow
a user to select that DLL as an output option, and the developer will then
be able to intercept Mach3's internal calls to deal effectively with the
output. While I will include a "Blank DLL" that will basically pass control
back to Mach3, I will probably publish the G100 DLL as a freely modifiable
opensource project for those who wish to use it as a tutorial or modify it
for special purposes to do so. Power can quikly be added then for developers
to do as much as they wish.
This means if you design motor drivers, USB devices, or simply wish to
leave Mach3 to drive a printer port, you will still be able to do things
such as grab a video window buffer to do things with video, or just drive
motors as a function of your mathmatics. The DLL will be able to do as much
or as little as it wants. It will be a standard "open source" developers
hook. It will hav eaccess to Serial Control buffers, movement routines, and
the complete Ring0 driver parameters, IT will be able to take control down
to a single printer port pulse if desired. This is not alot of work, it is
bascially just opening up the entire class base of all functional blocks to
developers and programmers. It shoudlnt matter if you use C#, VB, or C++, or
what compiler you use, as long as you use the properheaders, (I thnk) all
fucntions will open up. As a DLL, the system shoudl allow total integration
to Mach3's internal fcunationallity. It will be possibel , for example, if
you return False to a config call like
bool OpenScreen()
and Mach3 will not open a screen. This woudl allow the DLL to run Mach3 in
the background and be controlled from a separate applciation, Mach will
check with the DLL before even starting up its drivers. The "Blank" dll will
simply give permision to MAch to open normally by returning "true" to that
call...
Since I need to redo the G100 code for the upcoming firmware, this seems
to me the way to go. It allows an unprecendented level of control, and
literally gives any programmer a fully operative front end for creation of
many program types. It doesn't create a huge delay for me in development,
and the end result is probably a much more robust way of developing. It also
allows anyone of the "Open Source" mindset , to modify or add devices or
code at will. The only bone of contention I can see is a possible argument
as to the movement buffer that will be passed. Certain systemic constraints
exist for that, but Ill see what can be arranged. Theres alot of information
that can be used by programmers. I have no problem giving the hooks to
pretty much all the hundreds of system calls Mach3 uses.
Comments welcome on the approach.. This will happen pretty quickly, the
blank shoudl be trivial, then the G100 version of the blank will apear as I
clean up the G100 interface and allow a "Device selection" capability in the
ports & Pins config..
This means that MachIV will no longer be necesary, you'll just select a
G100 as the output device.
Thanks,
Art
www.artofcnc.ca
