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

EdV wrote:
On Nov 19, 8:29 pm, Joerg <notthisjoerg...@xxxxxxxxxxxxxxxxxxxxx>
wrote:
EdV wrote:
On Nov 16, 5:40 pm, Jamie
<jamie_ka1lpa_not_valid_after_ka1l...@xxxxxxxxxxx> wrote:
EdV wrote:
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. TheMSCommcontrol 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
Check the default baud rate settings in windows if theMScommisn't
being instructed to set the baud rates. Also, Check the name being
used..
My Self, I don't useMScommsince 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-Hide quoted text -
- Show 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.
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/- Hide quoted text -

- Show 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.


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/
.

Relevant Pages