I am developing Delphi application on Delphi 2010 XE RAD Studio under Windows 7. My application talks on the serial port non-stop. I am using AsyncPro for Delphi 2010. Serial communication and everything else on the computer I develop with works great without any problem. However, when my release version of my application is run on another Windows 7 system, serial communication completely fails. We probed the serial communication itself for an answer and found out that Request to Send (RTS) line is not dropped right after sending all the bytes, whereas on my development computer RTS line is dropped correctly.
Even when I explicitly drop the RTS line to low or false state, RTS line doesn't drop right away but after good 15 milliseconds. Thus, serial communication on my release version is failing.
Am I missing important information about Windows 7 and serial communication issues?
UPDATE: I just found the bug with my Aysncpro 5.0 for Delphi XE. It is weird. When my Delphi XE IDE is open or running, my program is communicating flawlessly. When I shutdown or close my Delphi XE IDE while my program is running, the same program doesn't communicate very well or it times out.
Chime in if you have any idea why it is happening.
Any help will be appreciated.
Thank you,
Sounds like a timer resolution problem to me. I had the same problem trying to write to a USB FTDI driver using an event based timer with timeSetEvent()... When Delphi loads, it changes the timer resolution to less than 20ms, which made my app work fine. When the IDE wasn't running I couldn't get things to work below 20ms +/- 5ms (the default Windows resolution I believe).
To fix the problem, I call timeBeginPeriod(1) in the thread to set the minimum system wide timer resolution.
I believe this affects the resolution of other time based events, because I get better than +/-5ms accuracy on other (non-multimedia timer) wait events in my app when I use timeBeginPeriod().
So, what I'm suggesting is that somewhere in the AsyncPro code it's using some time based event or call back... That would be affected by Delphi's change to the timer resolution when it is loaded. Try calling timeBeginPeriod(1) somewhere in your app when it starts and see if there is a change.
Oh, and don't forget to call timeEndPeriod(1) when your app shuts down.
N#
Last few times I saw random inexplicable crap like I tried everything, and was unable to solve it for months.
I found two different common causes:
ASYNC Professional has some weird glitches that I was unable to solve, so I dropped it, and moved to TComPort.
I found all kinds of strange flow control bugs in USB drivers. I found FTDI chipset USB-to-serial more reliable than others.
The Debug build not having the problem could be two things:
Certain timing changes cause the USB device driver that was failing, not to fail.
You actually have some kind of a thread problem, like a race condition, leading to your ASync Pro components messing up in a way that looks like something's happening to your port, but really it's ASYNC pro.
The easiest thing to do is to try it with a different USB to serial adapter, and if that doesn't solve your problem, I would be tempted to pull out AsyncPro which I have also had many random problems with, and either write your own serial port class, or use TComPort. I have some long experience using a TThread that uses a com port "reader/writer" class and have found this the most reliable way to go, because you can tweak low level elements of the Win32 overlapped-IO calls, directly to meet your needs, and also be sure that you don't have some extra complexity/overhead getting in your way. (AsyncPro's complexity and overhead, are a significant potential source of bugs.)
This has to be a driver problem on the other machine, surely? Hardware flow control works fine on my W7 test box as well, (and Vista development machine). If your Apro has set the DCB correctly, and it sounds like it does because of your 'manual' tests, the driver should work...
15ms for a 'manual' RTS change from user mode is sad, but not at all unusual on Windows - that's why the driver should do it.
Rgds,
Martin
Related
We are developing a console software, with Delphi 7.
To simplify, this software is using an embedded TCP server to answer to external requests from a CGI. These answers contain generated HTML pages with Teechart graphs, and data extracted from a database, using DbExpress.
On Windows 7 and Windows 2008 R2 servers, we noticed significant increase of the run time of our software – 2 or 3 times the original process time on Windows XP or Windows Server 2003 – in a standard context of execution: software launched as a Service with the system user account.
But when our software is launched as a simple user, from command prompt, or directly from the IDE (debug mode), the problem simply disappear.
My first question is : has anyone already noticed this problem?
Using ProcessExplorer, we also noticed that when the software is launched as a service, there is no GDI Handle created, nor is a User Handle. But when the software is launched with a user account, some of these handles are created. With Windows XP and Windows Server 2003, either the software is launched as a service or with a simple user account, these handles are always created.
Can this observation be linked with our problem?
If you already noticed these behaviour, how did you fix the problem?
Because of the many places where we relied on Windows API CompareString function we could not replace it by non Windows versions.
But, we found that instead of using LOCAL_USER_DEFAULT by using LOCALE_INVARIANT($07) the API works fine.
So, we decided to hack the constant value as defined in Windows and over write it everywhere where it was used for comparison purposes with a conditional compilation like this:
{$IFDEF OVERLOAD_LUD}
const
LOCALE_INVARIANT = $7;
LOCALE_USER_DEFAULT = LOCALE_INVARIANT;
{$ENDIF}
That solved the problem.
I think we found the source of our problems. So for those that are looking for a solution, here's what we’ve done:
Delays are due to the use of Win32 API functions using locals. Using a Locale Identifier functions are now being deprecated in favor of using the Locale Name functions (see http://msdn.microsoft.com/en-us/library/windows/desktop/dd319091%28v=vs.85%29.aspx).
Our developments use significantly “CompareString” (http://msdn.microsoft.com/en-us/library/windows/desktop/dd317759%28v=vs.85%29.aspx), including the use of the indexOf method of the TStringList .The execution of this method (CompareStringA of kernell32) is slowed while running in the user context System (in Session 0).
To get around this problem, we overloaded TStringList with CompareStr instead of CompareString. This workaround suits in our context but CompareStr makes comparisons bit to bit and isn't case sensitive unlike CompareString. (Not to mention the fact that this method is about 10 times faster ... http://www.gefvert.org/blog/archives/651)
Another solution would be to switch to a newer version of the IDE, but we all know that this is another story...
I've taken over the maintenance job of a device driver from another guy recently.
The driver works with a pci-e board. when the system starts up, the driver will allocate a 128Mb memory, and then set some registers on the board to pass the information about the allocated memory. Later when the board is working, it will write some data to the memory and some other application will access those data through the driver.
The board is powered by a standalone adapter (not powered by pci-e slot, it's a demo or development board). So when sometimes the fpga program in the board goes wrong, we will re-powered on the board (this is fast) and restarted the pc also (this is slow, otherwise the board will know nothing about the driver-allocated memory).
Here comes my problem: is it possbile for driver to know the board has been re-powered on? if it can detect the event and do something like those done when the system starts up, it will save us much time.
I haven't got much knowledge about driver development before, it would be helpful if there is any not-too-complicated tutorial/article for this kind of job. Or maybe I must find some thick books to learn from scratch?
Hope I've made myself understood and any suggestions would be greatly appreciated:-)
Check Supporting PnP and Power Management in Function Drivers might help you.
Problem
I am working on modifications to one of my applications that communicates with a telescope.
One of the most annoying problems due to nothing else but reckless poor design, is the GOTO controller and its keypad.
If anyone of you remember the Sinclair Spectrum you know what I mean. As well as the rubber keys, the crucial keys for guiding and slewing the telescope are awkward to locate when your eye is trying to adapt to the view.
All it takes is the wrong key and you spend another 30 minutes or so re-aligning the telescope.
Workaround
My solution is a game controller such as a wingman, it fits neatly into your hands and is easy to locate the buttons. Also there is no risk of reseting the mount.
Question
My question is this, how does Delphi interact with game controllers because tthere is no mention in the documentation? Otherwise how do I access a gameport when it is connected through a USB dongle?
Working with the game controller is part of the Windows API. JEDI's JVCL has a Human Interface Device (HID) constroller (TJvHIDDeviceController) component that does what you want.
Delphi applications running on "NT" line operating systems (NT, 2000, XP, Vista, 7, 2003, 2008...) can't access hardware devices directly. Only drivers can, because the I/O ports required to access them can be accessed only by code running at the right IOPL level (which is 0 in Windows). There are some generic drivers available that open any I/O port (thus creating a security hole) that user code can call.
But tt's far better to rely on device drivers, and use the HID API to interact with them. Windows will recognize most older devices (like the serial/game port Wingman), while newer USB ones or use the standard drivers that come with Windows, or come with their own. Once the system recognizes the devices, you can use them in a standard way with no need to dig in the low-level details.
I have written a program in Delphi 7 (includes a ModBus component that uses Indy). On my machine it uses Indy 9 and works fine. It communicates well with other machines via a ModBus protocol. However, when the program is run on a different machine, I get a CPU 90-100% load. Unfortunately this machine is not in my office but "on the other side of the world". How can I find out whether this machine is using Indy 9 or Indy 10? And, further, If it is running Indy 10, could that be the problem or is this very unlikely?
Definitive answer is No
If you compile your program with indy 9, even if using packages, it shall use INDY 9 to run. AFAIK, there's no way to compile the executable using INDY 9 and use INDY 10 at runtime, even if you want, and no way it happen by accident.
To find out whats causing the high CPU load you might try a profiler like AQTime or SamplingProfiler.
That will get you the method(s) that are running most of the time. Then you will be able to find out whats causing the problem.
Alternatively you could add some logging to your application.
To find the root cause you could prepare a test application which will go through a sequence of actions like opening / closing connections. If it asks the user for confirmation ("Continue ? y/n") before proceeding, the user can check the CPU load for every step to detect the critical operation.
Thanks for answers. I do not think this is an Indy issue though. On my Quad CPU PC the CPU load also goes up from 1-2 % to aprox. 25%. This happens if I keep the line open (connected). If I, however, disconnect the ModBus Server after every poll from the ModBus CLient side and let that PC reconnect, the CPU load is always low. WHat is normal? Having the line open all time, or connect and disconnect for every poll? The polling frequency is: in Idle mode : 2000ms, in active mode 500ms.
you need to add logs to ensure you know whats going on.
is it the connection itself that is causing you the issue? or is it the work performed while connected?
Logs will help you narrow this down and you may be able to alter you code to be less processor hungry.
using AQTime or SamplingProfiler as also suggest earlier will help you.
personally i always add logging to every application by default, alot of them require turning on but its there. Once the software it on site you never know what may change and simply turning the logs on can save you alot of time
I am writing device software for a PC and for that, I want the PC to be usable as a device. When power is supplied, it should switch on without requiring to press the power button. There are power options in BIOS settings but it starts the PC only when its uncleanly shutdown. The other concern I have is how would unclean shutdown affect the hard disk, filesystem and the OS (XP or Linux).
What you need is another PC and one of these devices attached to it.
http://www.relaypros.com/mm5/merchant.mvc?Screen=CTGY&Store_Code=NCD&Category_Code=RS-232_Relay_Boards&gclid=CMna8_yOo5wCFQxM5QodWjoflQ
What you do is send this some RS232 commands for a quick closure on one of the relays. The relay is connected to the Power On pins of the computer you want to control.
You possibly could find another relay contact closure for AC current that allows you to close a relay when AC is flowing, but you would only want to for a brief second.
Unsafe shut downs can be quite detrimental depending where the filesystem state is in. It would be quite hard on the hardware too.
There is also the alternative of booting from the network device. A quick search led to some information on wikipedia. Also, there is something related called preboot execution environment which seem to be something like what you are looking for.
Some software options - these aren't exactly what you asked for, but they might help
Mac OS X: In the energy saver control pane's options tab, select "Restart automatically after a power failue. shutdown -hu now should then bring the system down but give you 5 minutes to remove power to simulate a dirty shutdown, and have the computer reboot automatically when power is restored. It's a slightly dirty shutdown anyway, I think. (ie, it doesn't log you off first)
Windows:
I don't have a windows machine so I can't try this, but you used to be able to tell windows not to power down the computer when you select shut down, but rather to put it in a safe state and display "It is now safe to turn off your computer". Perhaps you could then remove the power and have the bios believe it was a non-clean shutdown, and turn the machine on again when power is restored. There are some instructions on how to do this in Windows Server 2003 at the bottom of this microsoft help document. This forum discussion seems to suggest it might work on XP.
Linux: Not sure about this one, but maybe this website can help.
I haven't tried any of these, so no guarantees that they'll work or work safely.