Can we get the symbol name through the PLC address?

[NecoMai]

Hi drunsinn Our customer have one HERMLE C42U and one GROB G552 with HEIDENHAIN TNC640 NC system.

       Hermle had changed PLC password, but the Grob never.

       I had used the 'foolish' method to find the value which is shown on the screen when the spindle work. 

       The python program is ok and we can get all the value in the PLC. I write a few code as below:

      '''
      for num in range(0, 22000, 4):
         print('{}'.format(num), end='')
         print(con.read_plc_memory(address=num, mem_type=pyLSV2.MemoryType.DWORD, count=1), end='')
         print('\t', end='')
         if num % 40 == 0:
             print('')
      '''

      I had found that the value also has a symbol name at the same time. Can we get the PLC value and the symbol name at the same time? 

      That is an example : D4448: APICHN[0].NN_CHNCONTOURFEED and D39096 STG_SPINDELKOMP.DG_SPINDELDREHZAHL

      First, I want to get the symbol name through the PLC address.

      And the second, I get the PLC address value through the symbol name.

      Thank you very much!

[drunsinn]

Hello @NecoMai,

after looking into this i am sorry to say that I have found no better way to map the symbol name to the address or vice versa via LSV2.

The technical manual also doesn't have a list but talks about not mixing both address types in the plc program. I think the compilation of the plc program works in the same way when you compile a C program. Every symbol gets automatically mapped to a memory location during compilation. If you change something in the plc program the address might also change.

BTW: I am currently working on a rewrite of pyLSV2 for version 1.0. I want to use some functions from newer python version than 3.4. Can you check if you have the packages dataclass, enum and typing are available in ironpython? Those packages have been backported to older version of python since their introduction in python 3.6 and 3.7.

[NecoMai]

Hi Drunsinn Thanks for your reply.

     I can't find the package dataclasses(dataclass) and typing in ironpython but can find them in python 3.8. 
     You can get the latest ironpython version(src files) from the website as below:
     [https://codeload.github.com/IronLanguages/ironpython3/zip/refs/tags/v3.4.0-beta1](url)

     BTW, only phthon 3.5 or later can be supported in  PyCharm Community. 

[NecoMai]

Hi Drunsinn:

When I want to read the string in the plc: print(con.read_plc_memory(address=1, mem_type=pyLSV2.MemoryType.STRING, count=300))

It throw the error message: Traceback (most recent call last): File "E:/pyLSV2-master/JCTest.py", line 27, in print(con.read_plc_memory(address=1, mem_type=pyLSV2.MemoryType.STRING, count=300)) File "E:\pyLSV2-master\pyLSV2\client.py", line 1110, in read_plc_memory raise Exception("maximum number of values is %d" % max_count) Exception: maximum number of values is 200

I modified the maximum count to 200: print(con.read_plc_memory(address=1, mem_type=pyLSV2.MemoryType.STRING, count=200))

It throw the error message again: Error message: Traceback (most recent call last): File "E:/pyLSV2-master/JCTest.py", line 27, in print(con.read_plc_memory(address=1, mem_type=pyLSV2.MemoryType.STRING, count=200)) File "E:\pyLSV2-master\pyLSV2\client.py", line 1130, in read_plc_memory struct.unpack(unpack_string, result)[0] struct.error: unpack requires a buffer of 240 bytes

Not enough buffers?

I can see the string in the NC system as below: Line 1: xxxxxxx Line 2: xxxxxxx ..... etc

How can I read the string in Line 40? What is the address? 40 ?

Thanks very much!

[drunsinn]

Hello @NecoMai,

The maximum count of available strings is part or the system parameters. You get the number by reading con.get_system_parameter()['Strings'].

Everything in PLC memory is addressed starting at address 0. This is probably also the reason you are getting the second error message. You are starting at address 1 while reading 200 strings. The last string would therefore be at address 201 which doesn't exist.

Could you try the following code? This should fix your problem. print(con.read_plc_memory(address=0, mem_type=pyLSV2.MemoryType.STRING, count=con.get_system_parameter()['Strings']))

The code for decoding the values returned from the control isn't very good, it has no functionality for coping with errors returns from the control. This definitely has to be addresses for a 1.0 release. Thanks for bringing this to my attention!

[NecoMai]

Hi Drunsinn:

print(con.read_plc_memory(address=1, mem_type=pyLSV2.MemoryType.STRING, count=con.get_system_parameter()['Strings'])) When I run the above code, the system reports an error: Traceback (most recent call last): File "E:/pyLSV2-master/JCTest.py", line 17, in print(con.read_plc_memory(address=1, mem_type=pyLSV2.MemoryType.STRING, count=maxcnt)) File "E:\pyLSV2-master\pyLSV2\client.py", line 1130, in read_plc_memory struct.unpack(unpack_string, result)[0] struct.error: unpack requires a buffer of 240 bytes

The error message shows that the buffer is less than 240bytes Thanks very much!

[drunsinn]

Hello @NecoMai, to be honest I can't quite figure out what exactly is happening in your case. I have made some improvements in the branch https://github.com/drunsinn/pyLSV2/tree/rework_plc_data_read. Can you take a look and try if something changes?

This branch also has a improvement in regards to the problem with the limit of reading a maximum number of 255 elements at a time. Now it should be possible to read the complete memory in one go.

[NecoMai]

Hi Drunsinn: I am so depressed about the Heidenhain nc system. When I ping the C42U and Grob, I find that the network is intermittent and there is no rule. Would you help me to have a test for the other Heidenhain nc system? I get the network status in the nc system as below:

[drunsinn]

I am no expert on networking problems, all I can do is tell you what came to mind.

As far as I understand the article on wikipedia regarding package loss a dropped package could happen because the network was to busy or because of a checksum error.

Here are some things you could check to see where the problem is coming from.

Can you identify if the count of dropped packets only increases when you use pyLSV2? Try using different applications and protocols to send and receive data from the control. If you can narrow it down to pyLSV2 something in the way the socket is used isn't correct and has to be changed. If packages are dropped no matter wich type of transfer (file share, TNCremo, ..) it might be either a problem with the controller or the network itself.

The next step would be to check if these problems also happen when you connect directly to the machine with a known good network cable? A friend of mine had a case of strange behavior because of a damaged cable. The same goes for the network switch. If you have a free port on the switch you could plug the machine into the free port to check if this changes anything. You could also try to switch the ports of the two machines.

If non of these steps bring up anything the fault might be in the control itself. There are two ethernet ports on the control, X26 and X116. X26 is the 'main' network port for connecting to the network, X116 is used for equipment that is part of the machine itself. One of our machines uses X116 for a IP camera. Configuring X116 requires the PLC password. If X116 is not in use on the machine and you have the PLC password for it you could switch the connections and settings around. If the dropped packages go away something with the ethernet chip on the control might be broken.

Another way to check if the network is at fault 'listen' to all the network traffic using Wireshark. I haven't done this myself but there is a good explanation on how this can be achieved in the Wireshark manual: machine in the middle. This would indicate if the packages get corrupted bevor or after they arrive at the machine.

Again, I am not an expert! Take these points with a grain of salt. These are just some ideas I and a friend of mine came up with to narrow down where exactly the problem might be.

[NecoMai]

Hi Drunsinn: Thank you all the same. I had found the reason of packages loss. I am very sorry that I forgot to cancel my questions.