Oakes

Hi Hellfrog line 295: lDevice:update_arguments() I assume that this line doesn't fail for every device? (especially not for the MainPanel device) If so, I guess that the particular device referenced in lDevice at the time doesn't contain the update_arguments() function hence the error. You can test for this with the type command: if type(lDevice.update_arguments)~=nil then lDevice:update_arguments() End I think this should work, haven't tested it. You can try this little example here: http://www.lua.org/cgi-bin/demo Just paste this into the box and click run. apa = {a=12, b=20, c = function (self) self.a=self.a-2 end} io.write(apa.a) print "" apa:c() io.write(apa.a) print "" apa.c(apa) -- same as apa:c() io.write(apa.a) print "" io.write(type(apa.a)) print "" io.write(type(apa.c)) print "" io.write(type(apa.d)) -- this function doesn't exist, will return nilOtherwise you can use some form of error catching, but I haven't looked into how LUA implements this. /Oakes

Yes, for input and outputs (i.e switches, rotaries, encoders, pushbuttons and LEDS etc). For 7-seg displays, servos, steppers you need other cards Please see this thread, starts at post 53 (Stelios and me) http://forums.eagle.ru/showthread.php?t=45071&page=6 No, rotaries can be connected directly to the OC mastercard, connect each pin to an input (+ gnd of course) => for a 5 position rotary this means that you will have 5 sioc variables. One of these five variables will then be 1 and the rest will be 0 depending on the position of you rotary => as you rotate the rotary the following will happen [var1,var2,var3,var4,var5] => [10000], [01000],[00100],[00010] and [00001] Have a look at variables 0590 to 0594 in this file (the code for the Datalink ID) (0510 will be 1,2,3 or 4 depending on the setting of the Datalink ID rotary - this value is then sent to Export.lua) http://code.google.com/p/dcsbsexport/source/browse/trunk/SIOC/dcs.txt 3,4,5 etc way switches functions the same a a rotary, i.e. each position of the switch means that a SIOC variable is set to 1 and the rest to 0. For a 3 position switch => [var1,var2,var3] => [100], [010],[001]. See variables 0506,0507 and 0510 for tips (0510 will be 1,2 or 3 depending on the setting of the burst length switch - this value is then sent to Export.lua) Since we have direct connection to DCS via LUA we can set any switch/rotary to any position we want at any time (without actually having to go through all position). This is the flow we use: Physical switch/rotary is moved => determine position of physical switch/rotary (with SIOC) => send to Export.lua via TCP => look up correct parameters for the corresponding virtual switch/rotary => set the virtual switch/rotary to the correct position. /Oakes

Yep, XP is on another machine. Do you run win 7? From memory, around 40-50 I think. /Oakes

I use a 1:2 belt transmission. You can check out the CAD files here: http://forums.eagle.ru/showpost.php?p=776610&postcount=154 /brds Oakes

Nope, futaba servo. And on that note, I've got two problems with the OC servo card: 1. I have to plug/unplug it 10-20-30 times:huh: with Win 7 for it to be properly recognized, then I can reboot the computer etc without any problems as long as I don't remove the external +5VDC from the card. As soon as I do remove the +5VDC I need to do the plug/unplug thing again. Win XP has the same problem although it seems that I don't need quite as many plug/unplugs to get it to work. Anybody else have the same problem? 2. The Pulse length problem, I remember that you Brydling managed to solve this, can I buy a modified OC card/chip from you? /Oakes

New videos of the Variometer: /Oakes

