DLL for serial communications

Hi,

I am looking for a DLL that can be used for serial communications with VB.Is there anything like that?
I would appreciate any help regarding this.

Thanks,
Hari

The MSCOMM control works OK. In some circumstances you won't want to use an OCX, or as I found, the MSCOMM control won't do weird baud rates properly (I needed something odd like 141 baud for a certain gauge). If this is the case, you can code your own serial IO or get someone's DLL. I've tested and liked one called Wsc32.dll from http://www.marshallsoft.com/

Have Fun

As for those weird baud rate, you still can access it with your own code ;) All you need is juz call the CreateFile API by passing "COM1:" in the lpFileName parameter. and then call another SetCommMask API :)

For more, check out sample code from MSDN & hope this will help :)

Yes, you can change the baud rate this way. As I've said - you would still be using the OCX and may not want to. To avoid the OCX, writing your own serial COM code is quite easy, even in VB, using the API. However, for those that don't want an OCX and for those who don't want to code their own (would be for sure several long nights of coding and testing) - they can get a DLL.

Hello,
Thanks for ur replies Jay and Chris.
What i am actually trying to do is :
I am sending out a command to a machine to check the status of a machine parameter.Depending on the feedback i get i want to send out some other command to perform.I am using MSComm but it doesnt seem to work b'cos i am not able to get any feedback from the machine.

I would appreciate a lot if u guys could give me a sample code so that i can build upon it.Any DLL or vbcode would do.

Thanks.
Hari

I could help if YOU sent your code and also explained your RS232 wiring. It is not likelly that you are using the MSCOMM control badly - there is much info to be had about that. It is more likelly that your wiring is causing you grief! Once you completelly understand RS232 it's quite easy - but there is really no standard, only lots of typicals. (I say this much serial experience.)

:D juz write something for CraigRK in the other thread
All you need is create an ActiveX DLL and put the code into a Class and the rest of the WIN32API declaration in basic module file.

check it out :)

regards,

Hi Jay,
The problem we are facing is we have a kit which has some relays in it.We can turn those relays on/off by sending out some standard commands.Now we are doing that in VB using MSComm control.
When we send out a query,for e.g lets say to check if relay is on/off we are getting back the answer indicating the status of the relay.
But our problem is we are not been able to use that answer.i.e if the relay is on the staus is '1' we want to use this '1' to do something else.This we are not able to acheive.
I dont know if it is something to do with how MScomm sees input or something like that.

The bottomline is 'How to capture an input to manipulate something'?

Hope it is clear to you.
Hari

No, that answer is not entirely clear.

If you are getting back an answer, '1', then just do something like ... IF locAnswer = "1" THEN MSGBOX "Relay Is On" ... (I'm sure that this is a stupid answer, however, it's sounding like you don't have much VB or serial experience - no insult intended).

So you ARE getting back an answer, sounds like everything is good? If your not getting back something you can work with Be Aware that the MSCOMM control works in several modes, for example, BINARY and ASCII. Make sure this is set appropriately. Sometimes it doesn't matter, sometimes it does.

In any case, perhaps you can post your code (or EMail it to me for security reasons) and tell me exactly what the problem is. I have significant electronics, microprocessor, and VB experience.

-------------------------
First, InputMode Property
-------------------------

You can access the 'InputMode' of the MSCOMM control by pressing F4 when the control is selected on the form it is seated on. You WON'T see this property when you right click on it and select Properties. Also, you can do it in code, for example, MSComm1.InputMode = comInputModeBinary.

I almost always use binary. Binary is "better" because it returns to you ALL the characters being sent without interpreting them - letting you be in control. The choice of mode really depends on the situation and the programmer's intentions and capabilities.

FOR NOW, LEAVE IT ALONE until you're done the following test.

------------------------
Second, fixing the issue
------------------------

Well, short and sweet answer that will likely work with 'where you are' at present. You have told me that your TextBox, called text1, is receiving data. I am assuming you get "0" when relay is off ... I only know about the "1" so far.

Try this, it will make you smile:

Select Case Val(tex1.text)
Case 0
MsgBox "Relay is OFF"
Case 1
MsgBox "Relay is ON"
End Select

Please, don't run with this solution. If this is a personal project than OK, if it is a business one than it will not be as stable as it could be - read on.

What you MAY say once you test this is - "Hey, hold it Jay, this is working. How come my IF statement didn't work." Well, it's likely that there is a non-visible character in there with the "1". You IF was asking VB for an EXACT match, if anything other than "1" was there VB would say NO.

When you ask VB for Val(x), it returns a number if it can - you are asking it to convert a string to a number. If you ask for Val("Jay") it will say 0 cause it can't find any numbers in there. If you ask for Val("1Jay") it will say 1. This is how it applies to you - if there is a non-printing character, it will hopefully find your 1 or 0 and ignore the rest.

This will dump all the characters in text1.text so you can figure out what your being sent:

DIM locLoopI as Integer
For locLoopI = 1 to Len(text1.text)
MsgBox Asc(Mid(text1.text), locLoopI, 1))
Next locLoopI

