budman9mm
-
Posts
20 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Downloads
Everything posted by budman9mm
-
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
-
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
-
I think this is it. Let me know if it works. Dustin core.dll
-
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! 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
-
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
-
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
-
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 FSUIPC + PMDG or others = How to Set???
budman9mm replied to Diogo Alencar's topic in FSUIPC Support Pete Dowson Modules
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 -
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. 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
-
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
-
EDIT: Pete, please see my next message first! Hello again, 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. 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. Did you see my previous post regarding what is "supposed" to be just that (copied below)? 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. 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
-
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
-
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. 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. 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
-
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
-
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
-
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.
-
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
-
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. 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
-
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
-
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: 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