I agree to all you say. Indeed I feel to that there's nothing that can be done with EPIC that can't be done with FSbus, PHCC or IOcards on the matter of programming system logic. Just got one question:Myth: only EPIC can handle entire functions in the cockpit and others fadeout around 200 functionsFact: Not really. IOCards system can easily handle it all and more..Can IOcards to text LCD's ? Can IOcards to graphic LCD's ? I don't care much for graphic LCD's but I know it will be worked on in the PHCC project. Can EPIC do these LCD's ?It's the reason why I chose PHCC because I'm not into 7-seg displays and want to use text LCD's instead. Much nicer, much easyer to solder, looks more real and at same cost.

>Can IOcards to text LCD's ? Can IOcards to graphic LCD's ? I knew before, that question could be on the way from you, since I already know you like them from your other posts :-) Currently no. But remember it once used to support it and the new versions did not support it due to lack of much interest, i guess. Ferdie (designer) have plans to do it but again other projects taking priority over..> Can EPIC do these LCD's ?I don't know.srinihttp://projectsri777.blogspot.com

Good to read they plan to pick that up again.I knew they once used to support those.I can't understand why the item is not more popular.As I stated here long time ago there are lots of reasons why to opt for graphic LCD instead of 7-segments.First off one must opt for the 8*2 lcds. That's the logic choise for the cockpit.1) price is equal ( 1 lcd vs 10 blocks => enough for 1 radio)2) 2 row lcd makes easy for NAV/COM/ADF radio3) LCD is already on a pcb so easy solder & wire4) no none-italic numbers available on 7-segments; with lcd you can chose which you display on the same lcd5) option to show any possible character on lcd6) decimal point is better positioned which make values look like 3 digits, a point and 2 digits. with segments the point is so close to the first 3 that it rather looks like just 5 digits)7) segments are very hard to solder if you can't find a pcb for it or make one yourself8) one needs smaller numbers in the radios than most segment users get as result; lcd does that for ya.9) simply because in real .. they use LCD's anyway. (as real as it gets ?)Can't quite remember but I'm almost sure there are even more reasons.

>Fact: Not true. IOCards gives you two levels of complexity>options. If you are a non-programmer, you can simply map>offset functions to I/O connections and be done. But if you>love the coding challenge and want to simulate complex>functions, by all means, you can do that too with their SIOC>programming interface. Can you use both at the same time by the way? I mean, mapping stuff like "landing lights switch" via the "easy" interface makes sense, since its just a switch without much logic. But for stuff like radio 7-segment leds, transponder ident blinker for Squawkbox 3 etc, you need the SIOC. Can I build those complex ones with sioc while having most of the easy stuff via the easy method? Or do I need to do everything via SIOC?//Tuomas

