Gadroc

Ugh.. It's been able to do that from the beginning. Every profile has a keyboard interface in it be default.

Thanks for the good wishes guys. Been a very very busy year. Starting to get an itch for working on the pit, so hopefully you'll see more from me regularly.

Newer versions of DCS World automatically fall back to window mode if you have specified a resolution higher than the primary display.

Windowed mode. Helios draws over top of the MFDs drawn by DCS. If DCS is in full screen Helios can't draw on top of it.

I believe you need to call update_arguments on MainPanel before pulling out values.

Ian this looks like excellent work. I'm definitely going to look into using this and getting Helios to work with it. One note on your cascading setup. RS-232 is not meant for multidrop like that, and you'll probably run into signaling problems on longer runs. Rs-485 is a better choice for that. I'm going to probably run a i2c and re-485 bus daisy chained between each panel.

I think I have them stashed somewhere. If not I can recreate from my cad files. Might take me a few days.

zahry, This looks interesting. I need full dimension on this to check my cockpit and basement space. Do you have a full recommended setup including projector mounting? One constraint I have is I can't use full screen mode for warping software as I'm not willing to give up my MFCD screens.

That's the machine I started with. Check my build thread for an evolution of using it.

EOS boards are essentially low component count arduinos. What they add above and beyond off the shelf arudinos is bus communications (RS-485) and connector standardization. (same connector/headers for serial bus and power on all boards). When I put them together most of the solutions on the market where huge IO count centralized models (OpenCockpit and PHCC). I found two problems with them. First it required running hundreds and hundreds of wires from panels to the central IO solution. While fairly realistic it's a big pain to run and really hard to troubleshoot and fix. Second due to pin configurations on the IO board you often had to run custom break out boards in order to manage wiring. This meant I was paying for PCB fab. The other options on the market where low I/O count boards which where MUCH more expensive per input. Often they also where specialized input (Joystick/Keyboard Emulator) or output boards. Very few combined each. They also ended up consuming a large number of USB slots which becomes problematic. So EOS was conceived to do the following: 1) Standard wiring to each panel being two serial ports for daisy chaining and power. 2) Low cost per panel (<=$25) 3) Small in size so it can be mounted with the panel / instrument 4) Flexible to have multiple form factors (panel vs gauge) 5) Allow for a single connection to the computer per console (left, right and center) 6) Flexible firmware to do many tasks with the same hardware The pin I/O count was specifically chosen to satisfy the majority of all panels in the A-10 pit. I think it will hold true for other aircraft. Those panels which are different can be handled via expansion/daughter boards. (Example MFCDs will use the expansion header and input headers using the flexible firmware to run the MFCDS as a matrix giving enough inputs.) EOS Firmware Library Support Function 1) Analog Inputs 2) Direct Digital Inputs 3) IO Expander Digital Inputs (MCP3017) 4) Digital Outputs 5) IO Expander Digital Outputs (MCP3018) 4) Analog Outputs 5) Servo Outputs 6) Stepper Driver (Only one per board due to interrupt limitations right now) EOS Firmware Library Upcoming Features 1) Rotary Encoder Support 2) Matrix Input Allowing It's very very easy to make these work in a custom sketch (basically create an object and tell it which pins to use). Then Helios can communicate and map input / outputs to the boards.

I use designspark for the EOS boards. I'll be making some for the MFCDs as well. So much to do and so little time.

OutLAW the product description says multi-touch. Which means it should use the native windows capability of touch. If so use the setup steps here to associate the touch device with the appropriate screen.

I'm in the middle of cleaning up Helios so it's open source. Is expect a minor big fix release in the next few weeks. If the authors don't mind I'll include this feature as a module.

Open your profile. Inside the Profile Explorer double click on DCS-A10C / Black Shark. There should be a button that says "Setup DCS A-10C" or "Remove Helios Setup". If it says Remove Helios Setup then the correct Export.lua is already in place. If not click on setup button and it will but the Export.lua in the correct place.

