Simulating circuit breaker

Vitus · 15 Jan 2007

Hi there,

Since I started my DO228-101 project, I wanted to simulate the circuit breakers. Is it - in general - posible to simulate turned-out fuses? If so, any ideas where to start?

two pictures of the texture for the two circuit breaker panels:

best regards
Vitus

theisomizer · 15 Jan 2007

Hi Vitus,

You can simulate just about anything in FS, circuit breakers included. There are no Simvars that represent them so you would have to make your own custom system.

Are you using C++ or XML? If you are using C++ then you should probably just create a set of classes for the various circuit groups. However, if you are using XML I have no clue. Maybe someone with a little more XML knowledge could step in and answer that

Cheers,
Sean

Vitus · 15 Jan 2007

Hi Sean,

thanks for the answer! I am familiar in XML and C++, so I think a mixture of both will do it. XML for the simple optical stuff and C++ for systems that are more complex.
Is it possible to send "condition states" from C++ to XML? I think of something like this:
when the circuit breaker XX (programed in C++) cuts the circuit, it sends a "switch off <gaugeXX>" signal to the XML programed gauge. The XML gauge reacts by switching to state "off".

Hope you get what I mean.

regards
Vitus

n4gix · 15 Jan 2007

Vitus said:
Hi Sean,

thanks for the answer! I am familiar in XML and C++, so I think a mixture of both will do it. XML for the simple optical stuff and C++ for systems that are more complex.
Is it possible to send "condition states" from C++ to XML? I think of something like this:
when the circuit breaker XX (programed in C++) cuts the circuit, it sends a "switch off <gaugeXX>" signal to the XML programed gauge. The XML gauge reacts by switching to state "off".

Hope you get what I mean.

regards
Vitus

It's simple enough to set an XML L:variable that can then be "received" by an XML gauge:

Code:

double	circuitbreaker_one = 1 ;    //local variable for C gauge
ID circuitbreaker_one_id;               //pointer to memory

		case PANEL_SERVICE_POST_INSTALL:
					register_named_variable ( "CircuitBreakerOne" );  //name for L:variable in XML gauge

		case PANEL_SERVICE_PRE_UPDATE:
			circuitbreaker_one_id = check_named_variable ( "CircuitBreakerOne" ) ;  //sets pointer to XML variable contents
				set_named_variable_value ( circuitbreaker_one_id, (FLOAT64)circuitbreaker_one ) ; //sets value of XML variable to value of local C variable

There's no need to "unregister" the XML variable unless you're simply anal rententive, in which case simply send unregister_all_named_vars ; during PANEL_SERVICE_PANEL_CLOSE or PANEL_SERVICE_DISCONNECT

In your XML gauge, the variable is accessed via (L:CircuitBreakerOne,bool)...

I use this all the time in my various projects, since I have need to communicate with the model's embedded XML code as well as any XML gauges (of which there are very few) that might be used.

I hope this is helpful!

Bill
Eaglesoft Development Group

lc0277 · 15 Jan 2007

Hi Bill,

n4gix said:
It's simple enough to set an XML L:variable that can then be "received" by an XML gauge:

Do you have any idea on the performance issue of using L: variables versus C: variables declared by a IPanelCCallback/IGaugeCCallback ?

theisomizer · 15 Jan 2007

lc0277 said:
Hi Bill,

Do you have any idea on the performance issue of using L: variables versus C: variables declared by a IPanelCCallback/IGaugeCCallback ?

Hi lc0277,

I wasn't aware of any performance issues with these, but now you've got me curious :scratchch

I am in the process of moving some of my interface code from C to XML and I am planning on using a lot of IGaugeCCallback's, so I'd like to know if there is a performance hit.

Cheers,
Sean

taguilo · 15 Jan 2007

Hi,

If you know something more than basic concepts, it would be a piece of cake to develope the circuit breaker entirely in XML.
Actually the ability to program overhead-controlled systems is one of the strongest points of coding in XML.

Tom

Vitus · 16 Jan 2007

confusing

Thanks for your answers! I will test this stuff in the next few days.

Actually the ability to program overhead-controlled systems is one of the strongest points of coding in XML.

And why is that? Without knowing anything about this issue, I thought using C makes the whole gauge programing more flexible!?!

ziporama · 16 Jan 2007

Just a side comment - not that I've tried it (yet), the first thing that popped in my mind when I read your first post Vitus was the Cabin Comfort example.

You could define you own circuit breaker sim variables using the same techniques. The new properties would be of use both in XML and C++ gauges, and for 2D and VC.

