Announcement

Collapse
No announcement yet.

Serial Com-Port with Windows NT

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Bruce Fech
    replied
    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.

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

    Leave a comment:


  • Werner Lentz
    replied
    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]

    Leave a comment:


  • Kurt Schultz
    replied
    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]

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Mel Bishop
    replied
    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.


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

    Leave a comment:


  • Werner Lentz
    replied
    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]

    Leave a comment:


  • Tom Hanlin
    replied
    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

    Leave a comment:


  • Mel Bishop
    replied
    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).]

    Leave a comment:


  • Clay Clear
    replied
    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.



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

    Leave a comment:


  • Werner Lentz
    replied
    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]

    Leave a comment:


  • Mel Bishop
    replied
    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.



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

    Leave a comment:


  • Clay Clear
    replied
    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.


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

    Leave a comment:


  • Werner Lentz
    replied
    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]

    Leave a comment:


  • Clay Clear
    replied
    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).]

    Leave a comment:


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


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

    Leave a comment:


  • Werner Lentz
    replied
    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]

    Leave a comment:


  • Tom Hanlin
    replied
    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

    Leave a comment:


  • Werner Lentz
    started a topic Serial Com-Port with Windows NT

    Serial Com-Port with Windows NT

    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]
Working...
X