RS232 Serial Decoding and Reverse Engineering

[Mad Professor]

Good day all.

This is my 1st started topic here, so not really quite sure where I should post, so please feel free to move to where it is best suited, or boot me out on my arse if not welcome, lol.

I am thinking about starting a serial decoding and reverse engineering related project.

I will now try and give you some back ground and details on what I am trying to do.

A few months ago I got my hands on a 2nd hand Denford Mirac CNC Lathe (1990 model).
The lathe has a built in PC that run's Denford's own software to control the Mirac CNC Lathe via RS232 serial commands.
The lathe control software is MS-DOS based, and is also designed around educational environment so has a number of limiting factors.
What I would like to be able to do is install Windows on the lathe PC and run a piece of software called Mach3 that will then be able to control the lathe.

When other people have wanted to use the Mach3 software, they have ripped out all the old control hardware and replaced it with all new modern control hardware that can be interfaced to work with the Mach3 software.

This is where I am wanting to try and go down another path.
I am looking to try and decode and reverse engineer the serial commands use with the MS-DOS based Mirac software, so that I can make a plugin that with work with the mach3 software.

I have a feeling that I am jumping in the deep end of the pool with two lead boots on.

I only own basic diagnostic hardware, a few Uni-T DVM's, a PicoScope 2202 USB Oscilloscope.

I can hear Dave shouting at the screen now telling me to get a real oscilloscope, and not a toy.

As the picoscope software supports serial decoding I am hoping to be able to tap into the serial TX & RX lines, and pull useable data.

The other way I might be able to get useable data is to remove the EEPROM chip and store a dump of the chip, but I don't have the hardware or the knowhow for that at this point in time.

So at this point in time, I am really just looking for any advice or ideas that anyone can give me, or just plain tell me I am barking up the wrong tree.

Thanks for your time.

Best Regards.

[IanB]

The good thing is that RS232 is the easiest of serial protocols to decode or interface to.

Now I'm not sure from your description where the serial commands are being sent from or to. Does an external ordinary computer send serial commands to the lathe that then executes them? Or does the built in PC send serial commands to the lathe hardware directly?

[homebrew]

Hello,

for a start, you could just hook up an other computer with a RS232-Port and tap its RX pin into either of the two original communication lines. You will see at least half duplex traffic that way.
Older dos boxes tend to have two RS232 onboard. In DOS (realtime enough by definition) you might be able to dump both lines in parallel. Just write some simple BASIC code to dump the contents in a file. Later use a HEX-Editor of you choice to look at the result.

Use you scopes to determine the boudrate, startbit/stopbit etc. Then you can setup your one/two serial sniffer port(s) to that parameters.

Regarding mach3. I don't know it very well but it does the step sequencing in software, right? (I'm more the EMC2 guy)
I would assume that it is not possible to transmit step/dir information via RS232 for any reasonable machine/speed. It is just too slow. So if you manage to figure out the protocol you might still not be able to interface it to mach3. But well, thats only a bunch of assumptions ...

Best,
Pete

[mikeselectricstuff]

There are plenty of PC based serial monitors out there - you ideally want something that will monitor both ways and put timestamps on, but often once you figure out the basic structure that's less necessary.
A scope is handy for initially finding baudrate and looking at the relative timings, but once you have a general outline, simple dumps of data are often all you need.

[Mad Professor]

I was not over clear on the hardware, sorry about that.

You are indeed right, the PC sends commands via serial to the control board, and the control board then processes the data, and controls the spindle, axis, etc, etc.

The control board in the lathe an LCB3 and was made by GSM-SYNTEL LTD, but they stopped trading quite some time ago, so very limited info out there.

homebrew
Regarding Mach3 when controlling hardware via the printer port your quite right, that mach3 does all the processing and commands.

I have a DIY CNC Mill/Router that is controlled via mach3, but I don't use the printer port, I use a piece of hardware called ethernet smoothstepper, so mach3 reads the g-code commands, sends the data to the ESS, the ESS then processors the data, and commands the moves, then the ESS asks Mach3 for more data.

This is the same kind of thing I am looking to do for the lathe but via serial.

mikeselectricstuff
At this point in time I don't have any other older PC's with good old serial ports, all my other computers are just to modern.
I think I will have to look in the local paper ad's or freecycle for an old PC for serial data sniffing.
Any tips on a good piece of serial data logging?

[Monkeh]

You can do an awful lot with a couple of USB adapters and Realterm.

[Mad Professor]

Monkeh
I do own a few Prolific USB Serial Adapters, I always had nothing but problems with them randomly disconnecting, But it worth giving them a try.
Thanks for the heads up on the software, I will have a look at that now.

Best Regards.

[jucole]

