Jump to content

Bill Gilbert

Members
  • Posts

    15
  • Joined

  • Last visited

Posts posted by Bill Gilbert

  1. If response time isn't important, you can probably use non-aggressive settings on all that will get to the right temp eventually, but the design of the controllers and their implementation of PID can be very different.

    Or, you could do the PID in Labview and just use a power driver driver module for each loop. I did a test stand several years ago running 14 TEC temp control loops using homebuilt current driver amplifiers and an MCC USB-3105. I discovered later that Velleman makes a nice little DC input to PWM power driver kit for about $20:

    http://www.jameco.com/z/K8004-Velleman-DC-to-Pulse-Width-Modulator-Kit-Control-DC-Motors_120539.html

    Or you could use a DIO output driving MOSFETs or solid state relays for slow PWM (aka time proportioning). I wrote a LAbview time proportioning vi that will do a nice job with cycle times of 1 sec or greater, especially with the 1mS resolution offered by the Wait mS Multiple function since Windows 7. I can send or post if you like.

  2. I thought I remembered seeing fast response thermocouple conditioners long ago, but don't see any now, with exception of that Omega unit you found. Most industrial transmitters and conditioners integrate over at least a couple of line cycles to get rid of noise, since most temperature loops simply can't change that fast. The benefits of 4-20mA transmitters are a bit overblown and you won't find any fast ones. They also introduce a secondary calibration hassle, since the current is almost always measured as a voltage across a shunt resistor with a pretty crappy tolerance.

    If you want to stick with off the shelf technology, you could use a fast DAQ card with one of the SCXI modules, like the SCXI-1102, which can go way faster than 1000hz. At that speed, noise is going to be a problem, and you'll have to use twisted pair extension cables with differential inputs.

    To get away from long runs of TC extension wire ($$ and hard to find in twisted pairs), you could maybe make or buy a remote reference junction device. I've done that before. It's just a matter of placing a sensor like an RTD in a position to monitor the temp of the terminal blocks or connector where the transition from TC alloy wire to copper occurs, with some consideration to keeping the temp uniform (isothermal block). There is, or used to be, example code for doing the reference junction compensation in LAbview. I use the term reference junction, because it doesn't have to be cold. It used to be common practice to place the TC junction terminal blocks in an oven enclosure that was held above ambient temp, like ~120 degF. I might be able to dig out the code I used, but it was back in Labview v3 days.

  3. The mencoder lavc codec was compressing the output nicely, but reducing quality visibly. Fiddled around some more, spotted the IYUV string in the Get Codec Names vi, now using "-ovc raw -vf format=IYUV", which produces an uncompressed AVI that Labview can read. The IYUV codec is not show in the list that comes up in "mencoder -ovc help", but works. With the Cast Image in our app, I'm where I need to be.

    BG

  4. Thanks Jordan, but scanning the Handbrake webpage, I see nothing about any command line interface, this needs to be automated without having to use a separate GUI.

    Experimenting yesterday, I found Labview will open and read an AVI processed through mencoder using "-ovc labv" instead of "-ovc raw -vf format=yv12". Now the IMAQ Image to Array function chokes on the "invalid image type". I found Get Codec example yesterday, and will put more work into this today. Part of the problem is just my low position on the learning curve, and deciphering the alphabet soup of acronyms. I suspect there is a filter -vf that can force the pixel format into a greyscale format that Image to Array will like, but maybe not.

    It may not be necessary, since I think the historical reason that Image to Array and an Intensity Graph was used in our application have become moot. I took over this project about ten years ago, and left it alone, since it worked. Might be time to change that to an IMAQ Image control which displays the images just fine, and in color. Might end up being the easiest path right now.

  5. Thanks again all. Following links, I found this thread:

    http://forums.ni.com/t5/LabVIEW/Convert-MPEG-to-multiple-JPEGs/td-p/1199703

    ... where Andrey Dimitriev suggested using Mencoder

    https://en.wikipedia.org/wiki/MEncoder 

    which apparently uses FFmpeg. I managed to get it to work from the command line in System Exec. It creates an AVI that I can view with various media players, but so far, IMAQ Open AVI.vi chokes on this creation, suggesting that I need a Directx upgrade. I'm in Win7 at Directx v11, so I don't imagine that will do much good.  Now I need to do some more work to find a format that mencoder will create that I can read with labview.

    System Exec command line is:

    C:\mencoder.exe File-in.mov -ovc raw -nosound  -vf format=yv12 -o File-out.avi

  6. Will investigate these suggestions, thanks very much! Found a couple of trialware converters yesterday, but neither of them can be called from a command line. Tried one from iSkysoft, and while it did a conversion, it may have also be trying to install some sort of spyware, getting execution notifications now. Maybe they just want it to phone home to indicate who is using it, or...........

  7. For years now in the student labs we've used firewire video cams and the IMAQ 1394 driver to create AVI files which then get read and converted to intensity arrays for motion analysis in a Labview app. The cheap cams are going extinct, and they want to use I-pads to create the videos which are MOV Quicktime format. So far it looks like the I-pad app they want to use can't be made to spit out an uncompressed AVI. So now I need to find out if I can either:

    1) automate conversion of an MOV to uncompressed AVI and continue to use our LV analysis app as-is, or

    2) find a way to parse a compressed MOV video to a frame-by-frame intensity array, and build that into our LV analysis app.

    I am starting to search, but is anybody aware of an existing library or methods so I don't reinvent the wheel?

    Thanks,

    BG

  8. Well, downloaded the gzip exe utility, put gzip.exe in System32, and it compresses our 100MB data file to about 6MB just fine when run from the win-dos command line, When I try it in system exec with only the command line:

    gzip <full path to file>

    I get an error dialog saying "Labview: memory full". tried increasing the expected output to 10MB, no joy. Any idea what I'm doing wrong? Or is the system exec somehow limited to smaller jobs?

    Thanks

    BG

  9. Thanks for system exec suggestion, I'd forgotten about that. May not be last question I ask.

    In answer to "why gzip?", it's basically because one guy insists on it. Wants to stream data direct from the zip files and has already written apps on his end where they are working in Linux. He asked for pepsi, but I found the fridge full of coke. I already wrote an app that looks for our raw data files and uses the LV palette functions to zip them, but "no sale". He's already found a workaround, but I thought I should see if I can do this without major time investment.

  10. The group I'm working with would like me to use gzip to compress files instead of the zip palette functions in Labview. I got to thinking that the easiest way to do this would be to use the Python script node, which I saw and downloaded a couple of years ago, but never actually used. The machine I was working on got shipped away.

    Does the Python script node still exist, and if so, can anybody point me to the source? Searched but ended up chasing my tail.

    Also, if anybody has suggestions for a better way to approach this puzzle, sing out. I looked and couldn't find a gzip dll, but may not have been looking in the right places.

    Thanks,

    Bill

  11. I suppose it's a little late to be chiming in, but depending on how you configure the gauges, you will(hopefully) get a voltage proportional to the strain and the level of applied excitation. As you are finding out, there are lots of ways to configure and apply the gauges.

    If you are doing experimental stress analysis, the manufacturers of the gauges will have lots of reference materials and calculators you can use to come up with likely values of voltage per unit microstrain. If you are experimenting with transducer design, can use the experimental stress formulas to guess at the ouput of your design, then probably run a calibration using a deadweight tester or comparison to a trusted transducer.

    If you were using off the shelf load cells or pressure transducers etc., you would be given a full scale output value in millivolts output per volt of applied excitation , mV/V. They are generally temperature compensated as well.

    -BG

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.