SIOC Pre compiler

Hi Guys,

Well im deep into SIOC now and while I love its functionality and the power it provides, I hate its syntax!

So im going to write a Precompiler that will allow us to write in a more friendly manor and then compile this into valid SIOC script

here are a few ideas I have,but I am looking for more ideas so I can make this a success!

intelliSense
Automatic VAR numbering
All Parameters to be declared at the top of the code,
then all scipt underneath, allowing you to keep Var decleration neat
Color coding of Functions, vars etc


So come on guys let meknow what really annoys you about SIOC :)

i personally would love to get to grips with SIOC, but time, age and computer skills sadly are not on my side. you are a professional programmer, so make it as simple as you can.
a lot of us didn't grow up in the 'computer generation', so what about a 'what you see is what you get' type of dropdown menu system with the ability to 'manipulate variables' in a simple manner (not suggesting that we are a simple bunch, just that a lot of us need some
help).
i was talking to John Rossiter (boeing737ng) the other day about exactly the same issue.
maybe you should have a chat with him.
good luck anyway and keep us posted.
and for those of you who dont know chris, here he is....

http://www.737ng.co.uk/chriswarner310109.jpg

sorry chris, couldn't resist it .......

regards ... ian

For those of us who do not speak 'programming' it's an excellent idea. I really hope you succeed with this.

I might even be able to use SIOC with that add-on. ;)

Chris/Mr Roper

In addition to agreeing with Ian (as always!) I am not certain how far your pre complier will go, however, existing SIOC error messages are totally inadequate. One great addition would be the facility to select a variable and then have all other uses of that variable highlighted in colour - I get fed up doing individual notepad "find" calls to try and track what is going on when a variable changes. I am not used to the anarchic programme flow

Regards and thanks

David

An excellent idea! Go for it Chris! But don't wear yourself out (I know how fast these projects can grow out of proportions :) )!

Quote:

---

I get fed up doing individual notepad "find" calls to try and track what is going on when a variable changes. I am not used to the anarchic programme flow

---

David!
Try Notepad++! http://notepad-plus.sourceforge.net/uk/site.htm
Although it will not help with the programme flow. The find/replace facilites are great. Syntax highlightning, linenumbers and kinds of other good stuff is in this powerful editor!

Without it, I'm lost.

Chris:
Was thinking about writing a Perl script for renumbering variables,but I'm putting that on hold for now;)

Great Idea ,
I could like a more visual programing , like drag and drop , could be???
think SIOC is great and very powerfull but very complicated for normal people like me. Thanks in advance for your work.
regards

Ian...Just wait until I see you next!!!! (only joking!)

My idea is that It will precompile the script and make sure It is valid..taking it from my interface into native SIOC.. It wont be a debugger im afraid (i.e. you wont be able to use it to debug values in real time

my idea is this so far, and I have this working in a very early stage

step 1

type "var" as you press space, a list of available types of var will appear..then when you select this it will show you all the available parameters for this type of var

all the "vars" will be at the top of the code with none of the inline script as is now

you will then be able to implement the script underneath and this will precompile into correct "SIOC"

an example might be

Code:

---

Var VSdisplay, IOCARD_DISPLAY, 14, 5
Var CRSRdisplay, IOCARD_DISPLAY, 19, 3
Var MCPstatus, FSUIPC_IN, Offset $62BC, Length 4
MCPstatus
{
 VSdisplay = 1000
}

---

as you can see you wont have to worry about numbers, and this will all be color coded and use "intellisense" so that as I typed MCPstatus, it would have showed me all the variables that match what im typing.

also a lot of the syntax that is required by SIOC wont be required

My main problem with drag and drop style is that it is quite slow, whereas a intilsense type approach is normally much faster to write.
Does this make sense, and do people think it would help?

Brilliant !! I can't wait for something to make it easier to facilitate programming SIOC.
Regards......................Brian W.

Chris

Yes please, this would be a great improvement and the variables list at the top reminds me of programming in C back in 1982, though sadly mostly now forgotten!

Thanks again

David

Quote:

---

Originally Posted by fordgt40

Yes please, this would be a great improvement and the variables list at the top reminds me of programming in C back in 1982, though sadly mostly now forgotten!

---

Hi guys, its 2009 now (!), global variables should be avoided in programming as much as possible, it is considered bad practise nowadays... :-)