Etienne

n4gix · 16 Jan 2007

lc0277 said:
Hi Bill,
Do you have any idea on the performance issue of using L: variables versus C: variables declared by a IPanelCCallback/IGaugeCCallback ?

For all practical purposes there is none whatsoever... You are effectively allocating 64bits of memory and creating a pointer to that memory block. How much more memory would be used by coding a IPanelCCallback to accomplish such a trivial task?

Truthfully though, I don't see any real "upside" in splitting such a system into C + XML code. I would either program the entire thing in C or XML...

As a payware developer, I've no real use for XML gauge code at all, for what should be obvious reasons. My only real interest in XML is communicating between my gauge system and the model's embedded XML code.

taguilo · 17 Jan 2007

Vitus said:
Thanks for your answers! I will test this stuff in the next few days.

And why is that? Without knowing anything about this issue, I thought using C makes the whole gauge programing more flexible!?!

XML stack's programming orientation makes it a great environment to work with complex mathematical structures, like algorithms, polinomials, trigonometric functions, and so on. Even you can woirk with arrays (though this needs a bit of XML advanced skills)

Tom

Waugh · 23 Jan 2007

taguilo said:
XML stack's programming orientation makes it a great environment to work with complex mathematical structures, like algorithms, polinomials, trigonometric functions, and so on. Even you can woirk with arrays (though this needs a bit of XML advanced skills)

Asserting that XML's reverse polish notation is it's strong point is like me telling you that Window's bugs are really "features". :banghead:

Also your assertion:

Actually the ability to program overhead-controlled systems is one of the strongest points of coding in XML.

is like telling me that the strongest point of this shovel you are trying to sell is that it shovel's horse manure.

XML is a tool, and so it's "strongest point" is not that it is able to do any particular job. Moreover, strongest point relative to what? C++? To compare XML to C++ at all is like comparing flying a paper airplane to the moon landing.

While as the above suggests you can use XML to make gauges (and darn complex ones if you care too do so), is certainly not the best or easiest place to do anything complex, nor will it allow you to reduce the complexity of your project in a way that makes it maintainable for those changes that must be programmed with each new version of FS.

If you doubt this assertion, just simply open up any XML gauge and compare that to code well written in C++ for readability, especially for something complex. IMNSHO

o ) reverse polish notation is for Texas Instrument calculators.

Moreover, as has been pointed out above, XML is open for the world to see (and hence not really "code" in my book

), so useless to those of us doing commercial programming except to interface to the XML compiled in the model.

C++ has a much steaper learning curve than XML gauges, and is a programming language that will take you awhile to really use efficiently and correctly, but the rewards are that you can then do ANYTHING you can dream. Be warned though, it is very addictive.

lc0277 · 23 Jan 2007

What I really like in the combined C++/XML approach is that we could emulate a model-view design pattern, which is some sort of standard for most programmers today.
The C code doing only the simulation stuff (ie managing the state of your electrical circuits according to all external events and variables) and the XML part containing only graphical stuff.
From a personal point of view it eliminates the two main drawbacks of these languages :
- no overbloated RPN expression in XML (only getting C:/L: variables with minor scaling operations)
- no huge preprocessor macros for rendering even the simplest bitmap
In fact this design involves only the primary use of these languages: systems/logic for C-C++ and data representation for XML.

As a long-time supporter of free and open source software (FOSS), I really feel disturbed by hearing those concerns about XML and pay. products. Bear in mind that being "open source", like XML, does not deprive you of any copyright ownership and thus legal protection against piracy. Furthermore, DLL/GAU files does not offer any protection for your art and image files, which maybe involved more work than for the simple gauge logic. Extracting ressources from files is very tricky you know ...

taguilo · 23 Jan 2007

Waugh said:
Asserting that XML's reverse polish notation is it's strong point is like me telling you that Window's bugs are really "features".

Hi,

If you really knew why RPN is -and must be- used in XML code, I'm sure you would think different.

XML is a tool, and so it's "strongest point" is not that it is able to do any particular job.

Yes, a tool to make gauges, like C/C++ is as well. In essence, not a difference here.

Moreover, strongest point relative to what? C++? To compare XML to C++ at all is like comparing flying a paper airplane to the moon landing.

This is not about comparing programming "tools" per se, but in regard of how useful each one can be to accomplish a given task (ie represent an aircraft gauge) Up to this point, and with exception of file I/O, sound and/or vector graphics-based gauges, there should be no external difference between an XML coded gauge over a C++ one.

