EMCO Concept 55, need ethernet comm protocols

This is going to be a long shot but I thought I would ask.

I was given a like new EMCO Concept 55, built 2007. Equipped with 4th axis and 8 station tool changer. Has ethernet communication with the PC, and USB comms to the Fanuc 21 emulator terminal. The machine works, and I am able to jog and home the axes.

I could use the machine as it is, but I don't want to expend the energy to learn obsolete Fanuc software, I upgraded my lathe just because of this. 30 year old Fanuc software in that case.

So here is what I want to do: Since everything is in working order, I want to use the existing ACC and write my own software to replace the EMCO WinNc software. I can write the CNC software, no problem there, what I don't have is any clue as to what the command strings and structure looks like across the ethernet connection.

So before I sit down and write a port sniffer, I thought I would ask if anyone has the command documentation.

Or do I just rip out the ACC and install a new controller and my software.

Bump. anyone?

Search for a paper titled: Intelligent Control Software for
Industrial CNC Machines

They have reverse engineered one part of the puzzle which may or may not be of any use.

I'm in the same boat right now, picking up another emco.

Thank you :)

After looking more at that paper it may be of little use, but I've found a few more resources:
1. a paper called: An Adaptive STEP-NC Interpreter for Feature-Based Machining on EMCO Mill ? by He, Pingzeshi (ResearchSpace@Auckland, 2014). I am trying to get ahold of this one now.
2. CrossNConnect here: CrossNConnect download | SourceForge.net
3. another paper titled "STEP-NC feature based EMCO mill by Bins Jo Pappachan

I'm working on getting the papers from the university of aukland.

No luck on geting those papers, yet.

It seems we should be able to use a packet sniffer like wire shark (Here: Wireshark · Go Deep.) and get some info on what's getting sent between the PC and the machine controller. The packets should have enough info to tell us where it's coming from and where it's going.

So the machine and PC only send two packets back and forth while idling, identical each time, as far I can tell. I've attached the wireshark capture. I renamed the file extension as a .txt file so the forum would accept it as an upload. To read it with wireshark, you'll have to remove the .txt extension and put the period between emco and pcap.

No idea how we'd figure out how to control it though. Personally, i'd put an arduino, pi, or something else monitoring the stepper motor signals so I could know what packet gets sent to the machine to enable one axis to step. The monitoring device would send out it's own signal when the stepper motor board got its step signal, in essence to mark the packet that gets sent right before the motor steps.

The two packets copied as printable text are:

(º/{nàô-E(ú@@ª¿À¨
ˬ
bÀ'}}À#P?ì

and


àô-(º/{nE(@À¨
ˬ
À'b}}À$P

other info:

93 33.002582 192.168.10.12 192.168.10.20 TCP 60 [TCP Dup ACK 1#1] 1122 ? 49191 [ACK] Seq=1 Ack=1 Win=1925 Len=0

94 33.002628 192.168.10.20 192.168.10.12 TCP 54 [TCP Dup ACK 2#33] 49191 ? 1122 [ACK] Seq=1 Ack=2 Win=256 Len=0

Looks like something that'd take quite a lot of head scratching. I'm hoping the fellas from the university of Aukland get back to me. From the sound of it, they may have created their own control software for these machines.

That makes my head hurt. :tired:

You have now convinced me that replacing the controller and using my own software is the way to go. That process is pretty easy, about two days of work. The stepper drives are easy to interface.

Right now my machine is sitting up on a pallet rack, maybe I'll drag it down next spring. I need to get another machine off of my floor before I can tackle that project.

I was secretly hoping that there'd be something so simple like G-Code going between the PC and machine. No such luck. I think I'll take a look at how the packets change when homing each axis, individually. If that isn't easy to decipher, I can't think of anything else that would be. I'm kindof leaning towards it not being objectively worth it to reverse engineer it if it's more difficult than dead simple. Financially, selling the ACC / ethernet interface card would net more than enough to buy a mesa ethernet card, for example. Time wise, I have no idea how much time the reverse engineering would take. Likely many times over what it would take to convert to linuxCNC. I'm thinking it might be worth the effort if you had, like, over 10 of these machines.

Yeah, I don't see the value in reverse engineering the original system. It's to easy to just retrofit it with something we have good documentation for. The ACC is actually worth something?

I had been successfully convinced the ACC was highly desirable - by someone selling their machine.

I haven't really thought about it though, people might not be interested in retrofitting it, the ACC controller, to their machines, and it may not break and need replacement, but I did sell the control card from another non ACC machine (rs-422) and it sold for more than a Mesa card.

Its very easy to make programs to that control so why not just use the machine as is?
Use CAM software to feed the machine, then just making parts and not worrying about retrofitted monster that works maybe. Emco made the machines very reliable and they have good documentation for them.
I got electrical and mechanical documents and controller backups from Emco Europe by asking,

TLDR: See the attached file starting with the name machines. This perfectly describes what we need.

While sorting all of my digital files I stumbled upon a manual of the EMCO DNC protocol and noted how it actually described the packets I captured quite well. If you would like to see what I mean by that, you could read the DNC manual and inspect the packets, specifically showing the bytes in hexadecimal and bits, and see the similarities. You'd want to look at the one that describes the protocol in full binary.

I did also discover that EMCO has a lathe that comes with an external control PC, but that you can install a different OS on the ACC card in the lathe and eliminate the control PC entirely with the use of a special control panel, the DigiPanel for the Emcomat 14D etc. This means that the PC in the back of the machine, assuming ours are identical to the one in the lathe, are fully capable of running everything on their own. In theory if we only had a mill version of that software / OS for the lathe, we could throw it on the machine and call it a day (after adding the display and such).

I'm still not set on doing this, but after stumbling on that information I started digging again. I found that someone has done exactly what we want to do here. I havent found their code anywhere though, so still looking.

I've started looking into this a bit further. It seems obvious that linuxcnc should be able to control this machine. The MESA cnc cards use ethernet, for example. Started asking here(link)..


I don't know anything about writing drivers, but the MESA card uses drivers, and not some kindof more direct communication over the network. Oh well. Don't mind to learn about this. LINUXCNC also appears able to control GPIO pins more directly, If we could get the correct configuration for the GPIO pins on the ACC card, we could possibly control directly from there.

Now this file has nothing to do with actually controlling the machine. But, when I installed EMCO software for the display addition to a lathe onto a USB drive and explored the contents (linuxacc) you will see that there is listed in there variables and such that you can look out for to get an idea of what they did at the factory. The file says things like: "Searching sync exceeds 1.5 revolutions", which is a good hint (to me) that I can use a signal from the machine to check position. (NOTE: the 1.5 revolutions notice should only occur during homing, other codes during cutting) In the same file, or somewhere else, it was defined the, what was it called, acceptable error or something on the sync variable. So reading the files could give us an idea about how to use every feature of these machines.


On another front, it may be possible to install linuxcnc and control the machine directly. Not sure, but linuxCNC is capable of using a parallel port card, and the machine controller seems to be on PCIE on the machine controller, the info from a file modules.alias states:

Quote:

---

alias usb:v04D8p0003d*dc*dsc*dp*ic*isc*ip* emcoalias usb:v04D8p0002d*dc*dsc*dp*ic*isc*ip* emco
alias usb:v04D8p0001d*dc*dsc*dp*ic*isc*ip* emco
alias usb:v04D8p0000d*dc*dsc*dp*ic*isc*ip* emco
alias pci:v000010EEd00000300sv*sd*bc*sc*i* acc_module

---

Note: This is also reinforced in the modulespcimap.txt, where it states that

Quote:

---

# pci module vendor device subvendor subdevice class class_mask driver_data
acc_module 0x000010ee 0x00000300 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0

---

in another file, modules.dep, we can see some more interesting things, namely:

Quote:

---

/lib/modules/2.6.24.3/acc/emco.ko: /lib/modules/2.6.24.3/kernel/drivers/usb/core/usbcore.ko/lib/modules/2.6.24.3/acc/acc_module.ko:

---

a file about usb drivers (Pretty sure the machine controller would be over PCI tho, and this is only the input device(s))

Quote:

---

# usb module match_flags idVendor idProduct bcdDevice_lo bcdDevice_hi bDeviceClass bDeviceSubClass bDeviceProtocol bInterfaceClass bInterfaceSubClass bInterfaceProtocol driver_info
emco 0x0003 0x04d8 0x0000 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x0
emco 0x0003 0x04d8 0x0001 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x0
emco 0x0003 0x04d8 0x0002 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x0
emco 0x0003 0x04d8 0x0003 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x0

---

there is a module called acc_module.ko which seems to be all PCI, reinforcing this belief. Now most of these documents are barely readable with my program, notepad++ but there might be much more info in there if they could be decoded differently. But it's a possibility that these files are compiled and we're very lucky to see any text at all? I don't know.

You will need a working setup to know exactly how to talk to your machine, or do some trial and error. Do you have a working control for this machine? Here's what I found (working on controlling now)

During the initialization between the machine and pc, config files are sent from the PC to the machine. These are specific to your machine, and individually adjusted from the factory. They just include things like backlash compensation and such for your individual machine. You can use "generic" (I got them from another machine owner) config files but that would take trial and error. For example, during controlling my machine I accidentally used the wrong config files, and the machine, upon trying to home it, just made noise and did nothing. All of the control parameters are sent from the control pc to the machine at startup, and if they're wrong, the machine won't play nice.

I have my PC set up as in the research paper right now, just doing a man in the middle attack. Contacted one author of the research paper, but since research in this area is very competitive, they aren't forthcoming with their code.

As another area of interest with these machines, editing the config files is super easy. Looking into what features I could add right now.