But more serious, I do not think a SIOC pre compiler is a good approach. Personally I do not need that at all ...

The SIOC language already is an application language, particularly targeted to building cockpits, so why do you want to abstract from that??? And more important, the 'event driven' mechanisms in SIOC will be very difficult to abstract from.

I think it is better to try to understand the SIOC language, just spent some time, it is not as difficult as it seems. My website may be of help:
http://www.lekseecon.nl/howto.html. Start with simple examples.

And if it still does not work, for instance because you do not understand the syntax of the SIOC language, so you have difficulty to program using a text editor, you could also fall back at the GUI interface of SIOC.

regards,
nico

I think it would be a great idea. I do not understand any of the SIOC language or the explanations that Nico has written. If you are some sort of computer programmer it all makes sense. I am not and none of it makes sense to me. So anything that simplifies programming would be a plus!

Rob

Quote:

---

Originally Posted by mounty

I think it would be a great idea. I do not understand any of the SIOC language or the explanations that Nico has written. If you are some sort of computer programmer it all makes sense. I am not and none of it makes sense to me. So anything that simplifies programming would be a plus!

Rob

---

I'm sorry my examples dit not help you.

I'm afraid that if one does not understand my SIOC examples one will certainly not be able to work with the suggested SIOC pre compiler tool.

In that tool you abstract from the syntax details, but you cannot abstract from the underlying SIOC semantics. If you do not understand these semantics your lost I'm afraid.

Nico

Hi all,

I too found this is a great idea, about 2 years ago, so I have done it already.
However, since this was just for myself I have written some kind of preprocessor
in TCLTK script. Since it was just a tool for me to use i have not made this extensive, meaning that it works with fixed filenames and locations so a change in that needs to be updated in the code itself. It wasnt made for distribution, for being user friendly.
However, a precompiler like I made will not make the syntax of SIOC easier, that remains the same.
It only allows to define all the inputs and outputs in the beginning of the script and work troughout the script
with names. So if I reallocate some inputs to another mastercard, I do not need to look through the sioc code
for the places I used it, just modify the defines and compile.
Below the defines you write your sioc code as usual but with only the CONST_name as references to any
input, output or display. In the SIOC code you give each var a name, the var numbers you give dont matter since when going through the preprocessor it will assign var numbers incrementally by itself.
Syntax coloring is provided by several editors. Example UEDIT (ultraedit) allows to build your own list of names to be colored in different colors.
Intellisense ... dont have that...
Someone willing to write a full blown application which is stable and which is tested for a bigger community you can always get my tclscript as an example.
I agree to with Niko, if you dont understand the examples in his site then you probably miss some explanation
about how SIOC works. Ones you get the clue about SIOC its pretty straightforward and easy to understand.
However, I do not agree with him saying that if you dont write SIOC with txt editor, use the GUI. I find the GUI
very difficult to work with and find the txt editor version much more simple.
Just take some example scripts, like Niko provides or with the examples in the download of SIOC. Take a script,
analyse it and try to understand. If you dont understand how it should work, post the part you dont understand here and just ask explanation.

Greetz Peter

first thing i have to say is give the guy a break. what he is trying to achieve from what i understand is a simpler way of assembling and being able to read scripts.
at the end of the day, if SIOC was the 'be all and end all' and easy to use and understand, we would all be using it, right? but it isn't and we're not. it's just another option for
cockpit builders to consider.
with respect, what nico doesn't take into consideration is that we all have different skills and talents. some of us are computer 'whizzkids' and some us can make parts for a watch or craft wood into a work of art. we are engineers, carpenters and truck drivers. we're not all computer programmers or have been educated in writing programming.
there is so little documentation and 'from the ground up' tutorials for SIOC that a lot of people (including me) look at it and decide it would be easier to learn chinese. i gave my OC boards away after ripping my hair out for three months.
so, my slant on it is anything that can make the use of SIOC easier to understand and get into has got to be worth the effort.
anybody want to write a 'from downloading the program to getting it to do something' tutorial that we can understand?

