george seifert

My favorite 8.0 feature that nobody talks about is the gravity well that aligns labels with terminals on the block diagram. I use that hundreds of times a week and it makes the life of my cursor keys a lot easier (and longer).

Yet another 8.0 feature that nobody talks about is the DIAdem Report Generation Express VI - which is partly because not everybody has DIAdem installed. So I have made talking about it really easy by videotaping it for you :thumbup:

Have fun,

Herbert

Great post. Thanks for doing that.

George

I thought this code use to fail (probably an earlier version of DAQmx) if I used a DAQ card that didn't support PFI12, but now I don't get an error. Why does it let me send a string like /Dev1/PFI3:12 to the "output terminal" input of the DAQmx Export Signal VI if I can't select /Dev1/PFI12 from the list in the "output terminal" control?

George

Maybe here:

VISA\Serial Instr\Version INformation\Resource Manufacturer Name

Found it with the class browser (ctrl-shift-b):

Ton

Nope. That returns the VISA manufacturer. In this case National Instruments. I've tried every property in the list.

Rolf, I don't really want to go the Windows API route, but I don't see another way.

George

Checkout VISA properties. If you have a VISA refnum you can get various properties for that and the Interface Information->Interface Description should contain extra information in the string for other than built in serial ports.

Rolf Kalbermatter

Thanks Rolf, but I tried that. The Interface Description just returns "COM4 - USB Serial Port". Not quite enough to narrow it down. I went through all the properties and none of them give me anything useful. I suspect I'd have to use some type of Windows function, but have no idea which one and have no idea how to figure out which function I need.

George

I have a USB device that comes with a driver that makes the USB port look like a COM port. I'd like to be able to automatically detect which COM port it picked. The only way I can see to do that is to match something like the Driver Provider that shows up in the Driver tab under the COM port properties in the Windows Device Manager to the manufacturer of the device. I don't have a clue how to retrieve that info. Can anyone get me started?

George

Thanks for the inputs. That helps a lot.

George

I'm not sure if the topic title fits exactly, but it sounded kind of impressive. I'm just looking for a general idea here of a direction to take. Any thoughts are welcome.

I have 4 channels of data that I want to sample for 15 msecs. When I start sampling each of the channels depends on a corresponding independant trigger that the code will initiate. For instance, trigger 1 happens so sample channel 1 for 15 msecs. Trigger 2 happens so sample channel 1 for 15 msecs. The triggers can happen any time in relation to one another so for instance trigger 2 could happen during the sampling of channel 1. Part of the problem might be that I have existing DAQ boards I need to use that don't have parallel DAQ inputs.

I was thinking that I have to do a continuous acquisition of all channels and then somehow pick out the data of interest based on a timestamp of when the trigger happened. Does that seem reasonable or is there a better approach?

Thanks,

George

Thanks. Lots of good stuff there to consider.

George

I need to get info from the user regarding a test sequence. I put the attached control in an array so they can setup several different parameters for a test. They'll select a Type which then determines the additional info needed. So for each entry in the Type enum I have one or more separate inputs. It looks a little clumsy because there are a number of inputs. I could pare down the number of additional inputs and have some of them do double duty, but that would add to the confusion I think. Ideally only the required additional inputs would appear based on the Type selected (or maybe the required additional inputs could change color).

I know someone's going to say this sounds like a job for Xcontrol, but they confuse the heck out of me. Also I don't know how or if they would work in an array. Any suggestions would be welcome -even votes for Xcontrol.

George

Download File:post-2786-1163688073.ctl

The 8.20 exe builder allows setting of a version number. Is there any way to access this programmatically within a built app? I tried the App version property but it returns the LV version.

Here's a subVI that I use to get the info.

George

Download File:post-2786-1158324922.vi

As mentioned in another post I'm having a problem in LV 8.2 using the PSP protocol with a datasocket read to read a shared variable published by another executable. I'd like to ask a different question in that regard. Is there a better way to share variables between two LV executables residing on the same PC? I think using the datasocket read was the only way I could do it in LV 8.0.1 without some fancy add on module (I forgot the name of it).

Thanks,

George

I have two applications that communicate by one VI publishing a shared variable and the second application reads the variable using a datasocket read with the PSP protocol. This used to work fine under LV 8.0.1. Now that I've switched to 8.2 it doesn't work anymore and gives me the following error:

Error 1181 occurred at DataSocket Read in Time Lapse.vi

Possible reason(s): LabVIEW: Protocol not recognized by LabVIEW.

NI so far hasn't come up with a solution. Has anybody else had trouble with this?

George

I'm pretty sure you can't. I think they did add that in 8.2 though.

I have LabView 8.0 with a good sized app. I've tried all the suggestions in the prior posts to get rid of the "insane errors" that suddenly cropped up. Nothing has helped.

I haven't seen the previous posts, so I don't know if this came up. This appeared on the NI forum. It worked in one case for me. I had another problem once where a timed loop went bezerk on me. I was getting tons of insane objects. I finally tracked the problem to the timed loop. I replaced it and that solved the problem.

George

The insane objects question comes up from time to time. Here is one way to find the particular problem:

1) Close LabVIEW

2) Put the key "LVdebugkeys=True"in the LabVIEW.ini file

3) Open your VI

4) Press CTRL+SHFT+d, then press CTRL+SHFT+h (I had to press CTRL+SHFT+h+d).

This will turn on an object browser.

