Voice command structure
This page is about theory on how voice command communications should happen with gcode based 3d printing machines. it is a starting point and i would encourage edits and further input.
Computer processing power available to controllers and plc is at a tremendous curve of advancement. about 2000% of microprocessor power will be available in a years time frame.
there are several issues that need to be improved upon, but one area I found little help with was with voice commands.
voice commands should have structure and be clear, easy to understand, and translate to text. voice commands should also be verified to be accurate, i would like to say the the following method would work appropriately, and if not a verification request should be asked, or the command should be rejected. also i would like to say that the commands can be morphed, or processed as the same meaning for several sets of words, so move, proceed, and goto are similar, and can be all part of the same command, but do not use a combined command and function such as the word 'forward' which implies a direction and a motion, and violates the checking rules. each part of the command should be single meaning, and therefore make sense along with the complete instruction, so no verification response is needed.
the variables I would recommend for the choice command structure as is follows.
Commands that morph, or a single command that has several meanings or words linked to it, such as go, move, process...
A 3 level tier structure. each with a safety rating, to indicate the damage an error would have. a 1 would be nuisance, 2 would be mechanical, and 3 would be costly damage. how to rate these needs to be determined. also be sure that a command is set to a function, and that the function and command not be part of the same word. this allows for verification in sentence structure. if applicable the use of such words should provoke a response by the system for a clarification. so if forward 5mm is used although it makes sense it should still be verified because it had the possibility of being a verbally recognized error with no way to correctly verify it meets the safety criteria for non verification.
type of command system, the thing to change (function of) , and the value to give it. (value)
IF the type of command matches the thing to change, then the command is likely valid especially if the value verbally spoken is within sanity limits of the command.
If the verbal command, does not match the thing to change, reject the command.
3 level TIER system
commands: Tier (1)
--------------------------------------------------------------------------------------------------------
Move(2)
set(1)
change(1)
remember(0)
make(2)
print(1)
Function of TIer (2)
---------------------------------------------------------
temperature nozz(3)
temperature bed(3)
axis(1)
memory(0)
alarm(0)
probe(1)
Value TIer (3)
----------------------------------------------------------
within +/-10% (0)
out of sanity limts(3)
the functions also are set to work with specific commands only. so only if a specific command is provided, then the function can be made active. if the function and the command match, and adding all the numbers in brackets is less than 3, then the command can proceed without verbal verification. otherwise the command is rejected, unless verification would lower the safety risk number in the brackets.
