Serial Com-Port with Windows NT

[Werner Lentz]

Hello, I'm still trying to move a PBDos program to a Windows NT machine.
The program communicates with a PLC through the COM1 port.
The problem is now that the communication doesn't work. It's like the cable is disconnected.
The serial port of the computer is ok. We've checked with a serial mouse.
In the system configuration I'can't find any other program which tries to use the com port also.

Has anybody a hint which might help?
Thanks

------------------
Werner Lentz
[email protected]

[Tom Hanlin]

If you have Windows fax services installed, try turning them off.
Make sure there are no bent pins on the serial cable, then see that
it's securely attached.

Do you get an error code when you OPEN COM1? If so, what? If not,
double-check your comm settings.

------------------
Tom Hanlin
PowerBASIC Staff

[Werner Lentz]

Thanks Tom,
there are no fax services installed on that computer.
The cable is ok because it works fine if I go back to the old computer.
The error code I receive is '24 - device timeout'.
Sorry, I forgot that information first time.
Any idea?

------------------
Werner Lentz
[email protected]

[Mel Bishop]

Have you checked your flow control in windows to make sure it
matches the cable you have?


------------------

[Clay Clear]

Werner,

Mel's idea is a good one to check for, also, are you SURE that the
serial ports actually defined (hardware wise) on the NT machine
match the serial port numbers on your old machine? In other words,
are you sure that the NT machine even HAS serial port " # 1"? Maybe
its hardware is actually defined as serial # 2, or something?



[This message has been edited by Clay Clear (edited May 22, 2003).]

[Werner Lentz]

Clay, the port connection on the PC backside says it's port 1. So I assume it's right.
Nethertheless NT says that it has port 1 and 2, even there is only one hardware port on the computer, which confuses me also.
Must the port have the same IO address and interrupt as on the old computer?

Mel what do you mean with 'check your flow control in windows'?

------------------
Werner Lentz
[email protected]

[Clay Clear]

Werner,

"COM1", "COM2", are, FOR MORE THE MOST PART, hardcoded into
PB/DOS as far as which interrupts and I/O addresses they use. The IRQ's,
however, may be programmatically set in the "OPEN COMx" statement.
Changing the I/O addresses is a bit trickier. I do not even know
if NT-class OS's will allow it. Tom or Lance will have to answer that
one.

the short answer: yes, definitely. If your program is coded to use
one I/O address and/or IRQ, then it will definitely fail on a machine
which does not have that hardware setup, or if you try to use it on
a different serial port than for which it was programmed.

I have never used NT, so I do not know why it would show BOTH
ports 1 and 2 if the 'puter only has one of them. Maybe the NT
machine has an interface card installed, in addition to the
builtin port? If it does indeed have one, and therefore really does
have two serial ports, then fixing your problem may be as simple as
connecting your hardware to the correct port. However, it would be
pretty obvious if an interface card were installed, so it most likely
does not have one, based on what you said.


------------------

[Mel Bishop]

Originally posted by Werner Lentz:
Mel what do you mean with 'check your flow control in windows'?

Open up control panel > device manager and right click on the
COM port you are using. You should have three options: Xon/Xoff,
Hardware, None. Play with these settings.

As a word of note: If you are getting a device time-out, you
may have only a 3-wire modem cable. This will require you to
use Xon/Xoff software flow control or buy a "real" modem cable.



------------------

[Werner Lentz]

Mel, hope your hint goes into the right direction. I've checked the cable.
It's 9 pin on computer side and 25 pin on PLC side. The 9 pins are fully connected.
So I'll reinstall the NT computer again as soon as possible and try the Xon/Xoff flow control.
But if this is the reason, why does it work with DOS?


------------------
Werner Lentz
[email protected]

[Clay Clear]

Werner,

Mel's advice might still be valid because your DOS machine uses
the correct flow control, but your NT machine does not. However,
I have NO idea of how to set a flow control on a pure DOS machine.



------------------

[Mel Bishop]

Originally posted by Werner Lentz:
But if this is the reason, why does it work with DOS?

Programs under DOS without windows can access the com port
directly. With windows loaded, the DOS program MUST pass the
data through the interface (driver). i.e., The data goes from
the program to the windows interface (driver) then out to the
com port.

At least, that's the way I think it works. Hope my suggestion
works.

I have NO idea of how to set a flow control on a pure DOS machine.

To use hardware flow control, (example):
open "com1:9600,n,8,1" as #1

To use software flow control,
open "com1:9600,n,8,1,rs,cs,ds,cd" as #1

I'm typing this off-the-cuff so...

The 4 entrys in the 2nd example switches off (ignores) the pins
allowing for hardware flow control.


------------------