I have an extended 2'x4' shapeoko2 in the garage right now as well. Although I'm going to be converting it to an OpenBuilds Ox this spring. Keep in mind the kind of cutting you want to do. Do you want to do 2.5D where you are cutting pockets and profiles of shapes, v-carving or full 3D objects. That will affect which CAM software you want to invest in. Here is the list of all the CAM software I evaluated around or under $500. V-Carve Pro is hands down the winner in my opinion for 2.5D and V-Carving. It's easy to use feature rich within those sub-sets. I've used older versions of V-Carve pro to cut out my pit. Cut2D looks like a good intro software if you are focused on 2.5D, but has no or limited capabilities for anything else. For those who are SketchUp fans (I most definitely am not in that group). Check out SketchUCam which does CAM right inside SketchUp. It's fairly limited but roughly equivalent of Cut2D. Meshcam is a good cheap 3D CAM system and was primarily designed to do it. It can do 2.5D but still uses STLs as input so it's going to be very limited in comparison to 2.5D tools. You can get a great deal ($149) on BobCAD v24 over at the shapeoko forums. BobCAD is a lot of capability for that price although it has a steeper learning curve. It can do 2.5D, 3D and V-Carve out of the box and with BobArt can do photo to carve operations as well. Be aware that BobCAD has a somewhat sketchy reputation for really aggressive sales. I worked directly with Al Depoalo and did not encounter this. One thing I do not like in BobCAD is it can't do automatic tabs unless you use there nesting component which is only useful in limited circumstances. You'll have to manually setup tool paths to do tabs. There are a few more I did not look in detail at - Sheetcam or pycam. Out side of these everything shoots up to $1k - $3k price range.

Well finally doing some work on the pit again. I finally got all the parts necessary to get my ADI working so this weekend I'm working on it. I got all the pin outs figured out and measured necessary current / resistance to drive the needles. All of the needles work perfectly fine from the micro controller. I was able to design and print up the bayonet adapter for my static inverter using the excess pins I have. So I can get my it wired up and test the ball on the ADI next.

Nicely done! I'll try and test it out this weekend. Interested in trying the same technique for CMSP display in A-10.

I just re-installed my pit and got hit with the bug where ok would not work once I setup my joystick. Looking in the log files I was getting the following error: GUI Error: [string ".\Scripts\Input\Data.lua"]:1270: bad argument #2 to 'format' (number expected, got nil) GUI debug.traceback: stack traceback: [C]: ? [C]: in function 'format' [string ".\Scripts\Input\Data.lua"]:1270: in function 'writeForceFeedbackSettings_' [string ".\Scripts\Input\Data.lua"]:1458: in function 'saveDeviceProfile' [string ".\Scripts\Input\Data.lua"]:1508: in function 'saveChanges' [string ".\MissionEditor\modules\me_options_controls..."]:93: in function 'save' [string ".\MissionEditor\modules\me_options.lua"]:380: in function 'func' [string "./dxgui/bind/Widget.lua"]:203: in function <[string "./dxgui/bind/Widget.lua"]:181> [C]: in function '?' [string ".\MissionEditor\MissionEditor.lua"]:908: in main chunk stack traceback: [C]: ? [C]: in function 'format' [string ".\Scripts\Input\Data.lua"]:1270: in function 'writeForceFeedbackSettings_' [string ".\Scripts\Input\Data.lua"]:1458: in function 'saveDeviceProfile' [string ".\Scripts\Input\Data.lua"]:1508: in function 'saveChanges' [string ".\MissionEditor\modules\me_options_controls..."]:93: in function 'save' [string ".\MissionEditor\modules\me_options.lua"]:380: in function 'func' [string "./dxgui/bind/Widget.lua"]:203: in function <[string "./dxgui/bind/Widget.lua"]:181> [C]: in function '?' [string ".\MissionEditor\MissionEditor.lua"]:908: in main chunk I traced the problem back to my F16 MFD's. The default profile for them are missing some default configuration for force feedback, which causes the save profile to crash. To fix open "F16 MFD1.lua" and "F16 MFD2.lua" in the "DCS World\Mods\aircrafts\A-10C\Input\A-10C\joystick" folder and replace forceFeedback = { }, with forceFeedback = { trimmer = 1.000000, shake = 0.500000, swapAxes = false, invertX = false, invertY = false, }, Now delete the files that begin with "F16 MFD" from your "C:\Users\<Username>\Saved Games\DCS\Config\Input\A-10C\joystick" folder. Restart DCS and you can now configure your joysticks again.

