y2kiah

Cool thanks. I'm going to start cutting the metal this weekend. I read that aluminum cuts cooler than MDF and hoped this was true, if your bit isn't hot after a job then it must be true. I'll try without the cutting fluid first since it worked fine for you. Thanks for your input. I've seen back lighting done on some flight deck builds where the whole box was illuminated like that, seems to work just fine, but I don't think they used LED strips. LEDs can be super bright but are still lousy at omnidirectional lighting. Try painting the interior of your console flat white to help with that.

Great job! :thumbup: Can I ask what feed rate and depth of cut you used? And did you use any cutting fluid? How do you plan to mount the LED strips to the back plate? Keep up the good work.

very nice Ghost. It's a good structure, I could see building a full pit around it, with the essentials already there from the beginning. It's a good fly while you build solution.

Looking good! Hopefully that sign maker will be up for the job.

Pizzicato, yesterday this is all your post said. I think I get your point, thanks. Can we move on now?

So far I've been using Franklin Gothic Medium on the panels, would be interesting to see how they look in those other fonts though

This has probably already been found but I'm not going to read through 7 pages to find out. In the Start Up training mission, the canopy switch when clicked to close with the mouse moves but the canopy does not close, I had to use the keyboard command to do it. Also, the EAC switch on LASTE panel refused to move at all, even if I move the throttle out of the way. I couldn't go on with the mission.

They fit the standard size heavy duty switches that I have. I guess I can't guarantee that they'll fit the real mil spec switches, but at 25 bucks per switch, I'm not worried about satisfying that crowd. :) I'm using the same process but with #3 and #4 switched, so I clear coat after engraving to seal everything up. I've tested some engraving and it does look very good, but takes FOREVER on the machine with such a small bit. I'm tempted to settle for rounded corners on the letters but one stroke per letter and a larger bit. I'll try that out at some point, but also means I'll have to redo all of my lettering layouts. I use a 1/16" Matte/White engraving plastic bonded to 3/16" acrylic for a total of 1/4" thickness. The Matte side faces up, so the white surface actually sits about 1/32" below the top of the panel. This way when I engrave I'm guaranteed not to completely punch through the white layer. Back lighting looks good with a simple flashlight test. If I were to do LED backlighting, I use 2447 or 7328 acrylic to act as a diffuser, which is the case on these panels. You will need quite a few LEDs with this method though to get even coverage. For my panels, I'm planning on engraving a 1/32" deep pocket on the back side to fit an EL sheet in, and I will use clear acrylic behind the engraving plastic. EL sheet will be expensive but something I'm willing to do one panel at a time. Wow if you can get all your panels lasered in one month for a total of $99 dollars, I would do that in a heartbeat. Pretty cool service you have there, I can't see anything like that around here.

panels cut Hi all, just wanted to give an update before my thread fell off the first page :P The first batch of panels have all been cut, here are some pictures of several of them. Unfortunately for me, but fortunately for someone else, these panels will not find their home in my pit. Sorry for the blurry photos, but my hand was not steady enough. Keep in mind these are not cleaned up yet, the tabs need to be filed down, they need a good washing and light sanding. The first couple shows the top side, these are back-lightable and have a nice high contrast white surface for the lettering. The last photo shows the back side with pockets cut out. Next update will be after painting and engraving. If you are in need of a particular panel or panels, send me a PM.

Can I vote for you developing the HUD first? :) Personally I would skip trying to sell panel plans. You're basically just taking free information, organizing it and slapping a price on it. I'm not sure many will buy into that. I would go right for selling a finished product. The plans have very little value IMO, in fact the community has deemed the value to be in the neighborhood of zero dollars - but the physical object has real value. Anyway, good luck with this endeavor!

sounds like there have been some improvements in A-10C in this area. Should make it easier for builders that don't want to mess with lua!

cool I'll keep you updated. Your BU0836 card works a bit differently since it is a USB HID device, when you plug it into the PC, Windows recognizes it as a game controller. With that card, you would be limited to the normal key mappings available in the sim, and not use Lua at all. If you purchase a card with an RS232, Serial-to-USB, or ethernet connection, it's a lot easier to talk with from the lua script.

