[Lua Socket 64 FSUIPC 5]

12 minutes ago, Bleedin said:

I got it working.

I like to hear that.  I don't know why these files are so hard to find,  so I hope we can keep them here when someone else inevitably runs into the same problem.

Dustin

[Lua Socket 64 FSUIPC 5]

Although I no longer use LUA to interface with my cockpit modules, I still have it set up from when I did and it works.  The only confusion I have is that I have a core.dll *size 102,912) in the Modules root and I have one in the Modules\lua\socket folder and they appear to be the same. 

Make sure you have this at the top of the lua file.

local socket = require("socket")

Also, I noticed that you have to have a socket.lua and a socket_core.dll that may actually be the 64 bit DLL(?).  These go in the Modules root.

 

socket_core.dll

socket.lua

[Lua Socket 64 FSUIPC 5]

I think this is it.  Let me know if it works.

 

Dustin

core.dll

[Lua Socket 64 FSUIPC 5]

On 11/20/2017 at 10:45 AM, dru5412 said:

Well all i can say is for me, i downloaded the lua and core.dll as described and seemed to work without needing any other change.. 

When I say worked ( i can open socket and communicate over it) but have the other issue with event.offset, but hopefully totally unrelated.

I was finally get some real time to test this out and I am happy to report that after a few initial tests,  sockets is now working! 

 

On 11/15/2017 at 12:21 PM, Pete Dowson said:

You an get lua sockets under Fsuipc5.12b by loading the 32 bit luasocket library from
  http://files.luaforge.net/releases/luasocket/luasocket/luasocket-2.0.2/luasocket-2.0.2-lua-5.1.2-Win32-vc8.zip

unpacking it into "modules/Lua" and then replacing "socket/core.dll" with the one from  https://download.zerobrane.com/luasocket-win64.zip.

It's the first step that, the best I can recall, that I didn't do before.  I think I was only overwriting the core.dll in the second step.  So many thanks for getting this to work!

-Dustin

[Lua Socket 64 FSUIPC 5]

2 hours ago, Pete Dowson said:

So, then, what would the "require" declarations need to be in your Lua code as I'd like to document this in the installed Lua PD). You'd need to provide for the missing 64-bit socket.core, mime.core DLLs which were buillt into 32-bit FSUIPC, and presumably also the ltn12.lua, socket.lua and mime.lua which I also included?

I tried what Luis suggests early on into this thread.  The require statement was the problem I ran into because Lua kept balking at everything I tried ( I cannot recall right now as to the exact error, I can try again if it will help).  

Luis, if you figured this out, I will be very happy!  Intently awaiting your reply.

-Dustin

[Lua Socket 64 FSUIPC 5]

3 hours ago, brian60 said:

First I created two virtual serial ports with this free app com0com - https://sourceforge.net/p/com0com/news/2012/06/com0com-v3000-released/

it creates two virtual serial ports and links them together. One port is connected to a LUA script with com read and write and the other is connected to this

free app CommTunnel - http://www.serialporttool.com/CommTunnel.htm. this app even has a window so you can see whats being sent and received.

I use esp8266 12f wifi chips with mcp23017 gpio expanders(I2C version)  with adafruit library(for mcp23017) and arduino IDE for programming. (ordered in bulk from china they are very

cheap and you can chain 8 via I2C for 128 gpio ports on one esp12f). The 8266 is more powerful and has more memory and costs alot less than an arduino and has WIFI. you can get the

nodemcu devkit that has a serial interface on board but i am trying to cut out as many wires as possible.

 

Interesting work around.  The main reason I change to using lua sockets in the first place was due to the fact that I was losing a lot of data using the USB serial ports with the com lib and connecting to my panels which are Arduino Megas.  I suspect there are multiple reasons for this,  but have you experienced any data loss and/or corruption with this method?

Dustin

[Lua Socket 64 FSUIPC 5]

That's correct.  It does not currently work from FSUIPC 5.  It will work with some slight modifications within WideFS since it is 32 bit.  Pete was unable to get sockets to compile correctly as 64 bit last I heard.

Dustin

[FSUIPC + PMDG or others = How to Set???]

