LUA delays response

[dedel]

Hi there,

 

I am using a small event driven LUA script to call my HID USB device whenever a light switch is toggled (using offset 0x0D0C). Then the USB device sets it's outputs accordingly.

However, there is a significant delay between the incident and the response: from immediate up to 1 sec. It seems that the event is polled with a fixed 1 sec interval.

Is there a way to shorten this interval to have a more rapid response?

The ipc.display window behaves similar.

 

Many thanks for a hint,

 

Dedel

[Pete Dowson]

I am using a small event driven LUA script to call my HID USB device whenever a light switch is toggled (using offset 0x0D0C). Then the USB device sets it's outputs accordingly.

However, there is a significant delay between the incident and the response: from immediate up to 1 sec. It seems that the event is polled with a fixed 1 sec interval.

Is there a way to shorten this interval to have a more rapid response?

 

Apart from joystick and button polling (which can be set but defaults to about 50 per second), there's no fixed "polling" unless you programmed it using a timer event, and even that's dependent upon Windows Timer messages. Performance otherwise depends entirely on FS performance, though to prevent slowing down FS's simulation there will be imposed delays between each Lua line of up to one millisecond -- more on occasions if FSX is busy or needs to do more to accomplish the requests being made. All the Lua interpreter does is Yield by using a Sleep of 0 or 1 milliseconds depending on the command just executed -- and, of course, if they involve sending messages to Windows or FS and waiting for a response, the delays will obviously be longer. But most certainly not a second. Even if FS is very busy, and you get the occasional longer delay, the average execution speed will be much much faster.

 

As an example of the sorts of speeds that are achieved, take a look at the Master-Slave lua programs which make one PC running FS slave to another running FS, and with very acceptably smooth results providing one of the PCs (I forget which) is faster than the other.

 

Pete

[dedel]

Thanks a lot, Pete,

 

I can see more clearly now. I think, I can live with that delay as far as lights are concerned. If I switch on the cabin light and my ceiling light floods the room half a second later - I can live with it.

 

Dedel

[Pete Dowson]

I can see more clearly now. I think, I can live with that delay as far as lights are concerned. If I switch on the cabin light and my ceiling light floods the room half a second later - I can live with it.

 

So you can see why it is apparently taking one second -- or half now?  Is it a long complicated plug-in or something?

 

Pete

[dedel]

Very short:

-- "annunciators" test program

Vendor = 0x04D8
Product = 0xFE7A
Device = 0  -- Multiple devices of the same name need increasing Device numbers
--------------------------------------------------------
-- First, we need to get the device
Report = 1  -- I *think* all joystick types use Input Report 0
dev = 0
dev, rd, wrf, wr = com.openhid(Vendor, Product, Device, Report)
if dev == 0 then
   ipc.log("Could not open HID")
   --ipc.exit()
else
   ipc.log("HID opened successfully") 
   ipc.log(dev.." "..rd.." "..wrf.." "..wr)
end
X = ""
function lights(offset, value)
  X = string.char(1, 0x0D, 0x0C, value/256, logic.And(value,0xFF), 0, 0, 0)
  if dev > 0 then
		n = com.write(dev, X, wr)                 
    ipc.display(value)
  end
end
function HIDclose()  
  ipc.display("Landing Light Closed")  
  ipc.log("HID closed")
  com.close(dev)
end

event.offset(0x0D0C, "UD", "lights")
event.key(89, 1, "HIDclose")
event.terminate("HIDclose")

Dedel

[Pete Dowson]

Ah, so you have the time between you operating the switch (an assigned button) and the time offset 0D0C changes, the time from that change till the event is seen in the Lua code, the time to send 'wr' (> = 8 bytes) over a USB line, and the time for that USB device to operate some circuit.

 

So where do you think, in those areas, the biggest delay is arising? Is FS under a great load (what frame rate?). If would probably be at least two frames for the first two parts. The COM call operates by placing the data in an output buffer, and that buffer is then processed by a separate thread which is simply waiting for data to send.

 

In all this there are communications going on between about 4 different threads. so performance of your system, the amount of parallel thread operations (processor type dependent), will all affect the timings.

 

Nevertheless, I cannot imagine it could ever be anywhere near a second. Even half a second seems very unlikely.  But unless you measure each of those intervals separately, we wouldn't know where to look.

 

Pete

[dedel]

Hi Pete,

 

as my script is a proof of concept I did not do complicated things yet. I am sitting with a small plane on the ground, no movement, just the prop is spinning. No AI. static scenery. Frame rates about 25. By the way, I am using Prepar3D.

I am operating the switch with either a mouse click or a FSUIPC assigned key. The graphic's response is quick: the switch on the screen flips and the annunciator light changes almost immediately (~0.1s). But, even omitting the COM channel the LUA display alone reacts slowly (up to 1s).

I proofed it with this minimalistic script:

-- "annunciators" test program

function lights(offset, value)               
    ipc.display(value)
end

event.offset(0x0D0C, "UD", "lights")

My USB device is polled by the interrupt channel every 5ms. I assume, the time from preparing the USB output buffer to actually sending the message is less than that (Windows 7 with an i5 processor @ 2.3GHz). So the delay seems to be within the action --> offset --> LUA chain.

 

Detlef

[Pete Dowson]

Hi Pete,

 

as my script is a proof of concept I did not do complicated things yet. I am sitting with a small plane on the ground, no movement, just the prop is spinning. No AI. static scenery. Frame rates about 25. By the way, I am using Prepar3D.

I am operating the switch with either a mouse click or a FSUIPC assigned key. The graphic's response is quick: the switch on the screen flips and the annunciator light changes almost immediately (~0.1s). But, even omitting the COM channel the LUA display alone reacts slowly (up to 1s).

I proofed it with this minimalistic script:

-- "annunciators" test program

function lights(offset, value)               
    ipc.display(value)
end

event.offset(0x0D0C, "UD", "lights")

 

Don't use ipc.display for fast actions. It's intended for more permanent and updated displays. The process in creating and updating a display is complex and will take time. If you want to measure times use logging -- monitor 0D0C as a U16 in FSUIPC (right-hand-side), "to normal log", then add an ipc.log line to your Lua in place of the display line.

 

Pete