MSCOMM Problems

[VictoryHighway]

Greetings,
I am attempting to use the MSCOMM control to communicate with an external device.

What I need to do is send a packet of binary data (this contains a block-mode identifier that the target recognizes, then the length of the packet and then finally command codes for the target.)

However, I am having some real difficulty in accomplishing what should be relatively easy.

So, I have setup a Byte array called output() that will for now store 5 bytes. This is what I have in my code for right now:

        Output(0) = &H18
        Output(1) = &H3
        Output(2) = Destination
        Output(3) = 0
        Output(4) = &H49
        
        Dim s As String

        With MSComm1
        ' First we initialize a few properties.
        [COLOR=green]' Set the COM port number.[/color]
        .CommPort = COMPORT
        [COLOR=green]' The communication settings.  The values are:
        ' baud rate, parity, data bits, stop bits.[/color]
        .Settings = "115200,n,8,1"
        [COLOR=green]' Recieve and send thresholds, described below.[/color]
        .RThreshold = 1
        .SThreshold = 1
        [COLOR=green]' Open COM1 and begin communications.[/color]
        .PortOpen = True
        [COLOR=green]' Send the string "some data" to the output buffer.[/color]
        .Output = Output()
        [COLOR=green]' Get the current contents of the input buffer.[/color]
        s = .Input
End With

Now, I can seemingly send ASCII text "terminal commands" to the target device and it will respond correctly, but I am not getting the proper response when I tried to send the "block-mode" packet.

So, what I have done is build a "spy cable" so that I can view and capture the data going through from my PC to the target. I have a second PC on the recieving end of the spy cable which is running ProComm Plus 4.8.

What ProComm is apparently showing me is that my computer's serial port is not sending out the data that I want it to send out.

What I'm not sure about is why this is happening. Am I doing something wrong with the code? Any ideas?

Thanks in advance,
Geoffrey

 

[TheVampire]

Are you setting the comm control to binary mode?

MSComm1.InputMode = comInputModeBinary ' this actually sets the output mode as well as the inputmode.

Also, I think you have to place your array into a variant, and then use it in the output statement

i.e.

Dim MyOutput as Variant

' assign the array to the variant
MyOutput = Output()

' Send the block out of the port

MSComm1.InputMode = comInputModeBinary
MSComm1.Output = MyOutput

Hope this helps,

Robert

 

[VictoryHighway]

Robert,
I did as you suggested and DIMmed my Output variable as a variant and changed the inputmode to comInputModeBinary as you suggested.

However, when I try to run the program now, I am only getting an Invalid Property Value error when I try to send data out.

Any thoughts?

--Geoffrey

 

[TheVampire]

Exactly where does the error occur?

Robert

 

[VictoryHighway]

During the MSComm1.Output = Output() statement.

 

[TheVampire]

Ah,

You want to keep your original variable set to the array. Add in another variable that is dimmed as a variant, and assign the array to the variant like I demonstrated above. Your modified code would be this:

Output(0) = &H18
Output(1) = &H3
Output(2) = Destination
Output(3) = 0
Output(4) = &H49
        
Dim s As String
Dim MyOutput as Variant
MyOutput = Output()
With MSComm1
        ' First we initialize a few properties.
        ' Set the COM port number.
        .CommPort = COMPORT
        ' The communication settings.  The values are:
        ' baud rate, parity, data bits, stop bits.
        .Settings = "115200,n,8,1"
        ' Recieve and send thresholds, described below.
        .RThreshold = 1
        .SThreshold = 1
        ' Open COM1 and begin communications.
        .PortOpen = True
        ' Send the string "some data" to the output buffer.
        .InputMode = comInputModeBinary
        .Output = MyOutput 
        ' Get the current contents of the input buffer.
        ' s = .Input ( See my comments below )
End With

Also, I would suggest not trying to read the input buffer from the same routine as you are using to output information. You code will probably execute before the device has time to get the information you sent it, and to respond back. It's much better to get the data in the mscomm OnComm event which will fire once the device responds.

Robert

 

[VictoryHighway]

Robert,
Thanks, I'll give this a try tomorrow and let you know.

--Geoffrey

 

[VictoryHighway]

Hi Robert,
I've just had the chance to try what you suggested. It doesn't seem to have helped at all though.

I've used ProComm on a second computer to monitor and capture the data that is being sent out by my computer's serial port and it's not quite what I need to be sending out. You will find this below:

03 3F 49 03 3F 49 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A

Do you have any idea of what's going on here? I'm about to pull my hair out!

--Geoffrey

 

[TheVampire]

A couple of questions.

1: What's the value for "Destination"?

2: What's the Upper boundry on your Output array? ( How is it dimmed? )

I'm assuming that you have Procomm on the other PC set up with the same baud, data and stop bits that you've set the comm port for.

