Upland
asked on
MScomm revisited...
Thanks to Rockie for pointing out my problem last time... but I have hit another - and I am sure it is just as easy!! (Maybe I should stick to databases in the future)...
OK: I am communicating with a gizmo via COM1 which has an LCD display to show bytes received/transmitted. I know the correct bytes to send to this machine to get it to respond, but when I send them via "mscomm1.output = <string>" it does nothing! I know the string is correct because if I add a 'VB watch' to the string and then copy it to the clipboard, I can open up Hyper-terminal, set it up for COM1 and then "paste to host" from the clipboard and voila! - correct response from gizmo!!
I guess my question is: Is there anything at all I need to do other than the following?
msc1.CommPort = 1
msc1.Settings = "1200,n,8,1"
msc1.Handshaking = comNone
msc1.PortOpen = True
msc1.output = String$
msc1.PortOpen = False
Remember: Pasting String$ through Hyperterminal works just fine. There is something I am just not understanding about VB comms - can anyone enlighten me?
In case it is relevent, String$ is a five-line text message with lines separated by &HA (linefeed) and it starts with &H02 and ends with &H03 &H0D
Thanks
OK: I am communicating with a gizmo via COM1 which has an LCD display to show bytes received/transmitted. I know the correct bytes to send to this machine to get it to respond, but when I send them via "mscomm1.output = <string>" it does nothing! I know the string is correct because if I add a 'VB watch' to the string and then copy it to the clipboard, I can open up Hyper-terminal, set it up for COM1 and then "paste to host" from the clipboard and voila! - correct response from gizmo!!
I guess my question is: Is there anything at all I need to do other than the following?
msc1.CommPort = 1
msc1.Settings = "1200,n,8,1"
msc1.Handshaking = comNone
msc1.PortOpen = True
msc1.output = String$
msc1.PortOpen = False
Remember: Pasting String$ through Hyperterminal works just fine. There is something I am just not understanding about VB comms - can anyone enlighten me?
In case it is relevent, String$ is a five-line text message with lines separated by &HA (linefeed) and it starts with &H02 and ends with &H03 &H0D
Thanks
My guess is that you are closing the Serial Port before it has time to send the entire message...if you have another computer available, try running Hyperterminal on the second computer to display what you are sending out of the test PC......
Try inserting this code before closing the port...
While msc1.OutBufferCount > 0
Wend
This will allow all the data to get out of the port before it is closed.....
Remember that the msc1.Output does NOT automatically send a Carriage Return, and Hyperterminal probably does...you may have to use:
msc1.Output = "Test Data" + vbCR
or even:
msc1.Output = "Test Data" + vbCRLF
hope this helps!
-kf
Try inserting this code before closing the port...
While msc1.OutBufferCount > 0
Wend
This will allow all the data to get out of the port before it is closed.....
Remember that the msc1.Output does NOT automatically send a Carriage Return, and Hyperterminal probably does...you may have to use:
msc1.Output = "Test Data" + vbCR
or even:
msc1.Output = "Test Data" + vbCRLF
hope this helps!
-kf
ASKER
Dalin,
Thanks for the comment.
It really is text (I think). Weird, I know, but a byte in this context (according to the gizmo handbook) is a pair of ASCII characters transmitted which the 'gizmo' combines to form a 2-digit decimal value.
eg. A 'byte' 07 would be transmitted as &H30 followed by &H37. The 'character' 2 or 3 mentioned above, on the other hand, is transmitted as chr(2) or chr(3).
MScomm control has an InputMode property for text/binary but not a corresponding OutputMode... what exactly were you suggesting I try in your comment?
Thanks for the comment.
It really is text (I think). Weird, I know, but a byte in this context (according to the gizmo handbook) is a pair of ASCII characters transmitted which the 'gizmo' combines to form a 2-digit decimal value.
eg. A 'byte' 07 would be transmitted as &H30 followed by &H37. The 'character' 2 or 3 mentioned above, on the other hand, is transmitted as chr(2) or chr(3).
MScomm control has an InputMode property for text/binary but not a corresponding OutputMode... what exactly were you suggesting I try in your comment?
ASKER
Dalin,
Thanks for the comment.
It really is text (I think). Weird, I know, but a byte in this context (according to the gizmo handbook) is a pair of ASCII characters transmitted which the 'gizmo' combines to form a 2-digit decimal value.
eg. A 'byte' 07 would be transmitted as &H30 followed by &H37. The 'character' 2 or 3 mentioned above, on the other hand, is transmitted as chr(2) or chr(3).
MScomm control has an InputMode property for text/binary but not a corresponding OutputMode... what exactly were you suggesting I try in your comment?
Thanks for the comment.
It really is text (I think). Weird, I know, but a byte in this context (according to the gizmo handbook) is a pair of ASCII characters transmitted which the 'gizmo' combines to form a 2-digit decimal value.
eg. A 'byte' 07 would be transmitted as &H30 followed by &H37. The 'character' 2 or 3 mentioned above, on the other hand, is transmitted as chr(2) or chr(3).
MScomm control has an InputMode property for text/binary but not a corresponding OutputMode... what exactly were you suggesting I try in your comment?
ASKER
Kfrick,
Thanks for the answer but I have to reject it as I had considered that earlier and then dismissed it - I had already stepped through the code and it made no difference. As for the CR, I am explicitly sending a &H0D at the end of the string - this is also in the clipboard when I do the 'paste to host' from Hyperterminal.
I have tried transmitting the complete string as described above and also sending the characters one at a time... for example:
...
msc1.output = Chr(&H30)
msc1.output = Chr(&H31)
msc1.output = Chr(&H34)
msc1.output = Chr(&H30)
.... etc
Will send 0140 (exactly as described in the handbook.
Regards,
Upland
Thanks for the answer but I have to reject it as I had considered that earlier and then dismissed it - I had already stepped through the code and it made no difference. As for the CR, I am explicitly sending a &H0D at the end of the string - this is also in the clipboard when I do the 'paste to host' from Hyperterminal.
I have tried transmitting the complete string as described above and also sending the characters one at a time... for example:
...
msc1.output = Chr(&H30)
msc1.output = Chr(&H31)
msc1.output = Chr(&H34)
msc1.output = Chr(&H30)
.... etc
Will send 0140 (exactly as described in the handbook.
Regards,
Upland
I would hook up another PC in place of your LCD gizmo, then send the "monitor" PC your Hyperterminal output, and your VB output, to discover the difference.....
If you can send it with Hyperterminal, you can send it with VB!
You may have to get ahold of a program to display not only the Text, but also any "white spaces" or control chartacters, to succesfully monitor the data. I use good old "PCPlus" for DOS when I really want to look at serial communications.
Sorry my answer didn't work....hope you can figure it out!
-kf
PS.....are you using 3-wire (RX,TX, & GND) or more (CTS/RTS/DSR/DTR) for your connection?? If you are using more that 3-wires, you may have to set the handshaking properties of your msc1 object....just a thought!
If you can send it with Hyperterminal, you can send it with VB!
You may have to get ahold of a program to display not only the Text, but also any "white spaces" or control chartacters, to succesfully monitor the data. I use good old "PCPlus" for DOS when I really want to look at serial communications.
Sorry my answer didn't work....hope you can figure it out!
-kf
PS.....are you using 3-wire (RX,TX, & GND) or more (CTS/RTS/DSR/DTR) for your connection?? If you are using more that 3-wires, you may have to set the handshaking properties of your msc1 object....just a thought!
ASKER
kfrick,
It is just a 3-wire... but the other information (which I believe is irrelevant) is that the 'gizmo' is actaully an RS485 connector - and it goes through an RS485/RS232 convertor (which just looks like a 9/25 convertor). I say irrelevant because it is still there when I am using the hyperterminal connection.
I will do as you suggest and set up a receiving PC locally.... watch this space.
Upland
It is just a 3-wire... but the other information (which I believe is irrelevant) is that the 'gizmo' is actaully an RS485 connector - and it goes through an RS485/RS232 convertor (which just looks like a 9/25 convertor). I say irrelevant because it is still there when I am using the hyperterminal connection.
I will do as you suggest and set up a receiving PC locally.... watch this space.
Upland
ASKER
I realize that this now has very little to do with VB and mscomm controls... but here goes anyway...
I set up a PC locally, connected the comm ports and here are the results...
Connected my VB prog to PC running DOS and captured as text.
Also, connected to PC running Win95 Hyperterminal and captured as text.
Both results were the same...
Here is Hex Dump of captured text:
02 30 31 34 30 31 30 41 42 43 44 45 46 0a 0a 0a 0a 0a 03 41 0d
.....This is exactly as it should be because it is exactly the same as the captured text, using the same methods from the original DOS program when it sends the same six characters "ABCDEF" in this case.
This however is the cut and pasted (to gizmo via Hyperterminal) 'Watch Window' text
02 30 31 34 30 31 30 41 42 43 44 45 46 0a 0a 8a 0a 8a 03 41 0d
... which, bizarre as it seems, actually gets the correct response from the gizmo.
Notice that two of the five linefeeds (0a) get turned into 8a when they get pasted. Looking at them in the clipboard they are all 0a linefeeds - so I am presuming that it is something to do with Hyperterminal.
If anyone can be *bothered* to paste the string from the hex above to Hyperterminal's "paste to host" I would be curious to see if they get the same result. Here is the code ... it will save you the typing.
TX = Chr(&H2) & _
Chr(&H30) & _
Chr(&H31) & _
Chr(&H34) & _
Chr(&H30) & _
Chr(&H31) & _
Chr(&H30) & _
Chr(&H41) & _
Chr(&H42) & _
Chr(&H43) & _
Chr(&H44) & _
Chr(&H45) & _
Chr(&H46) & _
Chr(&HA) & _
Chr(&HA) & _
Chr(&HA) & _
Chr(&HA) & _
Chr(&HA) & _
Chr(&H3) & _
Chr(&H30) & _
Chr(&H41) & _
Chr(&HD)
Personally, I think I need a priest!!
I set up a PC locally, connected the comm ports and here are the results...
Connected my VB prog to PC running DOS and captured as text.
Also, connected to PC running Win95 Hyperterminal and captured as text.
Both results were the same...
Here is Hex Dump of captured text:
02 30 31 34 30 31 30 41 42 43 44 45 46 0a 0a 0a 0a 0a 03 41 0d
.....This is exactly as it should be because it is exactly the same as the captured text, using the same methods from the original DOS program when it sends the same six characters "ABCDEF" in this case.
This however is the cut and pasted (to gizmo via Hyperterminal) 'Watch Window' text
02 30 31 34 30 31 30 41 42 43 44 45 46 0a 0a 8a 0a 8a 03 41 0d
... which, bizarre as it seems, actually gets the correct response from the gizmo.
Notice that two of the five linefeeds (0a) get turned into 8a when they get pasted. Looking at them in the clipboard they are all 0a linefeeds - so I am presuming that it is something to do with Hyperterminal.
If anyone can be *bothered* to paste the string from the hex above to Hyperterminal's "paste to host" I would be curious to see if they get the same result. Here is the code ... it will save you the typing.
TX = Chr(&H2) & _
Chr(&H30) & _
Chr(&H31) & _
Chr(&H34) & _
Chr(&H30) & _
Chr(&H31) & _
Chr(&H30) & _
Chr(&H41) & _
Chr(&H42) & _
Chr(&H43) & _
Chr(&H44) & _
Chr(&H45) & _
Chr(&H46) & _
Chr(&HA) & _
Chr(&HA) & _
Chr(&HA) & _
Chr(&HA) & _
Chr(&HA) & _
Chr(&H3) & _
Chr(&H30) & _
Chr(&H41) & _
Chr(&HD)
Personally, I think I need a priest!!
Upland,
If you are sending binary data, you need to have the outdata in a Byte Array instead of String.
Dim lOutData (1 to N) as Byte ' N Bytes will be send
For i = 1 to N
lOutData(i) = somthing "Fill your Array with Binary Value
Next i
MSComm1.OutPut = lOutData()
Now You need to know what the other machine is looking for and put the value to the byte array accordingly.
If you are sending binary data, you need to have the outdata in a Byte Array instead of String.
Dim lOutData (1 to N) as Byte ' N Bytes will be send
For i = 1 to N
lOutData(i) = somthing "Fill your Array with Binary Value
Next i
MSComm1.OutPut = lOutData()
Now You need to know what the other machine is looking for and put the value to the byte array accordingly.
ASKER
Dalin,
Many thanks once again for your comments.
I declared b(1 to 22) as byte - and then after the TX = ... (see above), I placed:
For i = 1 To 22
b(i) = Asc(Mid(TX, i, 1))
Next i
I checked through the array and confirmed it contained the same values as above. 02, 30 .... 0d.
....but still no success with regards a response from the gizmo. Oh well...
Many thanks once again for your comments.
I declared b(1 to 22) as byte - and then after the TX = ... (see above), I placed:
For i = 1 To 22
b(i) = Asc(Mid(TX, i, 1))
Next i
I checked through the array and confirmed it contained the same values as above. 02, 30 .... 0d.
....but still no success with regards a response from the gizmo. Oh well...
Geez......
Just curious about the last 4 entries in your code above.....looks like you're sending
<ETX>"0A"<CR>
with these codes
Chr(&H3) & _
Chr(&H30) & _
Chr(&H41) & _
Chr(&HD)
Is that your intention? Or is it a typo??
I am also confused by the "41" as the second last character of your captured hex data.....????
Try this as your output string.....
Out$ = Chr$(2) + "014010ABCDEF" + vbLF + vbLF + vbLF + vbLF + vbLF + Chr$(3) + vbCR
(all one line, y'know...)
msc1.Output = Out$
Do either of the first two data dumps actually operate the LCD gizmo??
Just curious about the last 4 entries in your code above.....looks like you're sending
<ETX>"0A"<CR>
with these codes
Chr(&H3) & _
Chr(&H30) & _
Chr(&H41) & _
Chr(&HD)
Is that your intention? Or is it a typo??
I am also confused by the "41" as the second last character of your captured hex data.....????
Try this as your output string.....
Out$ = Chr$(2) + "014010ABCDEF" + vbLF + vbLF + vbLF + vbLF + vbLF + Chr$(3) + vbCR
(all one line, y'know...)
msc1.Output = Out$
Do either of the first two data dumps actually operate the LCD gizmo??
ASKER
kfrick,
Thanks once again...
You are right when you say 2 and 3 are STX and ETX. The 30 and 41, however, are part of this esoteric protocal and are actually a Block Check which is calculated on all previous characters - except STX.
The calculation of BCC is:
BCC = 0
For i = 1 To Len(TX$)
BCC = (BCC Xor Asc(Mid$(TX$, i, 1))) And &HFF
Next i
TX$ = Chr(&H2) + TX$ + Hex(BCC \ 16) + Hex(BCC Mod 16) & Chr(&HD)
The &H0d is also part of this protocol and signals End Of Transmission.
Just for completeness:
After the initial STX......
01 Indicates the machine on the bus being addressed (1 - 8)
40 Indicates a 5 line message is to be displayed on Gizmo's LCD.
10 Indicates it should be displayed for 10 minutes then erased.
Then we're into the message itself and five linefeeds.
Many thanks.
Thanks once again...
You are right when you say 2 and 3 are STX and ETX. The 30 and 41, however, are part of this esoteric protocal and are actually a Block Check which is calculated on all previous characters - except STX.
The calculation of BCC is:
BCC = 0
For i = 1 To Len(TX$)
BCC = (BCC Xor Asc(Mid$(TX$, i, 1))) And &HFF
Next i
TX$ = Chr(&H2) + TX$ + Hex(BCC \ 16) + Hex(BCC Mod 16) & Chr(&HD)
The &H0d is also part of this protocol and signals End Of Transmission.
Just for completeness:
After the initial STX......
01 Indicates the machine on the bus being addressed (1 - 8)
40 Indicates a 5 line message is to be displayed on Gizmo's LCD.
10 Indicates it should be displayed for 10 minutes then erased.
Then we're into the message itself and five linefeeds.
Many thanks.
Do you have a program that can Drive the device?
1. Run that program to make sure the Device will response so you are not beating a dead horse;
2. Look at the menu of the device to see what exactly it is look for, whether text or binary, if binary, you need to send each byte exactly the way it requres ( for example, I had a instrument that receive each character with two bytes, with the two highest bits of the second bytes set to high always. My guess is that your device is looking for binary
in its own way... (If you have Doc and need help to figure out what it need, you can send it to me via email or FAX,my email Dalin_N@MailExcite.com)
3. If you can not find any doc, but you have a program that make it go, you can always capture what is going back and forth, just make a T in your signal cable... (I had to do that many times).
1. Run that program to make sure the Device will response so you are not beating a dead horse;
2. Look at the menu of the device to see what exactly it is look for, whether text or binary, if binary, you need to send each byte exactly the way it requres ( for example, I had a instrument that receive each character with two bytes, with the two highest bits of the second bytes set to high always. My guess is that your device is looking for binary
in its own way... (If you have Doc and need help to figure out what it need, you can send it to me via email or FAX,my email Dalin_N@MailExcite.com)
3. If you can not find any doc, but you have a program that make it go, you can always capture what is going back and forth, just make a T in your signal cable... (I had to do that many times).
OK on the goofy checksum, still one question.....
Your first two data strings read <ETX><&H41><CR>.
Your third data string reads <ETX><&H30><&H41><CR>.
Where did that &H30 come from, or, why is it missing in the first two examples??
-kf
Your first two data strings read <ETX><&H41><CR>.
Your third data string reads <ETX><&H30><&H41><CR>.
Where did that &H30 come from, or, why is it missing in the first two examples??
-kf
ASKER
Dalin,
Thanks for the response.
1. I have the DOS program that came with the device - it works just fine.
2. The device doesn't have a menu as such. What it does have (which is good) is a 'debug mode' in which you can see everything sent to the device as hex and all responses from the device as reverse video hex. So in this respect I can see everything that is going on (or not as the case may be).
The only bad thing about the device (in either regular or debug mode) is that unless the message is correctly formatted: ie [stx, addr, code, data, etx, bcc, cr] with everything present and correct - including the bcc (see message above) then it ignores the whole message.
I can capture the data from the original DOS program and then send exactly the same bytes from my program without getting any response from the device. But as I have said above a few times, if I copy the string to the clipboard from the VB Watch Window (just before I do mscomm.output) and paste-to-host via Hyperterminal then it works. (Apart from the fact that a couple of the &H0a bytes are switched to &H8a)
The only other difference I can think of is that the gizmo sits behind an RS232-RS485 convertor as it only has a 9-pin RS485 comms socket on it.
As far as documentation goes, there are five sheets of paper - page one describes the protocol above and the next four pages are simply the different 'messages' you can send it and the responses you can expect to get back.
I have briefly spoken to the guy who wrote the original DOS program without getting anywhere - unfortunately he refuses to have anything to do with MS Windows PERIOD - he even uses a DOS email client and a DOS web browser.
Thanks again....
PS - If you really think the front page of the documentation will help then I will scan and email it later (is a TIF ok?)
Thanks for the response.
1. I have the DOS program that came with the device - it works just fine.
2. The device doesn't have a menu as such. What it does have (which is good) is a 'debug mode' in which you can see everything sent to the device as hex and all responses from the device as reverse video hex. So in this respect I can see everything that is going on (or not as the case may be).
The only bad thing about the device (in either regular or debug mode) is that unless the message is correctly formatted: ie [stx, addr, code, data, etx, bcc, cr] with everything present and correct - including the bcc (see message above) then it ignores the whole message.
I can capture the data from the original DOS program and then send exactly the same bytes from my program without getting any response from the device. But as I have said above a few times, if I copy the string to the clipboard from the VB Watch Window (just before I do mscomm.output) and paste-to-host via Hyperterminal then it works. (Apart from the fact that a couple of the &H0a bytes are switched to &H8a)
The only other difference I can think of is that the gizmo sits behind an RS232-RS485 convertor as it only has a 9-pin RS485 comms socket on it.
As far as documentation goes, there are five sheets of paper - page one describes the protocol above and the next four pages are simply the different 'messages' you can send it and the responses you can expect to get back.
I have briefly spoken to the guy who wrote the original DOS program without getting anywhere - unfortunately he refuses to have anything to do with MS Windows PERIOD - he even uses a DOS email client and a DOS web browser.
Thanks again....
PS - If you really think the front page of the documentation will help then I will scan and email it later (is a TIF ok?)
ASKER
kfrick,
Sorry - it was my misprint/typo. It really is there as can be seen in the BCC calc code.
Sorry - it was my misprint/typo. It really is there as can be seen in the BCC calc code.
Just wondering, how is the 232/485 converter powered?? If, for example, it is DB25 on the RS232 side, and plugged directly into a DB25 COM2: of your PC, it might be drawing power from "unused" handshake pins that Hyperterminal might activate differently than VB......
Try playing with the DTREnable or RTSEnable properties of the msc1 object.........
Sheesh!
-kf
Try playing with the DTREnable or RTSEnable properties of the msc1 object.........
Sheesh!
-kf
ASKER
kfrick,
The convertor is 9-pin 485 => 25-pin 232.
I then have a 25 => 9 convertor to plug it into COM1
I have also tried it directly into my 25-pin COM2 but the results are the same.
As I said earlier, it is a 3 wire 485 (TX, RX, GND)
I'm sure a week ago this project looked like fun! :o)
The convertor is 9-pin 485 => 25-pin 232.
I then have a 25 => 9 convertor to plug it into COM1
I have also tried it directly into my 25-pin COM2 but the results are the same.
As I said earlier, it is a 3 wire 485 (TX, RX, GND)
I'm sure a week ago this project looked like fun! :o)
Usually those 9->25 adaptors pass all the handshaking lines thru from DB9 to DB25....the 485 converter still might be taking power from those handshaking lines.......
You might have to look at those signals with some test gear....Do you have a DVM or O'Scope available? Look at pins 4,5,6, and 20 at the DB25 connection during transmission from each session (DOS, VB, HyperTerm) to maybe see a difference there.....
I'm also a bit confused about "3-wire 485"....most 485 interfaces I have seen use 2 twisted pairs, 1 for RX+,RX- and 1 for TX+,TX-. But I don't think thats really your problem, cause the hardware all works with your DOS program.....
How far can you throw that thing???
-kf
You might have to look at those signals with some test gear....Do you have a DVM or O'Scope available? Look at pins 4,5,6, and 20 at the DB25 connection during transmission from each session (DOS, VB, HyperTerm) to maybe see a difference there.....
I'm also a bit confused about "3-wire 485"....most 485 interfaces I have seen use 2 twisted pairs, 1 for RX+,RX- and 1 for TX+,TX-. But I don't think thats really your problem, cause the hardware all works with your DOS program.....
How far can you throw that thing???
-kf
ASKER
kfrick,
The 485 output from the gizmo is in the form of a 5 hole strip connector with screws. I screwed half a metre of regular 3-core flex (which was supplied with the gizmo) into holes 2, 3 and 4 as instructed and then soldered up a 9-pin 485 from a 9-pin socket (again supplied with the gizmo for that very purpose).
Unfortunately I do not have a scope - I'm only a humble programmer! Scoping pins is out of my league I'm afraid - even soldering is pushing it for me.
I am still taking comfort about my soldering skills though from the fact that the DOS program works exactly as it should.
I could probably throw it a good 20 metres or so further than I could have done a few days ago!! I'm just regretting opening my big mouth and saying I could convert an old DOS program into a 32bit Windows app in a couple of days!
The 485 output from the gizmo is in the form of a 5 hole strip connector with screws. I screwed half a metre of regular 3-core flex (which was supplied with the gizmo) into holes 2, 3 and 4 as instructed and then soldered up a 9-pin 485 from a 9-pin socket (again supplied with the gizmo for that very purpose).
Unfortunately I do not have a scope - I'm only a humble programmer! Scoping pins is out of my league I'm afraid - even soldering is pushing it for me.
I am still taking comfort about my soldering skills though from the fact that the DOS program works exactly as it should.
I could probably throw it a good 20 metres or so further than I could have done a few days ago!! I'm just regretting opening my big mouth and saying I could convert an old DOS program into a 32bit Windows app in a couple of days!
If you can capture the string and was able to make it work through HyperTerminal, then put the string to your VB program and it should work... unless you set some of the parameters wrong for the MSComm... Try to step through
Dim lSendString as String
lstring = " Paste the stuff that worked in hyperTerminal
msc1.CommPort = 1
msc1.Settings = "1200,n,8,1"
msc1.PortOpen = True
msc1.output = lSendString
msc1.PortOpen = False
Dim lSendString as String
lstring = " Paste the stuff that worked in hyperTerminal
msc1.CommPort = 1
msc1.Settings = "1200,n,8,1"
msc1.PortOpen = True
msc1.output = lSendString
msc1.PortOpen = False
ASKER
OK.... YOU try and paste a few linefeeds into a literal string!! :o)
OK, I DVM'ed the DB9, and here's what I've found.....
You can control the voltages on PIN4(DTR) and PIN6(DSR) via the DTREnable and RTSEnable properties of the msc1 object as follows:
DTREnable=FALSE, DTR = -11VDC
DTREnable=TRUE, DTR = +11VDC
RTSEnable=FALSE, DSR = -11VDC
RTSEnable=TRUE, DSR = +11VDC
Your 232->485 gizmo most likely requires both voltages, and the setting of these properties will not bother the serial data flow so long as the Handshake property is set to "none".
Try setting the properties to opposite values, maybe this thing will work yet!
Crimeny!
-kf
You can control the voltages on PIN4(DTR) and PIN6(DSR) via the DTREnable and RTSEnable properties of the msc1 object as follows:
DTREnable=FALSE, DTR = -11VDC
DTREnable=TRUE, DTR = +11VDC
RTSEnable=FALSE, DSR = -11VDC
RTSEnable=TRUE, DSR = +11VDC
Your 232->485 gizmo most likely requires both voltages, and the setting of these properties will not bother the serial data flow so long as the Handshake property is set to "none".
Try setting the properties to opposite values, maybe this thing will work yet!
Crimeny!
-kf
ASKER
KF - YES YES YES YES YES YES YES YES YES YES !!!!!
DTREnable=FALSE, DTR = -11VDC
DTREnable=TRUE, DTR = +11VDC
RTSEnable=FALSE, DSR = -11VDC
RTSEnable=TRUE, DSR = +11VDC
Whatever it means - it works!!!
I always suspected the DB9 probably needed DVMing!
So.... I set them both to TRUE and bingo!! All the bytes displayed on the LCD as they should - and then all the reverse video responses from the gizmo.... just perfect.
Am I supposed to set them back to FALSE again sometime...? The reason for asking this is that although I see the response in the LCD, the OnComm doesn't fire (except when I set DTREnable = True) and the InBufferCount stays at zero.
By the way...I have also set the Rthreshold = 1
Anyway, many many thanks... send me an answer (Just say "See Comment") and you can have the points!! ....and I'll even increase them by a hundred!
DTREnable=FALSE, DTR = -11VDC
DTREnable=TRUE, DTR = +11VDC
RTSEnable=FALSE, DSR = -11VDC
RTSEnable=TRUE, DSR = +11VDC
Whatever it means - it works!!!
I always suspected the DB9 probably needed DVMing!
So.... I set them both to TRUE and bingo!! All the bytes displayed on the LCD as they should - and then all the reverse video responses from the gizmo.... just perfect.
Am I supposed to set them back to FALSE again sometime...? The reason for asking this is that although I see the response in the LCD, the OnComm doesn't fire (except when I set DTREnable = True) and the InBufferCount stays at zero.
By the way...I have also set the Rthreshold = 1
Anyway, many many thanks... send me an answer (Just say "See Comment") and you can have the points!! ....and I'll even increase them by a hundred!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Oh, sorry, I see that it Might have an impact on Data Flow after all, at least on RX'ing.......
Maybe you shuold try enabling RTS Handshaking?!??
ANYWAY....play around with it, have fun, and congratulations on your superb soldering skills!
-kf
Maybe you shuold try enabling RTS Handshaking?!??
ANYWAY....play around with it, have fun, and congratulations on your superb soldering skills!
-kf
ASKER
kfrick,
Many thanks once again... just let me know if you need anything soldering...
Upland
PS - I have tried the handshaking set to all four settings and none of them seem to allow me to receive - ie. msc1.InBufferCount never gets > 0.
What else can I play around with? Should I start a new question? :o(
Many thanks once again... just let me know if you need anything soldering...
Upland
PS - I have tried the handshaking set to all four settings and none of them seem to allow me to receive - ie. msc1.InBufferCount never gets > 0.
What else can I play around with? Should I start a new question? :o(
You can toggle those properties at will, maybe set them one way to TX to the gizmo, then set'em back to RX.......
Maybe there is a combination of all these properties that will work in both directions for you...you'll just have to figure it all out, there's no black magic here......
Glad you got it working!
-kf
Maybe there is a combination of all these properties that will work in both directions for you...you'll just have to figure it all out, there's no black magic here......
Glad you got it working!
-kf
Sound like you need to send it Binary, because you are talking about send Bytes...