Flight Simulator & PLC Control

I'm a Mech-E. I do HVAC, but flight sims are my hobby. I'm building a F-16 ****pit(pit) and am looking to use a SLC 500 type PLC to do the I/O <-> between the PC and pit's dials, switches, analog instruments, and motion system. I'd like to buy the stuff used(cheap) on eBay.

The flight sim software runs on a Windows PC and uses a "shared memory" or "mem_mapped_file" to exchange date. A small background app. reads and writes data to/from the main program.

The I/O list is roughly as follows:

• Digital inputs - 350
• Digital outputs - 250
• High resolution analog inputs (>=12-bit) - 8
• Low resolution analog inputs (>=8-bit) - 16
• High resolution analog outputs (>=12-bit) - 16
• Low resolution analog outputs (>=8-bit) - 16
• Rotary encoder inputs - 8

I'd like to get a max latentcy of updates to the PC of no greater than 20 msec for the analog I/O. The digital could be 10x slower.

Here are my questions:


Am I in the right ballpark for a family of PLC?

Is there anything I'm overlooking in the above?

Can I use the older SLC 5/0x systems that use the serial RS-232/484 protocols? Or do I need to go with the much more expensive Ethernet systems?

Could you point me to good literature that explains comm protocols between PCs and PLCs?


Any help here would be greatly appreciated.

Craig

350 digital inputs? Even if you use high density cards such as
IB32 you would need 11 of them. Sounds expencive to me...
I would probably try to multiplex them using one input and
one output card. For example 16x16=256 is too short but
16x32=512 which is plenty more than what you need. I would
go for combination such as OB16 and IB32 which is only two
cards. This would reduce weight of the wiring as well
high flex cables are expencive too. (You want your flight
simulator to move right?).
You could probably do same with most of the outputs but the
analog I/O would probably need to stay individual considering
scan time restriction.
As for communication, how much data you want to pass back
and forth?

panic mode said:

350 digital inputs? Even if you use high density cards such as
IB32 you would need 11 of them. Sounds expencive to me...
I would probably try to multiplex them using one input and
one output card...

Click to expand...

Right, I was thinking that multiplexing would be the way to go. Haven't done this before. So that's how you do it, input/output synched to logic?

...analog I/O would probably need to stay individual considering scan time restriction. As for communication, how much data you want to pass back
and forth?...

Click to expand...

I really don't know how this is done well enough to answer your question correctly. About 90% of all digital and analog data needs to be passed between the PC and PLC. The PC needs to be updated max 20 msec delay for the analog I/O. The digital could be much slower. These are switches and lights. Sorry I can't speak more intelligently about this. :-o I'm currently looking for info on how the serial comms work.

Thanks you,

Can you estimate how many integer, double-integer, float and single-bit data you think you need to transfer between the PC and the PLC? Don't forget that in PLC world, integer is a 16-bit value, double-integer and float are 32-bit and bit... well, a bit is a bit - enough said...

Sounds like expensive fun to me too.

I would not use just I/O cards in the PLC. A DeviceNet or Profibus interface card could reduce the wiring and number of I/O cards needed.

I am more familiar with theme park rides and animation. They update at the movie frame rate or 30 times a second. That is a little slower than the 20 ms you mentioned. I know a lot about the motion side of these projects.

I also know how much it costs to automate just one car or platform of a theme park ride. Did you win a lottery?

• Digital inputs - 350 total passed to PC
  
  Digital outputs - 250 total passed from PC
  
  High resolution analog inputs (>=12-bit) - 8 total passed to PC
  
  Low resolution analog inputs (>=8-bit) - 16 total passed to PC
  
  High resolution analog outputs (>=12-bit) - 16 total passed from PC
  
  Low resolution analog outputs (>=8-bit) - 16 total

passed from PC

In addition to the above, I estimate about ten more floating poing values passed PC --> PLC

Thanks

Re: Sounds like expensive fun to me too.

Peter Nachtwey said:

I would not use just I/O cards in the PLC. A DeviceNet or Profibus interface card could reduce the wiring and number of I/O cards needed.

Click to expand...

I'm not familiear with these. They are interface between the PLC and PC?

I also know how much it costs to automate just one car or platform of a theme park ride. Did you win a lottery?

Click to expand...

LOL, no... part of the fun and challenge is to build with stuff I get dumpster diving at MIT, buying on eBay, and jury rigging from consumer products. ;-)

I do this with other flight sim nuts. Here's a forum topic about one of our projects: http://forums.frugalsworld.com/vbb/showpost.php?p=585962&postcount=9



