Mark Smith

I passed my CLD

Lucky for me, Michael didn't get to grade my exam - or maybe his advice kept me from making silly mistakes!

Thanks to all for the feedback and help - LAVA is a great community.

Mark

QUOTE (Mark Yedinak @ Feb 5 2009, 12:13 PM)

You might be write but I can't imagine anyone creating a networked device that isn't intended to sit on a real network. My entire professional career has been in the network world and the thought of duplicate IP addresses makes me cringe. You may be right and this is intended to be the equivalent of a hard wire replacement but I don't see the logic in anyone doing this. The beauty of a network is that you can place equipment anywhere and be able to communicate with it. Once you are on the network you should play by the rules. Anyway, that is the network guy in me talking.

I think the reason instrument manufacturers do this is cost and performance. It's really inexpensive compared to GPIB (I just did a quick google and found a network interface chip for <$5 and a GPIB chip for around $30) and all personal computers come equipped with a NIC (a GPIB Interface Card could set you back a few hundred dollars). Also, 20 feet of Cat 5 cable w/connectors is at most a $10 item and a 20 foot GPIB is more like $100. So this has become the "new serial" port for some vendors (of course, USB is really the "new serial" and some vendors use that). So these aren't really "network" devices in the more conventional sense (someone from across the country connecting to my Tek Scope is kind of pointless) , they're just devices leveraging cheap communication technology.

Mark

QUOTE (Mark Yedinak @ Feb 5 2009, 11:45 AM)

This is useful information but it is still a very bad idea to give the same IP address to all of the clients. This can cause some major problems on your network. Duplicate IP address can lead to routers and switches on the network having bad routes and can create data loops and circular routes within the network. Worst case this can bring a network down. If the IP addresses of these clients can be seen by network I would strongly recommend against using duplicate IP addresses. From a network perspective you are asking for trouble.

Mark,

I'm gonna guess that you and I are working from the same paradigm where we see TCP/IP and client and we start thinking about servers and distributed apps and networks. But I think that this problem is just one of local instrument control where a Ethernet and a NIC can replace a GPIB cable and card. So this is like having to address four instruments that all have the same GPIB primary address that can't be changed (I know that doesn't make any sense, but then again I can't imagine an Ethernet-enabled instrument where the IP address can't be changed, but that's apparently the case) by addressing four separate GPIB controllers so the VISA string might look like

GPIB0::2

GPIB1::2

and so on.

But I'm extrapolating here, since we haven't heard back from jbhee on this!

Mark

Edit: also what Phillip said (he got that in before I posted)

QUOTE (OlivierL @ Feb 5 2009, 10:45 AM)

There is an easy way to open a TCP connection using the TCP interface of your choice. I can't find the code I wrote in the past using this technique but I'm 98% certain that this is right though:

Use "VISA Open" and specify the Ressource Name to be: TCPIP SOCKET TCPIP[board]::host address::port::SOCKET TCP/IP Socket

[board] allows you to select which interface you wish to use. You can then talk to the device using regular VISA VIs. For more information, look up "VISA Resource Name Control" in LabVIEW help files.

Hope this helps.

Olivier

That is very interesting! I've never had occasion to use TCP/IP for instrument communication, so that one went right past me. Do you know of any examples using VISA that implement a client/server? Not that I have a real need, I'm just curious.

Thanks,

Mark

QUOTE (Ton @ Feb 5 2009, 07:50 AM)

That is no problem, this is all done in compile time (the name of the event is part of the 'wire').

Ton

I was thinking more if your event datatype changed and you did not update the control/constant wired to the "Type" input you could get some really interesting run-time results!

Mark

QUOTE (nicolasB @ Feb 5 2009, 06:14 AM)

Hello,

I've created a variable manager in a functional global which generates a user event for each changed rsp set variable.

The attached code is an example reduced to the minimum.

It works fine but my question is if any of you see a possibility to get different names for the user events.

Like you can see in the "MyVar1 and 2 Indicator.vi" both user events in the event structure have the same name and this is very inconvinient when the number variables/events increases.

regards,

nicolas

It appears the event name in the event handler structure is going to be the same as the name of the control that it references. So, the only way I see to do this is to get the event in the called VI and load it into a control with a new name and then use that control to register the event. I don't really like this (it requires loading the control with a local variable or property node since just passing the data thru the control won't affect it) but it does work - see attached VI. Maybe someone else has a better idea.

