I have written a simple c# app having functionality of serial
communication. I am using it to read and write to a device. The device
recognizes string commands. I am successfuly able to read from device
using this app. But peoblem is in writing(sending) commands to device.
I am simply using
if (serialPort.IsOpen == true)
{
serialPort.Write("Command1");
}
But my device does not respondes to it.
To check, I tried sending same command using hyperterminal to my
device and my device recognizes it and works perfectly.
Can anybody guide me whats the accurate way to write or what
needs to be make sure for writing to serial port in c#. Is this encoding issue...
(Serial Read using this same app is working pretty fine !!)
Thank you for your time.
Moreover, there is no exception or error and in debug mode
this line executes.
This is a very common problem and invariably caused by leaving the Handshake property set to None. Serial port devices almost always pay attention to the handshake signals and ignore anything you send if the DTR signal isn't turned on. Which indicates that you are powered up and the data it receives isn't noise. Setting DtrEnable to true will be required, that's what HyperTerminal does as well.
And it won't send anything back when it thinks you are not ready to receive anything because the RTS signal isn't turned on. Setting RtsEnable to true will be required, that's what HyperTerminal does as well. Or just set the Handshake property correctly, Handshake.RequestToSend is the common requirement.
If you still have trouble then you can use SysInternals' PortMon to compare the serial port driver commands your program issues against the ones issued by HyperTerminal.
Hyperterminal likely appends a newline character to your input when you hit the Enter key to send information, which consists of a "line feed" and "carriage return".
Check the documentation for your hardware, but my guess is that the device you're attempting to send information to is looking for a carriage return, '\r', to signify the end of input. Like others in the comments are saying, append the appropriate character(s) to the end of your input.
Alternatively, you can use the SerialPort.WriteLine function to accomplish the same thing as appending a newline '\r\n' character to your input without explicitly modifying it.
if (serialPort.IsOpen)
serialPort.WriteLine("Command" + "\r\n");
Related
I am trying to setup a simple program to a Spellman power supply.
I have setup a serialport object and included a timer to try RS232 connection.
Serial port configuration:
COM4
9600 baud rate
8 data bit
One stop bit
No handshaking is needed for this device.
I am having an issue because I need to send a SPECIFIC string to the Spellman
which I was told this would work:
STX22,pETX
But this does not work, I get no response.
Here is the problem: I have seen other examples, where the Tx or transmit line sends, 22,p^L. The ^L is a special looking character that is smaller and raised. What is this character and how do I send it in C#?
It seems that little character is what I need instead of the ETX part of the string because the hardware responds back.
The cabling works fine -- I shorted the 2 and 3 wire and I get back exactly what I sent in my program.
I have also tried sending it all data in hex instead of ASCII string, and it also does not work.
I also tried using \0002 and \0003 in many different forms for STX and ETX, does not work. I just need to figure out this 22,p^L issue.
Also this 22,p^L I have only seen in LabVIEW programs.
I am developing a softphone,using "officesip (https://sourceforge.net/projects/officesip/)", I succeeded in establishing call between subscribers, but while a receiver picks up the call the, the call is terminated,showing "error:488:not acceptable here".
At sender side, I found that the error is related to media compatibility issue. But I couldn't find how to solve it, where do I need to configure or change?
Notes:
I have only headset connected to my PC no webcams
SIP server is NGCP-SIPWISE
The call works perfectly when I call from "officesip" to "X-lite",but terminates when I call between two "officesip",after receiver picks up,with status 488.
The "488 Not acceptable here" means audio codec incompatibility problems.
Make sure that both ends has at least one common codec.
You can see the codec list in the INVITE message SDP part (with the m=audio line the codec payload numbers are enumerated and also in the a=rtpmap lines as text).
Also it might be a bug in officesip. In this case I would recommend to enable only one single codec on both end (such as PCMU) and try a call.
The project is as follows;
I would like to create an application that will be able to see packets going to a USB device. When a certain bit of data that is known is sent to the device, the returning data will be intercepted and modified before the application requesting it, gets it. I have used a USB sniffer to see the packets being sent and I know exactly what bits need to be changed. My two questions are;
Is this a possible software solution?
Will this have to be a hardware solution?
Additional Information –
The USB device uses a FTDI245R chip for communication. I know the VID and PID of the device.
I have experience programming in vb.net and C# but I have never done anything with USB
I would like the application to be able to have a number entered and changed to hex data and that is what would be sent to the device. The number being entered would be changed frequently.
Any input is appreciated.
It sounds to me like you want an upper filter driver to the FTDI driver. I don't know what class or type of device you are using or if it has a vendor specific driver or not, but here is a sample that shows how to create an upper filter to a vendor specific driver. This example uses the OSRUSBFX2 device and sample driver in the WDK, you'll want to change the code to work and interface with the FTDI driver instead.
I did a lot of search and it comes with nothing.Such as below:
c# check printer status
how do i check if a printer is installed and ready using C#?
I tried all the code I found in here but none of them can tell the status of a printer's power is on or off.
The printer is always plugged in and sometimes it's powered off, so I need to make sure it's powered on and then do the print job.
Real need some help here!
question update
the windows still send the print job to print spool when my printer is off, I don't need this, because my client sometimes will deliberately turn off the printer to avoid print something that he don't need. but windows still send it to spool, when my client turn on the printer again, it prints the thing that exactly he want to avoid.
The legacy code uses kernel32.dll's CreateFile function to open LPT1 as a file and directly write string to it to accomplish then printing function. It got no way to know the status of the printer, it just write string to the parallel port. so when the printer is off, the write function got no return, hence the following code after that will never get executed.
hopefully u can understand what I am trying to do here. I want to avoid the situation to print when the printer is off.
In my code, I'm setting the following values:
public SerialPort comPort = new SerialPort();
comPort.PortName = portName;
The PortName can be COM17, for example.
Now if I've add two devices through my GUI, both on COM17, one will eventually throw an exception (Access to COM17 denied). Now I'd like to check which device is hooked on that COM-port so if my application recognises it, it can send commands through the port, or if it's not recognized, it'll disable the option in my GUI.
So, is there a way to get unique information from the COM-port which I can save in my database when it's being installed?
EDIT: To clarify, if the wrong device is hooked to that COM port (other than when I installed), I get an error. I catch that error so I know it's not the right one. But I'd rather like to know which device that might be. Say I've got 2 drivers DLL's included, 2 different devices, and somebody switched them up. Then my application could check and see the correct names, and therefore conclude it's only a matter of changing the COM-ports of the installed objects, instead of just throwing an error and saying the user has to reinstall.
This is going to depend on your hardware. If the devices attached will give a predictable and consistent response to a particular signal message, then you can use that to identify them. I do the same thing to figure out which COM port a piece of proprietary hardware is attached to. I iterate through all the COM ports and send a message that I know will give a particular response from the hardware. Which ever port gives me the expected result is the one with the hardware.