This will tell you the binary value of each character. The number 49 will appear for the "1".

------------------------
Important Things To Know
------------------------

What you need to do is find out what characters are suppose to be sent when the relay is ON and OFF with the documentation for the RS232 controller - if it exists.

You see, one issue is that after you send a QUERY command to that controller, do you KNOW what to expect back - if you do not then you have a problem. LETS say you send a QUERY and QUICKLY check for a reply. LETS say you get a "1", and you deal with that. LETS say you send a QUERY again and get a " " (space). This SPACE character could have actually been the second character of the first reply - so you will think you got a bad reply.

Your input code needs to KNOW what to expect. IT IS HIGHLY LIKELLY that the controller sends something like "1" with a carriage return after it (binary value of 13) - like hitting ENTER on the keyboard. Some send an EOT character (a binary value of 4)

---------------
Proper Solution
---------------

If you send a QUERY command what you want to do is wait for the TERMINATING character and then interpret the data that came before it - in your case a "1" or a "0".

Are you starting to see this? It's like asking me a question and then only waiting long enough to hear half my answer. If you asked me another question while I was speaking, which answer is for which question? That's why they usually end a transmission with some sort of "stop" character.

Wait for the terminating character and then interpret what came before it!

:-)

Hi Jay,

As u said the SELECT CASE statement seems to be working.But teh setup we have is called 'Serial ISolated I/O module'.This has 8 relays.The commands are
Nx-for turning a relay ON(x is relay number 1..8)
Fx-turning a relay OFF
Sx-to get status of relay.

At present what we are doing is,we are sending Sx to get status of relay.Depending on the reply whether it is 1 or 0 we have to act on it.I included the SELECt statment the message box is popping up.But since we have 8 relays we have set up timers to switch on the relays at certain times.The message box is freezing up. The program is not able to continue.I have to exit using Task manager and get back.

Is there a solution for this??
By the way this is not a Business project.It s for academic purpose.So we are ready to try anything!

I would appreciate any help.

Hari

Firstly, look at my attached picture file ... is this the unit you are using?

To answer your question, yes, there is always a solution. Please send me your code. Also, tell me what you are trying to accomplish OVERALL.

Remember that, if you have the unit I think you have, that it "echos" all of the commands that you send it. That means that if you send the command to turn on a relay, the unit will send that command back to you. If you send the command to ask foir relay status, you will get that command back before you get the actual status.

I suspect it is locking up because of a receive loop somewhere - especially if your using timers to send commands.

Hi Jay,
It is almost the same as in the picture.It is a DIY kit.We have a thermoformer that we have auotmated using VB.Now we want to attach some sensors so that depending on the status of teh sensor we might trigger like for e.g

if the sensor senses low air pressure then may be increasing pressure or something like that.

I am sending the code please look into it and see if it makes some sense.This is teh main form which has MSCOMM.

Thanks,
Hari

Understand that the methodology of coding has changed with Windows (multitasking and object-orientation). Think of a program as a collection of code snips that will be 'called upon' by events external to those snips - between none and all of those events will be generated by the program itself.

-----------------------
A little about DoEvents
-----------------------

Here are comments in the code regarding DoEvents:

"Yield to other processes"
"LETS COMPUTER FREE WHILE PROCESS IS RUNNING"

This is not true.

Calling DoEvents tells Windows to process other events for YOUR program (not other programs) - an example of an event is a timer. For example, if in a loop, you will notice that the timer code will not get performed. However, if a DoEvents is put inside that loop, the timer code will get performed.

You have to think carefully about the use of DoEvents!!!

