ipc Lvars read slowly

[sisoffi]

Hi Pete,

im tring to interface the guidance of my md80 leonardo with IPC Lvars.

The variable read is : md_ipc_ap_hdg = ipc.readLvar("L:md_ipc_ap_hdg")

the write ipc.writeUD(0x68EC,md_ipc_ap_hdg)

trough a lua file in the folder modules.

P3D 4.5 

fsuipc 5.15

the problem is that in my external interface 7segment display and also in mobiflight the fsuipc value lag for microseconds and 

interchange by a fraction time with 0000 for the altitude and 000 for speed and heading.

 

I noted also that output leds work slowly instead the pulse normally show in the Virtual cockpit.

 

Can you help me about it?

 

thanks

Simone

[Pete Dowson]

L:Vars are read directly through the P3D panels interface. There is no built-in delay in FSUIPC. You say "lag for microseconds". How are you measuring such a minute lag? It would take milliseconds in any case (i.e. thousands of microseconds). Nothing in FSUIPC measures microseconds.

I don't know why the L:Vars you are reading alternately give 0. That has to be a function of the aircraft panel coding because if the variable was unavailable the return is nil, not zero, and trying to display that as a numeric will give an error.

Run the LVar logging Lua plug-in provided and observe the values there as they change.

BTW why not read the speed and heading from the normal P3D offsets? I'm sure they must be correct. Using L:Vars for such basic values seems very odd.

Pete

 

[sisoffi]

Thank you Pete.

Im using via mobiflight and arduino to intercept the offset read from lvar and send to a 7segment display.

If i run Lvar logging i imposible because many data scroll without chance of read something.

"BTW why not read the speed and heading from the normal P3D offsets? I'm sure they must be correct. Using L:Vars for such basic values seems very odd."

What do you intend to with this? is not the method i just use with the ipcLvars and offset?

[Pete Dowson]

1 hour ago, sisoffi said:

If i run Lvar logging i imposible because many data scroll without chance of read something.

Check the log file!

1 hour ago, sisoffi said:

"BTW why not read the speed and heading from the normal P3D offsets? I'm sure they must be correct. Using L:Vars for such basic values seems very odd."

What do you intend to with this? is not the method i just use with the ipcLvars and offset?

I don't understand why you are using L:Vars for standard values available direct from P3D in existing offsets.

I have no idea what you "intend", I'm just amazed that you resort to L:Vars when there's no need! Look at the main FSUIPC Offset list!

BTW why are you using offset 68EC?  The user offsets are 66C0 to 66FF. Your zero displays might simply be something else using that reserved offset!

Pete

 

[sisoffi]

log file in attach.

my script for lua is :

 

 

--GLARESHIELD  ----------------------------------------------------

--WING
master_warn = ipc.readLvar("L:masterwarn_adv1")
ipc.writeUD(0x6748,master_warn)

master_caut = ipc.readLvar("L:mastercaut_adv1")
ipc.writeUD(0x674C,master_caut)

--GUIDANCE IPC
md_ipc_ap_alt = ipc.readLvar("L:md_ipc_ap_alt")
ipc.writeUD(0x68F0,md_ipc_ap_alt)

md_ipc_ap_spd = ipc.readLvar("L:md_ipc_ap_spd")
ipc.writeUD(0x68E8,md_ipc_ap_spd)

md_ipc_ap_hdg = ipc.readLvar("L:md_ipc_ap_hdg")
ipc.writeUD(0x68EC,md_ipc_ap_hdg)

md_ipc_ap_vs = ipc.readLvar("L:md_ipc_ap_vs")
ipc.writeUD(0x68F4,md_ipc_ap_vs)

ipc.sleep(50)
end

 

 

are not correct the offsets?

 

thanks.

Simone

FSUIPC5.4.log

[sisoffi]

Dear Pete,
I think I understood the logic of Lvars.

If the maddog reads for exxample the variable md_ipc_ap_alt = ipc.readLvar("L:md_ipc_ap_alt") 

and writes it in a free offset (of my choice?) ipc.writeUD(0x68F0,md_ipc_ap_alt)

why this offset is 0x68F0 is in use? ( i found this old script from my old maddog)

Then, instead 0x68F0 can you say me which free offset can use? there is a list of free offset can find somewhere?

thanks

Simone

[spokes2112]

