2011-01-27 2 views
2

Est-il possible que .Net SerialPort et VB6 MSComm fonctionnent différemment?SerialPort Vs MSComm

Dans les deux cas, je suis en train de lire des données du tampon, et tous les deux m'ont obtenu des chaînes différentes, si j'importe la DLL MSComm dans mon projet .Net, ça fonctionne parfaitement.

Quelqu'un at-il plus d'informations en profondeur?

Si elle aide, voici mes échantillons simples, dans les deux cas, j'envoyer le même tableau d'octets ...

VB6:

Dim MSComm1 As Object 
Dim ArrToSend() As Byte 
Dim IncomeData As String 
Set MSComm1 = CreateObject("MSCommLib.MSComm") 
With MSComm1 
    .CommPort = 1 
    .PortOpen = True 
End With 

ReDim ArrToSend(4) 
ArrToSend(0) = 179 
ArrToSend(1) = 1 
ArrToSend(2) = 92 
ArrToSend(3) = 92 
MSComm1.Output = ArrToSend 
IncomeData = MSComm1.Input 

C#

SerialPort _serialPort = new SerialPort(); 
_serialPort.Open(); 
Byte[] _bytesToSend = new Byte[4]; 
_bytesToSend[0] = 179; 
_bytesToSend[1] = 1; 
_bytesToSend[2] = 92; 
_bytesToSend[3] = 92; 
_serialPort.Write(_bytesToSend, 0, _bytesToSend.Length); 
String ReadExisting = _serialPort.ReadExisting(); 
+3

Quelle est la différence entre les deux chaînes? Vérifiez-vous les erreurs de réception (par exemple, les erreurs de parité)? Pourquoi ne configurez-vous pas/ne spécifiez-vous pas les paramètres du port COM: par exemple, le débit en bauds, les bits d'arrêt et la parité? – ChrisW

+0

J'ai écrit beaucoup de code de port série, à la fois natif et. NET, et IMO System :: IO :: Ports :: SerialPort et MSCOMM.OCX sont à la fois la corbeille. Ils prennent l'API du port série Win32 robuste et puissant et en abusent, vous forçant dans de mauvaises pratiques. Si vous voulez écrire du code robuste, vous devrez utiliser p/invoke (ou ce que j'ai fait, un wrapper C++/CLI). –

+0

@Ben Voigt Qu'est-ce qu'un encapsuleur C++/CLI sinon PinVoke? Je pensais que C++/CLI était seulement pour le portage de C++ hérité (non managé) à .NET; cela aide-t-il également à accéder aux API non gérées à partir du code managé? – ChrisW

Répondre

1

Je me attends qu'ils utilisent tous les deux the underlying O/S API; mais je suppose qu'ils peuvent chacun utiliser cette API de différentes manières: par ex. avec différents paramètres de port COM par défaut (si vous ne spécifiez pas les paramètres explicitement). Une autre différence peut être dans la synchronisation: quand vous lisez l'entrée/réponse, comment savez-vous si elle a été envoyée encore, et comment savez-vous si la fonction «lire» ou «entrée» attend assez longtemps ?

+0

Je fais un Thread.Sleep avant la lecture, pour m'assurer que j'ai une réponse, que j'ai, mais avec des caractères différents ... – Rama

5

Vous mélangez des octets et des chaînes. MSComm était très laxiste à ce sujet mais SerialPort se soucie de l'encodage de texte. Il est clair que vous utilisez un protocole binaire, il est probable que votre chaîne reçue contient des points d'interrogation pour les octets qui n'ont pas pu être convertis en SerialPort.Encoding (ASCII par défaut). Vous devez utiliser la méthode Read() pour obtenir la réponse.

+0

Je reçois des points d'interrogation pour les octets dans ma chaîne (carrés en fait), par I les séparer en chars, et là j'ai le code ASCII, faire cela ne serait pas le même que d'utiliser Read() dans une boucle for? De toute façon, je vais tester votre réponse lundi (je tourne les appareils au bureau pour que je ne travaille pas à la maison ...) – Rama

0

MSComm et Serialport sont des cadeaux gratuits et n'ont pas beaucoup en commun. Une bibliothèque portable bien connue qui vous évite les problèmes est SuperCom. Il offre un MSComm compatible ActiveX et également une bibliothèque de classe A NET. On peut utiliser celui qui correspond le mieux. Il peut être utilisé avec C++, Delphi, VB6, VB net, C#, FreePascal, Perl, Java, et bien d'autres. Et il est entièrement compatible avec 32 bits et 64 bits de Windows inclus. Windows XP, 7,8,10.