הערה
הגישה לדף זה מחייבת הרשאה. באפשרותך לנסות להיכנס או לשנות מדריכי כתובות.
הגישה לדף זה מחייבת הרשאה. באפשרותך לנסות לשנות מדריכי כתובות.
Question
Monday, March 16, 2009 7:10 AM
I want to send some data through a serialport (USB) permanently and got a problem once the USB interface crashes. Sometimes it just happens, but if I ask the PC "serialport2.isopen ()" I will get a TRUE, even though the USB cable was uplugged. How can I check if a connection is still available. CDHolding wasnt working either. I am using VB 2008 Express
All replies (7)
Friday, March 20, 2009 9:39 AM ✅Answered
Hi Roback33,
Welcome to MSDN forums!
USB is a hardware bus and as such not directly exposed
to user-mode (Win32) applications (or even .NET).
Only Windows device-drivers do control the USB or get a driver from manufacturer of your USB hardware.
So if you connect a printer with USB, use the Win32/.NET printer-API.
Or if you connect a modem with USB, use the Win32 serial-API.
Or if you connect an imaging device (camera/scanner), use TWAIN/WIA.
If you want to replace simple, generic communication, better use Ethernet
and TCP/IP.
If you want to design your own external, USB compliant hardware,
you have to understand the USB bus protocol
and implement a controller chip.
Then on Windows side, you have to write your own
device driver with the Windows DDK.
Sure there are OEM kits making all this easier.
Please visit sites like:
http://www.usb.org/
http://www.microsoft.com/hwdev/bus/USB/
http://www.lvr.com/usb.htm
http://www.beyondlogic.org/
and learn the technology.
This article is about a USB HID component which enables you to communicate with HID devices over USB. There is no default component available for USB at this moment, and this component should provide you with a good starting point when writing your own USB HID enabled applications.
This article provides a sample application as well as the component itself.
In .NET, please use the System.IO.Ports.SerialPort Class to replace the VB6 MSCOMM component.
The following is the equivalent code sample in VB.NET.
Drag&drop SerialPort1 from Toolbox onto Form1.
Public Class Form1
Dim Rx As String = ""
Public Event DataReceived As IO.Ports.SerialDataReceivedEventHandler
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
SerialPort1.PortName = "COM1"
SerialPort1.BaudRate = 9600
SerialPort1.Parity = IO.Ports.Parity.None
SerialPort1.DataBits = 8
SerialPort1.StopBits = IO.Ports.StopBits.One
'SerialPort1.Handshake = IO.Ports.Handshake.None
SerialPort1.RtsEnable = True
SerialPort1.Open()
'If SerialPort1.IsOpen = True Then
' SerialPort1.Write("MicroCommand")
'End If
End Sub
Private Sub SerialPort1_DataReceived(ByVal sender As System.Object, ByVal e As System.IO.Ports.SerialDataReceivedEventArgs) Handles SerialPort1.DataReceived
Rx = SerialPort1.ReadExisting 'or SerialPort1.ReadLine
Me.Invoke(New EventHandler(AddressOf DoUpdate))
End Sub
Public Sub DoUpdate()
If Len(Rx) > 9 Then
TextBox2.Text = ""
TextBox2.Text = TextBox2.Text & Rx
If Rx = "0415151A74" Then
WindowsMediaPlayer1.URL = "C:\eduglow\suoni\asciugacapelli.wav"
PictureBox1.Image = Image.FromFile("C:\eduglow\figure\asciugacapelli.jpg")
WindowsMediaPlayer1.Controls.Play()
End If
End If
End Sub
End Class
**Note:
**http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.datareceived.aspx
The DataReceived event is raised on a secondary thread when data is received from the SerialPort object. Because this event is raised on a secondary thread, and not the main thread, attempting to modify some elements in the main thread, such as UI elements, could raise a threading exception. If it is necessary to modify elements in the main Form or Control, post change requests back using Invoke, which will do the work on the proper thread.
http://www.microsoft.com/downloads/details.aspx?FamilyID=075318ca-e4f1-4846-912c-b4ed37a1578b&DisplayLang=en
**How do I implement Serial COM Port communication in .NET?
**Using the SerialPort class to implement Serial COM Port communication. It represents a serial port resource. This class provides synchronous and event-driven I/O, access to pin and break states, and access to serial driver properties. We can control a serial port file resource by using this class.
System.IO.Ports.SerialPort Class Members (Properties, Methods, Events,etc.)
Visual Basic .NET Code Sample: Using the COM Port in VB.NET
http://msdn.microsoft.com/en-us/library/system.io.ports.serialport_members.aspx
Article: http://www.innovatic.dk/knowledg/SerialCOM/SerialCOM.htm
Related threads with code samples:
http://social.msdn.microsoft.com/Forums/en/vblanguage/thread/c9fef85f-949f-4f5f-8639-26205607fbce/
http://social.msdn.microsoft.com/Forums/en-US/vbgeneral/thread/62ddb9a4-fe79-43bd-b43e-de2af7aeb039
Best wishes
Xingwei Hu
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Monday, March 16, 2009 6:28 PM | 1 vote
That's tricky, since the port is a virtual com port, and not a standard one. Even then, the word "connected" has various meanings.
You are wanting to tell if the cable is connected, I assume. If the device that you are connecting to is a normal serial device, it will probably set one of the control lines "high". (Usually, it will be CTS, or DSR, but sometimes the CD is used.) So, I would start by checking to see if CTS, or DSR was high. If not, try raising RTS. Most serial devices will raise CTS if you raise RTS. That is the start of hardware handshaking.
Monday, March 16, 2009 7:23 PM
do you have a pinout of the device you are connecting to? Looking for work - Zip 65101 http://www.vbforums.com/showthread.php?t=552774
Tuesday, March 17, 2009 6:10 AM
@ dbasnet - no pinout or usual USB pinout, since the devices are changin permanently.
@jinzai - Its not exactly about the cable connection. I plugged of the cable just for testing purpose. My problem is more, when the device freezes/hangs but itself or switches off by itself.
The main task of my application is to repeat a special sequence:
Switch off the device (at+cfun=0)
Switch on the device (at+cfun=1)
build up a data connection (at+cgact=1,1)
Now sometimes it just happens, that the device crashes during data connection and I would like to implement a serialport doublecheck before every new sequence start, to assure that everythink is ok.
Tuesday, March 24, 2009 7:19 AM
Ok, after reading all this, I assume its not possible to do it.
How about this solution:
I am using all devices as modems which understand hayes (AT) commands.
How about to send an "AT" and wait for the answer to it? The possible answers are "OK" or "ERROR".
I can send the command "AT", but have no idea how to double check what the modem will return.
SerialPort2.Write("at")
backdo = SerialPort2.ReadLine
Debug.WriteLine(backdo)
As a dubug result I will get "AT". How can I get the answer from the modem to the attribut "backdo"?
Tuesday, March 24, 2009 7:11 PM
I am looking at that class that you are using, and it seems to me that if you call CtsHolding (or DsrHolding), and it returns true, then you are connected to something, at least. In the event it is not true, you could try to toggle RTS, but the class does not appear to control that line directly. The kernel32 function EscapeCommFunction can be used the toggle it directly, as well as DTR. That function can also set and clear BREAK, which modems also respond to. Ther ought to be something in that that is useable to you.
Your solution seems feasible, you just need to provide your code with a state variable, like the modem has. (It is in TERMINAL mode when you are passing AT commands, and DATA mode once it has answered a call, negotiated the protocol, and lit off CD.) You should use a similar paradigm on your end. When you are in TERMINAL mode, you use one buffer, and in data mode, you use another.
Where does the data ordinarily go? Do you have a routine that processes it? That is where you get it into "backdo", but only when you are in the TERMINAL_MODE. Once you detect CD from the modem, you switch into DATA_MODE, and the data goes where it is supposed to, and not into "backdo".
To be clear, when you send a command to the modem, toggle the state to TERMINAL_MODE. In the receive routine, intercept the data (When in TERMINAL_MODE only), and stuff it into "backdo", instead of your ordinary buffer. You need a handler for CD in order to have the modem tell you when to switch modes. In that handler, set the state to DATA_MODE. (You might have to flush the buffer, or not. Only your application will know for sure.) Then, the data will go into the normal buffer.
Tuesday, March 24, 2009 8:30 PM
there is a bug that shows itself when the usb adapter is unplugged when the serial port is in use. some people report having to reboot there pc, other just restart the app.
Looking for work - Zip 65101 http://www.vbforums.com/showthread.php?t=552774