Is this the full lua script?
Probably not as there is an "end". Might be better to show the whole script.
Are you using "event" listeners? If not you should. "Event" listeners will trigger only when the value has changed.
It seems like you are loading script this each time any l:var is changed or it is on a constant loop, either will cause delays.
The free to use offsets are 0x66CO - 0x66FF. (Modules\FSUIPC Documents\FSUIPCx Offsets Status.pdf)
Another thing noticed is your offset types, maybe(?) use the following to save available user space -
- UB for the cautions
- UW for speed and heading
- UD for altitude
- SW for VS

Just an example of using listeners and proper offsets. Load this lua using [auto], leaving it running while flying the maddog.

--GLARESHIELD  ----------------------------------------------------
--WING
function md_warn (varname, value)
	ipc.writeUB(0x66C0, value)
end

function md_warn (varname, value)
	ipc.writeUB(0x66C1, value)
end

--GUIDANCE IPC
function md_speed (varname, value)
	ipc.writeUW(0x66C2, value)
end

function md_hdg (varname, value)
	ipc.writeUW(0x66C4, value)
end

function md_alt (varname, value)
	ipc.writeUD(0x66C6, value)
end

function md_vs (varname, value) 
	ipc.writeSW(0x66CA, value)
end

event.Lvar("L:masterwarn_adv1", 100, "md_warn")
event.Lvar("L:mastercaut_adv1", 100, "md_warn")
event.Lvar("L:md_ipc_ap_spd", 100, "md_speed")
event.Lvar("L:md_ipc_ap_hdg", 100, "md_hdg")
event.Lvar("L:md_ipc_ap_alt", 100, "md_alt")
event.Lvar("L:md_ipc_ap_vs", 100, "md_vs")

 

[Pete Dowson]

2 hours ago, sisoffi said:

are not correct the offsets?

The offsets you are using are listed in the FSUIPC Offsets list as "reserved". Why did you choose them? They are listed in the FSUIPC as "reserved". I don't recall what for, but they may be is use for other things. As listed, and as I stated, the offsets free for users to use as they please are 66C0 to 66FF.

1 hour ago, sisoffi said:

why this offset is 0x68F0 is in use? ( i found this old script from my old maddog)

I have no idea. What is actually reading these offsets to display them? It is that to which you need to refer, surely?

1 hour ago, sisoffi said:

Then, instead 0x68F0 can you say me which free offset can use?

I told you earlier and just above (please do read things): 66C0 to 66FF.

I see spokes2112 has contributed -- his suggestion looks very good indeed.

However, the big question for me is: what is reading these offsets and writing to your displays?

The Log file is useless. For some strange reason you are pressing "NEW LOG" -- you did it trice, as indicated here:

[Continuation log requested by user]

and here:

[Log closed by user request, and continued in new file]

Please do NOT press NEW LOG. That starts a new blank log and you may lose the important details!

Pete

 

[sisoffi]

Thank you Pete and thankyou  Spokes2112.

this is in attach the complete Lua script. I see the example and will try it.

I have also a reply from maddog team that :

"I think it's all backed up by the refresh of the "exposed" variables, he kept it deliberately low for a performance talk"

ill try to investigate.

MADDOG.lua

[sisoffi]

Hi spoke2112, 

I've tried to use your script but not work.

Can you please modify the script directly in the previous?

 

many thanks

 

[Pete Dowson]

53 minutes ago, sisoffi said:

I think it's all backed up by the refresh of the "exposed" variables, he kept it deliberately low for a performance talk

I've no idea what that means1

47 minutes ago, sisoffi said:

I've tried to use your script but not work.

This is probably because the offsets are being read by something else, which oyu haven't identified, and changing them won't work without changing that too1

WHAT is reading the offsets? Is it the MadDog directly? does it use FSUIPC? Does it say it needs FSUIPC?

Pete

 

[sisoffi]

i attach the new log file.

The lua script post to spoke2112 doesn't work

Quote

 

 

FSUIPC5.log

MADDOG.lua

[Pete Dowson]

I see you are using LINDA. I think you may need to ask their support.

You are constantly writing zero to those offsets, the ones you will or cannot say why you chose. You still haven't said what it is driving your displays. How can you expect help?

The other thing I note is that your Lua plug-in is headed:

-- MD80 Interface BY sKALARKI
-- LUA Script V 1.0
-- 20.10.2011

2011? That must surely pre-date the MD80 aircraft you are using? What makes you think it is in any way still relevant?

Maybe this "sKALARKI" can offer something for your P3D4 version?

BTW, the Lua is a bit of a mess. All the part till "--GLARESHIELD"  only gets run once, when the plug-in is first loaded.  Is that what you really intended?  Then, at the end of your Lua plug-in you have "ipc.sleep(50)" which is really unnecessary and is only excuted the once too. and the "end" right at the end is invalide -- there's nothing for it to complete.

