Tim_S

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

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".

Pardon me as I take off my technician hat and put on my programmer hat... What I was saying is that I expect a subset of errors to occur. I (currently) have to decipher these error codes to produce a meaningful message to the operator. My statement was as a technician where each error causes a different thing to look for (think state machine). ErrorHandling Example.vi Here's a quick example, no OO as I'm just throwing this together. The errors coming out of the file open, write and close will always require the same type of display (in this case, a 'this is what went wrong message'). Perhaps I'm perceiving an example that doesn't lend itself to more advanced error handling. Wouldn't that be: ?

This is part devil's advocate and part for my comprehension... I can see where I have errors that would be displayed differently (say, file not found versus cable not plugged in). Wouldn't I have to know what the error state when coding to select the correct object (assuming using OO)? If so, I don't see the benefit of defining at runtime. Thinking of some of your code samples, I'm handling the error message upstream of where you would. Handling the error upstream would generate more case statements at the "top" level, so later VIs would not get executed. Tim

Thanks for posting this here; I wasn't able to make it to NI week , so I'm glad for this post. I'm still processing this and where it can be of value, but here's my thoughts... I don't use the native error handling (specifically I use the cluster, but not the VIs) as the information provided in the dialog is not useful to the end user, or I need the code to continue running as the system must respond to the error (e.g., stop the test based on a fault occurring). The first case only has one error, so I create a message and use the 1, 2 or 3 button dialog to display what I need to the operator. I like the idea of having the option to include pictures, links to online manuals, etc., available in the error message dialog. This makes the OO in NEC an interesting concept, though I could accomplish the same thing with a subVI. I can't say I've ever had multiple errors with this type. I handle the second case through the use of an error daemon, allowing the parallel loop display the error so the generating loop can handle the fallout. The cluster I send to the daemon is not an error cluster (especially since I'm often dealing with multiple language selection, a large, nasty beast in-and-of-itself). This would be where I handle multiple errors as there may not be an operator to click on a dialog box. Tim

Which, of course, I am. I understand what you meant now. Thanks for the explanation. I worked at the very tail end of a project where the main developer implemented a system in version 1 of TestStand. I recall there being, shall we say, speaking in tongues and gnashing of teeth before the blood oaths were sworn to never speak of this ill again. As such I'm a little leery of working with it, though I have been trying to get some time to give it a serious look-see. Tim

Crelf - Could you explain this, especially the "fall apart sometime"? Tim

I've not tried this, but it seems that you may want to perform access such as this programmaticly. You should be able to use the remote address and an internal lookup table to do what you want. Tim

QUOTE (Ramom @ Jun 9 2009, 12:26 PM) You can do the calculation (slope) yourself or you can go to the Mathmatics->Integration & Differentiation functions subpallet. I'm assuming you have evenly x-axis spaced points. Tim

QUOTE (Rock4 @ May 28 2009, 10:58 AM) It sounds as if you're having more fundamental generic programming questions then you are having problems with LabVIEW. I think you're best bet is to look at fundamental programming tutorials and speak with someone one-on-one. I'd recommend doing that and read through "LabVIEW for Everyone". Tim

QUOTE (Rock4 @ May 27 2009, 11:54 AM) Thank you for mentioning you're a student and trying something first. You'd be better off attaching the VI rather than the Word document; the Word document is a little hard to read. Yes, you have a lot of bugs in your code. To specifically address your issue, the value of the Inlet Valve Open/Close control is only read once since it is not inside any loops. For what you're doing, you should only need one or two while loops and not the overall loop. I'd recommend turning on highlighted execution and watching how the data flows on the block diagram and what happens to the data using probes... you'll learn a lot from doing that. There's a lot of books out there. I haven't read any, but there is a list at http://sthmac.magnet.fsu.edu/labview/basic_labviewbooks.html. I expect there'll be a few opinions on good books. Tim

QUOTE (jed @ May 27 2009, 12:25 AM) My inclination is to fix a hardware problem in hardware. The first thing that comes to mine is that a 5B module takes in a differential signal and outputs a NRSE signal. You'd have to reference it to be exactly like your other channels, but that shouldn't be an issue. Tim

