Howto talk:Methods to replace the NASAL code with JSBSim code

To me this HowTo seems confused and in its present state not very helpful to anyone. Can you try this single component instead of what you propose in this HowTo?

   <channel name="JATO">
       <switch name="systems/jato/throttle-norm">
           <default value="0"/>
           <test logic = "AND" value = "1">
               systems/jato/ignition-on == 1
               systems/jato/rocket_number_1 == 1
           </test>
           <output>fcs/throttle-pos-norm[1]</output>
       </switch>
   </channel>

This would be a pure JSBSim-side way to control the JATO ignition. Also note that the name of a component should (preferably) be the name of a property tree node that doesn't exist beforehand. AndersG (talk) 15:52, 11 August 2018 (EDT)

@AndersG Meanwhile, I do not understand why the article is not useful ... certainly converting the NASAL code in JSBSim may seem strange, but JSBSim is a very good and fast language that allows a direct control of parts of the aircraft and often can completely replace NASAL avoiding having to use two different programming languages. The example (certainly can be improved) describes the method of starting a rocket engine of an aircraft (G91R1B) for the assisted take-off (see this example: https://youtu.be/wdr9CuAsBL0 ). The ignition of rockets requires to manage a series of procedures and checks on the status of the power supply bus (entirely realized in JSBSim) and some switches (also managed via JSBSim) that in the old writing with NASAL code produced an overlap of the code . The rewriting in JSBSim has simplified everything and avoided having to write two procedures (with concurrent logic) different motion between them. I must point out to you that the solution you have found (I obviously tried) does not work and the reasons are descripted in the article discussed here, as there is a continuous rewrite of the variable: fcs/throttle-pos-norm[1] by FGFS that cancels any modification realized by JSBSim. --Abassign (talk) 17:11, 11 August 2018 (EDT)

@Abassing JSBSim itself continuously rewrites fcs/throttle-pos-norm[1] from fcs/throttle-cmd-norm[1]. However, when you put a FCS component that does so too it'll win over JSBSim's default write. Unless you use execrate on the channel, I suppose (and I suppose that that is an unforeseen bug with execrate, which is a fairly new and untried feature of JSBSim). I've looked inside FGRocket.cpp in JSBSim and it seems to use fcs/throttle-pos-norm[x] just like FGPiston.cpp so I don't expect that rocket engines behave differently in this regard than piston engines where this method is well tried. AndersG (talk) 17:46, 11 August 2018 (EDT)

@AndersG Thank you for your note that is really valuable and that will lead to a modification/update of the article, it is at this point necessary to introduce also the parameter execrate and its side effects necessary to correctly perform the conversion of NASL code in JSBSim. I did the test by removing the parameter execrate and changing the code as you wrote yourself, at this point it worked, but it's just a patch, because the variable /controls/engines/engine[1]/throttle still keeps writing on the variable fcs/throttle-cmd-norm[1] and then the rockets start (in an unwanted way) as soon as the value of /controls/engines/engine[1]/throttle becomes equal to 1 (100% throttle).
Is necessary to introduce an inhibition by set this parameter sim/input/selected/engine[1] to zero for example by this code:

var prop = props.globals.initNode("sim/input/selected/engine[1]", 0, "BOOL");

by NASAL code ... or by JSBSim ... but at this point it does not seem convenient to do so .. because we must introduce some code that is not consistent with the written JSBSim code, as it only serves to introduce a patch.
The problem is that it should be possible to have a method to inhibit the modification by the FGFS code of some JSBSim veriabili. But I want to discuss this part with you in the JSBSim github, as I think it is a technical problem to be analyzed further. --Abassign (talk) 04:04, 12 August 2018 (EDT)