George Pollock

I'm using LV 8.6 and Compact Field Point I/O. I use an AI-110 for analog measurements. It would be great to be able to change the measurement scale of the AI-110 from within the running LV app. As an example, try to make a cheap $20 multimeter, the sort you get at the local electronics outlet. If you make a measurement and don't like how it fits the scale, you just turn the knob, select a different scale and get the measurement you want. All this would work in LV except that I find no way to get out to the AI-110 and change its scaling. Doing it one time once, forever, with MAX is not what I am looking for here. I must be overlooking something here. Any help appreciated.

The cFP-1808 module backplane controller has a small hole labeled "RESET" that just begs for a straightened paper clip to be inserted. The question is: (a) What is it that is RESET? (b) To what state is it RESET? and © Now that it is RESET, how do I put the reset values into some state of my choosing?

Sounds like a good plan to me. If you have a long wiring haul, be sure to use twp and keep your returns separate. That is about 90% of noise immunity. Shielding is not as important as it sounds, if you do the former.

I have used a Dell Latitude for a couple of years. LV 8.6 now. No problems at all. BUT, if you have fat fingers like me (are you an adult?) then you will find wiring with a little finger pad is a short-cut to insanity. I got a large diameter Kensington track ball. Works perfectly.

You might consider saving the value that you output in a Global variable. That would save it after the VI that creates it terminates. Also make it available to any VI in your total implementation. It is true that many programmers have a dislike for using Global variables, often born out of ugly experiences in multiple-programmer situations. But, in LV, they are a handy tool, especially since you can have more than one named Global variable set, and thus partition your Globals between users. You can also partition shared values among functions, such as output values, control equation constants, etc.

Your remark that the "multimeter sends data continuously" is a red flag. Some of the older stuff had the idea that computer compatibility consisted of just "hosing" data up the line in RS-232. No dialog, no trigger, just hose the data up the channel continuously. That is an entirely different I/O situation than a more civilized exchange of requests and acknowledgments.

For RS-232 / USB conversions, I suggest you make the acquaintance of "Newegg.com", a supplier of all sorts of computer related stuff. I've gotten a couple of convrtors from them, at something like $35. I've used them to drive a cFP backplane controller with RS-232 from the computer's USB port. That is a good general fix, by the way. There is a lot of legacy hardware out there that has RS-232 ports. And, while your computer probably has an RS-232 port, it is probably only got one. USB expansion ports are cheap, so you can generate as many RS-232 ports, using converters, as you need. By the way, if you are using RS-232, be mindful of the age and original intent of that standard. Do not plan on long cable runs or high baud rates without careful research.

As a general comment, I am doing closed loop temperature control on a LV 8.6 system using "bang-bang" control. PID is almost a "knee jerk" when it comes to control algorithms, but it is a costly item from NI and, at least in my situation, not needed. Not the cost, not the aspirin of working with PID. "Bang-bang", if it doesn't ring a bell, is the way everything in your domestic world is controlled. Your heater, your air conditioner, your toaster, your oven, your electric blanket (probably). The only proportional control I can find in my domestic world is the engine thermostat on the family car. "Bang-bang" needs no analog output, no heavy math. The only requirements are that the process driving force (in my example, the heaters) is not over-sized for the problem and that there is enough time in the process.

Look into your code and see if you are either building arrays by just stacking data on them or you are building strings by concatenation. Both leave you open to inheriting the C problem of memory leakage. Much better to declare arrays of fixed size and then fill them, declare strings of fixed size and then insert characters. More work but no leaks.

If what you want to do is to associate a temperature measurement with some event in the process, try inputting the event as a digital bit somehow. Then sit on the bit and when it changes, grab the next TC reading, and add a time tag. Neville is correct; you are in a domain where things do not happen fast. Use that to your advantage.