No a "flame" really - just a small correction. While I cannot speak about other solutions in this respect, the total # of BI units that can be attached to a PC is "limited" by the system itself which stands I believe, at 128. Based on my understanding on how Keyboard studio works it is very easy to serialize and identify individually each and every BI module so making a small math exercise for GammaRay(128 x 256) brings this to a bit more than the 1000 limit you hint - not that this makes any difference. This subject is highly academin IMO since I am yet to see one cockpit having that many switches and knobs - LOL!

Yep. Most of the choices have "enough" inputs and outputs. :)What was pretty interesting to me was trying the "Simboards" software (one can download it from the site) - it had so far the most intuitive setup I have seen, and if one wants custom code, one mouse click gave you a small text editor where you could write a small Visual Basic script. It would be associated with that switch or led or whatever. While I dont care much about VB myself (pretty much any language works and can be learned, as long as it does the job.. SIOC as a language definition is very strange in itself for example with the numbered variables, but I solved that issue with a conversion script of my own) - what I liked a lot in simboards is the possibility to combine easy pointy-clicky setup of trivial stuff with custom code snippets, using the same tool.With iocards it's "all or nothing" - as an iocards user one should really learn sioc from the beginning, because the moment you need that custom snippet, you need to convert everything to sioc anyway.Man, this must be such a huge confusion to newcomers.. we have sort of "grown into" the options and have our own knowledge of what is what.. we know the features of our choice and the shortcomings and have learned to work around them.. it's quite a load of knowledge to absorb...//Tuomas

>I agree completely with you that one should try to stay away>from Visual Basic as long as possible ;-). VB is something>that should be kept in a Museum, its not really the right tool>for real time programming (IMHO). I am not sure how you define "real time programming" under Windows XP Nico... WINXP is NOT a RTOS despite M$'s eforts to prove it otherwise. In this sense, VB is as RT as any language under WINXP!>SIOC with its event driven approach is much more suited to the>needs of real time programming of logic for aircraft systems.SIOC is as "event driven" as ANY programnming language - even Visual Basic :-). Come to think of it, SIOC is neither an RT language nor an "event driven" one in the proper sense of the definition. SIOC - is actually polling the inputs and reacts to their state - if that is what you call "event driven" than so be it. The proper definition of "event driven" though refers to interrupts and not polling and that is quite far from how SIOC is conducting its business behind the courtains. SIOC may do that polling quickly enough that it becomes irrelevant whether it is RT or not (for home cockpits), but calling SIOC "event driven" or hinting that it might be RT is quite an exaggeration which at best it looks funny, at worst it misleads.VB might not be the most attractive language for many applications, but for prototyping and "systems programming" for non-critical applications like home cockpits it is more than enough - and simpler to use too, considering the vast lib availability, powerful debugging and GUI. It also enjoys a popularity with novices other languages lack. Besides, VB is only ONE option for intefacing LevelD or Betainnovations SDKs.C++ etc. is also an excellent option and I believe that it does not belong in a museum (yet).

>VB might not be the most attractive language for many>applications, but for prototyping and "systems programming">for non-critical applications like home cockpits it is more>than enough - and simpler to use too, considering the vast lib>availability, powerful debugging and GUI.The point is, any turing-complete programming language is potentially possible to use in a home cockpit. But we like SIOC, it works nicely for us, you are happy with VB, so there is no problem, right?What kind of home-cockpit related libraries have you found for VB by the way? SIOC of course has no concept of libs, though one can do subroutines. But as it is designed specifically for iocards, one doesnt really need them in the same sense as one would if using a general purpose language.> It also enjoys a popularity with novices other languages lack. Unfortunately.I am not sure if there is more horrible VB code than there is horrible PHP code in the world.. it's not the language's fault of course.. :)//Tuomas

