No announcement yet.

ASCII over Ethernet on a P2-550

  • Filter
  • Time
  • Show
Clear All
new posts

  • ASCII over Ethernet on a P2-550

    So long story short, I am a fairly green PLC user utilizing a Productivity 2000 to create a system to weigh parts and dispose of the parts that don't make the weight requirement.

    The scale I am connecting to is a Precisa EP 8200D with the slide in ethernet module. It simply outputs a string of ASCII characters when you send it a Print command "PRT,CRLF". The string that the scale return should read "+/-, XXX,.,x, g" with the X's being the weight that it read. I have attached a .pdf of their only documentation on the ethernet module in case that would be handy. And since I can't get the link to work if you search "Precisa 360 EP Balance" and scroll down the user manual can be found there.

    Since the scale was purchased with the ethernet module in it I had to create a custom ethernet protocol. This allowed me to read the raw string of ASCII characters because the ASCII IN and ASCII OUT commands only work for serial communication. After establishing communication I finally started sending and receiving data. Sometimes the data comes through the way it is supposed to ex: "+ 126.7 g", but there have been many instances where it does not come through even close to that.
    For example I have seen it come across as the following strings:
    ".7 +126"
    "126.7 g g"
    " +126.7 g"
    "+ 126.7.7 g"

    BUT when I monitor the scale data from Putty every single string of data reads "+ 126.7 g" or whatever weight the display is reading at the time. I cannot get any of the variations that I see on the PLC side to populate on the Putty screen. I believe this is telling me the PLC is manipulating the data differently? Also any idea where the extra characters could possibly be coming from?

    I'm hoping someone has some sort of insight as to what's going on. I apologize if anything needs more clarity, just let me know.

    Thanks in advance
    Attached Files

  • #2
    How is your CPE instruction(s) setup?
    I assume you are using a String tag, how many characters is the string set to?
    Does the scale always send the same number of characters?
    From your examples could it send 10 characters one time and then 7 the next leaving some of the characters in the string from the previous reading?
    Have you tried clearing your string tag before doing a CPE Receive?
    Did you setup and are you monitoring the status tags of the Ethernet device in hardware config?
    Is the device responding more than once per request? ( Messages received status tag) ( Pending Input Messages status tag)
    Is the input queue overflowing? ( Input Queue overflow status tag)


    • #3
      Thanks for reaching out Techme! Here are my CPE receive and CPE send commands respectively. With "Weight Value" being a string of 128 characters because AD said that has sometimes alleviated customers issues. Then "Weight Trigger is the default of 15 characters containing "PRT0x0D0A" with the Hex being a CRLF.

      Click image for larger version

Name:	Capture2.JPG
Views:	286
Size:	57.2 KB
ID:	122967Click image for larger version

Name:	Capture3.JPG
Views:	255
Size:	57.3 KB
ID:	122968

      I should have probably thought about clearing the string before trying to receive a new one, but sometimes it's easy to slip up and forget something like that. After I implemented that it seemed to throw out the gross errors. I do believe there must have been characters left behind. That being said though it is still not 100% working. Now sometimes it will flash "+126" then ".7 g" and the ".7 g" will stay. It's almost like it gets half of the data and then sends the clear string command which I know it's not.

      Also no messages pending for me, and the Quene Overflow is not checked so I think I am good there now.

      Attached Files


      • #4
        How are you clearing the string? It sounds like you may be clearing it in the middle of receiving a message sometimes.


        • #5
          That's what I was thinking as well. At the time being I am just using a push button to clear it. And it seems to do it even when I cycle the weighing and clearing slowly. I'll have to check my hardware tomorrow, perhaps a bad pushbutton.


          • #6
            other things to look at are:

            Make sure you are only triggering the receive once. Just because the complete happens does not mean it will not receive on top of what has already been received and the complete bit will turn on as soon as it receives a single character. You may use the complete bit to keep the instruction from happening more than once. You will have to reset it with logic.

            You can use the messages requested and messages received status tags to make sure you receive a response to each request. The message requested will increment each time a request is sent and then you can enable the receive and when the messages received = messages requested it should have received the information.

            Basically this is a "Custom Protocol" so you have to build in the checks to make sure you receive a response for each request and only once.


            • #7
              Thanks a lot. I've been working on another project and now just sitting back down with this scale. Not quite there yet but headed in the right direction for sure.

              I've written a short program using only some logic and the CPE commands. I believe according to my logic I should be sending only one time and receiving only one time. But I am still having issues with it only populating either the whole number or the decimal part of the weight once in a while not both.

              My message sent status always seems to increase by one when I make the statement true, but my message received status will sometimes go up by 1 and sometimes go up by 2, thus putting data in the message pending status. It's almost like somewhere in the time between the scale being triggered to reading the data the weight sometimes gets broken into 2 chunks of data? This doesn't seem possible but I'm not that familiar with ethernet protocol (Probably why I'm having problems).

              I have attached the latter just to see if it makes any sense or not. Ignore the tags, when i made a new program I used the same tag database as my program, the first input simply clears whatever data is in the string. Then the second input starts the command to send the trigger then receive the weight. I also tried to put a timer after the sent was complete to see if it was a timing issue, but the results didn't change.

              My initial major problem was not clearing the data after I received it. Now that problem is fixed I wonder if it might be a setting in the scale.

              Any insight is appreciated, always good to have another set of eyes.

              Click image for larger version

Name:	Ladder1.JPG
Views:	294
Size:	73.6 KB
ID:	123155Click image for larger version

