Response speed of FSUIPC with FS2002

[iws]

Hello all, This is my first post to the Group after programming with FSUIPC

for about a month now.

First an introduction - I am the fortunate owner of a FRASCA flight simulator made in the late 60's which simulates a Piper Warrior single-engined plane. The simulatoe has a full instrument panel, electrically trimmed control column rudders, seat etc. Originally it had a plotting/control table but this has now been discarded in favour of the cockpit controls only.

The simulator actually works quite well with its mechanical integrators and motors but the one thing it lacks is a display. After investigating FSUIPC I took the decision to try to replace the mechanical system with a PC running FS2002/FSUIPC and use Visual Basic 6 to program an interface.

I have been playing with the MAPLIN 8-servo interface card which is driven from the serial port at 9600 baud. This card at about 20 quid can drive up to 8 servos. I know that EPICS offers more choices but I cannot afford that (yet).

One big advantage of the Simulator panel is that all the intstruments have been adapted from their original operation to take direct drive from pulleys. This makes it easy to control them.

I have succeeded in coupling the turn coordinator bak indicator and driving it in a closed loop from FS2002. The main problem I have is that the refresh rate is anly about 2 times per second which makes a bit of a lag particularly at large rate changes. I have tried adjusting various parameters such as timer rates to no avail. I should mention that I am using the HELLO program as the basis for the control program.

Any tips for speeding up the resonse will ne gratefully received.

I would love to post pictures of the Frasca but I do not have a publicly viewable depository. Is it possible to attach them?

Best regards,

Ian.

[Pete Dowson]

I have succeeded in coupling the turn coordinator bak indicator and driving it in a closed loop from FS2002. The main problem I have is that the refresh rate is anly about 2 times per second which makes a bit of a lag particularly at large rate changes.

500 mSec cycle time? Good grief! How are getting it to go that slow? On an average modern PC with FS2002 you should be easily be able to match FS frame rates, though I would suggest keeping it down to around 20-30 per second if possible. The normal Windows timer tick of 55 mSecs (18 fps) is usually a reasonably good start.

Any tips for speeding up the resonse will ne gratefully received.

Sorry, I really don't know how you've managed to make it so slow. Visual Basic doesn't help of course, that's pretty slow in itself, but still. Is it perhaps the serial port side? 9600 baud isn't very fast -- 960 cps. Maybe if you are transferring hundreds of bytes per cycle you will get down to 2 fps quite easily.

There are many examples of applications which run as fast as FS -- Project Magenta, for instance provides instrumewntation on one or more client PCs on a Network, with data from FSUIPC being fed via WideFS, and still achieves 20-40 fps without problems.

I would love to post pictures of the Frasca but I do not have a publicly viewable depository. Is it possible to attach them?

I think so. There may be a limit on size, but many folks here do seem to attach pictures. I've not tried it myself.

Regards,

Pete

[iws]

Thanks Pete - you have answered my basic question. There is obviously something wrong!

I tried to send a post with more information with an included JPEG, but it failed 'cause the JPEG was still to big. I will try a bit more compression in a while.

The information was that it is a modern PC ie a 1.8 Ghz 256Mbyte RAM, running alone,

no network no other programs other than FS2002/FSUIPC and the compiled EXE servo control programme.

Now that I know it should be faster, I will experiment with the various i/o sections. As I mentioned, I am using the HELLO program as the structure for my program and I have alreadY reduced the Timer period to 5 milliseconds and checked for any delays in the code. I am sTill using the display box from HELLO to check display/check connection.

I have noticed that the cycle time of FS itself may be a factor. The turn/bank coordinator looks as though it may only be refreshed by FS

at that rate. Maybe I chose the wrong dial/variable for my test (offset 037C). Apart from using the FS sliders to minimise what FS has to do

is there anything else I should do? As you said, there must be something really odd happening.

I must say, that apart from the slow cycle time, the FSUIPC software is working very well with no errors and the supplied sample programmes are invaluable.

Best regards,

Ian.

[Chris Brett]

Post the code you are using to extract the information from FS, there may be an oddity there. If you are making many calls to UIPC every timer event, use only one _Process call rather than _Read/_Process, _Read/_Process.

Also, given you are driving external hardware, it may be a hardware update delay rather than a software delay. Have you tried updating a simple label caption on the form window with the UIPC-obtained result of the slip indication and comparing how frequently that label gets updated?

There must also be some conversion between the UIPC value received and the output required for the hardware to work - check there is no delay there also. Post code if in doubt.

Cheers

Chris Brett

[iws]

Hello Pete and Chris,

Based on the valuable information you passed on that it should be working a lot faster, I started looking at my code in earnest.

I discovered that inside the scan and write loop I had embedded a call to reset the serial port. Once this was removed, it all speeded up.

--- Unfortunately my write to the serial port doesn't work now so I have further work to do! (I am using a third party serial port driver, not being able to afford the full VB compiler with its serial drivers). I am presently checking buffer sizes etc.

An interesting side effect was that the loop delay was affecting the refresh rate of the turn coordinator as displayed by FS2002 although the rest of the panel and the scenery was refreshing at a normal speed.

