FSUIPC5 - LINDA Interface Changes

[Scotfleiger]

LauKill commands are sent to FSUIPC for the 2 running LINDA LUA processes when the user forces a restart. I am not sure what happens when ipcReady.lua restarts the LINDA LUA processes by calling LINDA.LUA which in turn loads INIT.LUA.

[Scotfleiger]

Hi Pete

I took your comments on using com.close with the handle for the VRI MCP panel (5 as allocated originally). It would appear that if it is closed then the same handle will be reused for the VRI device on restarting. With this the event.vriread(handle) is correctly assigned and working. The various HID com handles still increase as I have not disposed of them.

The above situation will not occur when the ipcReady is called to restart the LUA code without any killLUA calls. Therefore, the handles still need to managed within FSUIPC5. 

FSUIPC5.log

[Pete Dowson]

1 hour ago, Scotfleiger said:

I am not sure what happens when ipcReady.lua restarts the LINDA LUA processes by calling LINDA.LUA which in turn loads INIT.LUA.

FSUIPC automatically kills any threads still running when asked to restart them (i.e. load them again).

I'll upload a 5.101p version with some fixes to test shortly.

Pete

 

[Pete Dowson]

1 minute ago, Scotfleiger said:

It would appear that if it is closed then the same handle will be reused for the VRI device on restarting. With this the event.vriread(handle) is correctly assigned and working.

Yes, as I surmised. I will fix this in any case -- for the same "real" handle the same "local" handle should be assigned.

That will be fix #1.

Fix #2 will be to stop those attempts to provide local handles for real handles with are invalid, like 0.

And Fix #3, which may not be so easy, will be to work out how to free the local handle automatically when the COM device is closed by enforced killing of a thread.

Pete

 

[Scotfleiger]

Good news and thanks for all the effort you are putting in. I'm afraid I must finish for today.

[Pete Dowson]

2 minutes ago, Scotfleiger said:

Good news and thanks for all the effort you are putting in. I'm afraid I must finish for today.

Me too, soon. If I can't do all three "fixes" I mentioned I will continue in the morning. But I would dearly love to get this sorted soon, then, because I feel I need to release a full Install package before I go away for a week.

So many of the support responses Thomas and I have to attend to here are due simply to folks not knowing there are interim releases which already fix their issues.

Pete

 

[Pete Dowson]

Okay. I think I've managed all three fixes. At least I hope so:

FSUIPC5101p_TEST.zip

Please retain this logging for any tests, good or not. i'd like to see the results.

Debug=Please
LogExtras=x2004

Thanks,
Pete

[Scotfleiger]

Morning Pete

The management of the VRI handle is fixed in 5.101p. After multiple restart of the 'original' LUA code the same handle (5) is assigned by the com.open() and used by event.vriread(). LINDA retains full control of the VRI MCP panel.

FSUIPC5.log - original LUA code - same handle used.

When I repeat the test with the 'modified' LUA code which closes the VRI handle before restarting with com.close() (see line [COMM] Closing VRI port Dev=), FSUIPC5 allocates a new handle to the VRI device. LINDA correctly uses the new handle and LINDA retains full control of the VRI MCP panel.

FSUIPC5.log - with VRI com closed before restart

The same behaviour occurs in both cases with the HID device handles. New handles are assigned to each device on restart leading to the long list of handles. This does not affect LINDA operations. My code in both cases does not attend to close the HID com handles. Should I will look further at closing the HID handles on my side?

Thank you for burning the late night candle.

 

[Pete Dowson]

1 hour ago, Scotfleiger said:

Should I will look further at closing the HID handles on my side?

It would be tidier, but there's no need to go right out of your way. I have a limit of 1023 handles in a table shared by COM (com, vri, hid) and windows (ext), for all loaded threads. Provided your setup is unlikely to get anywhere near filling (leaves some for others!) then it should be fine.

Incidentally, I don't suppose this error matters, does it?

*** LUA Error: C:\P3Dv4\modules\linda/system/events.lua:460: attempt to index global 'JH' (a nil value)

It is occurring at every LINDA start.

I'll be releasing the full Install 5.102 this afternoon.

Thanks,
Pete

 

[Scotfleiger]

I am hitting problems trying to close the HID handles. P3Dv4 is locking up. This is probably down to the different way 5.101p now manages the VRI and HID handles.

The 1023 handles limit is only ever a problem for us developers who need to restart regularly to test new LUA code. So it is not a problem.

The LUA error is my coding error and can be ignored.

I am happy for 5.102 to be released.

Edited June 12, 2017 by Scotfleiger
Rewording

[Pete Dowson]

31 minutes ago, Scotfleiger said:

I am hitting problems trying to close the HID handles. P3Dv4 is locking up. This is probably down to the different way 5.101p now manages the VRI and HID handles.

How are you trying to close them? It should be just the usual com.close, the same as you use for your VRi devices.

If could could supply a short plug-in which demnstrates this, please, I'd like not to have it outstanding in a full User Release if possible. I at least have plenty of "Hid" devices, I can patch such a plug in with different VID and PID values.

If it isn't so easy for you I can see if I can adapt one of my Lua examples. I think there's a one which Logs HID stuff.

Pete

[Scotfleiger]

Pete

I have decided not to attempt to close any device (VRI/HID) using com.close. I will leave it FSUIPC5 to manage. It works for LINDA.

I do not have time this week to do any more work as I am far, far behind with my other work. Do not let me stop you formally releasing 1.102.

Andrew