Name:	Ladder2.JPG
Views:	212
Size:	36.0 KB
ID:	123156


              • #8
                It does sound as if you are receiving multiple packets. This is likely due to the Serial to ethernet conversion from the scale. It looks like your second packet is overwriting your first So you receive "+126" in the first message and then ".7 g" in the second. Since you are receiving to the same tag the second is overwriting the first.

                Is there a way to specify a termination character or a specific "Number of digits" from the scale?
                Does the scale always send the same number of characters?

                Have you done a send and then not enabled the receive CPE and see how many pending messages are in the "Pending Input Messages" tag of the device? This would tell you how many the plc is getting back each time the request is made.
                Last edited by techme; 06-04-2019, 04:08 PM.


                • #9
                  Monitor the packets (Wireshark maybe) to see what's going on



                  • #10
                    Hello again,

                    techme and bcarlton, thank you. I was using the PLC to try to look at sent, received, and pending messages. This was showing that as you said I was receiving 2 separate packets sometimes, but not always. Which means the second piece of data is overwriting the first. I confirmed that today after figuring out how Wireshark works, and per one Print command sometimes it receives one packet back, but sometimes two. This seems to be inconsistent and I can't seem to trend a pattern to why it sometimes sends one and sometimes two.

                    I do not believe you can specify a termination character from the scale as far as I know. When sending 1 packet of data it seems to be consistently 8 characters. I will have to look closer in Wireshark to see if when it's broken into 2 data packets if they are consistent or not. The local scale rep is coming into the shop today so I have a list of questions to ask him. I'm hoping he can tell me why the data would be coming in two packets instead of one and we can work to fix it.

                    If not, I am trying to think of a workaround. I believe I'll have to do something along the lines of read it, see how long the string is, store it in a buffer, then when the second packet comes to overwrite the first I'll have to take that piece of data then marry the two up before I can do my compare. Seems more complex than it should be, but you gotta do what you gotta do.

                    Will try to post again this afternoon after meeting with the scale guy.


                    • #11
                      Did you see the post to the guy working with you? If you do this it will append the messages into a string. Once you have completed the step in the process you can then clear the string and it will wait until there are pending messages again and build another string.

                      Last edited by techme; 06-10-2019, 01:50 PM.


                      • #12
                        I saw it briefly, but didn't look closely. That would make sense to at least give it a shot. Going to try that first thing tomorrow to see if that can get some of the bugs worked out.

                        When the scale guy came in, he didn't know much about the internals of the scale but he did think it was strange that the information would sometimes split into two packets and other times it would only come though as one. After being on the phone with another person who was supposed to be a little more technical and that going no where. He decided he going to contact someone higher up to see why it would be outputting things in this manner.

                        But if that line of code that you wrote above works I will be ecstatic.

                        Thanks once again


                        • #13
                          Still not getting anything to come to fruition. The scale people came back and basically said if it works on putty you should have no problem getting it to work and basically said my wireshark analysis didn't mean anything. Typical vendor where nothing can be wrong with their product..

                          Techme, you asked about a termination character earlier. I didn't see anywhere in the software to add one and the scale guy knew nothing about it. But under further expection of the wireshark data as pictured below, it seems the scale sends a CRLF after the data is all in tact. So there isn't one on the first packet, yet there's one at the end of the second packet. And there is always one if the data does come through as one packet.

                          1st split packet
                          Click image for larger version

Name:	Split Data_1_AD.JPG
Views:	181
Size:	86.5 KB
ID:	123356
                          2nd split packet
                          Click image for larger version

Name:	Split Data_2_AD.JPG
Views:	171
Size:	87.5 KB
ID:	123357
                          All in one packet

                          Click image for larger version

Name:	GoodScaleData_AD.JPG
Views:	168
Size:	116.0 KB
ID:	123358

                          I know the receive should be only happen once, but is there a way to hold that connection open until it gets that CRLF? Or would something like that still overwrite the first packet, I need a way to pair up the packets before the data.

                          The way that was suggested would work if the problem was how my coworker described, but it is not sending more data than it is receiving. The problem is it sends once, but receives 2 packets and the first packet the "126" flashes on the screen, but gets overwritten by the ".4" almost immediately.

                          I feel like I'm almost out of hair to pull out of my head staring at this thing!


                          • #14
                            So the BIG question is still:

                            When you send a request to the scale and DO NOT enable the CPE Receive, what does the messages pending tag show? From what your are seeing in the wire shark I would think you would see the pending messages tag be "1" sometimes and "2" sometimes.

                            You should be able to use the logic I posted earlier whether it is 1 message or 2. I think it will add the termination code, but it should still pack the messages in the string. What does it do when you tried this logic? Can you post how you put this logic in the code? Make sure you are not clearing the string between messages. (Only after the entire string has been received.) Can you post logic how you are clearing the string that is put together in the logic I provided. I have simulated your scenario and it works here.

                            I know the receive should be only happen once, but is there a way to hold that connection open until it gets that CRLF?
                            The receive is staying on and receiving both messages. If it were not the data would not be getting written over. The wireshark proves that there is more than one message or packet being sent. You just have to handle the data coming in so that it packs it into a string correctly. This is what the logic I gave an example of does. Make sure in logic you are not clearing the string within the scan between the reads. (So make sure you DO NOT read the temp string, pack into the final string, then clear the final string in other parts of the logic before reading the next message.)
                            Last edited by techme; 06-12-2019, 03:49 PM.


                            • #15
                              You are correct, sometimes the pending message is 1 and sometimes it is 2. I thought I had implemented your code previously, but due to negligence on my side it didn't work the way it was intended. I went over it again today and changed it to how it should be, and now appears to be handling the data properly.

                              Right now I am simply using a fiber cable to clear the tag values back to zero, it works for this purpose, but I will now need to sit down and think out the logic for the machine to be able to only send 1 clear after the data is taken.

                              Apologies for the misunderstanding, I think we are on the same page now! I will post again if I run into any hiccups.