Oakes

Hi Hellfrog/simu12011 1st question: Well, it seems that all indicators are linked to the mainpanel device (deviceID =0) rather than the panel they are actually located at, check mainpanel_init.lua for values. 2nd question: Sorry, haven't used that type myself, as I'm sure you know you can implement you own Device/switch handling function in ExportSupport.Lua (specific functions are at the end of the file) and feed it parameters based on the inputsTable: [510] = {SimpleRotary, 12, 4},The above equals the call SimpleRotary(valueOfSiocParamNbr510, 12, 4) [3603] = {Hellfrogsfunction, 36, 1, 3, 4},might be appropriate.... Just remember that you can only have 5 parameters on each line i.e. in the following code 11, 22 and 33 will be ignored [3603] = {Hellfrogsfunction, 36, 1, 3, 4, 11,22,33},You can change this by adding more parameters to this line in Export.lua inputsTable[lSIOC_Param][1](lSIOCValue, inputsTable[lSIOC_Param][2],inputsTable[lSIOC_Param][3],inputsTable[lSIOC_Param][4],inputsTable[lSIOC_Param][5]) No need, this type works like a rotary and expects to get 0 and 0.1 and 0.2 as input to performClickableAction. Make the switch change a SIOC parameter to 1, 2 and 3, code below is for the Burst Lenght switch (same behavior) Var 0510, name BurstLen, Value 1 Var 0506, name BurstLenShort, Link IOCARD_SW, Input 8 { IF &BurstLenShort = 1 { &BurstLen = 1 } IF &BurstLenShort = 0 { &BurstLen = 2 } } Var 0507, name BurstLenLong, Link IOCARD_SW, Input 6 { IF &BurstLenLong = 1 { &BurstLen = 3 } IF &BurstLenLong = 0 { &BurstLen = 2 } }And this line in inputsTables.lua takes care of the DCS side [510] = {SimpleRotary, 12, 4},Just let me know if you need any more help. /Oakes

Hi Stelios I don't have any USBKey card myself so take the following with a big:) grain of salt. You need to first connect the card to SIOC via sioc.ini From the SIOC help file (Press Config in main SIOC program and then search help on usbkeys & usb_keys): Secondly you need to bind the USBKeys card to a parameter in SIOC (again from the help file): This will give you a SIOC parameter that briefly takes the value of the the pressed button and then returns to zero, you can then send this value to DCS and use it to determine what you want to do. Without having access to the hardware (I use the master cards and the scripts are written for that purpose) it is problematic to give any better advise, one question pops to mind though, what happens when you release the button (i.e what will be sent to the linked variable?) Can releases be detected? /Oakes

Hi Jenx Here is a scritp for Autohotkey that should solve your problem. You need to replace the "1Joy1" and "1Joy2" parts to match the buttons you have connected the switch to. Format is "(Joystick Number)Joy(JoystickButton)". The Joystick Number is simply the number the BU0836 has in the controllers list under Settings/Control Panel/Game Controllers. I'm not sure if the switch uses S or s but you can change this as well in the script below. /Oakes

That one is for someone not using SIOC /Export.lua etc. if you use SIOC my export script has support for these types of switches as you can see in my post above. /Oakes

Jenx, I'm a little l bit unclear on how you have connected your switch to the sim. Are you using any software or are you just mapping the physical switch directly as a joystick button within DCS? Can you explain this in some detail, since you are using the BU0836 I was assuming that you do not use Export.lue etc to interface with the sim. /Oakes

This will work just fine with the current scripts, from an input perspective a momentary 3 position switch is not different from a non-momentary 3 position switch. So how do we do this with OC/SIOC? 1. Connect you 3 pos switch to two inputs (say 10 & 11) so that when the switch is up input 10 is activated and when the switch is down input 11 is activated. When you let go of the momentary switch no input is activated. 2. Connect your inputs to 2 variables (say 100 & 101) in SIOC and also create a 3:rd variable (say 102) . 3. Write some SIOC code for 100 and 101 that changes the variable 102 so that when the switch is in the up position 102 = 1, when in the middle position 102 = 2 and when in the down position 102 = 3. 4. Update the inputsTable table (use the SimpleRotary function) with the appropriate values found in clickableData.lua Currently I'm working on getting the weapons display to function correctly and I've also done some coding for getting instruments to work (servo based, some initial success with the variometer) /Oakes

Well, you need to calculate the number of steps needed to get to where you want. So if you physical switch is in the long position and you move it to the med position you need to send 2x S etc. You can do this by catching the Joy buttons from the BU0836 with autohotkey and then send the S key the appropriate times. Or maybe I misunderstood your question? /Oakes

