I'm working to interface the A2A cessna to make a home cockpit.
For the moment, I would like to see what can I do only with simple arduino and mobiflight.
I have interfaced some switches, like battery, alternateur, ... with simple Lua script.
Could someone have an idea?
The offsets reserved for users are 66C0 to 66FF. Others, just because they have no assignment listed, are not necessarily free for any unauthorised use.
Do you know what sort of values that L:Var supplies? Have you logged it? Try the Lua logging plug-in supplied for a real-time log.
Have you double-checked your coding at the other end, in the Arduino or Mobiflight (which I don't know).
I start to see more clearly, I started again from the beginning today.
I used the offsets you told me.
For the RPM, we have 14 figures, only positive. So, logically, it's on a 16bit, and usigned, so it will be "writeUW" in the script.
Idem, for the airspeed, we have 14 figures, always positive. So, logically => 16bit, unisgned.
But it doesn't work... After, I tried with other offset (66C1, 66C2, 66FF,...) always same thing.
But, to bsure that my script is good, I tried to delete the RPM script in offset 66c0, to put the airspeed in offset 66c0, and... that's work!!
So my problem now is only from the offset. I'm not sure I understand everything about offset... Could you give me a little help?
But 14 decimal digits, where each digit can go from 0 to 9. A 16-bit word has 16 binary digits, with each digit going only from 0 to 1.
So the range of numbers your 16-bit Unsigned Word (UW) can handle is 0-65535.
I am pretty sure that your value of 86.54463907825 will be written as 86 or maybe 87 (I don't remember if it is rounded, but probably).
So, what is your Arduino or whatever expecting to read? Maybe it wants the double floating point format which 86.54463907825 would suit? For that you use 8 bytes and ipc.writeDBL. Or perhaps it needs a 32-bit floating point value, in which case use ipc.writeFLT. You need to know what the receiver is expecting!
"Offsets" are just places in memory, where stuff like data can be stored. Nothing magic. They don't do any work. In your case they are just being used as postboxes.
Yes you are right, speed value is rounded.
Mobiflight use the rounded value, so for the speed, 0 to ~ 200 knots wich gives in decimal 0 to 11001000 so 8 bit, unsigned.
So if I use the offset 66c0, for the airspeed gauge, wich use 8 bit=1 byte, the next free offset should be... 66c0 + 1 byte = 66c1= the next free offset wich can be use.
First, I modified the script, for IAS, 8 bit, so ipc.writeUB, on offset 66c0. Test: all right, it works.
Next, I added the script for RPM, 16 bit, so ipc.writeUW, on offset 66c1; Test: negatif. Always ok for the IAS, but no value receive for the RPM.
So I decided to switch the positions of these scripts: and that is the problem!!: now, I haved value for RPM on 66c1, but no for IAS on 66c0!
So I have understood that only the first script is reading in the script!
on second for alternator (3344) and RPM (66c1) => and now, it works for the two gauges i same time! Because there is on 2 differents script!
Do you know if it's possible to write theses script on the same .lua text? Maybe I forgot something between the two script?
Better still, look into using the 'event.lvar()' libarary function and have two functions that get called only when the lvar changes (see the FSUIPC Lua Library.pdf, page 26).
I tried to use the library "event.Lvar()" but there is nothing when Lvar change, even if I switch some thing like battery.
tried to use the library "event.Lvar()" but there is nothing when Lvar change, even if I switch some thing like battery.
You need to specify which LVar you want the event to trap. It doesn't keep scanning all of them just in case! That would slow your system right down!
I made it very clear the Lvar between the () after "event.Lvar".
If I understand correctly, it is not enough to just replace ipc.readLvar by event.Lvar?
It's OK, I finded the good script and removed everything before.
This is my script; and it's loaded as soon as RPM value change! thanks!
The code is ok, and work great for RPM.
I tried to do one separate script for vertical speed, but it doesn't work too... it's weird.
-- First, placed in the function, it will only do anything when the function is called. But how can it be when there's no event for it?.
-- The value returned you've called value. The Eng1_RPM would be replaced by the name of the LVar, as a string (i.e. "Eng1_RPM").
Please do not try to "wing it". Refer to the documentation! That is what it is for. It would save both of us a lot of time!
Also, when testing a Lua plug-in, when it doesn't work CHECK THE FSUIPC log file. If there are errors stopping it running (as in this case) this will be logged.
Does the Lvar monitring plug-in provided in the Lua example plug-ins ZIP show proper values for that LVar name? That's your check.
Also, as just stated always check the Log for errors.
Does the Lvar monitring plug-in provided in the Lua example plug-ins ZIP show proper values for that LVar name? That's your check.
I understand that my first script was all wrong. That's why I had search to correct this, and I have find a good script few minutes later.
I don't understand what you mean with the lvar monitoring pulg-in? If your question is: does Lvar "L:VerticalSpeed" is the good Lvar for vertical speed, yes it is. Anyway, it work with my first script "while 1 do ... ipc.readLvar...end"
Reading options from "C:\Program Files\Lockheed Martin\Prepar3D v4\Modules\FSUIPC5.ini"
16 FLT path = "C:\Users\fryau\Documents\Prepar3D v4 Files\"
16 FS path = "C:\Program Files\Lockheed Martin\Prepar3D v4\"
188 ### PDKmodeHelper callback registered!
No, that was good. I thought it would help you, in future or further ventues into Lua plug-ins, to know WHY it was wrong, that was all. sorry if this insulted you!
I don't understand what you mean with the lvar monitoring pulg-in?
If you look in the FSUIPC documents subfolder (where all the odcumentation is, by the way, in case you ever want to look at it), you will find a ZIP file called something like example lua plug-ins. There's one inside that called "log lvar". If you run that you will get a display on screen of the changes in the LVars associated with your current add-on aircraft.
If your question is: does Lvar "L:VerticalSpeed" is the good Lvar for vertical speed, yes it is. Anyway, it work with my first script "while 1 do ... ipc.readLvar...end"
You never showed me one for the vertical speed.
Well, you've changed something else then. Use the plug-in I mentioned to check the LVars and their changes. It's by far the best way to see what is going on.
Nothing is running before that line in any case, so why post it?
So, yes I have found the Log Lvar.lua, anyway I have define ctrl+F2 for log lua log Lvar and ctrl+F3 for lua kill all to stop the log.
0 FLT path = "C:\Users\fryau\Documents\Prepar3D v4 Files\"
157 ### PDKmodeHelper callback registered!
I don't know why, but I have somethig like this now in the FSUIPC5.log folder, and I think this is want you expect Pete!
265922 FLT path = "C:\Users\fryau\Documents\Prepar3D v4 Files\"
284281 LUA.0: beginning "C:\Program Files\Lockheed Martin\Prepar3D v4\Modules\C172.lua"
1633297 LUA.1: beginning "C:\Program Files\Lockheed Martin\Prepar3D v4\Modules\RPM.lua"
"while my script with the event.Lvar() function is on a folder name "RPM.lua" in module folder, as C172.Lua"
Why have you named a folder "RPM.lua"? Such a folder name doesn't make a lot of sense, and FSUIPC won't look for lua plug-ins in such a folder unless you change the path for ALL lua files by adding the parameter LuaPath=<path to lua files> to the [LuaFiles] section of the INI (with the path you wish to use instead of Modules), which you have not done.
And you evidently do have a C172.lua file in the Modules folder, possibly without your extra code for the VSI?
so it seems after all that the C172.lua in the MODULES folder (NOT the RPM.lua folder as you stated) does contain the VSI code, and a value (-4 in this case) was returned.
The 28, 31 and 32 are line numbers in your lua program. Now that is more lines than in the last Lua you posted here, so I can't look at those, but you can, and you know now that they were executed and did have the value.
You have an unprintable character, that one represented by ï in the log, which is non-ASCII (It's part of the Windows implemented extensions to ASCII, using the 8th bit -- ASCII only uses 7 of the 8 bits in a byte. Lua only handles straight ASCII.
Best to delete that line completely and re-enter it, taking care with the keyboard. Those characters (special ones and those with accents) can be entered with various keyboard press combinations or sequences.
However, you were asking about VSI which was mainly what I was responding to.
When you are writing to offsets you can easily check that the values you expect are being written there by using the "monitor" options in FSUIPC Logging. See the right-hand side. You can monitor up to 4 values at a time. Just enter the offset (just the 66C3 part, not the 0x), and the type (in this case S16, a signed 16-bit or "Word"). Then below select normal log to see the vlaues in the log, or FS window for a display on screen as it changes.
If the values in the offset are correct, then look at your Arduino programming!
/ I had a RPM.Lua folder because yesterday, my script "event.Lvar" for RPM worked only on a separate folder.
/ I had check the value in the offset, and there was correct.
I ask google concerning the error "unexpected symbol near 'ï' ", it could come from the text editor, wich could put hidden special characters. I use Notepad++, and the coding use is UTF-8 (without BOM).
How is the use of "event" better for you? Because, interfacing a cessna, I finally have not a lot of variable to interface, it would not be enough with this form of script? There is some "limits"?
thank you for your help. Sorry if I'm stuck. It's incomprehensible for me, but it worked yesterday morning, but it's impossible to redo this "event.Lvar"
I had a RPM.Lua folder because yesterday, my script "event.Lvar" for RPM worked only on a separate folder.
Without telling FSUIPC to load from that folder it wouldn't have run -- unless you explicity loaded it from that folder using an ipc.runlua function in a Lua which was loaded from the Modules folder!
I had check the value in the offset, and there was correct.
It that case it is evidently a problem with your Arduino programming.
Now, it's worse... the C172gauges script is not used by FSUIPC.
That is a different script from any other you've mentioned or shown.
The LuaFiles section lists all Lua files which have ever been seen in the Modules folder. It doesn't mean it is still there or that you are running it!
How is the use of "event" better for you?
It isn't better for me. It is just more sensible as then the processor is not wasting time executing your script, but simply sitting waiting for the LVars to change. And the suggestion is very sensible. Most of the best and most relicable scripts these days use events for that reason. But it was a later addition to the Lua facilities in FSUIPC, which is why there are examples of both still abounding.
I actually think since then you've been confusing yourelf and me posting contradictory messages many times. The VSI one for instance was never mentioned before you said it didn't work any more, and then this iall the wrong assumptions you make ad repeat like that concerning folders and script names.
I completely agree with you, Pete, I stubborn this weekend and accumulated mistakes.
The only thing that does not happen is the launch of the script independently. To do this, I assigned a switch.
ipcReady.lua is executed automatically when FSUIPC detects that the Sim is "ready to fly".
I have test with the [Auto] section and it's ok!