Gadroc

As metalnwood says its more than a parallel port in fact I would not call the UC100 a USB to Parallel interface per say. Yes it's USB and has a DB25 on the other end, but it's not a parallel port to the computer. It's a microcontroller that handles sending pulses to the stepper. To use it you need CNC software that knows how to specifically talk to the UC100. That's either Mach3 or UCCNC.

Yes, the UC100 is an alternative to ESS SmoothStepper. It was cheaper than SmoothStepper at the time I was putting together the shapeoko. UCCNC is supposed to have a better trajectory planner for constant velocity mode than the older Mach3. Saw some videos of the same machine running Mach3 and UCCNC and it was much better. Upgrading to Mach4 was going to cost me $$$ so I gave UCCNC a try. So far I'm really happy. Never got the shapeoko dialed in as it's mechanical problems showed up to soon, just got the ox dialed in and I'm likely to slip into ain't broke mode. At least till I get into tinker mode again.... always have ideas on upgrading. That being said getting the spindle squared to the gantry is pain in the #$!@%.

Work area depends on the machine design. The gantry design, plate design, dust shoe, etc... all can affect how close the cutting bit can get to the extremes of the machine. My machine (OpenBuilds OX) I have a 800mm X axis linear rail but only have about 620mm travel on it. This is because the plates that the motor mounts to are far wider than the cutting tool ;). On the Y axis mine is 1500mm rail with about 1255 travel, as this dimension has to account for the X linear rail and the spindle itself. I have a UC100 coupled with a Gecko G540 to drive my machine. I used it with Mach3 but have switched to UCCNC. I would not recommend Mach3 anymore, it's very long in the tooth and may or may not work on current hardware. Mach4 doesn't seem to be as stable and there are a very small number of motion controllers which are all expensive. UC100 + UCCNC is about $200 where Mach4 + Motion Controller is about $400-$500. I have not tried linuxCNC. I wanted to have a hardware based motion controller vs PC based and I have not researched what hardware is available for linuxCNC.

Yep. It's an AVENGER 180 setup. I've done some initial warping config, but need to get the pit recut some my eye point is in the right position. Current pit has the front panel about 3-4" higher than the real thing. That along with dropping about 6-9" from beneath the seat will put my eye point right in the sweet spot for the 180 degree screen.

Got some new toys in.... Need to put a hydraulic kit on the pit do drop it down to the rims putting my head in the right position for the screen. Spent this weekend rebuilding the CNC so I can start cutting out the new seat cradle and front panel.

You can't send the same TCP stream to two computers. Each will have to have it's own connection and DCS-BIOS will have to send data to each client. I think phasing out UDP is a bad idea for this reason. TCP has significantly more overhead and then your are adding additional overhead per client. While this overhead is small in the grand scheme of a big computer, it does add up when you are talking milliseconds between transmissions. The overhead is huge when dealing with low power micro-controllers. You can do UDP without multi-casting, which is what Helios export was setup to do by default. Default to just sending UDP packets to localhost or default to TCP, but don't remove the UDP capability.

The socat tool in the repo will not work under windows 10. It needs to be recompiled with a newer version of the mingw64.

Looking good! I love how once you have a laser cutter everything can be built out of stacks of acrylic :thumbup:. I'd be willing to bet that was my drawing of the landing gear handle. Gadroc

Let's just assume 40 discrete devices (gauges + panels). Let's add up the cost differences, I've excluded items that would be the same and these are rough costs. [TABLE]Item|Each|Qty|Line Cost Pro Mini Arduino|$3.99|40|$159.60 RS-485 Chip|$1.60|40|$64.00 250ft Bulk Cat 5e Cable|$37.99|1|$37.99 PC Power Supply|$75.00|1|$75.00 [/TABLE] RS-485 Total $336.59 + (Protoboards, LEDs, Switches, IO Expanders, etc...) [TABLE]Item|Each|Qty|Line Cost Arduino UNO|$5.99|40|$239.60 USB Cables|$4.99|40|$199.60 7 Port USB Hub w/ Power|$14.99|6|$89.94 [/TABLE] USB Total $529.14 + (Protoboards, LEDs, Switches, IO Expanders, etc...) One of the nice things about DCS-Bios is it's simplicity. All devices get broadcast all data and can relay back arbitrary commands. This allows you to just plug in a device with out having to configure / install new software on the sim computer. All of the "smarts" are at the panel / gauge. If you keep that paradigm, you're going to move a LOT of communications burden to the simulation computer. Assuming we stick with simple arduino sketches that's 40 serial ports relaying DCS Bios information. You can go HID devices, but that means you are going to have to flash the secondary serial controller on the arduino and stop using the default bootloader. You still will need to manage 40 connections and relay all DCS Bios information to all of them. With the RS-485 solution you have a very simple solution comparatively, to talk to all these devices through one nice and simple serial port. Discrete USB only works in my opinion with all the smart in a middle ware controller like Helios. Which means more programming on the PC side and a generic as necessary only communication protocol with the devices.

It looks like they are for the lock washer. There is a washer on the real switches that slot into those tabs. It prevents the switch from twisting.

Do the math on power draw on these boards. The wires inside a ethernet cable are 26 - 28 AWG and can not handle much current. If you run power through the daisy chain cables the first boards connectors and run of wire will have the total current for the entire daisy chain running through it.

I concur. I've read several things along the same lines and even reports of termination hindering shorter runs. My plan has been to create "termination plugs" off the PCBs which I would plug into the last devices on the chain if it became necessary.

