Writing non string to COM port

[Eric Kelderman]

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

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

[Eric Kelderman]

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

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

[Enoch S Ceshkovsky]

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:

 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:

  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:

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

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

[Jules Marchildon]

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

[Eric Kelderman]

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


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

[Lance Edmonds]

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>

[Eric Kelderman]

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

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

[Lance Edmonds]

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>

[Eric Kelderman]

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


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