While working on SCL I got this idea of doing OLP with scripts. If you think about it the scripting approach is a direct match for running robotic programs. Each robot vendor has its own syntax but eventually all languages are designed around the same stack oriented programming principle.
For each vendor we'll have to introduce a dedicated script engine (similarly to the SCL script engine). This by itself is a pretty difficult task since we need some deep knowledge of the vendor specific syntax (grammar). Implementing a parser for each grammar is not always straight-forward even with modern parser generators like ANTLR. It just takes time and effort. Applying the language rules and semantics is also difficult but essential to build a decent interpreter. But once you get over this point the OLP commands (as we know them) are just regular statements in the program code.
Robotic programs are usually designed to be self-sufficient. Meaning they don't need anything else to run. The target positions, the initial state of the variables, the motion instructions, the logic etc. are all built within the program text. The same is true for the script.
The script can be edited easily with a little support from the code editor like context based code completion and code validation. Imagine editing a robotic program like this ... you just type. No other tools needed.
Once your code is grammatically correct you can instantly run it and see it working just like on a real robot. Furthermore in case of logic errors you can debug it just like SCL. The SCL debugger is actually a generic script debugger that can be reused for other languages as well. It needs some touches here and there to make completely opaque to the syntax. Here is how it looks debugging the Fanuc LS syntax.
With the scripting approach the script is the single source of truth. e.g. the UI, the download, the simulation work on the same script. The code in PS will be the same code running on the real robot. For the user the development effort is small. Just edit the script.
Grammar and semantic errors can be detected in advance. No additional tools will be needed in PS. Just use the native robot syntax.
Some might think that learning the specific robot program syntax is difficult. How about learning custom XML in PS? There you need to learn both the robot syntax and the XML syntax. Isn't this even more complex? If you are a power user writing in the native syntax only is much easier. If you are a regular user then the a power user can prepare a native code snippet for you and you only paste it in.
Nowadays we integrate with VRCs from different vendors. They all work externally to Process Simulate and we end up doing some cross process calls. Performance, security, communication protocols, time synchronization - these are all things we should take into account. The end result is usually not that good for the user. With the scripting approach we may have a built-in VRC for each robotic language running at optimum performance.
I think you get the idea. Process Simulate can become a real scripting power horse making it easy for the user to design, run and debug robotic programs.
But this is all a future vision for now.
See you!
Comentários