ShaunR

Ahhh. But you can. Consider the lilly a tank that requires 10 litres to fill completely and all we have is a valve that only has 2 positions (open and closed i.e. digital control). Our hypothetical tank is (say) being drained at a rate of 1 litre per minute however, our valve, when fully opened, is capable of supplying 2 litres per minute. If we open that valve for 10 minutes then we will fill the tank to the brim and it all gets rather messy, what with the overspill and everything. However, if we open the valve for 30 seconds, we will supply the tank at the same rate as it is being emptied (on a minute by minute basis). Now. the problem is, in all probability there will be times when there is nothing in the tank (due to timing differences, magic and the law of jam-butty) . So its desirable to open the valve for (say) 40 seconds so there is always more than is being consumed. Ultimately the tank will fill so as we approach the a pre-determined limit we want to switch back to 30 second "pulses". We haven't changed the magnitude of the output (the valve can only be on or off). But what we have done is opened it for more or less time. We have "pulsed" the valve and by changing (or "modulating") how long we keep in open for ( "width" of the pulse), controlled the system and we can all go home . For the above, PID control is simply a calculation (derived from the current level in the tank) that continuously calculates how long we leave the valve open for to achieve and maintain a desired steady state (a level in the tank).. What it gives us is a continuously varying duty PWM signal (which is varying at the sampling rate) , where the period is 1 minute and has a steady state at 50% duty cycle (30 seconds). It doesn't really matter what interface we use to control the valve itself (analogue, digital, a hammer or telekinesis). Just as long as we can open and close it for an amount of time the PID algorithm tells us to.

Nope. Since you are still advocating that the type control interface is implicitly linked to the process. Ovens and kilns, for example, use contractors, SSRs and normal relays, all of which are digital. NI have an example of PWM PID control for their FPGA boards.PID Control Reference Example for LabVIEW FPGA They also have a note on their PID autotune function from the PiD control toolkit which uses a relay PID Autotuning VI and Limitations (it uses Ziegler-Nichols apparently ) But I suppose I'd better answer the OPs original question Choosing PID parameters is a bit of a black art. Manufacturers of PID controllers all have their own algorithms for determining the P, I and D terms (usually called "Autotune") and generally they will be biased to their particular industry and products.. One thing they all have in common though, is that they will analyse one or more step functions as you have seen with the Ziegler-Nichols. But it is worth bearing in mind that this "Autotune" is not a magic bullet. It is a "first best guess" and time will still need to be taken to optimise for the particular process. So. If the manufacturers can't get it spot on for every process. Then I don't think we can expect to. You've read up on Z-N (if its good enough for NI then its good enough to start with eh? ). and its probably time to bite the bullet and see what happens. Use your calculated values and log the tanks (level?) process variable. Start off by using a low setpoint so you don't overfill and inspect the log record to see how much overshoot, ripple and offset there was (you never know, it might be acceptable as is!). You've been wise enough to install a manual valve so if things go really askew you can just shut it off. If you didn't have any problems, Increase the P a large amount and start running for that valve:lol:

PID is designed to control a process to alleviate overshoot, ripple and offsets. It has little to do with the interface. Indeed. First choice is always an on/off controller (they're cheap and easy). But the choice on this type of control depends on whether the process can tolerate overshoot and ripple rather than digital or analogue. Some processes that have significant lag or asymmetric properties cannot be controlled at all this way.

KEY_READ

Error -604 is "Access Denied". Its probably the UAC (User Account Control) which was first introduced in Vista and consequently first disabled in Vista . Try disabling UAC and see if that helps. Disabling UAC

Sweet. Thanks for clarifying.

Hmmm. Does that mean you would have 2 repostories one for packages and one for zip files? Or do you mean that you will not accept a submission UNLESS it is packaged for VIPM?

How would you handle the submissions to the LAVA repository that aren't packaged in a VIPM distribution?

Better put in a capital req for that 42" LCD TV monitor.

At the risk of tryin' to walk with both feet in mouth. Maybe he means something like this?

Sales and Marketing: Engineering:

6 Sigma analysis.Anything greater than +- 3 standard deviations from the mean (or in this case +3 STD). Works well for these waveforms.

Works fine on both x64 an x32 using Win7 and Vista ( once I'd replaced all the ogk stuff )

Buy me a MAC and LabView for MAC and Linux and I'll tell you BTW. No problems changing the icon back again?

How about "Eric"? That's a good solid name.

Change the "uType " to "1" (icon) instead of "0" (bitmap) and load an ".ico" file.

Name: OPP Push File Submitter: ShaunR Submitted: 29 Aug 2010 File Updated: 03 Jan 2011 Category: Remote Control, Monitoring and the Internet LabVIEW Version: 2009 License Type: Other (included with download) OPP Bluetooth is a partial implementation of the OBEX Object Push Profile (OPP) demonstrating "pushing" a file to a bluetooth device (e.g. mobile phone). Installation: Unzip to a directory of your choice. Required Packages: Labview 9.0 or greater. Transport.lvlib (included). Bytes2kbits.vi (included). Elapsed Time.vi (included). Filter EOF Error.vi (included). Percent.vi (included). Rolling Average.vi (included). Str To UTF16.vi (included). UTF16 To Str.vi (included). Known Issues. None. Contact: PM ShaunR on lavag.org (http://www.lavag.org) Versioning: Version 1.1 Added more mime-types see mimetypes.txt. Changed the default mime-type if file extension unknown. Changed from sending nothing to sending as "application/octet-stream" since some mobiles require a type. Added more vi documentation. Changed the transport layer to use transport.lvlib. Knowledge of the channel number no longer required. Changed the default payload size. Changed to 8192 since my HTC Desire doesn't like 14273 ) Added/clarified licensing/copyright. Version 1.0 Initial release. Initially release on the old lava website. Click here to download this file

Name: Transport.lvlib Submitter: ShaunR Submitted: 30 Aug 2010 File Updated: 27 Aug 2011 Category: Remote Control, Monitoring and the Internet LabVIEW Version: 2009 License Type: Creative Commons Attribution-Noncommercial-Share Alike 3.0 Transport.lvlib is a LabView API to simplify and accelerate networked communication development. It simplifies development by abstracting TCPIP, UDP and Bluetooth interfaces into a single polymorphic vi which is a thin wrapper around the conventional open, read, write, close and listener VIs for all the network interfaces. It removes dependency on the underlying hardware transport protocol and provides a uniform application interface enabling abstraction of the application from the interface. Features: Supports TCPIP, Bluetooth and UDP (p2p, broadcast and multicast) interfaces. Supports encryption (blowfish). Supports zlib compression (only on platforms Win32, Win64 and linux 32) Installation: Unzip to a directory of your choice. Add the supplied .mnu file to your palette. Required Packages: Labview 9.0 or greater. labview_blowfish_encryption library (included). Known Issues. None. Versioning: Current version 1.0. See changelog.txt. Contact: PM ShaunR on lavag.org (http://www.lavag.org) Credits: Thanks to Tad Taylor for releasing he blowfish encryption library to the community. Click here to download this file

It is a single diode which, by itself, can perform half wave rectification . The terminolgy of "rectifier" and "diode" in single diode AC->DC conversion is purely symantics. You will need 2 of them if you are using a center tapped transformer or 4 (more usual) for non- center tapped. Rectifier

Try turning "Trace Execution" off altogether. I know you say that your "Trace Execution" is not set to slow, but this phenomina existed on even the earliest versions when the speed option wasn't available.

An in a similar light to MikaelHs question. Are you using a termination character to detect the end of string (and if so which one?)?

Zip files have a checksum built in. You get warnings/failures if the file is corrupt and you try to extract. Most text files are MD5 hashes which is more of a test of trust than corruption - to ensure the file downloaded IS ithe file you are expecting..

Not currently. But it does support custom run-time main menus The "Example Use.vi" uses a custom menu