I am building an engine run system in Labview 2009 with a PXI controller talking to a Delta Motion controller and a Parker Aries drive. I think most of that is irrelevant to this question, though.
I need to move a throttle. I built a control that looks like a throttle lever. I can move it with the mouse to extend a linear actuator that will be hooked to the throttle. It looks great and works great, but I am still uncomfortable with it. I think I would prefer a real lever controller in my hand as opposed to the mouse. I've looked briefly at USB hardware that is used in flight simulator games, and like the idea, but am not sure how I would implement it.
I found an example that uses VISA to translate the movements of devices that I think are similar to this, but heres the problem: if I use the lever, it will have to be plugged in to a computer that is not running labview, but is connected, via Remote Desktop, to the controller in the PXI chassis that is running the VI.
I have no idea if this is easy, hard, or highly improbable...?
This can be done, first off. It should not be that hard.
There are a few things that I would ask first however.
How critical is the throttle control (if it did't work sometimes or was slow would that be ok)?
How fast are you going to need to update the throttle position and if you miss one is that important?
Things to think about.
When you do remote anything it will take longer for things to update
There is a chance that the communication will not be recieved for some reason so you will have to have a hand shake system in place.
If something is time critical or safety then I would not reccomend remote via another computer.
That was my feelings at first about the remote desktop connection, but I have already run a fairly time critical control system over this dedicated network with no troubles related to the connection. Now when I say time critical, I'm talking a 100 ms update rate at best. I can live with 2 - 3 times that.
Not working sometimes is not an option. A little slow, or missing a point on the throttle sweep are not as big of a deal.
This is actually a combined control and acquisition program, acquisition being maybe more important than control. There are other direct wired safety overrides to shut down the engine in the event of a major control system malfunction. I bring up the acquisition because this is the reason for wanting the PXI system (with the embedded controller talking to the Delta and Aries drive) close to the engine. I don't want 600 foot runs of coax going to my 6133 cards in the PXI for data collection. I must be a few hundred yards away from the engine while controlling it. I cannot come up with a better way to do this than using remote desktop to control the embedded computer in the PXI? I am also stuck with the embedded controller, rather than a computer controlling the PXI over fiber for a couple of reasons.
I'm thinking that one solution is to dissasemble a roller ball mouse and turn it into a throttle lever, then use it in conjunction with a regular mouse to move the cursor around. I would just choose a keyboard key down to disable cursor clicking and then follow the roller balls mouse position. But I would much rather buy something better sutied to the task.
What's wrong with a simple linear potentiometer (long stroke type one such device is http://www.etisystems.com/lcpl.asp this is also avialable from Farnell) offering a 0 to 10V signal fed in to the daq? if noise pickup is going to be an issue from the throttle lever consider changing the 0 to 10V signal from the pot to 4 to 20mA then back to voltage at the DAQ.
What engine is it and have you limitted the rate of change on the fuel metering actuator in software otherwise a slam check could over fuel the engine or cause it to surge if its a gas turbine/ jet.
If you have a spare DAQ card for the throttle lever put it in the remote PC and let the remote PC communicate with the PXI rack using eithernet although getting 100Hz loop rate with Windoze in the loop will be a challenge - Mike
You can always excite a old sewing machine foot-pedal and use it as a AO resource to control your actuator. Certainly, monitor the footpedal output with your applcation for feedback purposes but, I'm not a real fan of drive-by wire.
Thinking of it this way..... An internal combustion engine (by definition) contains and controls explosively energetic reactions. Thus the control system must be fail safe! a LabVIEW numeric control would need some pretty hefty processes in the backround to fail in a safe (unthrottled) condition.
Like I said, the "pilot" will be sitting at a PC or laptop that is not running Labview, so a linear pot will not work. I am only looking for about 10 Hz (100 ms). I have not come across any rate limitations on moving the throttle of a jet engine. I've seen one get shoved (accidentally) from idle to wide open throttle quicker than I can do with my actuator, and it took quite a long time for it to lumber up to speed. Did not appear to have any adverse affect? These are mechanically fueled engines, so all I'm doing is moving the throttle lever, not replacing the FADEC.
As far as not being a fan of drive by wire, I don't like them in cars, but on this application, it's the only option. And like I said, there will be hardwired safety overrides.
I found in another post something I had forgotten. Labview is able to read joystick commands. Also, I don't have the joystick yet, but I used the similar mouse VI to successfully read mouse commands over a remote desktop connection. I hope the joystick will work similarly. I have ordered a CH Pro Throttle USB controller and hope to get it by the end of this week...