Mark

http://lavag.org/old_files/post-1322-1233843289.vi'>Download File:post-1322-1233843289.vi

OK, the typecast looks interesting but I think it would require care to make sure you don't get a run-time failure from an improper cast

QUOTE (jbhee @ Feb 4 2009, 10:11 AM)

Thank for your answer, in fact I have a network card with 4 Ethernet ports with IP1, IP2, IP3 and IP4. On each port I connect products which have a fixed and unchanged IP, this IP is the same for each product. So I have 4 different networks (IP1 <-> IP, IP2 <-> IP, IP3 <-> IP, IP4 <-> IP) and I must open a TCP communication with each product and the PC. I have used the VI TCP Open Connection but I can put anly the client IP and I don't put the host IP (IP, IP2, IP3 or IP4), so I don't know which product is. Which is code I can use to put the IP client and the IP host to create a TCP connection ?

Sorry for my poor english, thank for you answer,

The short answer is "you cannot" - LabVIEW does not expose an interface to allow selection of a specific interface for outbound TCP/IP packets. And that's because the OS does the selection. Here's a little more info

http://digital.ni.com/public.nsf/websearch...5E?OpenDocument

http://support.microsoft.com/kb/175396

It appears you may be able to do some command line programming to set temporary routes

http://www.tech-recipes.com/rx/478/nt2000x...-routing-table/

and set the route "if" parameter to force a specific interface

QUOTE (ejensen @ Feb 4 2009, 10:11 AM)

... I have noticed that when it returns the error, it removes any old files from the build that were in the destination directory, but doesn't replace them as it would on a successful build...

An error has occurred. Expand the Details section for more information.

Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:

Error 10 occurred at New VI Library.vi

Possible reason(s):

LabVIEW: Duplicate path.

=========================

NI-488: Asynchronous I/O operation in progress.

I think you explained pretty well what happened - the app builder tries to write to some path (llb?) that already exists. The app builder fails, then cleans up after itself (I don't think it wants to leave any half-written files laying around). The next time, that path doesn't already exist so the app builder succeeds. I don't know why it won't overwrite or any of those details, but it sure sounds like the builder would succeed the first time if you clean out the destination folder first.

Mark

QUOTE (nitulandia @ Jan 29 2009, 08:25 AM)

Hi,

First, thank you for the comments.

In regards to your comment, yes, that is the observed behavior. "OK - so if you put the DLL in the requested path, it works the next time you call the VI - but will it fail again later looking for the same DLL but now in a different path? That's what I think I read".

It is very likely that this will fail again if I shut down-and-up my machine, however, I'm not able to reproduce this all the time. The only way I can get it to fail every time is if I completely remove the .dll from the last expected path.

And yes, I have all the vendor's dlls in the same location where my VIs are. And, all of these have also been added to my LV project.

BTW, my vendor is aware of the issue... and of course, the "finger pointing battle" has already begun. They claim that the issue here is LabVIEW :-) I'm planning on posting the solution to this issue once the root cause is found. For now I need to educate myself a little more on .NET assemblies, thanks for the link.

Cheers,

Eddie

It's a long shot, but I found this instruction in the LabVIEW 8.6 help

"If you reference a .NET object from a VI that does belong to a LabVIEW project, the CLR considers the project to be the running executable. The CLR therefore searches for private assemblies in the project directory"

So if all your DLL's aren't in the same directory (and at the same level - not in subdirectories) as your lvproj file, try putting them there. Seems I'm rapidly running out of ideas!

Mark

Thanks for the explanation - Paul obviously understood the problem better than I did. Good luck!

Mark

QUOTE (nitulandia @ Jan 28 2009, 04:55 PM)

Hello Mark,

This is the error msg:

"Error accessing property EieParallelTest.TestManager.Api.Interface.IEnvironment.Controllers of ObjectId handle: 0x5A5115C for obj 0x2B8BB1[EieParallelTest.TestManager.Environment] in domain [LabVIEW Domain for Run] and thread 7464, (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.

Inner Exception: System.IO.FileNotFoundException: Could not load file or assembly 'file:///C:\Documents and Settings\user123\ABC.dll' or one of its dependencies. The system cannot find the file specified.

) in PROOF OF CONCEPT2.vi"

The error code returned is 1172.

If I manually put the ABC.dll in the path, my VI will work.