good luck chris, soldier on..... regards ... ian

Ian

You just beat me to it! Only good can come out of this by helping and encouraging people to take the first steps.

Quote from Nico

"Hi guys, its 2009 now (!), global variables should be avoided in programming as much as possible, it is considered bad practise nowadays..."

I like being passe, it comforts me! In any event surely SIOC has "global" variables with local variables limited to only three within a "function".

Keep at it Chris

Regards

David

Hi David,

You forgot to copy the ;-) smiley with that statement. ;-)

In SIOC every variable is global, so you can not even put them in the beginning of your program text only ...

Note that global variables is more an issue in procedural programming languages, such as Pascal, Basic, C, C++ ...
SIOC is not a procedural language but an event based scripting language.

@all
If somebody wants to make a pre -compiler, ok, fine, go ahead, no problem with me, it might benefit some people. I only wanted to warn that I have some doubt about its success, you better spent your time learning SIOC,

Nico

Nico

Sorry

:) + one for luck :)

Regards

David

I think this is a highly commendable idea and would love to see something that would put SIOC coding into laymen language. The main bug with SIOC and all OC related hardware and software is adequate instructional information. I think if there were more explicit examples of coding it would help us all enormously, after all Manolo Valez is a very talented programmer, he just needs to impart some of that knowledge to his customers. I think Nico Kaan has done the best job of all enthusiastic users to impart that knowledge to the English speaking world but the fact remains that if you don't know the basics you have little hope of coding it.

My experience has been that once you have your hardware setup and the SIOC script written you very rarely revisit it, you just run it and fly it! I have been fortunate to gather scripts from other users including Nico and adapt them to my pit, however I would gladly have paid for this to be done from the outset as I don't consider myself a programmer nor have the inclination to be one. I would think that I'm not alone in this scenario. I would rather see a pool of available SIOC scripts that are available to OC users who could take what they need depending on the hardware they have and any specific tailoring could be done by the experts at a cost. This would give all users what they want but leave us non-programmers to get on with the business of building. This is the reason I have made available all my SIOC scripts for anyone to use, but you still need to know some of the basics in order to incorporate them into you pit.

I will be very interested to see how the precompiler works out though. :)

Ken.

I agree with Nico that a precompiler is not what people needs.

In my opinion it would be better to have some helper application for reading and writing SIOC scripts.
Coloured sysntax, correcteness checker, and so on.

This could be realized for example by writing a plugin for eclipse. It could caontain an editor abstracting the details of the language for non programmers but allowing to go in the low level details for the more experts in programming languages. The concept is that of having on file (the SIOC ASCII script for instance) and several views of it helping better understanding the meaning and the functioning of such a script.

Hi all,

just something I wanted to add to this thread. Some time ago I saw a video of the cockpitbuilders gathering in Spain. Manuel Velez had there a session and was announcing
a new SIOC version which would be a visual approach. However, I got no idea where he
is standing with this. i'll send him an email and keep you posted.
Anyway, I stand by my point that I made in a previous post. I am working in software, so is Niko, so for us SIOC is probably easier then for some others. However, it is not that difficult so if you want to work with it, look at some scripts, try to understand, and if you cant figure it out, post the piece of code and I will describe in detail how this piece of coding works.
I agree with many, documentation in english on opencockpits is not that good and is not that much widespread. If I find time I'll try to write up an understandable document .. just give me some time.
Anyway, no need to toss away OC cards because you dont understand the programming....
learn it by asking questions about it. And the best way I think is to take a small script, try to understand and if you cant figure it out, post it and I 'll comment on the script what it does in detail.

the problem to deliver plug and play sioc scripts is that it is soo powerfull that one person want to do different things with it then someone else...
there are also so many different planes and software that can be supported?

