2

Here's an undertaking I'm currently in, and would absolutely love someone to assist more directly. I'll list the subjects that I would greatly appreciate more knowledge within. Know anything about one of these, then I'd most likely love your help.

  • CNC Computerized Numerical Control principles
  • CAD Computer-Aided Design and CAM Computer-Aided Manufacturing processes.
  • G-Code CNC Geometry Code format and its reference
  • HP-GL Hewlett-Packard Graphics Language
  • FORTH A procedural, stack-oriented programming language decompiling.
  • The specific FORTH language from MultiCam called μCito / micro-Cito / uCito
  • RS-232 Recommended Standard 232 serial communication over DE-9 D-Subminiature cable.
  • The way a Stepper Motor works
  • Any Microprocessor Programming / Burning / Flashing experience. Such as ATmega328P (Arduino)
  • Any SBCs Single-board Computer. Such as the Raspberry PI
  • Old 90s MultiCam CNC machines. Like the one I'm on: MultiCam 44 Plus (Similar Control Enclosure)

If one, more, or any of these fall under your interest, and you're in my ballpark 😀. I'm semi knowledgeable in all of the above, but I'm still lacking in the FORTH language and decompiling it. If you're experienced with FORTH, and know how to decompile a firmware that is built like it, please read on, cause you're exactly who I'm looking for!


Bit of background info and intentions:

We have an old MultiCam (hereafter: MC) 44 Plus CNC Router that was purchased back in the 90s to start a woodworking company. Links above show close to exactly what we have. The machine has been running great, and is mechanically solid as f***. It's electronics are really solid as well. Only trouble with it has been a flakey COM connection, and loose wires. Since CNC software has gotten WAY more advance since the 90s, there is so much available that could improve the CAD process. Since the CAM process has stayed very much "the same" at it's low-level computing, it seems logical to improve upon the machines firmware to integrate better interpreting functions of the CAD files. G-Code seems to be the biggest "standard" emerging today.

This machine reads exclusively HPGL files, but in a kind of proprietary way. It's intended that toolpaths be exported from MCs own CAD/CAM software EnRoute. The HPGL Post-processor is obfuscated to unreadable, but all exports are done with HPGL mode set to 3D (ZZ1 command). These specific HPGL commands are described in the manual that followed the machine.

Since the machine controller board (hereafter: S960) is completely outdated, and impossible to find a equal one at a reasonable price, the plan is to replace it with another controller and see that it's possible to keep the machine production up and going even in the event of a complete failure of the S960. So I've ordered some other "basic" controller-boards from China, and looking into Mach3 and the works. But to get all the current machine specific parameters from the S960, I started to interface with it over it's RS232 COM-port. And this is where I found a very nice system/program that was controlling it. So since it's already nicely connected, I want to get deeper into this firmware and append more functionality.


Research and progress:

