iannicholson

I should have done that a long time ago.

Please follow this link.

Better late than never! Thanks for working on this.

Any chance you were able to fix the error? This package still doesn't install properly (in VIPM it claims there is a missing dependency, but it doesn't find one to install).

0_o,

Thanks for the info, but I'm not sure that helps. This is occurring before the Welcome screen; isn't that what skipNavigatorDialog=True would suppress?

Also, this apparently is a different dialog from that controlled by "Show the login prompt at LabVIEW Startup time", as I get an additional login dialog with that option checked

crelf,

Thanks for the answer, but I already have that unchecked. Please see the screenshots below:

LabVIEW 2009 is asking me to log in, with only one user. LabVIEW 8.6 did not do this. Is there a way to disable the dialog? Or is it standard behavior starting with 2009? It is a minor annoyance, but when drop through clicks are disabled, it is tricky to get this dialog to let me past.

No probs.

I am aware of the read-only issue (as I have posted on the thread in one of the links you referenced) and that is one of the reasons I was asking for a screenshot.

JG,

I'm embarrassed; I didn't realize you were the last poster on the thread!

From this snapshot, it says that >=8.0 is supported.

...

I can't check on a lower version at the moment, but what is happening on your install? Please post screenshot etc...

Cheers

-JG

JG,

Sorry, I got a notification of your post as I was submitting my update. Check my edit above! Thanks though!

*SEE EDIT BELOW*

