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 Controlprinciples - CAD
Computer-Aided Designand CAMComputer-Aided Manufacturingprocesses. - G-Code
CNC Geometry Codeformat and its reference - HP-GL
Hewlett-Packard Graphics Language - FORTH
A procedural, stack-oriented programming languagedecompiling. - The specific FORTH language from MultiCam called μCito / micro-Cito / uCito
- RS-232
Recommended Standard 232serial communication over DE-9D-Subminiaturecable. - 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 memoryfile that is specific for our exact machineFLRAM.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!
