Gadroc

The source code to Helios has been available for a while now.

Looking great!

Keep in mind that a laser cutter cuts on the line, as opposed to a CNC router or mill which cuts to the line. When calibrating you will need to account for kerf.

What value is the potentiometer that your using?

360 degree servos don't allow positioning. They rotate contiously you can only vary speed. You'll need to use gears to add more rotation.

Yea I went build my own route. I used the tube, power supply and optics out of the same machine as weeb got. Actually theatmachine worked fine post 608 upgrade. Only reason I upgraded is so I could fit a full 12x24 inch sheet in the machine. I avoided FSL due to some interesting posts and feedback as well. Their driver is nice, but they have no support for DIY and I don't like the 5th gen design.

No not right now... And this is a very non-trivial exercise. I've written up some of challenges before.

Nope. POKeys are not arduino compatible micro controllers.

I wouldn't consider a RAMPS/arduino for a laser. It will only work well for outlines. The X7 and 608 are great controllers and will allow engraving, cutting at multiple speeds, PPI all in one job. My laser became 10x more useful once I put one in.

Mini pros have 20 available pins for use. Digital Pins 0 & 1 are required for communications so they can't be used which leaves 12 digital pins. Analog Pins A0-A5 can also be used as digital pins which gives you 6 more. And if you look on the board it has A6-A7 also there just doesn't have pins soldered in for them which gives you two more. By the same math Megas have 52 digital available + 16 analog/digital for 68 pins. There are a few more things to consider than just total number of pins. 1) How do I repair or modify parts of the pit individually? 2) Do I want to be able to add functionality later to a panel? 3) What is my power draw? Only so much current can flow through the microprocessor at once. How many of those 68 pins can be active at once. 4) How do I manage ground connections? While the mega and mini have 20-68 inputs they only have 2-3 ground pins. Every switch will require a pin and a ground connection. What is your wiring harness going to look like. 5) How much are all my connectors going to cost? If you have central wiring don't forget to include the cost of D-Sub or other connectors at each panel. 6) Am I going to do back-lighting? If so you're not going to drive it straight off the arduinos. A single panel back-light is approximately 200-300ma of current based on my experimentation. This quickly adds up and you really need to worry about power management. There are more and if people want I'll spend some more time later this week doing some write ups. I feel like I'm the downer on this thread, but that's not my intent. I just want people to plan ahead. Not thinking this through all the way because one panel was easy is going to lead to a lot of wasted money and time. Ian has done a tremendous job of making getting started easy and I'm ecstatic about the activity driving forward.

Servos are easy and can be done out of the box. Although you need to be very careful about wiring and current to not blow your arduino. Steppers are a different story they require a stepper driver module and more careful timing to work correctly. I have proper timer driven stepper code with acceleration done in EOS and I will be porting over.

It's all about trade offs. Here are the signaling options I see at hand. 1 - Dedicated USB-TTL Each In this case we will have to replicate the memory data to each individual serial bus. This will result in the computer doing a lot of lifting to replicate and transmit the same data 58 times. This is the simplest to do as there is no hardware design work. It is going to take a lot of USB hubs, but is roughly 15Mbs in data which should be no problem for High Speed USB 2. I would likely off load this from the main flight sim computer to be safe on performance. Cost: $116 ($2 low end cable x 58 ) Cost: $125 ($25 10 port hubs w/ power adapter x 5) Total: $241 2 - TTL Direct w/ I2C return Just run cables between the serial tx/rx pins from many Arduinos. Theoretically this could work but is likely stretching the bounds. The cable will end up being several meters once daisy chained around the entire pit. This is likely going to pick up lots of noise form the PWM back-lights, stepper motors and servos. In addition that length of cable might cause problems with signal quality itself due to the capacitance of the wire. Some one really needs to do the math on this one before saying it's good. This may end up drawing more current from the drivers than they can handle. Or it may work just fine. One down side is it complicates using the I2C bus for other chips like IO Expanders. Lastly what I'm really concerned here is the ground coupling across the boards. For the TTL signaling to work they all have to share the same ground reference. This means running ground wires between all the boards. I'd have to do some research on how to do that in a safe manner with out inducing unwanted current. Cost: $6 ($2 low end cable x 3) Total: $6 (but not sure it will even work at scale in the pit) 3 - Line Driver/Receiver In this case you can select between RS-232, RS-422, RS-485, CAN and a few others. These drivers have clear specs on cable length and number of receivers which can be connected. CAN would require dedicated capabilities in the micro-controller as well as a transceiver. The atmega328 on the minis do not have CAN capability, which means a CAN controller IC, additional crystal and transceiver IC. This will cost $4-$6 in parts for just the can bus. In addition it will take a lot more space on a circuit board. RS-485 is a much better choice for the Arduino. I'm using the Texas Instruments SN75176B RS-485 driver. These can handle up to 32 transceivers on the bus and only cost $0.88 each at low volumes. Cost: $51.04 ($0.88 per SN75176B x 58 ) Cost: $6 ($2 low end cable x 3) Cost: $105 ($35 raspberry x 3) Cost: $50 (twisted pair wire) Total: $212.04 Plans 1 and 3 are with in spec of all the components and I have high confidence they'll work with little error. RS-485 is actually cheaper once you factor in the usb hubs. In addition you'll probably run into issue with windows on the $2 usb cables. They are almost guaranteed to be counterfeit Prolific or FTDI chips as the chips themselves inside the cables cost that much at volume. The latest drivers from those companies may not work with the counterfeit chips. Non-counterfeit cables cost $10-$15 each.

