Jeffrey Habets

Hehe, my tactic seems to work.. Ofcourse, always looking for better solutions... But when in need for such a thing and no time to develop a better one, you now all know where to find it..

Just a quick note before anyone starts putting this into an XControl. It has already been done: http://zone.ni.com/devzone/cda/epd/p/id/2959

The master slave pattern you are using now is perfectly fit todo what you want. Reading you message, it appears to me that you are trying to put al your code in the toplevel VI. I think you should have a close look at your code (especially the analysis part) and try to refactor parts into sub-VIi's. Try to identify parts of the code that are logically nameable, decide on what inputs and outputs that part should have, and create sub-VI's for those parts. Use good discriptive icons for the sub-VI's. This should clear up your toplevel VI while still understanding what's happening, just by looking at the toplevel diagram.

Some code would help.. I'm not really sure if I know what you mean.. Is it the actual "Display State In" control that get's an unexpected value? Did you probe this in the facade VI? I've been playing a bit with classes in XControls too and have seen some strange behaviour, but haven't been able to put the finger on the exact problem yet.. Need to play around a bit more with this.. Yep, that would be the way to go! And don't forget to notify LV of state/data changes through the action output.

Very nice! Personally I would prefer if the filename was prepended with a backshlash so it's clear to the user that he is seeing the complete filename. e.g. C:\Program Files\Natio...\labview.exe

Hi Ton, I'll be there... I will be talking about XControls.. So I guess I'll probably see you then.. :-)

I'm not sure if I understand what you mean exactly.. I take it that you just want to send data from your cRIO to your host and log it there. You are not controlling (e.g. sending setpoints) from host to cRIO are you? What you probably should use here is an RT program on the cRIO controller that has one DAQ loop for your acquisition and another parallel loop for communication with the host. Now, if you are using LV8 or higher, the comm. with the host could be simply done with shared vars. Otherwise you probably want to implement some basic tcp/ip communication here or maybe use VI-Server.

It's been a while since I did cRIO (it was in LV71), but I'm sure I'm not the only one reading here.. Just shoot..

If memory serves me right, I think you can give the sequencefile path as a commandline parameter to the operator interface (assuming you have an .exe made out of it). You can even use wildcards here to load multiple sequencefiles in the sequence files dropdown list. PS: Maybe another avatar would be more appropriate here.. Thanks.

Hi, I guess this could be solved by introducing an event data field "Discard?" as e.g. is also the case with the "Panel Close?" event. This way the programmer can instruct LV to do the default event handling or not. I would actually expect this option in every filter event.

I had both of these, but there was a typo in SuperSecretPrivateSpecialStuff.. Darn, I missed out on this for this long. :thumbdown: At least I can now confirm this specific entry gives us the extra events.

Someone please tell me how I can access the VI activation event... Is there some SuperSecretIniEntry I don't know of yet? Feed me please! :laugh:

Strange thing... Updating the tipstrip while it's showing works here on my LV8.0.1. Download File:post-906-1150873643.vi

This is basic stuff.. What you need is a case structure. Attach the control to the case selector and add cases for all values you want to catch. See the attached example. Download File:post-906-1150716505.vi

Your agents fit very well in an OO-design.. They would become so-called Active objects, objects that spawn their own separate thread of execution using VI-server. I've used them on multiple occasions and it's a very strong concept.

I guess the most important reason is that with this technique you can create unique references for each class. This way you won't be able to wire ClassA:Method1() to a reference returned by ClassB:Create().

Hmmm, seems to work as expected here.. You should make sure that the reference is a reference to your particular XControl type. If your reference is a generic control reference it's logical that you will only see the methods and properies that are common for all (X)Controls. You can easily create the correct reference by dropping a control ref. on your FP and then drag-and-drop the XControl on top of that to create a strictly typed reference for your XControl. Hope this helps.

This is pretty cool... :thumbup: For me personally, I'd leave out the Error in and out. We all know what they do and they just clutter up the documentation page. (Wish NI would do this too..) And maybe some nice headers for grouping inputs and outputs.

I actually edited a project file ones or twice because I needed a slightly different application and installer build and didn't want to lose the old ones and was to lazy to create complete new build specs. I simply copy/pasted the appropriete tags in the project file and edited the tags relevant for the naming of the build specs. This worked fine. I suppose if you stick with the schema for a lvproj everything is OK. Ofcourse it's always a wise thing to backup your project file before manually editing it.

Hmmm, you're right.. The Exit event only works from the taskmanager's applications tab, not if you kill a process from the processes tab. I guess that's equivalent to unix's kill -9 to unconditionally kill a process. I think that's a good thing btw. There always should be a possibility to unconditionally kill runaway or zombie processes. If you really don't want the user to shutdown your app that way, make sure he doesn't have rights to do that. Don't know much about Windows' user management, but I'm pretty sure a 'normal' user won't be allowed to kill a process that isn't started in the same user's context.

You can use an event structure and catch the Application Exit event. If you use the filter event you can even prevent your app from exiting this way.

Yes, probably the case.. I got another error, invalid file type on a .vi. Probably a corrupt file, haven't checked it yet. My suggestion would be to simply continue doing the mass-compile even if errors occur, so the process won't have to be started all over again.

Thanx Jim, Cool tool... It choked on an error 43 in the Save:Instrument method though. Did a second run where I filter out the error and display the file where the error occurs on and found that the error occured (Thus far, it is still running) on: LabVIEW 8.0\resource\FrameWork\Providers\lvfp.llb\prefPage_FPEthernetBankConfiguration.vi and LabVIEW 8.0\resource\FrameWork\Providers\lvfp.llb\prefPage_FieldPointEthernet.vi

I can beat that easily.. :-) 4hr:20min and the damn thing is still running.. I must admit I have quite some toolkits installed but this is a real pain..

Any chance you are using the DeferPanelUpdates propertie in your application? I've noticed this behaviour too (in LV8) but haven't really investigated it. *I think* it has to do with nesting constructs like: MainVI->DeferPanelUpdates := true MainVI->DeferPanelUpdates := true MainVI->DeferPanelUpdates := falseMainVI->DeferPanelUpdates := false At least.. Preventing this does the trick for me..