Oh yes, I could live with 30 times a second on the analog I/O.

I had to back up to to the vbb but it looks like a fun site.

Normally, I refuse to ask questions to pry info out of people, but this has caught interest. Are you planning to synchronize the simulator to the games? Do they provide position with a synchronizing pulse? In the documentation, do they mention SMPTE? How far along are you?

It seem that these games are much more than just games to the people on the frugal site.

You can get Joysticks with DeviceNet interface. They are quite common. A DeviceNet interface allows multiple devices to communicate over a RS-485 like line at 500kps. This allows one scanner card in the SLC to talk to all your devices. This saves on wiring as not all the wiring must be brought back to the SLC. Google Profibus and DeviceNet to find much more.

If you must use a SLC the get a 5/05.
If you have $, get a Control Logix.
I would consider a PC running Linux with Profibus DP or DeviceNet because it will require a lot of processing power to get the analog inputs, calculate the model's reaction to the inputs, compute the motion the actuator must make to make the platform do the desired motion. Theme parks have an advantage because they do the same thing over and over again and all the motion points are stored in a table.

Peter Nachtwey said:

I had to back up to the vbb but it looks like a fun site.{/B]

Click to expand...

Hi Peter,

Sorry 'bout that. Here's the correct link: http://forums.frugalsworld.com/vbb/showthread.php?p=600022#post600022

and another with a bit of motion cueing madness. http://forums.frugalsworld.com/vbb/showthread.php?t=20800

Are you planning to synchronize the simulator to the games?

Click to expand...

Let me give a bit of background for the games. There are two flight simulators we're working with. Falcon4 by Microprose and Battle of Britain by Rowan. Both have the same hooks for talking to the simulator or pit as we sim nuts call them. Both games have been pretty much abandoned by the IP owners. The source code has been leaked(Falcon4) or released(BoB) and continued development picked up by sim enthusiasts.

I'll talk about Falcon4 it is based on modern jets and is more complex. The original Falcon4 coders made a "shared memory file" or "memory mapped file" in windows. The used this to send real time game data to a Hercules mono monitor for debugging. Like the old Dos C debuggers had.

A description of "shared file" and the data that it contains can be found here: http://www.eagle9.nl/main/Programmi...?DocPath=/main/Programming/F4 Data Extraction

We are able to write apps that run in the background and dish off this data to our pits. We also do keyboard emmulation and manipulate the Windows DirectX game controller stuff to get the data into the sim.

So... we're not really synchronized, we just read the data and act on it as fast as we can. Falcon4 typically read/writes to the file 50 times/sec.(code execution time) and this varies a lot.

How far along are you?

Click to expand...

I personally am not that far along. My focus is in the sensory aspects of the game: HMD/head-cueing, motion cueing, G-force cueing, etc. I've been at it for two years. Others' work can be seen here: http://viperpit.org/forum/viewforum.php?f=1&sid=21d4011a8ce961fc6f16c949dc6800a5
[/quote]

It seem that these games are much more than just games to the people on the frugal site.

Click to expand...

You think? :-D

I would consider a PC running Linux with Profibus DP or DeviceNet because it will require a lot of processing power to get the analog inputs, calculate the model's reaction to the inputs, compute the motion the actuator must make to make the platform do the desired motion. Theme parks have an advantage because they do the same thing over and over again and all the motion points are stored in a table.

Click to expand...

Rgr on the Profibus, I'll get researching that right away.

Regarding the motion platform, I'm not sure I'll go that route. My research of the military literature indicates that the force for a fighter jet aren't well simulated by a platform. I'm thinking that if I do use one, I'll only use a couple of DOF's for high frequency stuff, but for flight forces, I'll use G-suit pressurization, "G-seat"(sections of the seat push on your butt and back), and "helmet loading"(actuators throw your head around simulating inertial forces).

Thanks for your interest,

If you can do all that then don't mess with a PLC

If you know how to manage shared memory in protected mode then you don't need a PLC. Buy a PC Profibus DP Master card like this:

SST PC Profibus DP card

It can interface to all the I/O and it will show up in dual port memory on the SST Profibus DP card. SST has drivers to aid in accessing this memory, but you may wish use your own. The SST card is fast. It can update 6000 I/O points per millisecond. This is much faster than a PLC.

The PC will also be fast enough to do close loop conrol for your actuators.

I checked the link and it is down now. Try it later.
If the link is dead try Google for

Hilsher
Anybus

Also see Profibus Trade Organization

Have fun. Let us know how it works out.

Craig's "office" maybe?...
[attachment]
beerchug

-Eric