OK - so if you put the DLL in the requested path, it works the next time you call the VI - but will it fail again later looking for the same DLL but now in a different path? That's what I think I read. And that is really pretty strange - sounds like the .NET assembly (DLL) may be buggy. Or, does it just take it a while to fail again? Since you said the problem is random, maybe it just works for a while because it doesn't try to execute that method? That is possible because a method invoked by reflection won't cause any problem until it is actually called at runtime - it's not like a DLL that loads when the calling application loads so if it doesn't get called the app could run for days if that particular method doesn't get called.

Anyway, there's nothing your LabVIEW code is doing to cause this - it's all happening in the .NET assembly so it may be up to the vendor to fix it. But here's a link to how .NET resolves paths to private assemblies

http://www.ondotnet.com/pub/a/dotnet/2003/...dingpolicy.html

The easiest way to deploy a .NET DLL is to include it in the same directory as the exe since that's always the first place .NET looks for it. So, if they aren't already there, try putting all the DLL's in the same directory. That should force the calling DLL to at least look for any dependencies there.

Mark

I guess I'm not quite sure what the product you want to deploy actually is. If you need communication between two LabVIEW based programs running in separate execution threads, then what Paul has suggested makes a lot of sense. I had interpreted the need as more of an application with an API for LabVIEW developers. To do this and still protect your IP, you could deploy your project with a set of VIs that have either password protection or no block diagrams. Then the LabVIEW developers that want to use your application would just add those VIs to their block diagrams and that would be that. To run your app stand alone, you would just need to include an exe that called whatever - it could call into your library of VIs or it could just be self-contained. But it seems a little convoluted to deploy an application written in LabVIEW for LabVIEW users and then not provide the ability to load VIs that link to that app into a block diagram. But it's altogether possible I don't understand the problem

Mark

QUOTE (nitulandia @ Jan 28 2009, 01:59 PM)

Hello Mark,

The errors are being generated while the VI is running. I've attached a .bmp which shows for example, where the exception is coming from, and the error msg described previously. Note that it IS NOT always the same method that throws the exception, however, it seems that it is always complaining about the same DLL though. In other words, even though I have 7-8 dlls, LabVIEW wants to see the same abc.dll in different locations.

Thanks for the info - this probably isn't what I first suspected, so I'll ask more questions. You describe the error as a LabVIEW error and as an exception - is it indeed an exception thrown by the .NET assembly? Or is it an error generated by the LabVIEW call? Can you attach the error message and error code?

Thanks,

Mark

QUOTE (nitulandia @ Jan 28 2009, 10:31 AM)

Hello,

My LV ver: 8.2

A vendor has given me some instrument drivers in the form of .NET DLLs (several DLLs). I've been able to sucessfully write wrappers (.VIs) around them, and all seem to be working fine.

The issue I'm running into is the following: very randomly, an exception is thrown by the DLLs (I still don't know why that is). The LabVIEW error describes more or less the following: "Cannot find abc.dll at C:\Program Files\etc etc" . If I manually copy the DLL to the expected path all works fine once again. However, the error will show up again after a while, and this time, it wants the abc.dll at some other location. Again, if I manually copy the DLL to the expected path all works ok.

I've looked into "registering" the .NET DLLs up front, but so far have not been able to find a way to do this.

LAVA gurus, any pointers will be much appreciated.

A couple of questions - do these errors happen while the VI's are executing? Or do they happen after a VI that calls a .NET DLL is closed and then re-opened? I'm guessing the latter but more info would help me understand

Thanks,

Mark

A couple of ideas

1) Build the core program as an actual DLL (using the option in the LabVIEW Build Specifications in the Project Explorer to create a Shared Library). This exposes whatever API you have into the core program as conventional C/C++ functions. It's a good way to create core app that could be called from different languages/development environments. Calling it from LabVIEW then requires using a CLN.

2) If you're only going to run the core app standalone or controlled from LabVIEW, then you could deploy the app as a library (folder or llb file) and define some VIs as the API. You could then have a VI that serves as a caller for the core app built as an exe that would run standalone or you could call into your library of VIs (your API) if you want to build a specific UI.

Mark

QUOTE (Mourad @ Jan 22 2009, 08:36 AM)