>It also enjoys a popularity with novices other languages lack. That's not really appealing to me. I'm in the computer programming business as a professional for 28 years now, so not really a novice ;-)That's why I know and have experienced that there are more powerful programming languages then BASIC. But if you are happy with it stay with it, no problem.There are several ways leading to Rome.Cheers,Nicowww.nicokaan.nl

As I said - use the right (and enjoyable) tool for the right job. I was only trying to put definitions in order and separate marketing myths from facts (for the benefit of other, less programming-knowledgeable ppl around here)Besides that, I sincerely respect and admire your experience and your contribution to the community - especially for those who are deep into LevelD :-).

I was not making a stand for VB - I was rather trying to clarify RT and "event driven" concepts which were liberally thrown in as advantages of SIOC against VB. As I said before - "balancing act".Regarding VB's specifc capabilities (or lack-of): anybody may like or dislike any language - but IMO one should be considering each language's merits relevant to a certain job: I might not like screwdrivers but I sure as h..l use one to drive a screw instead of using a hammer for the job.There are no special VB libs for FS programming and that's exactly what I did NOT mean. What I meant was that one can write very sophisticated programs quite easily in VB or C++ by using ready-made libraries - just like PM did with their Systems application, and that without needing to learn yet another language. Interfacing any I/O device is an easy task in C++ or VB and it becomes almost trivial if you are given a proper SDK and god examples to kick you off in the process.Nico chose the correct path (for him) IMO. He used C++ for the "high level" application and - I think - went down to SIOC only because he didn't have a proper SDK. So he used the right tools for the right jobs.SIOC might be perfectly suitable for one-off jobs - nothing wrong with that. But giving it mythical properties like RT and "event driven" while all it does in this sense is regular polling, is an entirely different story :-). It even shows on the CPU-used counter as being busy as h..l checking those inputs which tells me it's not optimized or terribly clever either. Or maybe it has something to do with the slow PIC used by the HW?

>I was not making a stand for VB - I was rather trying to>clarify RT and "event driven" concepts which were liberally>thrown in as advantages of SIOC against VB. As I said before -> "balancing act".Yep. There are a lot of choices, and it's hard to choose without knowing more than one ever wanted to learn in the first place :)>I might not like screwdrivers but I sure as h..l use one to>drive a screw instead of using a hammer for the job.Nothing wrong with hammers, as long as they are big enough =)>wrong with that. But giving it mythical properties like RT and>"event driven" while all it does in this sense is regular>polling, is an entirely different story :-).Yeah. I meant this from the cockpit builders perspective - not how sioc and the hardware is implemented. The structure of the language is quite different from "normal" languages, since sioc is designed around this specific task. This is what I meant by "event driven", not hardware level.The SimBoards software has quite similar approach, just with Visual Basic scripting - but the difference to "plain" VB is that you don't write one program, but rather each hardware input and output has its own small "program snippet" that gets executed whenever the state of that particular input/output changes. SIOC works the same way, you have variables that correspond to switches, leds, FSUIPC offsets etc - and then you write small snippets of code after each one. It can be as simple as this:// Gear lever Var 2, Link FSUIPC_OUT, Offset $0BE8, Length 4 // 0=up, 16383=down Var 3, Link IOCARD_SW, Input 89 // Landing gear switch{ V2 = V3 * 16383 } Or also more complicated. The number variables are braindead though, and should really be assined at compile time rather than by the programmer.. :-/ Hence I wrote a script to do that for my own code.Luckily the iocards team is working on stuff and improving the code and hardware.//Tuomas

I am a believer in KISS (Keep It Simple Stupid)I like BI's products. They are simple to use and they work. In fairness to EPIC, I have never used thier products. I haven't felt a need.John

