I want to send data hex format (0x01) or (0xff) to the port where rs232 cable is connected. I am using the MSCOMM control in VC++ 6.0. Is that the correct way to send the hex data. This is the code I have.
CString output;
UCHAR data1,data2;
data1=0x01;
output.Format("%x",data1);
m_mscom.SetOutput(COleVariant(output));
data2=0xff;
output.Format("%x",data2);
m_mscom.SetOutput(COleVariant(output));
If it is not correct, please tell me how to send hex format data to the port.
Thanks in Advance
If your data is simply a hex value that you want to send out (as opposed to a hex formatted string), you probably want "%c" rather than "%x". Given a data value of (e.g.) 0x65, "%x" will produce two bytes on the serial port: '6' (ascii value 54) and '5' (ascii value 53). "%c" will produce a single byte on the serial port: 'e' (ascii value 100 or 0x65).
As far as sending data on a serial port in C, have a look at CSerial or CSerialPort: they may simplify things for you a bit (note that I've not used them, I tend to do serial port apps in python with the pyserial module or in wxWidgets with the ctb library).
Edit: The other one that's quite good (I have used it before, but couldn't find the link when I wrote the original post) is CSerialFile, part of the WFC libraries. As I said, I tend to use wxWidgets now, but if you're using the Microsoft foundation classes, CSerialFile does make serial access very easy.
I'm no familiar with MSCOM but it seems like it won't work. Format may re-format the data to an ASCII string representation instead.
Alternatively, you can just use any serial port as a 'file' in Windows. Look at the windows api for opening files and you will see that you can address certain devices as files by using a filename like 'COM1:' instead.
Then, you can read/write from it like a file.
Related
I'm using SerialPort https://www.npmjs.com/package/serialport in a node.JS test script. I need to write the following sequence:
"\xc0\x00--EOF-Pattern--"
The device behind the Serial port expects the bytes to transmit and then the EOF pattern to show the end of the payload. A number of other binary send works fine.
However when I try to send "0xC0" it always ends in sending crap bytes. It looks that my hex is always somewhere translated into Unicode (or something similar).
Even when I do something like
var buff = Buffer.from("c0002d2d454f462d2d5061747465726e2d2d","hex");
and send "buff" to the SerialPort the Hex sequence is destroyed. Again - this only happens when a "0xC0" is in.
Any hint what I can do ? How to prevent ANY recoding on the serial line API ?
Using nodejs and iconv-lite to create a http response file in xml with charset windows-1252, the file -i command cannot identify it as windows-1252.
Server side:
r.header('Content-Disposition', 'attachment; filename=teste.xml');
r.header('Content-Type', 'text/xml; charset=iso8859-1');
r.write(ICONVLITE.encode(`<?xml version="1.0" encoding="windows-1252"?><x>€Àáção</x>`, "win1252")); //euro symbol and portuguese accentuated vogals
r.end();
The browser donwloads the file and then i check it in Ubuntu 20.04 LTS:
file -i teste.xml
/tmp/teste.xml: text/xml; charset=unknown-8bit
When i use gedit to open it, the accentuated vogal appear fine but the euro symbol it does not (all characters from 128 to 159 get messed up).
I checked in a windows 10 vm and in there all goes well. Both in Windows and Linux web browsers, it also shows all fine.
So, is it a problem in file command? How to check the right charsert of a file in Linux?
Thank you
EDIT
The result file can be get here
2nd EDIT
I found one error! The code line:
r.header('Content-Type', 'text/xml; charset=iso8859-1');
must be:
r.header('Content-Type', 'text/xml; charset=Windows-1252');
It's important to understand what a character encoding is and isn't.
A text file is actually just a stream of bits; or, since we've mostly agreed that there are 8 bits in a byte, a stream of bytes. A character encoding is a lookup table (and sometimes a more complicated algorithm) for deciding what characters to show to a human for that stream of bytes.
For instance, the character "€" encoded in Windows-1252 is the string of bits 10000000. That same string of bits will mean other things in other encodings - most encodings assign some meaning to all 256 possible bytes.
If a piece of software knows that the file is supposed to be read as Windows-1252, it can look up a mapping for that encoding and show you a "€". This is how browsers are displaying the right thing: you've told them in the Content-Type header to use the Windows-1252 lookup table.
Once you save the file to disk, that "Windows-1252" label form the Content-Type header isn't stored anywhere. So any program looking at that file can see that it contains the string of bits 10000000 but it doesn't know what mapping table to look that up in. Nothing you do in the HTTP headers is going to change that - none of those are going to affect how it's saved on disk.
In this particular case the "file" command could look at the "encoding" marker inside the XML document, and find the "windows-1252" there. My guess is that it simply doesn't have that functionality. So instead it uses its general logic for guessing an encoding: it's probably something ASCII-compatible, because it starts with the bytes that spell <?xml in ASCII; but it's not ASCII itself, because it has bytes outside the range 00000000 to 01111111; anything beyond that is hard to guess, so output "unknown-8bit".
I need some help on how to configure a new port and how to send/receive data from that port.
thus far I have:
import serial
ourPort1 = serial.Serial(
port = 0, #how to define for rs-232, rs-485, or usb
baudrate = 9600, #can i set this so its can also use 38600?
parity = serial.PARITY_NONE,
bytesize = serial.EIGHTBITS,
stopbits = serial.STOPBITS_ONE
)
I have tried reading the official documentation but I'm not sure how to approach sending 5byte commands and receiving 24 byte status packets with PySerial. Any help or references would help me a lot. I can't seem to find much for this module.
This may be way too late an answer, but I'll take a crack at it anyway:
the port property should be a string with the name of the port you want to connect to: on Windows it'll be something like "COM1", on Linux "/dev/ttyS0".
You can then use ourPort1.write(msg) to send your 5-byte message, where msg is a string 5 characters long. Be aware that if you want to send literal integers as bytes instead of ASCII values, you'll need to do a bit of extra work.
Use reply = ourPort1.read(24) to read 24 bytes into a variable called reply. Once again, this will be stored as a string full of ASCII characters by default -- you'll have to use chr() and ord() to convert back and forth between byte value and ASCII letters.
For more info, start here: http://pyserial.sourceforge.net/pyserial_api.html
I'm receiving UDP packets from a server ( exactly: Open Sound Control packets). i'm storing those packets in a ByteArray.
I want to convert this ByteArray into String so i can exploit the data received. I tried a lot of conversion but each time i'm having non readable charachters.
Here is the code :
| server peerAddr |
server := SocketAccessor newUDPserverAtPort: 3333.
peerAddr := IPSocketAddress new.
buffer := ByteArray new: 1024.
[ server readWait.
server receiveFrom: peerAddr buffer: buffer.
Transcript show: (buffer asString) ; cr ; flush. ] repeat.
I also tried the following conversion but in vain:
buffer asByteString.
buffer asStringEncoding:#UTF8.
buffer asStringEncoding:#UTF16.
buffer asString.
buffer asBase64String.
buffer asFourByteString
buffer withEncoding: #ASCII
Here is the string output :
Any help?
Additional info: The received data is open sound control data so it has a specific formatting, that's why it's diplayed like that, i need to parse ints, floats, strings, whitin a specific bytearray indexs. Does anyone recomand a package that offer those possibilities ?
Thx in advance.
if you want to read the data from the byte array, use the UninterpretedBytes class for that.
You can do:
ubytes := UninterpretedBytes from: aByteArray.
ubytes doubleAt: 5.
stuff like that.
you can also use the uninterpreted bytes to read a string from the bytes.
The correct way to convert bytes to string is definitely applying the right character encoding. The following
(65 to: 75) asByteArray asStringEncoding: #UTF8
should yield
'ABCDEFGHIJK'
Using #asStringEncoding: is the right way to do this. However looking at your screen capture it seems that the bytes you're receiving are not a straight string. There's probably some binary packet format that you need to take apart first and then only decode into strings those parts that you know are actually utf8 encoded (or whatever the encoding is).
You probably can borrow a lot of the code for Squeak's OSC package: http://opensoundcontrol.org/implementation/squeak-osc
I'm working on supporting of the TCL (thermal control protocol, stupid name, its a printer protocol of futurelogic) but i cannot find resources about this protocol, how it is, how it works, nothing, on theirs site i only found this mention http://www.futurelogic-inc.com/trademarks.aspx
any one had worked with it? does any one knows where can i find the data sheet?
The protocol is documented on their website http://www.futurelogic-inc.com/support/downloads/
If you are targetting the PSA66ST model it supports a number of protocols TCL, which is quite nice for delivering templated tickets and, line printing using the Epson ESC/P protocol.
This is all explained in the protocol document.
Oops, these links are incorrect and only correspond to marketing brochures. You will need to contact Futurelogic for the protocol documents. Probably also need to sign an NDA. Anyway, the information may guide you some more.
From what I can gather, it seems the FutureLogic thermal printers do not support general printing, but only printing using predefined templates stored in the printer's firmware. The basic command structure is a caret ^ followed by a one or two character command code, with arguments delimited using a pipe |, and the command ended with another caret ^. I've been able to reverse-engineer a few commands:
^S^ - Printer status
^Se^ - Extended printer status
^C|x|^ - Clear. Known arguments:
a - all
j - jam
^P|x|y0|...|yn|^ - Print fields y0 through yn using template x.
Data areas are defined in the firmware using a similar command format, command ^D|x|y0|...|yn|^, and templates are defined from data areas using command ^T|z|x0|...|xn|^.