Dararef subscribe control.

[Keith Baxter]

Hi,

I posted this in another thread so I thought I would highlight here.

I am having issues when dataref subscribe is sending many sends from the sim to the AM.

The instrument stops working after time and .....
AM go's into "Not responding" mode. One cannot even shut down the instrument. I have to shut down/pause the sim, then wait for AM to catch up with the processing. This is worse when print statements for a many package receive dataref in testing are applied.

The current way is fine for small instruments. In larger instruments it is leading to data sends to the sim and reads from the sim being delayed or missed.

As I stated in the other thread. It would be nice if we could have an option to filter the subscribe before millions of subscribes hit the callback function.

So the proposal is to have a filter at subscribe level.

"nil" will indicate default
"val" would indicate a value change filter
"time" would indicate a time filter
"pack" would indicate a package size filter

If the Data read is per frame rate then ....

"frame" would indicate the read after x frames.


Whilst my reasonably powered PC can handle some of this the RPI falls over long before it even tries.

@Corjan I would like to hear your comment on this one please and if control is possible.

Keith

[Keith Baxter]

Hi,

Ok so I did a bit more digging to ascertain what the bottle neck is. It would seem that moving and rotating nodes are the issue. Setting text seems to be OK

You can run this code on an aircraft, default "Columbia 400" in xplane is a good example.

Here the data read and dataref change "count" is interesting to observe.

Note the change in the print statement output format in the console.

It looks like there is no "time" involved in the dataref read. I would seem it is "data package size" or some other filter.

The commented out dataref subscribe is what I Request.

Code: Select all

robR_40vlgC="font:roboto_regular.ttf; size:40px; color: red; halign:left; valign:center;"



count_text=txt_add("",robR_40vlgC,20,10,500,30)
egt_text=txt_add("",robR_40vlgC,40,50,300,30)
cht_text=txt_add("",robR_40vlgC,40,90,300,30)
itt_text=txt_add("",robR_40vlgC,40,130,300,30)
oil_text=txt_add("",robR_40vlgC,40,170,300,30)
mix_text=txt_add("",robR_40vlgC,40,210,300,30)

count=0
function temp_indicators(egt,cht,itt,otemp,fmix)
	count=count+0.0000000001
		txt_set(count_text,string.format("%.10f",count))
		txt_set(egt_text,"EGT       "..string.format("%.6f",egt[1]))
		txt_set(cht_text,"CHT       "..string.format("%.6f",cht[1]))
		txt_set(itt_text,"ITT       "..string.format("%.6f",itt[1]))	
		txt_set(oil_text,"OIL TEMP  "..string.format("%.2f",otemp[1]))
		txt_set(mix_text,"MIXTURE   "..string.format("%.4f",fmix[1]))
		print(count)
end		

xpl_dataref_subscribe("sim/cockpit2/engine/indicators/EGT_deg_C","FLOAT[8]",
						"sim/cockpit2/engine/indicators/CHT_deg_C","FLOAT[8]",
						"sim/flightmodel/engine/ENGN_ITT_c","FLOAT[8]",
						"sim/cockpit2/engine/indicators/oil_temperature_deg_C","FLOAT[8]",
						"sim/cockpit2/engine/actuators/mixture_ratio","FLOAT[8]",temp_indicators)
						
--[[						
xpl_dataref_subscribe("sim/cockpit2/engine/indicators/EGT_deg_C","FLOAT[8]","VALUE;10"
						"sim/cockpit2/engine/indicators/CHT_deg_C","FLOAT[8]","VALUE;10"
						"sim/flightmodel/engine/ENGN_ITT_c","FLOAT[8]","VALUE;10."
						"sim/cockpit2/engine/indicators/oil_temperature_deg_C","FLOAT[8]","VALUE;5",
						"sim/cockpit2/engine/actuators/mixture_ratio","FLOAT[8]","VALUE;0.01,"temp_indicator)
]]						

Keith

EDIT:
I am thinking that we should not allow dataref buss subscribe for this reason or have more control.

[Corjan]

Hi,


Limiting the incoming data is a not a solution, it is a hacky way to make the problem less obvious.

I would rather get to the source of the problem, and find out why it is slow.


Do you maybe have a piece of code that is slow on your PC?

Corjan

[Keith Baxter]

Hi,


Limiting the incoming data is a not a solution, it is a hacky way to make the problem less obvious.

I would rather get to the source of the problem, and find out why it is slow.


Do you maybe have a piece of code that is slow on your PC?

Corjan

Hi Corjan,
Thank you for the response.
Unfortunately I stripped out the instrument which had a 19 dataref bus. I made a few smaller bus's. That seems to have helped as the instrument has not hung up since.
I have not tried it on a RPi yet

I will try and reproduce and send you code.

Keith

[Corjan]

Hi,

Having multiple smaller subscribes can indeed help.

Corjan