Jeffrey Habets

I use the GOOP Inheritance Toolkit from Endevo. It's commercial and does support inheritance. Big plus of their product is that they also have a UML modeller which works in close conjunction with the GOOP wizard. It has features like code generation from UML class diagrams to LV-code and reverse engineering from code to UML, which are real time-savers imho. The GOOP wizard btw is quite feature rich. Things like renaming class methods or entire classes, cloning methods and the class icon editor are al big time-savers for me. I haven't worked with any of the other options. Last time I looked at OpenGOOP closely there wasn't any inheritance yet though.

And while your at it.. Write wrapper VI's for your driver (encapsulate) and use these throughout your application. This way, the next time the same problem arrises, all you have to do is change the wrapper VI's to use the new driver.

Here's a nice example of how to recursively traverse the entire diagram. It can be easily modified for what you want I think. http://forums.lavausergroup.org/index.php?showtopic=308

Try this: http://dev.mysql.com/doc/mysql/en/repair.html as a starting point. I'm not sure though if this particular page will be helpfull if the file is really totally unreadable by MySQL.

This is not a LabVIEW problem. The LabVIEW program obviously uses a MySQL database through an ODBC driver. The error you get is from the MySQL database service. It is unable to open the database table file 'solcelledata.MYD'. So maybe this file is corrupt or deleted. If the database is on a server somewhere, you might need to contact your systems admin.

You could use Mozilla Firefox for this. With tabbed browsing, you can open a complete folder of links in different tabs at once.

It can be done, but you'll need to program it. You can use the IndexVals property of the array in combination with a numeric slider to set the visible part of the array. As of october 3rd it will very probably be built into LabVIEW. :thumbup:

I would probably display the arrayvalues in a listbox. The listbox click events can easily be captured. Then, use the listbox value to index the array.

I think you got me wrong. The 'property' I mentioned doesn't exist (yet). What I ment to say was that it should exist. Indeed the Run-Time Menu Path is not of use for what you want.

Hmmm, nice one.. Although I haven't had the need for it yet, I'd say for sake of completeness there should be a VI property Runtime-Menu reference. Edit: I entered a product suggestion for this on NI's website.

The C notation number += 1; basically is short notation for number = number + 1; So the LV diagram is not that different from C here. The diagram you posted can be simpler. Loose the sequence, it's not necessary (dataflow). Also, you can get rid of one local in this particular example. Whether or not you need the second local havily depends on the context in which you would be doing this operation. Most of the time you will be operating on data in shift registers or results from sub-vi's and displaying those in an indicator. No locals needed there. Learning moment: stop thinking in variables, the 'variable' is the wire!!

You need the VisFrame property. Wire the index of the frame you want to see.

Yes, I understand.. What I (or my customer actually) was interested in, was wether or not it would be possible to recover without MAX (e.g. via ftp). My thought was that this could be possible as long as no crucial OS or FTP-service files would be deleted. So, from your answer I asume that the lock in MAX also pw-protects ftp-access? Do you or someone else know if there's a possibility to pw-protect only certain directories as I would be able to do on *nix systems? (The users needs ftp-access to a certain directory but I would like to prevent them from reaching the rest of the system directories, like chroot-ing.) Hmmm, something inside me tells me this probably isn't possible and should go on the wishlist.

Hi, One of our customers asked me if important system files on the filesystem on his cRIO controller could be deleted through ftp. Since I don't have a RT system at hand to test this and don't want to encourage him to just try it I was hoping one of you guys might shed some light on this. Does the locking feature (in MAX) of an RT-target also prevent deletion of crucial system files? Thanks!

I think in general it is bad to have nested user interfaces (except for dialogs/modal windows), specifically because of the problems you described. Loose coupling of UI and application functionality is the answer. If you need to spawn a subprocess which needs to be monitored and/or controlled by the user, make the subprocess message based, but without a UI and let the owning VI be the UI and control the sub-VI through messages. Although still not the best way to do it, but in your case a nice solution without redesigning your application: instead of using the tab to display a message that the VI can't be operated you could use the tab do display the UI components of the sub-VI that is performing operations at that moment. Subpanels is one option here, the other is passing reference of the controls/indicators you want to be able to use and see. This is ofcourse a very short version of the answer and nothing really implementation specific is mentioned here. I could go further into implementation details, but lets first see how the discussion takes of further.