I can probably not publicly share the firmware file and other executables/files. So here is what I'm currently working with:

  • A NVRAM Non-volatile random-access memory file that is specific for our exact machine FLRAM.UC. It's a long list of parameters written in straight forward uCito commands. Like this: 134184961 138 16 set_sysparam 0.900000 139 32 set_sysparam 228.000000 1 set_float 150 36 set_integer - This file came with the purchase of the machine.
  • Some software that performs basic tasks. COMCHK.EXE that performs basic RS-232 quality. MX.EXE that interfaces the low-level on the S960 such as uploading files. DIAG.EXE which I don't know yet what does. Name implies it checks basic functionality of the S960. And M960UPD.EXE that I've not tried, and kinda don't want to mess too much with, since it's what updates the firmware - These files came with the purchase of the machine.
  • A binary-formatted file MTK328G.BIN which must be the current firmware. It contains many readable words that are direct words available on the terminal, thus seems to be the entire ROM that defines the uCito language. At the end of the file, it's written in plain-text uCito. - This file came with the purchase of the machine.
  • A uCito-formatted file M23-MIST.INI that is purely written in plain-text uCito. It's developer commented on the top (dated 1996) with changes made to the file, and it contains the word definitions and variable definitions of many machine specific things. Such as the key functions that are run when one presses the keypad keys on the machine itself. This file is what taught me the language. - This file came with the purchase of the machine.
  • The basic "file to machine" server application called WinDNC WDNC.EXE. It also came with the machine, and it's extremely "simple". It just passes along a directory of files to the machine if the machine requests it.
  • MultiCam Motion Mechanic. This is a program I found while googling the machine, and seemed to be a terminal program to interact with this specific language of machines, and it worked with ours as well. It opens a basic terminal interface, where the machine sends a prompt in return. It gives some more low-level functions such as: "Reboot machine - Load INIT", "Reboot machine - Don't load INIT", "Reboot machine - Monitor mode". Those all do what they say. Monitor mode acts very different, and seem to be the mode needed to perform a true firmware upgrade. It can also send a "change language" request to "Go native (uCito or native)", which switches the machine from hpgl mode, to uCito interactive mode. This interactive mode is where I learned / tested the language, and it's pretty cool how "on the fly" it works.

I gather by now that the machine operates the following way:

It has a main controller called S960. This is the "brain" that parses and stores the proprietary uCito language that is basically just FORTH, with the word definitions changed from pure FORTH. The controller is directly placed beneath the breakout board. This breakout board is labeled M23, and it contains all the pins/plugs which goes to all the interfaces. It has two LED bars with labels, and they light up as the input is triggered (Like the limit switches, Pause key, E-STOP switch, Z-Surface set block, etc). Some LEDs are always lit, and thus seems to be unconnected inputs. It also has a white tactile button that restarts the controller.

From this breakout board, wires go everywhere. 1 directly to the serial of the computer. 4 to the stepper drivers (3 wire leads to each of the 4 drivers. Enable / Step / Dir). 1 to the spindle relay. 1 to a "Mister relay" that we've never used. 4 to the limit sensors (rigidly mounted induction switches that triggers when a bolt is underneath it). 2 to the pendant (The control-panel box with keypad and a 20x2 char LCD display). 1 to it's own 5V power-supply.

The controller most likely has a kernel that starts the RS-232 (this is most likely "monitor mode"). With no input, it will perform the default boot. It loads the firmware file, and the firmware then loads its own INIT file, that contains more expanded operations of the machine. The INIT file ends with putting the machine into HPGL mode, thus stops echoing input on the RS-232.

The kernel can be told to not load the INIT file, just leaving the machine ready in native/uCito mode. In this mode, naturally no keys on the machines keypad itself works, and nothing is shown in the LCD display. But it interacts with uCito typed directly into the terminal. As such, I could just type out the M23_MIST.INI file in terminal, and it would do the same as if it was loaded.

I've discovered a bunch of what words do and definitions. Some examples:

stk - prints the integer stack without modifying it.

fstk - prints the float stack without modifying it.

. - pops an integer from stack and prints it. f. for float stack.

: <word> <code> ; - defines a word just like FORTH, but here one can "stack" words on top of each other. If defined again, future references will refer to it, but previous references will use the first definition.

set_float - Takes an integer from the stack and uses that as a location ref in NVRAM where it stores a float it also pops from the stack.

get_pos? - Takes an integer from the stack and finds that axis position (0-2 = X-Z) and puts it on the float stack.

umaline - Takes 3 floats. X, Y, Z, and moves the machine to those machine absolute coordinates. ualine is same, but in relation to it's "Set Home", and uline is in relation to current location (Relative move).

wait_plot - Will START any of the above movements queued, and waits for them to finish.

And many more...

