Announcement

Collapse
No announcement yet.

SS.maxlen =0 ?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts


  • SS.maxlen =0 ?

    I was trying to use STRPRINT to initialize a SS register to the string "Waiting for data..." and the PLC was throwing a ST140 buffer overflow area, complaining that the string operation was longer than the target string and was truncated. I put the SS register (SS0) in a data view line, and it just says <empty string>. Digging a little bit, it looks like you can look at the maximum possible length a string register can hold by appending .maxlen to the register. I did that, and my dataview is showing 0. SL registers show a maxlen of 256.

    Any ideas on what's going on? Or how to fix it?

    Thanks,
    Brian


  • #2
    That's not good. Your SS0.MaxLen should be 64 for ALL SS. Make sure you are not confusing the .Length value. That CAN be 0.

    If the .MaxLen is 0 (or anything other than 64), you have corrupted image register (user memory). Let us know what you are seeing.
    There are 10 kinds of people in this world, those who know binary, and those who do not.

    Comment



    • #3
      .MaxLen = 0? That's not good and should never happen. There may be ways you can back into it (like a raw memory copy), but if you can duplicate it, I'd really like to see your program.

      Cycling from RUN to PGM to RUN to fix it.

      Comment



      • #4
        It's definitely .MaxLen. And, cycling from RUN>PGM>RUN did not fix it. Nor did a power cycle.

        Today is the first time I noticed it, but the rungs that write to those SS locations don't fire often (only when I'm testing it. The whole thing is on my bench for now, not attached to a machine.)

        Just before I noticed the warning, I was reassigning some modbus registers. I forgot that you can't address MHR0 from the outside, so I was moving about 120 registers down 2 places using the replace function (awesome function, BTW). I have expanded the default MHR range, and have several user created data blocks, so there's been some changes to the memory register, but I never messed with the SS block.

        If you would like the program, I can email it to you.

        Comment



        • #5
          Originally posted by bfitz View Post
          If you would like the program, I can email it to you.
          Please email it to me (support@hosteng.com) & I'll make sure BobO gets it.

          Greg Kiser
          Hos Engineering, Inc.
          support@hosteng.com
          http://forum.hosteng.com
          This isn't all true.

          Comment



          • #6
            Done, thanks!

            Comment



            • #7
              Those fields are initialized during powerup and PGM to RUN, so they are likely being written by something in the program. Will look into it shortly.

              Comment



              • #8
                SS0 and SS1 both start at 64 after power cycle, and immediately change to 0 when entering RUN mode. Cool. Investigating...

                Comment



                • #9
                  In $TopOfScan rung 13 you are doing a MEMCOPY from MHR48-115 and overwriting SS0-1. String are structures that contain the two additional fields (.MaxLen and .Length) in addition to string data, and MEMCOPY is blindly overwriting those fields. If you want to initialize the string from external data use STRPUTB. You'll have to do it for each individually, but it's safe. Another (less recommended) approach is to make sure that your source memory has the internal fields set correctly, but it's best if you use STRPUTB.

                  Comment



                  • #10
                    ...and we are going to add a program check rule to warn that it is almost never right to target strings this way.

                    Comment



                    • #11
                      Oh, oops
                      Well, thanks for finding the problem! MEMCOPY was working well in other areas, so I figured it would target the string areas how I was expecting. I'll get it changed to the other instruction you mentioned. And I'm glad you are adding a warning; I'm sure I'll bump into it in the future

                      Comment



                      • #12
                        Originally posted by bfitz View Post
                        Oh, oops
                        Well, thanks for finding the problem! MEMCOPY was working well in other areas, so I figured it would target the string areas how I was expecting. I'll get it changed to the other instruction you mentioned. And I'm glad you are adding a warning; I'm sure I'll bump into it in the future
                        No worries! It's totally understandable and that's why we're adding the check rule.

                        Comment



                        • #13
                          Well, after I switched the other MEMCOPY instruction I was using for a STRGETB, everything looks like it's working as I expected.

                          Thanks again for the quick response! Support like that is one of the reasons I buy the stuff I do!

                          Comment

                          Working...
                          X