>Can you use both at the same time by the way? I mean, mapping>stuff like "landing lights switch" via the "easy" interface>makes sense, since its just a switch without much logic. You cannot mix the old software that gave you the mapping ability and the new sioc programs. Atleast not easily. But wait..That is exactly what i have added on top of SIOC (making the old mapping software redaundant) with my opensource project GenEx (http://iocards-genex.sourceforge.net/) and for more background info: http://projectsri777.blogspot.com/2005/03/...ibution-to.html ).SIOC is the new script driven programming direction IOCards is gradually moving towards and for some non-programmer iocard users, this is troubling. So, I initiated a new project (Disclaimer: I am not part of the IOCards team, but a normal regular user) that allowed users to easily map their routine buttons and displays by simply entering their connections information into an excel spreadsheet file. Then underneath, my program automatically generate all the necessary sioc program logic code for them.> But for stuff like radio 7-segment leds, transponder ident blinker>for Squawkbox 3 etc, you need the SIOC. Can I build those>complex ones with sioc while having most of the easy stuff via>the easy method? Or do I need to do everything via SIOC?Yes, if you wish (but the truth is you don't need to in most cases as you'll see..). My program generates both source text file and final compiled binary file. You can edit the source code if you wish and add any other logic as you need. But the truth is most of the time that is not even necessary. Since my program currently generates complete working sioc programs for the entire different panels for different aircrafts. So, basically, all the stuff you mentioned will also be taken care by GenEx and the end result is you'll have fully functional SIOC program that includes any complex logic required for a given panel.But, if you like being hands-on, you can do the same as i was doing on your own.Currently, i have fully tested autogeneration code working for 777 and 737 MCP and EFIS panels. More panels like overhead and pedestal will be added incrementally making the guys who don't want to deal with sioc programming and fsuipc/PM offsets happy, while at the same time, leaving room for others to explore on their own.regardssrinihttp://projectsri777.blogspot.com

>You cannot mix the old software that gave you the mapping>ability and the new sioc programs. Atleast not easily. >>But wait..>>That is exactly what i have added on top of SIOC (making the>old mapping software redaundant) with my opensource project>GenEx Yeah, tweaking the code is not a problem - its just programming logic which is something one can learn, just the syntax is a bit weird because one doesnt have symbolic variable names (which should be added IMHO, cannot be that hard really :) We learned to weld, to use a hacksaw and to design cockpit constructions. This is just another thing to learn, nothing worse.The logic stuff is very powerful, we have been doing some stuff with FSBUs' "CCC" facility, I do like the graphical "network layout" interface a lot, since it shows things in a logical way, but I guess SIOC wont be too bad once I learn it. It sure seems pretty powerful as a programming language.//Tuomas

Sorry to dig this thread out of the blue but I was catching up on the action and this post from FVAPRES had me puzzled?>I am building my own custom software for my project (737NG). >I cannot fathom spending 25% the projected cost of my sim's>hardware on the software alone when I do, indeed have the>programming knowlege and patience to do it myself.What is the projected cost of your sims hardware? When you say you can't fathom spending 25% of projected cost on software, are you referring to Project Magenta? I also assume this because you say you've started coding your own software. I make the cost of the complete package, including PMsystems, around 668EUR. My own 737 sim is now becoming quite advanced, but I don't know how the heck I'd have got here without that software. Admittedly, I bought it before the price increase.What I really don't understand is that after making the statement about not warranting the expense, you then seem to be placing your support behind EPIC? Don't get me wrong, EPIC is a great system, and I spent well over $1000 on EPIC USB based hardware, and then faced the pain of understanding MODULES, ROWS, CONNECTORS and everything else. I then ditched EPIC and spend a couple of hundred $'s on IOCards and have not looked back since. Easy to use, damned powerful - my nearly complete 737NG overhead is driven solely by IOCards and PMSystems and, given another month or two, I would challenge ANY 737-800 type rated pilot to find a significant flaw. Maybe you can achieve that with your own software and with EPIC with MANY months if not years of effort, but why have you chosen THE most expensive commonly available interfacing system when the vast majority of the current serious sim building community will tell you there are better (and far cheaper) options. It just doesn't match with your comment on software costs.As for support, I admit Ralph Robinson is a SUPERB guy. He helped me immensely, but he is only one person. The support from MicroCockpit (and as far as I can tell Flight Link) is virtually non-existent. These are the companies who are PAID by Ralph to provide the support. I believe they do him more harm than good. The 'LATEST' EEPROM for the USB card on MicroCockpits appalling support section is STILL dated 2002. I don't comprehend your reasoning, unless it is the only hardware which supports your chosen method of interfacing, in which case why not stick with Project Magenta, save yourself a couple of years of programming headaches and have the choice of ALL the available interfaces (Phidgets, FSBus, IOCards, FDS new arrivals, EPIC etc). The overall cost would probably be less, and you'd achieve your goal a heck of a lot sooner.>>With all these pieces of the software, I need an interface>that doesn't talk to an offset in FS (my software talks to>itself via the named memory spaces separately, so all>variables stay in tact - no need to put the info into FS as>that wastes processing power on the FS computer). For me,>EPIC is the easy choice as I can make the switches do anything>I program it to.>I also do not know of any of the other solutions that allow>you to hook up EVERY piece in the 737NG cockpit. That's over>300 switches. EPIC can handle just that. Most others fade>out around 200 or less. I want a cockpit that isn't just>procedural with the switches. I want them to actually do>something, as if you're really flying the beast.Have you actually USED any of these systems in anger. I have, and I can honestly vouch that the above statement is plain wrong.I don't question your motives at all, and I admire the time and effort that you seem to be giving to the forums, but, as a planner, and hopefully soon to be builder, can you really give a truly knowledgeable opinion on some of these topics based solely on theory and planning?In the two or so years that I've actually been building, I've probably made as many bad calls as good calls and I have learnt from those mistakes. Only through actually DOING, the work, not just researching it, and listening to others who are actually DOING the work, have I been able to get where I am (and believe me there is a LONG way to go).Please don't take this as a negative post, I don't mean it to be. I've seen some great advice on one or two of your posts, but I do question your judgement on the above.Chriswww.virtual737.com