Thought I'd share an idea about using gauges with the other screen designers.

The gauge can illuminate diffrent color hues depending on a on/off state,
they can also have a needle that can switch to display on/off.
I am also intrested in using gauges to display speed/feed like a car speedometer as well.

The screen that incorporates this idea will be ready in a few weeks to a month along with two others(I currently have a big project that I must finish within the next few weeks, so I have little time to work on the new screens as of now ).

Very nice zealouse, look forward to the finished screen.
Hood

Cool concept indeed. I wish i had of thought of that.

This concept will really rattle the traditionalists.

BTW, what picture editor do you use?

Ynneb, I use Firework, 3D Max and a little Adobe.

Here is a "Feed Rate" gauge.

I believe this could be usefull if I can get the needle to rotate to a spindle speed or Feed speed. Any idea's, maybe for Artsoft's future projects.

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

Benny,
I'm a little slow, Ynneb is Benny backwards
I'm very much looking forward to these new developments, the new interface will be amazing
Thanks for pushing for these new enhancements.

Zealouse, just a whole hearted "thumbs-up" to those great guages! I can't wait to see a full dashboard of needles rockin' back and forth on my super-modified Mach 3 screen! Rock- On! Glenn

These look very cool......

Cool concept indeed. I wish i had of thought of that.

This concept will really rattle the traditionalists.

Benny, the opinions of some, including myself on occasions   Is not about being traditionalists at all.   What I have noticed is that these opinions virtually always come from those with a lot of CNC experience and a good handle on whats really necessary.

The science of ergonomics comes into play a lot with the design of cnc machine tools.   In fact it's vital that the person operating the machine can see at a glance whats going on.

If the user wishes to treat a cnc machine as a toy thats fine by me, as long as that user doesn't ever whine that they got confused    My needs are different.

I do admire some of  graphical talent shown in here, I'd admire it even more if they took some time to understand the reasons why real world controls are laid out the way they are.

But back onto the subject of meters, these are common place on realworld controls for things like Spindle load and speed etc.   More often they are analogue meters.   But Heidenhain and Mazatrol controls have had moving bar (VU type meters) on screen for years.

Wayne...