Section
Categories
Contribution
Most Popular Threads
<P></P>
SIOC…What Is It and What Does It Do?
<p></p>
As I have mentioned in the previous post there is a point in cockpit building where all of us starts to become a little bit of everything. This everything includes to be an electronics person, software person, computer person, hardware person and probably systems architect as well as a craftsman.
One of the most challenging parts of cockpit building is even if you get the whole equipment finished you need to do a little bit of coding. As the complete cockpit solutions with their software drivers with a handsome price, for the minor things we all end up getting these from local electronics shops and build them ourselves.
At this point we need to figure out how we can get connected to the PC and how we can trigger the events to run our hardware. Curiosity of course is the main driver here. WE SIMPLY NEED TO KNOW…
Right at this point very common issue if we are not a deep down programmer is to find some ready interfaces. There are a lot of companies that provides these. Today our article is concentrated on Opencockpits SIOC.
SIOC in very simple terms is an interface that is capable of driving Opencockpits hardware based on the script written with its own language. This hardware can be variety of things starting from leds, rotary switches, potentiometers, servo and DC motors as well as push buttons, and motorized gauges. What it does is based on the written commands it interfaces with simulator program, reads the values and perform the commands on the hardware.
How it does is a bit more complicated then the conventional programming. In the computer programming we generally create the events ourselves and based on the events we program actions. In other words every single functional element on the screen is accepted as an object with its own capabilities and there are functions, events or actions related to them which can be used. Therefore we use a lot of library functions to automate the program we are writing. SIOC, on the other hand does not create events. It only listens to them. It uses a very simple logic but uses this logic very effectively. Therefore it is considered as an event based programming language. Of course this language, compared to high level languages like Java, C# etc is a very very simple one with its own coding interface. It includes basic mathematical functions for calculations (no rocket science so do not be afraid), and the needed very simple functions like If…then, Assign, Command, Function etc.
One of the most common mistakes in SIOC programming is to assign a variable to be monitored then looking ways to find to monitor this with classical programming methods. However, if you do not put the command under correct variable SIOC does not recognize any changes therefore it does not change the value of the control. Then you become a sitting duck in front of your computer digging the documentation to find out what is wrong.
To better explain this difficult sentence let us look at an example. Assume that you will light a led in SIOC. The led is an hardware that should be connected to one of opencockpits cards. For the sake of simplicity let us name this hardware MasterCard.
What we do first is to tell sioc where the hardware is located. Therefore we define in sioc.ini that DEVICE 1 is a Mastercard and then we define in the code that led is connected to the OUTPUT number 23 of that card.
Next is to know when does that led will be on. Again let us assume that this led will be the led for APU BLEED led for B737. Aircraft operating manual says that this led must be on when the APU bleed is ON. Now we have to know how we will know if this led is on. There are two ways. If the airplane you are using or the Glass cockpit software you are using like SIM AVIONICS, FLIGHTDECK SOFTWARE, PROSIM737, PROJECT MAGENTA is giving you this information then you have to let SIOC know to monitor this particular offset and tell it to give an output signal when the condition of this offset changes.
VERY IMPORTANT: You have to prepare this command under the particular offset definition. If you do this under the led, because it looks more logical as you are programming the led actions it will be very difficult to light it up. Because led lights only when offset changes. And SIOC monitors the offset not the led.
The second way of course is a bit deeper and requires to use a program like FSINTERROGATE. So you simply interrogate the memory blocks by creating the condition and finding which offset value changes for on and off situation. This is like a trial and error and takes time. But when you find it out the action is exactly as given above.
As the command set is only a couple of variable definitions and couple of commands lighting a led is no longer then three or four lines of code.
One other important issue is to panelize the building as well as commands. In the previous article we have mentioned that the building should be under a plan. This plan has to be separated panel by panel. If you continue to follow this plan then you program your panels and their functions separately. Having everything in one SIOC code is possible but if you want to make changes that means you will struggle in thousands of lines no matter how neatly you have named or grouped your variables. Instead you can use a very wisely programmed option of using list files. You write your code on a clean config window and once you are sure everything is working name it something like OVERHEAD for example. Then export this file to text format again naming it OVERHEAD.txt.
Instead of using a compiled .ssi file in SIOC.ini use SIOC.lst This is a text file that can be opened with notepad and you simply insert the names of your different module .txt files. So when you run SIOC it reads them and compiles them all together as a single code preventing any duplicates on variable or function calls.
To summarize;
- SIOC is an event based scripting language. Not a whole programming language so takes time to get adjusted to its logic.
- Best performance is always gotten if the codes are separated by panels or even by hardware to make life easier if you need to change a led, switch, button or motor in the future. All you need is the values to monitor and the devices to control as well as conditions of that control.
- You do not have to be a rocket scientist to be able to program it.
See you in new posts soon.
Oral Barkay
Message