UDP "Bad_ConfigurationError" but still getting data

Ignition
1

I’m using Ignition 7.9 and trying to communicate with a couple scales over UDP, but I’m consistently getting “PayloadHandlerImpl” logging “Incorrect amount of fields configured” for the device. If I go to the quick client and subscribe to different fields, however, I am able to get the data and the diagnostics all read good while the fields themselves have a “Bad_ConfigurationError” issue:

image
image1412×658 204 KB

If I change the number of fields (despite being fairly certain it’s the right number), then I get a Bad_DataNotAvailable error and don’t get the data anymore.

I’m using the Packet Based message delimiter type, the message delimiter is set to “\r\n”, field count is set to 29, the field delimiter is “,”, and the message buffer size is double the default. We’ve gotten UDP communication working before with nearly identical equipment, just with one field less, and it doesn’t have this error. Not sure why it won’t work for us this time.

Could somebody please give me some ideas about what’s going wrong?

Thanks in advance.

2

Can you get a Wireshark capture of the UDP traffic so we can verify the field count and data is as expected?

3

I’m not too familiar with Wireshark but I’ve attached what we got this morning from trying to do a capture.

Data_Capture.zip (2.1 MB)

4

What are the IP addresses and ports involved here?

5

10.102.1.2 is the Ignition gateway and 10.50.132.194/5 are the scales. The gateway receives data from them on ports 26101 and 26102, and acknowledges them on 26601 and 26602.

If you filter to UDP.port == 26101 or 26102 you can see the data.

6

The device at 10.50.132.194 sends 3 different packets one after the other:

Date/Time,Type,Identity,Name,Number,Ref,Batch Start Time,Batch End Time,Production Minutes(mins),Target Weight(g),Under Weight Tolerance(g),Over Weight Tolerance(g),No. of Weights,No. of Good Weights,No. of Under Weights,No. of Over Weights,No. of Check Weights,No. of Unstable Weights,No. of Over Capacity Weights,Total Weight(g),Total Good Weight(g),Total Under Weight(g),Total Over Weight(g),Average Weight(g),Standard Deviation(g),Giveaway (Sample)(%),Highest Weight(g),Lowest Weight(g),

07:49:34,Sample,SO23017-1-18,09239 TB BROWNIES 12X608G,28,,2021/02/06 12:05,,3,608.0,15.0,30.0,1,1,0,0,0,0,0,604.0,604.0,0.0,0.0,604.0,0.00,-0.6,604.0,604.0,

Checksum=35D4

These drivers can’t handle this irregularity in payload and it’s not surprising you see errors in the logs parsing them.

The drivers expect something like payload #2 to be continually emitted with no variance in field count for formatting.

7

Ah that makes sense, thank you. Can you think of any ways to filter to only packet #2 or is our only option to see if we can get the other device to only send packets like packet #2 via that UDP port?

8

If you can’t get the device to emit only #2 I think you may need to try to acquire the data some other way. Maybe writing some custom Jython networking code, but the lifecycle considerations (where to run it, when to start/stop it) are tricky.

9

We were able to drop packet #3, and since packet #1 at least has the same number of fields, we’re able to get the data into tags now and it views it as good quality. Thanks for the help!

1 Like