Tim_S

There's all sorts of questions about sampling rates, update times, etc., but that gets into designing the system. From what you have here I'd put all the I/O on PROFIBUS since you already need it in the system.

Tim

A small update...

Tech support has determined that LV 2009SP1 fixes this issue. I've updated LV 2009 with patch 3 applied. I am still able to recreate this issue on my PC. I'm not sure what's going on but 2009SP1 users may not see this.

Tim

kristos_b has the right of it.... you'll need to break up your data into smaller files and avoid loading them all into memory. Windows slows down and will choke once a certain number of files are in a directory (sorry, I don't know the number off the top of my head and I expect it's different with Win7 and 64 bit). Zip files and subdirectories are ways to avoid hitting this limit.

I don't know your design spec, but saving all that data raises a red flag for me; you may want to go back and evaluate what you really need to save and what your requirements are.

Tim

I am wondering if anyone has experience write / read to an Uson Vector Leak Tester using LabVIEW. Uson Vector Leak Tester has a Modbus TCP/IP and Serial communication options. LabVIEW has a Modbus Library and DSC software for setting up Modbus server. I am hoping to communicate through TCP. I have not obtain everything necessary to try this out yet, but if anyone has experience with this, please reply to the post. Thanks.

I've never talked with a Uson Vector Leak Tester; I have talked to devices using Modbus TCP. The library off of NI's website works. You will need to know the Modbus address(es) of what you are looking to read/write; check the manual, though my experience is that the actual address may be nearby and not the address that is stated so you may have to search around a little. (I've used Festo and Eaton/Cutler Hammer products.) I expect the leak tester is a server and you'll be programming a master.

Tim

I want to measure 21 analog channels with a sample freq. of 10KHz and 1Ksamples/channel over 10k to 25k different situations.

This will result in 21*1k*25k= 525M measurements (I know it is a lot) at max. All this data must be saved to disk and processed later.

I'm not understanding this. You have 21 channels. They are sampled at 10 kHz maximum rate. What is the 10k to 25k situations?

You're going to run out of memory with the example code. I'm not clean on what you're doing that would generate so many long waveforms in one file.

I am looking for an AC digital multimeter that can read 15-20 Amperes of current @ 120VAC. This will need to be controlled via GPIB, serial or USB using standard SCPI commands. The only meter I have been able to find is an Instek GPM-8212 but it is not very precise and appears to be discontinued.

Do you any of you know of such a meter and/or have any experiences you would be willing to share?

My first inclination is to use a current shunt and voltmeter, however Algient (part of HP some years ago) may have such a multimeter.

Tim

I'm integrating Mercurial and re-organizing reuse libraries along with documentation as we speak.

I just finished cleaning up an 8-month-old mess. My code is in shambles. I don't need another headache.

You have my gratitude.

Not a problem. We (Tech Support and I) are still trying to get to a root cause. A coworker sugested moving from hml to xps files this morning (creates a single file); I'm going to look at those as Word can also save xps format.

I've been working with NI Tech Support. We've got this figured out to where it's time to share the fun we've been having. Hope this keeps someone from a bit of hair pulling.

OS: WinXP

LabVIEW: 8.6.1, but I was able to reproduce it in 2009

I have a library containing all of the code, menus, icons, interface VIs and documentation for an executable X. There are two build specifications: one to create the executable and put some of the files in appropriate directories, and one to distribute a portion of the source code. The first build specification (executable) has no issues. The second build specification reports a successful build. This is not the case as opening the library at the destination directory gives me a dialog box informing me the library is corrupt. The source directory does not have a corrupt library.

See this knowledgebase article for information on corrupted libraries and projects. The article did not show us anything missing in the source and distributed library files (Beyond Compare was useful for this).

We were able to track the corruption down to the documentation. The documentation consists of multiple Word-generated html pages. Each page has a subdirectory with the images, colorschememapping.xml, filelist.xml, and themedata.xml for that html page. The duplicate names in the subdirectories cause the library to become corrupted when the source code is distributed.

Things to note:

1. There are no error message preventing adding duplicate names (at least with xml and image files).

2. The executable build does put all of the documentation files into the correct location, so this is only in relation to source distributions.

Having the documentation included in the library was nice as the executable build placed it in the correct location in the build directory for the installer and the documentation is revisioned with the source code. I've taken the documentation out of the project for the time being; this prevents the corrupted library. The documentation will still be revisioned with the source, however it will require some manual copying to get it to the build directory until we can determine a permanent fix.

Tim

DCOM settings and using Quick Client have been mentioned.

I assume you're using LabVIEW 2009, however there is some strange behavior with the datasocket primatives with OPC with LabVIEW 8.x. The 2009 OPC client example uses the primatives, which is different than the 8.X version. You should use the legacy datasocket VIs if you're using 8.X.

Tim

I don't know of any that have LabVIEW programs, however the USB IMAQ driver will connect to webcams. I tried connecting to a 10-year-old (Microsoft? Logitec?)) webcam a couple months ago and had things up and running with streaming video in a couple of hours.

I've used all three methods. I've also used a scrollbar as an offset pointer of which data to display. The method I used all came down to the best way to present the data in a clear, understandable way.

My experience with treeview controls is mixed. The treeview is great for displaying hierarical data, but is notoriously slow to update. My experience with the treeview is it can be extremely slow to update depending on how you use the methods and disable panel updates is your friend.

Tim

We've done some testing of ignition coils, which can get some very high voltages on the primary side. We typically use a voltage divider with a little protection circuitry then run it through a 5B module for isolation.

Tim

I was trying the same thing with LV 8.6 earlier today. The Failed to Connect message was related to the Windows firewall on the the target machine. I turned the firewall off and have other problems, but that's another story. So, I'd recheck your firewall settings.

Tim

Is there any easy way to either automatically find the terminals of a given wire, or to select the whole wire rather than just the current straight-line segment?

Double-clicking on a wire will select the whole segment. Tripple-clicking will select all of the wire.

Tim

I am interested in finding out how many of my fellow LAVA lovers have had success interfacing LabVIEW with PCS 7 and what method was used to communicate - i.e. Profibus, OPC, etc

I've not communicated with the PCS 7, but I've communicated with a couple of different Siemens PLCs. We've used OPC through PROFIBUS (Siemens card) and Ethernet (KepWare) to the PLCs and both worked well. OPC is a process control communication method and not really suitable for machine control (though you can make it work). I assume you're performing process control, though.

Tim

It's not clear where the values in your array are coming from or are generated. However it sounds like you are looking for the initialize array primative.

Tim

I am using ni USB DAQ 6008 for my project; Shall I connect the pins that I don't use to ground?

You don't have to ground unused input channels, however it could eliminate noise issues. Grounding unused pins would be a bad idea.

Tim

I think the use of the queue for the singleton object is a good choice. I have implemented it is a two-element queue instead and had two copies of the same data in the queue. Locking the queue involved dequeueing one element. Canceling the lock involved reading the remaining entry and writing it back to the queue. I used the lossy enqueue to write new value to the singleton object.

I have used singleton objects when the object will have global affect based on changes from any location in the program. Offhand I can think of logging, error management, security, resource interface/daemon and configuration settings as times I have or might use a singleton object.

What amount of determinism do you need in your digital streaming? You're at the mercy of the operating system without hardware clocking.

I had the opportunity to test a Siemens OPC server the other day. The Siemens OPC server behaved like the RSLinx OPC server (i.e., good for control) with read timeouts at 100 msec and write times averaging 1 msec. I wasn't able to use my test VIs; the communication routine used performs read then write in series.

The KepServerEX and RSLinx communication to the PLC is over Ethernet. The Siemens communication to remote I/O is over PROFIBUS.

I expect you're looking to use a circular buffer to hold the last N seconds of data. You'd perform the analysis on the buffer which would include the last data acquired.

I'm finding out that not all OPC servers are equal.

I'm hoping people will have some advice for me on how I might better solve my dilemma. At worst, this post might help someone else out.

I've got two systems on the shop floor: one has Kepware's KepServerEX and one has Rockwell's RSLinx. I have a two test VIs: one connects to the OPC server and performs reads at (hopefully) 100 msec/10 Hz intervals using the traditional datasocket VIs and the other is the same except it performs a write. I'm using traditional datasocket instead of the primatives as I've got LabVIEW 8.0 installed and the primatives (as per the help files and notes in the shipped example code) don't work [well] with OPC.

I've run the LabVIEW code on both machines. Both PCs are equivalent machines. The RSLinx has no issues maintaining 10 Hz with write times of ~20 msec and read times of < 100 msec (the read timeout value is 100 msec; there is only a read if there is a change in the data). The timed loop doesn't show any missed iterations.

The KepServerEX has issues maintaining 4 Hz. The read VI maintains 100 msec until I start the write VI at which point it averages 180 msec. The write maintains about 230 msec average. Kepware tech support tells me the write takes precedent over the read, so the read gets interrupted for the write to occur. Kepware tech support advise me that I might try asynchronous writes as they would be faster. Kepware also seemed confused as to why I would need to go so fast as 100 msec. I will point out that Kepware tech support was extremely good about helping me and analyzing what was going on down to parsing and analyzing a low-level TCP log for me.

NI tech support spoke with R&D for me. It seems datasocket only performs synchronous operations.

I installed LabVIEW 8.6 on the machines and had the same performance with the same test code.

My current path involves using the OPC ActiveX control. I've downloaded the Kepware example code, which also installs a demo of their OPC server. All has been good until I discovered that some properties and methods the VB example code uses (some of which compiles and works using VB 2008 express) are not available/I have been able to locate in LabVIEW (specifically the method used in the example to add an item to a group).

There have been, fortunately, no large, blunt objects nearby.

My impression is that the two OPC servers are designed with different philosophies in mind: RSLinx for machine control (which is what I'm trying to do) and KepServerEX for production control. Datasocket, as a generic interface, performs synchronous communication as everything it can handle supports that.

So, has anyone run into this or found a way to handle it?

Thanks,

Tim

An off-the-shelf option might be to use 3B modules. It's certainly pricey (I recall them being about $300 each + backplane + power supply), but you've got a fairly solid linear gain. I expect there are other such bricks out there.

Tim

I use industrial PCs specifically because I get 14 PCI slots (and occasionally I use all the available space), so my first suggestion would be to use a different PC.

I've not looked, but I wouldn't be surprised if there was a bus extended to a passive backplane available; you may wish to look for such.

If you've not bought your cards already, a PXI chassis with a MXI extended may be an option for you.

Tim

A) Anybody actually going to use this stuff, or am I wasting time.

We just had another virus hit a customer machine, taking production test down. This is a hazard of using Windows on a plant floor where the data has to get to the plant network (especially in areas where IT practices are not so stringent). I'd have to sell people on why it's a good idea to add some thousands of USD to the project cost, but being able to eliminate this type of event would be a huge selling point. One reason I've not been able to sell it is I can't get the test data to a database directly from RT; "why add a second PC to a system when you've already got one".