Olivier:
- a better integration of user screens
Soon...
- acceleration curves integrated in the backlash compensation
Nope, won't happen. Backlash is an anomaly in Machining that is too hard
to account for. Fix the backlash is the only true solution. (I'm almost in
Art Volta's corner on this one. I do offer BLC, but don't like it or the
solution..
It needs to be designed in from the start in software. This is too complex
to change unless Mach3 becomes a reality. Mach2 will probably
never support it. ( Probably, I never say never..)
- the complete elimination of the mouse, like on industrial controls.
Nope, won't happen. While you can design a control based on Mach2 that
doesn't use the mouse by writing your own front end. (Not that difficult
since I released the Mach2Mill.exe application source. ) Mouse users
account for over 98% of total users and 98% of prospective users. This would
be very low in priority and I'll leave it to someone who decides to write
the front end necessary. Even then the toolpath would be hard to control. I
know there is some interest in this and I will consider ways to do it, but
low priority at the moment.
- linear and 3D axis mapping
On the list, but not quickly, definitly not by next development version.
Several months away. Many problems associated with this unless designed in
at conception time. This is strictly R&D stuff, of which I have many going
on in the background. You know, you guys only see about 40% of the functions
I actually write, most never get off the R&D board after code tests. I don't
like clunky solutions and tend to delete them after I get too exasperated.
This one I am still toying with.....I think its possible, just not
successful yet...
- enhanced software limits to take in account part holders and
associated stuff, or for example a rotary table sitting on the table.
Perhaps, but again low priority. Mach2 drives machines well, but its hard
to put in babysitter code, problem here is humans, they begin to rely on
features like this and that reliance leads to stupidity and destructive
results....I will , and am, however, looking into settable exclusion zones
where the tool is not allowed to go. They will be simpler than your
picturing though I think.
- a better toolpath draw, updating in all screens, with no offset
problems and a cursor for coodinates picking.
This is a probable or definite future release. I know the display is
sub-optimal and I do intend a major retrofit of this in the near future.
Coordinate picking is also on the list and requested fairly frequently.
- a better stability if there is a macro error, a better error
reporting, and a debuger for vbscript (the one from microsoft is not
working at all in mach2).
Been working on this. The VB debugger is a terribly difficult thing to
manage in a multi-thread OCX driven application. Will take time. I have
generated days or error trying to do this over the past 2 months. This one
has used tremendous amounts of time so far, but I'll get it yet. Windows
fights hard on this one...
- gecko 2002 support, and gecko 2003 support for dual feedback loops
(with rotary + linear encoders).
The G2002 series will not do encoders of any type. Not enough speed to do
so until an encoder hardware is added. This will take awhile until the g2002
is popular enough to justify any release of a g2003 I think. For the G2003
to become a reality, the G2002 must be finished and being used. The
completion of the G2002 code is on the list and fairly high in priority
though.
- documentation of internal variables, and all the macro associated
stuff. (the actual documents are not up to date).
Soon, I simply move to quickly for poor John to keep up. I will release
the source of the Macro interface if its desired so you can see for yourself
whats available...
Thanks,
Art