For the datalink buttons (haven't checked any other buttons) the following logic applies: 0 = Button is not pushed and indicator is off. 0.1 = Button is not pushed and indicator is on 0.2 = Button is pushed and indicator is off 0.3 = Button is pushed and indicator is on If round(lamp) == 0 or round(lamp) == 0.2 then -- code for lamp off else -- code for lamp on end I suspect that there is a smarter way to do this test since 0 = not pushed, 0.2 = pushed and if you add 0.1 to this it means that the indicator is on. Anyway, you can use this to know the complete status of the button not just the indicator. Secondly, I checked the values and I get something like 0.1000002325 and 0.200000423 rather than 0.1 and 0.2 so I use a round function to get rid of the "tail" so to say, you can check in ExportSupport.lua (<- from my scripts) for a good round function. /Oakes

Yep, thanks again Colin, gave me a little bit of a headache though..but now it's solved. Problem: MainPanel:get_argument_value(615) returns -1 if the gun is the Safe/Non-selected position. Returns 0 if the gun is armed / selected and returns 1 if the gun trigger is pressed. Funny thing though, if you press the trigger with the gun in the safe position the function still returns 1. So you can't say that as long as MainPanel:get_argument_value(615) == -1 show the weapon type/remain values, as soon as you press the gun trigger the values disappear since MainPanel:get_argument_value(615) now returns 1. Solution: Use a global variable that is set to "Armed" if MainPanel:get_argument_value(615) == 0 and to "Safe" if MainPanel:get_argument_value(615) == -1 => if you just press the trigger MainPanel:get_argument_value(615) goes more or less directly from -1 to 1 (without hitting 0) => the global variable is still "Safe". Then use this value to determine if the weapon type / remain number should show or not.... I guess that the real cyclic makes it impossible to press the gun trigger while in the safe/non-selected position....... /Oakes

Hi Colin Did you find a solution for this problem.....because now I have the same problem:)... /Oakes

Attached is my somewhat generic solution for export/import to SIOC / OpenCockpits cards. Some knowledge of programming is needed to make the scripts work. General idea has been to keep most of the complicated stuff out of Export.lua and into a bunch of support functions + definition files to make it easier for myself and other to connect the appropriate switches, LED's etc to their simulated counterparts. This version supports: Inputs with specific function calls for each SIOC parameter. Comes with ready made functions for "two position switches" and "rotaries". Simple on/off indicator output, cockpit LEDs, warning lamps etc. Usage: Install by unpacking and overwrite into the Export directory of DSC:BS. Note: Make a backup. Configure you SIOC server host ip and port in siocConfig.lua Configure your inputs/outputs in the appropriate files in the SIOCConfig directory. Configure the options in the USER SETUP SECTION of Export.lua This section needs to match the files etc in the SIOCCONFIG directory. Future work: Add support for rotary encoders. Add support for instruments (altimeter etc) Add support for selected weapon. Add support for Nav system display Enjoy:thumbup: Thanks to PanelBuilder for the help. /Oakes Update: I've created a Google Project to keep tabs on the code for the scripts. Future releases will be posted there. http://code.google.com/p/dcsbsexport/ If you want access to the code you can 1. use http://tortoisesvn.tigris.org/ for simple export to your computer 2. you can download complete releases from http://code.google.com/p/dcsbsexport/downloads/list 3. You can download individual files from the repository via the source code browser http://code.google.com/p/dcsbsexport/source/browse/ (click on the file and then right click on the "View raw" link). /Oakes Export_0_90_beta.zip

Tried without the try, worked like a charm, not completely certain what potential side effects etc this has....need to dig a little deeper into LUASockets.:helpsmilie: Thanks Colin /Oakes