Many thanks,

Ian.

[iws]

Attached is a much compressed photo of the sharp end of the Frasca flight simulator.

Ian.

[fturner]

When you set up your serial port connection, are you setting either Software (XON/XOFF) handshaking or are you using hardware handshaking.

I'm asking this because if resetting the serial port works, then what is happening is, your program is sending the data out the serial port, then its sitting there waiting for an ack signal back from the device. If you do not have the handshaking set up right, then this will stop your program cold.

You need to match up both sides of the serial communications, and hardware handshaking is the better. Of course you could try to disable the handshaking.

Fraser

Hello Pete and Chris,

Based on the valuable information you passed on that it should be working a lot faster, I started looking at my code in earnest.

I discovered that inside the scan and write loop I had embedded a call to reset the serial port. Once this was removed, it all speeded up.

--- Unfortunately my write to the serial port doesn't work now so I have further work to do! (I am using a third party serial port driver, not being able to afford the full VB compiler with its serial drivers). I am presently checking buffer sizes etc.

An interesting side effect was that the loop delay was affecting the refresh rate of the turn coordinator as displayed by FS2002 although the rest of the panel and the scenery was refreshing at a normal speed.

Many thanks,

Ian.

[iws]

Hi Fraser,

Yes, thank you for reminding me of possible handshake problems.

I am familiar with the various RS232 handshake methods. The problem is that I don't actually know what my servo driver card uses! I am assuming hardware (DTR/DSR) as it uses a "standard 9-pin cable" (which isn't standard for RS232 anyway!). The documentaion for the card makes no mention of the physical connections or handshaking. At an early stage of development I was scoping and looking for the RX line and I found a line that toggled this was probably DTR/DSR so the handshake is probably hardware.

I have had a bit more success since the last post. A port reset outside the loop which is activated by a command button on the form will start the serial port working. The loop time then decreases dramatically but is still

only about 100 msecs round the loop. It is becoming more and more useable though.

Once I get the basic read from FS/write to serial port loop working properly for one item the rest should be easy! Assuming that reading say

20 to 30 variables from FS and writing out to the serial port does not slow things too much then a multiple read followed by one process call should do the trick.

Then I can continue the work in scaling the various variables to fit the servo drives and dials of the real instruments. (I have the turn coordinator

bank dial working perfectly).

Servo drive should do for most instruments not needing more than 360 deg. movement, the altimeter will be a stepper motor.

Will keep the forum updated.

best regards,

Ian.

[Pete Dowson]

Yes, thank you for reminding me of possible handshake problems.

I am familiar with the various RS232 handshake methods. The problem is that I don't actually know what my servo driver card uses! I am assuming hardware (DTR/DSR) as it uses a "standard 9-pin cable" (which isn't standard for RS232 anyway!). The documentaion for the card makes no mention of the physical connections or handshaking. At an early stage of development I was scoping and looking for the RX line and I found a line that toggled this was probably DTR/DSR so the handshake is probably hardware.

The 9-pin socket has been a standard on PCs for a long time. The "standard" here is a PC standard, not an EIA or IEEE standard. The pin allocations are:

25-pin -- 9-pin -- Use

1 -- -- -- protective ground

2 -- 3 -- tx data

3 -- 2 -- rx data

4 -- 7 -- RTS

5 -- 8 -- CTS

6 -- 6 -- DSR

7 -- 5 -- signal ground

8 -- 1 -- DCD

20 -- 4 -- DTR

22 -- 9 -- Ring

23 -- -- -- DSRD

The normal data handshaking uses CTS/RTS not DTR/DSR. The latter usually need simply to be held on to indicate power is applied and the device connected. In many cables they are simply link to each other locally and not device inter-connected.

Assuming that reading say

20 to 30 variables from FS and writing out to the serial port does not slow things too much then a multiple read followed by one process call should do the trick.

The multiple Read calls don't take any time at all as all they do is build up the request block in the already-allocated shared memory space. The main time taken is by the Process call, in the changeover to the other Windows process and the queing in FS's message queue, then the process change back to you. The little bit FSUIPC does in the midst of all that is very quick in comparison (unless you are asking FS to load or save a flight, or change the time (which reloads textures) and so on). Reading 1 or 100 variables wouldn't produce a noticeable difference in comparison with the variations in process swapping times.

Regards,

Pete

[iws]

Hi Pete,

Yes, I am familiar with the PC "corruption" of the RS232 standard

(I was making an in-joke with my comment)!

Your information regarding read and process times is very useful.

I suspect that future problems may lie with the writes out to the serial port. However, as you indicated in an earlier post, if I am writing say between 20 to 30 3-byte strings out it may not be too bad.

I am using the inexpensive Maplin card as a proof of concept. If it works then fine. If not then I will bite the bullet and think about EPICS.

I could possible reduce costs by a combination of the two.

Todays project is to make a block of reads and writes out to the servo card, and to start reading the Indicated Air Speed plus scaling it to fit a 360 degree servo..

..... Gives me an alternative Christmas (seen most of the films anyway...)

Which brings me to wish you and all reading this the very best compliments of the Season.

Best regards,

Ian.