I found this Denford PDF entitled "Mirac PC CNC Lathe User's Manual."  http://www.denfordata.com/pdfs/mirac_pc_600dpi_hq.pdf

On page 99 it describes the generic lathe commands (not for all machines), which might be handy.   Perhaps you could pretend to send a simple shape job to the lathe and instead hook the serial to another OLD PC with a real serial port and a terminal emulator set to capture the data into a file; you should then be able to work out the raw data used to control the steppers etc and create a driver from that.   But in theory if your driver could turn MACH3 into stepper data, and then back to decent MACH3 G-code again,  then your driver is ready for testing. ;-)

[edit:  I once captured some "baked-in" serial cutter data from an obscure old CNC machine/software into one of those old Psion Sienna PDA things via it's RS232 serial terminal application, and then did a data conversions to windows; it worked very well.]

[Mad Professor]

I have hooked up my picoscope 2202 usb oscilloscope to the serial TX line to try and determine the serial baud rate.
My limited understanding of serial data is that I take the smallest pulse width to work out the baud rate.
In my case the smallest pulse width of 97us, so that's "1 / 0.000097 = 10309".
10309bps seems like a very strange baud rate.
I was expecting 1200, 2400, 4800, 9600, 19200, etc.

[Monkeh]

Monkeh
I do own a few Prolific USB Serial Adapters, I always had nothing but problems with them randomly disconnecting, But it worth giving them a try.
Thanks for the heads up on the software, I will have a look at that now.

Best Regards.

Prolific units, genuine or fakes, are dodgy little things. Chips like the CP2102 are a little better, FTDI, however, generally Just Work(tm).

[jucole]

I have hooked up my picoscope 2202 usb oscilloscope to the serial TX line to try and determine the serial baud rate.
My limited understanding of serial data is that I take the smallest pulse width to work out the baud rate.
In my case the smallest pulse width of 97us, so that's "1 / 0.000097 = 10309".
10309bps seems like a very strange baud rate.
I was expecting 1200, 2400, 4800, 9600, 19200, etc.

97 uS is very close to 104 uS which is 9600.

[madires]

I do own a few Prolific USB Serial Adapters, I always had nothing but problems with them randomly disconnecting, But it worth giving them a try.

I'm using them for years without any problem with linux systems. Even got multiport versions running 24x7 for years. 

[madires]

Prolific units, genuine or fakes, are dodgy little things. Chips like the CP2102 are a little better, FTDI, however, generally Just Work(tm).

I slightly disagree :-) Had quite often driver problems with FTDI chips under WinXP. Replacing with a PL2303 fixed that always.

[RobbieC]

I've used Keyspans for years with mostly no problems (their drivers have caused some system crashes and reboots in the past, both with XP and OSX) and they include a basic hex/ASCII serial sniffer as well.

Here's the link:
http://www.tripplite.com/en/products/model.cfm?txtModelID=3914

For basic sniffing, it works fine but could also be combined with a third party software sniffer and logger.

At work we have a USB hardware sniffer that I've never actually tried, but I'll check and see what brand it is.

Good luck!

[Mad Professor]

wilfred
The manual is referring to the >1996 version of the Denford Mirac where it is fitted with a newer control system "EuroStep Controller Cards", and all the software is windows based.
My Denford Mirac is a 1990 model and the control system is the LCB3 and was made by GSM-SYNTEL LTD, and the control software is MS-DOS based.

[Mad Professor]

Made a small bit of progress this morning, and also a small setback.

1st the setback, when trying to sniff the serial data via using a laptop and one of my prolific usb serial adapters, as I load the lathe control software I see a burst of data on the terminal screen, but the lathe control software then fails to see the controller. This happens no matter if I tap into the TX or RX lines of the lathe serial cable, so I am guessing the data lines are getting pulled to low for the lathe controller to cope.
I have not yet confirm that be using my scope, but I will be having a closer look later on today.

EDIT:
Just tested the serial voltages again but with the usb serial adaptor.
TX Line from the computer, 8.90v peek to peek, -8.12v to +781mv.
RX Line from the computer, 8.90v peek to peek, -7.96v to +937mv.

Without the usb serial adaptor connected to the TX & RX lines, I get the following voltages.
TX Line from computer, 20.79v peek to peek, -10.16v to +10.63v.
RX Line from computer, 16.40v peek to peek, -8.75v to +7.65v.

I have been able to pull some data from the TX and RX lines by using the picoscope and it's built in serial decoding.
9600bps does indeed seem to be the correct baud rate.

Something I did find strange is once the lathe control software is loaded and you are at the 1st loaded screen there is no watchdog, no data at all to or from the control board, It's not unto you go into one of the other screens, that the watchdog kicks into live.

I have turned the serial decoding to ASCII, and can see while the system is at idle it sends out a single ascii character, the control board reply's with the same character then 133ms later the controller sends a bunch of data.

