Jump to content

Bryan

Members
  • Posts

    366
  • Joined

  • Last visited

  • Days Won

    11

Posts posted by Bryan

  1. I've pretty much given up on triggered digital acquisition due to project time constraints and the fact that it's taking me so long to try to find information on it, so I'm just collecting several points of data, roughly 3-5 full square wave cycles and processing the data afterward.

    The problem I'm running into though, is that occasionally, in my collected data, I get what appears to be a buffer reset in my data. I'll have a square wave that will have a little blip, or extremely wide "high" cycle amid normal "good" collected cycles.

    What I think is happening is that the card is missing some of the signal when it resets the read point to the start of the buffer, so the little abnormalities are actually the end of one buffer width spliced to the beginning of the next.

    Now, with DAQmx, and this card, I am not allowed any buffer control with digital acquisition. I can't even read what the current 'read point' in the buffer is, tell it where to start reading or anything. The only thing it appears I can control is the buffer size, but I'm not sure if it's even doing anything because when I do this, I see no difference in my acquired data.

    Does anybody know any way to get around this problem, or should I continue to write little digital wave processing subVIs that will find and eliminate the odd-ball wave cycles?

    Also, just FYI, I'm not concerned about the 'splice' for viewing purposes, I'm doing calculations with the collected data, and inconsistant cycles are affecting the outcome stability of the calculations.

    Thanks guys!

  2. I'm running a PXI-6713 with DAQmx. I have a 60hz digital signal that I'm monitoring as a reference.

    What I want to do is:

    When the 60Hz signal goes high, begin data acquisition at a specified frequency and rate.

    When I try to set up a VI to montior digital input(s) and set up the trigger/timer, I get an error that reads:

    "Device property not supported by device or not applicable to this task."

    That basically tells me that I can't trigger the start of digital data acquisition using DAQmx and a PXI-6713 Card. Seems to me that there has to be a way to do it, anybody know how?

  3. Nevermind guys,

    I set up a scenario and monitored the PXI controller processor performance using the change state timing VI and found that CPU usage went up to 100% or so. I created my own version of a digital input monitoring VI using the task start and read channels VI with my own 'new value notification" and it used FAR LESS resources. (CPU usage with just my VI alone allowed it to drop to < 8%). I think the DAQmx timer change state function was monitoring the channels at full processor speed (~2GHz) with is MUCH faster than I need for my application.

    Sorry to end up solving my own problem, but hopefully it will help those who might run into the same situation.

    Thanks anyways! :D:P

  4. I've wanted to become a LabVIEW certified programmer for at least 3 years now, but I'm tentative to pay the money to become certified because I'm not sure if I have enough knowledge to pass the test. Here's why:

    I had a LabVIEW basics course in college, where we used LabVIEW 4.0.

    I then took another LabVIEW Basics I course when I worked for a previous employer, we used 6i for that course I believe.

    All of the remaining 5 years of experience with labview I have is due to learning as I go. I don't have any other formal education in LabVIEW except for the 2 basics I courses I've taken, but have written labview programs for rs232, 485, GPIB, IMAQ and DAQ applications, and I have no other formal programming education, all self-taught.

    I consider myself to be a relatively advanced programmer, but am afraid that in my basically self-taught experience with LabVIEW has left holes in my programming knowledge, which will be exposed come test time, then I will have wasted my money taking a certification test that I could potentially fail.

    I guess I need some level of certainty before I would feel comfortable taking that route.

  5. In my PXI system, I dynamically create a channel/task with all of my lines/ports that are configured as inputs.

    Using the DAQmx Timing Polymorphic VI (with Change Detection selected) I wire my task and the same physical channels used to create it to the VI. My intent is to monitor all input digital lines and return all of the input values if any line changes state at any time.

    Now, the VI has a timeout terminal (in seconds) that you can set to -1, which makes the VI wait indefinitely for a change on the input lines. This matches what I want to do, however, when I want to stop monitoring the channels, I have to wait until another state change before the VI will return.

    I've tried doing like I've done with queues and destroying/clearing the tasks, hoping that it will force the VI to return with an error, but nothing happens.

    Is there a way that I can abort the VI while it's waiting through the software? I'm currently searching through the DAQmx VI palette for functions that might hold clues. My unfamiliarity with DAQmx isn't helping either. :headbang:

    One way I can think of to do this is to wire one of my output lines to one of the input lines I'm monitoring, and when I want to abort it, set the output line high, which will generate the change and have the function return. I'd like to avoid tying up any of my digital lines like this if possible.

    Thanks guys!

  6. EXACTLY what John said.

    You can also use the "VISA Bytes at Serial Port" VI (basically a property node) to see exactly how many bytes worth of data reside at the port waiting to be read if you're not sure how many bytes to expect. (Located in the Serial, palette).

    Wire the output of that to your byte count input on your "VISA READ" and it will read in exactly the number of bytes that are waiting.

    If you're proficient enough at LabVIEW, you can also use state machines, aka "action engines" to do all of your functionality using just one VI. This can get messy though if things aren't kept organized from the beginning. I normally try to do my drivers this way if they're not too involved.

  7. I typed in a whole lot of stuff for you, but in the process thougt of something.

    You can look at the serial communication examples in LabVIEW (HELP >> EXAMPLES) to get an idea of how to do it. It's relatively easy once you get the hang of it.

    You'll need to know the port configuration required by the device you're talking to. (i.e. baud rate, parity, stop/data bits, etc) for the configuration.

  8. I didn't know the global channels created can be accessed in MAX :oops: Thanks!

    As for global channels vs tasks, I haven't played enough with them to really be comfortable with global channels. I'm creating my channels and tasks dynamically, and I haven't played with global channels enough to know if I can create them dynamically with as much ease.

    I'm learning this stuff, slowly but surely (my code is working) but correctly? I'm not sure yet. :D

  9. Okay, I just got my new "Toy" the other day (PXI system with controller running XP, a PXI-6713 AO and PXI-6509 DIO cards).

    The DIO card only works with the new DAQ 'stuff', so I am forced to learn DAQmx as opposed to the regular DAQ with which I am more accustomed.

    Now, in trying to figure out how to use all the stuff, I created a global channel, and now that I wish to delete it, I can't figure out how and have had no luck using LabVIEW help, etc in finding out how to delete it.

    Can anybody help? Also, if any of you guys have used DAQmx before and have any useful tips, tricks, or "head's-ups" I would appreciate you sharing them with me. I'm still trying to figure all of it out. :D

  10. Could you be a little more specific?

    To create a custom control, select it on the front panel of your VI, then from the EDIT dropdown menu, select "Customize Control".

    This will open the control editor with your selected control on the panel. From there you can make changes to the control.

    As far as advanced control editing is concerned, I won't be able to help you as I don't do much control customizing... yet.

  11. I think it would be beneficial to have case structures able to select a case based on matching of a regular expression when a string is wired to the switching terminal.

    Right now, they can accept ranges of values for one case... i.e. "a...c" will accept any character from a-b. It would be neat to be able to type in something like "foo*, *bar" and have it accept things like "foo, foobar, foo bar, lowbar, low bar" etc.

  12. When you created test executives in "pure G" do you mean you wrote your own scripting language and develop a LabVIEW interpreter? Isn't G = LabVIEW, or is G a text-based version of LabVIEW. I've heard people say "G programming " and "LabVIEW programming". Correct me if I'm wrong, but isn't it the same thing?

    Also, what I did with TCL and LabVIEW through tcp/ip is use the Tcl "Socket" commands found in the Tcl manual. Either in LabVIEW or Tcl, I created a kind of "server" that listens for and acquires connections. I set Tcl up as the "server" and wrote a "client" in LabVIEW.

    When LabVIEW connected to Tcl (via address and port) I had Tcl take any string that I sent to it from LabVIEW and use an "EVAL" function to execute it as a tcl script.

    Only problem with this is, if I sent a command from LabVIEW such as "set i 1", then next one I sent is "puts $i", I would get an undefined variable error, which tells me that it opens, uses, and closes a new interpreter each time the "EVAL" command is used.

    But like I said, if you're looking at communicating via tcp/ip using Tcl, look for the "SOCKET" commands in the Tcl manual. I'm basically a self-taught programmer in all of the languages I know, so while I know some basic and advanced stuff, there are a lot of "holes" in between that I don't know.

  13. Does anybody know if there is a way to select a case using regular expressions instead of exact strings or ranges?

    What I want to be able to do is the following:

    Say I have some strings like this:

    "FOO BAR"

    "FOO POST"

    "HELLO WORLD"

    "HELLO USA"

    What I want to do is have a case structure with 2 cases... "FOO" and "HELLO". If I wire any of the above strings to the case, I want it to select the case that matches the string segment before the whitespace, regardless of what's after the whitespace.

    Now the kicker... I would like to do it without using "Match Pattern" or any other extra VIs.

    I tried entering regular-expression-type values into the case structure, and got a non-unique case error. Is there a regular expression-type syntax that can be entered to accomplish this? I've already tried using "..." as explained in LabVIEW Help, and it appears I can only use it in one case, or I'm using it wrong.

    If LabVIEW doesn't support regular expressions in their case structures... perhaps they should consider it for future versions?

  14. I know that Test Stand supports Tcl scripts, but I have a need for using the capabilities of Tcl with LabVIEW.

    For example, for a test system I am currently working on, I would like to control the entire application with LabVIEW, use Tcl for script-driven control and monitoring of NI PXI DAQ.

    It would be nice to have a Tcl Interpreter library for LabVIEW, just like how there is a MatLAB, Hi-Q and even the formula node.

×
×
  • Create New...

Important Information

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