I see that MGI has been updating their (excellent, btw) freeware VI library (http://www.mooregood...abViewStuff.htm). Unfortunately, it looks as though they are publishing versions saved in the newest LabVIEW versions, since the 3.8-10 version doesn't want to install in VIPM for me. This presents me with a problem. I have customers on executables built with 8.6.1, and it is not ideal for me to ask anyone who updates to download the 2009 RTE as well (don't even have 2010 yet).

Does anyone have the latest MGI VIs saved in LabVIEW 8.6.1? If nobody has them available, I can ask MGI, but I don't want to ask too much of them Thanks to anyone who can help.

*EDIT*

I apologize to MGI, but apparently there is a bug in VIPM that may cause this (can be caused by read-only files in the package, among other possibilities). I had the latest two versions on my hard drive, so I tried opening both at the same time, and I was able to install the latest one without trouble. Descriptions here: http://forums.jkisoft.com/index.php?showtopic=1443 and here: http://forums.jkisoft.com/index.php?showtopic=1465.

There's a program called Jing. There's a free download of the app. It allows you to capture video of your clicks, and it works in Windows XP (there's app for doing this built into Windows 7). Just to make sure everyone is on the same page, I'd suggest downloading Jing and recording the SWF file showing the bug and then posting it on ni.com/forums so that a CAR can be made and tracked as necessary. Jing has been very valuable for recording exact steps to reproduce in a couple of CARs I've worked on lately.

Aristos,

I recorded a video with Jing. I found out while doing this that if you mouse over the newly displayed context menu (after a right-click), it apparently clears the selection request. If you don't mouseover the context menu, you get the selection rectangle. Also, this only happens on actual context menus, not tool menus.

Thanks,

-Ian

LabVIEW_RightClickBug.swf

UPDATE: Posted at NI.com here: http://forums.ni.com...le/td-p/1232057

I have not. I just tried my LV 2009 SP1 and 2010 installs. No such bug. I am on a Mac, so that might be a difference.

Aristos,

Thanks for your input here. I am running Windows XP SP3 on a laptop. I have the OpenG package installed and MGI VIs, but not much else regarding third-party addons. The problem is repeatable every time for me.

Yes! Just ran 2010 for a couple hours and that selection thing was driving me nuts.

I use 8.6.1 all the time and don't have this issue.

So you are saying you don't have the "f1" fix installed? (To fix the multiple object Properties page bug)

Is anybody running LabVIEW 2010? Do you have this issue as well?

Has anybody with NI acknowledged this issue?

I consider myself to be pretty advanced when it comes to searching; I couldn't find a single reference to this however.

Anytime I right-click on the FP, and dismiss the tool menu, I get a selection rectangle. If I don't catch it, moving outside the bounds of the FP will cause the FP to scroll to continue my unwanted "selection". So far this has been repeatable every time.

I am running LabVIEW 8.6.1f1, so I am curious to see whether this exists in LV2009. Also, I don't remember seeing this with previous versions, but it's hard to recall.

What do you all think? (I can't imagine this being expected behavior)

-Ian

I'm not a VB developer, but my experience both with the Office API and with various .NET APIs has been that they do have a Count property. Are you saying this isn't a built-in part of collections? I would expect there to be some standard method of retrieving its size.

I see what you are saying here. Most collections I access in VB do have a Count property.

I worked on a project that communicates with Fanuc robots, and used their PC Development Kit, which is a set of ActiveX objects. When the robot has an error, it shows up in a collection of Alarms. The problem with this Alarms collection is that the Count always seems to return 100, whether there are actually 100 alarms or not. Iterating over this using the Count means that you have to look through all 100 alarm obects, even though only one or two may have actual alarms.

I guess that the obvious solution for that problem is to stop when the Alarm object has a non-alarm (or empty, I can't remember which). As I'm writing this, I'm thinking that this may only be an issue with this particular set of objects, and most Count properties would work as expected.

So I will settle on the idea that the Count property should be wired to the For Loop's N terminal to get the proper number of iterations over the collection. I will have to try this out.

Thanks,

-Ian

I'm wondering if anyone knows a better solution to this...

If I call a (for instance) Visual Basic DLL, and it returns a reference to a VB Collection (since LabVIEW doesn't directly support Collections), what is the best way to perform the equivalent of VB's 'For Each' on this Collection in LabVIEW?

If the Count of the items in the Collection is known, you can wire that to a For Loop in LabVIEW. However, if this Collection is an arbitrary length, the only option I know of is to use a While Loop and attempt to index an Item each iteration. Then I wire the Error Out of the property node to the loop control terminal to tell it to stop when we receive an error (which should mean we are out-of-range on our index).

This method seems inefficient and just plain wrong. But I don't see any other way to do this. What do you all think?

(Sorry if few of you have experience with Visual Basic...)

-Ian

Moo's example above looks very close to what I use for this.

One thing to remember is: Always close the references to each object derived from the use of the FRROBOT object. This is a good rule-of-thumb for any LabVIEW project, but it seems especially important when using ActiveX automation.

Keep in mind when using the FRROBOT object, you need to chain everything together from the original FRROBOT.IRobot2 interface.

In the example screenshots Wedge posted above, I see that he is trying to use an 'Automation Open' block to instantiate the IXyzWpr class. All robot-specific classes must derive from the IRobot2 class, which means that you need a handle (refnum) from the IRobot2 object, which is what you will operate on. The functionality you need for the PR[] access is in the RegPositions collection (at least I think it is a collection, LabVIEW isn't installed on my home PC).

Right-click the RegPositions property, and create a new method "Item" (I think). Then wire an Index to get at the specific PR[]. I believe this will be "0" based (i.e. for PR[1], wire in "0" to the Index input). The output from this method node will be a reference to the specific PR[]. From here you need to access the "Format..." method, and supply it with an integer (it's actually an Enum, but I'm not sure it ports over to LabVIEW).

Remember to type-cast the output of the "Format..." method with a "Variant to Data" node, supplying for the data type a class-constant of the type you wish to use; i.e. IXyzWpr. This is a little tidbit I learned while trying to use the PCDK--some properties and methods of the FRROBOT object return a Variant, and others return PCDK-specific class refnums; this is to support multiple output types with less effort from the Fanuc developers. These variants will need to be type-cast into the proper class to be able to use them, but you won't be able to use the type-casting functions in the .NET pallette (as I originally tried to do); this is where the "Variant to Data" node comes in.

If necessary, I can post an example the next time I am near my LabVIEW development PC. I hope this explains a few things, however.

-Ian

Could you build a cluster containing the three controls and add this to an array control? Then you could add or remove elements from the array at runtime.

-Ian

I have been programming Fanuc Robots and communicating between them and LabVIEW for about a year now.

We use LabVIEW to publish data to the robots, as well as start and stop them, and are able to view their status in a LabVIEW FP. We use Fanuc's PCDK (PC Development Kit) for all communications between LabVIEW and the robot controllers. The PCDK is designed to be used with MS Visual Basic, but since the libraries are ActiveX, it is fairly simple to develop a set of drivers to do the dirty work (which is what I've done). The PCDK uses the existing Ethernet ports on the Fanuc robot controllers coupled with their own proprietary protocol to perform robust communication between systems. Using the ActiveX components means I don't have to write low-level protocol specific code to read and write to the robots; the framework handles this transparent to the user.

I took the samples in their lengthy documentation for the PCDK and converted them to LabVIEW equivalent sub-VI's. I took the time to make them application-independent (functions like 'Run Program', 'Reset Alarms', and 'Get Numeric Register Value') so they can be reused readily.

As for the availability of the framework I created, I'm pretty sure I am bound by company policy not to release it (I'd like to offer it for sale, but I would need to discuss it in length with my superiors). I will try to give any assistance I can for anyone interested, however.

-Ian

P.S. I have only implemented a subset of the available functionality in Fanuc's PCDK; nearly all of the features of the controllers are available to access through code using the PCDK.

The MGI toolkit has a Version Info node which uses API calls... It returns 'Development' when you run as a VI, or the executable version in compiled executables. I add the version to my FP's title bar.

http://www.mooregoodideas.com/goodLabViewStuff.htm

I was really getting excited about this! You guys have been playing with Microsoft Robotics Studio too much...

http://msdn2.microsoft.com/en-us/library/bb483024.aspx