Labview PID control for virtual CNC lathe

i am currently in my third year at UMIST, on the Mechanical Engineering (MEng) course. I am designing a control system for a miniaturised CNC lathe for my 3rd year project. For integration between the computer and actuators, i am planning on using Labview 7, but am currently having problems learning how to utilise the PID control toolset to create a virtual system response. I am planning on being able to input a specific transfer function for, say, a DC motor, and a ramp input, for example, and being able to view the output response as i vary the P, I and D gains. Some help with regards to the block diagram set-up for such a system would be greatly appreciated.

The best place to look for this kind of information is the shipping examples of LabVIEW. Open LabVIEW >> help >> find examples. Another good place is online. Go to Advanced Search and look in the example programs.

Similar Messages

  • Basic PID control for LabVIEW 7.0

    I am trying to find the basic PID control VI in my LabVIEW pallet. I thought that there was some PID VI's in 6.1 but I can't seem to find them in 7.

    Hi Dan,
    I don't think we ever put the simple PID in the pallet. However, if you'll run the NI Example Finder (Help>>Find Examples...) and search on PID, you'll find examples that use the simple subVI.
    Best Regards,
    Doug Norman

  • Pid control for mydaq

    Hello,
    I am writing to know can you please help me. I am trying to writing a PID control programme for a water level control project I am doing but when I use labview and select a daq assisitant it does not show terminals onit therefore I cannot wire it up. Can you please help to rectify this.
    Solved!
    Go to Solution.

    moonlightingelec wrote:
    Hello,
    I am writing to know can you please help me. I am trying to writing a PID control programme for a water level control project I am doing but when I use labview and select a daq assisitant it does not show terminals onit therefore I cannot wire it up. Can you please help to rectify this.
    Am not sure why you are searching the PID terminals in DAQ assistant. Are you using any LAbVIEW PID module?
    The best solution is the one you find it by yourself

  • PID control for student 2010 edition

    Hi I need to get a pid controller for a project i am completing in college , is there a pid controller that can run on this verson of labview ??

    PID Controller is nothing but a mathematical calculations. My suggestions is stretch yourself and try duplicating the PID contollers into LabVIEW.
    The best solution is the one you find it by yourself

  • I need to maintain a temperatur​e profile for my process.Ca​n i use PID control for this applicatio​n?

    Hi all,
    I need to maintain a temperature for my process.Can i use PID control vi's for this application?
    I have NI-PCI 6023E DAQ board.Should I need any other hardware components???
    Any help in this regard is highly appreciated.
    Thanks,
    radhika

    Hi,
    Thanks for your reply.
    I do have a temperature sensor and it is read by the DAQ (NI 6023E) .
    Also i have a voltage input to the program which has to be controlled in order to control the temperature.
    So , I am using a PID , the output of the PID should control the Voltage input so that the temperature is controlled.
    Can I give the  voltage input and the temperature  to the PID through the DAQ and  just use one more channel in the DAQ to get the output from the PID.Will that work???
    I am not sure why you have mentioned SC2345,SCB68.
    Thanks,
    radhika

  • PID control for a sinusoid

    Hello,
    I have written a program that takes a reference signal, and then uses a
    proportional control to synthesize a similar signal in a wire coil. I
    modulate the duty cycle of the counters of a PCI 6224 card. One counter
    goes to  the positive side  of an H Bridge, and the other to
    the negative. I'm getting decent results for reference frequencies of
    about a hz, but if I go below that I start seeing more interesting wave
    forms (the funkiness appears when the waveform crosses zero). I am
    questioning whether adding integral or differential controls are liable
    to improve matters given the time dependence of the system, and how to
    best apply them if appropriate.
    Attached are my program and the results it gives for several
    frequencies. Most of the missing VIs are those that record the data to
    file. The other is the proportional controller from the PWM Counter
    Output example, taking the reference signal as its setpoint. (It also
    adds .5 to the duty cycle from the P output. If at the setpoint, I want
    the current in the coil to remain constant)
    Thanks,
    Elliot
    Attachments:
    Amplifier.vi ‏229 KB
    generated waveforms.pdf ‏57 KB

    Hey, are you using the PID toolkit in LabVIEW?  If so, this link: http://www.ni.com/pdf/manuals/372192a.pdf, discusses using interregnal and derivative terms.  It is possible that your system just can't do frequencies below that.  Personally, I have found the best way to figure this stuff out is to just try.  Also, consider using the PID gain scheduling VI.  This will let you have different P, I , & D terms based on an input.  I have found that a very useful tool.
    Hope this helps!
    Dan
    Daniel Eaton
    National Instruments
    Systems Engineering
    Embedded and Industrial Control

  • Output of LabView PID Control Toolkit

    I am evaluating LabView to tune a PID loop.  From the datasheet, it looks like all of the analysis tools are there.
    I am not clear on the output.  Does it have a synthesis feature to create C code?  Or is it just a matter of plugging the tuning coefficients into an existing library. 
    I ultimately want to port this to an ARM control module.

    I'm not sure I understand what it is you actually want to do, but LabVIEW is not an analysis tool. It's a programming environment which happens to be geared towards analysis, so it has a lot of analysis tools shipping with it.
    LabVIEW has an add-on control toolkit, which includes some PID functions, but those are written in the language itself and I assume you can find similar libraries for other languages as well. It will not generate C code - the LabVIEW code is compiled to machine code and is then run using a run-time engine on targets which have support for the run-time.
    LabVIEW does have a couple of modules which translate the code to C. One creates the C code so that it can be run on Windows Mobile devices, but it doesn't give you access to the code. The other is quite expensive and is targeted at embedded targets. I'm not sure, but I think you do get the C code resulting from that one. Being automatically generated code, though, I assume it's not very usable.
    If you have a background in C, you should probably use it. I believe eVC is available freely from Microsoft and I believe it should compile to ARM processors. That said, you can also download LabVIEW and run it for 30 days in evaluation mode.
    Try to take over the world!

  • PID-Control (Tank Level)

    Hi!
    I want to realize a PID-control for a tank level. I've already looked at all related examples in LabVIEW, but I have a general question:
    Where is the measured value brought into the process (where would I connect the DAQ to the control-loop)?? I can't figure out how it's done in the examples (there is always an "initial value" outside the while-loop)....
    Would be great to get some answers!

    Generally you take the DAQ value and feed it into the PID as the process variable.  The examples store the process variable in a shift register in order to simulate a system in which the current value depends on the previous value, but in a real system the physics of the system handle that for you.  For example in a tank control system, the tank itself holds some amount of liquid, which doesn't change by a large amount within one sample period.  To simulate that properly you need to store a value equivalent to the liquid volume in a shift register.

  • Throttle body PID control using pulse width modulation

    Hello all,
    I am trying to do a PID control for a throttle body (using pulse width modulation) for a set value of feedback voltage. The process variable is the pulse width duty cycle. The throttle body is expected to be fully open at a feedback voltage of 5V and pulse width duty cycle of 42.5%.  When I use the highlight execution using the attached file, I can see the throttle body fully open (the values observed are: PID output 42.5 %, feedback voltage approximately 4.7V). However, when the highlight execution is unclicked, the throttle body flutters in the closed condition (still PID output 42.5%, feedback voltage approximately 0.9 V). Can any one please help by suggesting any modification to this attached file to make this throttle body respond to the set value of feedback voltage.
    Many thanks 
    Ajith
    Attachments:
    Throttle body control using PWM technique - PID.vi ‏525 KB

    How did you determine your P, I, and D gains? If you have not tuned your controller, you'll get poor performance. Running with execution highlighting will slow down the execution, which will change the effect of the gains. I would start with pure proportional control (I and D = 0) with a small proportional gain, and see if it responds in approximately the way you want. If so, then your code is probably correct, and you just need to do a full tuning to get good performance. There are many resources available on the web, on this forum and elsewhere, for PID tuning. Note that since your code uses a simple PID example, and not the one from the PID toolkit, the gains do not have the units that are used in many tutorials so you'll have to correct the calculations to compensate.

  • I have a big delay in my real time pid control

    hi ,
    since i don't have a digital input module i tried to use the serial port RS232 on my Crio to read the data from an absolute encoder in order to perform PID control for  a dc motor, but the problem is that the data took too match time to be read; there is a big delay between the first read position and the next one,and when i change the slide controller the indicator took time to change, although it should be instantinouse, here is
    a snapshot of my vi. 
    please i need help.

    Hi Moho,
    Looking at your code I see a couple of things that might be causing the issue. How long is the delay that you are experiencing? You are trying to transfer 2000 bytes every loop which will cause some delay. You also have a lot of mathematical operations that can take time between loop iterations. Also what is the VI that you have manipulating your waveform? Have you looked into the PID VIs?
    Scott B.
    AE NI

  • PID control in a windows CE Labview application

    Hi there,
    I want to build an application that will control the temperature in some ovens, using PID control. The application will be running in a controller (or a touch panel computer) with windows CE OS. I have Labview 8.6, PID control toolkit 8.6 and Touch panel module 8.6. The problem is that the PID vi's don't seem to work in touch panel module. 
    Is there any way to implement PID control in a windows CE Labview application?  
    Thanks in advance.
    Solved!
    Go to Solution.

    I think with a timed loop you can run reasonable good timing down to 1 mSecond. I think 1 mSecond is the lower limit for non realtime systems like Windows/windows CE. And if you have the PID toolkit this will supply you with the functions you need. You do not need an extra CE PID toolkit. This because  the touch panel module run under your standard Labview environment. But I do not know if all the functions in the PID tool like fuzzy logic are compatible with CE. Have you also considered Windows Embedded as OS for your module. With windows Embedded you can run standard Labview built exe files
    Both Windows Embedded, and XP Embedded can be trailed
    http://www.microsoft.com/windowsembedded/en-us/products/westandard/default.mspx
    Besides which, my opinion is that Express VIs Carthage must be destroyed deleted
    (Sorry no Labview "brag list" so far)

  • Toolkit for feedback system? Motion; PID; Control/Simulation???

    Hi, I have to develop/program an organ bath system - a feedback system mimicking real sinusoidal breathing oscillations (shown in attached images). I have NI Labview 8.5, NI-Motion 7.6, a linear motor (M-235 DC-Mike actuator), an MID-7654 Servo Power Motor Drive and a pressure transducer. I believe I will need to control the PID controller and am aware of the PID Control Toolkit as well as the Control Design and Simulation Toolkit for NI Labview. However, is it possible to control the system using the NI-Motion software I have at the moment? If not, do I have to purchase both the PID and Control/Simulation Toolkit or just one? Thanks in advance...
    Attachments:
    feedback design1.JPG ‏25 KB
    feedback system1.JPG ‏42 KB

    Dear Garry,
    Do you have a motion controller to interface the MID-7654 to your
    computer and LabVIEW? This would be the PCI-734x or PCI-735x. If you
    do, I believe that you could implement your application with LabVIEW
    and NI-Motion. You could do so by using the analog feedback feature for
    the control loops for each axis. Then, you could specify the optimal
    sinusoidal moves/pressure patterns that mimic real breathing patterns.
    The analog feedback from your pressure transducer will be used during
    the move(s) to maintain the pressure that you want.
    Please see Chapter 13 here for more details:
    NI-Motion User Manual
    http://www.ni.com/pdf/manuals/371242c.pdf
    Here is also a good discussion forum post on Analog feedback:
    Can i use NI-7358 to implement a hybrid position force/torque control system?
    http://forums.ni.com/ni/board/message?board.id=240&thread.id=2976&view=by_date_ascending&page=1
    I believe that the above option would work for you, and you would not
    have to use the Control Design and Simulation Module or the PID
    Toolkit. Please let me know if you have any additional questions. I
    haven't actually set up a system with analog feedback from a pressure
    transducer before, but I believe that the above would be a very viable
    option.
    Best Regards,
    ~Nate

  • PID Control Labview 7.1.1

    Hello, I have successfully created a PWM controller for my application
    and built a simple proportional controller into creating my pulse width
    output.  This got rid of the basic "drifting" problem of my device
    output but now a new problem concerning steady state error has arisen
    where the output is offset from my set point.  To combat this
    problem, I have heard that I should also implement integral control
    into my algorithm.  Looking through the daqmx examples, it appears
    to me that all the example PID vi's contain only P controllers when I
    looked at them more closely.  For traditional daq, I found a
    complete P, I, and D controller and was hoping to find something
    similar for daqmx.  Does anybody know of any example vi's online
    or if I am not looking at the packaged examples correctly?  Any
    help would be appreciated.  Also of note is that my setpoint is
    also changing slightly in real time.  I don't know if this has
    significance for more advanced controllers, but I thought I should
    mention it.
    Thanks,
    Nick

    Hello Nick,
    You can pretty much take the simple PID.vi from the traditional DAQ example and plug it in place of the P controller in the DAQmx examples. If you do the PID toolkit for LabVIEW, then it has a set of PID VIs that you could use.
    I am sure you know PID, but I have included a link on PID below.
    http://zone.ni.com/devzone/conceptd.nsf/webmain/D4748F0D59CF436D8625702700809EF4
    Also, please take a look at the 'NI Ready-to-Run Controls Starter Kit' which has executables and VIs for PID applications with our DAQ boards.
    http://zone.ni.com/devzone/conceptd.nsf/webmain/B238B02B04369A0386257028001A7B3A
    Thanks,
    Arun V
    National Instruments

  • Best design idea for parallel DAQ (via GPIB), PID control and watchdog system

    Hello!
    I am a starter programmer in LabView, I already understand the basic ideas, and design patterns, like producer/consumer, events state machine, functional global variables, and so on, so the basics...
    I started a project a few weeks ago, and first I wrote and tested all of the necessary subvi-s for my project, like the ones initializing my GPIB devices (a Keithley mux and a dvm), controlling/reading out the measured voltage/resistancy values from them, subvi for my Static Analog Output card (I have to drive 7 analog output channels, 4 has to be PID controlled regarding to some of the measured values from the GPIB devices), and another subvi for the analogue card, sending TTL watchdog signals out to my experiment in every 2 seconds.
    Any idea is welcomed about suggesting the best design pattern for my project.
    The main features of my program would be:
    After starting the user interface the program starts with a start-up state, initializes the DAQmx channels and the GPIB devices. The program starts to read out different values from the GPIB devices, including 4 temperature values in every 3 seconds.
    In the same loop (?), using PID control, the program sets the DC voltage values of 4 channels (3 to heating wires, 1 to a Peltier-heat pump) on the Static Waveform Analogue output card, the remaining 3 values are constants.
    I have to send digital TTL watchdog signal to some relays from the same output card, changing its state in every 2 seconds (not the same rate as the GPIB values are read out).
    When the 4 temperatures and the power values regarding to the heating wires are equilibrated after a few hours, the program goes into another state, and signals to the user, that the measurement can be started. During a measurement, I write out all of the measured values to a TDMS file, and there is also some basic calculations "on the fly", like a moving average.
    After the measurement done, the user can swap samples, and the program goes into the above state, waiting for equilibration . and so on...
    Do you think I should use a Producer/Consumer pattern with events? Or someone would recommend me a better design idea?
    Thanks very much!
    ps.: I read out lots of values from the Keithleys, so I put them in a cluster. I made a small test vi (attached without the GPIB comm subvi-s), just to test the GPIB comm. So this is the recent state of my project. (all other subvi-s tested and ready to use as I wrote above, like the DAQmx output part)
    Attachments:
    GUI_Calorimeter_control_image_v2.vi ‏284 KB

    Okey
    I think it is a better approach if I work first, and after I ask
    I go with small steps. For first, now I just want to make a DAQ analog output loop, and parallel a watchdog loop sending out TTL in every 2 seconds.
    The main loop in my project will iterate with approx. 10-15 seconds.
    I want to check in my watchdog loop, if my main loop hangs up (in that case the PID control stops, but the danger is if the output voltages stay on).
    After some readings, I have decided to use a functional global variable.
    I have attached the vi, can someone give me advice, what would be the good solution for this purpose?
    (I know it is a bit silly what I messed up with the shift registers in the bottom loop, it was some experimenting).
    Thanks in advance!
    Attachments:
    watchdog_funcglobvariable.vi ‏12 KB
    Global 1_stop.vi ‏4 KB
    analog_output+Watchdog.vi ‏57 KB

  • Engine Dynamometer Brake Control, DAQ & LabVIEW PID

    Hi all, I am in the middle of a project to design, build and test a controller for an eddy current engine dynamometer.  I have an idea of how the inputs, outputs and overall process go, but am not sure how to best implement the necessary features in LabVIEW.  I have access to a NI USB-6211 DAQ, and a PC with LabVIEW 8.6, DAQmx drivers and the PID toolkit installed.
    On the electrical and mechanical side, an SCR firing board takes a 0-5VDC analog control signal to vary the amount of current passed through 380V three-phase electrical lines hooked into a large field coil.  Varying the input 0-5VDC signal results in a directly related variation of input current into the field coil, which in turn affects the strength of the magnetic field generated by the coil.  A large ferromagnetic rotor spins concentrically within the coil.  If the magnetic field increases, eddy currents are induced in the rotor causing it to slow down and heat up, and vice versa.  The engine-under-test is bolted to the large rotor and is put under load by the effects of the induced magnetic field and eddy currents.
    The plan is to have LabVIEW manage the 0-5VDC SCR firing board control signal.  The dynamometer currently has manual rotary knob controls, but the types of tests that are currently possible are limited.  The goal of the overall project is to produce "dyno sheets," plots of engine torque and horsepower over the motor's usable RPM range.  The problem, and motivation for this project, is that the manual controls cannot provide repeatable, precise measurements necessary for "power sweep" tests used to produce dyno sheets.
    Power sweep tests are used by all engine and chassis dynamometers to gather an evenly distributed collection of data across the engine's usable RPM range.  The idea is that the engine should be forced to accelerate its RPM at the same rate from just off-idle to rev limit.  Bolted to a dyno and given its druthers, most engines will accelerate more slowly off-idle and more quickly in their upper RPM power bands.  Load must be controlled so that the engine can spin as freely as possible down low in the RPM range, and be forced to maintain constant acceleration as it tries to pull away in the upper RPM range.  Human, manual control of rotary knobs can provide a respectable effort in this situation, but the problem becomes very apparent when comparing back-to-back, "identical" tests on the same engine, with the same operator.  Repeatability of torque and power measurement tests is very important to understanding how distinct changes to the engines mechanical and fluid systems affect its torque output, along with other symptoms.
    I hope the background is helpful.
    There are RPM and Torque inputs into LabVIEW for the engine under test.  In the design stage, I figured I would be able to implement a PID controller in LabVIEW to vary the SCR firing board's 0-5VDC control signal.  The PID loop would control the 0-5VDC signal so as to allow the RPM of the engine-under-test to accelerate as closely as possible to an operator-chosen rate.  The USB-6211 DAQ has two analog outputs, one of which can be used for the 0-5VDC control signal.  The DAQ also has two digital counter circuits.  One of them is used for counting and determining the continually changing frequency of a TTL pulse train driven by engine-under-test RPM.  Lastly, one of eight analog inputs is used to measure a 0-5VDC analog input signal from a strain gage signal conditioner indirectly measuring engine-under-test torque output.
    I worked with LabVIEW as a student in school, but never attempted to design VI's from scratch until now.  I spent the last week or so practicing with the DAQmx Assistant and later the broken-out DAQmx LabVIEW code for bench-testing the counter and analog inputs for RPM and Torque.  I plan to begin experimenting with PID controls this week, but I have stumbled into a few trouble spots with the DAQ input code already.
    As of right now, it seems that the PID control loop will only use RPM data, not engine torque data.  I would like to make sure that the sampling settings being used provide just the right amount of coverage, not using more DAQ or PC resources than necessary.  I figure this will assure the sampling process and controller will run as close to real-time as possible without relatively large-scale changes to the system.  Due to mechanical limitations of the dynamometer, the engines under test will never exceed 3600 RPM.  A variable reluctance sensor is positioned closely to a 60-toothed trigger wheel bolted to the dyno's rotating assembly.  The VR waveform is passed through a LM1815 based VR signal conditioning circuit to produce a TTL pulse train.  This digital signal is then piped into of the counter inputs on the USB-6211 DAQ.
    (3600 Revolutions per Minute * 60 Teeth per Revolution) / 60 Seconds per Minute = 3600 Teeth per Second (Hz)
    The maximum frequency of the RPM signal will be 3600Hz.  I started to try different DAQmx Timing settings. It seems the three main options are Timing Source, Timing Rate and Number of Samples.  I have the book "LabVIEW for Everyone," and read Chapter 11 on LabVIEW with DAQmx, but I had trouble figuring out exactly how these three fields affect a Counter input, as compared to the examples in the book covering analog inputs.  If it's not too much trouble, could anyone shed any light on this?
    In case it's interesting, here are some pictures of the engine dynamometer and some of the older data equipment that is being replaced.
    Engine Dyno Pictures
    Thank you for any help!
    Rob

    CoastalMaineBird wrote:
    As it happens, I am involved with a large project that controls engines, as well.  I have two control loops, one controls dyno drive based on speed, and the other controls throttle based on torque.  Usually only one is in PID mode at a time, the other is open loop.  I have to run the engine thru a prescribed speed-torque cycle and measure how much exhaust pollution occurs.
    We do "Torque Maps" which are sweeps similar to what you describe. You put the throttle 100% ON, and ramp up the dyno speed, all the while capturing data.  You get a map of how much torque you can obtain at any given speed. 
    I do it on a PXI box to avoid timing issues.  When I last tried to use the host computer to do this, Windows was just not able to devote the time to getting the data right.  The PXI box guarantees that I can control the loop at 100 Hz (I have tested it up to 1000 Hz).
    Anyway, to your specific question: 
    I started to try different DAQmx Timing settings. It seems the three main options are Timing Source, Timing Rate and Number of Samples. 
    The counters are general-purpose, so they can be configured in many different ways.
    The TIMING SOURCE is where the basic timebase comes from.  If you're measuring a high-frequency signal, you want a higher-frequency timing source (so you have resolution to spare).  If you're measuring a low-frequency signal, you want a low-freq timebase (so you don't run out of counter bits).  If your max input is 3600 Hz (277 uSec), then a 1 MHz timebase (1 uSec) will give you  one part in 277 resolution WORST CASE.  A 10-MHz timebase will be 10 times as good.
    I don't know where you are getting the TIMING RATE and # SAMPLES inputs, can you explain? 
    That's a very interesting project you are working on, certainly a lot more involved and impressive.  I think I saw a few screenshots of the LabVIEW interface on your website and wow!...that is really nice.  The emissions analysis equipment can get very pricey, but I can't think of a more timely test to be directly involved in at this point in time.
    I briefly researched standalone LabVIEW system options and real-time capabilities.  I am hoping that the barebones nature and low operation count of the VI will allow a Windows host PC to be sufficient for controlling the process.  This is largely an economic motivation to keep the overall project cost down.  If it turns out that PXI hardware is necessary, it will also be possible to look down that path at that point in time.
    When I first looked at LabVIEW DAQmx reference materials, I suspectec I would need to go beyond the DAQ Assistant and break down DAQmx tasks into their lower level start, read, write, stop and clear components.  After reading more and working with additional LabVIEW PID examples, it looks like I may be able to stick with DAQ Assistant sub-VI's.  I was confused at the time by the different DAQmx timing components and chose to begin with a question on the counter input.  Today, a DAQ Assistant sub-VI seems to be handling the counter input well enough.
    I most likely need to focus on PID parameter tuning at this time.  If it turns out that the timing configuration of the counter RPM input is preventing the system from working as required to perform a power sweep, or follow a Torque Map like you mentioned, then I will need to revisit it.  For now I'm just going to be happy that its portion of the system seems to be working.  
    Message Edited by el bob on 03-24-2009 01:45 PM

Maybe you are looking for