ThanX Mark I got somehow connected when I changed the cable but now when I tried to scan for Connected Instuments it gives me a peeb and Error No. 511 (framing error). I tried to have same configuration as in the manual (9600, 7, Even, 1, Hardware) both sides but same error.

Any Idea?

Now I got error no. 513 (parity error).

These errors sound like communication errors caused by misconfigured serial port settings - if the start and stop bits aren't correct the data frame will be wrong. If you're not using the latest driver from NI (the plug and play one) I would get it because it seems to have the most complete and automated handling of all the possible serial port settings for the host. For instance, it tries to handle whether or not flow control is supported automatically. Also, your cable may still be incorrect - have you tested pin-to-pin to make sure it matches the diagrams in the user manual?

Mark

QUOTE (Mourad @ Jan 22 2009, 02:19 AM)

I checked "Find Instument drivers" and nothing under connected inst. but under installed drivers there are two inst. Agilent 34401 and HP 34401. Also under MAX i tried to read from Basic I/O but nothing returns and return status is xBFFF00015

I check serial port setting both under computer and HP and the are all same.

That error is a VISA timeout, so it means your instrument is not responding (and probably not getting your command string, either). If MAX indicates that your COM port (ASRL1::INSTR as the resource name) is working properly (and that is the one you are using) and you have read the HP34401A manual and you are sure it is configured properly for serial communication then I would next suspect the cable.

From the Agilent 34401A Manual

"Connection to a Computer or Terminal

To connect the multimeter to a computer or terminal, you must have

the proper interface cable. Most computers and terminals are DTE

(Data Terminal Equipment) devices. Since the multimeter is also a DTE

device, you must use a DTE-to-DTE interface cable. These cables are also

called null-modem, modem-eliminator, or crossover cables.

The interface cable must also have the proper connector on each end

"

Mark

QUOTE (Mark Yedinak @ Jan 21 2009, 09:21 AM)

The chassis I want to control only uses your basic RPC. They do not support XML-RPC. their commands are documented but I the mechanics of the RPC for sending the commands. I looked at the RFC specs for RPC and could work from those but if someone has already done this it would make my life easier.

I can also capture a network trace of their GUI communication with the chassis and reverse engineer the communication. I will go down this road as a last result though.

