Announcement

Collapse
No announcement yet.

Writing non string to COM port

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

  • Eric Kelderman
    replied
    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


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

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Eric Kelderman
    replied

    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).




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

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Eric Kelderman
    replied
    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


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

    Leave a comment:


  • Jules Marchildon
    replied
    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).]

    Leave a comment:


  • Enoch S Ceshkovsky
    Guest replied
    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

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

    Leave a comment:


  • Eric Kelderman
    replied
    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



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

    Leave a comment:


  • Eric Pearson
    replied
    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).]

    Leave a comment:


  • Eric Kelderman
    started a topic Writing non string to COM port

    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

Working...
X