Tim_S

QUOTE (panithan @ Apr 23 2008, 04:55 PM) One thing that will help is if you make sure to use "good LabVIEW coding practices". This will help you as well as others debug your code and will make the code look "more professional" (which could help you with your capstone). The main points I see is to keep your wires neat (not a lot of bends, wires don't overlap on each other, etc.), to keep the dataflow from left to right and top to bottom, and to put comments in the code. As mross pointed out, the motor will take 100 pulses to move one rotation, so if you have an output frequency of 100 Hz the motor will actually turn at 1 Hz (1 rotation per second = 100 steps per second). If your motion is not somewhat smooth, you may have an issue in the electronics that are driving the stepper motor are not powerful enough to cause the motor to move from pole to pole in one step. A way to check this independantly of your program would be to hook up a signal generator to the driving circutry. If you don't know how to use an oscilloscope, this would be a good time to learn. Sometimes the issues run into are not in the software or the hardware, but this dubious area inbetween. Good luck!

QUOTE (Cat @ Apr 21 2008, 01:45 PM) I had a lot of trouble with OOP at first, partially because (in my opinion) the NI examples tend to not be very "real world". It's nice that animals are composed of cats and dogs and sheep, but how do I abstract that to my problem? Of course, this is an issue with describing any feature for a wide audience. I have two systems where I've implemented an object-like structure. The first is a test stand where the error handling is an object, the database access is an object, the test sequencer is an object, etc. The objects, in this case, are subsystems of the large application. I was explaining the code to a layman today and he descibed the structure as an API for a [Windows] service. The second system I have with objects is a test plan editor. The editor can load and edit multiple test plans at a time; think similar to the way Microsoft Office applications work. A "test plan" object makes it much easier to deal with data than a 1D array of a cluster of.... This also allowed me to create "properties and methods" of the test plan object to perform all of the creation, opening, and editing into individual VIs; readability and maintenance was much easier with this structure. The by-reference object is more similar to C++ than the by-value object; I find the by-reference object more useful to me (more-so with the first implementation). I've played with the by-value object a bit and can see where I may have use for it in the future (as in the second implementation). As with any tool, though, it only makes sense to apply it where appropriate (using a screwdriver for a hammer is not advised).

QUOTE (Stijn @ Apr 15 2008, 02:11 PM) I'm half-surprised you're using a passive sensor as most cam/crank sensors I'm seeing are active and output a digitized signal. Tim

QUOTE (superslug @ Mar 25 2008, 12:20 AM) I've not had this problem with printing and LabVIEW (pleanty of others, though), but the first thing that comes to mind is the print driver may be causing the problem. I would recommend performing a complete uninstall and clean on the driver and then then reinstalling the driver. You could also verify that the driver could be a problem by trying to print from various applications.

QUOTE (ASTDan @ Mar 17 2008, 04:37 PM) You can hook PCs together on one RS485 network. Think of it as a networked version of RS232. QUOTE (ASTDan @ Mar 17 2008, 04:37 PM) I can set my device to continously send out data. So the computers don't need to send data to the device they just need to receive it. Will I run into loading, or ground loop issues, etc.? Loading will depend on the rate that the device sends out data. Ground loops should not occur so long as you hook everything up per RS485 specification. Line loading won't occur unless you exceed the RS485 specification (seems like it's 32 devices on no more than 1000 feet, but I'd have to look it up).

The digital outputs on the NI cards are not going to be sufficient to drive anything like a motor. You will need a power amplification stage between the card and the motor. I assume this is a small motor, but it will still generate comutation noise. You'll want to keep this noise from the DAQ card so that 1) it doesn't damage the card, and 2) you don't want it to get to the other channels. Unless the card is built specifically to handle the loads you're connecting, it is always good practice to provide an isolation layer between the card and the hardware. This has saved many a PC when something like arcing the 24-volt logic from the 480 VAC three-phase occurs (fortunately no one was hurt).

QUOTE (carlover @ Mar 12 2008, 12:17 PM) If NI is telling you that the driver can only acquire from one camera at a time, then the only way to acquire from more than one camera at a time would be to change drivers. This would include using multiple applications as the driver would be common the all of the applications. From my understanding of LabVIEW and vision, I would say the issue wasn't the choice of LabVIEW/NI, but the choice of using a USB camera system and the limitations that supplies. For the synchonization part, that depends on what you mean by synchonization. Tim

QUOTE (dasrobie @ Mar 12 2008, 12:20 AM) Are you refering to COM as in the serial port or COM as in a COM (ActiveX) control? Tim

QUOTE (vt92 @ Mar 11 2008, 02:25 PM) You may want to use the NI webpage under the Products & Services "tab". There is the ability to filter through DAQ hardware based on such requirements.