Greetz Peter

PS : i am not affiliated to OC so my explanation might not be 100% how it is implemented in software but it is how I try to explain it.

Peter

Thanks for your kind offer of help, it is appreciated. I think that there are different expectations and understandings of what Chris is trying to do. I have persevered with SIOC and have a reasonable understanding, however, still welcome what Chris is trying to do as it would make my life easier.

There is no magical solution that will enable all to instantly programme SIOC, but anything that eases the syntax, colour code expressions and can easily highlight all instances of variables can only help some and more importantly encourage others to take the plunge. The way forward is to expand the usage of SIOC.

Regards

David

Hi guys,

I'd like to give an example of how simple SIOC scripts can be ... :-)
Especially if you build for the Level-D 767 and you run my free lekseecon.exe program in the background, it is merely just a number of 'one liners'.

Suppose I want to connect three push buttons as MCP CMD L, MCP CMD C and MCP CMD R switch.

For each switch you only have to define one (!) line of SIOC code, like this:

Var 275 Link IOCARD_SW Input 5 Type P // CMD L
Var 276 Link IOCARD_SW Input 6 Type P // CMD C
Var 277 Link IOCARD_SW Input 7 Type P // CMD R

SIOC variable numbers 275, 276 and 277 are predefined by my lekseecon tool and are implicitly linked by lekseecon at run time to the Level-D.
These variable are the control variables for the switches in the Level-D panel. If the variable is 1 the switch will be ON, if it is 0 the switch will be OFF.

You only have to understand what the Variable attributes mean:
* Link IOCARD_SW means that the variable is linked to an IOCard switch;
* Input 5 means that the switch is connected to Input 5 of a Mastercard;
* Type P means that the switch is a push button, each time you push the button the Variable connected to it changes from 0 -> 1 or
from 1 -> 0.

The var numbers 275, 276 and 277 are only used in these lines, they will not appear anywhere else in the script so no need here for tools to find these places.

regards,

Nico

Hi Niko,

be carefull with the examples form your LEKSECON, they are only valid if working with your program and with the LEVEL_D. The logic which needs to be put into SIOC and interact with FS is taken care of by your superb application. Therefor your sioc script has become merely a definition part to tell which inputs, which outputs, which displays.
If all addon planes (like PSS, like PMDG,..) would have such extensive SDK as the level-D there would be no more need for SIOC, just an application for each like your leksecon and cockpitbuilding would become a breeze.... lets hope the future turns in that direction

Greetz Peter

Yes, I agree with Peter.

If eveyrbody with every airplane could use lekseecon then tehre would be no need to think of a improved SIOC.

Hi,

:-) it was a teaser... one can always switch to the 767...

For other airplanes using FSUIPC offsets it is just a tiny little bit more complex, you need two var definitions (instead of 1).

A first variable to make the FSUIPC offset available, and a second variable that relays the values from the switch to the FSUIPC var:

Var 1 name CMDL Link FSUIPC_OUT Offset $8b0A Length 2
Var 2 name CMDSwitch Link IOCARD_SW Input 5 Type P // CMD L
{
&CMDL = &CMDSwitch
}

And again, these two var declarations can be placed together in your SIOC script. These variable numbers or variable names will not be used anywhere else, no need for tools to highlight that.


But I'm always available to answer questions, here or in the Opencockpits fora,

Nico

Well, I said it was a brilliant idea, althought I'll never use it myself:roll:
I was of course thinking about those of you who do not know the nuts & bolts of programming.

I thought it might help...

I also warned Chris on how big this project could become if he went full throttle with this. It would take a considerable amount of time to make it user-friendly on a novice level (assuming nothing about Chris's programming skills, any project with such parameters is time consuming).

But look on the bright side!
The use of editors suitable for writing code has been discussed, as well as the well of information available among fellow builders.

So if there's a code problem, post it here!

There's help to be found

Cheers!

Morten

Nico

I wonder from how many sources the routine to light up the master caution and fire warning lights might be called?

Just a little teaser :p

Regards

David

Var 1 name CMDL Link FSUIPC_OUT Offset $8b0A Length 2
Var 2 name CMDSwitch Link IOCARD_SW Input 5 Type P // CMD L
{
&CMDL = &CMDSwitch
}

see, i told you it was like learning to write chinese !
just another teaser (no i mean it) :o))