You are probably using the Current VI's Path constant to build a path to the file or folder you want to create. This constant's value is actually not so constant in that it is different in a build executable. Say your VI is normally located in c:\app\main.vi and you build an exe in c:\app\build\main.exe. In the first case, the constant's value will be c:\app\main.vi in the second case it will be c:\app\build\main.exe\main.vi So in the case of an executable you'll need to strip of one more path element to find the application directory. If you have the OpenG libs installed, you can use the Current VI's Parent Directory VI instead of the Current VI's Path constant. It will figure out if it's running from an exe or dev.environment automatically for you. Or you can do it yourself by looking at the Application.Kind property.

Ok, I thought I knew all the tricks to make LV frontpanels behave nicely in all screen resolutions and DPI-settings but here's one thing I can't solve and I'm not sure this is a LabVIEW (runtime) bug or something Windows/ActiveX-isch thing. I have a LV app running on a cRIO target. The UI is exposed to the user using a webpage with an embedded panel. This runs perfectly on every resolution with the standard dpi-setting of 96dpi. Problems begin to occur when the user has selected 120dpi which is ofcourse the case with our customer. Actually I see this happen often with the crappy non-standard resolutions nowadays. Actually LabVIEW does pretty well with the 120dpi setting when you do not use the application font, but rather something like Arial. If you want to use application font you need to prepare your entire UI for the larger DPI setting unless you think overlapping buttons and such are nice. With the remotepanels something odd seems to happen. See the pics below. The left pic shows the webpage (which is designed of a minimum vertical resolution of 1024 pixels) on my desktop PC with a resolution of 1280x1024@96dpi, it's how it should be. On this same system @120dpi, it also displays as you'd expect and the picture is the same. The right pic shows the webpage on a widescreen laptop with screen resolution of 1680x1050@120dpi. Here it seems the FP itselfs 'shrunk' (since I'd expect it to be about the height of the screenres) and at the same time the embedded LabVIEWControl object grew, since it now expands beyond the vertical screen size (the actual object height=888 pixels). Also if I switch resolution on the laptop to 1280x1024@120dpi, the webpage displays the same as at 1680x1050@120 whereas it displays correct in this very same resolution on my desktop system. So my very fuzzy conclusion would be that on some systems with an unusual native screenresolution at a 120dpi setting some unexpected behaviour occurs when using remotepanels in a webpage. The question remains wether this is a LV runtime problem or Windows/ActiveX related. Has anyone encountered something similar? Or better yet, tell me it's not a bug/problem and the solution is actually very simple.

I know there are quite some folks who disable the autowiring feature because they want to stay in control of the wires (of course). But did you know you can very easily toggle the autowiring on and off with the 'a' key? This in combination with the space-bar for changing the wires' direction (which y'all probably knew already) makes a quite powerfull combo and certainly saves me some mouseclicks now and then.

What you need is the so called Merge VI. First, make a VI that contains the diagram as you want it to have it when you drop it on an other BD. You need to make this VI available on your palette (e.g. place it in user.lib). Under Tools->Advanced->Edit Palette Views you can edit the palettes. Here you can right click on VI's in the palette and select Merge VI to drop the VI's diagram instead of a subVI on your VI's diagram. So what you need to do is find your VI in the palette and enable the Merge VI option.

If you keep that up during the lifetime of the program, yes. I first ran into this because I was constantly (I think it was at a 500 ms rate or so) was reading volume info to provide realtime insight into available diskspace on the flashdevice. After I added the code to do that, all data I thought was written to flash mysteriously disappeared when the device was rebooted. My first thought was something was wrong with the hardware (defective flash e.g.). It took me over a day to figure out what actually was going on.

Found this on a cRIO system and NI reproduced it also on a cFP controller, so this problem probably exists on all ETS RT targets. The filesystem cache seems to get committed to flash every second or so. With each files access you do, the timer used for this is reset. So, if you (like me) for example call the volume info primitive in your idle case and your loop rate is < 1s, this timer is constantly reset and thus all data your write to the flash (either from your app or through ftp) is lost on system reset or reboot unless you gracefully end your application using a stop button and ending your loops (which is mostly not the case on an embedded system). Call the flush primitive you might say.. Well, this doesn't seem to work on the target. So basically I see at least two bugs here: 1. The flush should simply work 2. The calling the volume info primitive should not reset the cache timer

Have a look at CdRecord, popular commandline burning program on unix platforms but also available as windows binaries and a huge number of other platforms. CdRecord home: http://cdrecord.berlios.de/ Win binaries: http://www.sbox.tugraz.at/home/t/tplank/ You should be able to call these tools with the system exec.