|
Usually this is because you have the wrong port settings,
the wrong cable, or your device is improperly configured. More
information.
The reason that you are getting unrecognizable
ASCII characters in the Analyze window is because you probably
have not setup the serial communication parameters correctly
in Winwedge. In order to fix this problem you will have to find
out the communication parameters for your device and set up WinWedge
to exactly match these parameters. If you do not know the parameters
used by your device you will need to either consult the users
manual for the device or contact its manufacturer for this information.
You can set up WinWedge by selecting the SETTINGS option from the PORT menu,
and select the appropriate serial communications parameters. Once WinWedge
is configured properly you should see recognizable data in the analyze window.
You can also use the Port Analyze feature
in the Software Wedge to try different parameters until
you get data that appears correct. Try different baud rates
using seven data bits, even parity, and one
stop bit until you get data that looks either partially
or completely correct. Finally, try different combinations
of parity, number of data bits and number of stop bits
until all data is correct. Most devices use either seven
data bits with Even or Odd parity or eight data bits with
No Parity. One stop bit is also used more frequently than
two.
It is also worth noting that some serial
devices will still send strange characters even when the
communications settings match exactly. Some older devices
that were designed for outputting to serial printers will
often send printer control codes that appear as garbage
in the analyze window. In many cases there is a setting
on the device that can disable this, but you should contact
the manufacturer of the device to find out whether the
data you are receiving is normal, and what your options
are. Even those that do not send printer control characters
will often send unprintable characters such as STX, ETX,
carriage return and Line feeds as part of the data stream.
The manual that comes with your serial device should provide
you with sample data that you can compare what you are
actually receiving.
The fact that you are getting data in the analyze window
and not when the wedge is activated implies that the communication
is established and the wedge is receiving data.
The first thing you should check is whether
or not the WinWedge Window (when Activated) is displaying
your data. If the data appears there but not in your application,
then check which Mode you are in (Keystrokes or DDE) and
verify that the settings are correct. It is important to
realise that Setting the Wedge for DDE Mode will not result
in the data being sent to any open Window like it can in
keystrokes mode. In Excel for instance you must write macros
to actually manage the DDE transactions.
There is also a small number of applications
(such as applications that run in a DOS Window) that cannot
receive the keystrokes from WinWedge. Try sending the data
into Notepad and see if that works, if it does then it
could be an incompatibility with the application you are
trying to send the data to.
If no data appears in the WinWedge Window
when it is activated then the record structure is not defined
properly. To correct this problem take another look at
the data in the Analyze window and make sure that the "Start
of Record Event" and the "End of Record Event" have
been defined properly. By default, WinWedge expects a carriage
return as the end of a record. This will appear in the
Analyze window as a music note character. If you do not
receive this character from your device then it means that
WinWedge received your data but is still waiting for this
carriage return character to signify the end of the record
before transmitting the data to your application. To correct
the problem change the end of record event to a time delay
between records, a fixed number of bytes received or a
character that your device does transmit such as an ETX.
If you are confident that your start and
end of record events are correctly defined, make sure that
you have selected the proper parsing and filtering parameters
for each field. Check your delimiters or field lengths,
and try removing any filters you set to see if that corrects
the problem.
Finally, if you are inputting very large
data records, you may also need to increase the size of
the serial input buffer.
The reason that the data is going into Notepad is because
it is the default setting in WinWedge. If you want the data
to go into another application, you must specify that application
by entering the appropriate "Application Title Bar Text".
To specify the application, choose the "Send Keystrokes
To" option under the MODE menu and specify the appropriate
Title Bar Text for the application that you want to send
data to. The title bar text is the text that appears in the
title bar of the application’s main window. If you want
the wedge to launch your application the first time it receives
any data, you can also specify the full path for the application’s
executable file name in the text box labeled "Command
Line". Note: You must specify the full path. For example
if you have any application called Excel.Exe under the directory "C:\MSOFFICE",
then your complete path would be C:\MSOFFICE\EXCEL.EXE.
You can use the following six keywords
to place the date and time stamps: {Year},
{Month}, {Day}, {Hour}, {Minute},
and {Second}. If you would like the date and or time stamp
placed before the data, then you would place the date and
time stamp functions in the "Record Preamble" text
box. If you would like the date and time stamp to be placed
after the data, then you would place the function in the "Field
Postamble" text box. For example if you only want the
date stamp before the data, then you place the following
keywords in the "Record Preamble" text box. {Month}/{Day}/{Year}.
The "Timer Controlled Output" can be used to
send a string or prompt to a device at a specific time interval.
To set up the timer controlled output select "Serial
Output Strings" from the DEFINE menu and specify the
time interval and the timer controlled output string that
you want sent out the serial port. If you want the timer
to be enabled as soon as the wedge is activated, then check
the "Enable Timer On Activation" option. If you
are using the wedge in send keystrokes mode, then you can
enable and disable the timer from the QUIT menu after the
wedge has been activated or you can use the [TIMER-ON]
and [TIMER-OFF] DDE commands to turn on and off the timer.
It is possible to work with another program while WinWedge
is running on the same PC. There are several ways that you
can set up WinWedge to work. If you simply want to log data
to a disk file, you can set up WinWedge in "Log To Disk" mode
and all data will be logged to a disk file in the background
while you work with some other program in the foreground.
In a similar manner, you can set up WinWedge to communicate
with another application using DDE (Dynamic Data Exchange).
With DDE, again, all operations occur in the background so
you can have WinWedge and the application that is receiving
data from the Wedge running in the background while you work
with another program in the foreground.
WinWedge can also be configured to convert incoming serial data to "keystrokes" and
therefore trick other programs into accepting the incoming serial data as if
it were being typed in on the keyboard. In order for this to work correctly,
the other application must be running in the foreground, which makes it more
difficult to work with a separate application while collecting data with the
Wedge.
WinWedge is designed as a tool for inputting serial data
from instrumentation into a PC. It is not an application
that stores data or acts as a database where date information
plays any role in the functionality of the product.
It generally does not have anything to do with dates and times therefore the
year 2000 issue does not affect the product to any great extent. Although it
does have some simple date and time stamping capabilities, in the vast majority
of applications, the Wedge is not used to generate date information. In WinWedge
for Windows, the system date is used for all date functions and is generated
by the operating system (which is fully year 2000 compliant).
Some of the date stamp functionality in the Wedge has been designed to provide
the year portion in a 2 digit format with the century portion of the date either
excluded altogether or hard coded by the user. In the rare circumstances where
a user has the Software Wedge configured to provide a full four digit year
portion in a date stamp, you may have to edit their configuration for the Wedge
to hard code in a "20" instead of a "19". This process
is trivially easy. (After making the change you should not need to do it again
for another 100 years.)
WinWedge does not have the ability to calculate check
sums or make logical decisions on data. This means that it
does not directly support any high level protocols like modbus.
It does not mean that you cannot use WinWedge to communicate
with modbus devices. You can, in most cases, implement any
protocol that you like, including Modbus, using features
of the application that will be using the Software Wedge.
For example, you could use the macro language
in whatever program you are feeding data into to implement
the protocol, and then simply use the Software Wedge to
do the serial input and output. If you were using a program
like Excel, Access, Wonderware, Fix DMACS, etc., you could
use the macro or script languages in these programs to
calculate any necessary checksums on your data or perform
logical functions to control the flow of data. WinWedge
would simply act as a tool providing the other application
with a way to both send and receive serial data.
This only happens in Excel 2000 when you
choose Exit from the File menu, it does not happen if you
click on the X in the top right hand corner of the application.
Normally when you quit an application that was connected
via DDE to another application, the DDE Links are automatically
terminated, but a bug in Excel 2000 causes this error.
To fix the problem add the following line of code to the
end of the Auto_Close Macro:
DDETerminate
chan
Yes. All current versions of WinWedge including
the 16 bit versions will work with Windows 2000 and XP.
Versions released prior to 1998 may not work correctly,
and we recommend you upgrade to the current release. To
check your version go to the Help Menu and click
on About.
Possible causes of this error include:
- Another instance of WinWedge is running and accessing
that port.
- Another application (e.g. Hotsync for a Palm Pilot) is
running and accessing that port.
- The port has been disabled. Common on laptops with multiple
devices attached in order to free up an interrupt (IRQ).
- The port is malfunctioning or absent. Check in Control
Panel: try removing it and rebooting/reinstall the drivers.
- The Com Port was disabled in your
Bios.
- The Serial device was auto detected
by NT/2000 as a Serial Mouse.
This error is caused by your buffer size
settings. NT based systems will not accept settings that
are not an integer multiple of 2. For example setting your
Input buffer size to 32767 will cause this error, but setting
it to 32766 will not.
Usually the same or similar error will occur
when trying to access that com port from another piece
of software such as HyperTerminal.
In most cases removing the com port in the
Device Manager and restarting Windows (which will then
automatically detect the com port and reinstall the driver)
will resolve this problem. If after restarting the problem
has not been resolved manually reinstall the driver: Open
the Control Panel, double click on the System Icon, click
on the Hardware Tab then open the Device Manager. Scroll
Down to the Ports and doble click on the problem port.
Click on the Driver Tab and select Update Driver. Let Windows
search for a suitable driver and even if it says the current
driver is the best one make sure you follow through the
wizard until it is finished. This will reinstall the Driver.
No reboot should be necessary.
Usually the same or similar error will occur
when trying to access that com port from another piece
of software such as HyperTerminal.
In most cases removing the com port in the
Device Manager and restarting Windows (which will then
automatically detect the com port and reinstall the driver)
will resolve this problem. If after restarting the problem
has not been resolved manually reinstall the driver: Open
the Control Panel, double click on the System Icon, click
on the Hardware Tab then open the Device Manager. Scroll
Down to the Ports and doble click on the problem port.
Click on the Driver Tab and select Update Driver. Let Windows
search for a suitable driver and even if it says the current
driver is the best one make sure you follow through the
wizard until it is finished. This will reinstall the Driver.
No reboot should be necessary.
|
