Hmmm...
In general, the conversion process involves...
Solicit information in a "conversational manner"
Using that information, construct a command according to a particular format into pseudo-code.
When the coding is done, convert the pseudo-code into G-Code.
Now, it might be the case that there is "header data" associated with each executable file. You need to know if that is so and what those contents need to be.
Without a doubt, the first thing you need is a paper listing of the G-Codes used by your machine.
Each "complete code item" must include the Command and all of the required Parameters.
For example: GO TO: A, B, C, D, E,...
Where perhaps...
A = X-Dim
B = Y-Dim
C = Z-Dim
D = Cutter Rotational Speed
E = Cutter Translational Speed
...?
First, envision the process after the converter has been completed.
Somehow, the operator indicates to the program, "Let's build a sequence".
The screen comes back and says, "Fine, let's build a sequence."
Whoever builds the "sequence developer" has to have a sense of the sequence required to build a sequence. For example...
HEADER DATA?
DEFINE INITIAL FACTORS
Home Location
Limits
...?
DEFINE SEQUENCE
DEFINE FINISH ROUTINE?
It's not absolutely required but, there's a lot of benefit to be had by defining the Limits.
You "could" simply define the sequence. You could then bring the cutter-head to a particular location and say "GO". As long as all of your code is absolutely correct, then this will probably deliver the goods.
One way or another, you must have the complete sequence in mind, or better yet, on paper - in detail!
Soliciting Data in a "conversational manner":
Build a split-screen. One half shows the instructions as they have been developed and in the order that they were developed. The other half is used to develop instructions.
The "Code so far" portion of the screen shows each constructed command and its associated parameters.
Each Command and set of Parameters makes up a single line.
The "Code development" side of the screen provides a selection of functions:
New Command..... Build a new command code for addition to the "Code so far" list.
Save Command..... Add the newly completed command to the end of the list or the edited command
Edit Command..... Scroll through "Code so far", select command and edit
Delete Command
Insert Command
Cancel Command
Open Sequence
Save Sequence
When you select New Command, either a menu of all commands is displayed or a menu of menus is displayed.
In either case, you eventually get to the point where you select the particular command that you want to construct. Once a new command is selected, the screen displays the command and a list of the required parameters. The operator then enters the appropriate data, using the appropriate units, for each parameter.
Once the parameters are all entered then the operator selects Save Command.
Now, before the program appends the new command to the list of "Code so far", it would be a good thing for the program to look for obvious violations of limits.
Of course, the sequence doesn't know what it is trying to make and, in general, can not tell you that a particular parameter entry is wrong. However, there can be a defined set of limits that the sequence must operate within.
For example, it simply would not do to tell the cutting-head to move 2 feet beyond its physical limit. If the physical limits of the procedure are defined at an early stage of the command development process then the program can at least indicate when you are trying to exceed the physical limits.
You might also be able to determine and indicate some areas of the work-piece that are absolutely out-of-bounds to the sequence. If any command violates one of those areas then the program might indicate that the move violates a boundary. It should then indicate how and why.
If the program does not find any obvious violations then the new command is added to the end of the list of commands on the "Code so far" part of the screen.
TANGENT:
When you think about it, machining a part is an interesting concept. It's not so much "building something" as much as it is "unbuilding something".
It's like the sculptor that is carving an elephant from a huge block of rock. How does he do it? He carves away everything that DOES NOT look like an elephant!
Machining is the same thing. Starting with a block of metal, the machining process takes away everything that DOES NOT look like a widget!
What something "IS" can be equally defined by what it "IS NOT". This works best within a limited set of extremes.
END TANGENT:
The "Code so far" display should show the command and parameters in a way that is clearly obvious.
The "name" of the command should be indicated using, at least, an easily recognized acronym, if not the full name. The parameters should be separated by any convienient delimiter. Use whatever arrangement that will display the entire command and parameters on one line.
The list of "Code so far" should look the same as the code you have written on paper.
The Edit Command function should allow you to scroll up and down through the list of "Code so far". Once you have highlighted the code you want to edit, press Enter and that command with its previously saved parameters is displayed. Then TAB through the fields making changes as necessary. When the edit is done, then select Save Command.
Once you have completed the sequence, Save Sequence.
If this particular sequence is an edited version of an existing sequence then you should have the option to overwrite the previous version or "Save As..."
Then you need to have a way to compile the particular sequence into the code recognized by the machine.
You have to build a "parser" that will read the commands as you have saved them and then convert each command with parameters into the specific format that the machine will recognize.
The paper listing of the G-Code Commands must give an indication of the precise format of the Command and the Parameter Structure as used by the machine. It would be great if you had a copy of an old source program just so you could see exactly what the machine expects. You will also need to know what is being used as the "delimiter" between the various parameters. Typical delimiters between parameters include "comma", "semi-colon", "slash", a "space", or possibly some combination. Typical delimiters between command-lines include "Carriage Return", " Carriage Return - Line Feed", "Form Feed", "End-of-Line", or...?
Command: A,B,C,... (delimiter is "comma")
Command: A, B, C,... (delimiter is "comma" and "space")
Command: A;B;C;... (delimiter is "semi-colon")
Command: A/B/C... (delimiter is "slash")
Command: A B C... (delimiter is "space")
You then have to go through the effort of parsing your commands and constructing the final G-Code.
Easy stuff? Well... maybe.
The converter should be a small general-purpose parser. As long as the "conversational version" is developed in a consistent manner then the conversion process should be pretty simple and straight forward.
Conversational Version: Move To: X = 2.345, Y = 6.332, Z = 0.000
G-Code Version: GO_TO: 2.345 6.332 0.000
Your "parser" would read the line, grabbing and holding characters on a character-by-character basis while looking for the "colon". The parser builds a string. Once the colon is found, the "parser" would use the string thus far and go through a list of your command names looking for the corresponding G-Code name. Your list might include Move To = GO_TO. Once found, the G-Code name, GO_TO, is written to a "scratch area".
So far... GO_TO:
Next, the "parser" continues reading your code line looking for an equal sign followed by a space. When that is found, the "parser" then continues reading your line, grabbing and holding the characters, again, character-by-character, until the "parser" sees a "comma" or "end-of-line". The "parser" "pre-pends" a space onto the front of those characters and drops the comma from the end. Those characters are added to the "So far..." string.
So far... GO_TO: 2.345
The "parser" repeats the last step...
So far... GO_TO: 2.345 6.332
So far... GO_TO: 2.345 6.332 0.000
In the last case, the "parser" ran into an "end-of-line" character instead of a "comma". As such, the "parser" knows that was the last parameter. The "parser" then copies the completed data to the next line in the G-Code file. The "parser" then goes for the next line of code.
The finalized version of the line of code then looks exactly like it would if you used the original G-Code data entry scheme.
In general, "parsers" are pretty easy to develop. The hard part is determining unambiguous formatting for the source, and that formatting needs to be rigidly formalized.
There are only a few billion different ways of doing this.
This "plan" is far short of everything that you need to take into account. However, it might give you a place to start from. Creating your own interface program can be a real kick in the a$$. The neat part is that you can have this do exactly what you want... with no artificial limitations.
(155)