com port problem

[Guest]

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

At my job we have older software that communicates to controllers through com
ports. This will work fine with Windows 98 but not with XP. We have
VirtualPC to recreate a Windows 98 environment on a computer with XP, and
that still worked. I understand that XP has given the kernel priority to the
ports so that the user cannot interfere with anything that it is doing, but
there has to be a way to get through to the ports. One example is we are
running a file that is to be cut on a glass cutting machine. The table gets
the instructions from the computer one at a time (although at a very high
rate). This will work for a while, yet then the entire file is dumped into
the controller, instead of one at a time. Another example is just
communicating through the com port with a PLC. I have even tried a solution
called Porttalk. It is supposed to open the ports for an exe to use, yet
this still has not worked for me. I am hoping to get any information that
can help me solve this problem.
I am also looking to re-writing some software that communicates through
these ports and does so fine with Windows 98. I know that this can be done
because many of the programs have a newer version that will work for XP. I
was wondering if anyone had any information on how programmers gained access
to these ports, or any advice on making this happen with XP. Any help is
greatly appreciated. Thanks in advance

 

[Guest]

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

Hi

Well easy solution get you an low-end pc load win98 and
just run that pc for that particular program that your trying
to run, why give yourself the headache keep it simple

Al


stu96art wrote:

> At my job we have older software that communicates to controllers through com
> ports. This will work fine with Windows 98 but not with XP. We have
> VirtualPC to recreate a Windows 98 environment on a computer with XP, and
> that still worked. I understand that XP has given the kernel priority to the
> ports so that the user cannot interfere with anything that it is doing, but
> there has to be a way to get through to the ports. One example is we are
> running a file that is to be cut on a glass cutting machine. The table gets
> the instructions from the computer one at a time (although at a very high
> rate). This will work for a while, yet then the entire file is dumped into
> the controller, instead of one at a time. Another example is just
> communicating through the com port with a PLC. I have even tried a solution
> called Porttalk. It is supposed to open the ports for an exe to use, yet
> this still has not worked for me. I am hoping to get any information that
> can help me solve this problem.
> I am also looking to re-writing some software that communicates through
> these ports and does so fine with Windows 98. I know that this can be done
> because many of the programs have a newer version that will work for XP. I
> was wondering if anyone had any information on how programmers gained access
> to these ports, or any advice on making this happen with XP. Any help is
> greatly appreciated. Thanks in advance

 

[Guest]

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

I am working on converting software over to XP. This is just an example and
I figured that if I could get this to work, then I could have a heads up on
the other. Thanks for your help, and any further assistance is greatly
appreciated.

"stu96art" wrote:

> At my job we have older software that communicates to controllers through com
> ports. This will work fine with Windows 98 but not with XP. We have
> VirtualPC to recreate a Windows 98 environment on a computer with XP, and
> that still worked. I understand that XP has given the kernel priority to the
> ports so that the user cannot interfere with anything that it is doing, but
> there has to be a way to get through to the ports. One example is we are
> running a file that is to be cut on a glass cutting machine. The table gets
> the instructions from the computer one at a time (although at a very high
> rate). This will work for a while, yet then the entire file is dumped into
> the controller, instead of one at a time. Another example is just
> communicating through the com port with a PLC. I have even tried a solution
> called Porttalk. It is supposed to open the ports for an exe to use, yet
> this still has not worked for me. I am hoping to get any information that
> can help me solve this problem.
> I am also looking to re-writing some software that communicates through
> these ports and does so fine with Windows 98. I know that this can be done
> because many of the programs have a newer version that will work for XP. I
> was wondering if anyone had any information on how programmers gained access
> to these ports, or any advice on making this happen with XP. Any help is
> greatly appreciated. Thanks in advance

 

[Guest]

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

If the DOS or Windows 9x program used standard data transfer
principles, then the serial ports should have worked just fine
in XP. XP serial ports work fine even with DOS programs if
the DOS programs used standard access methods. However some
wanted to do weird things especially with handshake lines that
is not standard use.

Quite possible that problem is not the software. Quite
possible it is how the serial port defaults. For example, a
peripheral needs a line hung in a certain direction. That
line was left in a default state when running Windows 9x.
However same port left in a state in Windows 98 will instead
be put by Windows XP to what should always have been the
default state. Then the peripheral does not work.

Remember, serial port used in PCs is a non-standard
standard. Numerous implementations are based upon default
states that violate RS-232. We use those serial ports most
often for functions that the RS-232 was not intended.
Therefore, I made some good money by taking an oscilloscope
and learning how every unique serial port was setup.

The original RS-232 was only for a Data Terminal Equipment
(DTE) to talk to a Data Communication Equipment (DCE being a
modem). You are already using it for a function it was not
intended. We do this often. What you have is a kludge
application of that RS-232 function. Made more complex if the
controller uses those other handshake wires. Therefore learn
details of what those other signal wires must be or be set
at. Windows 98 application software could have left DTR
sitting high but XP automatically leaves it low. Had the
program used serial port in a more standard way, then it would
have worked just fine in XP. I still use DOS programs I had
written long ago on XP and other Windows NT based systems.

Too many unprovided details to really answer your question.
You must provide such signaling details to get a useful
answer.

stu96art wrote:
> I am working on converting software over to XP. This is just an
> example and I figured that if I could get this to work, then I
> could have a heads up on the other. Thanks for your help, and
> any further assistance is greatly appreciated.

 

[Guest]

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

Thanks, that is good information. Could you please let me know what I can do
in order to give you details about the problem, so we can work on a solution.
Am I correct in saying that it sounds like your solution would only work for
one computer?? I am looking to make this software work and any XP machine.
Thanks again for all of your help and let me know about giving the details.

 

[Guest]

Archived from groups: microsoft.public.windowsxp.hardware (More info?)

Start with how RS-232 is wired. Remember that RS-232 in its
most standard form involves handshaking the RTS/CTS lines (25
pin connector pins 4 & 5; 9 pin connector pins 7 & 8) and
handshaking DTR / DSR lines (pins 20 or 7 and 6 or 6). Also
some designs utilize the CD signal (Communication Device
detect). IOW start with what signals the controller want to
use. Some of those signals may be jumpered inside a custom
cable so that program does not see signals that controller
needs.

stu96art wrote:
> Thanks, that is good information. Could you please let me know what
> I can do in order to give you details about the problem, so we can
> work on a solution. Am I correct in saying that it sounds like
> your solution would only work for one computer?? I am looking to
> make this software work and any XP machine. Thanks again for all
> of your help and let me know about giving the details.