A little problem, as soon as I add the "local inpst = socket.try(c:receive())" to LuaExportBeforeNextFrame() I get a Lua::Config::call error LuaExportBeforeNextFrame:(null) in the error log, presumably 1x error per frame => error log grows quickly. If I remove the local inpst = socket.try(c:receive()) the error goes away. Everything works though, I get data on the socket etc so the only problem is the huge log file after a couple of minutes of playing. One theory that I have is that the error is a result of calling "socket.try(c:receive())" when there is no data waiting on the socket ( = > 99.99% of the time). Anybody have any ideas? /Oakes function LuaExportBeforeNextFrame() -- Works just before every simulation frame. -- Call Lo*() functions to set data to Lock On here -- For example: -- LoSetCommand(3, 0.25) -- rudder 0.25 right -- LoSetCommand(64) -- increase thrust --io.write("---Log: Check for packet on Socket-----", "\n") local inpst = socket.try(c:receive()) if inpst then io.write("---Log: Packet on Socket-----", "\n") io.write(inpst.."\n") for lSIOC_Param, lSIOCValue in SIOC_Parse(inpst) do local lInputsTable = inputsTable if lInputsTable[lSIOC_Param] ~= nil then -- io.write(lInputsTable[lSIOC_Param][4].."\n") lInputsTable[lSIOC_Param][1](lSIOCValue, lInputsTable[lSIOC_Param][2],lInputsTable[lSIOC_Param][3],lInputsTable[lSIOC_Param][4],lInputsTable[lSIOC_Param][5]) end end end

http://www.lua.org/pil/ /Oakes

Found a small bug in the code for the letter "R". Fix is attached, unzip into the SIMPLEFONT directory. /Oakes R.zip

Yep, I'll post the code as soon as I get a minute to myself......:music_whistling: Yes, good cards, bad documentation Made a little servo tester rig as preparation for starting making instruments. Test results are not so good, the servo and/or the USBServo card are not linear (off by about 5-7 degrees for the middle of the travel envelope), so there will be problems with using servos for instruments. However the servo was repeatable to about 0.5 degrees so servos will work fine for indicators with few discrete steps (like a flap indicator) where you can test and trim each position individually. For a 360 degree indicator like the variometer the non-linearity will be problematic (especially since servos have about 120 to 180 degrees of travel -> meaning you will need gears, which will multiply the non-linearity of the servo). I guess one could map the non-linear response from the servo and compensate in Export.lua but that might be somewhat time consuming. Then again I bought the cheapest micro servo I could find to test with so the problem might be related to a lack of quality. More testing needed....... /Oakes

Did a little work with Export.lua yesterday. /Oakes

or.. a guy with excellent skills in building joysticks maybe :smilewink: Seriously though, I've found that the datalink panel makes me a lot quicker when it comes to "datalinking"....so much easier to reach out with my left hand and punch a solid button rather than fumbling with my mouse. Yes, exactly, couldn't have said it better myself. I find great satisfaction in building stuff and making it work...if I didn't build sim stuff I'd be building something else... /Oakes

Spent some time with the CNC this evening: /Oakes

Hi Trigger Is that a servo I see in the back? I've been thinking about if the 1024 steps you get from the OC Servo cards will look ok on a 360 degree instrument (2,84 steps / degreee) => about 0.35 degree resolution. Maybe the motion will be quite jerky....but then again steppers require more hardware. Any ideas on backlash elimination in the gearing system? (I'm assuming you use a standard 180 degree servo and hence the need for gears) One little idea I've been thinking about is to replace the 180 degree servo feedback pot with a "normal" 280-300 degree pot to avoid having to use gears (this pot could be mounted externally on the axle somewhere). Do you have a good source for gears btw? (other than Lego :)) /Oakes

Didn't know about the English version. Well, I'm hoping that we can use the framework of LoSIOC to generate the LUA files needed to get the export/tcp etc connections to SIOC running, and then modify those files to match with DCS....or at least get an idea of a suitable approach...maybe easier than to start from scratch....I seem to remember that LUA coroutines and other stuff gave me a headache the last time :) But then again, if the LoSIOC team is a couple of weeks (here's hoping :)) from releasing a DCS version....... /Oakes /Oakes

Yep, any news from the LoSIC guy? Can we use his stuff or do we have to start from scratch? /Oakes

Wow...just wow:thumbup: /Oakes

Thank you all for the kind words. Hmm..the "limit" switches are the only connection to the sim. My plan is to send the gear up command when the lower switch is pressed (handle is up) and the gear down command when the upper switch is pressed (handle is down). I.e. to go from gear up to gear down the following will happen: 1. Pull the handle 2. Lower the handle (still pulling) 3. Release the handle (which will press the switch) 4. Send Gear Down to the sim. If there are no separate gear up/gear down commands I will use some SIOC logic to insure that the handle will not be out of sync with the sim. i.e. only send the "G" key when the opposite switch from the last one pressed is pressed. I don't know how the real control operates i.e. at which point in the pull - move - release cycle the landing gear up/down sequence is initiated. Maybe someone can enlighten me. /Oakes

Just making sure you guys are awake :) Yes, in the picture the spring should be uncompressed rather than compressed i.e. when you pull on the handle the spring will compress. /Oakes