Well, I haven't tried this myself yet (still trying to get the variometer done) but I think you need to do the following: Add a line in your SIOC.ini MASTER=X,6,1,Y where X is the next available number (for me this would be 1 since my (single) USBExpansion card is number 0 - probably yours as well). Y is the device number which I think should be shown on the SIOC software page (under devices) when you have connected the card. Otherwise it should be available in the test program for the USBoutput card see this link -> http://www.opencockpits.com/modules.php?name=Downloads&d_op=getit&lid=320. Example (and yes I made up the number 36 below, this differs from system to system) [MASTERS] MASTER=0,4,1,13 <- USB Expansion card MASTER=1,6,1,36 <- USB Output card btw the second number defines the type of card (4 for a USB Expansion card and 6 for an USB Output card) Now, to link a variable to a the USBOutput card instead of the Mastercard you need to add the X number at the end of the Link IOCARD_OUT statement in your file. Var 123, name USBOUTTEST, Link IOCARD_OUT, Output 1, device X With my example above: Var 123, name USBOUTTEST, Link IOCARD_OUT, Output 1, device 1 btw, If you leave the "device X" out of the IOCARD_OUT line it defaults to device 0 <- which is why everything has been working so far I.e. Var 123, name USBOUTTEST, Link IOCARD_OUT, Output 1, device 0 = Var 123, name USBOUTTEST, Link IOCARD_OUT, Output 1 Also, please note that the USBOutput card is electrically inverted from the Master card. Master => Common Ground & Individual "+V" USBOutput => Common "+V" & Individual Ground /Oakes

I'm sorry but maybe I've misunderstood your question (keyboard etc)...how to write to Export.lua? You can send info/commands etc back to Export.lua over the same socket that you've used to extract stuff from DCS, you then need to parse this in export.lua and call the appropriate commands to toggle switches etc. Is this what you meant? /brds Oakes

No 3 -3 on mine, mine looks like this: 2 + 2 1 1 0 - 0 On mine when you push the button 0 and 2 will be connected. /Oakes

Fill the tube with water, plug both ends, put it in the freezer for a couple of hours and then do the bend (the ice will prevent the tube from collapsing at the bend). /Oakes

Yes, interesting, but...does this mean that this modified servo card will still work with SIOC or do we need some other way to interface with it? /Oakes

Servo card from OpenCockpits. http://www.opencockpits.com/catalog/electronic-cards-iocards-servo-motors-c-21_32.html /Oakes

Part 2 of the variometer. /Oakes

Yep. /Oakes

New video: Milling a part for the Variometer. /Oakes

I've done something similar for outputs (LEDS etc) in the latest version of my script: http://code.google.com/p/dcsbsexport/source/browse/tags/beta_0_93/Export.lua#158 As you can see LEDs etc will only be updated at about 5hz. I tried the same with inputs but I didn't like the slight lag this produced. On the other hand for 99.99% of the times when I check the socket for any input traffic there is none because SIOC as you know only sends changes to variables i.e. I flip a switch. => unless I flip a switch there is very little processing capacity required per frame. You can see this in the example below: If inpst = 0 (which it does 99.99% of the time) then we jump directly to end => no processing necessary [color=Blue] local inpst = pit:receive() [/color][color=Blue] if inpst then ..... ..... end [/color]Why such a big FPS improvement, well it depends on what the ProcessInput() function is doing (it's is not mine, I guess it has something to do with multi BSVP SIOC TouchPAL etc.). Maybe only place this function into LuaExportActivityNextEvent(t) and keep my stuff as it is. /Oakes

Working on it....new youtube video coming soon. /Oakes

Datalink is momentary and so is the Targeting Systems panel (Auto turn, Reset etc) in the real chopper I believe so I went with momentary as well and so on. /brds Oakes

Wow! :thumbup::thumbup::thumbup::thumbup::thumbup::thumbup::thumbup: /Oakes

Pictures? (pretty please with sugar on top :)) /Oakes

Servo based (Futaba S3003) instrument design. Time to warm up the CNC.... /Oakes

Ok. Thanks Colin. /Oakes

:doh: Dooh...didn't think of that...thanks Colin. /Oakes

No, with my solution the switches can never (excluding bugs etc) be out of sync so at start-up all out-of-sync "sim" switches will be set to the "real" switch position. So you'd better make sure that the fuel cut-off levers are set to the correct position when starting in the air or else you'd have to set a speed record in "turbine startup":) /Oakes

Hi Colin yep, I know, the problem is that the get_weapon_type_on_station() reports the station as EMPTY, so if you use that as the "trigger" for display or not display ones "real" display will be out of sync with the "sim" display (since the sim display follows the behavior you described). Anyway I made a work around in the script (only update the display if you select a different station). It's a little bit messy, I'm seriously thinking of rewriting that part of the code at some point....:book: maybe there is a smarter way. /Oakes