QUOTE (Bob Edwards @ Mar 11 2008, 12:55 PM) Datasocket is a "catch-all" for communicating, so it has a fair number of quirks (besides the limited documentation). Datasocket is good for small numbers of variables (I believe the number I've heard is 200 as the upper end); large numbers of variables cause performance (mainly delay) issues. This is something to keep in mind with your design. You may want to consider something such as TCP, though if you have multiple listeners it seems that UDP would be more appropriate (UDP is not as reception robust which may not be an issue on one machine). As a thought, it sounds like you're creating a plugin-like archetecture. You may want to consider alternative design structures, all of which depends on your design constraints. You may even want to consider something off-the-shelf such as TestStand if you need to integrate in C code as well as LabVIEW code. Tim

QUOTE(Aaron L @ Mar 5 2008, 07:21 PM) Years ago I had to do this and wound up reading the serial port then buffering the string. I've not looked to see if there are newer tools that can do this, but I'm suspicious that's what you're going to be doing.

QUOTE(JDave @ Mar 5 2008, 03:41 PM) In the user32.dll there is a SetWindowPos function that can be used to make the window the frontmost. I didn't see a get or query counterpart in a brief search, but that would be the place to look. Tim

QUOTE(kanmo @ Mar 4 2008, 07:30 PM) Yes. This would require basically the same VI properties as if you had a user interface in a subVI.

QUOTE(CamilloN @ Feb 28 2008, 02:41 AM) I've used an inverse-FFT filter before, though it was using the one-sided versions. It worked rather well so long as the frequency content of the noise was "sufficiently far away" from any frequency content of the signal. You will get distortion of the original signal if the signal and noise intermix. With the signals I had, there was a fine line between not eliminating noise and eliminating signal, so you may have to play around with the frequency threshold more than with other methods.

QUOTE(fuzzycontrolfreak @ Feb 25 2008, 08:35 AM) If you know you're getting a 36 kHz signal and you want shape data, then you should be sampling at ten-times the expected maximum frequency (twice for frequency). The sugestion of the encoder is good if you want to be synchronous to the shaft (data collected in constant degrees apart rather than time). What you intend to do with the data after you've collected determines which method would be best. Tim

QUOTE(CamilloN @ Feb 25 2008, 04:07 AM) I believe the word you're looking for is "filter". Time/phase shifting can be a problem with filters. There are some that are designed to have no phase shifting but those tend to affect amplitude instead. Depending on the filter settings and your data, neither phase nor amplitude may be affected in the areas you want to keep. You may want to try a "running average" filter. This involves taking multiple sequential points and averaging them; the effect tends to take out little spikes. The number of points you use can impact the portion of your data that you want to keep.

QUOTE(dblk22vball @ Feb 6 2008, 02:12 PM) I've heard of spray patterns being detected before, but it was with a custom-built capacitive-based sensor array in an R&D lab environment. What you seem to be describing is a more 3D version of web analysis (I think that's the proper term), which is detecting features of anything streaming by at high rates of speed. Such applications include detecting applied glue, thickness of paper, and bubbles in molten glass (fiberglass production). For something at lower rates of speed, there is an NI demo of detecting how full a soda bottle is on an assembly line.

QUOTE(Phil Duncan @ Feb 5 2008, 01:14 AM) What is rotating the surface? It seems an encoder would work for your application.

QUOTE(Natu @ Feb 4 2008, 03:57 PM) JFM has the right of it... the VI is operating based on your longest delay. Tim

QUOTE(Natu @ Feb 4 2008, 06:35 AM) It would help if you posted your main VI as well.

QUOTE(Lars915 @ Jan 30 2008, 04:57 PM) Thanks. The activeX interface from LabVIEW to TS4.x looks like a significant learning curve task; I'm not sure what to make of it yet. I'm still trying to wade through the manuals. DSC is rather dissapointing in that it doesn't have very good example code nor can I find any manuals installed with DSC. Tim

QUOTE(Francois Methot @ Jan 30 2008, 05:46 PM) If you look in the Example Finder and look through NI's website (they have an instrument driver section), you should find what you're looking for.

An option has been proposed to me to use LabVIEW as a front end for TestStand and the Data Supervisory and Control Module in a test executive application where there is data acquisition, OPC communication, reporting, calibration, error logging, parallel execution and test/limits configuration. (The reason for LabVIEW front end is DSC and TestStand won't meet customer requirements alone.) The last time I saw TestStand was version 1 (there was lots of colorful metaphors used at the time) and I've not used the DSC module. What has people's experiences been with any combination of these? Thanks, Tim

QUOTE(jennifer @ Jan 28 2008, 11:58 AM) You could open the file and use "Read from Text File" to read n number of lines. You'll have to right-click on the primative function and check Read Lines to do this. The Spreadsheet String to Array primative would also be useful. Tim

QUOTE(bayram_mercan @ Jan 25 2008, 07:31 AM) Converting the dynamic data type to a waveform will provide you t0 and dt. From there you can get the array you're looking for.