[This message has been edited by Mel Bishop (edited May 22, 2003).]

[Tom Hanlin]

If NT thinks you have two comm ports, you probably have two comm ports;
or, possibly, you have a strange arrangement, where you have only one
comm port that is mapped to COM2 instead of COM1. The port information
on the back of the computer doesn't really mean anything-- the ports
may be turned off, disconnected or remapped at the hardware level, BIOS
setup level, or by NT itself.

For grins, you might try this:

def seg=&H40
print hex$(peeki(0))
print hex$(peeki(2))

For a normal pair of comm ports, you would expect to see 3F8 and 2F8,
in that order.

If the computer has an internal modem, that's probably taking one of
the comm ports.

------------------
Tom Hanlin
PowerBASIC Staff

[Werner Lentz]

Thanks so far.
For my understanding, in the help for OPEN COM statement I've found:

'By default, COM1 and COM3 use IRQ4, while COM2 and COM4 use IRQ3. Use
'of non-standard interrupt request lines (with the IR option) must be
'done with caution, as an error can easily cause a system crash.
'Port addresses are read from the BIOS data table located at 0:0400h.

Does that mean, that PBDOS compiles a program, which is specific to the computer on which it is running.
Is the Port address coded into the compiled program?
If so, a program coded with COM1 at a certain hex address will not run on an computer which has COM1 at a different hex address?


------------------
Werner Lentz
[email protected]

[Mel Bishop]

Originally posted by Werner Lentz:
...which is specific to the computer on which it is running.

No. All IBM compatable computers come with a default standard.
The standard for COM1 and COM3, 2 & 4 are universal. You can
change the IRQ's and ports but that would force you to write
programs that are unique to your particular CPU box.

As long as one doesn't change the default settings, you program
should run on any IBM style computer in the world.


------------------

[Lance Edmonds]

Tom's answer is probably covered this question the best, but to elaborate a little more...

With modern PC hardware, the BIOS generally configures (by default) the serial ports so they are compatible with traditional DOS settings (COM1=IRQ4,&H3F8, etc), but any PNP-aware OS such as Windows can remap these settings so that they are actually using completely different IRQ's, etc. In this case, booting to DOS will give you one set of port configurations, and a completely different set when Windows is running.

The first method of discovery of the port setting can be done through the Windows hardware device manager (it's in the SYSTEM applet in Control Panel) which should tell you the resources that the ports are using. The info shown there will generally show accurate values unless the resources have been manually set (which bypasses the automatic setup), but there is no absolute guarantee they are correct unless you can use the serial port from a Windows application to verify it is working properly.

Now, many BIOS's provide a "PNP OS" setting that allows the OS to reorganize the hardware, so you may need to disable that setting in the BIOS to ensure that the ports remain locked to the expected IRQ and base address, etc.

That said, Windows NT/2000/XP uses a HAL (Hardware Accessibility Layer) that virtualizes ALL hardware so that applications can never actually deal directly with the hardware.

That is, the HAL actually sits between the hardware and the application, so all hardware I/O is actually being "managed" to ensure that the OS security is not breached. This means that Windows has the last word on what data and port state(s) it deems your app should see, if indeed it will even allow your app to work with the target hardware!

In most cases, serial comms will work just fine with the virtualized hardware of Windows NT/2000/XP, but interference with xon/xoff signals can be a problem.

In summary, you need to be sure that the port settings and IRQ actually match with what the port is using under the control of Windows, and you may need to fiddle with the BIOS and Windows Hardware Manager to ensure the port settings are "standard".

Good luck!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Kurt Schultz]

Hi, Werner -

You may be tilting at windmills.

If I remember correctly, Windows in general doesn't want you to
have direct access to the serial ports (DOS didn't care as
much).

Your solution may be to use API calls, so that the appropriate
NT serial I/O drivers are requested in a way that keeps NT
happy.

A big part of the problem has to do with the OS needing to keep
track of which app is using which hardware in a multi-threaded
environment. If it can't keep track, the machine would go hard
flakey.


Kurt Schultz
[email protected]

[Werner Lentz]

Thanks all,
last friday I had the chance to make the tests and the hint with Xon/Xoff
was right. Communication is now working.
You've helped me a lot.
Best regards.

------------------
Werner Lentz
[email protected]

[Bruce Fech]

Werner,

I think Lance got it right with his hal comment.
I also had all kinds of problems getting my DOS apps on NT to talk to both AB SLC5's and Motorola MOSCAD's.

My solution was to write a very small app in PBWin and use it as a driver to do all the COM I/O, and then pass the data back and forth to both my apps and Intellution's FIX32 via DDE.
I have never had a comm failure using it this way, everything has been working great for years without any kind of failures or data loss.

Hope this helps.

------------------