Pete

 

[sisoffi]

Pete,
I don't use Linda. I installed it to understand if through its logging I can better understand the lua variables. I can unnistall it.

The hardware I still use relies on Skalarki (hardware manufacturer for 320) but no longer supports the md80 anymore since the old version.

I reused the same file even on the new version as many Lvars are still in use and I added the new Lvars  for guidance/glareshield.

Could you help me better solve the script? I tried to insert the one above but it doesn't work.

[sisoffi]

all other Lvars (apart guidance) are only output Leds

[Pete Dowson]

10 hours ago, sisoffi said:

I don't use Linda. I installed it to understand if through its logging I can better understand the lua variables. I can unnistall it.

It confuses the issues very much. It runs many of its own plug-ins AND external hardware drivers modules.

10 hours ago, sisoffi said:

The hardware I still use relies on Skalarki (hardware manufacturer for 320) but no longer supports the md80 anymore since the old version.

So is there a driver they supply which uses those original offsets you had? That's what I'm still asking, all these times. What is reading those offsets and sending them to your hardware? I've no record of ever assigning any to Skalarki -- they never applied for an assignment. Looking through my records IU see you are encroaching on offsets assigned to others:

6700-67FF = Jean-Michael Biston ("Michael") for Airbus gauges
6800-6BFF = Robert Fischer, FS-Communicator

10 hours ago, sisoffi said:

Could you help me better solve the script? I tried to insert the one above but it doesn't work.

Your last script has a mix of event-driven LVar reading, and a set before it which only execute once, when the script is first started. I think you need to work out what it is you want to do. Just saying you "want it to work" is no use. You need to say exactly what you are trying to do and why. If you have some hardware driver which is using the original offsets you showed, albeit "illegally", then you will need to stick to those and using the formats it requires. But you still say nothing about what is supposed to happen to the offsets you are writing despite my repeated questions about this.

In your last effort you changed to proper user offsets but you don't say you changed the hardware driver to match.

Sorry, but you are continuing to provide too little detail.

Oh, and before you provide another log, make sure Linda isn't running, and enable the Lua logging.option.

Pete

 

[sisoffi]

Hi Pete, I leaved the Linda and no there is only Fsuipc in the modules.

The driver was skalarki board and not assign never in the fuispc offsets. The Board is not in use from me and use Arduino with Mobiflight.

 

[spokes2112]

Pete,

I think this is how he's doing it - 
MaddogX custom values (non-FS) --> Lua --> FSUIPC Offsets --> Mobiflight <--> Arduino --> Hardware

Looked at the Maddog L:vars in the model using a hex editor to find data type to "try" to reduce FSUIPC offset use.
It was found that there is too much data to use the "user" available offsets.
The original offsets are being used in the "reserved" area. ( they worked before, not correct though!)
It is unknown if the Mobiflight/Arduino software will read anything other than a double so the data types remains unchanged.

Simone,

Reworked the complete lua file & updated all the lvars to MaddogX, tested and it works (see FSUIPC.log) writing to the same offsets that you originally provided. The lua has a plethora of notes within.
Attached below.

Hope it helps,
Roman

MADDOG_X.lua

MADDOG_LVAR_LIST.txt

FSUIPC4.log

[Pete Dowson]

2 hours ago, sisoffi said:

The driver was skalarki board and not assign never in the fuispc offsets. The Board is not in use from me and use Arduino with Mobiflight.

In that case you need to change your Arduino program to use the different offsets if you have to change those.

Ah, I see spokes2112 has replied with a solution.

58 minutes ago, spokes2112 said:

I think this is how he's doing it - 
MaddogX custom values (non-FS) --> Lua --> FSUIPC Offsets --> Mobiflight <--> Arduino --> Hardware

Right. So the offsets used are defined in the Arduino program. Is "mobiflight" another software driver? I don't think I know it. I have an Arduino (used with an add-on board to control my 737 magnetically held Starter switches). I don't remember how i programmed the Arduino -- I think I used their software.

1 hour ago, spokes2112 said:

too much data to use the "user" available offsets.

Ouch!

1 hour ago, spokes2112 said:

It is unknown if the Mobiflight/Arduino software will read anything other than a double so the data types remains unchanged.

I think you mesn "double word"  (DWORD). A "double" is an 8-byte floating point number,. 😉

1 hour ago, spokes2112 said:

