Micro850 - MSG_CIPSYMBOLIC

[Cyanogen]

I have 2 Micro850 PLCs that I am working on that use MSG_CIPSYMBOLIC blocks to transfer data back and forth. Or at least they were...

Basically the project was a simple IP address change on each controller to add them to a different network. After changing the IP address on the controllers, and inside the MSG_CIPSYMBOLIC block, the program no longer functioned.

I've checked network cabling, IP addresses on the controllers, and inside the MSG_CIPSYMBOLIC blocks, and everything looks correct. Rockwell Automation has been less than helpful, and won't return calls/emails so hopefully you guys could point me in the right direction.

I don't mind getting someone on an hourly support gig if needed, just need to work this problem out.

 

[drbitboy]

Obvious stuff:


You already did this, probably, but have someone else look at the IP address settings; perhaps there is a typo you are not seeing, because you are seeing what it should be and not what it is.


Can you look at network traffic with Wireshark or similar?


Was it only the MSG_CIPSYMBOLIC instructions that no longer work?


Can you upload the program to ensure the new IP addresses are in the programs that are actually running?

 

[Cyanogen]

A few weeks ago (one of the only times I could get Allen-Bradley on the phone) they remoted into my machine and double checked the IP addresses and told me they looked fine.

It's only the MSG_CIPSYMBOLIC instruction that no longer works. Everything else seems to be functioning as intended.

I have uploaded the programs from the controllers, and the correct IP addresses are in the programs.

Here are the programs in question:

https://drive.google.com/drive/folders/1BgRHgDNNXCMS2EIiMgVNYlpBoWZm1pYA?usp=sharing

 

[drbitboy]

Do you have copies of the original programs, the ones that worked?


The IP addresses look good to me. One of those programs has two message instructions; I assume that is an attempt to debug?


The elements have the following values:

• CL2
  • CommsSymCfg.Service := 1 (Write)
  • CommsSymCfg.DataType := 200 (UDINT cf. here)
  • CommsSymCfg.Symbol := 'CommsDataOut'
  • CommsSymCfg.Count := 5
  • The Data buffer input to the instruction is
    • CommsData
      • a USINT array [1..10]
• LAS
  • CommsSymCfg.Service := 0 (Read)
  • CommsSymCfg.DataType := 200 (UDINT cf. here)
  • CommsSymCfg.Symbol := 'CommsDataOut'
  • CommsSymCfg.Count := 5
  • The Data buffer input to the instruction is
    • ComData
      • a USINT array [1..10]

So the .DataType and .Count values are 200 and 5 in both programs, indicating five UDINTs for a bytecount of 20 (=5 x 4), but the Data buffers are only 10 bytes long. Could that be a problem?

 

[Cyanogen]

Here are the original programs.

Rockwell automation support actually changed the data type to 200 when they remoted into my machine.


Here are the original programs

https://drive.google.com/drive/folders/10i5XLVyKNc7LI6ZoQIHebA1fh1qNwEh_?usp=sharing

 

[drbitboy]

Here are the original programs.

Rockwell automation support actually changed the data type to 200 when they remoted into my machine.


Here are the original programs

https://drive.google.com/drive/folders/10i5XLVyKNc7LI6ZoQIHebA1fh1qNwEh_?usp=sharing

What was the data type before?


Those original programs have no values assigned in some of the CommsSymCfg and CommsTargetCfg structures; how did they work?

 

[Cyanogen]

The original symbol data type was 198.

This is what is confusing me... The facility maintenance swears these systems were working, and I believe them because the chemical feed was working on the trending section of their SCADA system.

This is my first time working on a project through Connected Components Workbench, so I'm not sure if I made a mistake in uploading from the controller because the LAS program has the MSG_CIPSYMBOLIC parameters in it, but the CL2 program does not.

Any advice or tips would be greatly appreciated!