FSUIPC Lua program stops running randomly

[AlMassimo]

Hi all

I'm a long-term Pete Dowson admirer and user of his wonderful program,

I know is needless to say after all this time, but FSUIPC and the integration with LUA

is simply extraordinary.

I am building a home cockpit and I chose the Pokeys board for my MIP (ethernet), throttles (USB)

and recently also overhead (ethernet version).

With LUA and IPC controls and pokeys.dll I managed to have a great deal of systems working with default B737/800

so I'm very happy with that, and this site helped me a lot to find examples and solutions for almos every problem.

Also Pete's documentation was so good and clear, even though I had to overload my poor brain to get started

at the beginning.

Now I decided to post a message because I cannot really solve this issue by myself.

My code, launched by ipcready as documented, works perfectly, no errors, all running smoothly.

Randomly though, I realize that the code has stopped working because there is no reaction to variables change

or switches changes etc.

I see the log file and there is no message of any kind regarding errors or other issues.

Is there a way to understand what problem is causing the code to stop, or to trace the errors in a deeper log?

It happens both with the MIP code and with the OVERHEAD code (based on ethernet pokeys) but never with

the throttles (USB pokeys) but the net is stable, I changed switches, cables, etc, but all other net devices

seem to work.

Can someone (hopefully Pete!) help me ?

 

Best regards

 

Massimo

 

 

 

[Pete Dowson]

My code, launched by ipcready as documented, works perfectly, no errors, all running smoothly.

Randomly though, I realize that the code has stopped working because there is no reaction to variables change

or switches changes etc.

I see the log file and there is no message of any kind regarding errors or other issues.

Is there a way to understand what problem is causing the code to stop, or to trace the errors in a deeper log?

 

Why do you think the code has 'stopped' rather than the connection to the hardware device(s)?

 

If you restart the Lua plug in, does it work again? You can assign a key press or button ot start it -- the existing one will be terminated and the plug-in loaded and started again).

 

You can use the Lua trace/debug checkbox on the Logging page to get a line-by-line and variable-by-variable log of what the plug-in is doing.

 

It happens both with the MIP code and with the OVERHEAD code (based on ethernet pokeys) but never with

the throttles (USB pokeys) but the net is stable, I changed switches, cables, etc, but all other net devices

seem to work

 

So your code is reading stuff over a Network connection? Or is there a separate driver doing the Network bit?

 

Pete

[AlMassimo]

Hi Pete,

I'm so happy to read your replay! Thank you very much.

 

Yes I considered the possibility that the net could have lost the connection to the pokeys for some time,

and so the code was no longer communicating with the device.

In order to find out if the code is still working I can write some ipc.display commands reporting fsx

status changes (maybe gear down or flaps out etc).

If I see the message it is clear that the code is running but it lost the connection.

I will test this immediately, if you agree that it is a valid test.

I already set a key (the "O" key for overhead) and pressing it it run the overhead.lua

and everything start working again.

This solves the problem, but is not very good to lower the landing gear and discover that

nothing happens, then press the "O" key and so on...

Here is the initial part of the code (please let me know if you want me to encolose all the code)

 

require "luacom"
poKeys = luacom.CreateObject("poKeysDevice_DLL.poKeysDevice")

if poKeys == nil then
  ipc.log("Error: poKeysDevice_DLL object creation failed.")
  ipc.display("NO POKEYS - QUIT PROGRAM")
  ipc.exit()
end

   -- LEDS (digital outputs)

   fuel_p1_FWD_lowpress = false -- pin 1
   fuel_p2_AFT_lowpress = false -- pin 2

  .........

   -- SWITCHES (digital inputs)

   yaw_damper_ON = false      -- pin 33            
   starter1 = 0
   starter2 = 0
   master_battery = false  -- pin 42

   power_ON = false

 

   ........
  
function connect_to_poKeys()
   result = poKeys:ConnectToNetworkDevice("192.168.0.12")
   if (result == false) then
       ipc.log("Error: Connection to poKeys56E at 192.168.0.12 failed.")
       ipc.exit()
   end
end
 

  .......

 

This is how it is documented for pokeys device and it works, until it stops!

I will test the ipc.display trick, I should be able to see if the code is still

reading the fsx vars but not the pokeys status.

This probably would move the problem onto the pokeys.dll plugin.

I will report the test results as soon as I complete the test!

Thanks again

 

Massimo

 

 

 

 

 

 

 

[Pete Dowson]

This probably would move the problem onto the pokeys.dll plugin.

 

Yes. Once your code enters third party options, in this case the DLL you are connecting to via luacom, I'm afraid it's outside my knowledge and capabilities to help. Maybe the provider of that DLL can help you diagnose whatever is going wrong with the connection?

 

Pete

[AlMassimo]

I must apologize for the title I chose for my topic...

yes you were right, it is not the lua code that stops working, but the connection with the pokeys,

in fact the ipc.display("AP ON") came out when I pressed the Z key after I lost the control of the panel.

So the lua was running but it could not read or write the pokeys pin status.

I considered that pressing the "O" key the code (now I know was a new instance of the code)

started and the connection was still alive but probably that happened because the command

 poKeys:ConnectToNetworkDevice("192.168.0.12")

was sent once again and that restarted the device connection.

 

I will study a way to check periodically the connection, and send an ipc.display warning when

it is lost, or try to reconnect it.

I don't think is a network issue, probably could be a sort of stack overflow, maybe a queue that

is filled with data, perhaps because I send more status change commands than needed

(I should send only one when the status change, but I don't do this at moment, I simply

read the fsx var with

 

   event.timer(50,"update_switches")

 

and if the fsx variable o switch is 1 I send a 1 state to the corresponding pin,

and this could not be the right thing to do.

At least now I have a new target for my debugging....

Thanks Pete for your support.