It's still my intention to open source the code, but I need to clean up a few things. In the mean time if someone wants to write a plug in drop me a PM and I'll send you some sample code.

Yes. Any interfacing into the simulation requires export.lua. Both Hawgtouch and Helios are free to download and try. So you can test it out on your favorite servers.

You can not run MFCD, RWR or CDU on another computer. The main computer is the only one that can render them. All of the software that displays them basically screenshots the main computer and sends them to a remote one. Helios will run over a network to render gauges which is how I run my cockpit. I have a small ITX computer embedded in the front console. It runs main Helios, ADI, HSI and runs my physical switches and talks to DCS over the network. The main computer runs the external display, MFCDs, RWR and CDU. To do this you install Helios on both the main computer and remote one. Run profile editor on the main computer and select Profile -> Add Interface -> DCS A-10C/Blackshark. The next screen will show properties of the DCS interface. Enter the IP address of your remote machine and then click setup button. This install the lua files in DCS to talk with Helios. You don't have to run Helios on the main computer after installing those lua files. Next install Helios and create your profile on the second computer. Make sure the firewall is turned off or allows the helios port (default 9089 unless you changed it) through.

This thread should help explain how to read the clickabledata.lua files which tell you exactly how to trigger any cockpit functions.

The problem with the switches staying on is how your sending commands to the simulation. If you look at the definitions of the inputs you'll notice a release action on magnetic switches. When you click in the GUI it will send the action command on mouse button down and a release action on mouse button up. You need to simulate this. When the switch is turned on via hardware you need to send a action command then send a release command. The simulation assumes you are manually holding the switch in the on position if it never gets a release command.

Part of the problem is using loops based on your example code. An arduino sketch calls the loop method over and over and over again. What you need to do is track target, next step time and current positions. Each iteration of the loop check to see if the next step time is here or past and if so step that motor in the right direction then adjust the current position. You can do this with a few motors in series if you want. This also allows you to check for new target positions as well. What will happen with the system as it stands is an escalating blocking scenario. If a new target comes in you'll block all other execution in your "for ( int i= 0; i < abs(step); i++)" delay loop. Which means it has to get all the way to the next target before it reads input again. This means it will not get new smaller incremental changes from other smaller moving needles as you are not processing input during the move. This will make them stutter as they move to new position and then have to wait for all the steps to the large move on the faster moving needle. That being said you will get stutter in motion unless you block as you are or move the stepping code to an timer interrupt (which is where i've gone with the EOS firmware). Now the challenge I have not tackled yet is managing multiple motors in one interrupt is difficult. You can not reliably use microseconds in an interrupt and you need to be very careful how much code you use to loop through motors. You don't get a whole lot of instructions between timer fires at really high speeds on the stepper.

I'm still here just slower to respond than before. I've switched over all my panels to EOS boards. They are currently driving LEDs, Backlights, Digital Switch Inputs, Analog Inputs, Servos and Steppers via Helios. I'm currently running the following on it: 1) Landing Gear Panel (including Flaps Gauge) 2) AHCP Panel 3) VVI 4) CMSP In progress: 1) MFD Bezels 2) UFC 3) CDU Next Up 1) Radio panels. I've got a few weeks off starting next monday so I should have be posting quite a few updates.