CIP Message General Failure

[Gadelric]

Wizards,

It has been a few, but you all have always done me well.

I have acquired a 1769-L33ER and want to use it as my collection PLC to reduce the lag when collecting data from my older PLCs (1768-ENBT/A.)

Everything with the older PLCs works just fine, they are slow but getting the job done.

My issue is with one of the other 1769-L33ER, and a 5069-L340ER.
The error i get is 16#0000_2107 "General Error"

I've tried to read from the desk PLC to the line plc, and have this error.
Tried writing from the line PLC to the desk PLC, same error.
Sister machine, sitting 10 feet away works just fine.
Ive tried direct IP addressing, and then mapped the line PLC to the desk PLC I/O, same error.


If I message between the two line machines, it works fine, but one of the line machines errors out the message when it messages outside of the room its in.

I don't want to stir up the IT department if I don't have to, is there another way to test?

I can always use the one machine that is able to message the desk PLC and use it as a data collection slave, but I'd rather not if I don't have to.

 

[robertmee]

Can you see both PLCs in RSLinx that you're trying to message between? Both on the same subnet?

Post an image of your message instruction and the Path.

Post an image of the data type tag on the source PLC and the data type tag on the PLC with the Message Instruction. Your error code indicates a mismatch.

You've given far too little information to really be helpful. But this thread might be of use: https://www.plctalk.net/qanda/showthread.php?t=75965

Given the fact you've added the PLC's to the I/O and assuming they are OK (No yellow triangle), I'm guessing data mismatch.

 

[Gadelric]

Mr Robertmee,

You are correct my friend, made test dint in both PLC and it works.
All these machines use the same UDT to track events, Ill dig through it some more...

Thank you for the quick reply.

 

[Gadelric]

message general failure has been dialed down to the UDT.

The main UDT references a Date_Time UDT.
The Date_Time UDT is different between the two machines.
One has the date_time as Dint, the other has them as an INT... same company made them at different plants.... fml...

I attempted to make a completely new UDT in the collection PLC that has the same structure for the array, except the "data types" for "date_time" don't technically match as the names are different, so the same error persists.

Will updating the date_time UDT in the one off machines cause a melt down?
Is there another option?

 

[robertmee]

message general failure has been dialed down to the UDT.

The main UDT references a Date_Time UDT.
The Date_Time UDT is different between the two machines.
One has the date_time as Dint, the other has them as an INT... same company made them at different plants.... fml...

I attempted to make a completely new UDT in the collection PLC that has the same structure for the array, except the "data types" for "date_time" don't technically match as the names are different, so the same error persists.

Will updating the date_time UDT in the one off machines cause a melt down?
Is there another option?

It likely won't cause a melt down, but you'll need to do it offline and download. Cant change data types online.

Usually Date/Time data is queried from the process through the GSV WallClockTime. That requires a DINT array, 7 elements long. So, I'm surprised if they are using that, that they stored the data into an INT. Most anytime I've seen INTs instead of DINTs used are to conform to some HMI requirement or communication device that only accepts INTS. So that would be where I would investigate. But changing from INT to DINT within the processor, shouldn't affect any math. But again, because INTS are two bytes and DINTs are four bytes, would need to check to see if any COP instructions are moving data in/out of those INTS. Changing them to DINTS could screw those instructions up as you are working with half the number of bytes.

 

[Gadelric]

As I tend to be ambitious, I downloaded one of the line programs to my desk PLC, after killing all the io and controller faults, I updated the UDT to include the date/time items.

The only errored routines were associated to the tracking routines.
Ill get the rest of the machines that message correctly to send data and then update the few that are not.

As I have another program that collects this data out of the PLC, I'll have to be careful not to break everything at once...

Be a nerd they said, it will be great they said...

Thanks for your guidance.