Sorry if I lost you, but you're absolutely right, documentation and examples/tutorials are a must. I'll put that stuff up onto the project website. As far as support goes, it would be an open source solution so the community at large would be responsible for supporting each other, no different than OC or others of its kind. I would fully expect early on to answer questions on the forums and clear up any gray areas in the documentation, but after some time the community should be able to pick up from there, even if it's only a few people. I would see my ongoing role as maintaining the code base, implementing bug fixes and suggestions/requests from the community, and putting out new releases. That all being said, I don't think support will be much of a problem, the Arduino community is large and active, much larger than the OC community, and growing all the time. I'm sure this is because it's not so focused on one thing, more of a general prototyping board. This is actually very advantageous to pit builders because we can benefit from the work of hundreds of people that have no interest in building pits, but whose work is useful to us. From the perspective of any 'veteran' on the Arduino, the firmware I create will be nothing more than "just another library," something very familiar to them. Depending on your programming level you would either use it out of the box, no coding (or very very little coding) required, or if you want to get more advanced you can extend it, modify it, or do just about anything with it. In fact the firmware is written with the intention to be extensible, so the community can create and post code for new electronics that they may want to use. I know right now it's all talk until you guys see something concrete. I haven't even really announced it yet, except for this post. I fully intend it to be a turn key solution, complete with a visual development program for configuring your pit controls.

to give you a little insight into how my solution will work (I'm using Arduino cards for my pit) here are some of the components I'm working on: * defining a protocol for communication between the various tiers. I chose to use a very basic ASCII NVP (name-value pair) format. * generic firmware to parse and handle incoming messages, and send control event messages, acts as a TCP client that connects itself to the server * simulator interfacing (or what I'm calling "agent") to provide the connection to simulator software. So in the case of DCS this is a Lua script, for FSX this is a SimConnect program, probably in .dll form, or FSUIPC for older versions, etc. etc. This is also a TCP client that connects itself to the server, but identified itself differently than the firmware client. * TCP Server to accept client connections, contains configuration for the pit, runs all "custom" pit logic with embedded Javascript engine (Google's V8 ) and handles all communication between sim clients and microcontroller clients. A diagram would really explain all this better, but that's for another time. There will also be some one-off solutions, like the A-10's CDU, that don't use the generic firmware but instead use specialized firmware, but still interface with the TCP server using the same protocol. This whole system is essentially the same thing that OC / IOCP / SIOC is, except it's geared around the Arduino / ATMega family of microcontrollers. For my solution NVP protocol takes the place of IOCP, and Javascript replaces SIOC. Already, this is a huge improvement. I encourage others to follow this path which I believe is superior and much more "future proof" than the OC solution. Also cheaper. I know it's a tough sell until people see it in action as a proven solution, all I can say to that is I have already proven the concept through isolated tests, and I'm getting close to releasing the complete solution for all to see and use.

It's just like that, yes. It's a "back door" provided by the developers for interfacing with the sim. I can't imagine it will be much different for A-10C than how it already works in Black Shark, if you're curious about the details, there's a lot of information in the forums about it.

it will be fine, there won't be key commands for all cockpit switches but they can all be controlled from lua script.

I've been going on best information I can find. Mil specs when available, word of mouth next, then by eye or best estimation if all else fails. The side consoles are good to fit real panels. It's the main instrument panel where I'm doing most of my guess work. Bottom line there is that right now I can only guarantee that my own parts fit my own panel. DM has the real parts to go from so his panel will be accurate in places that mine is not.

what do you plan to do about it? have anything in mind? I've been toying with the idea of using the cylinder from an old office chair for height adjust. it would be pretty sweet to hook it up to the cockpit switch and have a screw drive the seat height. I haven't done any design for the seat yet, still using the free model I found.

well the CNC works pretty well within its limits. I need more powerful motors to cut faster, or with deeper passes. Above about 40 ipm I was losing steps when cutting MDF at .1" per pass, causing lots of messed up parts and botched jobs. A few weeks ago one axis on my motor driver went bad during a job, so I had to get a new one and relearn the machine's characteristics with the new driver. I also added a second X axis motor on the opposite side because I was getting racking on the gantry that caused some corners to be not square, and some bumpy edges. I've learned that racking is a pretty common problem on gantry machines, so many have double motors to solve the problem. I've already designed and started building machine #2 which is based on aluminum extrusion, with only a few parts cut out with this machine. It'll be a lot faster, more rigid, with tighter tolerances, and I'll be able to machine metals with it. Here's a couple shots of the new machine design. It's pretty much a copy of the ShopBot, or Joe's hybrid CNC, but the Y and Z axes are improved to give more range of motion. The old driver and motors will be used for a smaller desktop engraving machine. not exactly sure of the cost, let me try to figure out what I spent and I'll let you know

I use the free version. There are a few scripts available (google it) that export to dxf. I open the exported dxf into CamBam and design the machining operations, then export the G Code. The CAM step can be just as time consuming as designing the panel in CAD.

Well I've officially started construction of the pit. I made 4 cuts!!! That's right... FOUR! I know, serious stuff. I'm starting with the right console panel mount surface. I'm using aluminum angle .5" x 1" where the short edge faces up for the rails. J-B Weld bonds the pieces together. The rail surface will fit onto the console ribs and secure in place with screws. This weekend I'm going to cut out some panel light plates (but they're not for me, darn). Some updates to the pit design, more stuff on the instrument panel Pit extended 12 inches for leg room, and a flat surface to mount the monitor/tv. I'll do my best to curve the top edge of the skinning on the real thing. The ADI has room for a 5.6" 4:3 screen, portrait orientation. The HSI will have a 5" 4:3 screen, landscape orientation. I haven't ordered those yet, but I did order a 3.5" 320x240 TFT for the CDU, it fits nicely and is barely smaller than the real screen. This TFT is driven from a microcontroller so no connection to the PC is required. Hopefully ED will export the CDU text line for line, or this solution probably won't work. In that case, any old 3.5" screen will do that can be connected to the sim PC.

