Leaderboard

I recently spent some time describing a logging tool that we use here at DMC that has significantly reduced our debug times and helped a lot with onsite support and I thought it was worth bringing it up to the LabVIEW community. Essentially, it's a logging utility based off of NLog that allows the user to add the equivalent of print statements to their code - any string that can be built is fair game. It also allows a logging level to be associated with the print statement and this is the concept that makes it extremely powerful. Some statements can be low-level "trace" statements, while others are "warnings" or "errors". During run-time (even in an executable) the level of the logger can be changed and you can easily do trace-level debugging for a glitch, and then set it back to an informational level afterwards. Multiple targets are supported, including RT console, log files, TCP/UDP streams, and email. All the calls are made asynchronously, so the debug statements have a minimal impact on the code execution. At this point we are finishing and polishing the implementation, but more information and details can be found in a blog post I recently wrote: NLog for LabVIEW: Logging done properly -Jody Koplo

Glad to hear to found the right solution for you. It really comes down to what device does what you want to do and does it well. It really does not matter which one has the most RAM, CPUs, ports, etc. If it does not do it's job well (web browsing, email, apps, whatever) then all the 'spec's in the world do not matter. The best thing you did was to try them side by side. Same thing goes for smartphones. Now, if you have kids, you will need to buy a second iPad. I cannot get mine away from them. At least the apps they love are teaching math, reading and basic physics. I have high hopes for the next generation of engineers who have had much better access to information than we did. Now to just get LabVIEW running on a tablet...

I have found removing the mutation history resolves all sorts of LVOOP ills. It doesn't always work, but sometimes it does--often enough that it's usually the first thing I try.

You may have luck by opening just the class and editing it by itself (no project open). Having as little as possible open seems to help LabVIEW not get into some infinite loop. Tim

Yea, I've had similar problems. It's been to where I had to open the "offending" VIs outside of the project, correct the issue and save before I could load the project without Bad Stuff happening. Tim

QUOTE (Mark Yedinak @ Jan 21 2009, 11:36 AM) If you are talking about the MS RPC protocol you may want to think again about that approach. This is not just a simple protocol but the full blown DCE RPC specification with MS proprietary extensions. The various network protocol layers that this all can be embedded in each other, and the various security providers that the different layers can use including several encryption layers will likely make this a never ending project to be implemented in LabVIEW. As Mark has explained RPC is just a term used for anything that can allow remote execution of code through some kind of network connection. In that sense even VI Server is an RPC protocol. So you really need to find out the dialect of RPC you are talking about. Rolf Kalbermatter

Hello Bjarne, Accessing an OPC server on a remote computer requires configuration of the DCOM interface and this is - at least for me- not an easy task. There is a configuration white paper available on the OPC foundation home page. I remember that even this detailed white paper is not complete when the OPC server computer is not included in a Windows domain. The problem gets worse when the active user isn't an administrator. OPC is nice but very complex for a technology that is used by many developers who do not have the time to configure firewalls and access rights :-0 I didn't think it was possible to run an OPC server on a realtime OS like VxWorks. I'm not sure if this will solve your problem as I don't understand the problem you are describing. I only have tried it on Windows only platforms and without reconfiguring various DCOM objects and access rights it was impossible to use or browse any OPC tags on a remote computer. I've even had an OPC server that I could never access over the network, using it on the same computer was the only solution. A solution could be to create an extra LabVIEW process on the remote computer that uses the LabVIEW data sockets or a custom made TCP or UDP server solution. This was a workaround for a Linux LabVIEW solution I had in mind for a die hard unix customer. I would say good luck. I hope you let us know if the solution of Tom L. works for you! Venlig hilsen Donald