ciao ... ian

Quote:

---

Originally Posted by ian@737ng.co.uk

Var 1 name CMDL Link FSUIPC_OUT Offset $8b0A Length 2
Var 2 name CMDSwitch Link IOCARD_SW Input 5 Type P // CMD L
{
&CMDL = &CMDSwitch
}
see, i told you it was like learning to write chinese !
just another teaser (no i mean it) :o))

---

LOL, writing chinese is a lot more difficult in my opinion... ;-)

However, if you do not understand these 5 lines, you made a wise decision to forget about SIOC.

nico

Quote:

---

Originally Posted by fordgt40

I wonder from how many sources the routine to light up the master caution and fire warning lights might be called?

Just a little teaser :p

---

David,
In my Level-D, the master caution light is controlled at only one place, just like the Gear indicator light in this annotated example:
http://www.lekseecon.nl/images/lekse...nno_output.htm

;-)

Regards,
Nico

Nico

This is becoming Pythonesque don`t you think?

Let us both respect our different systems, skills and needs and focus on moving forward.

Regards

David

David,

You are talking chinese to me now :-)
But I agree with you, it is time to stop, let us close this thread and go back to work.

Regards,

Nico

Ian,

you dont understand this?
this is very easy to explain

Var 1 name CMDL Link FSUIPC_OUT Offset $8b0A Length 2
Var 2 name CMDSwitch Link IOCARD_SW Input 5 Type P // CMD L
{
&CMDL = &CMDSwitch
}

when this is the only lines in the SIOC script the SIOC program will do the following :
it will check all inputs at a high rate (let say 50 times per second). If the value in the
hardware of input 5 changes state it will change var 0002 from 0->1 or from 1->0.
When the var changes the defines script for Var 0002 will be executed and this will
copy the value of the input into var 0001. Since this variable is linked to an FSUIPC_OUTPUT the SIOC program will copy the var 0001 to the fsuipc offset 8b0A. So in 8b0a a 1 will be copied if you press input 5. the next time you press input 5 a 0 will be
set into offset 8b0A.
The site of project magenta (documentation) has an extensive list of all fsuipc offsets and there use.
Thats it.
Just take into consideration the SIOC script you write is only an input to a program wich runs in the background. Sioc itself will continuously check all hardware inputs, all fsuipc inputs that your script needs and when one of those variables change then the value
of those inputs (hw inputs/fsuipc inputs) is copied into there respective var xxxx.
When a var changes value then the script linked with this var will be executed. This script
can of course change one or more other vars and those changing vars can again change
other vars .... you see that this is an event driven program sequence. One event ( a change of a var) can lead to a chain of events....
there is little syntax possibilities in sioc. When an event happens you can use an IF THEN ELSE construction to decide what will happen depending on a value of a var, or of one of the three boolean values (C0 C1 C2) or one of the three real (real numbers) vars (L0 L1 L2)

Hope this explains a little.

Quote:

---

Originally Posted by fordgt40

Nico

I wonder from how many sources the routine to light up the master caution and fire warning lights might be called?

Just a little teaser :p

Regards

David

---

Does anyone know the offset to light the Master Caution in FSX? I have looked through the FSUIPC docs and can't find anything.

Hi John,

I'm afraid there is no offset in FSUIPC with state information about the Master Caution annunciator.

The only add-on I know off that makes that info available (via its SDK), is the Level-D 767.

Quote:

---

Originally Posted by kiek

Hi John,

I'm afraid there is no offset in FSUIPC with state information about the Master Caution annunciator.

The only add-on I know off that makes that info available (via its SDK), is the Level-D 767.

---

Yeah, I didn't think so. Didn't hurt to ask.
thanks for replying, Nico.