1. Home
  2. Electronics Design
  3. MSComm and USB to RS485 Converters (head hurting now, must have martini)

MSComm and USB to RS485 Converters (head hurting now, must have martini)

I am having some weirdness and was wondering if any of the readers of this group are experiencing the something similar.

I was using a Quatech QSU200/300 which worked great but then upgraded to their ESU series which do not work with my in house application. My senior SW developer is out for a spell. Here is what is unique about his application although I do not understand it in detail.

  1. The MSComm control is created in memory by his application which is a .dll that we then use in various test engineering applications
  2. As I look around in his code I see he commented out a "read from device" section of code in his .dll source for setting baudrate, inputmode, etc. Some devices need to be "woke up"? Sounds interesting, hmmmmm.
  3. Hyperteminal to Hypterminal link ups work
  4. Our applications are "talking" to embedded uC boards using LT1785 RS485 driver by Linear.

I am going to try and step through his test example with the .dll loaded in the project today to see what is going on but first I have to get it to run because there are undeclared variables scattered through out.

Thanks in advance for having a look at my dilemna.

Ed V.

PS - mmmmmmmm, martini

PPS -

  1. RS232 to RS485 converters work fine but I am out of serial ports due my IT departments drive to use PCs that have fewer everthings.
  2. BB-elec Ulinx USB converters do this also
  3. If you keep the gin in the freezer and put pop a couple olives in your mouth you can skip those tedious shaker to glass to mouth steps
Reply to
EdV
Loading thread data ...

Check the default baud rate settings in windows if the MScomm isn't being instructed to set the baud rates. Also, Check the name being used.. My Self, I don't use MScomm since it's a MS thing and requires a license key to operate it. I just go for the raw API levels.

Make sure the USB device gets mapped in as a comport and operating before the App starts.

--
"I\'m never wrong, once i thought i was, but was mistaken"
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5
Reply to
Jamie

If you are out of serial ports, go to ebay and search for "edgeport". The edgeport USB to serial port adapters are very good professional products. A vodka martini straight up is a an upscale way to say "give me a glass of vodka". Works for me. Per the late Hunter S. Thompson, "Always trust your bartender!"

Reply to
Si Ballenger

quoted text -

I found that data is going out but the repsonse from the embedded controller is "wrong". I think it is time to get a serial protocol analyzer or a serial port sniffer and see what is coming out to see if it is corrupeted somehow.

Reply to
EdV

quoted text -

sounds like a timing error or parity error..

--
"I\'m never wrong, once i thought i was, but was mistaken"
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5
Reply to
Jamie

Hide quoted text -

You could try Portmon. It's been a while since I used it but IIRC it had to be started before starting the COM routine. Since I've got a DSO with a long buffer I use that nowadays, at the point where it is RS232 again.

--
Regards, Joerg

http://www.analogconsultants.com/
Reply to
Joerg

this.http://webpages.charter.net/jamie_5-Hide quoted text -

Well I threw the kitchen sink at it and we found out that we need to wait for the USB driver to finish poking around before we read the input bufffer after we send out a command. Ah the simple joys of looping until something is in the buffer. Why we don't use a routine that triggers on an MSComm event is still eating at me but I am tired of questions.

Thanks much, Ed V.

Reply to
EdV

this.http://webpages.charter.net/jamie_5-Hide quoted text -

You're just creating way to much work for your self. Create a secondary thread do the waiting there. Send notification messages via a user message to the main thread that will read the incoming from a circular buffer.

--
"I\'m never wrong, once i thought i was, but was mistaken"
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5
Reply to
Jamie

this.http://webpages.charter.net/jamie_5-Hide quoted text -

Don't know. Some SW won't use MSComm because of the licensing restrictions that it comes with. I have no idea whatsoever why Microsoft put those restrictions in place. To me it seems like a shot into their own foot because it stifles Excel VBA apps and thus Excel sales.

Sounds like a good time for that Martini :-)

--
Regards, Joerg

http://www.analogconsultants.com/
Reply to
Joerg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.