Windows is a PREEMPTIVE multitasking operating system - it does not need to be called to yield to other programs - it does so automatically (through a timer interrupt, actually).

Without using DoEvents, even in a loop, the only thing that will 'stall' is your program, NOT other programs.

---------------
Variables is VB
---------------

As a rule of thumb, declare all variables AND state their type.

For example:

Dim locCounter ' Wrong
Dim locCounter As Long ' Right

When you don't tell VB what type to use, it is made into a Variant. Variants have their uses - not all the time. They are inefficient both storage wise and execution wise. Also, it can be harder to catch errors. Additionally, it's not highly 'portable' - not many other languages have Variants.

I always put "Option Explicit" at the start so that VB will force me to declare each variable - at that time I force myself to determine it's type. You will KNOW when to use a Variant, and if you don't KNOW, then don't use. When it is needed, it will present itself to you.

---------
Using End
---------

Generally speaking, DO NOT use 'end'. Read the Microsoft Help. There may be a time to use it, but it is not the way in which VB programs must end - the way your using it.

Think of it like this, when all the objects (in your case, for now, forms) are destroyed, the program ends. To 'destroy' your form, you do an 'Unload Me' or 'Unload Form1'. You can Unload a form from another form, or from module level code. By the way, when an 'end' is executed, the UnLoad Event is not performed, so no 'shutdown' of the port is performed.

Since we are discussing this, it is a great time to show you a glimpse of VB programming.

DON'T: Have a routine to call that closes everthing down (ports, files) and performs an 'end'. Call that routine from 9 places to shut down your program.

DO: Close everything (ports, files) in the UnLoad Event. Where you want to end your program, say when a button is pushed, you do an 'UnLoad Me'. This causes the code in the UnLoad Event to execute.

Remember, when that top right "X" thing on all forms is pressed, you know the one that closes the form, the UnLoad Event gets fired automatically.

As you can see, VB programming is 'event driven', as I stated earlier.

------------------------------------
.Enable Property of a Command Button
------------------------------------

"If CmdSend.Enabled = True Then" ...

This DOES NOT tell you if the command button is pressed or not. When the Command Button is pressed you get an Event, that's it. This property does two things - It changes the appearance of the button; It determines if an Event is generated when the button is pressed.

--------------------

Well, Well. Yes, there are many issues with the code that will make it unreliable and, indeed, inoperable.

As you stated, I can see you are having an issue with getting INPUTS and using them to control the OUTPUTS.

(N.B. I can understand why one might want to find out if a relay is on or off. In your case, you are issuing a command and therefore you already know it's state.)

--------------------

There are TWO ways to approach the processing of incoming serial data. One is event driven and one is polling. For your task, you have chosen event driven - I agree, so we won't go into polling.

...

As you have done, you can tell the MSCOMM Control to generate an Event when 1 character of data is received ("MSComm1.RThreshold = 1"). Of course, if you were to set this to a number greater than 1, you would introduce issues - as I can see you are aware.

However, that one character might not be the 'last' one - you may just have received the first character of a message and can do nothing YET. Therefore, you will ADD the received character(s) to a buffer. Then you will process that buffer - not just the last received character(s). If you have not received a recognizable "message" - something you can process - you will do nothing more. If you have received a "message" you will process it and remove it from the buffer - leaving what you have not processed.

To illustrate:

You SEND "I1<CR>" (asking for the state of INPUT 1).

You get a "MSComm1_OnComm" event = comEvReceive and find the character "I" (remember, the controller sends back - echo's - what you send it). You would add this to your buffer - so Buffer now = "I". You now do a processing loop on the Buffer. So far nothing to do - your buffer is unchanged.

You get a "MSComm1_OnComm" event = comEvReceive and find the characters "1<CR>1" (remember, because you have said "MSComm1.RThreshold = 1" does NOT mean there will only be 1 character - it means there will be at least 1 character). You would add this to your buffer - so Buffer now = "I1<CR>1". You now do a processing loop on Buffer. You will remove the "I1<CR>" and know that that was the command that you SENT - your buffer is parsed to remove the part you interpreted while leaving the part you did not. Buffer now = "1".

You get a "MSComm1_OnComm" event = comEvReceive and find the character "<CR>". You would add this to your buffer - so Buffer now = "1<CR>". You now do a processing loop on the Buffer. You will remove the "1<CR>" and know that it the status of INPUT 1. Your buffer is parsed to remove the part you interpreted while leaving the part you did not. Buffer now = "".

Are you getting the picture? In any given receive event you may get enough characters to process NO messages OR MANY messages.

--------------------

I can see what you basically want to do. Perhaps, to start the process, you will turn on a relay to power up the thermoformer. Then, you will want to constantly monitor the INPUTS so that other actions can be taken. Additionally, you will want a STOP button to terminate the process.

--------------------

Would you like some code to help you along?

Hi Jay,
Your explanation made some sense.Thank you very much.Regarding the some help coding any help is always welcome.I think u now understood what i want to achieve.

So please if u dont mind help me with some coding.

Hari

The attached file contains:

ETSIOLib.ocx
SIODirect.vbp
frmMain.frm
frmMain.frx

BEFORE you open SIODirect.vbp with VB:

1) MOVE ETSIOLib.ocx to the Windows\System folder
2) Start a DOS prompt, and enter these commands:
a) CD C:\Windows\System
b) REGSVR32 ETSIOLib.ocx
3) Open SIODirect.vbp and have fun.