While as the above suggests you can use XML to make gauges (and darn complex ones if you care too do so), is certainly not the best or easiest place to do anything complex, nor will it allow you to reduce the complexity of your project in a way that makes it maintainable for those changes that must be programmed with each new version of FS.

Coming from someone that probably knows very little about XML "real" complexity and scope, I can understand this point of view. Unfortunately, people use to make assertions and sometimes bash out different opinions just because they ignore the other side of the road.

If you doubt this assertion, just simply open up any XML gauge and compare that to code well written in C++ for readability, especially for something complex. IMNSHO o ) reverse polish notation is for Texas Instrument calculators.

Well, glad that MS keeps thinking different since the last three versions of FS

Moreover, as has been pointed out above, XML is open for the world to see (and hence not really "code" in my book ), so useless to those of us doing commercial programming except to interface to the XML compiled in the model.

Now and to be fair, this is a strong point. XML as of today is almost unusable for commercial developing. And I personally think this is the main cause for being denosted by most payware developers like you. If ever would be possible to protect .cab files in some way just to avoid piracy steal, a big part of them would be happy to code in XML, especially being aware that their project times (program-debug) could be considerably shortened.

C++ has a much steaper learning curve than XML gauges, and is a programming language that will take you awhile to really use efficiently and correctly, but the rewards are that you can then do ANYTHING you can dream. Be warned though, it is very addictive.

Almost two years ago, I didn't know what was all about that RPN stuff.
Now, I can assure you XML, once properly understood (which is not easy indeed) is very addictive as well

Tom

Vitus · 24 Jan 2007

First of all, thanks for your answers. I would have never thought of initiating such a controversy discussion with such a simple question

After some evenings concentrating on XML programming, I reached the conclusion that I dont like it.

I am programing for even ten years, basically with OOP languages like Delphi or Java and therefore I think the best approach for me is, like lc0277 mentioned, put the program logic in the C++ DLL/GAU files and all the graphical stuff in the XMLs.

The next step is setting up the environment. And even with this I got a problem! Due to the fact I dont have the latest version of MS visual studio, I cant open the project file of the SDK.
Is there a tutorial somewhere about setting up the program environment for building FS gauge file? I didnt found anything yet.

Thanks alot for your help and the interessting discussion! As a candy for your patience, two pictures of the 2D Cockpit:

Best regards
Vitus

n4gix · 24 Jan 2007

Vitus said:
The next step is setting up the environment. And even with this I got a problem! Due to the fact I dont have the latest version of MS visual studio, I cant open the project file of the SDK.
Is there a tutorial somewhere about setting up the program environment for building FS gauge file? I didnt found anything yet.

What IDE do you have? There is a tutorial available at avsim.com cleverly called "idehow2.zip" that shows how to set up the VC v6.0 IDE for gauge projects.

There's a series of 'sticky posts' at my "Panel & Gauges" forum at http://flightsim.com that illustrate how to set up the MSVC++ .NET 2003 IDE, but is also easily applicable to the .NET 2006 IDE.

Vitus · 25 Jan 2007

It works, thanks for your help!I didnt found the tuts on avsim, but your tutorials on flightsim.com are really good and made it

Stay tuned for the next stupid questions from me

regards
Vitus

n4gix · 25 Jan 2007

Vitus said:
It works, thanks for your help!I didnt found the tuts on avsim, but your tutorials on flightsim.com are really good and made it

Stay tuned for the next stupid questions from me

regards
Vitus

You are most welcome. I'm glad that they were helpful!

Waugh · 9 Feb 2007

lc0277 said:
As a long-time supporter of free and open source software (FOSS), I really feel disturbed by hearing those concerns about XML and pay. products.

Yes just aweful that you had to pay for your clothes or food.

What is disturbing to you about wanting to get paid for what you do for a living? Do they pay you at work?

We like to pay our people too, and enjoy paying others for the excellent quality of their art/work as well.

Bear in mind that being "open source", like XML, does not deprive you of any copyright ownership and thus legal protection against piracy.

Feel free to not protect/give away your work, just as we feel free to protect ours and request compensation for our hard work.

Furthermore, DLL/GAU files does not offer any protection for your art and image files, which maybe involved more work than for the simple gauge logic. Extracting ressources from files is very tricky you know ...

Actually, you could protect your artwork should you so desire by encrypting the resources. But really we are not really worried about someone using the artwork and using for their own "home built" gauge. This may be how they get started programming and learn to design their own. They will not really be able to use it to replace our gauge in an integrated panel anyway.