FlightGear: fcs/center-brake-cmd-norm unwritable

[ghost]

I have just tried to add the chocks under the nose wheel by assigning the bogey's <brake_group> to NOSE and driving the fcs/center-brake-cmd-norm property as per https://github.com/JSBSim-Team/jsbsim/blob/master/src/models/FGLGear.cpp , but the property is flickering between target value and zero if viewed in the property browser, and there is no braking force, no matter whether make a filter with name="" on it or make the filter <output> to that property.

I have tried unsetting override-fg-brake-properties that I have set, as well, it does not help.

[bcoconni]

I can't reproduce the issue you described.

The center brake is forced to 0.0 only if override-fg-brake-properties is set to false. Otherwise the property fcs/center-brake-cmd can be set to any value.

[ghost]

Oh right, I'd made a typo, had put override-fg-brake-properties under /fdm/jsbsim/systems instead of /fdm/jsbsim.

It works with <output> now, but not with name="", also when setting manually from property browser it gets reset to 0 somehow.

[bcoconni]

It works with <output> now, but not with name="", also when setting manually from property browser it gets reset to 0 somehow.

I am not getting what you are talking about. Could please provide a short code extract to clarify your statement ?

[ghost]

<property>xyzzy</property>
<switch name="fcs/center-brake-cmd-norm">
 <default value="xyzzy"/>
</switch>

Now if I set xyzzy with property browser to different values I will see the centrer brake property flickering but experience no braking force.

<property>xyzzy</property>
<switch name="fcs/blablabla">
 <output>fcs/center-brake-cmd-norm</output>
 <default value="xyzzy"/>
</switch>

This one works, I see both fcs/blablabla and fcs/center-brake-cmd-norm at the value of xyzzy.

But if I just set the fcs/center-brake-cmd-norm directly with property browser, it stays at the set value for a split second, and then gets reset to 0.

[bcoconni]

The property fcs/center-brake-cmd-norm is tied by JSBSim: https://github.com/JSBSim-Team/jsbsim/blob/6190fcc32051fd96c601b329ed320a67cacdc725/src/models/FGFCS.cpp#L743-L745 But properties cannot be tied twice meaning that the following syntax cannot be used:

<property>xyzzy</property>
<switch name="fcs/center-brake-cmd-norm">
 <default value="xyzzy"/>
</switch>

By the way don't you get a warning message when you are trying to use this syntax ?

Unlike the method above, the update of fcs/center-brake-cmd-norm via the <output> statement is simply copying the output value from xyzzy to the property (i.e. it does not need to tie the property) so the update is processed successfully.

But if I just set the fcs/center-brake-cmd-norm directly with property browser, it stays at the set value for a split second, and then gets reset to 0.

This is no surprise since JSBSim is executing the piece of code each time step, so the value that you are trying to set is immediately overwritten by your own code at the next iteration of JSBSim:

<property>xyzzy</property>
<switch name="fcs/blablabla">
 <output>fcs/center-brake-cmd-norm</output>
 <default value="xyzzy"/>
</switch>

However if you modify xyzzy from the property browser then fcs/center-brake-cmd-norm should be immediately updated to that same value.

[bcoconni]

After having given more thoughts to the subject, there is no reason why using the name="" attribute for the definition of an FCS component should result in a bound/tied property. So I pushed a series of commits that should fix the problem. The syntax below should now work.

<property>xyzzy</property>
<switch name="fcs/center-brake-cmd-norm">
 <default value="xyzzy"/>
</switch>

as it no longer tries to bind fcs/center-brake-cmd-norm to the function output. Instead it just copies the function output to the property fcs/center-brake-cmd-norm.

I will wait for the dust to settle about the <and> and <or> topic before committing this to FlightGear.

[ghost]

I'm having doubts about this because now one can not tell whether a property they want to assign a filter to will really get tied to that filter or not, when before it was clear that if didn't work it was tied by something else.

On Sun, Apr 28, 2019 at 08:42:55AM -0700, Bertrand Coconnier wrote:

After having given more thoughts to the subject, there is no reason why using the name="" attribute for the definition of an FCS component should result in a bound/tied property. So I pushed a series of commits that should fix the problem. The syntax below should now work.

<property>xyzzy</property>
<switch name="fcs/center-brake-cmd-norm">
 <default value="xyzzy"/>
</switch>

as it no longer tries to bind fcs/center-brake-cmd-norm to the function output. Instead it just copies the function output to the property fcs/center-brake-cmd-norm.

I will wait for the dust to settle about the <and> and <or> topic before committing this to FlightGear.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/JSBSim-Team/jsbsim/issues/136#issuecomment-487390624

[bcoconni]

Not sure I'm getting your point. A tied property does not mean it cannot be modified. The value of a tied property can be modified as you rightly did with the code:

<property>xyzzy</property>
<switch name="fcs/blablabla">
 <output>fcs/center-brake-cmd-norm</output>
 <default value="xyzzy"/>
</switch>

The changes I made does not remove any check. Actually the previous code was preventing something that had no reason to be prevented.

[bcoconni]

@mike402 Has this problem been resolved or do you need further support ?

[ghost]

I think so, yes, now at least it works uniformly with {left,right}-brake-cmd-norm, thank you for fixing it!

While I, personally, don't like having to use <output> as opposed to generally doing name="", as it takes new aircraft developers (and myself when I forget things while trying to help them out) hours of trial and error to figure, it would probably be better off a separate issue.

[bcoconni]

I think so, yes, now at least it works uniformly with {left,right}-brake-cmd-norm, thank you for fixing it!

You're welcome. So the issue is closed.

While I, personally, don't like having to use <output> as opposed to generally doing name="", as it takes new aircraft developers (and myself when I forget things while trying to help them out) hours of trial and error to figure, it would probably be better off a separate issue.

For the record, you can still use name="" as you were used to. The <output> tag now has exactly the same behavior than name="" with the exception that you can have multiple <output> properties while only have a single name="".