I'm trying to identify the operating system on a Thermo-CRS C500 robot arm controller. From the specifications I know it runs on a 100 MHz 486 processor, and has 4 MB RAM and 2MB of flash/NVRAM combination for filesystem.

All the identifying strings in the system only refer CROS -- CRS Robot Operating System -- v 3.1.1249. It may be that this is a completely custom kernel, but it might also be based on some kind of BSD or other UNIX-like system.

The system shell has a quite unix-like environment. Most of the system binaries, such as /bin/cp and others are implemented in some kind of bytecode. The bytecode interpreter resides in /sbin/r3interp, which file indentifies as FreeBSD/i386 compact demand paged executable.

The kernel binary contains some strings that could help identification:

  • Caught wild IRQ 0
  • double fault exception (very bad) [e=%08x]
  • invalid TSS exception [e=%08x]
  • Cur_Proc->pr_vfsd.vf_vp == 0
  • sp->owner == Cur_Proc->proc_id

In particular the x86 exception names exist in most kernels, but not in that form. I have already checked late 1990s versions of FreeBSD, 386BSD, Linux 1.x, Minix 1 and 2, Xenix 386 and NetBSD, but haven't found a match. For more detailed analysis, binaries are here and boot messages here.

Can someone figure out some obscure Unix version that might be the base of this customized system?

  • What about an in house product?
    – UncleBod
    Jun 14, 2020 at 11:26
  • 4
    Even an in house system is going to start from something with this file system. Jun 14, 2020 at 11:44
  • Have you tried to identify the manufacturer? They might be willing to tell you.
    – UncleBod
    Jun 14, 2020 at 12:22
  • 1
    @UncleBod I haven't tried contacting them for this, but some other people did about other information about the system - it seems they don't have anyone who could answer, as the system hasn't been manufactured since ~2003.
    – jpa
    Jun 14, 2020 at 13:43
  • What happens if you use readelf on r3interp? Jun 14, 2020 at 14:51

1 Answer 1


Here's a manual for CROS and one for the C500C robot controller. It seems clear that the bytecode files are compiled from the RAPL-3 programming language (no filename extension for binaries, .r3 for source files, .v3 for "variables files". There's a manual for the language here and for the development tools, which run on Windows, here. The manual for updating CROS on the controller is here which makes it clear that CROS is updated by re-writing the OS image on the controller, then rebuilding the filesystem on the controller.

I can't find anything in any of these manuals that indicates that CROS is based on any other OS. Given the scale of the software provided for it, it seems plausible that it was purpose-written for the job. Re-using a BSD file format would save some wheel-reinvention, but it could also be a coincidence of magic numbers. The boot-up messages don't say anything about the Regents of the University of California, which is a requirement with BSD-licensed code.

  • 2
    Yeah, I guess you are right. Nowadays it would be weird for any company to spend so much time reinventing the basic operating system, but things were different back in 1990s. And after all they did make up a custom programming language.
    – jpa
    Jun 14, 2020 at 15:20
  • 7
    I think we often overestimate the effort it takes to design a programming language, or implement a compiler or operating system. Yes, implementing an operating system that can reliably run on millions of possible combinations of CPUs, busses, graphics cards, storage controllers, network cards, can scale from watches to 10000 CPU supercomputers, can support batch, interactive, transactional, and realtime workloads, support I/O-bound and CPU-bound workloads, steady and highly volatile workloads, and be easy to use for novices while being powerful for experts is hard. But this is not such an OS. Jun 14, 2020 at 19:59
  • 5
    … this OS has 1 well-defined hardware platform, 1 well-defined workload, and 0 users. Jun 14, 2020 at 20:00
  • 2
    @jpa Not at all. For robotics and industrial equipment it is in fact very common to write the entire operating system from scratch. The only reason you'd use an existing operating system is if you need TCP/IP networking and can't find a good library or save files on standard filesystems like NTFS or EXT3 and can't find a good libraryor need a GUI and can't find a good library because they require writing complicated drivers . If you're doing none of the above it's easier to manage your processes directly by using timer interrupts in your own code
    – slebetman
    Jun 15, 2020 at 6:30
  • 2
    Way back when, working on an embedded system, I wrote an OS in 8086 assembly. It handled radio communications using a homegrown protocol, dynamic memory management, digital and analog I/O, and it had a bytecode interpter. I also wrote the compiler, in C, that turned a DSL into bytecodes to run on the embedded system. It wasn't as big a task as a modern OS because the requirements were very specific. I only had to support just what the system needed, no more, no less. Jun 15, 2020 at 14:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .