Understaning LUA and interfacing???

[pitbldr]

As I am approaching the stage in my project where I'll need to start interfacing some controls with the sim, I am trying to learn/understand how it all works.

 

I am not a programmer so that is part of the struggle. And I know I can use some of the solutions available for interfacing with the sim, but I am the type of person who likes to know how and why something works.

 

So can anyone break this down and give me a high level overview of how it all works?

 

1. What's the flow of information? Does DCS:WH spit it out into a LUA file and is that then readable by other software that is (could be) interfaced with hardware? I assume this data can travel over USB, serial, or TCP??

 

2. What file(s) are controlling all this information exchange? I know about export.lua, but I don't understand its relationship or role exactly.

 

3. If I have a hardware interface that can be used to illuminate LED's, how is that done exactly? I assume something needs to be configured in a LUA file, but what?

 

I've read through all the links I could find on LUA and I think I am a little more confused than when I started as it seems that most of what I found was referring to DCS:BS and there have been changes made in the code for DCS:WH that don't match up.

 

I appreciate anyone's time in helping me understand this. :)

[LtFransky]

I'd like to know as well.

[metalnwood]

I would go to lua.org and start reading the documentation and some examples as you are going to need to get familiar.

 

You need to make the right changes to the export script to send and receive any information you want. Every example I have seen sends/receives using TCP. You wont be able to talk to serial/usb devices directly from a10/lua, at least not without a lot more development experience with lua and other languages.

 

 

Most people set up their own input/output loops by selecting and exporting the data they want and reading input from external sources via TCP.

 

The export.lua give you the opportunity to read information from a10 every frame that is rendered and do something with it - i.e. send it somewhere. At the same time you are able to read external information. I.e. get an external event for a flipped switch and match it in game.

 

Your LED hardware interface will not talk with lua directly. You will probably have to write a utility in a different language to control the leds. This other program will get its state information from the lua export. If you tell us the hardware you are using it's possible to give you more help there.

 

Sorry, this is the condensed version as I am about to run the kids to school.

[Thermal]

Thats a pretty good first pass explanation.

[GlennW]

I have also recently started my Simpit build so I'm new to all of this and trying to figure it out.

Am I correct in thinking that software such as Helios takes the complexity of scripting and so on away? Can you interface all switches and LEDS Ins/Outs through Helios?

[metalnwood]

Right now helios supports software switches on other monitors that you can flick with a mouse or touchscreens.

 

Even if you dont have a mouse its easier to get to switches this way than using the 3d cockpit.

 

I know that helios has plans to integrate with hardware boards so that you can attach real switches to the computer and helios will take care of the a10 interfacing.

[Gadroc]

Helios supports any hardware interface that exposes itself as directs controller today. It will expand to support more as time goes on. I have a PHCC setup and need to order a open cockpits card.

[Deadman]

Ok here is a question for Helios . What information is not exported by it or can you get access to all working switches and gauges in the cockpit?

[Gadroc]

Every switch and indicator available in DCS is exported in Helios. Some items are not available like data for RWR or UHF displays.

[Deadman]

Thanks :thumbup:

[Alex_rcpilot]

Adding one piece of info:

 

In case someone started geting the sensation that the file export.lua itself is doing the communication, actually the DCS executable does. It reads whatever you've saved in the file and other files of its kind, then decides what to do accordingly.

 

DCS executable implements a socket interface which may be addressed by its IP and port number. It's seen either by another PC on a network or another software on the same PC running DCS, depending on the IP you've specified in those lua files.

 

There are numerous socket communication monitoring utilities that show you what the data looks like. Here's a screeny of data strings for a few simple instruments (the selected text).

It requires some programming skills to translate that string into useful information. This is normally done by writing a custom software. And if this software has access to hardware, it can then redirect the data to any hardware it can reach.

[pitbldr]

Thanks Alex!

 

So the DCS executable is "polling" certain files for commands that it needs to execute? For instance, I press a button that is interfaced to the sim and software writes a command to a file where it's then read by DCS? Is that accurate??

 

In any case, your explanation shed a little more light on the process for me! :thumbup:

[TigersharkBAS]

Awesome post Alex.

[y2kiah]

Hi guys,

That.... isn't quite right. I'll see if I can clear things up.

 

lua.dll and lua-socket.dll are the images most responsible for the implementation of Lua and the socket interface used for external communication from Lua script.

 

dcs.exe has embedded Lua to use as a scripting language, there is no polling of files going on at all. dcs.exe loads the images (dll's) at runtime and makes calls to Lua to control it at a high level, like write to its state(s) and read from its state(s).

 

Lua is an interpreted scripting language, the code that you write into export.lua is literally running pre-compiled code at runtime. Lua was implemented with C++, just like DCS. The Lua interpreter parses your commands in real time and decides which code path to take.

 

No data is written to any file and then later read back in, everything is in memory until you explicitly tell Lua to write something to a file. I would recommend against that though. There is no need for polling a file for changes, your script should be complete when it is loaded at startup, because changes to it will *probably* not be picked up at runtime.

 

The DCS programmers have control over the embedded Lua engine, and have determined the hooks that they create to interface with the sim. export.lua, and the specific functions within it, are the hooks that we are given to run our code within the context of the simulation. They give us some data objects and functions to call to interface with the sim. What we do with it is completely up to us.

[Alex_rcpilot]

Thanks y2kiah for your timely correction. My appologies for making the confusion deeper instead of clearing things up. When I said executables I didn't really think of dlls which are also compiled functions to be executed. I'd vote for you on the lua file handling part. Finish them before running the program.

[pitbldr]

Hi guys,

That.... isn't quite right. I'll see if I can clear things up.

 

lua.dll and lua-socket.dll are the images most responsible for the implementation of Lua and the socket interface used for external communication from Lua script.

 

dcs.exe has embedded Lua to use as a scripting language, there is no polling of files going on at all. dcs.exe loads the images (dll's) at runtime and makes calls to Lua to control it at a high level, like write to its state(s) and read from its state(s).

 

Lua is an interpreted scripting language, the code that you write into export.lua is literally running pre-compiled code at runtime. Lua was implemented with C++, just like DCS. The Lua interpreter parses your commands in real time and decides which code path to take.

 

No data is written to any file and then later read back in, everything is in memory until you explicitly tell Lua to write something to a file. I would recommend against that though. There is no need for polling a file for changes, your script should be complete when it is loaded at startup, because changes to it will *probably* not be picked up at runtime.

 

The DCS programmers have control over the embedded Lua engine, and have determined the hooks that they create to interface with the sim. export.lua, and the specific functions within it, are the hooks that we are given to run our code within the context of the simulation. They give us some data objects and functions to call to interface with the sim. What we do with it is completely up to us.

 

Ok, so is it accurate to say that in my previous example, when a button is pressed and the interface sends out a command, that it's the LUA intepreter that is "reading" that and taking the appropriate action?

 

I've been working through some online LUA tutorials, so some of the code is starting to make sense, but I'm still fuzzy about how the sim receives the commands. I have the impression now that a custom software/interface solution can send out commands to the port specified in export.lua file. I assume that those commands being sent are the "hooks" you're referring to and LUA already knows what to do with it.

 

Thanks for everyone's time in answering! I know this may be basic stuff, but it's all new to me. :)

[y2kiah]

Alex, minor details aside you were right on, wasn't really correcting what you said. Somewhere along the line the notion of Lua being a file dump got out there, I was just trying to correct that.

 

pitbldr, yep, you have it now.

In function LuaExportStart() we open a socket for reading and writing with external programs. We can choose either TCP or UDP.

 

If TCP, we must establish a connection with a TCP server that is running somewhere (most likely the same computer for most of us) and listening for connections.

 

If UDP, there is no concept of a connection, so we can just start sending packets and listening for them.

 

Then when the sim starts, function LuaExportBeforeNextFrame() and LuaExportAfterNextFrame() are called each frame. In them, we should do the following:

1) read any messages that have come into our open socket from the outside world. This is how messages from our hardware finally reach the simulation.

 

2) parse the message and do something with it, either performClickableAction() for some control, or anything else we may need to do. It's up to us to determine the message format. At a minimum, we need to know which control to set, and the value to set for the control.

 

3) get latest values from simulation for output to our lights, servos, stepper motors, etc. this is done with get_argument_value(). When we have all of our values, put together a message to be written to the socket. This will send the message out of the sim and eventually to our hardware. Polling for changes every frame can be a problem, we don't want to saturate the network with 60 messages per second when our hardware can't even respond that fast. This step can be done within LuaExportActivityNextEvent(t) every .1 seconds.

 

So how does our hardware connect into all of this? For me, using the Wiznet shield on an Arduino, I can connect my interface card directly into the same TCP server that Lua connects to. So when I flip a switch

1) my Arduino firmware reads the input

2) it sends a TCP message to the server

3) the server forwards that message to the sim (Lua)

4) sim parses the message and does performClickableAction()

 

this works in the opposite direction as well. This is just one way to do it and requires me to write the firmware, a TCP server running on the PC, and the export.lua file.

 

If you use OpenCockpit cards, they handle the first two for you, and you just need to write an export.lua to send messages in the proper format. If you use Helios, even export.lua is written for you, so you need to write almost no code at all.

 

Hope this helps.

[Alex_rcpilot]

Actually what you were asking is really a good question. It involves what's going on between different modules within a software (DCS) itself, and between different pieces of software. The answer helps everyone get a better understanding of a vast collection of similar software. I'd like to take this chance to learn more from other guys.

 

For the lua part. IMHO, it's like handing a task list to your accountant. It lists all the account numbers and phone numbers needed during work, but this sheet itself isn't money. Then during working hours a phone call arrives that involves one of the accounts on the list, the arranged withdrawals or deposites will be "triggerred" accordingly. The accountant does it all, and you don't need to know which bank she visits to get it done.

 

The task list is like your lua file(s);

the accountant is like the group of DCS programs in charge of related functions;

the phone calls are like magic strings in your socket report(highlighted in my screeny) triggered by pre-defined events;

the money in or out of corresponding accounts are like effects triggered by your report.

[Alex_rcpilot]

No problem y2kiah. I remember you had a PIC32 board back then. How far did you go with that?

[y2kiah]

I've been using Arduino all along, I think Gadroc was using PIC or maybe someone else. My solution is about 2/3 finished. I have to stress test my firmware to make sure I don't run out of memory on the boards in practice. I'm doing some tricky things with dynamic memory that aren't exactly recommended on AVRs so I can pass configuration to the board from the PC and never have to re-flash the firmware when I make a hardware change.

 

I also have to finish the server. Attached is a shot of how that is going so far. It looks better running on Windows 7, but it will run on XP, Vista and 7 and possibly Linux if I get around to it.

[pitbldr]

Y2kiah and Alex - thank you both very much! That is the information I needed and helps tremendously. I think I have enough now to start playing around with the LUA code. I am sure I'll have more questions, but at least this is starting to make sense. :D

[Alex_rcpilot]

I've been using Arduino all along, I think Gadroc was using PIC or maybe someone else. My solution is about 2/3 finished. I have to stress test my firmware to make sure I don't run out of memory on the boards in practice. I'm doing some tricky things with dynamic memory that aren't exactly recommended on AVRs so I can pass configuration to the board from the PC and never have to re-flash the firmware when I make a hardware change.

 

I also have to finish the server. Attached is a shot of how that is going so far. It looks better running on Windows 7, but it will run on XP, Vista and 7 and possibly Linux if I get around to it.

 

Oh wow, that's pretty neat work you're doing there. You've got tons more experiences with PC programming than I do. I'm glad that you've got so much up and running, and that it's just a fraction of the big picture.

 

You're right about AVRs and dynamic memory. With all those pointers assigned here and there, it's like building an OS from scratch, at least the memory management part. Good luck with the testing job!:thumbup:

[Alex_rcpilot]

You're welcome pitbldr, it helps us all with these discussions.

[Gadroc]

I've been using Arduino all along, I think Gadroc was using PIC or maybe someone else. My solution is about 2/3 finished. I have to stress test my firmware to make sure I don't run out of memory on the boards in practice. I'm doing some tricky things with dynamic memory that aren't exactly recommended on AVRs so I can pass configuration to the board from the PC and never have to re-flash the firmware when I make a hardware change.

 

I also have to finish the server. Attached is a shot of how that is going so far. It looks better running on Windows 7, but it will run on XP, Vista and 7 and possibly Linux if I get around to it.

 

I'm using an Arduino based system as well. I've got working prototype breadboard versions of a few different models to run steppers, digital inputs and led outputs. I've got the protocol over RS-485 between boards done, but need to finalize the RS-485 to usb bridge setup.

[TigersharkBAS]

This thread is plus 1 awesome. Thanks to all who are sharing their knowledge.