[michaelwoodcock]

So the code and captured data is attached. I'm working on everything like this: (forgive me for the cheesy file names)

1. Raw data capture using the test.py file. This just saves all data for analysis

2. packet match finder works.py. This will listen to the network continuously and print and save to a text file all of the repeated payloads. (remember: the other packet data is ignored, since it changes every time) The trick here is to initialize the machine two times, then you can see all of the packets that are sent to the machine to initialize it more easily.

3. replicatetraffic.py: This file is intended to have a list of all packets to send to the machine and send them after receiving the prerequisite packet from the machine, also stored in a list from previous analysis. Note: Will have to add the keep alive packet function somewhere


4. (Coming after mastering the above) control.py: This file will work with the initiated machine and dispatch commands. It will read the received packets for the simple data such as position ackowledgement and machine status.

Curious if anyone has any experience with this or thoughts on how to proceed. I'm going to dig deeper into packets to finalize my code to initialize the machine, then move onto other things if I can get the initialization down.

I've fooled around with reading the packets to and from the machine, finding the patterns for the initialization process, and working out the differences. The payloads of the TCP packets are identical each time.

To control the machine seems do-able, but it requires some lazy coding since I have no idea what all of the data during the initialization process really means. A lot of it is concise, but there's huge swaths that are not.

My plan was just to use my packet captures and send the raw data from the control PC to the machine to initialize it without completely understanding what it is and does. The only thing that should matter, is that it is the exact same payload every time, and I can replicate it, or at least I think.

If this assumption is correct, it would mean that I need to figure out the rest of the stuff about the packets. The payload is identical each time during initialization, but the other details around the packet are not. We're talking things like headers, I guess. I don't know all that there is to know about packets yet. Only ever messed with packet payloads.

[Fish4]

I’m looking for a help for Kuraki CNC horizontal 4 axis machine with the Fanuc 15 M controller. The problem is when I turn on the ( main power) breaker it gives me emergency on screen before I move all the X axis to the origin or home. I have to press the button of E, without removing the emergency from the screen. You cannot do any kind of controller or active any kind of button so if you guys anything you know about this help me.

[michaelwoodcock]

Hey sorry about your troubles with the machine. This isn't the best place for advice on that machine, as many in the EMCO section may know nothing about how the system works. My EMCO machine, for example, only seems to emulate the fanuc control, it doesn't actually seem to use it for anything else. However, in my research, I came across some fanuc stuff by the name of fanuc focas. It may be able to tell you more about your machine. I can't remember how and where I got the software, but it didn't work for me as the EMCO machines seem to communicate a different way. You would still need a way to hook it up to your machine, (hopefully you have an exposed ethernet port somewhere) and that's assuming it's compatible. Again, I have no idea, it didn't work on my machine.

Back to EMCO and some interesting tidbits:
On initialization, we can capture and recreate two files that the control pc sends to the backend. These are a .msd file, and a .awl file.

The .awl file would suggest that the EMCO machines utilize a siemens protocol for communication, S7COMM. However, there is a free program that should be capable of initializing the machine if this were the case: awlsim. I can confirm that it does not initialize the machine. It must have something to do with the fact that the .msd file is sent first, and not an .awl file like the siemens system would use natively.

This is interesting as it seems to indicate that:
1. the MSD file is merely for the communication from the front end to the back end pc (supported by the fact that EMCO distributes the .msd file inside a zip folder called machine, and inside a subfolder labeled ACC_MSD)
2. the AWL file seems to be controlling the machine more directly (this seems supported by the fact that this file is located in a folder named PLC). It's possible that this file is how the linux system on the backend pc communicates with the rest of the machine. What's more, I recognize this file from fooling around with another EMCO mill, and I've attached a translated PDF version from the pc mill 50.

The AWL file seems very useful. It gives the pinout of the entire machine so even if you decided to retrofit controls you could use it for wiring info.

Still have not started cutting with this machine, which is when I'll hopefully be able to sniff out the rest of the communication. My circuit for the machine is overloaded, and the breaker for the circuit trips when I run a program from the mill. So far I can only jog around and stuff.

Hoping someone knows something about how the files interact. I could only find that siemens uses the .awl files, but not .msd files. Maybe there's some info out there. Fingers crossed.

[michaelwoodcock]

Not sure how I missed this, but reading back the response from the machine during initialization is feasible. There are some random hurdles though. More on that later. Here's an example of the data sent back from the mill, it should be easy to write a program that reads and uses this data:

Timestamp: 2023-07-08_18-25-06
TCP Packet: 192.168.10.12 --> 192.168.10.20
Raw Content: b'i:5.618: 6: p= 20c18 l= 10 SW_VERSION : 46 31 43 4c 36 30 31 36 0 0 0 0 0 0 0 0\r\ni:5.618: 18: p= 0 l= 0 MSD_SIM_STATE :\r\ni:5.619: 15: p= 1 l= 0 START_INIT :\r\ni:5.619: 83f: p= 0 l= 10 AXIS_CONFIG : 0 1 2 ff ff ff 3 ff ff ff ff ff ff ff ff ff\r\ni:5.619: 856: p= ff0000 l= 4 SPINDEL_CONFIG : c ff ff ff\r\ni:5.619: 859: p= 0 l= 0 TRANSFORM_INFO :\r\ni:5.619: 83a: p=ffff0000 l= 0 AXIS_INFO :\r\ni:5.619: 83b: p= 70000 l= 0 REFERENC'