Also for anyone using DCS-BIOS I have written a Java library to parse the UDP stream. I'm using it on a raspberry pi to render an HSI. You can find it here on my github (https://github.com/Gadroc/dcs-bios-reciever) account.

There are approximately 36 panels which need circuits (including CP indicators and indexers as 1 panel). An Arduino Mini Pro has 20 input/output pins which can be used. According to my panel input spreadsheet this means 21 of the those panels can be managed by a single mini pro. The rest of the panels will require additional expansion chips or multiple Arduinos. Let's do a rough guess saying 4 of the panels will require two Arduinos that means just with panels we have 40 Arduinos. In addition, assuming we are using an LCD for ADI/HSI, we still have 3 primary instruments (VVI, Altitude, IAS), about 6 secondaries (AoA, Clock, Oxygen etc...) and about 12 engine gauges. That's around another 18 Arduinos. Grand total that's 58 Arduinos and if you count the I/O pins to drive seven segments your well into the 500-600 I/O lines. This is very different problem than just one board many are working on right now. I'm not sure we want to be trying to drive 58 individual serial buses all with the same data. It's not going to be manageable. While I love the DCS-BIOS export functions and network protocol, I don't think the arduino side scales properly to the protocol needed for running the entire cockpit. Out of Band Commands / Configuration - Right now the protocol does not allow for sending commands to individual boards. It only allows for data from the simulation. In particular when we get to steppers you will need the ability periodically to re-zero them. This requires the ability of sending commands not just simulation data. No Polling Capability - In order to fix the 58 individual serial buses, we will need some multi-drop support in the protocol. This requires the ability to pass a "talking stick" around the arduinos so each of them can speak it's input commands in turn without talking on top of each other. Both are symptoms of not having a packet / addressing layer to the serial bus protocol. On the Ethernet side UDP does this for us. But we are currently just taking the contents of the UDP packets and sending them raw onto the serial bus instead of wrapping it in another packet format. My current thought process is to divide the pit into 3 to 4 separate RS-485 buses. Right Console, Left Console and Center Console. Each of the buses would be controlled by a raspberry pi listening on Ethernet to the DCS-BIOS UDP stream. It would then map the DCS address space into an address space specific to that bus. This will narrow down the data needing to be sent each from on the serial bus to about 64-100 bytes per bus. Now I can loop sending those bytes to each board on the bus requesting any inputs they have. Each board responds and I move on to the next. This should allow 20 Arduinos per bus each being updated continuously and polled about 5 times per second. That being said I could also subdivide it a little further where each console has two raspberrys. One for inner panels and the other for outer panels. This would have each pi managing about 10 usb serial ports. I'd still run into the command issue which will require some modification to the serial bus protocol. This is tempting from a power distribution standpoint as well.

Latest versions of Helios detect DCS World and create it in the right location.

For DCS World the location has changed. They are in your "%USER PROFILE%\Saved Games\DCS\" folder if I remember correctly.

The only real requirement is that the touch screen works appropriately in the version of windows you use. The one thing I would look for is the touch screen type. An optical or capacitive multi-touch system works best. Especially if you want to use sliders or rotary style inputs. Resistive touch screens work fine but require far more pressure to keep the mouse button down. As Ian said you want at least a 1920x1080 screen to take advantage of most of the existing profiles, but any will work. Helios can resize profiles to your screens but things can quickly get to small to actually use. Personally I think the sweet spot is 21"-24" screen with an optical multi-touch controller. I have not kept up with the market on this so don't have specific screens to recommend anymore.

Are you creating a new interface that you want added to the Helios source code? Let me know if you need help. I can walk you through submitting a pull request so it can be incorporated into the main source tree.

The anti-collision switch is a magnetic toggle switch which will only stay on in certain situations. For helios you need to bind the toggle switch to both to position change and release actions.

You probably have a feedback loop. The simulation changes the switch, which causes helios to send the switch change back to the sim. When you bind state from the sim to the switch. Make sure you check the checkbox that prevents the cascading triggers. I can't remember the exact wording on the screen right now. I'll have to look tonight.

That looks correct. Try turning off Windows Firewall on the Helios PC.

You need to research pointers. I won't directly give you the code, as using them without understanding them is a recipe for very very nasty crashes. Basically you define the variable in your sketch, pass in a pointer to the variable location in the constructor. Then the deference the pointer when setting the bit.

The 0xfffe address is a "magic number" it's the last data sent for a frame of the simulation. If you shift out data without it, your shifting out data for ever byte of data sent from the simulation. In a typical case that means you shifting the same data out 70-150 times every 30ms. This is probably causing you to lose data as the shift routine your using is slow (arduino function are written for safety not speed). Any output updates LCD Screens, LEDs, etc. Should only be updated during the 0xfffe call. Otherwise you're doing it way more than you need to and you're possible displaying incorrect data.

Yes put this in your sketch instead of calling updateShiftRegister in your main loop routine. void onDcsBiosWrite(unsigned int address, unsigned int value) { if (address == 0xfffe) { updateShiftRegister(); } }