yah if this hobby was just about buying things ready made I probably wouldn't like it so much. If I want to drop lots of money I'll just go fly a real plane. I like the DIY aspects the best. It is what you make it - it's flight simulation, it's (life size) scale model building, it's collecting (real panels and stuff), it's electronics, computer programming. So many disciplines rolled into one. Some just want to have a pit and don't really want to build a pit though, and I respect that too.

I hear you. I didn't mean to say that it's a problem that doesn't have to be solved. On the contrary, I believe it's a problem that *always* has to be solved, and in that way it's not really an issue, more of an inherent part of pit building. It really has nothing to do with option 1 vs. 2, it all comes down to the sim command being a toggle. However you interface your switches, if you only have a toggle command available, you will need to solve it with scripting trickery. I'm not really convinced option 1 in this case is the "simpler" of the two because assuming you want the pit to work right, it actually becomes more of a hassle than just using Lua. Option 2 doesn't solve the problem for you, but it's a convenient place to create your solution. My comment about systems staying on or off with the first flick was clearly assuming that the switch sync problem HAS been solved - just pointing out that start up conditions don't matter much as long as the switches work right.

I use the same font on all of my panels, some are stable some aren't. I think it's mainly just a Z buffer issue. When I look at some panels open by themselves the text is rock solid, but the same panel incorporated in the large pit model shows z fighting. Best I can tell it has something to do with the way the text was placed, and how it is dragged after being placed. When placing text directly onto a surface it's usually fine. If you use the measurement tool to place it at the intersection of two lines, it can cause problems. If you move the text only along one axis at a time, it stays fine. If you move diagonally or along multiple axes in a single motion, it causes problems. I fought with it for a long time trying to place the text right, then it turned out not to matter because as the pit model got more complicated, more z fighting started to show anyway, so I stopped trying.

There's no problem with using both methods. Start out with option 1 and when/if you reach a limitation of that method and you want more for your pit, you can incorporate option 2. About the uphill battle, you'll find lots of help on this forum and a solution will certainly be posted that you can take advantage of. Most likely you will only need to copy files and edit a few lines of code to get the lua solution going. Also, I'm not sure why there is so much worry out there about out of sync"ness", but It's really not an issue. Any card you use whether its Leo's or OC or some other solution will let you hook up switches in such a way that you get unique events reported for each switch position. Then you would NOT map the events to "toggle" commands but instead use discrete commands like the equivalent "up / down" if available. If only a toggle command is available, use Lua to loop a toggle-query until the desired position is reached if a query is possible. So option 2 potentially could save you there. Sure it's possible that some switches will be in the wrong position at start up, but as soon as you move the switch once the problem is solved. Look at it this way, if the switch is off but it's supposed to be on, just flip it on and the thing it controls will stay on - no harm done, nothing out of sync. If the switch is on and it's supposed to be off, flip the switch off and the thing will stay off.