OK - so this is the ONC RPC as specified in IETF RFC 1831 (that's a pretty ancient standard in computing years)? I guess I'm still a little confused because to the best of my knowledge there is no "basic" RPC. RPC (Remote Procedure Call) has been implemented a thousand different ways - SOAP, CORBA, Windows Remoting, etc, and in the grand tradition of computing none of them are compatible with any of the others! So, I don't really have anything else to offer except encouragement!

Good Luck!

Mark

QUOTE (Mark Yedinak @ Jan 21 2009, 08:30 AM)

Has anyone implemented the RPC protocol in G to control external applications via RPC? I am looking at automating some tests using an external chasis which can be controlled via RPC calls. I would like to use LabVIEW as the automation platform to leverage our current code bas for communicating and controlling the product under test. I have seen the LabVIEW XMPRPC server but that is for controlling LabVIEW via RPC, not the other way. Any pointers or suggestion would be appreciated.

Thanks

Mark,

I'm making the assumption that you're talking about the XML-RPC server project in the CR? If so, that does include an example of creating a LabVIEW call into an XML-RPC server. You are correct that this project mostly supports the server side, but it includes all of the stuff you need to pack XML-RPC into a request for any XML-RPC server and parse the response (see the Call Generate Sine Wave.vi for an example). But, you first just call it RPC, so I'm not clear exactly which RPC implementation and protocol you mean - there are lots of them and the XML-RPC project only supports one!

Mark

QUOTE (Eugen Graf @ Jan 21 2009, 03:51 AM)

Hello LAVAs!

What is the best solution for the following problem? If I use VIs for overriding, so they have to have the same name. But if I create a executable I get name conflicts, because two VIs with the same name can't be saved in one (exe) folder.

Next question is: if I want to have VIs with the same name in two different classes I have the same problem (name conflicts), so I have always to use prefix in the members. Is there an another better solution as to use prefixes?

Thank you, Eugen

LabVIEW has some real underlying issues with the namespaces (classes, lvlib) and building into an exe - just try building an app using a lot of the new plug and play instrument drivers that use the same VI names for things like Configure, Read, etc and differ only by location on disk (they all reside in different folders) and owning library. You'll get a built app that may have half a dozen folders deployed so that each VI can still have a unique name. It looks pretty ugly, but I'll give NI credit - it does work. Still, this doesn't look like a good long-term solution since a LVOOP app will be even worse - if you have a lot of override VIs in a large app, I can see where you could get hundreds of folders in a deployed app. So, it appears we have a LabVIEW dev environment that uses namespaces but a compiler/linker that really does not - as you pointed out, each VI name must be a unique path. You can achieve that by prepending something to the name, or you can just save your child classes in unique directories - then the complete path to the overridden VI is still unique. The app builder will maintain this unique path (even though it will report a name collision) but it will create as many deployment directories as you created for the child classes.

Does anyone have any insight as to what the long term vision is for this issue? I'm curious.

Mark

QUOTE (Mourad @ Jan 20 2009, 11:58 PM)

I have attached the vi file, thanx in advance.

The first thing I noticed when I opened your file was that it is pointing to a LLB file in the instrument lib folder for the sub VIs - that means it must be pointing to an older version of the instrument driver - the latest version is a NI plug and play driver.

Second I noticed that the resource name is an IVI typed control - this probably means that your version of the driver was converted from an IVI driver (which could be fine) but the first thing I would try is to replace the IVI driver with the LabVIEW plug and play driver.

http://sine.ni.com/apps/utf8/niid_web_disp...?p_model_id=978

Third, the default value in the resource name is a GBIP address - are you using serial or GPIB?

Next, does the instrument return the correct response string to the *IDN? query in the Initialize? If it does, then you are probably communicating correctly with the instrument - if not, then you first need to figure out how establish communication before you try to make a measurement.

Try these things and let us know if it helps.

Mark

QUOTE (Michael_Aivaliotis @ Jan 19 2009, 03:06 PM)

Regardless of your fancy footwork, I would fail you because your app is dead in the water right from the start. I can't even run it because you've hardcoded a path to a VI:

http://lavag.org/old_files/monthly_01_2009/post-2-1232402565.png' target="_blank">

If your app doesn't work out of the box, it's made of FAIL. It's like going to an audition on American Idol and you forget the lyrics to the song.

Thanks for the observation - that's the stuff I need to hear

Mark

QUOTE (gleichman @ Jan 19 2009, 01:09 PM)

How long did this take you? My advice is keep it simple and get it done. Clean code with good documentation. Clever will waste your time and leave you with an incomplete project that isn't fully documented.

One quick comment, the "Standard State Machine.vi" has a three deep case structure in the "Update" case. Use the "select" function in the comparison palellete for a cleaner and more readable vi.

I spent about 3.5 hours on the project (4 hours on the clock but with interruptions) - There was certainly no intention on my part to be clever - I've just spent a lot of time lately with scalable architectures using reentrancy so that's the first architecture that came to mind that I was sure I could code start to finish. What took longer than I thought was re-acquainting myself with the LabVIEW FileI/O VIs to create the logger part of the problem . I just haven't used them in a while and they've changed!

QUOTE (jcarmody @ Jan 19 2009, 01:39 PM)

Thanks to both for this tip - it is a lot easier to read. And as far as system labels, I had to go google that to find out what it was (took me to the LAVA WIKI!)

Mark

QUOTE (Ton @ Jan 19 2009, 12:08 PM)

Impressive and advanced solution with reentrant VIs. (points for that).

Easy comment:

No documentation on the BD of the GUI VI. (esp. in the event structure)

No on-line help on the led-status of the GUI VI.

I just ran out of time! So that is exactly what I would have had to submit and I guess I would have been dinged :thumbdown:

QUOTE (Ton @ Jan 19 2009, 12:08 PM)

I often make the User Interface VIs the dialog color (even though they may not be dialogs) because

1) It looks more "native" to windows

2) And it helps me immediately identify the FPs the end users will see

Is this considered poor style by the LV community?

QUOTE (Ton @ Jan 19 2009, 12:08 PM)

I like that - it does seem cleaner - I'll have to remember this

QUOTE (Ton @ Jan 19 2009, 12:08 PM)

Thanks for the feedback - I've been doing LabVIEW a long time but one can never do too much prep for an exam.

Mark

Download File:post-1322-1232389172.zip Anyone have time to take a look at my Security System implementation (the sample CLD app)? I'm taking the CLD Thursday and would appreciate any comments.

Thanks,

Mark