Announcement

Collapse
No announcement yet.

Writing non string to COM port

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

  • Writing non string to COM port

    Hi

    I like to write non string data to a Com port.
    Can I try this with a normal print#hcom1, Expression ?

    What I like to write is normal integer values, hex values etc.
    Communicating to a PLC like machine interface.

    Thanks for any information

    Eric Kelderman

    Eric Kelderman
    www.dlog.nl

  • #2
    It will depend on the binary format that you need, but the MK* functions would be a good place to start. For example, MKL$ can be used to create a binary representation of a LONG integer, in a standard Microsoft format.

    But unless you are talking about creating human-readable strings (like HEX$ and FORMAT$) there is no difference between a "decimal number" and a "hex number". They are just two different representations of exactly the same thing, like "15" and "&hF". And when you use a function like MKL$ you are creating yet another format, which is 100% independent of the original numeric format (decimal or hex).

    HTH.

    -- Eric

    ------------------
    Perfect Sync: Perfect Sync Development Tools
    Email: mailto:[email protected][email protected]</A>



    [This message has been edited by Eric Pearson (edited March 15, 2000).]
    "Not my circus, not my monkeys."

    Comment


    • #3
      Eric

      I didn't know of the function MK*, and will try this tomorrow as soon as I come into the office,

      Like:
      &H55 == 85 == COM SEND #1, MKL(85)

      Thanks
      Eric


      Originally posted by Eric Pearson:
      It will depend on the binary format that you need, but the MK* functions would be a good place to start. For example, MKL$ can be used to create a binary representation of a LONG integer, in a standard Microsoft format.

      But unless you are talking about creating human-readable strings (like HEX$ and FORMAT$) there is no difference between a "decimal number" and a "hex number". They are just two different representations of exactly the same thing, like "15" and "&hF". And when you use a function like MKL$ you are creating yet another format, which is 100% independent of the original numeric format (decimal or hex).

      HTH.

      -- Eric



      ------------------
      Eric Kelderman
      www.dlog.nl

      Comment


      • #4
        The first question is, does the device want the numbers as "human readable" or as the actual values in memory?
        There is a big difference between:
        Code:
         print #hcom1, str$(12345)
        AND
         print #hcom1, MKL$(12345)
        Try printing to a file to see the difference yourself.
        If it does want the actual memory values, what sort of endian system is the device using? This is very important!

        Anyways, Actual memory values can be gotten by MKL$(), but a better & faster way is to take advantage of PB's pointers. Create a pointer type of the source variable (long integer) and set it to aim at your destination string. With a simple @ptr = myinteger. Move the pointer along but being careful not to go past the end of our string and copy again.
        Example:
        Code:
          LOCAL strTemp AS STRING * 8 ' LONG integers are 4 bytes wide each
          LOCAL pstrTemp AS LONG PTR ' must be same as source type
          LOCAL a AS LONG, b AS LONG
          a = 22
          b = -56
          pstrTemp = VARPTR(strTemp)
          @pstrTemp = a
          INCR pstrTemp ' move to the next 4 bytes
          @pstrTemp = b
          a = 0 ' clear out results
          b = 0 
          pstrTemp = VARPTR(strTemp) ' now we'll reverse the process
          a = @pstrTemp
          INCR pstrTemp
          b = @pstrTemp
          msgbox str$(b) ' just to show results
        If you wanted to move byte length numbers around, just change the LONG to BYTE including the PTR. It'd also be a good idea to change the string size to fit. Use of a dynamic string is not recommened, but if you do, prefill it with the necissary amount of spaces BEFORE getting the strptr()

        Another way is to consider using a User Defined Type. This is especially useful if protocol uses blocks of data. We just fill our type with the data needed in the format needed.
        Example:
        Code:
        TYPE TestType
         a as LONG
         b as BYTE ' just to show types can be mixed
         c as LONG
        END TYPE
        FUNCTION PBMAIN()
          LOCAL strTemp AS STRING * 9 ' LONG + BYTE + LONG = 9
          LOCAL Test AS LongType
          Test.a = 22
          Test.b = 44
          Test.c = 66
          LSET strTemp = Test ' strTemp now holds the 3 values
          Test.a = 0
          Test.b = 0 ' RESET Test would've worked too.
          Test.c = 0 
          LSET Test = strTemp ' copy the string into the type
        
          MSGBOX STR$(test.b) ' just to show it works
        END FUNCTION

        ------------------

        Comment


        • #5
          Eric, most likely you want to use ASCII 0-255, 8 bit values to serially Tx/Rx to your PLC.
          So if you want to send HEX 55, then literally send it as 01010101 via serial port.

          HTH
          Regards, Jules


          [This message has been edited by Jules Marchildon (edited March 15, 2000).]
          Best regards
          Jules
          www.rpmarchildon.com

          Comment


          • #6
            Thanks for responding, I'm still trying with your code examples, in te mean time maybe this will help:

            A pease of "GWBASIC" code which is seems to be working:

            2000 CLOSE #1: OPEN "com1:1200,e,7,1,cs,rs,ds" FOR RANDOM AS #1
            2010 X55 = INP(&H3FB): X55 = X55 OR 1: OUT &H3FB, X55
            2020 PRINT #1, CHR$(85);
            2030 FOR i = 0 TO 3000: NEXT
            2040 X55 = INP(&H3FB): X55 = X55 AND &HEF: OUT &H3FB, X55

            Line 2010 and 2040 are the ones I do not understand (being new to this)

            Thanks

            Eric


            ------------------
            Eric Kelderman
            www.dlog.nl

            Comment


            • #7
              Code:
              DIM Value?, a$
              Value? = &H055 ' unsigned value
              COMM SEND #hComm, CHR$(Value?)
              a$ = CHR$(&H055, &H0FA, &H0C0, &H0) ' 4 bytes assembled into a string
              COMM SEND #hComm, a$
              Where Value? is a byte variable which can range from o to 255, and a$ is a string containing 4 discrete bytes of 'numeric' data.

              In summery: if you need to send a stream of byte values, either assemble them into a string and then COMM SEND that string, or just send single bytes as needed (per my example above).


              ------------------
              Lance
              PowerBASIC Support
              mailto:[email protected][email protected]</A>
              Lance
              mailto:[email protected]

              Comment


              • #8

                Getting pretty desparate right now...

                I need some again help on this one

                It looks so simple print chr$(85) to com1

                in this QuickBasic code line 2010 does the trick,
                it seems to set a dtr register or something i read in the
                qbasic help where this line actually is given too
                2010 X55 = INP(&H3FB): X55 = X55 OR 1: OUT &H3FB, X55
                Leaving out this line the "DOS" code doesn't communicate with
                the machine too, using this line it works ok....

                It doesn't seem to have anything to do with the communication
                itself does it?

                2000 CLOSE #1: OPEN "com1:1200,e,7,1,cs,rs,ds" FOR RANDOM AS #1
                2010 X55 = INP(&H3FB): X55 = X55 OR 1: OUT &H3FB, X55
                2020 PRINT #1, CHR$(85);
                2030 FOR i = 0 TO 3000: NEXT
                2040 X55 = INP(&H3FB): X55 = X55 AND &HEF: OUT &H3FB, X55

                Thanks for all the help sofar I hope to solve this thing soon..

                Eric Kelderman

                Originally posted by Lance Edmonds:
                <font face="Courier New, Courier" size="3"><pre>
                DIM Value?, a$
                Value? = &H055 ' unsigned value
                COMM SEND #hComm, CHR$(Value?)
                a$ = CHR$(&H055, &H0FA, &H0C0, &H0) ' 4 bytes assembled into a string
                COMM SEND #hComm, a$
                </pre></font>
                Where Value? is a byte variable which can range from o to 255, and a$ is a string containing 4 discrete bytes of 'numeric' data.

                In summery: if you need to send a stream of byte values, either assemble them into a string and then COMM SEND that string, or just send single bytes as needed (per my example above).




                ------------------
                Eric Kelderman
                www.dlog.nl

                Comment


                • #9
                  The DOS code is reading and changing bits in the Line Control Register of the UART on the serial port whose Base address is &H3F8.

                  Do you know the spec's for serial coms to take place with the "remote device" (ie, handshaking, etc?).

                  In Windows, you cannot just open a port as you did with PB/DOS or QB, etc. You have to use the Windows API. Luckily, PB/DLL 6.0 provides this functionality directly! See the COMM statement and function, plus the example files in the SAMPLES\COMM folder.

                  If you are using PB/DLL 5.0, then you must rewrite the code to use the raw Windows API - not a task for the faint of heart unfortunately.

                  Lets see what you have come up with in your translation from DOS to Windows, and we can continue on from there.

                  ------------------
                  Lance
                  PowerBASIC Support
                  mailto:[email protected][email protected]</A>
                  Lance
                  mailto:[email protected]

                  Comment


                  • #10
                    Lance

                    I found a package "PComm Lite" from Moxa, www.moxa.com and they
                    provide a development kit for rs232, using that 57K dll it worked
                    instandly.....

                    I think the difference will be in openening the port, what I will do is first go on with the app I needed this for and then use PB/dll 6 to try again, the declarations are fairly simple like I wanted to create them in PB therefore as soon as I can convert this to PB I will not be dependend on this "hidden" code in the Moxa dll.

                    Thanks again for your input

                    Eric


                    ------------------
                    Eric Kelderman
                    www.dlog.nl

                    Comment

                    Working...
                    X