Machsupport Forum

Third party software and hardware support forums. => Newfangled Solutions Mach3 Wizards => Topic started by: vmax549 on February 27, 2006, 08:24:29 AM

Post by: vmax549 on February 27, 2006, 08:24:29 AM
Brian you guys need to invent/design/market a

Conversational VB Scriting Wizard.

If you can make Mach do all these nifty things that it does, surely you could whip up another "simple" wizard for us mere mortal need to be but can't programmers??????? (;-) Terry
Post by: ynneb on February 27, 2006, 11:35:51 PM
I hear what you are saying, sort of like a html editor where you see what you are doing without having to get down and dirty with the code. Nice Idea, I wonder how hard it would be though.
Post by: Brian Barker on February 28, 2006, 05:47:06 AM
It makes my head hurt to think about it...
Post by: vmax549 on February 28, 2006, 11:12:29 AM
Brian there used to be a DATABASE language years ago that was conversational in nature. It worked great for non programers. It did not last long through it got bought up by a corporate giant.  You really need to think about this. One of the greastest problem faced by mach uses today is the need to be able to write scripts and macros. There is a incredible amount of talent out here using Mach but most are like me, they come up with an idea, get started to impliment it and BANG run right into that wall again. If you could build a conversational programming interface you will open up a new world of CNC. Users would flock to mach for a low cost retrofit and easy implimentation.  Think about it there are only so many functions really needed.   Let's see Art and Brian relaxing on a sunny beach in Cuba sipping on a cool one!

(:-)= Terry    PS: I want the first copy, and don't forget the DOCUMENTATION.
Post by: Graham Waterworth on February 28, 2006, 04:47:33 PM
Hi Folks,

as a programmer of some 25 years I don't get the logic in this request.

If you don't understand how to string together a list of control commands how can you possibly sequence a conversational system.  You have to understand what you want to do and how to achieve it before a conversational system can be used.  The list of options for each selection would be huge and how could you decide which one you needed if you did'nt undestand the function.

A standard CNC control e.g. Fanuc with conversational input has a limited number of functions for programming the NC code, but has no control of the machine functions e.g. tool changer, limit switches etc. , this is controlled by the PC side of the system, this is custom written for each machine tool by the manufacturer and presented to the user as a ladder diagram that is read only.

Any system that has limitless possibilities is impossible to convert to questions and graphics, hence VB script.

You could possibly learn VB script quicker than a conversational system that can not do all you require.


Post by: ynneb on February 28, 2006, 06:10:43 PM
Graham, you are right, I guess it is just wishful / playful thinking.

Thats probably why Bill gates did so well, when he made windows do pictorially, what used to be done through typing Dos commands. It would be a huge task, and as you say, easier to learn VB script.
Post by: vmax549 on February 28, 2006, 06:39:51 PM
Graham, with you being a programmer you cannot possibly understand the frustration of not having the Programmers Gene as we call it. I can tell you exactly how it should be done and most of the commands used, draw you a ladder diagram, and tell you in squedo term how it suppose to work. But I cannot string together the logical expressions to make the code work/flow, I get lost every time. Bin at it for about 20 years and I am no closer today then 20 years ago of being able to do it. My wife suffers the same missing gene, she works in Civil engineering GIS and has the same problem in complex queries/macros. Her drafting side is a work of Art. Programmer,not!
(:-)= Terry
Post by: vmax549 on February 28, 2006, 06:48:20 PM
Graham for an example of the converstional part take a look at some of the Control/data aquisition software. They use x control moduals you simply place a control relay in place and answer a few questions concerning leads and function and hookup and it will write the integration code and apply it to the screen you are using. That I can do, write the actual code, won't happen.  (:-)= Terry
Post by: Graham Waterworth on March 01, 2006, 05:41:25 AM
Hi Terry,

I here what you are saying, but you have to realize that if you were all using exactly the same hardware with exactly the same setup it would be possible to create a program to create macros as the number of options would be much reduced.

How many different tool changer option would there be?