Reworked the complete lua file & updated all the lvars to MaddogX, tested and it works (see FSUIPC.log) writing to the same offsets that you originally provided. The lua has a plethora of notes within.

Wow! That's a lot of work! I've never seen so many events in one plug-in! 😉

Thank you so much for jumping in and helping Simone so comprehensively. He did have me at a loss, not knowing what he was doing. 

Oh, just noticed. According to your Log, I see you are using FSX. will the P3D4 version of the Maddog still be the same?  Most aircraft add-ons need serious changes to work in the 64-bit world.

 

Pete

 

[spokes2112]

33 minutes ago, Pete Dowson said:

Wow! That's a lot of work! I've never seen so many events in one plug-in!

Wrote a little VB program to convert Simone's original lua to the new style. That took care of a lot of the work quickly :)
Yes a lot of events. During logging, watching it load, it took quite a few seconds. Then once it loaded the event listeners took over updating everything - a couple more seconds.. After that it was smooth & responsive. :)

33 minutes ago, Pete Dowson said:

Oh, just noticed. According to your Log, I see you are using FSX. will the P3D4 version of the Maddog still be the same?  Most aircraft add-ons need serious changes to work in the 64-bit world.

 I have never seen L:var names change between 32 & 64 bit sims.. XML stays constant between the 2.

33 minutes ago, Pete Dowson said:

I think you mesn "double word"  (DWORD). A "double" is an 8-byte floating point number,. 😉

Ooops.. Yes, that is what I meant. 

I just hope that the new lua will help Simone.
Roman 

[sisoffi]

Hi Roman and Pete,

thank you very much to effort me. Now is more clear what you said to me and appreciate a lot the immense work for me.

the problem now that there is something wrong with the script. the displays don't work are all zero

(I changed the offsets on Mobiflight I checked the file name in fsuipc.ini and everything is perfect) but it doesn't work 😞

even the strings of a few posts ago didn't work. Does it seem to work only with the wording of the old file? it seems strange to me.

The Log show only READ if i active WRITE dont show nothing.

thank you
Simone

FSUIPC5.ini

FSUIPC5.log

[sisoffi]

ok the file MADDOG_X.lua work very well...superfast!

so excited!!!!

Pete, the only thing is not working if i mantain the name MADDOG_X.lua i need to change name MADDOG.lua leaved suffix _X

do you know this issue?

 

thanks,

SImone

[spokes2112]

Simone,

It is because of the [Auto] entry in your FSUIPC5.ini -

[LuaFiles] <-- This is the inventory of all your .lua files in the modules folder, do not change.. It is automatic.
1=MADDOG_X

[Auto] <-- This will auto start the lua (and other) files, as entered below, when the sim starts. In this case it is the wrong name.
1=Lua MADDOG

If you want to go with the original MADDOG_X.lua name then..
With the sim closed rename the lua file to --> MADDOG_X.lua
Open up your FSUIPC.ini file in a text editor and change to the following -->

[Auto]
1=Lua MADDOG_X

Restart the sim.

Glad the lua works for you !! 👍

Roman

[sisoffi]

thank you Roman,

work very fine and im very happy! two questios: in the maddog FGCP  there is an output alphanumeric that change in V S M behind vertical speed

is mapped on the IPC Lvars?

also altitude report = under 10.000 feet ...is not also mapped?

 

many thanks!

super
 

[spokes2112]

Simone,

L:vars do not support characters at all. But..
If your software to hardware interface accepts strings then this version may work for you.
The strings are built up in the lua then written to the offsets.

Ran into big problems, there were some duplicate offsets in the lua causing complete havoc so the main FGCP offsets have been re-assigned.
Also needed some extra room for the strings.
ALT was 0x68F0, shared with Fire Agent 1, now it is at 0x6904 as a STRING with a length of 5.
SPD was 0x68E8, shared with Fire Agent 1 Low, now it is at 0x6909 as a DWORD (unchanged type)
HDG was 0x68EC, shared with Fire Agent 2 Low, now it is at 0x690D as a STRING with a length of 3. Changed to string in order to format as "001, 023, 359" etc..
VS was 0x68F4 (big problems with this one), shared with Fire Agent 2, now it is at 0x6911 as a STRING with a length of 6. 
The next available offset for other things is 0x6913. 

Here is a video showing the string build in action -
https://www.dropbox.com/s/ygu0lj9mnl6tj81/MD80_FGCP_LUA.mp4?dl=0

MADDOG_X.lua

Hope this may do it for you,
Roman