Announcement

Collapse
No announcement yet.

Help with PRINT command

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


  • Help with PRINT command

    Using a D2-260 and trying to print the following out port2
    "%$$EW&e=54&male=" V14777%0 "&evtext1=" V15057%0 "&evtext2=Minitube&evdatetime1=" V15217%0 "&evdecimal3=" V15117%0

    Not sure why, but it stops printing after V14777 prints out the correct data. Any ideas?
    FYI Sending to a datamax printer for QR code.


  • #2
    Find a big enough chunk of free V memory for a large text buffer, and use VPRINT/PRINTV. You can then at least see what you are actually sending out the port from the PLC side using a Data View. That may point you to something.
    There are 10 kinds of people in this world, those who know binary, and those who do not.

    Comment



    • #3
      I does print using VPRINT, but it is missing the "&" character in all locations

      Comment



      • #4
        So the packets start like
        %$EWe=54male=
        ?
        Not sure why that would affect the PRINTV, but there's something strange going on regardless. Hmmm...
        There are 10 kinds of people in this world, those who know binary, and those who do not.

        Comment



        • #5
          Yes, that's what I am seeing. V14777=10 and V15000=1234567890
          %$EWe=54male=1234567890 and the m is underlined

          The e is underlined in the rest of the text, too. (&e)

          Comment



          • #6
            I have the first part printing correctly.
            changed
            "%$$EW&e=54&male=" V14777%0 to
            "%$$EW&e=54" "&" "male=" V14777%0

            Seems to want the & character kept seperate. Now to figure out why the rest of the string is not printing. Maybe because it starts with &e ?
            Last edited by commander; 11-19-2019, 11:34 AM.

            Comment



            • #7
              Originally posted by commander View Post
              and the m is underlined
              Ha! That is critical. The Underline means it was preceded with an &. The DrawText Windows API function says &m is displayed as m. It's how programmers designate accelerator keys in menus. That should NOT be done by the status display - & is &, not a Windows drawing escape sequence. That's in Data View?

              You might instead look at the V data in BCD/Hex (instead of text) in Data View. Take a screen shot of the whole thing (as many rows will fit on your screen) and post the screen shot.

              There are 10 kinds of people in this world, those who know binary, and those who do not.

              Comment



              • #8
                PRINT command.docxI created a text entry object to enter the string data and put it into V15600%16. that part prints ok and so does V14777%0 but nothing afterwords prints

                Comment



                • #9
                  Originally posted by franji1 View Post

                  Ha! That is critical. The Underline means it was preceded with an &. The DrawText Windows API function says &m is displayed as m.
                  MmmmHmm, I had a similar thought.
                  I remember the menu builder (and code) in VB for building the menu accel key.
                  And if you really wanted the '&' key, you would (escape) double it '&&' in the menu text.

                  Comment



                  • #10
                    You have some NUL characters in your buffer. These are almost never good in an ASCII based protocol (with control characters).

                    (little Endian rendering ASCII)
                    V15605 0x616D ma
                    V15606 0x656C le
                    V15607 0x003D =<NUL>
                    V15610 0x6526 &e

                    So it appears the contents of your V14777%0 is not correct
                    V14777%0 means look at V14777 for the LENGTH of the string in number of BYTEs, then starting at V15000 (the next word), that is the start of the text.
                    I'm going to guess that V14777 is equal to 0, but it should be at least 1. For example, if the value was 42, and you were suppressing leading 0's/spaces, then you should have
                    V14777 2
                    V15000 0x3234 // 0x32 is the character "2", 0x34 is the character "4"

                    If you weren't suppressing leading 0's or spaces (say you wanted leading spaces), and it was a BCD (4 digit) number, then it would be
                    V14777 4
                    V15000 0x2020 // space space
                    V15001 0x3234 // 0x32 is the character "2", 0x34 is the character "4"

                    How are you generating the text that is going into V14777..., V15057...., V15217..., and V15117.... Those should also be generating via previous VPRINT instructions?
                    Do a Data View on those locations (not sure how long - what are you VPRINTing to V14777?). There's a bunch of options.

                    I would do this 1 step at a time. Nail down the printing to V14777.... Make sure it looks exactly right for what you want to put in the "big" buffer. Then do V15057... and make sure it is right. And so on. Once you have those nailed down for a bunch of 1 digit (e.g. 3), 2 digit (e.g. 42), 3 digit (e.g. 321), …, then look at this big one.

                    Look at the Help for VPRINT, and look at the paragraph for VPRINT V-memory Text Element, specifically %0 behavior. I'm guessing that you are using VPRINT to generate V14777 buffer, or are you generating buffer contents non VPRINT ladder logic?
                    There are 10 kinds of people in this world, those who know binary, and those who do not.

                    Comment



                    • #11
                      Decided to change V14777%0 to V15000%10. (Had 10 in V14777 using MOVEW K10 V14777) I tried some coding using variable length strings, but that was abandoned.
                      Still not wanting to print ascii text in double quotes. Skips it and prints data in next rung PRINT command.

                      Comment



                      • #12
                        Can you post a screen shot of Data View with V15000 thru V15004 in BCD/Hex?
                        There are 10 kinds of people in this world, those who know binary, and those who do not.

                        Comment



                        • #13
                          V15000 3132
                          V15001 3133
                          V15002 3230
                          V15003 3031
                          V15004 3732

                          (byte swapped)

                          i changes all the printed memory locations to use a specific number of characters. I have it working now.

                          "%$$EW&e=54&male=" V15000%10 "&evtext1=" V15060%6 "&evtext2=1" "&evdatetime1=" V15200%10 "&evdecimal3=" V15120%3

                          all in one print command.
                          I think the problem was I was hand typing my data and the data fields needed to be right padded with spaces. This is how our software sends the data to the plc. Apparently it was sending ASCII 0 because I did not have the ASCII 20 entered for a space?

                          Comment



                          • #14
                            Originally posted by commander View Post
                            V15000 3132
                            I think the problem was I was hand typing my data and the data fields needed to be right padded with spaces. This is how our software sends the data to the plc. Apparently it was sending ASCII 0 because I did not have the ASCII 20 entered for a space?
                            YES! NUL character is NOT a space. 0x20 is the space character - so padding with SPACE (0x20) is the right answer.

                            So, are they ALL now padded with 0x20, so everything is working?
                            There are 10 kinds of people in this world, those who know binary, and those who do not.

                            Comment



                            • #15
                              Yes, every record sent from our software is right space padded. I will make a note on the HMI if someone enters a hand typed text that they use spaces after their text.
                              Everything is printing correctly.
                              At least I will now be able to finish this project before I am let go Friday. (Lack of work for me, but hurry and get this done before you go)

                              Comment

                              Working...
                              X