Is it :-

1. Electric

    1.1 How is tool one indexed
          a. encoder
          1.1.a. Encoder type
                   a. rotary
                       1.1.a.a Logic type
                                  a. incremental
                                  b. absolute
                   b. Etc.   
          b. limit switch
          1.1.b. Is the limit switch
                    a. NO
                    b. NC
          c. manual
          d. Etc....

    1.2 How is the tool count indexed
          a. encoder
          b. limit switch
          c. manual
          d. Etc...
    1.3 How many tools

2. hydraulic
3. pneumatic
4. manual
5. electro/hydraulic
6. electro/pneumatic

This is a very tiny example of the type of thing you would need to build in the background of the program. 

20 lines of questions and still nowhare near a result.

The logic table for this type of program would run in to megabytes.

I am not saying its not possible, just not viable, it would take years to perfect and never be finished.

Post by: vmax549 on March 01, 2006, 10:03:03 AM
Good morning Graham,

The way the other programs see it is that a relay is a relay, a mpg is a mpg, they basically all work the same. Of course you have to tell it the logic ladder, they give you a blank ladder to fill out.

Take a tool changer for example, they" basically" all work the same. The ladder is different from model to model, the components very in number and type.

As an example my son took LABVEIW and built a control panel piece by piece adding in all the components. That panel was to run a very complex machine process. He filled out the ladder logic and answered a few questions on the components and the Labview wrote all the  code for the process panel to work. He dropped in the Guages/ controls  he wanted to see and what the monitor points were and pressto instant control panel.

Now I have a simple mind but it would seem the CNC machines have a fairly simple basic structure in how they work. A relay is faily simple it is either NC or NO, A solenoid is either on or off, A mpg is quad output, two signals, ETC. Mach already does the hard part.

Labveiw has a free demo package, try it sometime. See what you think.

Just a though for the future. (;-) Terry
Post by: vmax549 on March 01, 2006, 10:17:43 AM
Graham just another thought,

Take your tool changer example. With all the variables you stated, in the end as a modual, it has an input point to change the tool/ operate functions and outputs to show position of tools. Mach would not need to know how you make it move to a new tool, just that if it sends a signal to the input in a certain way it will move to a location and how many total locations there are. same with the ouputs, it does not matter how the output is created, just what the signal represents. Mach would only need to know in what order to send signals.  Make any sense????  Terry
Post by: Graham Waterworth on March 01, 2006, 04:10:18 PM
Hi Terry,

I think you are missing what I am saying here,  drawing pictures of components and linking them together is the easy bit.  What is more difficult is programming what you want to do with them.

The question and answer system whether text or pictures would be endless. How could you filter out unwanted options when you don't know what somebody wants to do.

The program would need so much more information than you would require as it dose not have the ability to read your mind.

Yes you can tell it a switch is on or off, but when and for what reason, what happens after the switch closes/opens, do I move a motor and how far, until the switch changes or another switch opens or do I need to loop around and keep moving until A limit is reached.

If you think about it logically you have written the program in your head.  All you have to do is convert the mental program into VB Script.

Please don't take my comments the wrong way, this is an interesting subject and you never know you may convince me to tackle it at a later date.

By the way data aquasition and processing software is what I write. I am just finishing of a DNC system at the moment.

Post by: washcomp on April 28, 2006, 08:58:48 AM
I think one of the points that's confusing the issue is the traditional way of looking at things is from a CAD/CAM software package into a CNC controller.  If the controller is properly set up, the post processor throws the proper G-Code into the CNC controller and everything works out OK.

What we are moving into is a CAM/CNC system.  The middleware of the post processor is what we are discussing (and what is missing because of the various types of controls that people are using).

A possible approach might be to do the definitions of the various gadgets and have the hooks available for each common method of using it on a setup menu.  Once that was established by the tool owner, it would then define the interface from external coding to their specific tool.  Coding could then be protable from machine to machine because the menu driven "post-processor" would do the translation.

Just a thought,