Hi all,
Has anyone tried creating custom programs on the Groov EPIC using the shell? I’m interested in exploring the possibilities of the EPIC’s shell, not for production use but more as a hobbyist project. My initial idea is to start with something simple, like viewing I/O data, just to get a feel for the system’s capabilities and how I can interact with it programmatically. If anyone has experience or insights, I’d love to hear your thoughts or suggestions!
Thanks in advance!
Did you check this website: Getting Started with Python for groov EPIC | Opto 22 Developer
It has examples for Python
Keep in mind, accessing the Linux Shell level on an EPIC means, great power comes with great responsibility.
1.Download “Shell Licence” from “My Opto”
2.Install “Shell Licence”
3.Open port 22 in “Firewall”
4. Enjoy Shell Operation
Step 3 can be skipped over.
When you install the shell license in step 2, the firewall rule is added for you.
Linux is not unique to EPIC or RIO.
So, spending time in any Linux shell would benefit your adventures.
There are several web-based sandboxes on the web, so if you just want to get started in the Linux command line, you don’t need real hardware on site.
Many free courses that teach the basics are also scattered around the Internet.
Once you are comfortable in shell, bash and nano, pick a task and jump in.
Thank you so much, @gerhardK, @yuqingguang, and @Beno, for your valuable suggestions and for sharing the resources. I’ll make sure to explore developer.opto22.com and check out some courses as well before I accidentally break something.
== Languages ==
The main languages included in EPIC/RIO are python, c, c++, bash/dash, java, NodeJS/JavaScript, and perhaps others.
I wouldn’t use python due to its slow speed when that’s a concern. Starting a program written in python can take a second or two before the first line of the script is executed. I have run into situations where I wanted to start multiple instances of a python script (thirty or so) and the set of operations would not finish for more than about a minute. If the program had been written in a faster language, the work would have been done in one second. If a user has to wait more than a minute for a task to be completed, then that person may believe the EPIC/RIO is not responding.
I wouldn’t use C++ because it’s too complicated and verbose for little gain, and the language has many instances of undefined behavior that can lead to hard-to-detect bugs. There’s not much advantage C++ has over C, although C has major problems as well including its own set of undefined behavior.
Bash and dash are the shells that run on EPIC/RIO. Bash has all the features of dash and more, but dash is faster. I have written many bash scripts on EPIC and RIO. However, I’d recommend to avoid writing shell scripts in favor of other languages if you can. Bugs creep into shell scripts too easily. I had a computer science professor who said not to write shell scripts that are more than twenty-five lines, as a rule of thumb, because shell scripts are difficult to understand and error prone. Features like iterating over arrays or handling filenames with spaces are especially difficult in bash and dash, yet arrays are such a useful programming construct. Running commands in a systems programming language, such as C or JavaScript running in NodeJS require more lines of code than doing so in a shell, but entirely possible, especially once you have a solid code base that you can build upon. All that being said, bash on EPIC/RIO isn’t an unusual tool for developers to use; it’s just not very good.
Java can be a decent language without so many of the pitfalls of C++, but I don’t recall whether the development kit is available to developers. You could ask the Opto folks if you’re interested. Another downside is that Java is an object oriented programming language, which will require more typing on the keyboard to do the same task as some other languages. Also, writing object oriented code that does not result in spaghetti code is a skill that many programmers lack.
JavaScript/NodeJS is one of the two better options. The language is easier for beginners. JavaScript running in NodeJS is asynchronous, so some of the concerns of multi threading are avoided, but a task can be done asynchronously instead of blocking. NodeJS allows JavaScript to be a systems level programming language like C and C++. You can fork/exec other processes and perform some other low-level tasks like those you’d find in section 2 of the man pages. (In case you don’t know what I’m talking about, run $ man man in the shell to see the list of sections with section 2 being system calls and exemplary $ man 2 fork). I’d, persoinally, avoid using node libraries to avoid supply chain attacks.
Lastly, there is C, which has some serious problems and a few upsides, but writing your own C-like language which transpiles into C is an option, too, which might be one of the better options for the dedicated coder. The problems with C are UB (unspecified behavior, undefined behavior, etc), memory leaks, segfaults, lack of builtin data types (which make writing some algorithms difficult), and intellectual property claims. The upsides to C are its speediness, conceptual simplicity, mature tools, and system-level access.
As for making your own language that transpiles into C, you can use flex and yacc (or bison) on your development workstation. There is a yacc grammar available online, ANSI C grammar (Yacc). Your language would be “C-Like,” with if statements, loops, expressions, functions, and other basic elements of C. If you later find the C you’ve been writing is UB, you can change the way your language generates code to fix the issue throughout your large code base. You can also add the data types that C lacks into your language. You can limit the way memory is allocated and automatically free memory to avoid many memory leaks in C, e.g. only allow pointer assignment to local scope variables and generate code that ties freeing memory to each return (instead of allowing a return statement without freeing memory). If you find later that C is the wrong language for the job, you can change just the generators to transpile into another language, maybe JavaScript or another procedural language.
== OptoMMP ==
Accessing I/O from custom programs (as you have asked about in the OP), can be done using OptoMMP. See the OptoMMP protocol guide, https://documents.opto22.com/1465_OptoMMP_Protocol_Guide.pdf.
As cautioned on page 7, multiple communications can cause conflict, so your custom software must be the only writer and accessor of the I/O. The other controllers and I/O accessing services must be disabled.
Page 82 of the OptoMMP protocol guide talks about sending a PUC right after connecting. This is easy to overlook, so I mention it here.
EPIC and RIO have a VPN called wireguard available in the apt repository. You can install wireguard via the shell, and then follow the quickstart, Quick Start - WireGuard. Then all your OptoMMP communication should be done on either the loopback interface for I/O on the same device or over the VPN for remote I/O. This adds security to OptoMMP communication.
OptoMMP on EPIC and RIO has TCP and UDP support. I actually don’t know which of these protocols to use with OptoMMP. For other protocols I would use UDP, but I’m not sure UDP is best here.
== REST API ==
Besides writing software to interface with the I/O, you can also write software to interface with the services, such as groov Manage. There is the curl command for making REST requests. The groov Manage REST API is described here groov Manage REST API | Opto 22 Developer. There are curl libraries for C and other languages, too, so you can use the REST API with those. REST requests can be made to the local device or remote devices.
== Read Only Backups ==
I recommend making read-only backups of the source code of the custom EPIC and RIO programs you write. Backups and repositories on read-write mediums can be subject to tampering or ransomware. The consumer-grade options for read-only backups are optical disks, tape, and SD cards with the read only switch toggled on (like old floppy disks). Optical disks have limited space, can be scratched, or lose their data after ten years or so due to normal wear. Tape drives can be expensive and obsoleted. SD cards can be pretty unreliable, too. Despite these shortcomings, I’d pick one of them. You should checksum the whole backup to later verify integrity. Make multiple backups and test your backups (e.g. comparing the checksum of the backup data with the checksum of the original data). Multi session CDs are preferred over single session CDs to avoid waste. CD hardware and media are relatively cheap and available as of the time of writing this. I back up to read-write in addition.
Your question is broad, so I’ve tried to provide an overview. If you have other questions, feel free to follow up.
Thanks very very much for the extensive experience share there @Indigo
It’s very much appreciated.
I agree and have experienced a lot of what you share with one exception…
This is just unheard of till now.
We have a LOT of customers using Python as their main shell programming environment.
Never heard of a (start up) speed issue, in fact, we guide most customers to Python if they ask whats the best way to get started in programming. JavaScript comes in second.
We have a few customers using Java. Its a case of ‘if you are using Java, you don’t have to ask’.
In other words, there is nothing for Opto to provide. That’s the whole point of Java, you can write it on your workstation and just move it over to the EPIC/RIO when you are ready to go and it just works (or so I am told).
I like to point people to the 321 backup method.
3 different backups
2 different types of media
1 off-site.