Robert

 

[VictoryHighway]

Robert,
1. The value of destination is a user selected value between 0 and 64 (decimal). Currently, I have it set to 63 (decimal).

2. Here is the DIM statement that I have used:

Dim Output(1 To 5) As Byte

3. Yes, I have Procomm setup with the same baud rate, data bits and stop bits as the hardware device that I need to communicate with would require.

Hope this helps.

--Geoffrey

 

[TheVampire]

Dimming as Byte is correct, however you are setting the array up with elements 1 through 5, but plugging data in elements 0 through 4. I'm suprised that you don't get an error when you assign the Output(0) element, since it wasn't dimmed.

&H63 = 3F, so that explains somewhat why your output is reading as "03 3F 49".

Change your code to dim the array as:

Dim Output(4) As Byte

and then run it and see what you get.

Robert

 

[VictoryHighway]

Hi Robert,
I tried doing what you suggested plus another idea that I had.
My idea was to write the output variant to a file that I could look at on my own PC while comparing what is being recieved on the target.

The code that I used to write the file is below:

Dim MyOutput As Variant
MyOutput = Output()

Open "c:\output.txt" For Output As #1
Print #1, MyOutput
Close #1

Right now at this moment, I only have the two computers connected (without connecting in the hardware device).

The contents of the C:\Output.txt are as follows:

3F 3F 0D 0A

And the captured serial data from the other computer was:

03 3F 49 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A 0D 0A

Any ideas here?

--Geoffrey

 

[TheVampire]

I don't think that writing the variant to a text file is going to show the exact information that is stored in the array. Probably what you're seeing there is a pointer to the data location instead of the actual data ( because a variant can hold a very large array with many bytes of data ).

Also, note that one of your values ( Output(3) ) is set at zero, which is the NULL character. Is Procomm set up to accept NULLS or to discard them? Are you really wanting to send a NULL, or do you want to send the number zero ( chr$48 ) instead?

Robert

 

[VictoryHighway]

Robert,
I changed that 0 to a 1 instead (although in reality it has to be a zero.) There was no change to the Procomm capture.

--Geoffrey

 

[TheVampire]

Hmm. 1 is a control character. I'm wondering if Prcomm is ignoring some of those as well.

Just as a quick test, change all 5 of your values for the output array to 65 ( which is a capital A ) and send the data. See what Procomm comes up with. You should see five 41's ( hex of 65 ). If it does then then procomm must be ignoring some of the control characters. If it doesn't see them, the problem lays elsewhere.

Robert

 

[VictoryHighway]

Robert,
I just tried that and I discovered something interesting. Yes, I did get 5 A's to display on the monitor of the other computer, and I again captured the transfer.

I examined the output again and I did have five A's. It also again added 25 pairs of 0x0D 0x0A's.

Seems like ProComm may have been adding these on its own. I repeated the test with HyperTerminal instead. Captured the file and looked at it. It gave me five straight A's!

So, I put back in my original five bytes. I'm getting closer, but still not quite there. Here is what I'm supposed to send:

18 03 3F 00 49

What I got out of Hyperterminal is this:

18 03 03 3F 49

We're close, but not quite on target yet.

Robert, I thank you for your great help up until this point. Please let me know what else we can do to clear this up.

--Geoffrey

 

[TheVampire]

Well, the only other thing I can think of is that some of your values you are setting using the &H, and others you are entering as decimal ( the destination and the 0 ).

Try setting them all as decimal and see what that does.

Also, check your MSCOMM setting and see if NullDiscard is set to true or false. I would try it set to false. I'm not sure if that only applies to incoming data or if it does incoming and outgoing as well ( like the inputmode setting changes both input and output ).

Robert

 

[VictoryHighway]

Robert,
I have set NullDiscard to false. However, according to the help file, this only affects the input buffer.

In addition, I converted all of the bytes to decimal, and there was no change.

--Geoffrey

 

[TheVampire]

Hmm. I can't think of anything else right now. I can only imagine that it's a format problem, or maybe even something in hyperterminal that doesn't like NULL characters. The fact that the code worked fine when you were sending out all A's shows that the port is working and the basic idea is OK.

I'd just like to confirm that you are really wanting a NULL in that space, and not the number 0. I'm just asking cause it's a really unusual character to send to a device.

I'll let you know if I think of something else.

Robert

 

[VictoryHighway]

Robert,
Yes, I really need to send a binary value of 0 (not an ASCII 0).

The reason for this is because I'm interfacing my program to a hardware device that my company has designed. Basically, what we are doing is taking the serial data that I'm sending out and then it is forwarding it over an ARCNET-based network.

The 0x00 that I need to send is a "subaddress". This could be used to steer data to more than one device at a target node address on the ARCNET. However, the 0x00 means to steer the data to the node itself.

--Geoffrey