In addition to what Luke said, don't forget to activate the SDK broadcast in the 737NGX_Options.ini, per the instructions in the Offset Mapping for PMDG737NGX.pdf file in the FSUIPC Documents folder.  I use P3Dv4 and every time I install a hot fix, etc. it rewrites the .ini file and I have to change it back.  I map a button on the yoke to 70636 which is the A/P DISC on the sim yoke.  I believe you should also set the parameter to 1.

Good luck,

Dustin

[Lua Socket 64 FSUIPC 5]

4 hours ago, Pete Dowson said:

To make sure it isn't to do with FSUIPC or WideFS, could you add an event.offset for something which is known to change redularly, and log that so you can see it still running? For example, the time of dat "second" value, one byte at 023A. If that is okay it is down to the PMDG aircraft I think.

This offset works as it should.  I discovered that during the last update from PMDG, the SDK was reinstalled and overwrote the .ini and the SDK was disabled.  I corrected that and all offsets are triggering with desired results.  I think we can put this to bed.

4 hours ago, Pete Dowson said:

But there appear to be too many things missing which I couldn't find anywhere in the source provided. I assume it must be possible. i tried to work out what the missing bits should look like, but that's where I got lost in the very complex convoluted and uncommented code.

I see.  That can't be easy to decipher.  I don't know if the author, Diego can help from his gitHub.  I don't want to force the issue down your throat more than I have. 

Thanks for giving this issue so much attention.  I probably would have given up on it long ago without your help.

Regards,

Dustin

[Lua Socket 64 FSUIPC 5]