Unfortunately I don't think it's trivial to measure existing cable. If you're using Cat 5 / 5e /6 the impedance is 100ohm. Before buying the twisted pair for the pit I'd make sure it has a specified impedance from your vendor.

Termination resistance value is based on the impedance of the cable you use. RS-485 spec typically calls for a cable with 120ohm impedance, but I use cat5 network cable which is 100ohm. You only terminate on the extreme ends of the chain. So you should not solder termination to the board. Make it removable so you can add new boards to the end of the chain. See the following guide: [ame]http://www.ti.com/lit/an/slla272b/slla272b.pdf[/ame] (Ugg I must say the forums auto embedding of PDFs is annoying.)

Also you should only update the display on a frame end, unless you move to the newer library Ian posted.

You're problem is the baud rate. 500k baud is to fast for the Arduino to keep up with. Change Serial.bevin(500000h) to Serial.begin(250000) and make a similar change in the software you're using to relay dcsbios to the serial port.

gadrocsworkshop.com is back up

All true. It's also on my list to redesign my panel control board to have the pro mini's plug into it.

See my reply to IAN. I recommend no more than 32 devices on a 250k baud RS-485 bus (an arduino can not keep up with anything faster, so this is the limit unless you move to ARM based arduinos). Leave yourself head room for errors and slow devices. For me it's easiest to think of the cockpit as three different USB devices that can be plugged and unplugged independently. I suspect a arduino mega will have problems running 3 buses at once, but I haven't tested it. I have one here and intend on doing it, just haven't had the time. The 32 devices per bus I've definitively tested and have the math to back up. There is some overhead in the computer proxying DCS-Bios to 3 serial ports, but I don't think it will be significant. You can always put another cheap computer (raspberry pi) which listens on the network for DCS-Bios and runs the serial ports. I happen to have a raspberry pi in my pit already displaying the HSI on 5" monitor so it handles the serial ports so the sim computer is not burdened. It is important to note a few things about my comments: 1) my testing is all with my arduino library not IAN's new one, but most of the timings are based on defensive design and bus timings not the code. 2) I'm approaching this from the perspective of a full cockpit with several hundreds to thousands of IO lines. Ignore most of my concerns if you are wiring up a handful of devices. Most of this stuff is tremendously easy at small scale, but bites you in the ass at large scale.

You really have two options for running your cockpit. Home Run Wiring In this scenario you have large IO boards with 100s of inputs each. You run a large cable to each panel with enough wires for every switch on the panel. Here are some pictures of the kinds of cable harness you'll end up creating. Pros Simple to understand as you're getting started Fewer IO boards and less complicated electronics Many examples (Bodnar boards, EPIC, etc...) most pits have been done this way in the past as the micro-controllers where complicated / expensive. Cons Inflexible. If you later want to enable more functions on a panel you have modify cable harness at both connection to IO board and connection to panel. Changes make mapping harder later. Mapping IO board inputs becomes complicated, unless you plan really well up front and don't have a panel with inputs all over the place Hard to trouble shoot, requiring careful diagramming and labeling. Documentation will be key and keeping it up to date is crucial Often requires you to design "break out" pcbs to make wiring easier (often removing cost advantage) Distribute IO Boards Have a micro-controller at each panel / instrument and run a network (I2C, RS-485, Ethernet, USB, etc..) of them to the PC. Pros Cabling is much reduced. Wires to each switch terminate at the panel itself and only power and network cables come out of the panel. Cabling is standardized and interchangeable making it easier to troubleshoot. (Power is always power and all network cables are the same) Flexibility. Upgrading a panel does not affect any of the other panels at all. If I add more switches or an led it only has to be wired in that panel. Cons Higher up front cost for micro-controller and circuit boards at each panel. (although bigger pits it will come out in the wash as they require so many break out boards and expensive high pin count connectors) More complicated electronics. You need to be willing to learn at least a little about programming micro-controllers to make it cost effective.

This is bad practice and will lead to problems. I realize some of the libraries distributed with arduino do this, but it's still bad practice. The arduino IDE may not recompile the library if you change your defines in a sketch. It has no way of knowing the last compile of the library was invalidated by your change to your sketch. So it may not recompile the library and use a already compiled version with different define settings. You should treat libraries as DLL which are compiled once and distributed, not as code snipets which are included in a sketch build. The only thing that defines can be used like this are changes in board / processor. The arduino IDE / build chain will properly keep track and recompile all libraries when you switch to a different target board. Some more explanation here. Some of the reasons it looks like you did this (bypass native serial stack) are not necessary anymore. With 1.5+ of the libraries they switched to bytes instead of ints, and fixed flush so you can properly implement a fast RS-485 using them. You can look at my arduino library for examples.

I looked at that but didn't end up pulling the trigger... It supposedly does some 3D mapping of the object it's engraving/cutting. This will allow it to automatically adjust focus across non flat objects and automatically detect boundaries of your object to accurately position engraving. That's really it's only claim to fame as far as I'm seen. Mind you that is a huge timesaver and awesome if it works and remove some of the mastery phase of using a laser. I'd be nervous about their filter. It's cheaper than anything I've seen by a factor of 2 at least, and has significantly less volume as well. Either they are far more lax on their requirements or they have outdone existing companies that specialize in air filtration. I'd bet on the former. As to the CNC killer that's just marketing. It's able to 2D engrave and cut. It will not displace a 3D printer, mill, gantry router or lathe. They all can make different things and have different capabilities. With just a laser you can still make some incredible things out of many thin sheets with profile cuts. If all you have is a hammer everything is a nail... but there are other tools that do some of those things much better.

I'll get the arduino code working. I think I sent you address information before. Let me know if you need it.