>Besides that, I sincerely respect and admire your experience>and your contribution to the community - especially for those>who are deep into LevelD :-).Hi Al, Thank you for your kind words, really appreciated. I would like to spend just a few more words on SIOC, not to arrive at a point to see who's right, but for a better understanding.The major advantage IMHO is 'ease of expression'. Every programming language has abstractions designed for it's application area, and SIOC is ofcourse meant for home cockpit control apps.I agree with you that SIOC has to poll the FSUIPC input variables, but that's it with respect to polling. The IOcards hardware interrupts SIOC if there are changes, that's a sort of event.Furthermore, a SIOC program can be seen as a neural network. Only if a stimulus arrives (i.e. a var value changes) the attached piece of code (i.e. the var body) is executed. This gives us the concept of concurrency. Another important language construct for our kind of applications is the TIMER. So maybe we should better call SIOC an 'event-based scripting' language. :-)Cheers!Nicowww.nicokaan.nl

Hi guysI wonder where can i find SIOS tutorial for beginners , hopefully in englishSomehow failed to find that on OC siteTnx in advance

Hi,Unfortunately there is no SIOC tutorial for beginners. I have written down the basics of SIOC, and I explain a small example on my site, page IOCards, section SIOC.Opencockpits does provide two very extensive powerpoint presentations on SIOC in their downloads area. But I admit they are rather complicated. If you stick to the basics, i.e. use a text editor like Notepad to write your configuration text file, compile your file with config_sioc.exe, and run your compiled program with sioc.exe, you are in business! ;-)You could also study my config files for several systems of the Level-D (Level-D SIOC sources.zip), they should give you some clues...Regards,Nicowww.nicokaan.nl

Tnx for advices, NicoWill visit you exelent site again and try to figure out how to dealwith that :-) So far my programing skils unfortunatly are close to noneThats where the Fsbus has big advantage on IO sotware with his great GUI

Well.. I've been watching this thread and I have to throw in my $0.0002 worth.There's a lot of talk about the dis-service we do to our fellow builders by making broad comments about things we know nothing about and yet in those same threads are comments about how System A will beat the pants off of System B, yet the commentator doesn't even own System B and has never even worked with it.-That- is the dis-service that we do to our fellow sim builders.I think someone also mentioned that "Why do we keep going down these same roads...". 10 years ago, this hobby had very little in the way of options and avenues of entry. If you wanted to build a sim, chances are that EPIC was your only solution. Today the field has exploded and therefore is no longer as static as it used to be, hence these questions will keep coming up and as veteran sim builders, it's our responsibility not to cloud the answer with personal preferences perceived as fact.

>Thank you for your kind words, really appreciated. Raelly meant what I said :-)>I agree with you that SIOC has to poll the FSUIPC input>variables, but that's it with respect to polling. The IOcards>hardware interrupts SIOC if there are changes, that's a sort>of event.>>Furthermore, a SIOC program can be seen as a neural network.>Only if a stimulus arrives (i.e. a var value changes) the>attached piece of code (i.e. the var body) is executed. This>gives us the concept of concurrency. Another important>language construct for our kind of applications is the TIMER.While its true that a device like OA cards are "Interrupt" driven the interrupt can ONLY OCCUR from the Host side, never the USB device itself. USB is a HOST centric protocol and the HOST is the only thing can can initiate a communication. That means the programmer "polls" the USB device upon which the HOST driver "interrupts" the USB device and asks "is there any new data for me?". The new data is then sent up the chain back to the "polling" software. The device can never say to the host "hey I have new data". So not really "event driven", "interrupt driven" hardware-driven event for SIOC/OA - sorry.Polling is not necessarily a bad thing, but its important for SIOC and non SIOC users however to understand the true extent of SIOC's abilities.Well - elevating SIOC to a "neural netowrk" status just does not fit in with anything. If an algorithm reacts to some "If A then B" condition does not make it automatically a neural network - LOL! I used to simulate Neural Netowks in Prolog on multiple CPUs some years ago when I was playing with AI concepts for medical diagnostic expert systems and I can safely say that SIOC is not anything "like" a neural network.One thig is true though - it is a scripting language with a very specific purpose working with a very specific HW device. No special glory (or lack-of) in that respect.