5) In the top left list box, select the element that contains the name of your VI and the letters BDHP

6) In the top right listbox, find the line that begins with the error number.

7) Click on the F button to find the offending object.

8) Delete this object and recreate it. It will ususally be a wire.

Bob Young - Test Engineer - Certified LabVIEW Associate Developer

DISTek Integration, Inc. - NI Alliance Member

e-mail: BobY@DISTek.com

Has anyone had problems with timed loops causing crashes? I get really bad crashes - the reboot kind. If I disable the timed loop or replace it with a regular loop with a time delay, then everything is fine so I know it's the timed loop. This has happened in several different situations so it's hard to give an example. It happens with hardly anything in the loop or more complicated code inside it. I'd just replace the timed loop with a regular loop, but it's handy to be able to stop the timed loop when using parallel loops.

George

I have a timed loop that can have a time between iterations of up to several minutes. I want to be able to stop the loop when the user presses a button. The way I stop the timed loop now is by monitoring the button in another faster timed loop (1 sec). When the button is pressed I stop the fast loop and then run the Stop Timed Structure VI to stop the slower loop. I'll stop the slower loop also if an error occurs there in which case I then have to run the Stop Timed Structure VI to stop the faster loop. This seems a bit convoluted and was wondering if there's a more elegant solution.

I'd like to be able to change the background color of a numeric control in an array. I can't find any properties that will let me do that. Is is possible?

George

I'd like to be able to change the background color of a numeric control in an array. I can't find any properties that will let me do that. Is is possible?

George

I fiigured it out. I wasn't downcasting properly. It's not enough to use the Numeric class specifier when using the "To More Specifc Class" VI. I had to create a reference from the actual control.

George

A tip for those that try this toolkit with LV 7.1/8.0:

I had to change one of the property nodes in four VIs to make this library mass compile. Inside excel.llb, you'll find the "Excel write string/numeric" and "Excel read string/numeric" VIs have a broken property node pointing to a "Range->Value" property. Change this to "Value2" and the VIs should work.

Joe (orko)

I think the problem is an Excel version issue rather than a LabVIEW version issue. I had the exact same problem using the LV Report Generation Toolkit when I switched to Excel 2003 from Excel 2000 (or maybe it was Excel 2000 from the previous one).

George

I need to send someone an update to an application. Assuming that nothing changed about the additional installers is there any way to send just the code update? Would it even be possible to send just the .exe file assuming they did a full install of a previous version?

George

Write your first application and have it include a library with your variable in it. Choose to have the library automatically deployed.

Now you have three options:

1. Assuming that you prefer to have the ability to choose the variable to which your 2nd application connects at runtime, place a shared variable control (located on the I/O palette) on the front panel of your application. Clicking the drop-box control you will be presented with the option of browsing the variable space. This will allow you to choose the variable to which you are connected. The output of this control must be wired into a datasocket read/write (depending on whihch you want to accomplish.)

2. You can determine the URL of the variable from the 1st application and wire that as a constant to the datasocket read/write rather than having the control on a front panel.

I just tried using the datasocket to do the shared variable read. I fed the URL of the variable I'm reading into the "connection in" input and the type of my shared variable into the "type" input. I'm getting confusing info back from the Datasocket Read VI. The "quality" indicator reads 0. The help says that means "The data item is of good quality". However I get an error 42 (general error) from the VI, which tells me nothing. The URL I used is the same one I used if I use Bind to Source and it reads the shared variable fine that way. Any more hints on how I can programatically tell my VI where to read the shared variable?

George

... but unfortunately I still haven't be able to check it, because the shared variables crash my PC :-(.

Saludos,

Aitor

I've gotten shared variables to work between VIs in two projects with a small example. Now when I scale it up to my large project, LV crashes when I have both VIs running and the code gets to the point where it's trying to write to the shared variable. I backed out the shared variable of each project and the VIs function fine independently. When I put the shared variable back in it crashed again. Has anyone else run into this? Seems to me that the size of the project shouldn't matter.

George

Write your first application and have it include a library with your variable in it. Choose to have the library automatically deployed.

Now you have three options:

1. Assuming that you prefer to have the ability to choose the variable to which your 2nd application connects at runtime, place a shared variable control (located on the I/O palette) on the front panel of your application. Clicking the drop-box control you will be presented with the option of browsing the variable space. This will allow you to choose the variable to which you are connected. The output of this control must be wired into a datasocket read/write (depending on whihch you want to accomplish.)

I got hold of an engineer at NI that sent me an example of how to do it with "Bind to Source" (I asked him to make it available as an example). It was really pretty easy. It seems like that way would be a lot easier than having to include a datasocket read. I thought shared variables were supposed to take the place of datasockets.

George

Do not use "Bind to Source"...this allows you to have the variable connected to hardware. If you are familier with previous versions of the DSC module, by not binding you have the equivilent of a memory tag...your appplications can both read and write to the variables which seems to be what you are looking for.

Unfortunately, I don't have any experience with the DSC module. If I don't use the "Bind to Source" then how do I tell the second executable how to access the variable?

George

DSC includes an example for using this feature. Go to the examples directory/lvdsc/Event Structure Support. This should do a pretty good job getting you started.

Hmm, I don't have a lvdcs subdir in the Examples dir. Is the DSC module a special addon?

George

I don't know about shared variables, but I assume you should be able to do this through VI server by getting a reference to a control and using the Value (signaling) property.

Nope. That doesn't work between executables.