Timestamp: 2023-07-08_18-25-06
TCP Packet: 192.168.10.12 --> 192.168.10.20
Raw Content: b'E_INFO :\r\ni:5.619: 824: p= 0 l= 80 SW_END_MIN : ee a6 5e 2e 17 ae b8 3f 7b 14 ae 47 e1 7a 64 3f fc a9 f1 d2 4d 62 a0 3f 0 0 0 0 0 c0\r\ni:5.619: 825: p= 0 l= 80 SW_END_MAX : 3b df 4f 8d 97 6e d2 3f 52 b8 1e 85 eb 51 c0 3f 25 6 81 95 43 8b cc 3f 0 0 0 0 0 c0\r\ni:5.619: 827: p= 0 l= 80 REF_POINTS : 4f 4 71 1e 4e 60 d2 3f 3d f ee ce da 6d bb 3f af 94 65 88 63 5d cc 3f 0 0 0 0 0 0\r\ni:5.619: 819: p= 0 l= 4 MAX_GEAR : 0 0 0 0\r\ni:5.619: '


Timestamp: 2023-07-08_18-25-06
TCP Packet: 192.168.10.12 --> 192.168.10.20
Raw Content: b'819: p= 0 l= 4 MAX_GEAR : 1 0 0 0\r\ni:5.620: 819: p= 0 l= 4 MAX_GEAR : 2 0 0 0\r\ni:5.620: 819: p= 0 l= 4 MAX_GEAR : 6 0 0 0\r\ni:5.620: 80d: p= 0 l= 4 ACT_GEAR : 0 0 0 0\r\ni:5.620: 80d: p= 0 l= 4 ACT_GEAR : 1 0 0 0\r\ni:5.620: 80d: p= 0 l= 4 ACT_GEAR : 2 0 0 0\r\ni:5.620: 80d: p= 0 l= 4 ACT_GEAR : 6 0 0 0\r\ni:5.620: 833: p= 3000000 l= 10 LIMIT_SPEEDS_ACT : 26 e4 83 9e cd aa a 40 4c 37 89 41 60 d5 44 40\r\ni:5.620: 81b: p= 3000000 l= 10 LIMIT_SPEEDS : 26 e4 83 9e cd aa a 40 4c 37 89 41 60 d5 44 40\r\ni:5.620: 80d: p= 0 l= 4 ACT_GEAR : 6 0 0 0\r\ni:5.620: 811: p= 0 l= 8 LIMIT_SPEED : 4c 37 89 41 60 d5 44 40\r\ni:5.620: 81a: p= 0 l= 20 MAX_FEEDS : 19 1f 66 2f db 4e 8b 3f 19 1f 66 2f db 4e 8b 3f 49 9f 56 d1 1f 9a 89 3f 7b 14 ae 47 e1 7a\r\ni:5.621: 821: p= 0 l= 0 SPINDLE_ENCODER :\r\ni:5.621: 84e: p= 0 l= 0 S0_ENCODER :\r\ni:5.621: 81c: p= 0 l= 0 SPINDLESTATE :\r\ni:5.621: 842: p= 0 l= 0 SPINDLESTATE_0 :\r\ni:5.621: 843: p= 0 l= 0 SPINDLESTATE_1 :\r\ni:5.621: 844: p= 0 l= 0 SPINDLESTATE_2 :\r\ni:5.621: 845: p= 0 l= 0 SPINDLESTATE_3 :\r\ni:5.621: 815: p= 0 l= 0 SONDERBETRIEB :\r\ni:5.621: 814: p= 10000 l= 0 EINLESE_FREIGABE :\r\ni:5.621: 812: p= 10000 l= 0 ACHS_FREIGABE :\r\ni:5.621: 813: p= '

I found some very random road blocks though that would require me to simply do some dumb workarounds. For example, upon the PC sending the config files to the backend pc, we get this:

Timestamp: 2023-07-08_18-26-53TCP Packet: 192.168.10.20 --> 192.168.10.12
Raw Content: b'BX 100.4\r\nUN DB10.DBX 100.1\r\nUN DB10.DBX 100.2\r\nU DB10.DBX 2.0\r\nUN M 2.0\r\n= M 52.5\r\nU M 52.5\r\nCC FC 51\r\nU M 52.5\r\nCC FC 50\r\nU M 200.0\r\nU DB10.DBX 100.0\r\nCC FC 49\r\nCALL FC 12\r\nCALL FC 13\r\nU M 300.0\r\nCC FC 75\r\nO DB1.DBX 1370.2\r\nO DB1.DBX 1370.3\r\nO DB2.DBX 1.1\r\nR M 300.0\r\nR M 400.0\r\nR M 400.1\r\nCALL FC 62\r\nCALL FC 63\r\nCALL FC 41\r\nU DB10.DBX 2.0\r\nCC FC 65\r\nCALL FC 35\r\nU DB25.DBX 332.0\r\nR DB25.DBX 332.0\r\nEND_ORGANIZATION_BLOCK\r\n'


Timestamp: 2023-07-08_18-26-53
TCP Packet: 192.168.10.20 --> 192.168.10.12
Raw Content: b'\x02@\xb4\x01\x00\x00\x00\x00C:\\WinNC32\\\x00\x 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00C:\\WINNC3 2\\MILL55\\\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00MILL55\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xf f\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00'

For one, I am not sure why on earth the winnc32, mill55, x00mill55 are thrown in there randomely. I am hoping that merely playing back these same packets during my initialization that everything works out ok. I can send the two files programmatically, but understanding why those strings are randomly thrown in where they are is beyond me.