i have a program that send ASCII commands to a device via a serial port. The program is a demo and doesn't do what i want.
I am just trying to get the device to respond in c# and I'm not getting anything back.
all the serial port settings are correct.
I am sending exactly the same message as the demo software.
//e.g message <STX>ABC<EOT>
byte[] msg = new byte[5];
msg[0] = 0x02;
msg[1] = 0x41;
msg[2] = 0x42;
msg[3] = 0x43;
msg[4] = 0x04;
comport.write(msg, 0,msg.length)
the device is a monitor. The code was only an example. there isn't a heartbeat just a response for a correct message sent or a error message. the settings are standard 9600-8-N-1. "paperclip between pins 2 and 3 (TX and RX)." yeah i know the cable works because its the same one used with the product software that works. and im getting back what i send. I have used a virtual com program and everything seems alright. "6 bytes but initializing only the first 5. " sorry typo.
the SerialPort.DtrEnable and RtsEnable properties to true. are on by default in c#. i have tried the hyper terminal and am not getting a response with that either. I have sent \r and \n with no luck.
This C# Tutorial on Serial Port Communication should be able to help. I'm not sure if there is an appropriatei intrinsic caste between Hex and Byte through assignment in C#. That may be the source of your problem.
Device Heartbeat
Does the device send a DC2 or DLE response (heartbeat)? If so, try opening a COM port in Hyperterminal using basic 9600-8-N-1 settings and see if you get anything. Is there any STX, SYN, ETX commands sent back when you try to send a command? I'm not sure on the command-set implementation for the hardware you are trying to communicate with.
Checking COM Port Operation
Have you checked if your COM port is working properly? You can create a loopback by inserting a paperclip between pins 2 and 3 (TX and RX). This will loopback your COM port and in Hyper terminal you can open that COM port and type. The characters will echo back.
You can also use a piece of software called com0com to create virtual COM ports to test what you are sending before you actually send it.
It provides pairs of virtual COM ports that are linked via a nullmodem connetion. You can then use your favorite terminal application or whatever you like to send data to one COM port and recieve from the other one
Without anymore specific information, we'll be grasping at straws.
You're allocating and sending 6 bytes but initializing only the first 5.
Also, according to what you write, you're doing everything correctly, exactly as the demo program. Right? Then I can see only one solution: The device is pulling your leg!
Seriously: If one program works and your doesn't, there MUST be some difference.
By far the most common mistake is forgetting to turn on the hardware handshake signals. The device won't send anything if it thinks the host is turned off. Make sure you set the SerialPort.DtrEnable and RtsEnable properties to true.
As mentioned before, fix the array size. Although it probably won't help, the STX character ensures that junk is thrown away.
Check if basic hardware is okay with the Windows Hyperterminal applet. You can send the message you are trying to transmit by typing Ctrl+B, ABC, Ctrl+D
As others have suggested, it is good idea to check what is being sent and received with some kind of terminal software. I have had success with "realterm"-- it has nice displays of ascii or binary/hex views.
Since you are working with ASCII, another issue might be that you are not sending the correct line-terminating character. Some devices expect \r and others \n. Make sure you are setting that correctly.
the device is a monitor. The code was only an example.
there isn't a heartbeat just a response for a correct message sent or a error message.
the settings are standard 9600-8-N-1.
"paperclip between pins 2 and 3 (TX and RX)." yeah i know the cable works because its the same one used with the product software that works. and im getting back what i send. I have used a virtual com program and everything seems alright.
"6 bytes but initializing only the first 5. " sorry typo.
the SerialPort.DtrEnable and RtsEnable properties to true. are on by default in c#.
i have tried the hyper terminal and am not getting a response with that either.
I have sent \r and \n with no luck.
Related
I'm new to c# and try to control a device over tcp/ip. The device behaves as the server so what i have done so far is that my client program initiates the connection and successfully connects to the device.
But that's all i have. Once the connection is established the device starts sending all these hex strings that i somehow need to parse. I have the protocol manual for the device so i know how to read them but i have absolutely no idea how i would implement this in c#.
What i think that needs to be done is that i constantly need to listen for the device to send data.
Then i somehow need to find complete hex command strings. I know every string starts with "0x10, 0x02" and ends with the hex chars "0x10, 0x03".
The device dictates that i also need to send some sort of acknowledge message every time i receive a string. "0x10, 0x06" (ack) So there has to be some sort of two way communication.
Any help or guidance would be very much appreciated.
Thanks
You've got to keep the incoming data in a buffer and keep looking for that end character. When you find both start and end characters, you can run your custom "parse" method to extract the information and clear the buffer.
Here's a good starting point:
https://learn.microsoft.com/en-us/dotnet/framework/network-programming/asynchronous-client-socket-example
In the server part you can find an example of looking for the end character:
https://learn.microsoft.com/en-us/dotnet/framework/network-programming/asynchronous-server-socket-example
I'm totally confused and stunned about my problem. I wrote a multi client server using sockets.
I created a first GUI that receives clients and display them in a gridview, in the click gridview event it opens a new GUI with the socket between the clicked client and the server. So everything about the connection between server and the clients go well and fast
But my problems are :
the send information between them like sending full process it sometimes shown full and it sometimes less result .
send files management for example when the server request full folders/files in a directory sometimes it shows them all and sometimes less result .
But the command such open a window open an url, send a message , commands like those works so perfectly and instantly .
I am so confused right now what's the problem
Notice 1 : I used the extern IP for connection between server/client.
Notice 2 : internet connection is perfect (definitely not slow)
I tried to use different buffer sizes, but what I'm really confused about is that sometimes the result comes full with a specific buffer size and sometimes not with the same buffer size .
Thank you for your time !
I would also recommend you use wireshark so that you are able to get the full information and transactions that are really going on in the network.
This will help you to rule out where the issue is coming from.
To determine the packet size see the image
Here I am not talking about how the TCP handshaking protocol works as I assume it is working. However do note that in the transmission if you see something like RST then maybe somebody issued a reset command implying that some error occurred in the transmission. Such as something due to checksum for example. Although it is generally a problem for someone working directly on TCP/IP protocol
This should help you confirm that you sent and recieved the correct length.
I encountered a problem that took me too much time, but without resolving it.soI really want you to help me.
I have an application built with c # wpf, and communicates with ovens via serial port.
the frame I need to send have following form: [EOT] (GID) (UID) (Temp) [ENQ]
gid uid: group identifier and unit identifier (address of the machine).
(eof),(enq) :frames the message.
(temp) means: give me the temperature value.
the only machine that has the same address can answer (master slave architecture).
the form of the response message is: [STX] (Temp) <DATA> [ETX].
the field contain only the temperature value
stx start text. etx end text.
I have no problem with sending and receiving of data, and I can display the value of temperature for a single machine connected.
but when I connect More machines, I do not know which machine has answered the frame that I sent, because the response frame does not have any adress so that I can determine which oven have respond.
So the situation in brief is:
-I send Data to ovens.
- I received data.
- I can not decide which oven answered.
please any one have an idea.
PS: I work with the protocol:EI-BISYNCH of eurotherm EuroTherm
If needed: EI-Bisynch ASCII Sequence Diagrams
In these conditions, the typical solution is:
Send the request to the current device
Wait for an answer for a defined timeout
If we receive an an answer within the timeout, the device responded.
If we do not receive an answer, the device is offline, mark it as such.
Switch to the next device, goto 1
Basically you should be able to wrap into a loop the code described here:
Providing Asynchronous Serial Port Communication
That is a sample that works with an AutoResetEvent. One of the .Net multithreading that allows synchronizing threads (the threads that sends the request in the loop, and the threads that receive the message in the loop)
IN these situations, the machine that you addressed is responding (or at least its assumed to be) Single Master - Multi Slaves. Meaning :-
Master -> Hey #1 tell me your temp -> #1 SIR! YES SIR! 23 degrees!
Master -> Hey #2...
The idea is no other slave will respond. By convention of the protocol.
Its pretty hard to do anything but this kind of system on serial.
In terms of Design if you create something like a command queue. Each command knows what device it wants to talk to, and what question it wants to ask. You process each command, send the serial message, get the response, and give it back to the command. Now you have a command, which knows which device it talked to, and what the response of that device was.
As long as you only have one "in-flight" command to which you are waiting for a response, and you know which device you sent the command to, you can assume that the device that responds next is the device you asked to respond. Now this won't necessarily always be true if it is possible for your device to send un-prompted responses.
I am trying to read data from the serial port. The data comes off of a scale. I first send a command to start reading the scale.
_serialPort.Write("P");
then after waiting for some time I am trying to read using
temp2 = _serialPort.ReadLine();
The application hangs at this line of code. I have also tried the Read function but am getting the same result. ReadExisting() function returns an empty string.
As the ReadLine() is not timing out or throwing any exceptions I am unable to debug this issue as I have no further information. The port cannot be defective as WriteLine() and ReadExisting() are working.
Any help would be appreciated.
Thanks
Try this behind your recieve button:
string msg = serialObj.ReadExisting();
MessageBox.Show(msg);
With comms, start with a terminal program. That is a program that lets you type commands that are sent out of the serial port to your device, and displays any text that comes back from the device. This will allow you to try out the protocol you've described and see what the device sends back. Once you get the correct response, you know:
The device is working
The serial cable is correctly wired and working
You are using the correct port settings (baud rate, stop bits, parity, etc)
You understand what the protocol is (do you send a "P" or a "P" followed by a newline?)
Then you can run your code in the knowledge that if it doesn't work, it's something in your code that is wrong, not any other factors muddying the waters.
Once you send the initial command, you can read the serial port immediately for the response - the call you are using will simply wait until some data is received. If no data is received, it will wait forever (hence your program hang). Any of the above things being incorrect will cause the same symptom of not receiving any data. And changing the way you read the data (e.g. async reads etc) will not change the fact that there is no data being received.
The other thing to be careful of is port settings. Generally, start with the default settings for most things (as RS232 is used in a pretty standard way by most devices) - a typical beginner mistake is to explicitly set options like the Handshaking approach, but if you get it wrong it'll break the comms. Usually you'd specify a baud rate and 8N1 (8 bits, no parity, 1 stop bit) and leave the other settings alone until you find they need to be set to get anything wto work, or you know (as in their manual states it in black and white) that your device requires something different.
Change your Write function to WriteLine. That may help. In addition, take a look at the sample of this link at MSDN. It is helpful.
Check that the SerialPort.NewLine property is set correctly. If you receive a CR character only, and the ReadLine expect eg. CRLF, your application will hung.
Does the scale respond to each "P" sent to it, or is "P" a command that tells it to begin sending a continuous stream of data? To use a terminal program, set its baud rate and protocol to the same as the scale (and your program), and use it to send a "P" to the scale in place of doing that with your program. Any response from the scale should appear in the terminal window. I prefer termie or termite (both downloadable) hyperterminal is pretty bad.
you can use that part to send a data to serial port from c#:
int MyInt3 = Convert.ToInt32(textBox3.Text);
byte[] p = BitConverter.GetBytes(MyInt3);
serialPort1.Write(p, 0, 1);
And after that you can use Read() method.
We are trying to emulate a POS keyboard in order to integrate an application with an existing Point of Sale application.
We ran across this software: Virtual Serial Port Kit
It basically creates a virtual serial port pair so that data send to COM1 can come out of COM4 and vice versa. This allows our application to send data through COM4 to appear to the POS application that it is talking to a keyboard on COM1.
Pretty ingenious, but it seems there is some kind of signalling going on that we are not able to replicate with the .Net System.IO.Ports.SerialPort class...
From what we can tell from serial port monitoring programs, this is how the startup sequence works:
8 byte Command sent to keyboard
Keyboard beeps
Some kind of signal is sent from the keyboard
Second 8 byte command is sent to keyboard, triggered by the signal
Keyboard replies with device and version information
When using our virtual serial port, we cannot figure out how to replicate the signal sent from the keyboard. We can see all data coming through properly, so we believe the settings on our SerialPort object are correct. Here is a snippet of our SerialPort settings:
_port.BaudRate= 9600;
_port.Parity = Parity.None;
_port.DataBits = 8;
_port.StopBits = StopBits.One;
_port.DtrEnable = true;
_port.RtsEnable = true;
We also noticed from using portmon we see a GET_MODEM_STATUS request that is what the POS application is waiting on before sending the second command.
Any ideas on how to diagnose this? Since we are using .NET this whole situation is a little more low level than we're used to.
UPDATE: I also want to note that we tried the SDK here: Franson Serial Tools but we could not even get data to go through when using this SDK.
UPDATE: We have thrown out using any kind of virtual serial port. We have gotten a cable to run from the POS PC to another and can see data coming across to emulate the keyboard. Now our problem is that we can't figure out how to signal that the keyboard is ready to recieve data as the top answer mentions. It appears that the POS application sends the command to beep an waits up to 3 seconds waiting for a signal. So it times out when talking to our application, but not when talking to the real keyboard
How can we do this with the SerialPort class? We already set DtrEnable and RtsEnable to true, do we need to set something else? Or do we have to use a lower level serial port p/invoke to accomplish this?
SOLUTION:
_port.RtsEnabled = false;
Thread.Sleep(1000);
_port.RtsEnabled = true;
This makes the POS application think the keyboard is plugged in, which makes sense. I'll mark the #1 answer as the answer since it greatly helped us find the solution.
EDITED to give more perspective from the point of view of simulating the keyboard.
As it happens I have written low-level drivers for the 92R keyboard in the distant past.
You really need the documentation for the proprietary protocol to do this properly - for example commands sent to the keyboard contain a sequence number and a checksum. I'd recommend contacting Fujitsu and attempting to get hold of this documentation.
From what you've described:
The first 8-byte command you sent was probably a reset command (as it caused the keyboard to beep). The keyboard sends a response to acknowledge the command, then resets itself.
After sending a reset command, the POS app needs to wait for the keyboard to reset (I think about 3000ms) before sending other commands.
It looks like the second send is a command to request the firmware version.
The POS app will also need to subsequently send a command to enable "autoinput" before the keyboard will actually send keystrokes.
There are also commands available to request the keylock position, sound the tone generator, enable/disable the MSR, and write to the optional embedded 2-line display. So your simulator will need to be capable of reproducing the responses to these commands.
Once the POS app has enabled "autoinput" the keyboard will send unsolicited messages with the keystrokes being pressed (or keylock position changes, or MSR input). IIRC these messages also have a sequence number and checksum that you will need to reproduce in your simulator.
The only signalling I know of is that the keyboard raises CTS when it is ready to receive data. If you connect two ports on a PC, you need a special null modem cable (see below) so that when your simulator raises RTS on COM4 it will be seen as CTS on the other port.
The COM ports on a TeamPOS motherboard provide power to the keyboard. You probably don't want to connect these pins to your COM4 port, so I would suggest using a null modem cable that connects only the following pins:
2 (Tx data) - 3 (Rx data)
3 (Rx data) - 2 (Tx data)
7 (RTS) - 8 (CTS)
8 (CTS) - 7 (RTS)
I've not done serial port development for years, but when I did I always used a Crossover Cable and a second PC running Windows HyperTerminal.