QUOTE (Michael Malak @ May 26 2009, 06:26 PM) You can effectively make a splitter invisible by using the splitter from the Classic pallet and then making it the same color as the background. The Modern pallet splitter will have a 3D effect, the Classic is flat. Tim

QUOTE (Warren @ May 20 2009, 03:18 PM) Typically I would have a digital input in the form of a PCI card, remote I/O, etc., and I would wire the switch to that. Then it would be a matter of communicating to the card/bus and getting the state of the input. This would be a preferred method. You can get a USB based solution for about 100 USD. You can use a parallel port as a digital input device. A little web search should provide you with the information you need. There's risks to doing this such as blowing out your parallel port or (if you're really unlucky) your motherboard. This does assume your PC has a parallel port. Tim

QUOTE (Gabi1 @ May 16 2009, 07:37 AM) Is there a reason you need to install the latest version of the driver? It may benefit you to "standardize" on a version of the driver, LabVIEW, etc. You may want to look at using virtual machines and performing your development in those, especially if you have different versions of the drivers. Tim

QUOTE (lovemachinez @ May 14 2009, 10:54 AM) LabVIEW does not operate the way you are thinking. The data is contained "on the wire". I would recommend looking at shift registers for next-loop operations. Tim

QUOTE (xShadowDanx @ May 7 2009, 10:56 PM) You can wire a control that contains the milliseconds to delay to the Wait primitive. You could also have a control that has seconds (which more operators understand) and then multiply by 1000 to get milliseconds. Tim

QUOTE (Black Pearl @ May 5 2009, 06:36 AM) We've got a similar albatross with our customers... it's called simultaneous engineering (SE). For anyone not familiar with SE, it's akin trying to build a cart that will sit perfectly level forevermore while the horse is still growing. There are pieces we know we'll use... calibration, communication to a PLC or remote I/O, error management, etc. These become part of the library. Anything we create gets looked at and we try to see if it's a one-shot item or something we'll re-use. Sometimes what we reuse is surprising. Getting an initial specification is tough. I like to mock up screens, create a little Powerpoint and write-up of how it'll work and get sign-off on that design. The signature is the critical part as anything after that is a change and is chargable. Paper trails of what changes were desired and approved provides documentation as to why things are more expensive, taking longer, etc. I've heard this refered to as "managing the customer". Tim

QUOTE (esqueci @ May 4 2009, 11:15 AM) I've used two ways to solve this issue... The first is to call a function in the DLL that programmaticaly executes another VI inside the DLL. This can be fairly self-contained and you can use function calls to interact with the parallel loop (including terminating it). A static reference to the looping VI works pretty well. The second is to use VI server to obtain a reference to a VI inside a DLL. This can be messier and I would recommend avoiding it as you start dealing with different memory spaces. Tim

QUOTE (JFM @ Apr 21 2009, 02:46 PM) I haven't tried compiling yet. I called NI tech support to try and "get my ducks in a row" before trying this. Support put me on hold to discuss my questions and was informed I couldn't compile without the physical unit. Have I been mislead? Tim

I've got a customer that is very remote (how many miles are between Detroit and Brazil?) who needs an update of the code on the cRIO system we provided them as part of the test stand. I can make the updates to the FPGA and RT portions, but tech support tells me I can't compile them without the physical unit. The only cRIO we bought shipped with the test stand. I'd like to be able to compile the update to the cRIO without having an identical system on my desk. Tim

QUOTE (Scooter_X @ Apr 8 2009, 10:49 PM) Thanks for pointing out this is for a class. A nudge in the "right direction" is that LabVIEW can sort an array of clusters. Tim

I really appreciate the responses and advice. Thanks to everyone. This has definitely been a challenge in thinking how to structure the application for best performance where there the resources are very limited. At this point I've created three VIs. The first contains the other two. The second performs the clocking, start DAQ, stop DAQ, and passing of data from a global variable (32 element array of U32) over a FIFO to the RT portion. The third VI writes to the global array of U32 from a FPGA I/O node and speed calculations off encoders going to digital inputs. Populating the global with the data and pulling it out at the desired sampling rate seemed the best idea. That was until something started nagging me from, uhm... a decade or so back... about signals theory and sampling. I'm pretty sure I've held onto that text book... time to dust it off!