I have made some progress with the UDP issues and WideClient.  First, without a doubt, the lua file of this size must be run as "initial.lua" and WC started before P3D in order to allocate enough memory (you mentioned this before, but I think it's absolutely required).  Secondly, changing the event.timer that checks the UDP connection for received data to somewhere around 50msec AND adjusting my udp socket.bind timeout to something other than zero (2) appears to have fixed the connection refused problems.  Best I can tell, with some limited testing, the UDP connections are working as they should, and quite well.  No more LUA out of memory errors!

A problem I am running into now is that all of my event.offsets are getting sent one time, at startup, as they should.  However, after that, no further state changes are reported by WideClient as well as the STR type offsets are reported as nil by WC.  I confirmed that "initial.lua" is still running.  This may well be a PMDG issue.  They have just released an update to the NGX on Tuesday, so I'm getting that now.  Will test this out tomorrow hopefully.

Thanks again,

Dustin

 

[Lua Socket 64 FSUIPC 5]

EDIT:  Pete, please see my next message first!

 

Hello again,

11 hours ago, Pete Dowson said:

event.timer is okay. i use it quite a lot in plug-ins.

I misread the WideFS user guide where it mentioned this thinking it was an exception in the com library.  Anyway, I tried varying the duration of the timer same with ipc.sleep as mentioned (see below) and it still goes through a few messages passed back and forth and ends up with the same out of memory errors.

11 hours ago, Pete Dowson said:

There's something else awry in your code. There's no way changing from one type of "loop" (by time) to another should do that. Unless your loop doesn't inlide an ipc.sleep so that you don't hog the processor. Try ipc.sleep(2) if you want to do it at the same speed as the timer, though i think you'd find the timer method only gives you 2 msecs approximately. You might need to allow more for a contained loop.

I agree.  It should not make a difference.  However, I tried using ipc.sleep(2) within a loop that then calls my function to receive the UDP and I get the same connection refused every iteration.    I also tried varying the duration up from a few msec, to 50 msec, 100, etc. up to 2 full seconds...same result.  I will continue to try and track this down using event.timer.

11 hours ago, Pete Dowson said:

Or if you can find 64-bit compiled versions of these which are Lua 5.1.x compatible.

Did you see my previous post regarding what is "supposed" to be just that (copied below)?

On 7/16/2017 at 8:01 PM, budman9mm said:

I did come across some files linked from github that are supposed to be compiled 64 bit luasocket, but unfortunately I have no idea what to do with them yet.  Maybe they can help you, maybe not.  https://download.zerobrane.com/luasocket-win64.zip

I'm just asking because I was excited to see this, yet I have no idea what to make of whether it is applicable or not.  I would be certainly willing to investigate incorporating it if you think it is worthwhile.

11 hours ago, Pete Dowson said:

By "go back", do you mean to P3Dv3?

Affirmative.  I haven't given up yet though.  I just haven't had time yet, but I am going to try and rebuild the code step by step.

And thanks for the list.  I have a printed "FSUIPC Lia Library Reference" that I have referenced at least a hundred times and it just did not register that it specifically says "[Not WideClient]". I don't know why I'm forgetting these details...*sigh* I regret wasting my efforts as well as yours.

Thanks,

Dustin

[Lua Socket 64 FSUIPC 5]

Pete,

I'm sorry for missing this, but I was unaware until you said as much that some of the plug-in commands weren't available - I later see it in the User Guide.  I was able to find a case of event.timer being used being used to check my UDP connection for receive data every 2msec.  So I tried tried removing that and instead using a loop to execute my "receiveUDP()" function.  It now does not give any Lua out of memory error, but it results in a UDP connection refused.  With "event.timer" it was making connection with my Arduino nicely, but after a number of commands sent back and forth, it would start the memory issues.

I may keep trying to chase this down for a bit.  Maybe you have some idea as well.  However, I'm just wondering if you think the sockets issue will ever be able to be compiled into FSUIPC5?  I may just go back to working in the previous versions of software until that time.

Thanks

D

[Lua Socket 64 FSUIPC 5]

2 hours ago, Pete Dowson said:

Are you using Lua display facilities?

Yes.  Mostly for troubleshooting so I can see values of variables. I have now commented out all of the ipc.lineDisplay and ipc.display commands.

3 hours ago, Pete Dowson said:

Where's the log please? Any crash details from Windows?

I really need such information. Just saying "crashes" is really no help.

There was nothing in the log when I sent that except the windows event viewer.  However, I tried a few more times and WideClient did terminate with a message to check the log.  I attached it to this message along with the windows event viewer details.  These are from after removing the ipc.display cmds.

2 hours ago, Pete Dowson said:

Could you try with that testsrvr.lua instead, just to prove that it isn't related to the Networking side of things, which is what we were trying to deal with.

I did as you asked with tstsrver and tstclient and it ran without error and seems to be connecting just fine.  I've attached the log for that anyway as well.

I've started adding points in my code to log.  It does seem that the memory errors start once I start receiving event offset triggers...somewhere.  It's going to take some doing to find out just where.

Thanks,

D

WideClient.log

windows_event_view.txt

testclnt.log

[Lua Socket 64 FSUIPC 5]

6 hours ago, Pete Dowson said:

What, WideClient? Space for execution of Lua threads and other things is allocated dynamically, not part of the EXE file. And as far as it is concerned, P3D3 is the same as P3D4 (and FSX, FS9, even FS98!)..

Thank you for explaining how the memory is allocated.  To clarify, I ran the script as normal, not using WideClient ,but just FSUIPC4, it ran fine.  So, I tried using WideClient in P3Dv3 and the script runs, although an error occurs in the FSUIPC console...

 ***ERROR C0000005 at 1AF27076 ExWriteStateData(Offset=9BFC, Size=4)
 ***      Access violation trying to read address 000064C8
 ***      EAX 00000026  EBX 00000001  ECX 00000000  EDX 00000000  EDI 1

I have no offsets to 0x64C8.  Even so, and without tracing down what is causing this, it is not a fatal error and the script continues to run.  I'm not sure if it is relevant to the problem or not.

Going back to P3Dv4...I attempted to run WideClient before running P3D and it (WideClient) crashes.  I then execute WideClient again and it throws the out of memory error.

I will try and do as you suggested about tracing it down with ipc.log statements next, but time is short right now as I expect you can understand.

 

Dustin

[Lua Socket 64 FSUIPC 5]

I was able to get WideFS registered and configured to allow connections on the same PC.  I have my lua script in the separate wideclient folder I created.  Unfortunately it is giving me "6989 *** LUA Error: not enough memory" and just repeats trying with the same.  I verified that it does execute properly in P3Dv3 still.  It's roughly a 45kb file and growing.  I guess since it's not running within the P3D thread that there is significantly less memory allocated?  Any thoughts?  This whole 64 bit thing we all wished for is starting to look fraught with caveats.

Thanks,

Dustin

[Lua Socket 64 FSUIPC 5]

13 hours ago, Pete Dowson said:

There is a work-around. Install WideClient on the same PC asFSUIPC5.

I will give it a go.  I haven't used WideClient much yet so I am skimming over the documentation.  Does this need to be a registered version?

Dustin

EDIT:  Please disregard.  I see that WIDEFS7 is still the same version from FSUIPC4 and that registration is valid.

[Lua Socket 64 FSUIPC 5]

I'm just glad you are aware of it.  It's certainly not urgent for me.  In all of my many searches, I did come across some files linked from github that are supposed to be compiled 64 bit luasocket, but unfortunately I have no idea what to do with them yet.  Maybe they can help you, maybe not.  https://download.zerobrane.com/luasocket-win64.zip

I'll keep trying some work arounds and update if I get anywhere.

Thanks for all your help,

Dustin

[Lua Socket 64 FSUIPC 5]

I didn't even realize there are some network examples in there, so I tried running "testsrvr.lua"" which utilizes socket (socket = require("socket");) and it gives me the same exact error.  I have removed any traces to my own lua installation with no luck.  I think I'm at the point where I am going to try install P3Dv4 on another PC and see what transpires. 

1 hour ago, Pete Dowson said:

I'll have to revise all that stuff myself as know little about it and have forgotten whay i did know!

I certainly do NOT envy you having to do this!  I tend to get things in a working order and quickly forget how I did so.

Dustin

 

[Lua Socket 64 FSUIPC 5]

1 hour ago, Pete Dowson said:

Is this your own compiled LUA code?

Thanks, Pete.  I haven't compiled any of my own code for the sim (I have never tried).  I just have the script (PMDGOH_1.LUA) in the modules folder.  I think you can tell my ignorance on the topic.  I just wrote enough LUA code (see below) from your included Lua Library Reference(aside from the UDP portion)  to do what I needed.  What I do have compiled is the LUA 32 bit 5.1 and lua sockets in a completely different folder.  If I understand correctly, there is a lua sockets already provided with FSUIPC, so it really should work as is.  I was wondering that since I have PATH variables that point to my own compiled LUA directory, is it possible that it's using that instead of the FSUIPC LUA facilities? So I tried removing all the LUA environment variables and seeing no change.

(Snippet)

--Overhead Panel #1
local socket = require("socket")
local lan = 1 --1 UDP enabled, 0 COM Port enabled 
local address, port = "*", 47019 --send port
local remoteip, remoteport = "192.168.1.142", 47018 --Arduino #1
local remoteip_2, remoteport_2 = "192.168.1.148", 47018 --Arduino #3
host = "192.168.1.5" or "*"
----
--ipc.display("PMDG Overhead/Aft Overhead")

if lan == 0 then
	dev_1 = com.open("COM23", 115200, 0) --Don't go faster than 115200
	dev_2 = com.open("COM7", 115200, 0) --Mega #3 Aft Overhead
--I don't use the COM ports because I tend to get bunches of buffer errors
elseif lan == 1 then 
	server = assert(socket.bind(host, port))
	server:settimeout(0)
	udp = socket.udp()
	udp:settimeout(0)
	udp:setsockname(host, port)
	
	server:setpeername(remoteip, remoteport)
	ipc.lineDisplay("UDP peer #1 opened", 10)
	server:settimeout(5) --Remove blocking
	udp:settimeout(5)
	
	server:setpeername(remoteip_2, remoteport_2) 
	ipc.lineDisplay("UDP peer #2 opened", 10)
	
end

Thanks,

 

Dustin

[Lua Socket 64 FSUIPC 5]

I am running FSUIPC 5 1.03g, registered.  I am trying to run a LUA script (via Key Presses section) that I used with P3Dv3 that controls my PMDG 737NGX home made overhead panels, etc. in P3Dv4.  I exclusively use UDP to communicate between Arduinos and FSUIPC which uses Lua Sockets.  I now get the LUA error:

Quote

 *** LUA Error: error loading module 'socket' from file 'socket':   socket: bad header in precompiled chunk

I am assuming this is because I have not compiled a 64 bit version of LUA.  I installed the 32 bit version a long time ago and I muddled my way through it with Luarocks version 5.1.x, I believe.  My question is, am I on the right path in believing that I need to figure out how to compile it again with 64 bit?  I am not very strong on these sorts of things and I can't find any clear cut ways to do it on my Win7-64 box.  The searches I am coming up with are all over the map on ways to do it.  Has anyone done this yet that could advise on what I need to do or point me to a URL that explains the best way?

Thanks in advance,

Dustin