[jucole]

Just had a thought,  if the lathe software has a "calibrate" option you could let it run and capture all the available axis motions as well as the limit switch signals.

But you'd have to be careful when you start sending it test data, as you probably couldn't run the tool-post off the end of the track onto the floor because of the limit switches and the lathe control board,  but you could certainly accidentally run the tool-post into a spinning chuck, which would be nasty or run the lathe bit into the material too fast.

[ttp]

A few months ago I got my hands on a 2nd hand Denford Mirac CNC Lathe (1990 model).
The lathe has a built in PC that run's Denford's own software to control the Mirac CNC Lathe via RS232 serial commands.
The lathe control software is MS-DOS based, and is also designed around educational environment so has a number of limiting factors.
What I would like to be able to do is install Windows on the lathe PC and run a piece of software called Mach3 that will then be able to control the lathe.

Have you tried Denford forums? I'd imagine a protocol from 1990's wouldn't be a big secret.

[Mad Professor]

ttp
I have e-mailed them and posted a number of questions related to the denford mirac cnc lathe on there forum.
It seems denford are unable or unwilling to give more details then they already have on the forum or in the pdf manuals.
They keep pointing the finger back to the firm that made the LCB3 control board "GSM-SYNTEL LTD", as said before, GSM-SYNTEL LTD have long since stopped trading, so there is no way of contacting them for any details on protocol used.

[abyrvalg]

What kind of USB-Serial are you using? There are "true RS232" ones with +-12V levels (these have a standard DB-9 connector on serial side usually) and "TTL" ones with +5V or even +3.3V levels (i.e. cell phone data cables). You need a "true RS232" one obviously. If your one is "TTL", it's protection diodes will try to limit the original signal.

If you get two "true RS232" adapters, try "LGComSpy" serial monitor software in "pass-thru" mode - very handy to monitor both Rx and Tx simultaneously.

Another option is to disassemble the control PC's software

[Mad Professor]

abyrvalg
Both are prolific usb serial adapters, and they look like this:


Anyway I have given up trying to sniff the serial data by using the above prolific usb serial adapters.
I have been able to get my hands on an older pc that has real hardware onboard serial ports.
This computer does not drag down the voltages on the serial lines, so I am now able to sniff both the TX & RX lines while the lathe is running.
At this point in time I am only looking at the serial commands sent to the control board, then I will be looking at the control responses.

Below are a few of the serial commands in ASCII format.

Home X Axis

M09;M13;I;F1200;K;I;M13;P;I;M13;P;I;M13;P;I;M13;P;I;M13;P;I;P;I;M09;M09;U15;

Home Z Axis

M09;M13;I;F1200;J;I;M13;P;I;M13;P;I;M13;P;I;M13;P;I;M13;P;I;P;I;M09;M09;U15;

Spindle CW 500rpm

M09;M13;U04;V05;E0250;M09;U15;

Spindle CCW 500rpm

M09;M13;V04;U05;E0250;M09;U15;

Spindle Stop

M09;E0000;V04;V05;I;M09;U15;

It seems a at 1st look that some of the commands are standard g-code (m-gode) commands, like M09 & M13.
Sadly this is not the case, as M09 is Coolant off, and M13 is Spindle on CW and flood coolant on.

It's now just a case of working out what each piece means.

[abyrvalg]

Do you really need to decode all these single operations like M09? Just make a list of low level operations required by Mach3 (like "spindle cw at rpm=R", "move to x=X with feed rate=F" etc), execute them in original software with different parameters and capture command strings without going into every detail, except the positions where to insert rpm, coords, feed rates.
I.e. try starting a spindle at 300 RPM - will that E0250 change to E0150 as RPM/2 ? If yes - just use M09;M13;U04;V05;Errrr;M09;U15; with rrrr=RPM/2

[true]

Prolific units, genuine or fakes, are dodgy little things. Chips like the CP2102 are a little better, FTDI, however, generally Just Work(tm).

I slightly disagree :-) Had quite often driver problems with FTDI chips under WinXP. Replacing with a PL2303 fixed that always.

If you have a legit one, and it isn't an older chip, maybe. I was a PL2303 believer until the fakes started hitting the market...it's so easy to buy a fake now compared to a legit one, even legit brands use fakes, and most adapters I have purchased or have come across in the last 2 years with a PL2303 have been total crap.

Anecodes are wonderful things...

[abyrvalg]

Just for curiosity - did you looked inside the LCB3? What is there? Some 8048/8051?

[Mad Professor]

abyrvalg
Below is a list of the main components of the LCB3 control board.