Let me know :-)

Hi Jay,
I got ur code,Thank u very much.
I haven't tested it yet.But when i just gave the run command it is giving some error as "Text property is read only".
It is pointing towards a line in which u have like

Comboport.Text="1"

I didnt understand what it was.

Also if u dont mind could u please explain to me how the program works.What is that colorful thing in the middle?!!

Thanks again,
Hari

http://www.banasoft.com/DownLoad/BNComm.exe

Banasoft Communication Control is a multithread communication component written by VB completely. It 's compatible with MSComm control and have many enhanced features.

Hari, ignore the suggestion by Un1. You don't need another serial control.

The file I sent, frmMain.frx, contains the entries for the the ComboBox (Comboport.Text). Did you open the SIODirect.vbp or did you open frmMain.frm? You should have opened the project file (SIODirect.vbp). The error (Comboport.Text="1") is telling you that 1 is not in the list - the list comes from the .frx file - so that it has 1 and 2 in it.

The colorful thing in the middle is an OCX - a control I created. Much like a textbox is a control. The difference is that the new control is an direct interface for your controller. It contains methods to easily turn on and off relays, etc. It will also automatically generate events when the inputs change, etc - so you dont need to poll for them. You can add it to any program you have.

Hari asked:

Can I perform some action depending on the input status.I am sure we can. But do I have change something in code?

----------

Apparently, this OCX is working well for Hari.

(Please note that all the code I sent you (in the frmMAIN) IS NOT required - it is there to demonstrate how to use the OCX.)

My reply is yes, you can. The control I sent ETSIOLib.ocx will generate an EVENT to your program, when an INPUT signal changes state.

You can place code under this event to, let's say, turn a Relay ON - as follows:

****

Private Sub DIY108_Driver1_StateChangeInput(pasNumber As Integer, pasState As Boolean)

'pasNumber is from 1 to 4 and tells you which INPUT changed
'pasState is TRUE if the INPUT is 1, else it is FALSE

If pasNumber = 1 Then
If pasState = TRUE Then
Call DIY108_Driver1.RelayOn(1)
End If
End If

End Sub

****

This code will turn on Relay 1 if INPUT 1 becomes TRUE (1). Because it is EVENT driven, THERE IS NO NEED for you to make a timer to poll the Input - you will get an EVENT automatically when an Input (or Relay) changes state.

Check out all the things the OCX does by entering "DIY108_Driver1." somewhere in your code. When you enter the '.' a list will pop up showing you what you can do.

Have Fun and good luck with your project. :-)

Hi jay,
You had mentioned that since "1" is not in the list of combo we get that error.How about adding 1 and 2 in the list of combobox and deleting the statement

comboport.Text="1"

Will that make any difference?
I thought may be we can put it in the combobox instead of having in other file.Also it is easier to convert the project into an .EXE
PLease tell me ur opinion on this.

Hari

Hari,

I think that when you add the values "1" and "2" and whatever to the control at design-time, they end up in the .frx file. I normally don't put values in controls like this. I normally use AddItem at runtime, as follows.

If you want to do it in code so that you don't need the .frx file then add these statements before the comboport.Text="1". You can remove the comboport.Text="1" if you want, there will just be no default chosen when the form is displayed.

comboport.AddItem "1"
comboport.AddItem "2"