The Motion Mechanic software also has a function to "Send file" and "Store file". The send just takes a file and "types" it into the terminal, but the "store file" has a list of locations to store into. These are numbered 1 to 20, and a special "U" spot for the User INIT file (The M23_MIST.INI). With some experimentation and just pure guessing, I used "dir" command to list the filesystem. It has numbered files, and the INIT file, and shows the available space. The "list" command preceded with a filenumber will print the file to terminal, thus it allowed me to capture and download the INIT file on the machine, and a SELF_TEST file that was located in #2. After doing a blunder and trying the "format_files" command, wiping ALL files on the filesystem, I was able to understand that position -3 was the INIT file location, and used "-3 store" to save the INIT file again and boot the machine, but also letting me easily edit the machines code. I found these commands by just looking trough the binary firmware file. It's mostly unreadable binary, but here and there the word definitions show up. So have to judge only on their names alone to figure out what they do. Many commands (such as ioctl and the likes) I stay away from since I might blow up the machine unless I know what they do.

And THAT segways our way into why I'm posting.


There is a whole bunch of stuff "going on" in the firmware, and many more definitions of words that I don't know what does, or their parameter requirements on the stack.

I would like some assistance with decompiling this firmware so I can explore the possibilities with the current one, and thus we can develop more advance functions in the INIT file. Possibly we could create/update the firmware and flash it to the machine. Though I'm very skeptical on doing that. The machine is in production, so I'm trying to thread carefully not to brick it.

Is this something that would interest you? Want some example snippets of something? Please get in contact!

Edit: A snippet of the start of the firmware file

And thank you so much for reading trough my wall of text. Best wishes!

1 Answer 1

2

interesting project you've got here and you're giving a good overview - maybe too much (in comparison to most of the other questions here)

i think you need to search for (retired) poeple that got deep or better very deep knowledge about your CNC and the S960/M23 controller stuff, to get (more safe) informations about firmware upgrading etc. - details around your target at best: how to store and restore the complete machine state - for the case you damage something in the firmware/config/settings

do you have any idea what technology is behind x86, PowerPC or super-special, due to the age of the system?

are you maybe able to write an emulator that can run the firmware? most microcontrollers or hardware of that time wasn't super complex - to have a clean room for analysis?

did you tried Ghidra, Binwalk on your firmware binary? (could work but its maybe too old)

6
  • 1
    Thanks for your reply. Will definitely go more in towards analyzing the firmware. I have also sent some emails trying to get into contact with whoever might know more. I have no idea what processor is running it. I might try and remove the M23 breakout board to see the labels on the processor IC. That should give way more pointers on what architecture is used. Here is a snippet of the start of the firmware file. Maybe this could tell you more? It's very seems organized into 16 byte and 8 byte chunks. imgur.com/a/TyzCAYi
    – arsenic87
    Oct 2 at 4:29
  • maybe binwalk could help to find the architecture is used: embeddedbits.org/… and can you put up some photos of the controller cards?
    – llm
    Oct 2 at 6:20
  • 1
    Loads! I'm not used to posting on StackExchange, so a bit unclear on how to post an update. But very short summary: I took apart the motherboard, and found the processor is an Intel i960 (should have guessed, right?). This "monitor mode" is actually described a lot around the intel manuals as a prebuilt ROM, and it seems the developers of this uCito language has kept that monitor mode for updating the firmware. I also found the guy that made it: extratech.com/co-history
    – arsenic87
    Oct 10 at 14:33
  • 1
    The i960 is specifically a 80960SB. It has a PA28F400-BVB80 (BOOT FLASH / EEPROM) that I suspect is used for firmware and the "file storage", and a bit of to the side is a UV-erasable EPROM that has a "home-made" uCito sticker on it. That EPROM is a M87C257-20FXI that most likely contains the "handler code" for firmware. I'm gonna work on dumping it's flash, but might be able to dump it all trough the terminal :)
    – arsenic87
    Oct 10 at 14:48
  • 1
    Here are some pictures of the board
    – arsenic87
    Oct 10 at 15:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.