-------------------------------------------------
U1   EF6809P
U2   TL7702ACP
U3   SN74LS138N
U4   (SYN-017)
U5   TMM2764DI-2 (EPROM NO 929 PC03095 LCB3)
U6   TC5565APL-12
U7   EF6840P
U8   MC6840P
U9   MC6840P
U10   EF6821P
U11   EF6821P
U12   EF6850P
U13   MAX250CPD
U14   SN74LS02N
U15   SN74LS123N
U16   SN74LS123N
U17   DM7407N
U18   ULU2803AN
U19   ULU2803AN
U20   6N137
U21   LF356N
U22   EF6821P
U23   EX039L
U25   MAX251CPD
U26   ULU2803AN
-------------------------------------------------
OPT1   TLP521-4
OPT2   TLP521-4
OPT3   TLP521-4
OPT4   TLP521-4
OPT5   TLP521-4
OPT13   TLP521-2
OPT25   TLP521-2
-------------------------------------------------
IT1   76250
-------------------------------------------------
XDRV   GS-D200
ZDRV   GS-D200
-------------------------------------------------

[abyrvalg]

A 6809 with 8k ROM and 8k RAM - nice!
Just for curiosity again - if you have a prommer to read that 2764, i can look at the dump in disassembler.

[Mad Professor]

abyrvalg
As said in my 1st post:

The other way I might be able to get useable data is to remove the EEPROM chip and store a dump of the chip, but I don't have the hardware or the knowhow for that at this point in time.

[abyrvalg]

Some code like this:

Code: [Select]

switch(cmd[current_position++])
{
   case 'M':
       //parse number after M
   ...
   case 'U':
   ...
}
is more probable to see in a size-constrained firmware, but this leaves nothing visible in text view (btw, control PC's software should be a much easier target for such quick text-mode lookup, they can just printf() to strings like "M09;M13;U04;V05;E%04d;M09;U15;").

If you don't have a prommer to read the EPROM - better keep dumping RS232. Anyway, your Mach3 driver will translate single G/M codes to some strings of this "LCB3 language", so you need a string corresponding to a single G/M, not what each M09, U15 etc does

[Mad Professor]

abyrvalg
Thanks again for your replies and input.

Sorry for the lack of feedback from me, my wife and her friend have just brought 2nd hand cars, and with me being an ex grease monkey I have been roped into doing full service on there cars, and fixing any other problems.

I would not have any idea where to even think about starting with regards to decoding the software it's self.
The Mirac control software can be downloaded direct for the Denford where site here: http://www.denfordata.com/downloads/dos/MIRAC.zip

I am looking to try and get back into my workshop this weekend to start probing more data from the serial lines.

Can anyone here recommend a program for MS-DOS so that I can send the serial commands back to the control board for testing?
Yes I could use the windows computer that I am using for sniffing the serial data, but I can't inject data back into the serial with the lathe computer still connected, and moving a 1m x 1m x 0.6m, 350Kg lathe about in a small working is not an easy task.

[jucole]

If you look in the Mirac.txt file ~ line 1600 onwards there is a load of info.

for example:

G04  Dwell

A G04 causes the program to wait for a
specified amount of time.

The time can be specified in seconds with
the "X" or "U" prefixes or in milliseconds
with the "P" prefix.

Examples:  G04 X1.5
G04 U1.5
G04 P1500

[geraldjhg]

get two rs232 setups running (hyperterminal at least but others are better)  and connect
the rx only to both tx lines on the ongoing setup in both directions of commubnication
 (as it is a high impedance input) you will get an idea what msdos is sending and what the
CNC is responding
if it ascii commands you might be in luck
if its all binary you are in double trouble

[VladimirM]

Hello,

for a start, you could just hook up an other computer with a RS232-Port and tap its RX pin into either of the two original communication lines. You will see at least half duplex traffic that way.
Older dos boxes tend to have two RS232 onboard. In DOS (realtime enough by definition) you might be able to dump both lines in parallel. Just write some simple BASIC code to dump the contents in a file. Later use a HEX-Editor of you choice to look at the result.

Use you scopes to determine the boudrate, startbit/stopbit etc. Then you can setup your one/two serial sniffer port(s) to that parameters.

Regarding mach3. I don't know it very well but it does the step sequencing in software, right? (I'm more the EMC2 guy)
I would assume that it is not possible to transmit step/dir information via RS232 for any reasonable machine/speed. It is just too slow. So if you manage to figure out the protocol you might still not be able to interface it to mach3. But well, thats only a bunch of assumptions ...

Best,
Pete

Correct, but you can even monitor full duplex RS232 communication is 2 ports are used and data is forwarded from one to another and vice versa. And then you have information on all the data to see.
Docklight  https://docklight.de/  has this option ans it displays all the data very nicely in different colors and in ASCII or binary RAW format.. There are even some advanced scripting options to influence in its traffic.