Forum Index > Upgrading from SComm32

By: Guest Posted on: Jan 7 2015 at 04:03:34 PM
Hello all Me and my associates At CS Manufacturing are working on updating our software which used the SComm32 Library, made by the same developers as Comm64, to communicate with some of our hardware via a USB Serial port. However in our update we are converting our software from VB6 code to C# code and it would seem the original library is not compatible with the .NET framework. As such I am trying to replace it with the Trial of the Comm64 Library to see if it can suit our needs. The Problem I'm experiencing at this point is that I've basically cloned our VB code in C# and it would appear that I have to close and reopen the connection at least once per command transmission to the hardware. Additionally, despite being passed the same string it seems it not sending and identical transmission.

Any help resolving these issues would be Greatly appreciated. and Thank you in advance.

By: Guest Posted on: Jan 7 2015 at 04:16:11 PM
Sorry for missing this in the first post the input from the hardware is also garbled. Infact it seems to be worse than the transmission to the hardware.

Again Thank you for any help

By: Support Posted on: Jan 7 2015 at 11:07:31 PM
You say "your hardware" but you don't say what your hardware is.

You can use sComm32.ocx with .net and c#. Only restriction really is that you'd need to build for x86. You couldn't build for AnyCPU or for x64 (ocx are all 32 bit)

Getting back to Comm64. Are you able to create a small project that exhibits the problem you're describing? Perhaps using a loopback ?

By: Guest Posted on: Jan 8 2015 at 09:46:37 PM
Thank you for your help but I managed to solve it the garbled in/outputs was actually a result of me using the wrong Encodings for converting the strings to binary.

The issue with having to reconnect seems to have been a result of me setting the ports .OutBufferCount property to 0 immediately before writing to it.

For future reference is there a recommended amount of time to wait after clearing the buffer, before writing to the ports .Output property again? Or is clearing the OutBuffer simply not a good idea?

By: Support Posted on: Jan 8 2015 at 09:58:25 PM
Setting the OutbufferCount to zero immediately before putting data into the buffer shouldn't cause a problem.

But I'm not looking at the source code of the DLL at the moment so i can't be sure but maybe we have a bug in there. Or maybe its something in the serialport driver that is delaying the clearing of the buffer so it affects the data you're trying to send.

Is there any reason why you need to clear the buffer? Do you expect there to be any data from a previous transmission that is still in transit?

I'm actually curious about any delay in clearing the buffer so I'll run some tests tomorrow and see what i find.

By: Guest Posted on: Jan 9 2015 at 05:18:13 PM
Honestly I'm not the most Knowledgeable about how the hardware works. I did have a test yesterday which filled the buffer and locked the program but after some minor unrelated charges i have yet to run in to the issue again. My Supervisor was even saying that he wasn't sure if we had to clear the buffer in the original code that I'm translating from. He just left the line cause it was not hampering the program in any way. Sorry i can't be of more help. And Thanks again for your help


Reply - add comment to this topic
You may enter letters, numbers and standard punctuation only. HTML and other scripts/tags will be rejected
  Topic:- Upgrading from SComm32

Your Name


Forum scripts and databases - Copyright (c) 2009 - 2012