Is it possible to write to offset without triggering it's event?

[dwilliams]

As a rotary encoder on my hardware panel turns I'm sending NAV1 OBS Setting updates to the sim. But if I also am watching for change events on that offset (to update the value stored by the panel, or possibly to accommodate an active flight plan changing the value) I get into a sync problem where the event handler function can't keep up with the incoming encoder updates.

 

Is it possible to do an ipc.write to an offset without that offset immediately triggering it's own change event? Or alternatively in Lua, dynamically enable and disable events?

 

Regards,

Dave

Long Beach

[aua668]

Hi,

 

Please provide the LUA code for your question. With that it's easier to answer. Typically if you have such a problem, you did something wrong in the design of your program. Because typically you have some events (button or key presses) changing some offsets and you react on changes in offsets to display things (e.g. on some hardware device). I made many such modules for GoFlight hardware without ever having the problem you described. So if you provide the code we could check.

 

Rgds

Reinhard

[Pete Dowson]

As a rotary encoder on my hardware panel turns I'm sending NAV1 OBS Setting updates to the sim. But if I also am watching for change events on that offset (to update the value stored by the panel, or possibly to accommodate an active flight plan changing the value) I get into a sync problem where the event handler function can't keep up with the incoming encoder updates.

The events are not accumulated. If the previous event is still being processed in the plug-in when the next change occurs, it is simply flagged and sent when the plugin exits. If there were multiple such events they are made into the one.

So, I think you may be misinterpreting some results? Maybe you have multiple events being processed in the same plug-in, and a more frequent one is preventing others from signalling? If so, that would be fixed in the most recent FSUIPC version.

On your last question, yes of course your plugin can delete and re-establish events, but be warned: if you delete the last outstanding event, then on exit your plugin closes

Pete

[dwilliams]

Thanks Reinhard and Pete - see Lua below.  My test hardware is simply a debounced rotary encoder with an Arduino keeping track of the current OBS position locally, adding  or subtracting clicks from the encoder, and sending updates to the script. In turn, the script passes the new value to the sim via ipc.write. As the new value is ingested by the sim, the corresponding event triggers and the script sends the updated value (which should be the same as just received by the Arduino) back to the Arduino via a com.write .

 

Problem is, it seems when the script receives several quick updates in a row and make several quick ipc writes, it can receive an event for an earlier update - which is promptly sent back to the Arduino, which now thinks this value is current so resets what it is sending. e.g., as one spins the the OBS, the display (I am just watching the OBS needle on the default G1000 PDF) might read  55, 56, 57, 58, 59, 56, 57, ...   note the skip back to 56 as the event corresponding to 56 is triggered.

 

I am sure this is just a basic concept I need to get straight since I know it has been solved.  -Dave

 

dev = com.open("COM4", 115200, 0)
if dev == 0 then
    ipc.display("Could not open port")
    ipc.exit()
end
---------------------------------------------
function handlecom(handle, str)
    if string.match(str, "Control:(%d)") then
        ipc.control(tonumber(string.match(str, "(%d)")))
    end

    if string.match(str, "CRS:(%d)") then
        val = tonumber(string.match(str, "(%d+)"))
        ipc.writeUW(0x0c4e, val)      -- NAV1 OBS Setting (degrees, 0-359
    end
end
----------------------------------------------
function CRS (offset, value)
    com.write(dev, "CRS:" .. value .. ":\n")
end
----------------------------------------------
ipc.sleep(500)
event.com(dev, 20, 5, 0, "handlecom")
event.offset(0x0c4e, "UW", "CRS")  -- NAV1 OBS Setting (degrees, 0-359)

[Pete Dowson]

I've implemented many things like this. The problem is latency in the FS/Disconnect/FSUIPC loop. The solution which always worked for me is to update your display at the same time as sending the values to FS. Only update the display from a value received from FS when the last change from the user is more than X mSecs ago -- just experiment with X to find the best value, probably 100-500.

Pete

[dwilliams]

Thanks, Pete. In replicating a Garmin flight controller, my panel just has rotaries and push buttons - the display is the PFD, but I get what you are saying. I'll keep my local variables in sync with what I send and ignore returns from FS/Lua until the micro sees a break in twisting knobs.

 

What have you found to be the practical limit on sending to Lua, assuming it has to do string matches before it ipc writes? I think I have seen cases (viewing ipc.log on console) where if I send updates from the micro too fast, Lua seems to lose some characters? Or maybe that is due to logging delay?

 

In any case you have given me enough to experiment with. Thanks again - Dave

[Pete Dowson]

What have you found to be the practical limit on sending to Lua, assuming it has to do string matches before it ipc writes? I think I have seen cases (viewing ipc.log on console) where if I send updates from the micro too fast, Lua seems to lose some characters? Or maybe that is due to logging delay?

Sorry, sending "to Lua" how, from where? If it's using the com library, reading from a device, then there will be a buffer. You wouldn't lose anything, just maybe run behind (latency). The logging would slow it a bit, but the actual file output for that is in a different thread. If each input involves interaction with FS then that could take longer in the plug-ins thread, depending on what it is doing.

Pete